Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

Version 1 Next »

Commission Management


Introduction

Business Context

In the automotive area, especially the vehicle sales, it is common practice, that the salary of an employee gets together by a lower fixed salary and a variable commission e.g. in sales based on the vehicles and accessories he sells.
To support this commissioning process the proaxia DBM|E Core component provides the business function "Commission Management".
The concept of "Commission Management" is based on the SD invoice, so this business function can be used for all departments, which use the SD invoice within their process, e.g. like parts sales, service workshop, etc.
Because the solution itself is quite flexible and it is difficult to describe some functionalities in a transparent way without a concrete case, we use in the following documentation the process "sales commission" as use case.
Solution Overview

Figure 10: Solution overview
Example "sales process" overview:

  • Based on the customer (SD) invoices the commission is calculated on company individual rules.
    • Message of the SD invoice is the trigger
    • Commission type and other values came from basic settings
    • Formula builder with individual rules will be processed and calculate the commission value
    • Based on the salesman of the invoice the partner roles of the commission and also the commission split values are determined (split only in case of pool commission)
    • This step normally happens automatically in the background


  • The calculation result normally will be checked by the sales administration department.

Are all relevant documents are available (contract, leasing,…)

    • Do the system values fit to the documents and is the calculation correct?
    • If relevant, enter additional special conditions (e.g. special agreements)
    • Release the commission "checked by administration"
    • This step normally happens in the proaxia DBM|Ecommission monitor


  • The calculation result normally must be released by the salesman himself.


    • Check values and if all is fine, then release the commission
    • In case of differences between the calculation result and an individual agreed commission, the salesman will be able to apply the difference.
    • This steps could happen in the proaxia DBM|E commission monitor or e.g. by a customer individual non-SAP frontend.


  • In case of differences the responsible sales team leader has to release / to reject in addition the salesman changes the request.


    • In case of release, the correction is accepted and the transfer to HR can start
    • In case of rejection, the commission returns to the salesman and he must correct again
  • Finally, the released / accepted commission is transferred to the HR department to pay corresponding value with the salesman salary.


Based on the customer's philosophy the salesman and maybe also the salesman team lead, do not directly work in the SAP system. In such a case, it is also possible to integrate e.g. a company own UI5 solution for them. Such an UI5 solution is not part of the DBM|Ebusiness function "Commission Management". But to support such a solution, we provide the corresponding web services for the connection / integration of such a customer solution.
The same philosophy we support for the HR transfer. Some customer use SAP HR and will maybe fully integrate the DBM|Ebusiness function "Commission Management". Others use maybe an external system and just want to have a simple list print out. So here we provide the corresponding web services for the transfer of commission values.

Business Function Master Data

The customer maintenance of DBM|E Commission Management can be done by business department or business administration, but also by the IT department. Which department does the single maintenance depends on the organisation and the individual definition of the single customer.
The DBM|E Commission Management customer maintenance can be called by using the single transactions or by using the DBM|E user menu.
Here we describe the following maintenance transactions:

  • Posting calendar
  • Employee and pool
  • Calculation logic (formula builder)


Maintain Posting Calendar

Usage

Definition of single dates within the DBM|E commission posting calendar, which is assigned to each DBM|E commission type.
In the posting calendar itself, the dates for transfer of the commission values to HR is defined.
The idea behind the calendar is, to plan a daily job for the transfer of commission values to HR, but process the transfer only at defined days.

  • T-Code: /DBME/PMA_PCLND
  • Selection screen


Figure 11: Maintain posting calendar - entry screen
Choose the corresponding calendar ID and the year for definition of transfer days. For initial setting of the calendar ID there is the user parameter /DBME/PMA_PCALND available.

  • Calendar maintenance

Figure 12: Maintain posting calendar - main screen
Show the calendar of the selected year with the corresponding information:

    • day is a no working day (based on factory calendar) without / with transfer of commission data to HR
    • day is a public holyday (based on holyday calendar) without / with transfer of commission data to HR
    • day is a working day (based on factory calendar) without / with transfer of commission data to HR


  • Calendar functions


    • To switch between without / with transfer of commission data to HR process a single click at the date
    • Icons
  • "refresh"- refresh displayed information in case of change of factory / holiday calendar
  • "clear all"- remove all marked transfer dates from current year
  • "copy days"- copy transfer dates from another calendar to this calendar (show an additional popup to select source calendar ID)
  • "previous year"- switch to year before; changes must be saved before
  • "next year"- switch to next year; changes must be saved before
  • "legend"- show color legend


Authority check

  • Authority object "/DBME/P_PC" for activity and calendar ID


Maintain Employee and Pool

Usage

Definition of commission relevant employee within the DBM|E commission processing.
Not all employee of a company should get a commission based salary e.g. they have a defined fix salary and so, they should not get additional commission. And so it is necessary to announce the commission relevant employees to the system. During commission creation, the standard DBM|E logic checks the main partner role (e.g. sales man) again the settings done within this employee maintenance and decide, if a commission is created in initial status (e.g. new) or in denied status (e.g. not relevant for HR).
Additionally, here we have the possibility to build a so called "pool". A pool is a group of employees participating of each commission of a main employee of the group. The complete commission value in such a pool case is distributed to all employees of the pool based on defined percentages.

  • T-Code: /DBME/PMA_PEMPL
  • Selection screen



Figure 13: Maintain employee and pool - entry screen
Normally you choose here the corresponding plant for definition of relevant employees.
If in some cases the employee could work for several (all) plants, you can also define them "without plant assignment".
If you just want to handle a single / a reduced group of employees, you also can enter here directly their personel number(s).
In addition, there is the information functionality called by the icon . Pressing the icon, an ALV list with all maintained employee is displayed, depending on the corresponding selection criteria:

  • No selection criteria are entered  show all entries from table /DBME/PMA_APERN
  • Only Plant is entered  show all entries from table /DBME/PMA_APERN where the plant is equal to selection
  • Flag "without plant" is active  show all entries from table /DBME/PMA_APERN where the plant is empty
  • One PERNR is entered  show all entries from table /DBME/PMA_APERN where the PERNR is equal
  • One PERNR and plant is entered  show all entries from table /DBME/PMA_APERN where the PERNR and plant is equal


If no corresponding entry was found, empty ALV list is shown.

  • Employee maintenance

Figure 14: Maintain employee and pool - employee assignment
The list shows all already assigned employees and their validation (concerning criteria at the selection screen). In addition, you see if an employee is assigned to a pool or not.

  • To add new employee, press icon or and enter personal number and validity dates
  • To remove an employee, mark the corresponding line and press icon
  • To duplicate an existing employee, mark the corresponding line and press icon
  • All other icons are standard ALV functions like sort, search, filter, etc.
  • If you want to change to the general pool screen, press icon in the header function list
  • If you want to change to a specific pool, press icon in the corresponding employee line
  • If you want to check consistence of the actual data, press icon in the header function list; here are some general checks processed, like:
  • All pools must have a total of 100%
  • Validity of a single employee should not be shorter, than validity of a pool he is assigned to
  • Only employees can be assigned to a pool, that are also in the list of relevant employees


  • Pool functions – pool definition


Figure 15: Maintain employee and pool - pool overview
The list shows the general view all already created pools and their validity periods. In addition, the number of assigned employees and the pool status (ok / not ok) is shown.
In case you enter the pool screen for a special employee, only the pools are show, where the employee is assigned.
The pool definition (left side ALV) and the pool employee assignment (right side ALV) are together at the same screen.

  • To add a new pool, press icon and enter pool description and validity period dates
  • To change existing pool values, mark corresponding line and press icon
  • To remove a pool, mark the corresponding line and press icon
  • To duplicate an existing pool, make the corresponding line and press icon
  • All other icons are standard ALV functions like sort, search, filter, etc.
  • If you want to check consistence of the actual data, press icon in the header function list (similar functionality like in employee maintenance)


  • Pool functions – pool employee assignment


Figure 16: Maintain employee and pool - employee pool assignment
The list shows all assigned employees concerning the selected pools (depends on how you enter to pool view).
The pool definition (left side ALV) and the pool employee assignment (right side ALV) are together at the same screen.

  • To add new employee, press icon or and enter personal number and percentage; take case that total of percentage over all assigned employee must be 100% (per pool)
  • To remove an employee, mark the corresponding line and press icon
  • To duplicate an existing employee, mark the corresponding line and press icon
  • All other icons are standard ALV functions like sort, search, filter, etc.
  • If you want to check consistence of the actual data, press icon in the header function list (similar functionality like in employee maintenance)


Authority check

  • Authority object "/DBME/P_PE" for activity and plant


Maintain Predefined Condition Text Entries

Usage

Definition of predefined text entries for a single manual price condition within the DBM|E commission.

  • T-Code: /DBME/PMA_ACNDR

Maintenance screen:

Figure 17: Maintenance view for predefined condition text entries

  • If here for a manual price condition no entry exist, the text in the condition is open for free text entry.
  • If here for a manual price condition only one entry exist, this text entry automatically is set for the condition in the commission.
  • If here for a manual price condition are several entries exist, the user must choose one of this text entries from provided list. Only these entries are allowed.


To enter translation for the text entries, choose in the menu "Goto -> Translation".

Authority check

  • No DBM|E specific authority check.


Maintain calculation logic (formula builder)

Usage

The main calculation of final commission value should happen within the SAP standard "formula builder", used by DBM|E commission management.
Because each formula builder logic / calculation is fix assigned to a single DBM|E calculation type, the point of entry to the corresponding formula builder application is done via a button in calculation type customizing (by pressing icon formula builder).

Figure 18: Maintain calculation logic - entry formula builder via settings
In general, there are no preconditions required to use the formula builder, just a DBM|E calculation type must be defined. However, each customer requirement concerning commission calculation will be very different and in most cases we expect some additional values / enhancements will be required. To get this additional values / enhancements, there are a various of different possibilities within DBM|E commission management. But some are maybe not the best way to do and so we set here some general rules to get a proper solution:

  • All values from commission based documents (e.g. invoice, VSS order, vehicle), that should be used for calculation and could be changed within these documents after commission creation, should be copied to commission header structure extension during commission creation.
  • All values that should be used for calculation and can be determined already before formula builder, should be enhanced by own parameter structure and values should be filled by own BAdI implementation (in case fields are not already in the commission header enhancement)
  • All values that should be used for calculation, but determination is based on results of the formula builder logic, should be enhanced by own function class and own methods within this class
  • The result structure of the formula builder should only hold information, that are calculated during formula builder logic and which could not be determined later on e.g. name of salesman for displaying in HTML calculation sheet makes no sense to transfer


Entered to the formula builder maintenance screen, the shown areas are always the same -just the provided values could be different, depending on the DBM|E calculation type and the provided enhancements.
To learn in detail, how to work with formula builder application, we refer to the SAP standard documentation in SAP help portal. However, here we will give a short overview about the main areas of the application:

Figure 19: Maintain calculation logic - formula builder overview

  • Area 1 - "overview"

The overview shows all for the own calculation defined steps.Here we make difference between step types "conditions" and "substitutions".

    • condition if condition with result true / false
    • substitution single logic line


To add a new step, mark the corresponding line after that you want to enter new step and press right mouse button to pen context menu and choose condition / substitution.

Figure 20: Maintain calculation logic - create new condition / substitution
In addition, you have by calling the context menu also the possibility to move a single step up / down (also possible by drag&drop), to copy or to delete marked step.

  • Area 2 - "step"Here you define description of your step, shown in the overview screen.The description itself is obligatory, but we recommend to do it, to keep better overview about your calculation logic.
  • Area 3 - "parameter"Shows a list of fields, which could your result value. It doesn't matter if this is a final result or just a "help result for handling". So for each substitution entry you must define a parameter as target of your calculation logic. The following parameter values are provided:
    • Total commission value - transferred to commission header


    • Some DBM|E standard work fields from type text - no transfer
    • Some DBM|E standard work fields from type value - no transfer
    • Fields of customer enhancement "substitution structure" – transferred to commission calculation
  • Areas 4 - "value type"Here you define if your result should be a fix value or a formula result.
  • Areas 5 - "logic definition"In case you choose in the area before the value formula result, you must enter here your formula. To build up your formula you can use the available fields and functions (see next areas).Using the icon you can switch here between "description mode" and "technical mode" (expert mode).

Examples for logic definition:

  • Using standard functions
    • Value Item Type 01 + Value Item Type 02
    • ABS( Value Item Type 04 / Base value vehicle ) * 100


  • Using DBM|E functions
    • LOOKUP_PROVISION_ITEM_VALUE( PROV_DATA-PRNUM, '01' )
    • LOOKUP_CONDITION( 'ZPVE', Document Date, Percentage discount of vehicle value, 'VKORG', Sales Organization, 'VTWEG', '00', 'PMATN', Material, '', '', '', '' )
  • Areas 6 - "available field"Shows a list of fields, which could be used to build up the formula logic. So for each condition / substitution entry you can use this fields in combination with the available functions to create condition or to fill the chosen parameter. The following available fields are provided:
    • Standard DBM|E commission header data
    • DBM|E standard work fields from type text(see also parameter)
    • DBM|E standard work fields from type value(see also parameter)
    • Some standard SYST data
    • Fields of customer enhancement "parameters"
    • Fields of customer enhancement "substitution structure"
  • Areas 7 - "available function"Shows a list of functions, which could be used to build up the formula logic. So for each condition / substitution entry you can use this fields in combination with the available fields to create condition or to fill the chosen parameter. The following available fields are provided:
    • Arithmetic functions
    • Logical functions
    • Character functions
    • DBM|E standard functions
    • DBM|E customer enhanced functions (by class / methods)


Because the description in some cases is not so clear, the complete handling of formula builder can be switched to expert mode.

Figure 21: Maintain calculation logic - switch to expert mode
In that case, the single steps in the overview area shown with the technical names, like in the following screen:

Figure 22: Maintain calculation logic - formula builder example logic in expert mode

Authority check

  • No DBM|E specific authority checks


Customer Enhancement

  • Formula builder logic itself is the enhancement


Functionalities

Here is rough overview about all application / functions used by Commission Management solution.
Some of the DBM|E Commission Management customer functionalities can be called by using the single transactions / the DBM|E user menu. Others happen in background, e.g. like create commission out of the invoice by message.

  • Here we describe the following maintenance transactions:
  • Create commission based on source document invoice
  • Create cancellation commission based on source document invoice
  • Create manual commission
  • Application "commission maintenance report" – ALV
  • Application "commission maintenance report" – detail
  • Report "mass redetermination"
  • Report / interface "transfer to HR"
  • Interface "maintenance in external frontend"


Creating commission based on source document invoice

Functional Requirements

The trigger for the creation of a commission based on source document invoice, is the standard message handling of an invoice. In order to setup this process, just create an individual SD invoice message type (application V3) with all corresponding steps (access sequence, message schema, message condition) and assign the "printing" program, which call the creation of commission.
As result, the commission is created automatically in the background, when the message is processed successful. The status of the processing and also the created commission number, you can see in the message protocol / log of the invoice.

Figure 23: Create commission - successful invoice message log
Relevant for a successful creation, is that all customizing settings have been done, like commission type definition and determination, number range definition, item type definition and determination, etc.
To ensure, that there is for each invoice always only one commission, a corresponding check is processed during commission creation.

Figure 24: Create commission - invoice message log with error
If you want to reprocess the creation and start an additional message, you first must delete the existing commission with the reference to this invoice.
During the processing all defined values of the settings, the source invoice, the VSS order the invoice is coming from and the vehicle that is assigned to the VSS order ( both only in case VSS 2.0 package is installed), are stored in the corresponding commission tables. Also, some admin stuff like created by, creation date, etc. are stored.

Figure 25: Create commission - detail view
Note: You should store (by enhancement) always all values from source documents, that you want to use in calculation. This especially (only) is relevant, when these values could change after commission creation, e.g. like some values in vehicle. Otherwise you will never get a stable calculation result.
The commission date (in DBM|E standard) initial will be the creation date of the commission. But this date is especially important, because it is used also for the complete calculation as basis date, e.g. for determination of price conditions, and also to check validity of relevant employee. So, in case the customer defines here different dates as relevant calculation basis, e.g. invoicing date or selling date of the car / car contract date, this date should be updated with BAdI during commission creation.
Concerning the register / table "conditions" nothing happens during the automatic creation. Register and table are initial empty.

Figure 26: Create commission - register "conditions"
Also during the creation, the partner verification and determination is done. Based on the determined commission type definition (main partner) there is a check that corresponding partner role is assigned within the invoice. If the partner role is not in the invoice, no commission will be created. Is the partner role assigned, the creation checks the settings of "relevant employee". Is the partner number not assigned here, the commission will also be created, but with the status, that is assigned to the business operation "CRNR" (Create inactive commission) in the status schema settings, e.g. in proaxia example case this is "0008" (not relevant for HR transfer). In that case the commission result automatically is zero.

Figure 27: Create commission - info & register "participants" when partner is not assigned
Is the partner number assigned in the relevant employee settings, the commission will be created normally with the status that is marked as "initial", e.g. in proaxia example case this is "0001" (new). In that case the creation checks in addition, if the main partner is part of a valid pool definition. If he is, also all additional partners from pool will be added with the defined pool partner role from commission type definition.


Figure 28: Create commission - info & register "participants" when partner is assigned
When all data of the commission is determined, finally the calculation in formula builder is called and the result is returned to the commission calculation table. The main idea to show relevant values of the calculation and also the calculation result, is to display them in the HTML view of tab / register "price/commission".

Figure 29: Create commission - register "price/commission"

Creating cancellation commission based on source document invoice

Functional Requirements

The trigger for the creation of a cancellation commission based on source document cancellation invoice, is the standard message handling of an invoice – like the normal commission / invoice.
The main difference between creation of a normal commission and creation of a cancellation commission is, that cancellation commission must be connected to the original commission. So, during creation the cancellation commission determines the original commission based on information in the invoice field VBRK-SFAKN (Cancelled Bill.Doc.). When the original commission is determined, the cancellation commission is created depending on the case based on the values of the original commission and the status of the original commission maybe will be changed.
During the creation processing also here defined values are taken from the settings and the source documents (invoice, VSS order, vehicle). But especially the commission values are not calculated new by formula builder. To ensure, that commission value result is 100% like the original commission, they are transferred "1:1" from the original commission. So the following main values are taken from original commission:

  • Commission date
  • All entries of commission participant table
  • All entries of the commission calculation table


Also, if these entries are copied from original commission most likely "1:1", there could be small differences, because creation of cancellation commission must happen case depended, based on the actual status of the original commission.

  • Case A:Original commission is up to now not transferred to HR – "is open"


    • Commission date is copied 1:1; this is relevant because of "steering meaning" concerning the check of the employee's validity
    • Partner entries are copied 1:1, just the flag "calculation relevant" always will be initial and the administration data will be updated with actual values
    • Calculation entries are copied 1:1, just the administration data will be updated with actual values
    • Status of the cancellation commission will be directly set to the target status of business operation CRCA (or function module logic) which should be a status from type "canceled"
    • Status of the original commission will be changed to the target status of business operation CANC (or function module logic) which should be a status from type "canceled"


  • The objective is that cancellation commission has the same value results, both commissions are no longer changeable and both commissions are not relevant for the transferred to HR


  • Case B:Original commission is already transferred to HR – "is in HR"


    • Commission date is copied 1:1; this is relevant because of "steering meaning" concerning the check of the employee's validity
    • Partner entries are copied 1:1, just the administration data will be updated with actual values
    • Calculation entries are copied 1:1, just the posting information will be cleared and the administration data will be updated with actual values
    • Status of the cancellation commission will be directly set to the target status of business operation CRCA (or function module logic), which should be a status from type "ready to transfer to HR"
    • Status of the original commission will not be changed and so still is from type "already transferred to HR"
  • The objective is that cancellation commission has same value results, cancellation commission in best case should be no longer changeable, cancellation commission will be ready for transfer to HR and original commission is not changed in any way


Note: The values on data base level are also for cancellation commission stored always "positive" (okay, if there is negative value from original, this is also negative in commission). These values are also shown always "positive" at the screens. So, when implementing BAdI for the HR transfer you have to take care, that you multiply them by "-1" based on case commission / cancellation commission.
So, the header information of a cancellation commission most likely is similar to a normal commission. There is just an additional checkbox, showing that it is a cancellation.

Figure 30: Create cancelation commission - detail view
Concerning the register / table "conditions" also for cancellation commission nothing happens during the automatically creation. Register and table are initial empty.

Figure 31: Create cancelation commission - register "conditions"
Concerning the register / table "participants", we have case depended the situation described above.

  • Case A:Original commission is up to now not transferred to HR – "is open"

Figure 32: Create cancelation commission - register "participants" in case original commission is still open

  • Case B:Original commission is already transferred to HR – "is in HR"

Figure 33: Create cancelation commission - register "participants" in case original commission is already transferred
Concerning the register / table "price/commission", we should see the same information like in the original commission (because of copy all entries of commission calculation table 1:1.

Figure 34: Create cancelation commission - register "price/commission"
Note: Because the design of the HTML view will be defined customer individual by using own elements with own structures and own BAdI logic, we can't ensure that we will see here always 1:1 the same information like in original commission. So, during creation of the HTML view (elements/structures/BAdI) you should always keep in mind, that also the cancellation case should show same information.
Note: Because in some cases the cancellation commission also has to update the original commission, the original commission must be changeable during cancellation commission creation. If this is not possible (e.g. original is locked by a user) the processing of the cancellation invoice message fails and must be reprocessed

Figure 35: Create cancelation commission - log in case of errors

Creating manual commission

Functional Requirements

To create a manual commission, there are two possibilities – by separate transaction "create commission" or out of the commission report ALV list (via icon ). In both cases the user gets the same screen to enter the manual commission data.

Figure 36: Create manual commission - creation screen
When all relevant values are entered and confirmed with ENTER, a new commission without connection to a source document is created.
Comparing to the creation out of a source document, there is no check, if such a commission already exists. So theoretically, you can create the same manual commission several times – if you like to do .
During the processing also all defined values of the settings are stored in the corresponding commission tables. Also some admin stuff like created by, creation date, etc. are stored.

Figure 37: Create manual commission - detail screen
The commission date here also (like in source document based commission) will be the creation date of the commission. But this date is not so relevant in a normal manual created commission, because you usually create to set it with a fix commission value (not a calculated value).
The entered values from creation screen, you will find initial in the register / table "conditions".

Figure 38: Create manual commission - register "conditions"
The definition which conditions are shown at the creation screen and which price conditions are used to store them in the commission condition table is done by the customizing / settings of commission type definition.
Example 1 – one value: Example 2 – two values:

↓ ↓

↓ ↓

Figure 39: Create manual commission - steering of available conditions at creation screen
Also during the creation, the partner verification and determination is done. The logic here is like the source document based commission creation.

Figure 40: Create manual commission - register "participants"
When all data of the commission are determined, finally the calculation in formula builder is called - okay, normally not so interesting in case of manual commission with fixed value and the result is returned to the commission calculation table and shown in tab / register "price/commission".

Figure 41: Create manual commission - register "price/commission"

Function "commission calculation"

Functional Requirements

The commission calculation happens mainly in the formula builder. Here we define for each calculation scheme the corresponding calculation logic, which is assigned to a commission type.
The calculation is called in the background at each time we create a commission or when we change the values of the commission.
The main result of calculation is the total commission vale, which then is always divided to the actual assigned and active participant based on their percentage / fix value. The distributed values are stored for each relevant partner in the commission calculation table.

For more information, please see corresponding description in chapter "Maintain Predefined Condition Text Entries"

Usage

Definition of predefined text entries for a single manual price condition within the DBM|E commission.

  • T-Code: /DBME/PMA_ACNDR

Maintenance screen:

Figure 42 Maintenance view for predefined condition text entries

  • If here for a manual price condition no entry exist, the text in the condition is open for free text entry.
  • If here for a manual price condition only one entry exist, this text entry automatically is set for the condition in the commission.
  • If here for a manual price condition several entries exist, the user must choose one of this text entries from provided list. Only these entries are allowed.

To enter translation for the text entries, choose "Goto"  translation".

Authority check

  • No DBM|E specific authority check


Maintain calculation logic (formula builder)

Application "commission maintenance report" - ALV

Functional Requirements

Entry to the main application of DBM|E commission management to manage the created commissions.
At the selection screen, the user defines the criteria to reduce the shown commissions, that are relevant for the actual processing case. As result all corresponding commissions are shown with the main / defined information in a single ALV screen. To get more detailed information, a single line can be selected by single click and the commission detail screen appear. In addition, there are several functions available to handle the commissions.
In this chapter, the main selection screen and the ALV screen incl. the available functions are described.

  • T-Code: /DBME/PMA_PROV


Selection screen:
To get a better usability, the standard DBM|E selection screen is divided into two separate register.

In the first register, called "Main selection", you can define the selection criteria for:

  • Main commission data at header level
  • Commission status data at header level
  • Commission partner data at participant level
  • Commission vehicle data at header level

And at the second register, called "admin. data", you can define the selection criteria for:

  • Commission creation and last change data at header level)
  • Some addition commission parametersat header level)

Figure 43: Commission maintenance report - selection screen areas
Optional, the customer has here the possibility to enhance the selection screen / selection logic by additional fields. To get more details about this enhancement possibilities, please see chapter with BAdI enhancements.
Selection type:
In addition to the standard report variants, the customer can define own "selection types" within the DBM|E commission report solution.

Figure 44: Commission maintenance report - selection type
One idea behind these selection types, is partially like the report variants. In both cases, some fields of the selection screen could be "pre-filled" with default values.
But the main advantage of such a selection type is, that they can handle more complex "filling logics". The reason is, that they are handled by corresponding BAdI coding. In addition, also some more settings, e.g. layout of result ALV list, … can be set by BAdI enhancement based on the selection type. To get more details about this enhancement possibilities, please see chapter with BAdI enhancements.
But no advantage, without any disadvantage - comparing variants, the selection types must be defined by IT department (incl. development) and not easily from user, by saving the actual settings like it is for variants.
ALV screen:
As result, the user gets a normal ALV list reporting with all corresponding commissions.
Figure 45: Commission maintenance report - ALV screen
For each commission, the main information on header level is shown in one single line. If relevant, the customer can add own / additional fields. To get more details about this enhancement possibilities, please see chapter with BAdI enhancements.
The title of the list, is a concatenation of report name, the chosen selection type value and the number of selected commissions.

Available functions:

Next to the SAP standard ALV functions , like sort, filter, sum, print, … and the general report standard functions like cancel, back, …, the DBM|E commission report provides the following additional functionalities:
Function "refresh" (icon in push button line / in menu "commissions")
Refresh the shown data based on the selection criteria entered, when starting the report. So, commissions can disappear, in case, they have been changed in the meantime, but also some new commissions can be added to the list, because they now fit to the selection criteria.
Function "create manual commission"(icon in push button line / in menu "commissions")
Calls the screen to create a new commission manually. To get more details, please see chapter with "creating manual commission".
Function "status mass change" (push button in ALV icon line)
Mark all rows in the ALV, where the status should be changed and press button "set status".
A popup with all for the selected commission possible status values appears.

Figure 46: Commission maintenance report - ALV mass status change
Note: The popup shows the collection of all possible status values for the marked commissions. To get the list, for each single commission the possible status settings are determined based on the actual status and collect them into the list. So, for some commissions the combinations of actual status and in the popup provided status could be impossible. But the system cehcks this during processing and shows a corresponding message in the update protocol.
Select a status by single click at the status line and if relevant, enter an additional comment.
Note: Comments are added to each single commission status change, which is successful processed.

Figure 47: Commission maintenance report - ALV mass status change log
After status mass change the ALV automatically process the refresh function.
Note: The following commission flags (set by business operations) do not longer allow a status change:

  • Deleted
  • Canceled
  • Posted into HR



Function "change"/ "display" (entry in menu "commissions")
In case a single line of the ALV list is marked, these functions call the commission detail screen in change mode / in display mode. In case no line / several lines are marked, an error message appears.
Function "delete" (entry in menu "commissions")
Mark all rows in the ALV, which should be relevant to delete and select function "delete" in the menu.

Figure 48: Commission maintenance report - ALV mass deletion
Now system show security message, which is to confirm.

Figure 49: Commission maintenance report - ALV mass deletion popup
In case security question is confirmed with "yes", the business operation "DELE" is processed.

  • Commission status is changed to the corresponding status (based on status settings for DELE)
  • The flag "deleted" is set in commission header
  • When flag deleted is set in commission header, corresponding icon is shown in ALV list
  • Show processing protocol


Figure 50: Commission maintenance report - ALV mass deletion log
After mass deletion, the ALV automatically processes the refresh function.
Function "recalculate" (entry in menu "edit")
Mark all rows in the ALV, which should be recalculated and select function "recalculate" in the menu.
In case the user has the corresponding authority the recalculation for the selected commissions will be processed.
As result the processing protocol is shown.

Figure 51: Commission maintenance report - ALV mass recalculation log
"Hyper Links" (direct in ALV list)
In the ALV list, some fields have a special function. …

  • Commission number
    • Call the commission detail screen for the corresponding commission.


  • Reference document (invoice number)
    • Call the corresponding invoice in display mode (T-code VF03).
  • Long text icon
    • Just appear, in case there is a long text created for the corresponding commission.
    • Shows for the corresponding commission a popup with the actual long text in display mode. Details about how to edit a long text / the general text logic see in commission detail functions.


Application "commission maintenance report" - detail

Functional Requirements

Detail commission maintenance screen in DBM|E commission management
At the selection screen of commission report, the user defines the criteria to reduce the shown commissions, that are relevant for the actual processing case. As result all corresponding commissions are shown with the main / defined information in a single ALV screen. To get more detailed information, a single line can be selected by single click and the commission detail screen appear.
Alternative, a direct access (without commission report) is possible by commission change / display transactions.
In addition, there are several functions available to handle the commissions (independent how detail screen is started).
In this chapter, the detail maintenance screen incl. the available functions will be described.

  • T-Code: /DBME/PMA_PROV (by click at single commission) /DBME/PMA_PROV02 Change commission /DBME/PMA_PROV03 Display commission

Detail screen
In DBM|E standard the detail screen shows general header data (org. data and status information), main vehicle (only with VSS 2.0 package) and customer data and in the different tabs, the calculation result, the conditions, the participants, the status history and some administrational data.

Figure 52: Commission maintenance report - commission detail
Note: Because the customer requirements are very different (could be case depending, but also including own customer fields) and the complete screen is based on DBM|EGUI Framework and the complete content in tab "price/commission" is based on DBM|EHTML Framework, the final customer solution can look different. To get more details about "screen replacement" see the corresponding chapters of settings (to assign own screens) and also of BAdI enhancements (to handle data of own screens).
If the auto. recalculation for the actual commission type is active and the status of the commission allows changes, the commission calculation will be processed in background during calling the detail screen.

Available functions:

In addition to the here described detail functionalities, there are also some of the ALV functions (described in chapter before) are available (in case ALV list is toggled on).

Figure 53: Commission maintenance report - ALV function in detail view
E.g. it is also in detail screen mode possible to mark several commissions and process mass status update function.
Function "display / change" (icon in push button line / in menu "commissions")
Change the processing mode of the commission detail between "change" and "display", depending on the actual mode.
Note: In case you are in the change mode and select any commission in ALV list via click, it is possible, that you get an error message "operation not allowed" and commission is opened in display mode. The reason here is, that the actual status (status itself, cancellation flag, deletion flag, …) of the selected commission will not allow any changes and so it could not be opened in change mode.
Function "check object" (icon in push button line / in menu "commissions")
Process a complete check of the actual commission in detail screen. It checks the data concerning completeness, but also concerning data consistence.
In each case, an information message appears in the status line, e.g. like:



Figure 54: Commission maintenance report - function "check object" messages
Function "other commission" (icon in push button line / in menu "commissions")
Calls a popup, where user can enter the number of any existing commission. In case the activity is coming out of commission report, the entered commission must not be part of the actual selection / ALV list.

Figure 55: Commission maintenance report - function "other commision" popup
As result the entered commission data is shown in the detail screen.
In case the entered commission number does not exist, a corresponding message appear in the status line.E.g.
Function "toggle list on/off" (icon in push button line / in menu "extras")
With the toggle function, the user can switch off / switch on the shown part of ALV list.

Figure 56: Commission maintenance report - function "toggle list on/off"
The function is only available in commission report processing.
Function "save" (icon in push button line / in menu "commission")
Save actual commission data. Function is only in change mode useful.
Function "close" (icon in push button line / in menu "goto")
Close the commission detail screen and return to the full size ALV screen.
Function "exit" (icon in push button line / in menu "commission")
Close the commission detail screen and return to the commission report selection screen.
Function "close" (icon in push button line / in menu "edit")
Close the commission detail screen and return to the full size ALV screen.
Function "delete" (in menu "commission")
Sign the current commission as deleted. This function calls the business operation "DELE", which set the flag "delete" and also set the commission status based on the assignment from settings (business operation / status).
Function "header long text" (icon at screen "Header data" / in menu "edit")
The function opens a popup, where the user can add / change additional text information (object SAP long text) for a specific commission. The function is also available in case of display mode, but then the text in the popup is not editable.

Figure 57: Commission maintenance report - function "header long text" popup
To ensure that text information is shown also in multi-language countries (e.g. Swiss with DE, FR and IT), the long text information for a commission is always stored in one language. As base for the language, we define the language assigned to the plant from commission.
The long text is sored with following parameters:

  • Object: /DBME/P_PR
  • ID: 0001 (header long text)
  • Language: assigned language from plant
  • Name: commission number


Function "redetermine" (in menu "edit")
The redetermination function is a kind of "refresh commission master data". Here the user has the possibility to update commission relevant data based on the actual settings / master data. E.g. this could be relevant, if master data during commission creation was wrong - so user can correct the master data and update commission with the corrected master data version.
The function shows a popup, where several redetermination levels are selectable:

  • Commission header data  read the main commission header information from invoice, VSS order and the vehicle, like it is done during commission creation
  • Commission participant / pool data  read the actual partner and pool information for the main commission partner  there is additional option, to decide if manual created participants in the commission should be hold or should be deleted
  • Commission condition data  option, to decide if manual created conditions (normally all conditions) in the commission should be hold or should be deleted
  • Additional set commission status  additional option to set status immediately during redetermination; also, here status can be set only to allowed status values


Figure 58: Commission maintenance report - function "redetermine" popup
This function is only for active (not deleted, not cancelled and not already transferred commission) possible.
This function is only in change mode available.
Function "change status" (icon at screen "Header data" / in menu "edit")
Set the actual commission status to a new status. Here the status can be set only to values, which are allowed concerning the status settings – just this values are provided in the popup. In addition, it is possible to enter a comment / info text for the status change.

Figure 59: Commission maintenance report - function "status change" popup
After status change it is necessary to save the commission, before the next status change could be done. If the commission is not saved, the last status change / comment is the relevant change, which is stored in the history. All other changes between will be lost.
The history of all status changes, including their text comments, will be shown in the tab "history".

Figure 60: Commission maintenance report - function "status change" in register "history"
Here also a corresponding icon shows, if for the single status change, there is a comment available or not.
The status change text is stored as long text with following parameters:

  • Object: /DBME/P_PR
  • ID: 0005 (status change text)
  • Language: assigned language from plant
  • Name: commission number + status sequence number + status number

Function "show vehicle" (icon at screen "Vehicle")
Call the vehicle master application of the corresponding vehicle within the commission.
Function "change condition values" (icon & lines in tab "Conditions")
This functionality is at the end, a set of functions to create manual conditions, change these condition entries and also delete them again from commission.

Figure 61: Commission maintenance report - function "change condition values" icon
By adding a new condition (icon above ALV), there appears a new line in the ALV and user must choose one of the available price conditions (defined by commission type settings).

Figure 62: Commission maintenance report - function "change condition values" popup
Note: Same conditions could be added several times and each of them are included in the commission value calculation. But there could be also some, where it is technical possible to add them several times, but to do, is somehow "free of space", e.g. fix value condition. In general, this depends not from technical condition type, but from customer individual definition of condition meaning and calculation logic.
Note: Depending on the maintained master data for condition text entries, the comment text for a single entry is free changeable text (no text entry for condition), automatically filled text (only one text entry for condition) or must be chosen by available list (several text entries for condition).
The condition entry itself, is stored in the own table /DBME/PMA_APCND (not in "standard" price condition table).
As far as the commission allows changes, also the condition entries could be changed directly in the conditions ALV.
To delete an existing condition, mark the corresponding line in conditions ALV and press the icon .
Function "change partner values" (icon & lines in tab "Participants")
This functionality is at the end, a set of functions to add manual additional commission partner, change these entries and also delete them again from commission.

Figure 63: Commission maintenance report - function "change partner values" icon
By adding a new partner (icon above ALV), there appear a new line in the ALV and user must enter:  One of the available partner roles (defined by commission type settings).

Figure 64: Commission maintenance report - function "change partner values" popup
Note: Based on the settings, some partner roles are shown in selection, but because they are defined as unique in the settings, an error message appears. For main partner role of the commission, the unique flag must be active in the settings.
Note: Based on the settings, some partner roles are defined as not manual changeable. So, manual adding of such partner roles makes no sense (also if they are offered in the selection), because for such an entry no values can be entered. For main partner role of the commission, the unique flag must be active in the settings.
Note: Irrespective of the settings, the main partner role and pool partner role are defined in commission header and have a special logic. So, it never makes sense to add one of them manually.
 In addition to the partner role, also the person (HR number) must be entered.
Figure 65: Commission maintenance report - function "change partner values" HR number search
Note: Each combination of partner role and person (HR number) is allowed only once for a commission.
Note: In the DBM|E standard, there is normal HR search help behind the partner ID field. So, each PERNR within the system can be found / added. If customer does not like this behavior and e.g. will provide here only employees, which are defined in the "commission relevant employee" table for the corresponding plant, the search help has to be extended by search help exit. The Criteria here could be e.g. the transaction code in SYST (to determine, where the request is coming from (standard or commission)) and in example above the data from commission relevant employee. In such a case, there should be in addition a BAdI implementation, checking partner ID's during commission saving process, to avoid wrong manual entries (without search help).
 And finally, the corresponding value for this partner, to define which part he should get from total commission value. Here the user can enter a percentage or an absolute value and also mark the entry as commission relevant or not.

Figure 66: Commission maintenance report - function "change partner values" register "participants"
Note: In case percentage and absolute value are entered, the absolute value has priority and percentage will be cleared (= 0).
Note: The total sum of all entered percentage values could not be bigger than 100%, otherwise an error message appears.
Note: The total sum of all absolute values cannot not be bigger than the total commission value, otherwise an error message appears.
Note: Values from manual partner entries has priority and reduce the values from automatic determined partner entries. In general, automatic determined partner entries (main partner / pool partner) are always calculated as percentage (based on master data definition) and their percentage values are always recalculated by change of manual partner entries.Calculation logic for the automatic determined partner roles:

  • Base is the total commission value calculated in formula builder and by the price conditions.E.g. 2000 EUR
  • Reduce total commission value by the sum of absolute value from all manual partner entries.E.g. 2000 EUR – 500 EUR = 1500 EUR
  • Recalculate percentage of the automatic determined partner roles.
    • Reduce 100% by the sum of percentage value from all manual partner entries.E.g. 100% - 20% = 80%
    • Split rest of percentage based on the master data definition (which commission hold always in the background, e.g. main partner =60%, pool partner = 40%)E.g. main partner 60% of 80% = 48%; pool partner 40% of 80% = 32%
    • Split rest of commission value by the new determined percentage values to the single partner entries.E.g. main partner 48% of 1500 EUR = 720 EUR, pool partner 32% of 1500 EUR = 480 EUR and manual partner 20% of 1500 EUR = 300 EUR


Figure 67: Commission maintenance report - function "change partner values" calculation example
Note: Clearing the flag "calculation relevant" sets the corresponding partner entry inactive for the calculation and the values are recalculated without these entries.

Figure 68: Commission maintenance report - function "change partner values" flag calculation relevant
 And in addition, it is optional possible to add a comment for each changeable entry, e.g. why this person should get a part of this provision.
Figure 69: Commission maintenance report - function "change partner values" comment lines
As far as the partner role allows changes, also the person and the value entries could be changed directly in the partner ALV.
To delete an existing partner entry, mark the corresponding line in partner ALV and press the icon . Automatic determined partner entries (main partner / pool partner) cannot be deleted, here only the flag "calculation relevant" can be cleared and so commission value is set to zero.
Several Hyperlinks
In the detail screen, some fields have a special function (by double click).

  • SD document (invoice number) (in "header data")
    • Call the corresponding invoice in display mode (T-code VF03).
  • Sales document (invoice number) (in tab "administration")
    • Call the corresponding invoice in display mode (T-code VF03).
  • Reference document (VSS order number) (in tab "administration")
    • Call the corresponding VSS order in display mode (T-code /DBE/ORDER03).
  • Canceled commission number (in tab "administration" / just for cancelation com.)
    • Call the corresponding commission in display mode (in actual detail screen).


Report "mass redetermination"

Functional Requirements

With the report for mass redetermination it is possible to "refresh commission master data" for a specific selection of active commissions (not deleted, not canceled and not already transferred). Here the user has the possibility to update commission relevant data based on the actual settings / master data. E.g. this could be relevant, if master data during commission creation was wrong - so that the user can correct the master data and update the commission with the corrected master data version.

  • T-Code:/DBME/PMA_REDET


  • Selection screen:The selection screen mainly contains two sections:  the options(what should be done)

Figure 70: Mass redetermination - selection screen settings

    • Show list  shows first a list of the selected commissions and the user can mark the relevant commissions and process the redetermination for them; otherwise redetermination runs without list and all selected commissions are updated
    • Save protocol  stores the processing protocol additional in the application log with object /DBME/PMA and subobject MASS_UPDATE and so it can be called also later on; otherwise protocol is just shown at the screen during runtime
    • Commission header data  read the main commission header information from invoice, VSS order and the vehicle, like it is done during commission creation and update commission
    • Commission participant / pool data  read the actual partner and pool information for the main commission partner and update commission  there is the additional option, to decide if manual created participants in the commission should be hold or should be deleted
    • Commission condition data  optional, to decide if manual created conditions (normally all conditions) in the commission should be hold or should be deleted

 the selection criteria (at which commissions it should be done)
Figure 71: Mass redetermination - selection screen criteria

  • ALV list

Figure 72: Mass redetermination - ALV list result
In addition to the standard ALV functions, here we have just one additional function "start mass update". Pressing this function, the "refreshing of master data" will be processed for all in the ALV selected commissions, based on the chosen options at selection screen.

  • Processing log during runtime

Figure 73: Mass redetermination - processing log
After each processing, the actual log is shown to inform about successful, not allowed and not successful updates.
Authority check

  • Authority object "/DBME/P_MS" for activity


Customer Enhancement

  • Yes, BAdI and enhancement points are available.
    • BAdI
      • /DBME/PMA_IF_E_PROV_SELECTION~SELECTION_EXECUTE
      • /DBME/PMA_IF_E_PROV_SELECTION~SELECTION_POSTPROCESS
    • Enhancement points
  • /DBME/PMA_MASS_UPDATE01
  • /DBME/PMA_MASS_UPDATE02
  • /DBME/PMA_MASS_UPDATE03


Customer example (part of delivery)

  • No, activities will be described in user manual


Proaxia example (internal test)

  • No specific setting


Report / interface "transfer to HR"

Functional Requirements

With the report for "HR transfer" it is possible to send the open commission values for each employee / commission combination to the target system, e.g. an HR system to process there the commission payments.
The report itself just collects all relevant commission value entries, which are relevant for transfer, fit to the selection criteria and not already transferred, and send each of them to the BAdI implementation.
Within the BAdI implementation, the customer has to develop / enhance his own transfer logic. Reason for this approach are the large variants of target solutions (SAP HR within the system, SAP HR in different system, non SAP HR, …).
Based on the return value of the BAdI, the report updates in addition the commission value entry and marks it as transferred.
Most likely this report is running frequently as batch job.

  • T-Code: SA38
  • Report: /DBME/PMA_MASS_POST
  • Selection screenThe selection screen mainly contains two sections:  the selection criteria (at which commissions it should be done)

Figure 74: Transfer to HR - selection screen criterial
 the posting options(what should be done)

Figure 75: Transfer to HR - selection screen settings

    • Posting date  with this date the posting will be done in target system
    • Ignore posting calendar  process report without check to the settings in the posting calendar; if flag is initial, the report checks posting calendar and process the single entries only in case the posting date is marked as transfer relevant; in case report is running frequently in a batch job, flag should be marked and posting calendar should be maintained
    • Test mode  select relevant commission values, but do not call BAdI / do not update commission values
    • Remarks  possibility to add a remark to the single postings to transfer this information to the target system
  • Processing log during runtime

Figure 76: Transfer to HR - processing log
After each processing, the actual log is shown to inform about successful, not allowed and not successful updates. Application log object /DBME/PMA and subobject MASS_POST.
Authority check

  • No specific authority object.


Customer Enhancement

  • Yes, BAdI and enhancement points are available.
    • BAdI
      • /DBME/PMA_IF_E_PROV_SELECTION~SELECTION_EXECUTE
      • /DBME/PMA_IF_E_PROV_CREATE~SD_DOCUMENT_DATA_READ
      • /DBME/PMA_IF_E_PROV_CREATE~DATA_PREPARE_CREATE
      • /DBME/PMA_IF_E_PROV_CREATE~ITEM_CREATE


Customer example (part of delivery)

  • No, activities will be described in user manual

Proaxia example (internal test)

  • No specific setting


Interface "maintenance in external frontend"

Functional Requirements

If the customer will not use the SAP GUI as frontend, e.g. because the salesman in general does not work in SAP and so they should handle / release their commissions via an UI5 frontend, the DBM|Estandard does not provide a final solution, just a tool set.
The main reason for this approach is based in the large number of possible solutions concerning interface (web service, proxy, ODATA, direct, via PI, via Gateway, …) and concerning frontend (own solution, UI5, Fiori, …).
But to support such a case, we provide several classesthe customer can use to read relevant commission data (outbound processing) and to handle the different commission parts (inbound processing).
























  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.