LSMW idoc method for uploading condition records using COND_A IN
@Sisn
https://youtu.be/cjx2mlyhI_U
Download PDF :
https://icedrive.net/s/APyBWPS1tfDC5XRWt6wgj4DwAWhV
1 IDocs and Condition Technology
1.1 Overview of Condition Technology
The condition type shows what type of condition it is; price, surcharge, or discount in value or percentage or values.
The pricing procedure specifies the sequence in which the condition types are used for determining prices and the rules used to determine prices.
The access sequence is defined in the condition type and determines the sequence in which the system searches for valid entries in the condition tables. You can carry out a special search (here, for customer and material) or a more general search (for material group).
The condition table represents the validity periods for the individual condition records You can link to the condition records using a single condition record number (KNUMH).
The following are condition records:
KONH: Condition header
KONP: Condition items, possibly with supplementary conditions
KONM/KONW: Quantity scale or value scale
1.2 Structure of an IDoc
E1KOMG Filter functions (1:obligatory)
E1KONH Condition header (n:obligatory)
E1KONP Condition item (m:obligatory)
E1KONM Quantity scale (i:optional)
E1KONW Value scale (j:optional)
E1KONH
E1KONP Condition item (m:obligatory)
All condition records are combined in an IDoc, which fulfills specific criteria.
Application + Condition type + Condition table + VAKEY
The Konh blocks are the individual validity periods in a logical unit.
1.3 Terms
IDoc type
COND_A01 determines the hierarchical structure of an IDoc for price/condition interchange.
IDocs
IDocs and their segments are assigned to the IDoc type.
Output category
COND_A is assigned to the IDoc type. Reduced output categories from the customer are possible.
Reduction option
Individual fields from the IDoc segments can be reduced. This means that they can be transferred without data. Reduced output categories from the customer can be created that reference the IDoc type COND_A01. The reduction option is planned at segment and field level. Whole IDoc segments can be excluded from the transfer.
2 Migration of Data with LSMW
Use
You can use LSNW if the source structures are simple. You can also use it if the legacy system contains more complex structures.
Prerequisites
A comparison of functions between the legacy system and the SAP system must have been carried out. The data to be migrated is determined from this comparison.
Process
LSMW supports a step-by-step procedure. On the List of Steps screen, the next step is automatically displayed for each step.
3 Description of the Project
Use
Your work with LSMW starts with the definition of the project as a unit of the data to be migrated.
Process
1. You create the project from which you want to migrate data in the LSMW:
If Then
The mapping and field assignments for a project are available in an SAP system (for example, test system). You export them from this system and import them into your SAP system. See Exporting a Project and
Importing a Project
The mapping and field assignments for a project have been stored on a data carrier. You import them into your SAP System.
You want to migrate data from your legacy system for the first time. You define the project.
2. You define the subproject for a project or make it known to the LSMW by importing the mapping and field assignments (see above).
Result
The project and subproject have been defined. Now you define the (business) object.
More Information
• Editing Projects
• Editing a Subproject
• Edit object
• Maintaining Object Attributes
• Where-Used List
The following basic steps are included in the LSMW:
1. Maintaining Object Attributes: Here, you define the project, subproject and the required (business) object. If a suitable SAP standard import program is not available, you can use the recording function to create a user-specific, new object.
2. Maintaining Source Structures
3. Maintaining Source Fields
4. Maintaining Structure Relationships: In these steps, you define the structures and fields of the project. These describe the transfer file and must have the same format in the export program. You then relate the structures and fields of the SAP system to those of the project.
5. Maintaining Field Mapping and Conversion Rules
THE VAKEY MUST BE populated with any value , which is a combination of :
LIFNR matnr EKORG WERKS ESOKZ FOR PIR WITH PLANT
* Target Field: E1KOMG-VAKEY Variable key 50 bytes
call function 'CONVERSION_EXIT_ALPHA_INPUT'
exporting
input = ZA017-LIFNR
IMPORTING
OUTPUT = ZA017-LIFNR.
data gv_matnr type matnr.
call function 'CONVERSION_EXIT_ALPHA_INPUT'
exporting
input = ZA017-MATNR
IMPORTING
OUTPUT = gv_matnr.
CONCATENATE ZA017-LIFNR gv_matnr ZA017-EKORG ZA017-WERKS ZA017-E
INTO E1KOMG-VAKEY RESPECTING BLANKS.
Constant
E1KOMG-KVEWE = 'A'.
Condition table
Constant
E1KOMG-KOTABNR = '017'.
Application
Constant
E1KOMG-KAPPL = 'M'.
Condition type
6. Maintaining Fixed Values, Conversions and User-Defined Routines: Here, you define the conversion rules for processing project data. The system generates the conversion program from the structure and field relationships as well as the conversion rules. You then perform Migration Customizing. That is, you assign values to the fixed values and translation values and specify the definite variants for the conversion rules.
7. Specifying Files
8. Assigning Files
9. Importing Data
10. Displaying Imported Data
11. Converting Data
12. Displaying Converted Data
13. Starting IDoc Generation
14. Starting IDoc Processing
15. Creating an IDoc Overview
16. Starting IDoc-Postprocessing: The converted data is transferred to the SAP system. The import technique or method has already been assigned to the object by selecting the object type in the first step.
Result
The data from the legacy system has been imported into the SAP database. Any subsequent processes result from the type of datasets migrated.
More Information
• Description of the Project
• Definition of Source Structures and Fields
• Editing Field Assignments
• Data Import
• Special Case: Migration of Long Texts
• Periodic Data Transfer