v4ia and v4pac 1709: release notes - vistex, inc · previously, vistex generated sap financial...

Vistex, Inc. of 2 Last Modified: 7/25/2018

Area Sub-Area Type of Change Transaction Code Topic Changes

AgreementsCondition Contract Management

New FunctionalitySPRO/IRM/IPSPRO

Condition Contract Management

Previously, the Vistex Agreement created an SAP Sales Deal and stored the rules data entered in the agreement. However, in Release V4 1709, the sales deal functionality will not be used for creating agreements. Going forward, a condition contract will be created instead to store the Vistex Agreement information. The condition contract configuration is similar to the configuration of a sales deal. Outside of the creation of a condition contract number, instead of a sales deal number, at the time of agreement creation, no other changes have been made to the Vistex Agreement functionality.

For more information, go to the Condition Contract Management and New Engines supporting document.

Agreements Output Engine New Functionality /IRM/IPSPRO Output (Version 2.0)

Historically Vistex used the SAP output procedures and output types to trigger Idocs and print output. Going forward in V4 1709, the output control can be maintained in Vistex. The system still uses the output type from SAP in the output determination. However, in the output control, the applications, such as, billback, chargeback, deals, or claims, must be selected and the sales or purchasing output control is to be maintained as needed.


AgreementsPartner Determination Engine

New Functionality /IRM/IPSPROPartner Determination (Version 2.0)

Previously, for the partner determination functionality, Vistex used the SAP architecture for partner procedures and partner functions. Going forward in V4 1709, a new partner engine will be used and partner procedures can be created in Vistex. However, Vistex still uses the partner functions from SAP. There are no changes to assignment of partner procedure to agreements types, claims types, or transaction register types.


Agreements Text Engine New Functionality /IRM/IPSPRO Texts (Version 2.0)

A new text engine is available in V4 1709. The text determination configuration for text IDs and text procedures can be maintained in Vistex instead of SAP. Once the text procedure is created, it can be assigned to the agreement type. The rest of the text functionality at the application level remains the same.


CompositeContract Settlement

New FunctionalitySPRO/IRM/IPSPRO

Condition Contract Settlement

Previously, Vistex generated SAP financial documents. However, as V4 1709, Vistex will no longer create SAP financial documents. Instead, the system uses the condition contract settlement integration to create postings.

For more information, go to the 1709_Rls Notes Composites and Contract Settlement supporting document.

V4IA and V4PAC 1709: Release Notes

Vistex, Inc. of 2 Last Modified: 7/25/2018

Area Sub-Area Type of Change Transaction Code Topic ChangesV4IA and V4PAC 1709: Release Notes

Composite Pricing Lookups Change to Functionality /IRM/IPSPRONew Pricing Lookups in Composite

The previous lookups completely relied on Access Sequences. The user needed to pass condition type and access sequence. Now, with new calculation engine, calculation path can also be used instead of the access sequence. For the new lookups, there are two options:1. Passing condition type and condition table.2. Passing condition type and calculation path.

For more information, go to the 1709_Rls Notes Composites and Contract Settlement supporting document.

IPCalculation Buckets

New Functionality

/IRM/IPSPRO/IRM/IPCLBCM/IRM/IPCLBM/IRM/IPCLBUSPM/IRM/IPXX CLBSMP /IRM/IPCLBPMP/IRM/IPTTM

Calculation Buckets

The Calculation Bucket functionality has been introduced for release V4 1709 and is designed to store the source document information in the calculation bucket workbench. Previously, IP documents were used to perform calculations and stores the source document information, but, now, the IP documents will be replaced with calculation buckets. In addition, the calculation buckets will be used to store the source document information. These buckets use the calculation procedure and stores the net data to the calculation bucket workbench.

For more information, go to the Calculation Buckets supporting document.

IPCalculation Buckets

New Functionality /IRM/IPSPRO Calculation Engine

The New Calculation engine is designed for release V4 1709. This calculation engine replaces the SAP pricing procedure. As a part of this release, this calculation engine will be used for all the calculations. It uses the calculation path and calculation procedure, replacing the SAP access sequence and pricing procedure. This calculation engine will be used in Buckets, Condition search profile, Claims, Transaction, Catalog, Price simulation and Price books.

For more information, go to the Calculation Engine supporting document.

Matrix Matrix Fiori Change to Functionality N/A Matrix Fiori Grid Changes

Several changes to the layout of the Fiori planning grid application have been made as part of Release V4 1709. These changes include changes to the row visibility, search functionality, procedures, variables, alerts, among others.

For more information, go to the 1709_Matrix Fiori Grid supporting document.

Matrix Proforma New Functionality /IRM/IPMXMPM Mapping Profile

In Release V4 1709, a new workbench called “Mapping Profile” is introduced to replace the existing proforma profile configuration. This helps the user to fetch data from different sources like agreement/request, calculation run, price simulation, price records, planning document and pricing document.

Previously, the user needed to maintain the proforma profile in /IRM/IPSPRO, now from this release onwards, the Mapping Profile workbench is available for creation and modification. So now the user can create a mapping profile by using the /IRM/IPMXMPM transaction code.

For more information, go to the 1709_Mapping Profile supporting document.

Release V4 1709 – Composite Lookups & Condition Contract Settlement

New Pricing Lookups in Composite The previous lookups completely relied on Access Sequences. The user needed to pass condition type and access sequence. Now, with new calculation engine, calculation path can also be used instead of the access sequence. For the new lookups, there are two options:

1. Passing condition type and condition table. 2. Passing condition type and calculation path.

Old Flow: KOMK_SET; KOMP_SET; LOOKUP_NEW

New Flow: HEADER_COMMUNICATION_SET; ITEM_COMMUNICATION_SET; DERIVE_RATE

After setting the communication data using header set and item set, the user can use any of the following functions based on the business requirements. Below is the list of new lookups with the related old pricing lookups.

Old Lookup New Lookup Method Description LOOKUP DERIVE_RATE Derive Rate LOOKUP_AMOUNT DERIVE_AMOUNT Derive Attribute LOOKUP_AND_CALCULATE DERIVE_VALUE Calculate Condition Value LOOKUP_BASE_QTY DERIVE_BASE_QTY Derive Base Quantity LOOKUP_BASE_VALUE DERIVE_BASE_VALUE Derive Base Value LOOKUP_TIER DERIVE_TIER Derive Tier LOOKUP_ANY DERIVE_ANY Derives Any Amount LOOKUP_NEXT_BASE_QTY DERIVE_NEXT_BASE_QTY Derive Next Scale Quantity LOOKUP_NEXT_BASE_VALUE DERIVE_NEXT_BASE_VALUE Derive Next Base Value LOOKUP_NEXT_RATE DERIVE_NEXT_RATE Derive Next Rate LOOKUP_NEXT_TIER DERIVE_NEXT_TIER Derive Next Tier LOOKUP_QUANTITY DERIVE_QUANTITY Derive Quantity LOOKUP ATTRIBUTE DERIVE_ATTRIBUTE Derive Attribute

Condition Contract Settlement Previously, Vistex generated SAP financial documents. However, as V4 1709, Vistex will no longer create SAP financial documents. Instead, the system uses the condition contract settlement integration to create postings.

Accruals:

1) The accrual method, condition contract settlement billing document type, settlement process type, and condition type are assigned at the accrual profile.


2) The document schema group and account types are assigned at the condition contract billing type. The configuration Path is: SPRO > SAP Customizing Implementation Guide >Logistics - General > Settlement Management > Settlement documents > Settlement document types > > All Document types

3) Settlement Document type is assigned at the Settlement Process Type

Configuration Path is: SPRO > SAP Customizing Implementation Guide >Logistics - General > Settlement Management > Settlement Process > Define Settlement Process types

4) The document schema group is created and assigned at the pricing procedure determination.

For Customer, the assignment is completed using the configuration path: Use the Transaction code VOK0. Click on Pricing Procedure > Proc. Determination For Vendor, the assignment is completed using the configuration path: IMG > Logistics General > Settlement Management > Basic Settings > Pricing > Specify Pricing procedure Determination > Pricing Procedure Determination for Supplier Billing Document

5) The accrual account key is assigned to the manual condition type in the accrual key section of the pricing procedure. For Customer, the assignment should be done in the configuration path: SPRO > IMG > Logistics General > Settlement Management > Basic Settings > Pricing > Sales SD > Define Pricing procedure ‘ZSRACR’ For Vendor, the assignment should be done in the configuration path: IMG > Logistics General > Settlement Management > Basic Settings > Pricing > Materials Management > Define Pricing procedure.

6) The account determination is configured with both P&L and Balance sheet G/L accounts for the account key used in the pricing procedure. To complete the assignment for Customers, use the configuration path: SPRO > IMG > Logistics General > Settlement Management > Basic Settings > Account Determination > Revenue account determination (SD) > Assign G/L Accounts

To complete the assignment for Vendors, use the configuration path: IMG > Logistics General > Settlement Management > Basic Settings > Account Determination > Material Management > Specify account key determination

Settlements:


1) The settlement method, condition contract settlement billing document type, settlement process type, and condition type are assigned at the Settlement profile.

2) The document schema group and account types are assigned at the condition contract billing type. The configuration path is: SPRO > SAP Customizing Implementation Guide >Logistics - General > Settlement Management >Settlement Documents > Settlement document types > All Document types

3) Settlement Document type is assigned at the Settlement Process Type Configuration Path is: SPRO > SAP Customizing Implementation Guide >Logistics - General > Settlement Management > Settlement Process > Define Settlement Process types

4) The document schema group is created and assigned at the pricing procedure determination.

For Customer, the assignment should be done using the configuration path: Use the Transaction code VOK0. Click on Pricing Procedure > Proc. Determination For Vendor, the assignment should be done using the configuration path: IMG > Logistics General > Settlement Management > Basic Settings > Pricing > Specify Pricing procedure Determination > Pricing Procedure Determination for Supplier Billing Document

5) The account key is assigned to the manual condition type in the account key section of the pricing procedure. For Customer, the assignment is completed in the configuration path: SPRO > IMG > Logistics General > Settlement Management > Basic Settings > Pricing > Sales SD > Define Pricing procedure ‘ZSRACR’ For Vendor, the assignment is completed in the configuration path: IMG > Logistics General > Settlement Management > Basic Settings > Pricing > Materials Management > Define Pricing procedure.

6) The account determination is configured with (Balance sheet) G/L accounts for the account key used in the pricing procedure. For Customer, the assignment is accomplished in the configuration path: SPRO > IMG > Logistics General > Settlement Management > Basic Settings > Account Determination > Revenue account determination (SD) > Assign G/L Accounts For Vendor, the assignment is accomplished in the configuration path: IMG > Logistics General > Settlement Management > Basic Settings > Account Determination > Material Management > Specify account key determination

Posting profile:


Claims and Transaction register documents can be posted (Accruals/Settlements) with posting profile functionality. The posting profile functions similar to accrual or settlement profiles. The mapping of conditions in the posting profile needs to be configured. This requires the mapping of the source condition types to target condition type used in the condition contract pricing procedure.

Contents Planning Grid in Fiori ..................................................................................................................................... 2

Grid Options .............................................................................................................................................. 2

Reduce paddings and heights for maximizing rows visibility ................................................................ 2

Quick Search ......................................................................................................................................... 3

Toggle Settings ...................................................................................................................................... 3

Procedures in Fiori ................................................................................................................................ 3

Variables.............................................................................................................................................. 11

Metrics Visibility .................................................................................................................................. 12

Activity Log .......................................................................................................................................... 12

Alerts ................................................................................................................................................... 12

Summaries in Planning Grid ................................................................................................................ 14

Filters ................................................................................................................................................... 15

Color Map............................................................................................................................................ 15

Screen View ......................................................................................................................................... 16

V4 1709 - Matrix Fiori Grid

Page 2 of 16

Planning Grid in Fiori

Grid Options Several changes to the layout of the Fiori planning grid application have been made as part of Release V4 1709.

Reduce paddings and heights for maximizing rows visibility In order to improve the user view, the Row Sizes can be increased. The size increase is due to the reduction in the padding size. The user can toggle between the layouts by selection the option button. For comparison, see the following screen shots. In the firs, the standard layout is displayed.

However, after clicking on the button, the row height is maximized, as seen below.


Page 3 of 16

Quick Search

The Quick Search enables the user to quickly filter the required criteria without any selections. The user can directly input the required characteristic or metric for which the filter has to be applied.

The user needs to enter the required input and hit enter. Then, the system automatically filters the inputted data and shows only the filter data.

Toggle Settings This option helps to toggle the side bar options in the grid page. If the user clicks on toggle settings button, the side bar is made available.

Procedures in Fiori All the available matrix functions, procedures, export, import, update rows, clone rows, copy rows, and add rows functionalities, among others, are included under the Procedures menu in Fiori grid.


Page 4 of 16

The following functions are the default functions provided within the Procedures menu in the Fiori application:

1. Update Rows 2. Update & Trim 3. Extend 4. Add rows 5. Import 6. Export

Update Rows This is a default function available in Procedures for all the Fiori applications. The user can update the row data using different criteria in the grid. The user has to click on the Update Rows functionality and select the required criteria on which the changes should be applied.

There are Different update criteria’s available to update the row data. They are

1. All rows - If this option is selected, the user can apply the required change on all rows. 2. From selection - This enables the user to apply the change on the selected row. 3. Using filters – The user can apply the changes on the desired rows using filer option. 4. Using Formula – The user can maintain required formula and apply the transformations as per

the maintained formula.

After selecting the rows criteria, the user needs to select the required metric on which the transformations should be applied. If necessary, the user can add multiple metrics depending on the destination criteria.


Page 5 of 16

Next, the user needs to set a value for the selected metrics, as shown in the below screenshots.

When the user clicks on Next button, the systems shows the Summary and Preview of the transformations which are going to be applied on the rows. The Preview option displays the rows affected.


Page 6 of 16

Meanwhile the summary option illustrates the affected data in the form of a summary, along with the criteria applied and destination transformations.

Upon executing the above changes, the transformations will be reflected on the grid data as per the maintained criteria. The affected rows as per the criteria will also be shown in the activity log along with the changes. As per the transformations the data will be reflected within the selected metrics.


Page 7 of 16

In addition, the user can select multiple criteria, then create or update the subsequent rows as desired.

Update & Trim The Update & Trim Rows option give the ability to the user to update or trim the rows within the data using a two-step process. Here the user needs to select the Update & Trim option and select the required source criteria as shown below.


Page 8 of 16

Now, after selecting source criteria, the user needs to select the destination criteria, indicating where the row should be copied.

Please note, as it is a two-step process, it is mandatory to select the destination criteria also, in order to copy the rows from the source criteria.

In destination criteria, the system will only show the characteristics selected in the source criteria. If needed, then the user can also select the destination transformations. Also, if required the user can also extend or trim the source data. Upon execution, one row will be copied, based on the maintained transformations. In addition, as per the criteria maintained, the data is reflected in the destination criteria along with the transformations applied.

If only the destination transformations are maintained then only the destination rows are updated. If both the source and destination transformations are maintained, then both source and destination rows gets updated as per the maintained criteria.

Extend The Extend Rows option is helpful in Extending one row data to the other. In this option, the user can extend the destination and source values by applying extending criteria. If required, the user can maintain additional destination criteria. On clicking next, the ability to select the source transformations is available to the user. Then when clicking execute, the row is copied into the destination and the source values will be updated as per the maintained criteria.

Add Rows The Add New Rows option enables the user to add new records with in the available combinations. The user needs to select the required criteria with in the available characteristics and metrics to create new records. To function properly, the user needs to select the row criteria and required transformations for


Page 9 of 16

the new records. The summary is shown and, after execution, the system reflects the maintained criteria data along with the newly added record.

Import from Excel The Import from Excel options allows the user to upload data into grid from the excel file. In this procedure the user is able to configure the imported columns and fields, as well as, map the required columns. In order to import data the user needs to choose a file. Then the user can import and map the required column. After execution, the data will be uploaded into the grid from excel as per the mapped columns and configurations.

Add Members As part of the Import from Excel functionality, the user can also import or add new members to the grid data. For this the user needs to flag the add members option in the import window as shown below.

The user must verify that the file which is to be uploaded should consist of new rows apart from the grid data. The new rows will be added from the excel sheet as shown in the below screenshot.


Page 10 of 16

Export to excel The user can download the grid data into an Excel spread sheet using this functionality. Here, the user can select the required export options or criteria before downloading to excel sheet.

The four types of Export criteria are:

1. All rows: All the rows will be exported. 2. From Selection: Only the selected rows will be exported. 3. Using Filters: The user can apply a desired filter and export only the filter rows. 4. Using Formula: The user can define a custom formula and export the sheet data into the excel

file.

Depending upon the export criteria, the user can download the required data. For Example, if the user selects all the rows then the data from all the rows will be downloaded into the excel sheet, as shown in below screenshots.

Then after clicking execute, an Excel file will be downloaded.


Page 11 of 16

Variables In Release V4 1709, the variables which are created should be marked as visible in the variables functionality in order to be viewed.

As shown below, the user needs to click on Eye symbol to enable the variables configurator button.


Page 12 of 16

Here, the user can make changes to the variable value in the Variables Configurator popup. The changes will be reflected, once the user selects the Apply Changes button.

Metrics Visibility

The visibility of metrics can be verified by using Metrics Visibility button. Within this menu, the

user also has an option to hide the visible metrics by selecting hide metrics visibility button.

Activity Log This functionality shows all the changes made by the user to the grid.

From this option, the user has two options, Load More or Save Logs. The Load More option allows the user to load additional activities when multiple activities are available. The Save Logs functionality provides the ability to save all available logs to a notepad file.

Alerts This functionality allows user to set an alert on grid data. When the user changes the grid data, the alerts configured by the user will be shown up as per the rules maintained in the alerts section of planning grid. In addition, the user can define the desired alerts as per specifications. In order to create


Page 13 of 16

an alert, the user needs to enter the alert message, define a rule on which the alert should apply, and the severity.

Alert Severity When creating the alert severity, the user has the following three options:

1. Info: An informational message is displayed when this is selected during the rule definition. 2. Warning: A Warning message is displayed by selecting this during the definition of a rule. 3. Error: An error message is displayed when the severity of Error is selected.

As per the alerts configured, if the grid data is changed then the alerts get validated within the grid data and the system shows the appropriate alerts based on the configuration by the user.

Validation Modes Within the alerts functionality, the user can add a validation mode. The user can choose between the following two mode options:

1. Auto: This indicates that the grid will automatically validate the alerts without clicking on Validate grid button.

2. Manual: When the manual option is selected, then the user needs to click on validate grid button in order to validate the grid data.

Validate Grid Button To enable the Validate Grid button, the validation mode must be set t Manual. This requires the user to click on the validate button in order to validate the grid data, based on the alerts maintained by the user.


Page 14 of 16

Summaries in Planning Grid The concept of new summaries in planning grid allows the users to create custom summaries with the desired list of fields. The summaries are saved for subsequent use when the grid is loaded for planning documents or proforma documents. However, for scenarios, the summaries created in the Fiori application will be available only for that session.

The user can create these summaries on the fly for the planning grid in the Fiori application. The user needs to maintain at least one characteristic and one metric for defining summary at planning grid level.


Page 15 of 16

Filters This feature enables the user to filter the grid data among the required characteristics and metrics. The user can add a new filter and reapply filters for the characteristics and metrics. The user can also remove all the applied filters from the planning grid. Filters can only be applied at runtime, but cannot be saved. In addition, each filter is layout specific.

Color Map The Color Map display types are used to represent the color maps. Earlier there was only one representation for color maps, Bar. However, in this current release, the color maps are extended with two more representation types, Font and Background. These can be configured in the color maps tab at matrix level and, if required, can be accessed or edited at Fiori application level also in Metrics management functionality.

Font As the name suggests, Font controls the color for the text of the cell. In the matrix level, if a color map has display type as Font, then the text of the cell will be colored with selection.

Background As this option suggests, the Background will determine the color of the entire cell. In the matrix level, if a color map has display type as Background, then the background of the cell will be colored with the selected color.


Page 16 of 16

Screen View A new button available in the layout of the grid is the Full Screen button. This button displays the grid using the Full screen view. This function is available for Planning grid, Status tab, and Snapshots.

To exit the full screen mode, the Exit Full Screen button is available. This helps the user return to the original display size.

Release V4 1709 – Calculation Buckets

Calculation Engine The New Calculation engine is designed for release V4 1709. This calculation engine replaces the SAP pricing procedure. As a part of this release, this calculation engine will be used for all the calculations. It uses the calculation path and calculation procedure, replacing the SAP access sequence and pricing procedure. This calculation engine will be used in Buckets, Condition search profile, Claims, Transaction, Catalog, Price simulation and Price books.

Configuration Path To utilize the new calculation engine, the configuration must be completed. This is done using the following menu path: /IRM/IPSPRO > Incentive and Payback Module > Basic Functions > Calculation Engine

The user has to maintain the following for the Calculation Engine: a) Calculation Path b) Calculation Procedure

Calculation Path The calculation path replaces the SAP access sequence. The calculation path informs the Vistex calculation engine how to read the condition table (A table) for Vistex transactions. For the discount, price, or eligibility to be derived from a condition table and to be used in a calculations, the user needs to send parameters to the table and return the required condition types. The standard setting are provided for calculation path, requiring the user to enter the application, a four character alphanumeric name, and a description. The application, subdivides the usage of a condition to use in different application areas, for example sales and distribution or purchasing. In the Steps node, the user has to list the steps for the calculation path, similar to the setup of an access sequence. For each step, assign a step number and the condition table. Then, enter values in the following fields, as needed.

a) Stop If Found: Select the checkbox to stop at that step if a condition record is found. b) Result: If multiple condition records are found in the A table, the options All Records or Most Specific

Record will determine which records are used. c) Before Read: This allows the user to create a business script to be read before the condition table is read.

In the Step Fields Mapping node, enter the values in the following fields to map the condition table source fields to the target (document) fields:

a) Mapping Type: The options here determine how the data travels within this step. Using the option Incoming, pulls the data into the step. While, using the Outgoing option provides derived data to be read by other fields. For example, when finding the agreement for a customer, the customer would be Incoming and the agreement would be Outgoing.

b) Source: This indicates how to read the condition record. The source allows for the options Value Only, Initial If Value Not Passed, Initial and Value, Initial Value Only, Constant, and Skip if Initial. The Value only option specifies that the value is expected in the document, but if there is no value, exit the Read. The option Initial if Value Not Passed will provide priority to value passed if no value is listed as an initial value. The Initial and Value option reads all combinations and returns best/most specific record. While, the Initial Value Only will only provide those values listed as initial. Using the Constant option will provide the constant from the Value field. Finally, the Skip if Initial option will not be read if field is empty.

c) Communication Type: This indicates where the field is available. The options are Header, indicating the data is in the document header, Item, indicating the data is within the item structure, Derivations, which is used with 601/602 logic, and Dynamic Attributes, which uses run time characteristics.

Release V4 1709 – Calculation Engine

Page 2 of 2

Calculation Procedure The calculation procedure replaces the SAP pricing procedure and will be used for all the calculations. The calculation procedure is also used to determine the agreement using the condition search. The standard setting are provided for calculation procedure, requiring the user has to enter the application, six character alphanumeric name and a description. The application, subdivides the usage of a condition to use in different application areas, for example sales & distribution or purchasing. In the Steps node, list the steps in the procedure, similar to a pricing procedure. For each step, assign a step number and the condition type, then enter values in the fields, as needed.

a) From Step and To Steps: These are used to help the calculation procedure reference data or calculations made in other steps. For example, when using percentages, to reference a step, the percentage surcharges are calculated on the basis of the total. If user specify a from reference step at the same time, the condition values of the two steps specified. This allows the condition values of the steps in between to be calculated.

b) Path: Indicates how to read the condition records based on the calculation path. c) Outcome: Designates the contribution to the net value. The options here include Add, Subtract,

Informational Only, Result, and Final. The Add and Subtract options allow for basic arithmetic, while the Information Only option indicates the outcome is for statistical elements. The Result option is for intermediate values, and the Final option holds the final net value.

d) Copy From: Select the checkbox to copy a price from a source document. Here, no path is needed and the Information Only outcome must be used.

e) Required: Informs the system if the step is mandatory. f) Manual condition Property: Determines if manual conditions are allowed for the current step. Here the

options include No Limitations, Automatic Entry has Priority, Manual Entry has Priority, Not possible to Process Manually, and Manual Only.

g) Derivation Control: This entry is mainly use for the 601/602 engine. The options available are Invoke 601, Invoke 602, Apply Agreement Resolution, and Set Reconciliation Status. Selecting the Invoke 601 indicates to the evaluation engine to start collecting agreements. The Invoke 602 option directs to further the filter eligibility and benefits. While the option Apply Agreement Resolution is used for agreement resolution in case of multiple agreements. Here the user can create a new condition type and assign the Invoke 601 routine in the resolution. Finally, the Set Reconciliation Status is used in claims only for CEPOK.

h) Business Scripts: Allows for pricing functions in scripts to be invoked before or after the 601/602.

In the Step Outgoing Fields Mapping node, the user can map a value to one or multiple work fields. a) Field Type: This allows for the options of Rate, Condition Value, or Others. b) Source Field c) Data Area: The options available include Calculation (work) Fields, Dynamic Attributes, and Item. d) Target Field

Release V4 1709 – Condition Contract Management & New Vistex Engines

Contents Condition Contract Management ................................................................................................................. 2

Condition Contract Type Maintenance ......................................................................................................... 2

Vistex Related Condition Contract Custom Field Additions .......................................................................... 2

Condition Contract Assignment to Agreement Type .................................................................................... 4

Agreement Type Changes ............................................................................................................................. 4

New Vistex Engines in V4 1709 ..................................................................................................................... 4

Partner Determination .............................................................................................................................. 4

Text Determination ................................................................................................................................... 4

Output Determination .............................................................................................................................. 5


Condition Contract Management Previously, the Vistex Agreement created an SAP Sales Deal and stored the rules data entered in the agreement. However, in Release V4 1709, the sales deal functionality will not be used for creating agreements. Going forward, a condition contract will be created instead to store the Vistex Agreement information. The condition contract configuration is similar to the configuration of a sales deal. Outside of the creation of a condition contract number, instead of a sales deal number, at the time of agreement creation, no other changes have been made to the Vistex Agreement functionality.

Condition Contract Type Maintenance For the Condition Contract to be created when creating an agreement the Condition Contract Type must be configured. The Condition Contract Type can be maintained at the following configuration path:

SPRO > SAP Customizing Implementation Guide > Logistics - General > Settlement Management > Condition Contract Management > Condition Contract Maintenance > Maintain Condition Contract

Within the configuration screens, the following fields must be maintained:

• Number Range: This identifies how the system will number the Condition Contracts. • Type of Contract Partner: Controls whether the business partner of the condition contract is

a supplier or a customer or whether there is no business partner for the condition contract. • Type of Eligible Partner: Specifies the type of eligible partner for the condition contract. • Condition Type Group: This group is a combination of condition types and condition tables

to be used in the condition contract type. This is similar to Sales Deal Type Group, except for the categorization which can be used to categorize Sales and Purchase applications.

• Change via UI: This option determines if changes can be made via the user interface. However, currently, changes via User Interface are not possible for Condition Contracts. Therefore, this must be reflected in the selection.

Vistex Related Condition Contract Custom Field Additions Additional customization is needed to enable the use of Vistex related fields and Vistex custom fields within the pricing conditions of the condition contract. The Vistex related and custom fields must be added to the structures BAPI_TE_KOMG and BAPI_TE_KOMGX. The fields must be included in the structures using appends. These fields can be included on an existing custom append structure or included as part of a new custom append structure. In the example below, a custom append structure, ZSGAGRCC_ATTR, was created for BAPI_TE_KOMG. Then, the Vistex related fields were added to the custom append structure. Please note, do not go into change mode when displaying the BAPI_TE_KOMG structure, as this will cause an SAP core modification. Rather, double click on the custom append structure name and add the related Vistex and Vistex custom fields. Examples of including Vistex related fields on custom append structures for each BAPI structure are shown below in the corresponding screen shots.


BAPI_TE_KOMG configuration

BAPI_TE_KOMGX configuration

If the fields are intended to be used in the agreement rules, then the Vistex related fields must be appended to the Allowed Condition Key Fields – Customer Field structure, WCB_S_COND_KEY_FIELDS_CUSTOMER, as show below.


Condition Contract Assignment to Agreement Type Once the Condition Contract Type is maintained, it must be assigned to the Agreement type using the following configuration path:

IPSPRO > Incentives and Payback Module > Basic Functions > Pricing - Sales > Pricing Agreements > Maintain IP Agreement Types - Sales > Maintain Agreement Types / 1

Agreement Type Changes With the new condition contract functionality, it is no longer necessary to maintain anything in the Define Sales Deal Type configuration activity to be able to create an agreement type. The Agreement Type can be directly defined at the type level. In addition, there is no need to maintain the New Pricing Engine flag, as all the Agreements will be created with the new pricing engine in V4 1709. Besides that, the following fields have been moved from the Define Sales Deal Type configuration to the Agreement Type configuration:

• Prop.valid From • Prop.valid To • Release Status • No. Range no. • Agreement Group • Text Procedure

New Vistex Engines in V4 1709 In prior releases, Vistex used SAP engines for partner, text, and output till now. As of Release V4 1709, new engines for partner, text, and output will be available in Vistex. The configuration can be maintained for each of these engines in Vistex.

Partner Determination Previously, for the partner determination functionality, Vistex used the SAP architecture for partner procedures and partner functions. Going forward in V4 1709, a new partner engine will be used and partner procedures can be created in Vistex. However, Vistex still uses the partner functions from SAP. There are no changes to assignment of partner procedure to agreements types, claims types, or transaction register types. The following configuration path can be used to maintain the partner determination:

IPSPRO > Incentives and Payback Module > Basic Functions > Partner Determination > Partner Determination (Version 2.0) > Maintain Partner Determination Procedure

Text Determination A new text engine is available in V4 1709. The text determination configuration for text IDs and text procedures can be maintained in the Vistex system instead of the SAP system. Once the text procedure


is created, it can be assigned to the agreement type. Vistex Data moves from SAP tables to corresponding IRM tables. Currently, SMARTFORM and ADOBE are not supported to read Vistex Text. The rest of the text functionality at the application level remains the same. To complete the text determination configuration, use path:

IPSPRO > Incentives and Payback Module > Basic Functions > Texts > Texts (Version 2.0)

Output Determination Historically Vistex used the SAP output procedures and output types to trigger Idocs and print output. Going forward in V4 1709, the output control can be maintained in Vistex. The system still uses the output type from SAP in the output determination. However, in the output control, the applications, such as, billback, chargeback, deals, or claims, must be selected and the sales or purchasing output control is to be maintained as needed. Now, the Vistex Data moves from SAP tables to corresponding IRM tables. The following is the configuration path to maintain Output Control:

IPSPRO > Incentives and Payback Module > Basic Functions > Output (Version 2.0) > Maintain Output Control

Contents Calculation Buckets ....................................................................................................................................... 2

Bucket Configuration Path ........................................................................................................................ 2

IP Type ....................................................................................................................................................... 2

Calculation Bucket Group ......................................................................................................................... 2

Calculation Bucket Type ............................................................................................................................ 2

Calculation Bucket Type Sections ............................................................................................................. 2

General .................................................................................................................................................. 3

Header Criteria ...................................................................................................................................... 3

Item Criteria .......................................................................................................................................... 3

Data Model ........................................................................................................................................... 3

Bucket Filter .......................................................................................................................................... 3

Aggregation Types................................................................................................................................. 3

Aggregation Filter .................................................................................................................................. 3

Calculation Bucket Search Profile ............................................................................................................. 3

Calculation Bucket Workbench ................................................................................................................. 4

Calculation Bucket Workbench Sections .................................................................................................. 4

Header Tab ............................................................................................................................................ 4

Items Tab ............................................................................................................................................... 4

Tracking Tab .......................................................................................................................................... 4

Updating Buckets ...................................................................................................................................... 4

Calculation Bucket Mass Processing ......................................................................................................... 4

Calculation Run ......................................................................................................................................... 5

Condition Search Profile ........................................................................................................................... 5


Page 2 of 5

Calculation Buckets The Calculation Bucket functionality has been introduced for release V4 1709 and is designed to store the source document information in the calculation bucket workbench. Previously, IP documents were used to perform calculations and stores the source document information, but, now, the IP documents will be replaced with calculation buckets. In addition, the calculation buckets will be used to store the source document information. These buckets use the calculation procedure and stores the net data to the calculation bucket workbench.

Bucket Configuration Path Before utilizing the bucket functionality, the configuration must be completed. To do this, follow the below configuration menu path: /IRM/IPSPRO > Incentive and Payback Module > Documents > Calculation Buckets

Her the user has to maintain the following information for the Calculation Buckets: a) IP Type b) Calculation Bucket Group c) Calculation Bucket Type

IP Type The IP type is used to specify the IP application, condition search profile, and debit/credit indicator for calculation buckets.

Calculation Bucket Group The Calculation Bucket Group is used to store source documents for multiple IP types in one bucket. During processing, the system uses the header/item controls assigned to the bucket group and selects the calculation bucket type assigned to the bucket group. The user has to define sales or purchase bucket groups. For each bucket group, define the header controls with the IP type and sales document information, along with item control with the IP type and Item category. Once the bucket group is defined, the bucket group is to be assigned to the calculation bucket type.

Calculation Bucket Type The calculation bucket type can be maintained in the configuration transaction, /IRM/IPSPRO. The user can create or modify bucket types through the transaction codes, /IRM/IPCLBCM and /IRM/IPCLBM. Calculation buckets are used to define the calculation data, user has to define a calculation bucket type for each application/source document type. Below are the supported source document types:

• Sales document • Billing document • Delivery • Purchase document • Claim • Transaction Register

Calculation Bucket Type Sections As part of the calculation bucket type, information in the following sections must be provided:

• General


Page 3 of 5

• Header Criteria • Item Criteria • Data model • Bucket Filter • Aggregation Types • Aggregation Filter

General The information provided in the general tab is used to derive the application information for the bucket type. In the general tab, the user has to maintain the application, source, bucket usage, update type, bucket group, basis date field, bukcet anchor, and the number range field.

Header Criteria The header criteria tab is used to help determine which information will be included in the header section of the bucket documents. To add fields into the header criteria, click on the criteria button and select from the available IP header and item structure fields.

Item Criteria The item criteria determines the data that will be included in the item section for that bucket type. To add fields as part of the item criteria, click on the criteria button and select from the available IP items and item structure fields.

Data Model All the header and Item criteria fields to be stored in the bucket are listed on the Data Model tab.

Bucket Filter The bucket filter defines how the data will be filtered and updated into the bucket. The filter criterial fields and the filter value fields are available to use the bucket filter functionality. When updating the bucket, the bucket filter is first checked, followed by Header and Item Criteria. The user has flexiblity to include and exclude the bucket type filter values by selecting the appropriate options.

Aggregation Types The aggregation type is defined by the user with the criteria and values by which the bucket type will accumulate the relevant data.

Aggregation Filter The aggregation filter tab is used as an additional filter for aggregating data in Buckets. The aggregation filter can only be created for the aggregation type defined in bucket type. This is accomplished by selecting the aggregation type from the aggregation type dropdown.

Calculation Bucket Search Profile The calculation bucket search profile can be defined in the transaction /IRM/IPCLBUSPM. Here, the user can create the search profile for source document processing. This profile will be utilized when updating the bucket using the source document.


Page 4 of 5

Calculation Bucket Workbench The calculation bucket is created to store all the information of source documents related to one agreement or one partner. These buckets use the calculation procedure and store the net data of the bucket. Once the source documents are ready, the buckets are processed to update the calculation bucket. The calculation bucket can be created in two ways:

1. Manually, by creating the calculation bucket using the calculation bucket workbench transaction /IRM/IPCLBM.

2. Automatically, the creation of the the bucket is accomplished through the agreement.

Calculation Bucket Workbench Sections Within the calculation bucket workbench, the data for each bucket is divided into:

• Header • Items • Tracking

Header Tab In the headers tab of the calculation bucket, the header criteria details will be avaiable. For example, if the user selected the agreement as header criteria, then, the header tab will show the agreement details.

Items Tab The items tab stores the source document information along with the net data into the calculation bucket workbench. In the items tab, item details, color legend, item summary and page size are also available. The item details shows the pricing analysis information for the line items, as well as the color legend, which displays the different behavior of the line items.

Tracking Tab The tracking tab tracks the accrual and the settlement calculation run details. In the tracking tab, the color legend is available to show the different behavior of the calculation run for the accrual and settlement document. The user also has an option to navigate through the calculation run documents and verify the postings.

Updating Buckets To update the bucket, the user must navigate to mass process bucket transaction, /IRM/IPXXCLBSMP (where XX is replaced with the corresponding application, e.g. BB for Billbacks or CB for Chargebacks. Through this the user can update the calculation bucket. In the mass process bucket workbench user has to select search profile, provide source document information, select create option, and click on execute. Then the system will update the calculation bucket. The reprocess, reprice, and delete options are also available in the mass process bucket workbench.

Calculation Bucket Mass Processing The calculation bucket mass processing workbench is used to create accrual and settlement run. In the mass processing of calculation bucket transaction, /IRM/IPCLBPMP, the user has to select the search profile, provide the bucket type, provide the bucket number, and select the accrue or settlement option. Then when clicking execute, the system will create the corresponding calculation run. The tracking tab in calculation bucket workbench will also be updated with calculation run details.


Page 5 of 5

Calculation Run The calculation run workbench is used to post the accrual and settlement documents. In the calculation run transaction, /IRM/IPTTM, and the user can perform the postings by selecting the calculation run type and calculation run documents. Once the documents are posted, the system will post the accrual or settlement, which will update the tracking tab of the corresponding calculation bucket with the posting details. These details are available in the calculation bucket workbench.

Condition Search Profile The condition search is used to determine the agreements. Each agreement has the owners that are specified as partner functions with the corresponding partner number. To implement the condition search technique, a condition search profile must be defined. To maintain the condition search profile, the user must first specify the profile name with the corresponding description, and the application. In addition, the user must assign a condition search pricing procedure to the condition search profile. The condition types used for this procedure are relevant for the condition search. For each condition search profile, if the cascaded search is to be used, the mappings are to be specified. A cascaded search is when the results of the first search are transported into KOMP and KOMK structures. To do this, specify which structure is to be used for a particular combination of application, condition type, and condition field. In addition, specify the reference field to be used in the document field and the partner function to be used for that combination. Once the condition search profile is defined, it is then assigned to the IP type. The condition search profile is configured by following the configuration path: /IRM/IPSPRO > Incentive and Payback Module > Basic Functions > Condition Search > Define condition Search Profile.

Contents Introduction .................................................................................................................................................. 2 Mapping Profile Functionality ....................................................................................................................... 2 Configuration Steps ....................................................................................................................................... 3

Header Section .......................................................................................................................................... 3 Source ................................................................................................................................................... 3 Proforma Type ...................................................................................................................................... 3 Open Instance ....................................................................................................................................... 3 Matrix Data ........................................................................................................................................... 3 Change Validity ..................................................................................................................................... 3

Source Tab................................................................................................................................................. 4 Collection Types .................................................................................................................................... 4 Distribution Types ................................................................................................................................. 5 Basis Dates ............................................................................................................................................ 5

Simulation Tab .......................................................................................................................................... 6 Targets Tab ................................................................................................................................................ 7

Proposed Target .................................................................................................................................... 7 Target Type as Matrix ........................................................................................................................... 8 Target Type as Rules ........................................................................................................................... 10

Scenarios ..................................................................................................................................................... 11 Use-Cases for the Source Tab ................................................................................................................. 12

Collection Type as ‘Average’ / Basis Date as ‘Both’ / Key Figure as ‘Accepted Amount’ ................... 12 Collection Type as ‘Min’ / Basis Date as ‘Both’ / Key Figure as ‘Adjusted Amount’ ........................... 13 Collection Type as ‘Sum’ / Basis Date as ‘Valid From’ / Key Figure as ‘Adjusted Quantity ‘............... 15 Collection Type as ‘Max’ / Basis Date as ‘Valid To’ / Key Figure as ‘Net Price’ ................................... 16 Distribution Type as ‘Sweep’ / Basis Date as ‘Both’ / Key Figure as ‘Auto Adjustment Amount’ ...... 18 Basis Date as ‘Either Valid From/To’ / Key Figure as ‘Net Price’ ......................................................... 19

Simulation Tab ........................................................................................................................................ 21 Use-Cases for the Target Tab .................................................................................................................. 22

Target Type as Matrix ......................................................................................................................... 22 Target Type as Rules ........................................................................................................................... 25 Source as Planning Document ............................................................................................................ 36

Release V4 1709 - Mapping Profile

Page 2 of 37

Introduction In Release V4 1709, a new workbench called “Mapping Profile” was introduced to replace the existing proforma profile configuration. This helps the user fetch data from different sources like agreement/request, calculation run, price simulation, price records and planning document. Previously, the user needed to maintain the proforma profile in /IRM/IPSPRO, but from this release onwards, the mapping profile workbench is available for creation and modification. So now the user can create a mapping profile by using the Mapping Profile transaction code, /IRM/IPMXMPM.

Mapping Profile Functionality The Mapping Profile workbench is similar to that of existing the proforma profile where the user has to map matrix characteristics and key figures with respect to the selected source type. 1. Agreement/Request based Mapping Profile: Agreement/Request as a source mapping profile is used to fetch data from an agreement, agreement request, master request, deals, deal request, direct agreement, and direct agreement request. 2. Calculation Run based Mapping Profile: Calculation run as a source mapping profile is used to fetch data from a composite IP documents. 3. Price Simulation based Mapping Profile: Price simulation as a source mapping profile is used to fetch data from a price simulation. 4. Price Records based Mapping Profile: Price records as a source mapping profile is used to fetch data from a price proposal. 5. Planning Document based Mapping Profile: Planning document as a source mapping profile is used to fetch data from planning documents.


Page 3 of 37

Configuration Steps

Header Section Source Here the user can pick any desired source type, such as: a. Agreement/Request b. Calculation Run c. Price Simulation d. Price Records e. Planning Document

Proforma Type Assign a proforma type that is configured in /IRM/IPSPRO in the proforma type field in the mapping profile.

Open Instance There are two types of open instances, single and multiple instances. The user can select any instance depending on the requirement.

Matrix Data Here the user needs to select the matrix data (matrix, subset, usage) for which the mapping profile is to be created.

Change Validity The change validity functionality gives feasibility to the user to select the validity dates while creating a proforma. If the validity is marked as ‘YES’, then the validity change fields will be available while creating a proforma.


Page 4 of 37

Source Tab In this tab, the user needs to assign and map all of the necessary ‘Characteristics’ and ‘Key Figures’ with respect to the source category selected.

In characteristics mapping, matrix characteristics are mapped to the source characteristics.

In the key figure mapping, the matrix keyfigure is mapped to the source keyfigure and the conditions should be maintained. Note: The collective type, distribution type and basic date is selected according to the usecase.

Collection Types


Page 5 of 37

Sum If the user selects the collection type as SUM, then it picks up the ‘Total’ value of the price records that falls under similar criteria.

Min If the user selects the collection type as MIN, then it picks up the ‘Minimum’ value of the price records that falls under similar criteria.

Max If the user selects the collection type as MAX, then it picks up the ‘Maximum’ value of the price records that falls under similar criteria.

Average If the user selects the collection type as AVG, then it picks up the ‘Average’ value of the price records that falls under similar criteria.

Distribution Types This field works with a combination of the collection type.

Blank It will not consider any of the distribution type conditions; it will update the value to matching period records at the proforma level.

Sweep It will directly consider the first record value, which meets the source mapping condition.

Basis Dates


Page 6 of 37

Both This will use both the valid from and to dates on the rule sheet.

Valid From This will only use the from date on the rule sheet.

Valid To This will only use the to date on the rule sheet.

Either Valid From/To This will use the valid from date or the to date on the rule sheet.

In order to maintain conditions for any key figure mapping, the user needs to click on conditions button and map the required conditions.

Simulation Tab In this tab, the user needs to map all of the required simulation-related fields along with “Price Simulation Type” and “Basis Date” selections. Note: This functionality is similar to that of earlier the ‘Proforma Profile’ concept; there is no change in the mapping profile concept for the Simulation tab in Release V4 1709.


Page 7 of 37

Targets Tab • The Target tab has the feasibility of updating back to the Proforma level data into the matrix and

rules (price sheets) as well. The user needs to maintain the required targets in the Target tab to get the proforma data into the configured targets.

• According to the target type (matrix or rules) that are assigned at the Target tab level, the target type will be updated back with the latest proforma data whenever the proforma gets saved/posted.

• Here the user just needs to confirm whether the assigned list of target entries to be updated when a proforma is saved/posted using the field ‘Update Control’ drop down list.

• The user needs to map the respective target fields with the Mapping Profile Source tab fields (characteristics and key figures).

• The user can skip mapping for the mapping profile source matrix subset usage combinations. NOTE: Earlier in the proforma profile, it was limited to updating the proforma source matrix subset usage combinations only. But now it can update ‘N’ as the number of matrix sources and prices sheets.

Proposed Target When the user clicks on the proposed target in the Target tab, it displays all of the rules that are used in source mapping.


Page 8 of 37

Target Type as Matrix Here the user should map proforma characteristics with the target matrix characteristics and the proforma level key figures with target matrix key figures as shown in the below screenshot.

Characteristics Mapping for Matrix Target characteristics and source characteristics are mapped as shown below.

Key Figures Mapping for Matrix For the matrix target type key figures mapping, the user needs to map target key figures and source figures and should specify the ‘Update Type’ and ‘Distribution’ field values as shown in the below screenshot.


Page 9 of 37

Update Type Overwrite This will always overwrite the existing usage level data whenever the user updates the proforma data.

Cumulate This will always cumulate the existing usage level data whenever the user updates the proforma data.

Deplete This will always deplete the usage level data whenever the user updates the proforma data.

Distribution Sum This will sum up the similar values that are coming from the proforma to the matrix and it will update.

Average This will average the similar values that are coming from the proforma to the matrix and it will update.

Sweep This will sweep up the first record value that is coming from the proforma to the matrix and it will update.

Equal This will distribute equal value the similar values that are coming from the proforma to the matrix and it will update.

Weighted This will sum up the similar values that are coming from the proforma to the matrix and it will update.


Page 10 of 37

Target Type as Rules Here the user should map proforma characteristics with the target rule characteristics and the proforma level key figures with the target rule key figures as shown in the below screenshot.

Characteristics Mapping for Rules Target characteristics and source characteristics are mapped as shown below.

Key Figures Mapping for Rules For the matrix target type key figures mapping, the user needs to map target key figures and source figures and should specify the ‘Delete check box’, ‘Update Rules’ and ‘Distribution Type’ field values as shown in the below screenshot.

Delete Checkbox If the delete checkbox is enabled and the source field value is zero/empty and the update control (on save or on post) is applied, the system will delete the condition record.

Value and Validity Value Only This will update the value in the rule.

Value and Validity If a record does not already exist for that periodicity this will create new condition records in the rule.

Distribution Type Sweep When sweep distribution is applied, it will sweep the entire value into source condition records.

Weighted When weighted distribution is applied, it will distribute the value into the source condition records, based on the contribution percentage of records into the proforma.


Page 11 of 37

Scenarios For example, in order to summarize the ‘Mapping Profile’ functionality , Matrix /IRM/IPMX0306 and a few mapping profiles are used as per requirement in describing the flow as shown in the below screenshots.

Mapping profile ZSP5 is of source type agreement/request, proforma type “ZNEW’ with the open instance as ‘multiple’ along with a valid matrix, subset and usage and “Change Validity” combinations. Here the mapping profile ZSP5 is used for the master request application, which is used for creating the proforma with below configured Source tab configurations.

Master Request ‘R200012397’ with values in the price sheet ‘PR00-005’ is displayed below.

Now the user has to create a proforma using mapping profile ZSP5 in the Proforma tab along with the below highlighted Start Date and End Date selection values.


Page 12 of 37

Upon clicking on continue, proforma 4525 was created and the data is pulled into it according to the configuration as shown below.

Use-Cases for the Source Tab The key figures mapping is setup with collection type, distribution type and basis date fields.

Collection Type as ‘Average’ / Basis Date as ‘Both’ / Key Figure as ‘Accepted Amount’ In the master request, the rules for price sheet PR00~005 were maintained as shown below.

In the below screenshot, the user mapped the key figure ‘Accepted Amount’ to the ‘KBETR’ source field along with the collection type as ‘Average’ and the basis date as ‘Both’.


Page 13 of 37

The proforma was created with the validity dates as shown below.

Here the average value from the above highlighted two records is “40”; hence, the same is reflected back to the proforma level.

Collection Type as ‘Min’ / Basis Date as ‘Both’ / Key Figure as ‘Adjusted Amount’ In the master request, rules for price sheet PR00~005 were maintained as shown below.


Page 14 of 37

In the below screenshot, the user mapped the key figure ‘Adjusted Amount’ to the ‘KBETR’ source field along with the collection type as ‘Min’ and the basis date as ‘Both’.

The proforma was created with validity dates as shown below.


Page 15 of 37

Here the minimum value from the above highlighted two records is “30”; hence, the same is reflected back to the proforma level.

Collection Type as ‘Sum’ / Basis Date as ‘Valid From’ / Key Figure as ‘Adjusted Quantity ‘ In the master request, rules for price sheet PR00~005 were maintained as shown below.

In the below screenshot, the user mapped the key figure ‘Adjusted Quantity’ to the ‘UKBAS’ source field along with the collection type as ‘Sum’ and Basis Date as ‘Valid From’.



Page 16 of 37

Here the sum value from the above highlighted two records (committed quantity) is “10” and is reflected for the 01/2017 period as the basis date is the Valid From date; hence, the same is reflected back to the proforma level.

Collection Type as ‘Max’ / Basis Date as ‘Valid To’ / Key Figure as ‘Net Price’ In the master request, rules for price sheet PR00~005 were maintained as shown below.


Page 17 of 37

In the below screenshot, the user mapped the key figure ‘Net Price’ to the ‘KBETR’ source field along with the collection type as ‘Max’ and basis date as ‘Valid To’.


Here the maximum value from the above highlighted two records is “50” and is reflected for the 04/2017 period as the basis date is the Valid To date; hence, the same is reflected back to the proforma level.


Page 18 of 37

Distribution Type as ‘Sweep’ / Basis Date as ‘Both’ / Key Figure as ‘Auto Adjustment Amount’ In the master request, rules for the price sheet PR00~005 were maintained as shown below.

In the below screenshot, the user mapped the key figure ‘Auto Adjustment Amount’ to the ‘KBETR’ source field along with the distribution type ‘Sweep’ and basis date as ‘Both’.



Page 19 of 37

Here the first record value in the master request rules is ‘30’and it gets updated to all periods with respect to the basis date ‘Both’; hence, the same is reflected back to the proforma level.

Basis Date as ‘Either Valid From/To’ / Key Figure as ‘Net Price’ In the master request, rules for the price sheet PR00~005 were maintained as shown below.

In the below screenshot, the user mapped the key figure ‘Net Price’ to the ‘KBETR’ source field along with the basis date as ‘Either Valid From/To’.


Page 20 of 37


Here value in the master request rules is ‘100’ and it gets updated to periods with respect to the basis date of ‘Either valid from/to’; hence, the same is reflected back to the proforma level.


Page 21 of 37

Simulation Tab This functionality is similar to that of the earlier proforma profile concept.

The user can verify the price simulation created for the above mapping profile with simulation 4592 as shown in the below screenshot.


Page 22 of 37

Use-Cases for the Target Tab Target Type as Matrix

Matrix with update type and distribution assigned in key figures mapping In the master request, rules for the price sheet PR00~005 were maintained as shown below.

In the below screenshot, the user has to map the key figures along with the update type and distribution assigned as shown below.



Page 23 of 37

Proforma 4528 was created with values as shown below.

The target subset data before making changes in proforma is shown below.

In this example, manually made changes were done in the proforma value and the changes were saved (update control was set to on save) as shown below.

The user can even use existing proforma data updated from the source.


Page 24 of 37

Now check the target subset data, it is getting updated according to the update type and distribution as shown in below screenshot.

Update Type as ‘Cumulate’ / Distribution as ‘Sum - Auto Adjustment Amount’ Previously, the AAAMT was ‘105’ in the target subset data and in the updated proforma data it was ‘60’; after saving the proforma data in the target subset, it updated to’165’.

Update Type as ‘Cumulate’ / Distribution as Weighted - Accepted Amount’ Previously, the ACPAMT was ‘105’ in the target subset data and in the updated proforma data it was ‘15’; after saving the proforma data in the target subset, it updated to ’120’.

Update Type as ‘Deplete’ / Distribution as ‘Sweep - Adjusted Amount’ Previously, the ADJAMT was ‘5’ in the target subset data and in the updated profoma data it was ‘25’; after saving the proforma data in the target subset, it updated to ’-20’.

Update Type as ‘Overwrite’ / Distribution as ‘Equal - Adjusted Quantity’ Previously, the ADJQTY was ‘30’ in the target subset data and in the updated proforma data it was ‘45’; after saving the proforma data in the target subset, it updated to ’45’.

Update Type as ‘Overwrite’ / Distribution as ‘Average - Net Price’ Previously, the NETPR was ‘50’ in the target subset data and in the updated proforma data it was ‘105’; after saving the proforma data in the target subset, it updated to ’35’.


Page 25 of 37

Target Type as Rules

When the Delete checkbox flag is marked and update rules is selected as ‘Value only’ in key figures mapping In the master request, rules for the price sheet PR00~005 were maintained as shown below.


Page 26 of 37

In the below screenshot, the user mapped key figures along with the ‘Delete check box’ for the source field NETPR.




Page 27 of 37

The rules data before making changes in proforma is shown below.

The NETPR value was changed to zero for material VE-101 and customer 103630 in the proforma data and save the proforma as update control was ‘On save’ for the target type rule.

The proforma data with null values will be deleted from the target rule.

When on the Rules tab in the master request, the user can see that the rule with customer 103630 and material VE-101 was deleted as shown below.


Page 28 of 37

When the Delete checkbox flag is marked and update rules is selected as ‘Value and Validity’ in key figures mapping In the master request, rules for the price sheet PR00~005 were maintained as shown below.

In the below screenshot, the user mapped key figures along with the ‘Delete’ checkbox and update rules as ‘Value and Validity’ for the source field NETPR.



Page 29 of 37


The rules data before making changes in proforma is shown below.


Page 30 of 37

The NETPR value was changed to zero for material PH-800 and customer 103934 in the proforma data and the NETPR value to 10, 11 and 12 for material CPT-01 and customer 103933 in the proforma data. The proforma update control is set to ‘On save’ for the target type rule.

On the Rules tab in the master request, the user can see that the rules were added according to the validity as shown below.


Page 31 of 37

When distribution type is sweep and weighted distribution is selected in key figures mapping In the master request, rules for the price sheet PR00~005 were maintained as shown below.

In the below screenshot, the user mapped key figures along with the distribution type as ‘Sweep’ for the source field NETPR and ‘Weighted Distribution’ for source field ADQTY.


Page 32 of 37




Page 33 of 37

The rules data before making changes in the proforma is shown below.

The NETPR and ADQTY values in the proforma data were changed and the proforma was saved because the update control was set to ‘On save’ for the target type rule.

On the Rules tab in the master request, the user can see that the rule values got changed according to the distribution type assigned to the key figures.

Distribution Type as ‘Sweep – NETPR’ Previously, the NETPR value was ’10, 20 and 30’ in the rule data for all three months (JAN, FEB and MAR) respectively and in the updated profoma data, it was ‘100’ for quarter 1. After saving the proforma data in the target, the rule data updated to ’100’ for all three months (JAN, FEB and MAR).

Distribution as ‘Weighted Distribution - Adjusted Quantity’ Previously, the ADQTY value was ’1, 2 and 3’ in the rule data for all three months (JAN, FEB and MAR) respectively and in the updated profoma data, it was ‘10’ for quarter 1. After saving the proforma data in the target, the rule data updated to ’1.667, 3.333 and 5’ for all three months (JAN, FEB and MAR) respectfully.


Page 34 of 37

When update rule ‘Value and Validity’ is selected in key figures mapping In the master request, rules for the price sheet PR00~005 were maintained as shown below.

In the below screenshot, the user mapped key figures along with update rules as ‘Value and Validity’ for the source field NETPR.



Page 35 of 37


The rules data before making changes in the proforma is shown below.

The NETPR value was changed in the proforma data with different values for JAN, FEB and MAR as shown and the proforma was saved since the update control was set to ‘On save’ for the target type rule.


Page 36 of 37

On the Rules tab in the master request, the user can see that the rules’ values were changed according to the update rules assigned to the key figures.

Update Rule Type as ‘Value and Validity – NETPR’ Previously, the NETPR value was ’25’ in the rule data for dates 01/01/2017 to 03/31/2017 and in the updated profoma data it was ‘26’ for Jan, ‘27’ for Feb and ‘28’ for Mar. After saving the proforma data in the target, it created two new condition records and one record was updated in the rule with valid dates (01/01/2017 to 01/31/2017, 02/01/2017 to 02/28/2017 and 03/01/2017 to 03/31/2017)

Source as Planning Document When the source is the planning document, the only available tab is the ‘Target’ tab. The user needs to assign the planning document type with respect to the mapping profile type at the subset usage level as shown below.


Page 37 of 37