CX Works

CX Works brings the most relevant leading practices to you.
It is a single portal of curated, field-tested and SAP-verified expertise for SAP Customer Experience solutions

SAP Commissions - Seed Participant and Positions

20 min read

Overview

SAP Commissions - Seed Participant and Positions


During the validation of position and participant data imports many errors can occur due to the complex interdependencies that exist. Errors can include :-

  • Validation errors due to duplicate records in the same batch
  • Dependant Position effective dating mismatches
  • Missing Participant to Position association

Participant and Position import errors can effect a large portion of the organization structure, leading to multiple record failures or effective dating errors.

The aim of this document is to address the common validation and import issues and give methods to resolve them using Seed and Filler records. The concepts of Seed and Filler records are explained using examples taken from real data issues.


Table of Contents

Introduction

During the validation of position and participant data as part of the Commissions Data Loader (CDL), a number of errors can be raised. The validation errors can vary depending on the quality of the data extracts, the preprocessing that is done, and whether the position and participant data originate from the same source. Participant validation errors are usually confined to invalid unit types or duplicates due to multiple versions in the same batch. Position data, on the other hand, can be susceptible to a wider variety of errors and import issues because of the complex interdependencies that exist. Some common issues when validating and importing position data are:

  • Parent / Child effective dates mismatch

  • Ending a position

  • Batch name generation

  • Effective date range gaps

  • Manager does not exist

If a position fails validation then its children may also fail, and their grandchildren also failing, etc… If a position node high in the hierarchy fails validation then a large portion of the organization structure may not load.

Key Assumptions

  • All examples are for a standard monthly calendar

  • The stage position effective end date is only populated when a position truly ends

Advantages

  • Organization data can be imported even when the data isn’t 100% accurate

  • Number of batches required for Position load is reduced which results in faster import times

  • Makes ending of a position possible

  • Validation errors will not cascade to child positions

Disadvantages

  • Results in more Position and Participant records

Seed Positions

We could be in a situation where we are attempting to import the following position records:

Batch Name

Position Name

Payee ID

Effective Start Date

Effective End Date

Manager Name

Title Name

B1

POS_MANAGER

Rod

15/03/2020



TEST_TITLE

B2

POS_REP

Jane

01/03/2020


POS_MANAGER

TEST_TITLE

Note

These records are created in seperate file batches and are loaded sequencially, i.e. batch B1 is loaded first, then B2 etc. Attempting to load positions in a Parent / Child relationship in the same batch will cause an error as the parent record will not exist to associate with the child.

e.g. in the above example attempting to load position POS_REP when the manager POS_MANAGER has not been created first will fail validation.


If both positions were in the same batch then the following message would occur:

Field

Message

Error Code

70413

Severity

Error

Description

The imported Position POS_REP has an invalid Manager name


The first batch will import, but the record in the second batch will fail because POS_REP reports to POS_MANAGER from the 1st of March 2020, but POS_MANAGER does not exist until the 15th of March 2020.

The error message is :

Field

Message

Error Code

70418

Severity

Error

Description

Effective Dates of Manager assigned to imported Position, POS_REP, do not match


The failure of these records to import could have a cascade effect on many other position records within the hierarchy, creating multiple import errors. To fix this issue you can create a Seed Position .

A Seed Position is simply an ‘empty’ (not assigned to a payee and has a title that does not result in a plan) version of the position effective from the system’s start of time (earliest calendar period). The Seed Position will be imported before the other records and should only be created if this is the first time the position is loaded.

For the example above the stage records would now look like the following:

Batch Name

Position Name

Payee ID

Effective Start Date

Effective End Date

Manager Name

Title Name

B0_SEEDS

POS_MANAGER


01/01/2018


SEEDS

UNASSIGNED

B0_SEEDS

POS_REP


01/01/2018


SEEDS

UNASSIGNED

B1

POS_MANAGER

Rod

15/03/2020



TEST_TITLE

B1

POS_REP

Jane

01/03/2020


POS_MANAGER

TEST_TITLE


Note

  • As a by-product of importing the Seed Positions first, we can put both POS_MANAGER and POS_REP into the same batch. For larger and more complex position hierarchies the loading of Seed Positions can reduce the overall number of batches significantly.

  • We have created a node in the hierarchy called SEEDS where all the seed positions will sit under. This is to avoid confusing the generated records with the genuine ones. A title of UNASSIGNED that is not assigned to a plan has also been created.

  • We ensure that the Payee field is blanked out on the Seed Position. This is to ensure that the record will not trigger any compensation rules in the periods it is present.


After Validation and Transfer the records in SAP Commissions (excluding those with remove dates) will look like the following:

Position Name

Payee ID

Effective Start Date

Effective End Date

Manager Name

Title Name

POS_MANAGER


01/01/2018

15/03/2008

SEEDS

UNASSIGNED

POS_MANAGER

Rod

15/03/2020

01/01/2200

<ROOT>

TEST_TITLE

POS_REP


01/01/2018

01/03/2020

SEEDS

UNASSIGNED

POS_REP

Jane

01/03/2020

01/01/2200

POS_MANAGER

TEST_TITLE


Filler Positions

If positions are loaded with an effective end date of the system End-Of-Time (i.e. 1st January 2200), it is no longer possible to have an effective end date before this date. Attempting to re-load this position with an end date before the End-of-Time will create a new version of the record where the start date of the last record will be the end date of the prior record.

For example, our stage position records including seed records are below. This assumes the stage position effective end date is only populated when a position truly ends. All other records have null or End Of Time effective end dates.


Batch Name

Position Name

Payee ID

Effective Start Date

Effective End Date

Manager Name

Title Name

B0_SEEDS

POS_AGENT


01/01/2018


SEEDS

UNASSIGNED

B1

POS_AGENT

Freddy

22/04/2020


POS_MANAGER

TEST_TITLE

B2

POS_AGENT

Freddy

18/05/2020

04/07/2020

POS_MANAGER

TEST_TITLE


The data above will result in the following records:

Position Name

Payee ID

Effective Start Date

Effective End Date

Manager Name

Title Name

POS_AGENT


01/01/2018

22/04/2020

SEEDS

UNASSIGNED

POS_AGENT

Freddy

22/04/2020

18/05/2020

POS_MANAGER

TEST_TITLE

POS_AGENT

Freddy

18/05/2020

04/07/2020

POS_MANAGER

TEST_TITLE

POS_AGENT

Freddy

04/07/2020

01/01/2200

POS_MANAGER

TEST_TITLE


We still have records effective to the end of time and therefore the position will attempt to evaluate compensation rules indefinitely. This is because the import process for batch B2 splits the version loaded in batch B1 into two versions.

For most clients it is necessary to calculate the incentive for the month in which the payee left the particular position. To ensure that measurements, incentives, and deposit rules fire we must have a version of the position valid up to the end of the leaving month. We also do not want any processing to occur for this position for any periods after the leaving month.

To achieve this we can do the following:

  • Create a position version that is effective from the last known effective end date to the 1st of the following month - this will ensure that the position will calculate correctly for its final month.

  • Create another position version that is effective from the 1st of the following month to the end of time with null payee ID and title unassigned to a plan. This is the same process as the seed position creation.


If we generate the filler positions the stage data will look like the following:

Batch Name

Position Name

Payee ID

Effective Start Date

Effective End Date

Manager Name

Title Name

B1

POS_AGENT

Freddy

22/04/2020


POS_MANAGER

TEST_TITLE

B2

POS_AGENT

Freddy

18/05/2020

04/07/2020

POS_MANAGER

TEST_TITLE

B2_FILL_0

POS_AGENT

Freddy

04/07/2020

01/08/2020

POS_MANAGER

TEST_TITLE

B2_FILL_1

POS_AGENT


01/08/2020


SEEDS

UNASSIGNED

Note

  • The empty filler position (B2_FILL_1) is a mirror of the seed position with respects to the title and manager name. Depending on the circumstances this may not be appropriate.

  • The seed position hasn’t been generated because it was created and imported during the previous load.

  • We append text to the batch name so that the filler records are always loaded after the batch that has the end dates. This is because there could be a later batch where the position starts again and we have to make sure we do not overwrite those versions by importing all filler records at the end.


This will result in the following records :-

Position Name

Payee ID

Effective Start Date

Effective End Date

Manager Name

Title Name

POS_AGENT


01/01/2018

22/04/2020

SEEDS

UNASSIGNED

POS_AGENT

Freddy

22/04/2020

18/05/2020

POS_MANAGER

TEST_TITLE

POS_AGENT

Freddy

18/05/2020

04/07/2020

POS_MANAGER

TEST_TITLE

POS_AGENT

Freddy

04/07/2020

01/08/2020

POS_MANAGER

TEST_TITLE

POS_AGENT


01/08/2020

01/01/2200

SEEDS

UNASSIGNED

Now the position will no longer evaluate from 01/08/2020 onwards and so the position has been truly ended.



Note

It is possible to end date positions with existing Effective End Dates of End Of Time via the Position Upload facility in the SAP Commission UI. This is achieved by using the Upload End-dated Positions file option as shown below



Loading positions in this method deletes any version of the Positions after the upload End Date. This is irreversible.


Seed Participants

If you attempt to import a position that is effective before its corresponding participant, validation errors will be raised. To work around this data issue seed participants can be generated.

For example here are the stage participant and stage position records:

Participant:

Batch Name

Payee ID

First Name

Last Name

Effective Start Date

Effective End Date

B1

Geoffrey

Geoffrey

Hayes

01/02/2020



Position:

Batch Name

Position Name

Payee ID

Effective Start Date

Effective End Date

Manager Name

Title Name

B0_SEEDS

POS_CEO


01/01/2018


SEEDS

UNASSIGNED

B1

POS_CEO

Geoffrey

01/01/2018


<ROOT>

TEST_TITLE


We are able to import the participant record and the seed position, but when attempting to import the position batch B1 we get the following error:


Field

Message

Error Code

70414

Severity

Error

Description

Effective Dates of Participant assigned to imported Position, POS_CEO, do not match


We can avoid this issue by creating a seed participant. A seed participant is simpler than a seed position such that it is just an exact copy of the participant from the beginning of time to the End Of Time with all non-essential fields set to null.


The stage participant records are now:

Batch Name

Payee ID

First Name

Last Name

Effective Start Date

Effective End Date

B0_SEEDS

Geoffrey

Geoffrey

Hayes

01/01/2018


B1

Geoffrey

Geoffrey

Hayes

01/02/2018


With the Seed Participant we can import the position records successfully.


Additional Notes

  • For Seed, Filler, and End Positions it is a good idea to use one of the generic Boolean fields to indicate that the integration process has generated them.

  • Batch Name Generation - using the techniques above batch names for positions and participants are simplified. During the load of the stage tables you must ensure that each version of a position is in a separate batch. Failure to do so will result in the following error

Field

Message

Error Code

70421

Severity

Error

Description

The imported Position POS_CEO appears more than once in the import stage table in this batch


  • A similar error for participants can also occur.

  • If a stage position record has an invalid manager (i.e. one that does not exist) you could consider updating the manager name field with a default value. It is best to have a node in the hierarchy to use as the default rather than assigning to the root position so that they can be easily identified.

  • Filler participants can be created for when a participant truly ends, however a participant alone cannot generate incentive calculations without a position so this is not deemed essential. The creation of the Seed Participant ensures that the participant will exist for all of time and therefore avoid any payee/position effective date mismatch.

  • It is recommended to archive / truncate the contents of the stage position and participant tables for performance reasons.



Integration Disclaimer

The scenario described in this article was built using SAP Commissions release 2012.

SAP Help Portal Disclaimer

This article does extend the existing documentation by providing some examples and use cases, but it does not replace the corresponding section of the official SAP Help Portal for SAP Commissions



Conclusion

Seed and Filler aid the import of position and participant data and can reduce the number of distinct batches that need to be imported. Reducing the possibility of validation and import errors prevents lengthy interruptions to batch processing which can result in payroll delays.

Overlay