Functions in Details

CPE Interface
Introduction
The standardized CPE interface allows you to handle CPE data by different document types without using
the existing CPE UI. It can be used for purchasing and sales documents as well as for GTM contracts.

Note:
For using the CPE interface for logistics documents, business function LOG_CPE_SD_MM, and for
GTM contracts, business function ISR_GLT_CMMINTEG must be activated.

The creation and update of a CPE Formula, and the creation, update or deletion of other CPE
components like terms, price fixation options, and price fixation exercises etc. are supported either.
After the data is provided to the interface, the relevant standard logistics BAPI for creation or change of a
document needs to be called. In this way, the processing of the provided CPE data is triggered, even
though no other document changes are done. This also points out the fact that the interface is called
once per document like it is the case for all logistics document BAPIs.
Newly evaluated data, as well as unchanged document data can be retrieved with this CPE Interface.

This document shows some examples on how to use the interface.

General Information on How to Use the Interface

Technical Setup

The CPE interface contains the two main methods SET_DATA and GET_DATA. To use one of these
methods you must have created an instance of the CPE interface factory class:

DATA lo_cpe_interface TYPE REF TO if_cmm_cpe_interface.

lo_cpe_interface = cl_cmm_cpe_interface_factory=>get_instance( ).

IF lo_cpe_interface IS BOUND.

lo_cpe_interface->set_data( EXPORTING it_prcfix_exercise = lt_exercise

it_prcfix_exercisex = lt_exercisex
IMPORTING et_message = return ).
ELSE.
RETURN.
ENDIF.

As you can see, method SET_DATA has an importing table parameter ET_MESSAGE from type
BAPIRET2_T, which is also used in every BAPI for logistics documents. In case, invalid data have been
passed, or there is another problem regarding data consistency, you will find error messages inside this
table parameter.

Recommendation:
SAP recommends you to always check this parameter for error messages and, if error messages
exist, to interrupt the program processing. Else, passed data will not be considered anyway for
further processing, because this would lead to inconsistencies in the CPE pricing.

To request a creation, an update or a deletion of CPE data via SET_DATA method, two records must be
maintained for each CPE component:

a) Data record

This record contains the data to be inserted or updated (field values):

Interface data structure for Formula - CPES_FORMULA_INTF

Interface data structure for Term - CPES_TERM_INTF

Interface data structure for Price Fixation Option - CPES_PRCFIX_OPTION_INTF

Interface data structure for Price Fixation Exercise - CPES_PRCFIX_EXERCISE_INTF

 Interface data structure for Term Period Determinat. - CPES_TERM_PERIODDET_INTF

Interface data structure for Term Surcharge - CPES_TERM_SURCHARGE_INTF

Interface data structure for Term Calculation - CPES_TERM_CALCULATION_INTF

Interface data structure for Formula Conversion - CPES_FORMULA_CONVERSION_INTF

Interface data structure for Formula Rounding - CPES_FORMULA_ROUNDING_INTF

Interface data structure for Term Conversion - CPES_TERM_CONVERSION_INTF

Interface data structure for Term Rounding - CPES_TERM_ROUNDING_INTF

b) Update record

This record specifies, which fields are considered. The fields to be inserted or updated are
marked with ‘X’:

Interface data update for Formula - CPES_FORMULA_INTFX

Interface data update for Term - CPES_TERM_INTFX

Interface data update for Price Fixation Option - CPES_PRCFIX_OPTION_INTFX

Interface data update for Price Fixation Exercise - CPES_PRCFIX_EXERCISE_INTFX

Interface data update for Term Period Determination - CPES_TERM_PERIODDET_INTFX

Interface data update for Term Surcharge - CPES_TERM_SURCHARGE_INTFX

Interface data update for Term Calculation - CPES_TERM_CALCULATION_INTFX

Interface data update for Formula Conversion - CPES_FORMULA_CONVERSION_INTFX

Interface data update for Formula Rounding - CPES_FORMULA_ROUNDING_INTFX

Interface data update for Term Conversion - CPES_TERM_CONVERSION_INTFX

Interface data update for Term Rounding - CPES_TERM_ROUNDING_INTFX

Besides this an update flag is included, which specifies what should happen to the corresponding
data record. The following three update flags are supported:

- ‘I’ stands for an insertion of a record

- ‘U’ stands for an update of a record
- ‘D’ stands for a deletion of a record (not supported for Formula, Term Period Determination,
Term Surcharge and Term Calculation, like on the CPE UI)

Remark:
It is optional to specify the fields for an insertion of a record. If no fields are marked in the
 update record, all maintained data values will be considered. For a deletion of a record, no field
has to be marked.

Both records have a common part containing key fields and non-key fields. The key fields must be
populated with the same key values. The non-key fields in the data record must be filled with data values
whereas these fields must be filled with an ‘X’ in the update record, in case they shall be updated:

CPES_FORMULA_INTF

KNUMV KPOSN COND_TYPE FORMID FIXFORMRATE_DF34

1000022781 10 CPSY CM_CPSY 103.45

CPES_FORMULA_INTFX

KNUMV KPOSN COND_TYPE FORMID FIXFORMRATE_DF34 UPDATEFLAG

1000022781 10 CPSY X X U

You can easily recognize the key and data fields of every CPE component in its update record:

Component Component Type

KNUMV Type KNUMV

KPOSN Type KPOSN

COND_TYPE Type KSCHL

FORMID Type BAPIUPDATE

FIXFORMRATE_DF34 Type BAPIUPDATE

… Type BAPIUPDATE

UPDATEFLAG TYPE CPET_UPDKZ

All data fields are placed after the key fields, and before the update flag field. Beside this, all data fields
have the component type BAPIUPDATE.

Remark:
To clear a field value, you must enter an ‘X’ in the BAPIUPDATE field of the update record, and
leave the field value blank in the corresponding data record.
After passing the CPE data to the CPE Interface you must call an appropriate logistics document BAPI to
process the document pricing. This will call the CPE evaluation using the transferred CPE component data
through the CPE interface.

You can use logistics document BAPIs for creation purposes:

CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'
EXPORTING
order_header_in = ls_order_header_in
IMPORTING
salesdocument = lv_order_no
TABLES
order_items_in = lt_order_items
order_schedules_in = lt_order_schedules_in
order_partners = lt_order_partner
return = return.

And, logistics document BAPIs for change purposes:

CALL FUNCTION 'BAPI_PO_CHANGE'
EXPORTING
purchaseorder = lv_order_no
TABLES
return = return.

The provided CPE interface data will be considered right before the evaluation of the corresponding CPE
condition in the document item takes place.

Remark:
By default, for every new CPE condition that is added to a new or existing document, the CPE
Formula Assembly is called first. This means that the corresponding formula, terms and further
dependent CPE objects are automatically determined by the system. All changes via CPE
interface to the CPE objects just created by the CPE Formula Assembly will be handled as
updates.

Therefore, an insert of a CPE object (e.g. formula or term) via CPE interface will only be required, if the
CPE formula assembly could not automatically determine such an object. Theoretically, a deletion of a
just created CPE object via Formula Assembly is also supported. The following examples visualizes this
aspect:

Creation/Change of a logistics document – Formula Assembly determines CPE objects

 1. BAPI logic creates / changes logistics document data

2. Pricing is called

3. Formula Assembly is called first for a new created CPE condition

o Formula is determined

o Terms are determined

4. CPE interface data provided by the consumer (before BAPI call) is processed at this step

o Provided Formula with an update flag = ‘U’ updates the Formula data determined by the
Formula Assembly

o Provided Terms with an update flag = ‘I’ are created in addition to the Terms determined
by the Formula Assembly

o Provided Terms with an update flag = ‘U’ update the Terms determined by the Formula
Assembly (The interface Term data must already specify the Term number that is
determined later by the Formula Assembly to update the correct Term)

o Provided Terms with an update flag = ‘D’ delete the Terms determined by the Formula
Assembly (The interface Term data must already specify the Term number that is
determined later by the Formula Assembly to delete the correct Term)

5. Formula Evaluation is called for the first time for the new created CPE condition already
considering the updated CPE data from the interface

Creation / Change of a logistics document - Formula Assembly determines no CPE objects

1. BAPI logic creates/changes logistics document data

2. Pricing is called

3. Formula Assembly is called first for a new created CPE condition

o No Formula and no Terms are determined

4. CPE interface data provided by the consumer (before BAPI call) is processed at this step
 o Provided Formula with an update flag = ‘I’ creates the missing Formula

o Provided Terms with an update flag = ‘I’ are created

o Provided Terms with an update flag = ‘U’ would lead to an error as no Terms have been
created so far for the new CPE condition

o Provided Terms with an update flag = ‘D’ would lead to an error as well as no Terms have
been created so far for the new CPE condition

5. Formula Evaluation is called for the first time for the new created CPE condition already
considering the updated CPE data from the interface

Keys of CPE Components

Every CPE component has its own key. As this interface method is called once per document, KNUMV
(Condition number), KPOSN (Condition item) and COND_TYPE (Condition type) have been included as
generic key in each CPE component. The following table keys will be used per CPE component:

Formula:

Component Component Type

KNUMV Type KNUMV

KPOSN Type KPOSN

COND_TYPE Type KSCHL

Since a formula object does not have a logical key, and since there is only one formula per CPE condition,
the generic key can simply be used to specify the formula object, which is intended for the update. For
new logistics documents KNUMV should be kept blank here.

Term:

Component Component Type

KNUMV Type KNUMV

KPOSN Type KPOSN

COND_TYPE Type KSCHL

TERM_SEQNO Type CPET_SEQNO

TERMNO Type CPET_TERMNO

The formula of a CPE condition of a document item can have several terms, which can be distinguished
with the key field TERMNO. But when a new Term shall be created via CPE interface you don’t specify
the new Term number for it as it will be determined automatically via CPE coding. This causes problems
when you create several new terms without specifying a term number. If there is no number specified
for a term, it is not possible to address this term explicitly. If there is more than one term without a term
number, you cannot link a CPE component, which depends on one term, to this specific term.

For this reason, we have introduced the temporary TERM_SEQNO key field for Terms and for all
dependent CPE components. This temporary key can be used instead of the TERMNO key field. As soon
as the actual Term number has been determined internally, all components with the same TERM_SEQNO
key field value will be assigned to this term as depended components.

Remark: It is not required but also not forbidden to use the TERM_SEQNO key field together with the
TERMNO key field. But at least TERM_SEQNO or TERMNO must be passed.

Price Fixation Option:

Component Component Type

KNUMV Type KNUMV

KPOSN Type KPOSN

COND_TYPE Type KSCHL

TERM_SEQNO Type CPET_SEQNO

TERMNO Type CPET_TERMNO

The Price Fixation Option has the same key as the Term. This is possible as there can only exist one Price
Fixation Option for each CPE Term. The key field TERM_SEQNO is only required when the parent Term is
created at the same time without a specified Term number.

Price Fixation Exercise:

Component Component Type

KNUMV Type KNUMV

KPOSN Type KPOSN

COND_TYPE Type KSCHL

TERM_SEQNO Type CPET_SEQNO

TERMNO Type CPET_TERMNO

FIXGRP_SEQNO Type CPET_SEQNO

FIXTERM_SEQNO Type CPET_SEQNO

FIXTERMNO Type CPET_TERMNO

Each Price Fixation Option can have several Price Fixation Exercises. These Price Fixation Exercises can be
differentiated by key field FIXTERMNO. But if a new Price Fixation Exercise shall be created via CPE
interface, you must not specify the new Fixation Term number for it as it will be determined
automatically via CPE coding.

If you create several Price Fixation Exercises without specifying a Fixation Term number, this will causes
problems. For the Allocation process it is important to create Price Fixation Exercises in the correct
sequence. Without a Fixation Term number, this sequence would be undefined.

For this reason, we have introduced the temporary FIXTERM_SEQNO key field for Price Fixation Exercises
(like the Terms’ approach) that allows the consumer to use it instead of the FIXTERMNO key field.

Remark:
It is not required but also not forbidden to use the FIXTERM_SEQNO key field together with the
FIXTERMNO key field for Price Fixation Exercise update. But at least the FIXTERM_SEQNO or the
FIXTERMNO must be passed.

For the agriculture scenario, the temporary field FIXGRP_SEQNO must be always filled. Within this field
you can also link several Price Fixation Exercises that belong to the same Price Fixation Group.

 See further info in the Price Fixation Exercise Groups chapter

Remark:
If you don’t specify the FIXGRP_SEQNO field, the Price Fixation Exercise to be inserted will be
created as a normal Price Fixation Exercise like for metal or oil scenarios.

Term Period Determination:

Component Component Type

KNUMV Type KNUMV

KPOSN Type KPOSN

COND_TYPE Type KSCHL

TERM_SEQNO Type CPET_SEQNO

TERMNO Type CPET_TERMNO

CPET_PERIOD_TYPE Type CPET_PERIODDET_TYPE

In addition to the same key as used for the Term, the field CPET_PERIOD_TYPE has been introduced with
two possible values which specify the type of the passed Term Period Determination record:

C - Currency

Q - Quotation

All other values are forbidden and would lead to an error.

Term Surcharge:

Component Component Type

KNUMV Type KNUMV

KPOSN Type KPOSN

COND_TYPE Type KSCHL

TERM_SEQNO Type CPET_SEQNO

TERMNO Type CPET_TERMNO

The Term Surcharge has the same key as the Term. This is possible as there can only exist one Term
Surcharge for each CPE Term. The key field TERM_SEQNO is only required when the parent Term is
created at the same time without a specified Term number.

Term Calculation:

Component Component Type

KNUMV Type KNUMV

KPOSN Type KPOSN

COND_TYPE Type KSCHL

TERM_SEQNO Type CPET_SEQNO

TERMNO Type CPET_TERMNO

The Term Calculation has the same key as the Term. This is possible as there can only exist one Term
Calculation for each CPE Term. The key field TERM_SEQNO is only required when the parent Term is
created at the same time without a specified Term number.
Formula Conversion:

Component Component Type

KNUMV Type KNUMV

KPOSN Type KPOSN

COND_TYPE Type KSCHL

CONVPLACE Type CPET_CONVPLACE

CURRFROM Type CPET_CURRFROM

UOMFROM Type CPET_UOMFROM

CURRTO Type CPET_CURRTO

UOMTO Type CPET_UOMTO

In addition to the same key as used for the Formula, several specific conversion fields have been
introduced. This allows to maintain records with different Conversion Places or even records with the
same Conversion Place for different currencies/units.

Formula Rounding:

Component Component Type

KNUMV Type KNUMV

KPOSN Type KPOSN

COND_TYPE Type KSCHL

CONVPLACE Type CPET_CONVPLACE

TERMGROUP Type CPET_TERMGROUP

In addition to the same key as used for the Formula, two specific rounding fields have been introduced.
This allows to maintain records with different Conversion Places or even records with the same
Conversion Place for different Term Group.
Term Conversion:

Component Component Type

KNUMV Type KNUMV

KPOSN Type KPOSN

COND_TYPE Type KSCHL

TERM_SEQNO Type CPET_SEQNO

TERMNO Type CPET_TERMNO

CONVPLACE Type CPET_CONVPLACE

CURRFROM Type CPET_CURRFROM

UOMFROM Type CPET_UOMFROM

CURRTO Type CPET_CURRTO

UOMTO Type CPET_UOMTO

In addition to the same key as used for the term, several specific conversion fields have been introduced.
This allows to maintain records with different Conversion Places or even records with the same
Conversion Place for different currencies/units.

Term Rounding:

Component Component Type

KNUMV Type KNUMV

KPOSN Type KPOSN

COND_TYPE Type KSCHL

TERM_SEQNO Type CPET_SEQNO

TERMNO Type CPET_TERMNO

CONVPLACE Type CPET_CONVPLACE

In addition to the same key as used for the term, one specific rounding field has been introduced. This
allows to maintain records with different conversion places.
Price Fixation Exercise Groups

In the agriculture scenario, instead of normal Price Fixations, Price Fixation Groups can be created
containing a Future Price Fixation, Primary Basis Price Fixation and, optionally, one or more Secondary
Price Fixations.

There are two approaches for creating Price Fixation Groups:

1. Customizing approach

The relevant conditions for the Price Fixation Group are determined by the customizing settings
of a Pricing Procedure:

Purchasing side:

MCPE_WB  Customizing  Commodity Pricing Engine  Application Specific CPE Settings 

Assign Fixation-Relevant Conditions to Price Fixation Groups

Application Procedure Cond. Type Price Fixation Group

M CMSY01 CBSY (Primary Basis) CM_SOY

M CMSY01 CPSY (Future) CM_SOY

Sales side:

VCPE_WB  Complete Customizing  Commodity Pricing Engine  Application Specific CPE

Settings  Assign Fixation-Relevant Conditions to Price Fixation Groups

Application Procedure Cond. Type Price Fixation Group

V CMSY01 CBSY (Primary Basis) CM_SOY

V CMSY01 CPSY (Future) CM_SOY
V CMSY01 CTSY (Secondary Basis) CM_SOY

Remark:
Only one Future Condition and one Primary Basis condition must be included in a Price Fixation
Group, otherwise no (meaningful) Price Fixation Group can or will be created.
 2. Manual approach

The relevant conditions are determined on the fly by the corresponding pricing procedure used
in the logistics document. The system tries to find a Future condition, a Primary Basis condition,
and one or more Secondary Basis conditions.

Remark:
The manual approach is only used when no customizing entries exist for the Pricing Procedure
used in the logistics document.

Handling of Price Fixation Groups via Interface

Prerequisite for the handling of Price Fixation Groups is the usage of the temporary field FIXGRP_SEQNO
in the Price Fixation Exercise record. If a field number is used in more than one record this means that
the Price Fixation Exercises belong to the same Price Fixation Group.

When creating Price Fixation Groups, and if not all Price Fixations of one Price Fixation Groups are
provided via the interface, the system will recognize this fact and will create the whole Price Fixation
Group in the background.

There is one use case for which the specification of the temporary field FIXGRP_SEQNO is not sufficient
for the system to recognize the corresponding Price Fixation Group of the provided Price Fixation. This is
the case when we have an already existing Price Fixation Group and want to update it with an insert of
an additional Price Fixation, e.g. NBE  FLAT or NPE with fixed Exchange Rate  NFE etc.

In such a case we need also to specify the reference fields in the new Price Fixation Exercise data record.
These fields point out to an already existing Price Fixation Exercise of the Price Fixation Group we want
to update:

Component Component Type

REF_COND_TYPE Type KSCHL

REF_TERMNO Type CPET_TERMNO

REF_FIXTERMNO Type CPET_TERMNO

Remark: In case we want to update an existing Price Fixation Group with an insert of two or more new
Price Fixations at once, we need to use the same existing Price Fixation Exercise as reference.
Field Configuration

The CPE interface allows a you to create/update/delete CPE data. For example, you can make changes on
an an existing document without using the common UI.

On the UI, you do not have the possibility to change arbitrary data. Which fields are editable, is
controlled by the field configuration.

Analogous to the behavior on the UI, the field configuration table is decisive for which fields can be
changed via the interface. To check whether fields are changeable or not beforehand, you can call the
GET_DATA method to receive the current field modes (Have a look at the chapter ‘GET DATA’).

GET DATA

In order to get the current status of the CPE data on the database, you can call the GET_DATA method.
Similar to the data structures of the SET_DATA method, the output data is presented object by object.
In addition, you can request output tables which give you the current field modes of all relevant fields.
The field modes specify whether fields are required fields (2) or ready for input (1), read-only fields (3) or
invisible fields (4). These field modes are decisive for which fields can be changed via the interface (See
chapter Field Configuration). Since the field modes can depend on specific field values, the output tables
represent only the current status.

You will receive the exporting structures:

Data Field Modes

ET_FORMULA ET_FORMULA_FIELDCONFIG_DATA

ET_TERM ET_TERM_FIELDCONFIG_DATA

ET_PRCFIX_OPTION ET_PRCFIX_OPT_FIELDCONFIG_DATA

ET_PRCFIX_EXERCISE ET_PRCFIX_EXC_FIELDCONFIG_DATA

ET_TERM_PERIODDET ET_T_PERIODDET_FIELDC_DATA

ET_TERM_CALCULATION -

ET_TERM_SURCHARGE -

ET_FORMULA_CONVERSION ET_F_CONVERSION_FIELDC_DATA

ET_FORMULA_ROUNDING ET_F_ROUNDING_FIELDC_DATA

ET_TERM_CONVERSION ET_T_CONVERSION_FIELDC_DATA

ET_TERM_ROUNDING ET_T_ROUNDING_FIELDC_DATA
Use Cases

Formula

Delete Condition or Formula: Creation or deletion of CPE conditions is not supported by this interface as
this functionality has already been provided by every relevant document BAPI, which can handle
standard conditions. The deletion of a CPE Formula without deletion of the condition itself would always
lead to a fatal error and is not allowed. You would have to delete the whole condition via the standard
BAPI, which would implicitly delete the formula as well.

Example record:
Change the Formula rate from fixed to unfixed

LS_FORMULA LS_FORMULAX
KNUMV = ‘<KNUMV>’ KNUMV = ‘<KNUMV>’
KPOSN = ‘<KPOSN>’ KPOSN = ‘<KPOSN>’
COND_TYPE = ‘<Future Condition Type>’ COND_TYPE = ‘<Future Condition Type>’
FIXFORMRATE_DF34 = abap_true
FIXFORMCURR = abap_true
FIXFORMPRUN = abap_true
FIXFORMUOM = abap_true
UPDATEFLAG = ‘U’

Term

A term can be added to a formula, attributes of an existing term can be changed, and an existing term
can be deleted.

The term ID and dependent data can be changed in one step. For example, the Period Determination
Rule is dependent on the Term ID.

Example record:
Change Term by passing the Term ID and a dependent field value

LS_TERM LS_TERMX
KNUMV = ‘<KNUMV>’ KNUMV = ‘<KNUMV>’
KPOSN = ‘<KPOSN>’ KPOSN = ‘<KPOSN>’
COND_TYPE = ‘<Future Condition Type>’ COND_TYPE = ‘<Future Condition Type>’
TERMNO = ‘1’ TERMNO = ‘1’
TERMID = ‘<TERMID>’ TERMID = abap_true
PERDETRULE_Q = ‘1’ PERDETRULE = abap_true
UPDATEFLAG = ‘U’

All data dependent on the Term ID will be determined based on the specified <TERMID>. The Period
Determination Rule will then be switched to the passed PERDETRULE_Q.
Price Fixation Option

Depending on the customizing settings, a Price Fixation Option is created automatically for a term. If it is
not created automatically, it can be manually created using the CPE Interface. Changes can be done for
an existing Price Fixation Option.

Example record:
Create Price Fixation Option

LS_PRCFIX_OPTION LS_PRCFIX_OPTIONX
KNUMV = ‘<KNUMV>’ KNUMV = ‘<KNUMV>’
KPOSN = ‘<KPOSN>’ KPOSN = ‘<KPOSN>’
COND_TYPE = ‘<Future Condition Type>’ COND_TYPE = ‘<Future Condition Type>’
TERMNO = ‘1’ TERMNO = ‘1’
EXER_DATE_LATEST_ROUT = 1 UPDATEFLAG = ‘I’
LIMIT_FACTOR1 = 1
LIMIT_FACTOR2 = 2
LIMIT_ROUT = 2
PRICE_REF_ROUT = 1
QUANTITY_DISTR_ROUT = 100000

Example record:
Change Price Fixation Option – Add Option Comment

LS_PRCFIX_OPTION LS_PRCFIX_OPTIONX
KNUMV = ‘<KNUMV>’ KNUMV = ‘<KNUMV>’
KPOSN = ‘<KPOSN>’ KPOSN = ‘<KPOSN>’
COND_TYPE = ‘<Future Condition Type>’ COND_TYPE = ‘<Future Condition Type>’
TERMNO = ‘1’ TERMNO = ‘1’
OPTION_COMMENT = ‘Creation of PrcFix Option’ OPTION_COMMENT = abap_true
UPDATEFLAG = ‘U’
Price Fixation Exercise

Future/Basis Handling: The creation of a Price Fixation Group always requires data records with the
specified FIXGRP_SEQNO field.

Creation: An arbitrary Price Fixation Group can be created. In case the created Price Fixations shall
belong to the same Price Fixation Group, the same value must be used in the field FIXGRP_SEQNO.

Example record:
Create NBE

LS_PRCFIX_EXERCISE LS_PRCFIX_EXERCISEX
KNUMV = ‘<KNUMV>’ KNUMV = ‘<KNUMV>’
KPOSN = ‘<KPOSN>’ KPOSN = ‘<KPOSN>’
COND_TYPE = ‘<Future Condition Type>’ COND_TYPE = ‘<Future Condition Type>’
TERMNO = ‘1’ TERMNO = ‘1’
FIXGRP_SEQNO = ‘1’ FIXGRP_SEQNO = ‘1’
FIXTERM_SEQNO = ‘1’ FIXTERM_SEQNO = ‘1’
FIXTERMRATE_DF34 = ’99,99’ UPDATEFLAG = ‘I’
FIXTERMCURR = ‘USD’
FIXTERMPRUN = ‘1’
FIXTERMUOM = ’TO’
TERMCOMMQUAN = ‘100’
TERMCOMMUOM = ‘TO’
KEYDATE = ‘20181031’
DCSID = ‘<DCSID>’
MIC = ‘<MIC>’

Rolling: The Maturity Key Date can be changed for a NBE, NFE or an NPE Group at any time.

Example record:
Change Key Date of NFE group

LS_PRCFIX_EXERCISE LS_PRCFIX_EXERCISEX
KNUMV = ‘<KNUMV>’ KNUMV = ‘<KNUMV>’
KPOSN = ‘<KPOSN>’ KPOSN = ‘<KPOSN>’
COND_TYPE = ‘<Basis Condition Type>’ COND_TYPE = ‘<Future Condition Type>’
TERMNO = ‘1’ TERMNO = ‘1’
FIXGRP_SEQNO = ‘1’ FIXGRP_SEQNO = ‘1’
FIXTERMNO = ‘4’ FIXTERMNO = ‘4’
KEYDATE = ‘20181031’ KEYDATE = abap_true
UPDATEFLAG = ‘U’
Upgrade: An NBE or NFE Price Fixation Group can be upgraded to a FLAT group with the insert of one
Price Fixation Exercise – one Price Fixation Group component. The reference fields must be specified to
point out to the correct existing Price Fixation Group.

Example record:
Change NBE to FLAT

LS_PRCFIX_EXERCISE LS_PRCFIX_EXERCISEX
KNUMV = ‘<KNUMV>’ KNUMV = ‘<KNUMV>’
KPOSN = ‘<KPOSN>’ KPOSN = ‘<KPOSN>’
COND_TYPE = ‘<Basis Condition Type>’ COND_TYPE = ‘<Basis Condition Type>’
TERMNO = ‘1’ TERMNO = ‘1’
FIXGRP_SEQNO = ‘1’ FIXGRP_SEQNO = ‘1’
FIXTERM_SEQNO = ‘1’ FIXTERM_SEQNO = ’1’
FIXTERMRATE_DF34 = ‘2.15’ UPDATEFLAG = ‘I’
FIXTERMCURR = ‘USD’
FIXTERMPRUN = ‘1’
FIXTERMUOM = ’TO’
TERMCOMMQUAN = ‘100’
TERMCOMMUOM = ‘TO’
REF_COND_TYPE = ‘<Future Condition Type>’
REF_TERMNO = ‘1’
REF_FIXTERMNO = ‘4’

Remark: In case a Fixed Exchange Rate has already been set for the ‘missing’ Price Fixation Group
component, an update with UPDATEFLAG = ‘U’ and the Fixed Rate to be set should be used instead.

Remove: A FLAT Price Fixation Group can be retransformed to a NBE or a NFE group with the update of
one Price Fixation Exercise – one Price Fixation Group component.

Example record:
Change FLAT to NBE

LS_PRCFIX_EXERCISE LS_PRCFIX_EXERCISEX
KNUMV = ‘<KNUMV>’ KNUMV = ‘<KNUMV>’
KPOSN = ‘<KPOSN>’ KPOSN = ‘<KPOSN>’
COND_TYPE = ‘<Basis Condition Type>’ COND_TYPE = ‘<Basis Condition Type>’
TERMNO = ‘1’ TERMNO = ‘1’
FIXGRP_SEQNO = ‘1’ FIXGRP_SEQNO = ‘1’
FIXTERMNO = ‘4’ FIXTERMNO = ’4’
FIXTERMRATE_DF34 = ‘0’. FIXTERMRATE_DF34 = abap_true
UPDATEFLAG = ‘U’

Remark: Remove should be used, if you want to keep one or more Price Fixation Group components. To
get rid of the entire Group, all Group components should be deleted with UPDATEFLAG = ‘D’.