Skip to Content

Technical Enhancements within Dealer Business Management (DBM) – the Flowerpot and Actions

 

Introduction

 

A quick search on SDN for the word “flowerpot” and “DBM” revealed little information of initial relevance. I have not gone mad and we are not talking botany or database management but are talking about aspects of the dealer business management component of the ECC Automotive industry solution. Like many industry solutions, this is fertile ground for developers with many enhancements often being required. This is an attempt to provide a starting point and a cross technical-functional perspective of how you can enhance the order engine (OE), core component of the DBM 6.0 solution.

 

The basics

 

DBM is part of IS-AUTO however in practical terms it is the SAP ERP industry solution for all things related to the retailing of vehicles. All aspects of a vehicle – the manufacturer, model are created as master data in the system and vehicles can be traded accordingly using solution specific aspects of the standard logistics solution (sales order, purchase requisition, purchase order, goods receipt and billing). The two transactions which form the mainstay to functionality can be enhanced using the action concept.

 

Order actions are delivered as standard business functionality but new actions and modification to existing actions can be achieved – some examples of which an implementation developers might be involved in:

 

  • Additional business functionality such as dirty core processing, credit check or authorisation processing
  • Enhanced existing functionality such as additional checks before billing or order save

 

It should be noted that whilst the order and the vehicle both use a concept of actions, the two are each quite different from one another. This document will just discuss order actions and the information is only relevant to order engine actions.

 

The order

 

Within the DBM order an action is defined as a self-contained business transaction. Unlike the VMS action concept, DBM order actions are linked to one or more events. Events form part of a core framework called the order engine which drives processing of the DBM order. This is defined in the customising:

 

Transaction /DBM/SPRO and select Order / Order Control / Enhancements

 

The event, akin to a “process controller” to execute one or more business transactions (actions):

 

event details

 

The action should represent a self contained business transaction:

 

action details

 

  • There are several methods of executing an event which is essentially a process step
  • o From within an order when you do something implicitly e.g. ITEM_CHANGE
  • o Explicitly from within an order by selecting an event from a popup list (dialog)
  • o Externally from outside an order e.g. standalone program, interface, CRM etc

 

  • In all cases an access sequence must be fulfilled. The access sequence can consist of one or more criteria tables which can include many different combinations of data. This offers considerable customising flexibility and control over how a process is executed – much more than in the vehicle master
  • In addition to an access sequence, the processing and availability of individual actions is status dependent i.e. actions can be made relevant only under certain conditions e.g. goods movement (GDSMVT_CREATE) is only performed if all items are not marked as rejected or an order is released

 

Unlike in the case of the vehicle master, an iOBJECT is not used to store data. Data is stored in transparent tables that are akin to the traditional SD DDIC design. The tables are within the /DBM/ namespace and include /DBM/VBAK_DB (order header) and /DBM/VBAP (order item).

 

Order Action Enhancements – BAdIs

 

SAP produce a very useful cookbook which can help guide enhancements to the order engine. The latest version can be found under note 1105899:

 

https://service.sap.com/sap/support/notes/1105899

 

There are a number of enhancement spots available throughout the DBM order transaction – search from transaction SE18 using the prefix /DBM/ORDER* for a full list and the corresponding BAdI’s.

 

From an order action perspective three of the main BAdI’s can be found within the action customising:

 

Level and Definition

Enhancement Spot

Description

Preperation

/DBM/BADI_OE_ACTION_PREPARE

/DBM/ORDER_ENGINE_IMPL

Determination of Actions – use for checks ahead of the action being called

Execution

/DBM/BADI_OE_ACTION_EXECUTE

Action execution – the core business process

Post processing (finalize)

/DBM/BADI_OE_ACTION_FINALIZE

Post processing of action – executed after the action has been executed sucessfully

 

TIP: Do not fall into the mistake of thinking that every implementation needs to be created in the same enhancement implementation. When you create an implementation the system proposes an implementation – it is not mandatory to use that implementation. Structure your implementations logically as you would other developments. Putting everything into one enhancement implementation can result in serious grief when it comes to transporting enhancements!

 

The 3 levels of implementation form the core of the DBM order engine. The order engine is a central framework around which the DBM order transaction UI has been built. See function module /DBM/OE_MAIN_CONTROL or crucially static method /DBM/CL_ORDER_ENGINE=>RUN(). The event is executed from within this method (see method PROCESS_EVENT) and thereafter the action(s) (method PROCESS_ACTIONS). You can use checkpoint group /DBM/OE_ACTION to debug the order engine ahead of actions being processed.

 

Although BAdI’s can be placed in any action you are advised to steer clear of any actions where the “system action” flag is checked in the configuration. These actions are core to the standard working and processing of the DBM order and although can be enhanced should be treated with further respect.

 

TIP: standard implementations e.g. see enhancement implementation /DBM/ORDER_ACTIONS_IMP are not shown by default in the order action customising however these can be shown by typing =SAP in the transaction code box when viewing action configuration detail.

 

 

The Order Class

 

Within the order data is held within a central object – super class /DBM/CL_ORD_OBJECT and sub class /DBM/CL_ORDER. Internally amongst DBM developers this class is affectionately known as the ‘flowerpot’ due to its size and spherical like aspect of the data it holds. It is important to note that /DBM/CL_ORDER is only one of a number of classes that inherit from /DBM/CL_ORD_OBJECT:

 

order class

 

There are many attributes to the /DBM/CL_ORDER class however data is split in three principal areas with following prefixes:

 

Area

Description

DETAIL

The DETAIL area is just to build an interface to the main program which is calling the order engine. Changes and creation of new elements (items, jobs, …) are transferred via this area to the action.

COM

The COM area contains always the status quo of the order

DB

The DB area contains always the last saved version of the order i.e. DB version.

 

TIP: Note the read-only status of many attributes à adhere to the DETAIL to COM data transfer described later; don’t think of modifying COM or DB attributes directly!

 

Everything to do with the order is stored within this class including:

  • o Order header
  • o Order Item
  • o Jobs
  • o Tasks
  • o Splits
  • o Partners

 

Order action enhancements – a practical example

 

A new item level Z event and action called ZSTORAGE_LOC_CHA have been created in the configuration and linked together:

 

criteria table

 

The standard criteria table /DBM/OE_EVAC_DEF is used to define a new custom event and action. Within the action ZSTORAGE_LOC_CHA, click on the execution button to see the BadI that will be executed when the event and action are executed:

 

BAdI implementations

 

 

Within the respective method you may see the “raw” code or a public/static method call to pass a function module name. The interfaces for preparation, execution and finalize BadI’s are each slightly different – I have created class ZCL_ASG_DBM_ORDER_UTILITY which has static methods to cover all 3 scenarios:

 

utility class

 

TIP: create a generic bespoke class, in this case ZCL_ASG_DBM_ORDER_UTILITY with 3 static methods to handle your new action functionality whether it is preparation, execution or finalize implementations. Copy the standard code from the respective standard class/methods into your static methods e.g. class /DBM/CL_ORD_AX_ACFMOD / method CALL_ACTION_FM for the execution implementation. The advantage of using this approach is:

 

  • One standard interface (cut n paste for all your z actions)
  • Reusability – no need to create multiple methods to do the same thing
  • “Standard” exception class handling and control

 

In our example the code in the BAdI is:

 

BAdI code

 

The function module ZVSG_001_STORAGE_LOC_CHANGE_01 gets the value of a parameter id that is set elsewhere and if a value exists replaces the existing storage location value.  The message log is then updated to show the execution of the action and the change in storage location values.

 

The code to do this in the function module:

 

  DATA: LV_DUMMY        TYPE STRING,
        LV_LGORT        TYPE LGORT_D,
        LV_LGORT_OLD    TYPE LGORT_D,
        LS_ITEM_DETAIL  TYPE /DBM/S_POS.

* —Ensure a storage location exists
  GET PARAMETER ID ‘ZDBM_NEW_STORAGE_LOC’
      FIELD LV_LGORT.

  CHECK LV_LGORT IS NOT INITIAL.

* —Get the item struc & update the location
  LOOP AT IO_ORDER->MT_VBAP_COM
          INTO LS_ITEM_DETAIL
          WHERE SLCTD = ABAP_TRUE.
    LV_LGORT_OLD = LS_ITEM_DETAIL-LGORT.
    LS_ITEM_DETAIL-LGORT = LV_LGORT.
    APPEND LS_ITEM_DETAIL TO IO_ORDER->MT_ITEM_DETAIL.
  ENDLOOP.

*……………… Call Event ITEM_CHANGE ……………………… *
  IO_ORDER->ITEM_CHANGE( ).
  MESSAGE I194(ZASG) WITH IV_ACTION LV_LGORT_OLD LV_LGORT
          INTO LV_DUMMY.

  IO_ORDER->BAL_ADD_SYMESSAGE( ).

 

General Notes:

  • In the above example we get the selected item record from attribute MT_VBAP_COM (field SLCTD is set for all selected items – something which is dependent upon the action customising)
  • Standard method ITEM_CHANGE can be called to update the new storage location details
  • This action is a simple example – it does not do anything with statuses or document flow nor is it status dependent
  • (A) Golden rule – by all means update data via actions however don’t add in COMMIT’s, the standard framework will look after this. As a good practice you should not set a bespoke action to commit in the configuration unless it is explicitly required. Note the “automatic-save” feature on events – not enough time to go into detail here however the order can be saved automatically without request
  • Recursive calls à it is very easy to get into a situation where an action is called repeatedly by triggering itself again as a result of inappropriate method calls which can result in poor performance at best and un-explainable error messages at worst!
  • Method BAL_ADD_SYMESSAGE appends a message to the DBM order action log. Usage of the action log cannot be underestimated – do not use it at your peril!!

 

Other Sources of Information

 

Although DBM is very much a niche solution there does exist some sources of other information. In addition to the vehicle and order cookbooks you should consult:

 

The standard DBM 6.0 solution online help

http://help.sap.com/saphelp_dbm600/helpdata/en/6F/9FC1FA5E8F44B2858B845A3AD1249E/frameset.htm

 

Standard best practices

http://help.sap.com/bp_dbmv1600/DBM_DE/html/index.htm

 

The Automotive forum on SDN

SAP for Automotive

 

Conclusions

 

We have barely scratched the surface from an enhancement perspective and what can be achieved – whilst the vehicle master offers significant opportunities, the DBM order engine offers a developer even further opportunities and challenges for development. The order engine framework is an ideal mechanism for developing enhancements and you can re-use many of the standard methods within the flowerpot – class /DBM/CL_ORDER.

 

…a word of caution however – whilst the scope of this should excite you it can also be the cause of its own downfall. It is possible to trigger actions which result in the abrupt termination of the order engine in certain circumstances which can be extremely hard to scrutinize. I have heard examples of the order transaction being “down for days” in extreme cases where a rogue action has done something but nobody can work out where the actual rogue code is. In the order engine you have immense power and control to enhance, however just be respectful of that!

 

It should also be pointed out that although you can use any of the standard methods and concepts described in this document you should understand that you do so at your own risk. Methods such as ITEM_CHANGE are not released APIs and as with all standard code subsequent changes to them can occur in later versions without notice or warning. From a technical perspective this can mean something working one day and not the next – even with this in mind however many meaningful and significant enhancements can still be achieved.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Ganesh Sawant
    Thank you for focusing on the DBM Order engine in such a detail. I need your help regarding the appointment sheduling. I did all HR, MRS and WFM configuration but still not able to fine reason why i get error 1. service advisor is not relevant. 2. I do not get appointment sheduling button on the screen.

    Thank you in advance.

    (0) 
    1. Roger Sainsbury
      Hi Ganesh,

      I dealt with scheduling on the same DBM project as David. We actually ended up using our own bespoke scheduling solution, so I can only give my best guess as to what might be causing your problems. I think you are going to need to do some debugging!
      #1 Perhaps somewhere in master data you can specify the possible list of service advisors from the org structure, and you’ve tried to use someone else?
      #2 We encountered a similar problem to this. In our case it seemed to be down to the task data on the order. It looks like tasks were largely designed to drive scheduling, and so if you don’t have a valid task, then it doesn’t think you need to schedule anything. We’re not actually using tasks, but we create dummy ones to keep the standard button on the screen.

      I hope that’s of some help.

      Roger

      (0) 
      1. Ganesh Sawant
        Hi Roger,

        Thank you.

        You are correct.

        Problem 1:  I found that availability data for employee in HR is not transferred  incorrectly to WFM by report   “/MRSS/HCM_RPTWFMIF “  I don’t  know why  it is transferring availability data with very old dates ( e.g 1970 ) So I made manual changes. And it is ok for time bing.

        Problem 2: for “Appointment Scheduling” button not visible in service advisor.

        As per SAP     – If the Event can be executed (at least one action assigned to this event can be executed) the button is shown. I made all check and found I have made the action entry for corresponding access sequence in table.  Can you tell what is the exact customizing for this  ( Event , Stats ID, Action Control Matrix, and Action etc.) .  As you suggested that can you please what is exact way to maintain dummy task.

        If you want any information please mail me at below email
        1.     Ganesh_Sawant@satyam.com
        2.     GSAWANT@NISSAN-EUROPE.COM

        Thank you again.

        Regards,
        Ganesh Sawant

        (0) 

Leave a Reply