Easy and efficient way of uploading pricing conditions in SAP system using a single exclusively

designed program
Follow
Introduction
In order to upload pricing conditions in SAP system, we need to create a conversion program which caters to
all condition tables and uploads the respective data. Now since all condition tables have different
structures/key fields/fields, the BDC approach can’t solve the problem unless we do recordings for all
Condition Types. Also in case a new condition type is added, then we need to add a new recording to the code,
which increases the development/maintenance hours.
Each time pricing conditions need to be uploaded in the SAP system, a technical resource is required to create
a conversion program which uploads the data into the system. This tool helps in uploading the pricing
conditions for SD and MM module, thereby eliminating any multiple manual intervention.

Solution Details
As the requirement is to upload any condition table, we have to design a solution which caters to all condition
type uploads.
So in order to make it generic for all condition types, we would be expecting the Condition Table name to be as
a part of upload fields. Now using this Table Name, we would fetch the schema of corresponding Condition
Table and map fields dynamically. Also we would be using the Conversion Exits on the various field values
using the field information returned for each table.
For example, say the condition table name coming in upload file is A652. We will use FM
“CATSXT_GET_DDIC_FIELDINFO” to the details for table fields. As a result from this FM, we will get all the fields
with their attributes like:-
Key Flag (denotes whether the field is a part of Primary Key or not)
Domain Name
Data Element Name
Check Table Name
Length
Field Labels
Conversion Exit, etc..
The basic common fields in upload structure can be:-
KAPPL (Application)
KSCHL (Condition Type)
TABLE (Condition Table Name)
Now the point lies how we map the data from file to different condition tables, as each table has a different
structure and also varying in number of fields.
Since any Database Table can have only 16 fields (max) as a part of Primary Keys. And there are 5 fields which
are common in all A* tables:-
MANDT (Client)
KAPPL (Application)
KSCHL (Condition type)
KFRST (Release status)
DATBI (Validity end date of the condition record)
So remaining number of key fields left are 11 (16 – 5), now the upload structure of the file would have 11 fields
as floating/generic value. So we keep FLD1-FLD11 of type FIELDNAME (Char 30).
The other fields in the upload file structure (common to all condition types) are:-
DATAB (Start Date of Condition Record)
DATBI (End Date of Condition Record)
KBETR (Condition Value)
KPEIN (Condition Price Unit)
MEINS (Unit of Measurement)
KRECH (Calculation Type for Condition)
So the final upload structure is:-
Field Names Data Type Description
KAPPL KAPPL Application
KSCHL KSCHL Condition Type
TABLE TABNAME Table Name
FLD1 FIELDNAME Field Name
FLD2 FIELDNAME Field Name
FLD3 FIELDNAME Field Name
FLD4 FIELDNAME Field Name
FLD5 FIELDNAME Field Name
FLD6 FIELDNAME Field Name
FLD7 FIELDNAME Field Name
FLD8 FIELDNAME Field Name
FLD9 FIELDNAME Field Name
FLD10 FIELDNAME Field Name
FLD11 FIELDNAME Field Name
DATAB KODATAB Validity start date of the condition record
DATBI KODATBI Validity end date of the condition record
KBETR KBETR_KOND Rate (condition amount or percentage) where no scale exists
KPEIN KPEIN Condition pricing unit
MEINS MEINS Base Unit of Measure
KRECH KRECH Calculation type for condition

Now since in every A* table first 3 key fields are:-

MANDT
KAPPL
KSCHL
(NOTE: other 2 fields KFRST and DATBI are the last 2 key fields)
And first 3 fields in upload file are:-
KAPPL
KSCHL
TABLE
So rest of the key fields from A* table would be mapped to upload file fields FLD1-FLD11 based on the number
of primary keys. Thus we will start mapping from field 4 of condition table to FLD1, FLD2 and so on till FLD11,
based on the number of key fields.
In case we have 3 more key fields (excluding 5 common key fields), then in the upload file we will have values
in fields FLD1, FLD2 and FLD3. In case any other field has a value, then it is an erroneous data, and nor these 3
fields can be blank (as they are part of primary keys).

For instance, let consider the table A652 (refer the snapshot in attachments)
The mapping of upload file to Condition Table would be like:-
1. FLD1 –> VBELN
2. FLD2 –> MATNR
3. FLD3 –> VRKME
4. FLD4 -to- FLD11 would remain as blank.
Also the data coming in these fields should be in continuous chain.
For instance if FLD1, FLD2 and FLD4 has values and FLD3 is initial, then also this record is erroneous.
1. In case of the above erroneous situation, an error message “Discontinuity in Variable Key Fields” is
appended.
2. Validate the Processing Status from table T686E. In case no valid record found then append an error
message “Invalid Processing status for conditions”.
3. Now using the field information returned from FM “CATSXT_GET_DDIC_FIELDINFO”, check if any
Conversion Exit is applicable, and then use the value coming in the upload file field and apply the same to
convert the value and then we can pass this to IDoc structures. In case any error occurs then append message
coming from the Conversion Exit.
4. Check if the field is present in Segment
E1KOMG,
E1KONH, and
E1KONP
If field is found in the segment, then pass the value in the segment(s).
5. Also concatenate the key field values in a string called Variable Key.
6. After all key fields are covered with the above steps specified; then check for the length of the field. If
field length is greater than 100, append a message “Variable Key too big”.
7. Get the Logical System Name from table T000 where Client = SY-MANDT. In case no record found then
append an error message “No Partner Function Found”.
8. Concatenate ‘SAP’ SY-SYSID to form the Port Number.
9. In case no error is found till now and test run is not requested, then populate the IDoc Segments.
a. Pass Control Records
Pass the Sender and Receiver Information.
IDoc Type as COND_A04
Message Type as COND_A
Basic Type as COND_A04
Direction as Inbound
b. Pass Data Records
Now pass the above prepared data into segments
E1KOMG
Application
Condition Type
Variable Key
Region
E1KONH
Start Date
End Date
E1KONP
Condition Type
Condition Value
Condition Unit
Condition Price Unit
Calculation Type for Condition
c. DIRECT POST – Post the data using FM “IDOC_INPUT_COND_A”
Pass all the above prepared data into the FM.
If some error is returned, then append the same.
If no error found, and data is successfully posted then check for Status as 53. If found, append a success
message “Changes done successfully”
d. IDOC POST – Post the data using FM “IDOC_INBOUND_WRITE_TO_DB”
Pass the data records into the FM.
If some error returned from FM, then append the same in the log, to be displayed to the user. If no error
found, Commit Work and append message “Idoc successfully posted:” with the IDOC number.

Business benefits
The above explained approach will upload all the relevant condition records in to the SAP system for SD and
MM module using the iDoc approach (which is faster as compared to using BDC’s or LSMW’s).
The only thing which is crucial for using this tool is to understand the mapping of condition table with the
upload file format. Once the mapping is done and a Tab Delimited Text file is provided to this program, it
uploads the data in the desired tables; and thereby saving around 80% of estimated time. For instance, the
general effort spent in developing the conversion program is 40 hours -versus- 8 hours spent in using this tool.

In addition, no maintenance is required in case any other change request is to be catered.

Thus this solution minimizes:
The functional effort of manually entering conditions records one by one.
The technical effort of developing conversion program using BDC’s for different condition tables. The number
of these conversion program can vary depending upon the conditions to be uploaded.
The maintenance effort required as and when new condition types are added.

you can use FM IDOC_INPUT_COND_A

you could also check report RV14BTCI.

For pricing conditions you will be having the condition type and table name in the
first screen of the VK11 transaction.
In the second screen of VK11 you can see the fields will be varing based up on the
table name you are specifying the first screen.
You can use field VAKEY in the batch input program to pass all the values.
For example:
Your table name A601 contians three fields mentioned below.Leave the fields such as
KAPPL,KSCHL,DATBI,DATAB,KBSTAT,KNUMH since these will be avialble for all the tables.
the rest varing fields are
VKORG VKORG CHAR 4
VTWEG VTWEG CHAR 2
SPART SPART CHAR 2
KUNNR KUNNR_V CHAR 10
KONDA KONDA_V CHAR 2
MATNR MATNR CHAR 18
KFRST KFRST CHAR 1
You need to pass the value of all the fields to the VAKEY in the batch input program.
using offset option mentioned below.
VAKEY+0(4) = source-vkorg.
VAKEY+4(2) = source-vkorg.
VAKEY+6(2) = source-vkorg.
VAKEY+8(10) = source-vkorg.
VAKEY+18(18) = source-vkorg.
VAKEY+ 36(1) = source-vkorg.

CONDITION_RECORD_READ
BAPI_PRICES_CONDITIONS
CONDITION_RECORD_READ