Author Archives: jiteshdua

SAP Activate Methodology

Discover Phase:

The Discover phase is where the customer realises there is a need for a solution to satisfy their business pain point and starts looking out for the right SAP solution to map their requirements. During this phase, customers can apply for a free trial solution if applicable and try it out for themselves to check the features and functionalities of the solution. Customers can even reach out to partners like iQuantM to get the best consulting advise based on years of industry and SAP product experience to find the best solution. By the end of this phase, customers finalize to go ahead with the required SAP solution and move to the next phase in their implementation lifecycle.

Prepare Phase:

As the name suggests, this phase is crucial to both customers and partners as key activities that are crucial to the success of the project are completed with mutual consent. The system is provisioned to the customer post-signing of the contract with SAP and the partner. Simultaneously, key resources are identified from the partner side in terms of the SAP Consultants getting onboarded and enabled. From the customer side, business process owners are identified to provide the right requirements to the consultants implementing the project. A high-level project plan along with roles and responsibilities is finalised along with the project team, project governance procedure and escalation matrix and the project is ready to kick-off!

During this phase, an initial level of requirement is already collected when the business process owners fill in the Business-Driven Configuration Assessment questionnaire. This is a readily available document for the project team that can be downloaded and used to fasten the project delivery. Based on the answers obtained from the assessment, consultants need to plan for the next and probably most important phase of the SAP Activate Methodology – the Explore Phase.

Explore Phase:

The Explore Phase pretty much lays the foundation for the success of the project. In this phase, customers and partners collaborate with each other for 1 outcome – to finalize the business process to be followed in the new SAP system. This is done by a series of “Fit-to-Standard Analysis” sessions, where the SAP Best Practice business process flow is showcased to the Business Process Owner. Consultants first display a flowchart of the business process and later drive a demo of the same using the initial system that was provisioned to them. The project team then have a healthy discussion on how the business can map their business to the best practices. This is the usual process when it comes to SAP S/4HANA Public Cloud, otherwise known as SAP S/4HANA Cloud, Multi-tenant Edition. For the SAP S/4HANA business suite and SAP S/4HANA Private Cloud otherwise known as SAP S/4HANA Cloud, Single-tenant Edition, there is an additional “Fit-to-Gap Analysis” session where, additional requirements of the business can be noted and later mapped to the SAP system based on feasibility.

Another major point that SAP Activate has made easier for consultants is the standard migration templates that are readily available to download. This comes as a point of relief, especially for consultants who otherwise used to spend a lot of time coming up with a migration template to help the business fill in the information that is required to be migrated to the new system. This helps the project team save an immense amount of time and the business finds it comfortable to fill in the required information as advised by SAP. The business users are enabled on the migration templates and they can now internally start working on data consolidation, cleansing, and formatting to be filled into the standard migration templates. This comes as a huge relief to both the customer and partner project teams as working on data is arguable one of the most difficult portions of a project!

One of the best parts of the explore phase is the “Customer Execution of Standard Processes”. What SAP Activate tries to achieve is to build an early relationship between the end-users and the SAP system for an easier and accelerated adoption of widely accepted business processes. Consultants provide the business users with the documents required and help them run an end-to-end cycle in the SAP system. The previously self-enabled business is now familiar with the system and provides their concurrence that they have executed the business process in the system. They are provided with their own user access to explore and get familiarised with the system. This is great, especially in the initial stages of the project because this helps for an easier UAT in the next phase of the project.

All of the customer’s requirements in terms of additional WRICEF objects – Workflows, Reports, Integrations, Conversions, Enhancements and Forms along with the configuration values are noted in the Backlog document provided by SAP which is then signed off to signed off mutually between the partner and the customer. This backlog document consists of all the customer-specific requirements that need to be available in the SAP system for the business users to perform their daily tasks. Consultants then prioritize according to feasibility, difficulty and importance and plan the sprints for the Realize Phase where the primary aim is to close each of the Backlog items one by one.

A change impact analysis is done to understand how the new system will benefit the business and actions to enable a smooth transition to the new system are decided among the stakeholders of the project. Key users are identified and an end-user learning needs analysis is done and a learning plan is prepared for the key users who will help drive the success of the system during the duration of the project.

Realize Phase:

Once the Explore Phase deliverables are signed off, the project team can start working on the Quality system provisioned by SAP. In this phase, the SAP consultants start configuring the SAP system according to the Backlog document that is signed off. This happens in an iterative approach where the project team works based on multiple sprints that have been planned to execute the project by breaking down the backlog requirements into smaller deliverables that need to be showcased to the business process owner and signed off as completed once it matches the agreed-upon completion criteria. This is the phase where consultants are in regular touch with the business process owner to showcase to them, the SAP system they are building through multiple Solution Walkthrough’s that are scheduled through the Realize Phase.

The technical teamwork on completed the WRICEF objects that were noted in the Backlog document during this phase and work hand in hand with the SAP functional consultants and business users to ensure the custom objects are delivered with quality within the timeline.

User Roles and Authorizations can be a hectic process to finalize on, especially in large projects. For the same, SAP has provided us with standard persona-based roles that help the business users with their tasks through an End-to-End business process. For example, a maintenance technician will be provided with standard roles required for a maintenance technician in the SAP system and a maintenance manager will be provided with the standard role enabling him to perform his tasks as per the best practice in the SAP system.

In this phase, multiple levels of testing such as Unit Testing, String Testing, Integration Testing and User Acceptance Testing is performed to ensure the SAP system is configured according to the customer requirements provided by the business process owners. Data migration testing is also done to ensure the data filled in by the business users are in the correct format and ready to import to the brand-new SAP system.

Once all the deliverables are satisfied, a cutover plan is made to move the configurations, WRICEF objects and master and transactional data to the Production system which will be the system used by the business in real-time. This signifies the end of the Realize Phase.

Deploy Phase:

In the Deploy Phase, once every checkbox is ticked and everything is ready, the business faces a temporary downtime as the new SAP system is Deployed for usage to the business users. This is typically done during a weekend to ensure that customers have little to no effect due to the downtime. The cutover is a process that sometimes gives consultants sleepless nights as this is the culmination of all their hard work being moved into the SAP system for the usage of an entire organisation.

Once the cutover is done successfully and checked by the partner and the customer, the business users are supported by the consultants and the key users who now form the first line of defence in case users have doubts or face an issue. The customers and partners can now relish the success of the project through an intense time filled with dedication and hard work from all stakeholders involved.

Run Phase:

The Run Phase signifies the end of the customer’s lifecycle from identifying a solution for their business need to finally implement the solution and running their business process on the same. In the Run Phase, the customer project team are given only 1 task – to be updated with the latest innovation and technologies in SAP, especially in the product they have implemented by having a “Continuous Learning” to keep up with the pace of technology.

SAP Activate has matured to be a great methodology to be used for SAP S/4HANA implementation and conversion projects. Everyone who has been in a project knows how difficult it is to carry the torch from the start to the finish line. SAP Activate has really helped project managers and consultants across the globe complete projects successfully at a much faster rate. Despite the COVID-19 pandemic, numerous customers have successfully gone live with SAP solutions using the SAP Activate Methodology.

For more information on SAP Activate and how it should be used to successfully implement an SAP solution. You can find some important links for Project Managers, Consultants and End Users below:

SAP Roadmap Viewer – https://go.support.sap.com/roadmapviewer/
SAP Best Practice Explorer – https://rapid.sap.com/bp/
SAP Activate JAM Community – http://bit.ly/SAPActivate

Shipment Process

5 Replies

Shipment Process –

Step #	Tcode	Description
Step 1	VA01	Create Sales Order
Step 2	VL10G	Create Delivery Note
Step 3	VT01N	Create Shipment
Step 4	VL02N	Post Goods Issue
Step 5	VI01	Create Shipment Cost Document
Step 6	VI02	Transfer Shipment Cost Document
Step 7	VF01	Create Billing
Step 8	MIRO	Invoice Verification for shipment

SAP Notes –

662859

716013

740854

748028

User-Exits:

V54B0001 Shipment Costing: Configure pricing

V54B0003 Shipment Costs Calculation: Determine Rate Type and Currency

V54B0004 Shipment Costs Calculation: Determine Status

V54C0001 Shipment Costing: Description(s) shipment cost item(s)

V54C0002 Shipment Costing: Create shipment cost sub-items

V54C0003 Shipment Costs Processing: Determine Invoicing Party

V54C0004 Shipment Costs Processing: Determine Loc. for Tax Invoice

V54D0001 Shipment Costing: Determining the Tax Countries

V54KSFRC Determining the factors for apportionment of shipment costs

V54P0001 Extended Function Codes for Shipment Cost Information

V54U0001 Shipment Cost processing: Check whether changes made

V54U0002 Check shipment costs for completion

V54U0003 Specification of shipment cost number

V54U0004 Formatting for update of new objects (shipment costs)

V54U0005 Updating new objects in shipment cost processing

V54U0006 Shipment Purchase Order – Header Data Supply

V54U0007 Shipment Purchase Order – Item Data Supply

BADIs:

BADI_SCD_ACCTG Call During Shipment Cost Account Assignment

BADI_SCD_CREATE When Generating a Shipment Costs Document

BADI_SCD_CREATE_CHCK For Checks When Creating a Shipment Costs Document

BADI_SCD_PO_SELECT Call for the Purchase Order Item Determination

BADI_SCD_PROCESS_CHK For Checks During Shipment Costs Processing

BADI_SCD_SAVE When Saving Shipment Costs Documents

BADI_SCD_TRANSFER For Transferring Shipment Cost Items

Batch Management

24 Replies

What is a batch no. of a material and where can we mention batch no for material? Can we maintain batch no in mm01 Tcode while creating material?

In simple terms SAP Batch Handling means an additional keys fields for users to identify the same materials.

For e.g. Normal Control : Plant + Material + Storage Location
Batch Hanlding : Plant + Material + Storage Location + Batch Number

The structure of the material master record allows you to manage stocks of a material by value at plant level or company-code level and by quantity down to storage-location level. Under certain conditions, you may need to make further subdivisions for a material and manage batches.

Certain materials’ features cannot always be guaranteed to be exactly alike in production. For example, you cannot guarantee that a certain color will always have the same shade. Minor differences between production lots cannot be avoided. You need to be able to uniquely identify the individual production lots of the same material and manage them separately in inventory.

Materials that require such precise identification, for example pharmaceutical products, are identified and managed in stock not only according to material number, but also according to batch number.

With batch handling, you can manage not only production lots from in-house production, but also production lots from vendors as separate entities.

It is possible to supplement standard batch management with batch status management.

What Is a Material Handled in Batches?
Before you can manage batches of a material in stock, you must first specify in the material master record that the material is to be managed in batches for the specified plant. To do this, you must set the batch management requirement indicator in the material master record (for example, in the Purchasing view fieldMARA-XCHPF or Storage Location view field MARC-XCHPF).

Whether the material is managed in batches:
This indicator can be set while creating material.
MM01 — General Plant data/storage 1 View — Batch Management (check box)
(Check also Purchasing or Warehouse Mgmt 1 view).

Level of Batch Number Assignment
If a material is subject to management in batches, every quantity of that material must be assigned to a batch. Each batch of a material is identified by a unique batch number, under which it is managed. This number is either entered by the user (external number assignment) or assigned automatically by the system.

You can define number assignment for batches at various levels:

– Uniquely at client level for a material
– Uniquely at material level
– Uniquely at plant level

In the standard R/3 System, numbers are assigned to the individual materials at plant level.

For every batch, there are two types of data:

– General data on the batch (for example, shelf life expiry date, date of the last goods receipt), which is defined in the master batch. The master batch applies to all storage locations in which the batch is located. No stocks are managed at this level.
– Stock data, which is managed separately for every storage location in which the batch is located.

For example, if the batch C1 of a material is spread across two different storage locations, the stock quantity is tracked for each storage location.

Must the Batch Exist Before the First Goods Receipt?
Both the master batch and the stock data for the batch are created automatically during the first goods receipt. Thus, you do not need to create this data manually. However, if you want to define specific data for a batch, such as the shelf life expiration date, you have to manually maintain the batch data.

What Sorts of Batch Stocks Are There?
The following stocks are managed separately at batch level:
– Unrestricted-use stock
– Restricted-use stock
– Quality inspection stock
– Blocked stock
– Stock in transfer
– Blocked stock returns

Working with Materials Handled in Batches
When you enter goods movements for materials handled in batches, you must enter the batch number in addition to the material number. If you do not know the batch number, you can search for the batch using the required characteristics.

Config Settings

Logistics general – Batch Management

1.1. Specify Batch Level
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Specify batch level and activate batch status management Transaction OMCT

1.2. Batch Number – Activate Internal Number Assignment
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Number Assignment –> Activate internal batch number assignment Transaction OMCZ

1.3. Batch Creation – for Goods Movements
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Creation of new batches –> Define batch creation for goods movements Transaction

1.4. Characteristic Value Assignment — Update Standard Characteristics
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Characteristic Value Assignment –> Update Standard Characteristics Transaction

1.5. Activate Batch Classification for Goods Movements in Inventory Management
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Characteristic Value Assignment –> Valuation for goods movements –> Activate Batch Classification for goods movements in Inventory Management Transaction OMCV

1.6. Batch Determination – Condition Table(Cross Client)
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Condition Tables –> Define production order condition tables Transaction OPLB

1.7. Batch Determination – Condition Table(Cross Client)
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Condition Tables –> Define SD condition Tables Transaction V/C7

1.8. Batch Determination – Access Sequence(Cross Client)
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Access Sequences –> Define Production Order Access Sequences Transaction OPLF

1.9. Batch Determination – Access Sequence(Cross Client)
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Access Sequences –> Define SD Access Sequences Transaction V/C2

1.10. Batch Determination – Strategy Types
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Define Production Order Strategy Types Transaction OPLE

1.11. Batch Determination – Strategy Types
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Define SD Strategy Types Transaction V/C1

1.12. Batch Determination – Batch Search Procedure
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Define IM Search Procedure Transaction OMCY

1.13. Batch Determination – Batch Search Procedure
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Define Production order Search Procedure Transaction OPLG

1.14. Batch Determination – Batch Search Procedure
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Define SD Search Procedure Transaction V/C3

1.15. Batch Determination – Batch Search Procedure Allocation
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Allocate IM search procedure/activate check Transaction OMCG

1.16. Batch Determination – Batch Search Procedure Allocation
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Assign Search procedure to production order Transaction OPL8

1.17. Batch Determination – Batch Search Procedure Allocation(SD)
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Allocate SD Search procedure Transaction V/C5

1.18. Batch Determination – Activate Automatic Batch Determination(SD)
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Activate Automatic Batch Determination in SD –>For delivery item categories Transaction V/CL

1.19. Batch Determination – Batch Selection Class
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Define Selection Classes Transaction CL01

1.20. Batch Determination – Sort Rule
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Batch Determination & Batch Check –> Define Sort Rules Transaction CU70

1.21. Batch Determination – Make Settings for Batch Where-used list
Menu Path Enterprise Structure–> Logistics General–> Batch Management –> Make Settings for Batch Where-used list Transaction OMBB

Standard SAP SD Reports

26 Replies

Sales summary – VC/2

Display Customer Hierarchy – VDH2
Display Condition record report – V/I6
Pricing Report – V/LD
Create Net Price List – V_NL
List customer material info – VD59
List of sales order – VA05
List of Billing documents – VF05
Inquiries list – VA15
Quotation List – VA25
Incomplete Sales orders – V.02
Backorders – V.15
Outbound Delivery Monitor – VL06o
Incomplete delivery – V_UC
Customer Returns-Analysis – MC+A
Customer Analysis- Sales – MC+E
Customer Analysis- Cr. Memo – MC+I
Deliveries-Due list – VL04
Billing due list – VF04
Incomplete Billing documents – MCV9
Customer Analysis-Basic List – MCTA
Material Analysis(SIS) – MCTC
Sales org analysis – MCTE
Sales org analysis-Invoiced sales – MC+2
Material Analysis-Incoming orders – MC(E
General- List of Outbound deliveries – VL06f
Material Returns-Analysis – MC+M
Material Analysis- Invoiced Sales – MC+Q
Variant configuration Analysis – MC(B
Sales org analysis-Incoming orders – MC(I
Sales org analysis-Returns – MC+Y
Sales office Analysis- Invoiced Sales – MC-E
Sales office Analysis- Returns – MC-A
Shipping point Analysis – MC(U
Shipping point Analysis-Returns – MC-O
Blocked orders – V.14
Order Within time period – SD01
Duplicate Sales orders in period – SDD1
Display Delivery Changes – VL22

LSMW

1 Reply

source : ·

SAPNet (Online Service System): component XX-LSM or

· Email: lsm@sap.com or

· Fax: +49-6227-742890

· SAPNet: http://service.sap.com/lsmw

******************

1 Introduction

1.1 Purpose of this Introduction

This introduction is intended to allow a quick entry into the work with the Legacy System Migration

Workbench Version 1.6 (“LSM Workbench”).

1.2 LSM Workbench: What is it?

The LSM Workbench is an R/3-based tool that supports You when transferring data from non-SAP

systems (“Legacy Systems”) to R/3 once or periodically.

The tool supports conversion of data of the legacy system in a convenient way. The data can then be

imported into the R/3 system via batch input, direct input, BAPIs or IDocs.

Furthermore, the LSM Workbench provides a recording function that allows to generate a “data

migration object” in an entry or change transaction.

1.3 Supported R/3 Releases

Version 1.6 (this version) of the LSM Workbench can be used in R/3 systems with the following

maintenance levels: 4.0A, 4.0B, 4.5A, 4.5B, 4.6A, 4.6B and 4.6C.

For maintenance levels earlier than 4.0 please use version 1.0 of the LSM Workbench.

1.4 Costs

SAP makes this tool available to their customers and partners free of charge.

1.5 Delivery

The LSM Workbench is not part of the standard R/3 system. If you are interested in this product,

please contact SAP via:

· SAPNet (Online Service System): component XX-LSM or

· Email: lsm@sap.com or

· Fax: +49-6227-742890

· SAPNet: http://service.sap.com/lsmw

There you find all available information and documentation and the software itself (transport file).

Among others, the following accompanying material is available:

· Check list for the usage of the LSM Workbench

· Presentation of the LSM Workbench (PowerPoint presentation)

1.6 LSM Workbench Versions

Version 1.0 of the LSM Workbench was made available to about 350 interested customers and

partners in the frame of the First Customer Shipment between March 1998 (CeBIT) and middle of

August 1998. The resulting experiences and feedback were taken into account in the further

development.

In August 1998, version 1.0 of the LSM Workbench was made available to the public. Until today,

LSMW has been requested more than 1,000 times.

Legacy System Migration Workbench

In June 1999, version 1.5 of the LSM Workbench has been released.

Since July 1999, version 1.6 of the LSM Workbench has been available.

For all persons already familiar with version 1.0 of the LSM Workbench, section 11 provides a

compact overview of the modifications in version 1.6 compared with version 1.0.

1.7 Support

For problem messages via SAPNet (Online Service System), entry “XX-LSM” is available in the

component hierarchy. When you enter a message, please specify the number of the LSM Workbench

version you are using. (To display the version number, select Extras à Display LSMW version in the

initial screen of transaction LSMW.)

Note: If problems occur after step Convert data, please directly contact the special department

responsible for the module (FI, CO, MM, SD, HR, etc.). All steps following the data conversion are not

LSM Workbench functions. Therefore the LSMW team cannot provide support for these functions.

1.8 Significance of Data Migration

Data migration comes in the end of R/3 implementation. At this time, the R/3 system is normally

installed and application customizing is finished (in the best case).

An examination of R/3 implementation projects by SAP Consulting has shown that data migration is

about 20% of the total implementation expenses. This portion may rise up to 40% in smaller

implementation projects.

A significant reduction of the expenses for data migration results in a corresponding significant

reduction of the total project budget and the project runtime.

The first experiences with the LSM Workbench in R/3 implementation projects are very promising:

Both the expenses and the costs of data migration could be reduced significantly.

1.9 Basic Principles of the LSM Workbench

The LSM Workbench was developed on the basis of the R/2-R/3 Migration Workbench that has

been used many hundred times in the past and is still used presently.

The following concepts and techniques from the R/2-R/3 Migration Workbench were adopted:

· Business objects instead of individual tables or field contents are migrated.

· The conversion rules to be defined are flexible and can be customized in the frame of migration

customizing to meet the actual situation in the project in the user system.

· Preprogrammed conversion programs are not delivered. These programs are rather generated on

the basis of the defined rules.

The LSM Workbench was developed on the basis of the following principles:

· Most of the functions should reside in R/3. No collection of individual programs on different

platforms.

· The quality and consistence of the data imported into R/3 should be more important than speed

and performance of data migration.

· Existing knowledge and coding should be used.

· The developed “mapping” and rules should be reusable and thus be used repeatedly in projects.

On this basis, a concept was developed that is represented in the following chart:

Legacy System Migration Workbench

ã SAP AG July 1999 21

Accelerating Data Migration: LSM Workbench

One or several

files

R/3 Standard

Convert data

Batch Input

processing

Legacy data

on PC

Read data

Converted

data

Read data

Legacy data

on application

server

IDoc inbound

processing

Direct Input

processing

How LSM Workbench works

Structure

relations

Field mapping

Conversion

rules

Schematic Flow of Data Migration with the LSM Workbench

The main advantages of the LSM Workbench:

· Part of R/3 and thus independent of individual platforms

· A variety of technical possibilities of data conversion:

· Data consistency due to standard import techniques:

¾ Batch input

¾ Direct input

¾ BAPIs (Business Application Programming Interfaces)

¾ IDocs (Intermediate Documents)

The import technique to be used in an individual case depends on the business object.

· Generation of the conversion program on the basis of defined rules

· Clear interactive process guide

· Interface for data in spreadsheet format

· Creation of data migration objects on the basis of recorded transactions

· Charge-free for SAP customers and SAP partners

Legacy System Migration Workbench

2 Preconditions

The LSM Workbench is a tool that supports data transfer from non-SAP systems to R/3. The main

functions of the LSM Workbench are:

1. Import data (legacy data in spreadsheet tables and/or sequential files)

2. Convert data (from source format to target format)

3. Import data (into the database of the R/3 application)

Before you can apply the LSM Workbench, you absolutely need a data migration concept. The

following items should be considered in particular:

· Make sure that R/3 customizing is finished.

· Determine the data contained in your legacy system and which of the data will be required in the

future (with respect to business operation).

· Decide whether it makes sense to use this tool with respect to the data volume to be transferred.

It may be easier to transfer very small data volumes into R/3 manually. In the case of a very large

data volume, batch input or IDoc techniques may cause extremely long runtimes. A rough

landmark for estimating the required time: 10 000 records per hour where this value may vary

considerably depending on the hardware available.

· Identify the transaction(s) in R/3 via which you want to import the data into your SAP system. It

may be relevant whether you need the data for statistical analysis or for further processing in the

system.

· Run the relevant transaction in R/3 manually with test data from the legacy system and see which

fields must be filled. There may be required fields that do not correspond to data fields in the

legacy system. In such a case, you should better assign a fixed value or establish an optional field

for data transfer.

· Map the fields in advance in written form: Assign the source fields to the target fields.

· Determine the form in which non-SAP data will be transferred into the SAP system (e.g. via

“Move” or according to a rule).

· If applicable, define the translation rules (LSMW-internal name: “translation”).

· In which way will the data be extracted from the non-SAP system? Note: The LSMW does not

extract data.

· In which form is the legacy data available? Determine accordingly which of the LSMW functions

will be applied.

· If only a part of your legacy system will be replaced by R/3, determine which function will be

provided by the SAP system and which by the legacy system. If applicable, set up a concept of

data flows and interface architecture.

These questions will be answered differently for every customer and must absolutely be answered

before the tool will be used!

Legacy System Migration Workbench

3 Startup and Preparations

3.1 Authorizations

Authorization level Profile Function

Display B_LSMW_SHOW The user can display all projects

and their work steps. He/she

cannot switch to change mode.

Execute B_LSMW_EXEC The user can display data, and

read, convert and import data.

Change B_LSMW_CHG The user has “Execute”

authorization, and can change

and copy objects.

All B_LSMW_ALL The user can use all functions

made available by the tool.

Please take into account: The profiles listed above are not included in the profiles of the standard R/3

system. Therefore you have to add the required profiles to your user master record.

3.2 Initial Transaction

To start working with the LSM Workbench, use transaction LSMW:

LSM Workbench – Initial Screen

3.3 Project, Subproject and Object

On the initial screen, you can create a new project, corresponding subprojects and objects via Edit ->

Create new entry.

· Project: An ID with a maximum of 10 characters to name your data transfer project. If you want to

transfer data from several legacy systems, you may create a project e.g. for every legacy system.

· Subproject: An ID with a maximum of 10 characters that is used as further structuring attribute.

· Object: An ID with a maximum of 10 characters to name the business object.

In the initial screen, All objects provides a list of all projects created already. My objects displays a list

of all objects you created personally. All objects of the project displays all objects of the selected

Legacy System Migration Workbench

project as tree structure. Project documentation displays any documentation written for the individual

popups and processing steps. you can print the project documentation out, send it and save it in

various file formats.

Select Documentation to enter your notes. After clicking, a popup is displayed in which you can write

down your personal documentation. The documentation function is additionally available under

Administration and Recordings in the first seven steps of data migration.

Below, you find an example for a project with several subprojects and objects. This representation is

displayed by pushing the button All objects of the project:

Example for a Project Structure

Legacy System Migration Workbench

3.4 User Guidance

After selecting an object, ENTER or CONTINUE leads you to the interactive process guide. Here you

are guided through the individual steps of data migration.

LSM Workbench: The Main Steps of Data Migration

This popup provides the following functions:

· Execute: Executed the selected processing step.

· Personal menu: Here you can make an individual selection from the displayed processing steps.

Pressing button “Main steps” automatically activates all processing steps mandatory for a data

conversion.

· Numbers On or Off: you can activate or deactivate the numbering of the individual processing

steps.

· Double click = Display or Double click = Change: Here, you can determine whether display mode

or change mode is selected by double clicking.

· Object overview: Displays all information on the selected object.

· Action log: Displays a detailed overview (date, user name, time) for all processing steps already

carried out. you can reset the action log via Extras ® Reset action log. This action is stored with a

reference to the user and the date.

Legacy System Migration Workbench

Personal Menu: All Processing Steps Available

3.5 Field Mapping on Paper

Before you start working with the LSM Workbench, you should first map the required object on paper.

To do this, create and print out the “object overview”.

At this time, the overview only displays the list and description of the R/3 structures and their fields.

You may use it as a guideline for assigning the corresponding structures and fields of the source

system to these target structures and target fields.

You can also download the overview in table form and fill the table in Excel to have the mapping as a

file on your PC.

Legacy System Migration Workbench

3.6 Create Object Overview

This function is available as pushbutton in order to enable you to create an object overview at any

time:

Legacy System Migration Workbench

Object Overview: General Data, Structures, Structure Relations

Object Overview: Source Structures / Target Structures

Legacy System Migration Workbench

Object Overview: Rules

Object overview in table form

Legacy System Migration Workbench

Note: you may use this before the development of field mapping and rules to print out the R/3

structures for an object including the record description in order to carry out “mapping on paper”.

Overview of Reusable Rules

Legacy System Migration Workbench

3.7 Administration

In the initial screen, you can display the administration functions via Goto® Administration. Here you

can find a list of all existing projects.

It enables you to create, process, display, delete, copy or rename projects, subprojects, objects and

reusable rules.

By double-clicking on an entry you can branch to the entry display.

By positioning the cursor on an entry, you can store a personal note via Documentation. For every

processing action, the name of the person who made the last change and the date of the last change

are stored.

LSM Workbench: Administration

3.8 Recordings

In the initial screen, you can display the recording functions via Goto® Recordings.

If neither a standard batch input program nor a standard direct input program nor an IDoc is available

for a data object, you can create a new object using the recording function of the LSM Workbench.

However, also in cases where a standard program is available, it may make sense to use the

recording function in order to reduce the number of target fields.

Legacy System Migration Workbench

Note: The recording function records a fixed screen sequence. It cannot be used for migrating

data containing a variable number of items or for transactions with dynamic screen sequences !

Use the documentation function: Make sure that you are working in change mode. Position the cursor

on an entry and select Documentation. A popup is displayed where you can write down your own

notes.

For a detailed description of the recording function see section 6.

LSM Workbench: Recordings

3.9 Preparations for Using IDoc Inbound Processing

IDocs (Intermediate Documents) were developed for exchanging messages between different

systems (R/3 ó R/3; R/3 ó R/2; R/3 ó non-SAP system).

Since it is a standard interface to the R/3 applications, this technique can also be used for transferring

data.

To do this, however, some presettings and preparations are required (settings have to be done for

eache project). For a summary of these requirements see Settings ® IDoc inbound processing in the

LSM Workbench.

Legacy System Migration Workbench

LSM Workbench: Settings for IDoc Inbound Processing

· The first requirement is a file port for the file transfer. If required, create a port of the file type via

Maintain ports. To do this, position the cursor on “File” and press Create. You should be in change

mode. SAP recommends:

Port: LSMW

Name: Legacy System Migration Workbench

Version: 3 (IDoc record types SAP Release 4.x)

Outbound file Please enter a (dummy) physical directory and a file name, i.e.

‘filelsmw’

· As an addition, you can specify a tRFC port. This port is required, if you do not want to create a

file during data conversion but submit the data in packages directly to function module

IDoc_Inbound_Asynchronous. SAP recommends:

Port: assigned by the system

Version: 3 (IDoc record types SAP Release 4.x)

RFC destination: Name of R/3 System

Name of port: Legacy System Migration Workbench

· Then the partner type should be defined or selected. SAP recommends:

Partner type: “US” (User)

As of release 4.5A, this partner type is available in the standard system. Up to release 4.0B

inclusive, this partner type is not available in the standard program and should be added. SAP

recommends:

Partner type: Create US

Legacy System Migration Workbench

Report name: /SAPDMC/SAP_LSMW_PARTNERTYPES

Form routine: READ_USER

Short description: any

· Finally a partner number should be defined or selected. SAP recommends:

Partner number: LSMW

Partner type: US

Partner status: A (active)

Type: US

Language: DE or EN

Person in charge: Your user ID

· Activate IDoc inbound processing

¾ Confirm with “Yes” (to be done once for each system)

· Verify workflow customizing (to be done once for each system)

¾ The following entries of the workflow runtime system should be marked with a green check

mark:

· Workflow Administrator maintained

· Workflow RFC destination completely configured

· Generic decision task classified completely

· Sending to objects and to HR objects is active

Legacy System Migration Workbench

¾ To do this, you can start automatic customizing. After this you should set item “Monitoring job

for work items with errors” to “not scheduled”. (This means that you unmark the ID

“Monitoring of WIs with temporary errors”.) If you do not do this, the R/3 system tries over and

over again to post incorrect IDocs created during data migration.

¾ Check the function with Test RFC destination. The following message should be displayed:

‘Ping’ executed successfully. The RFC destination for the SAP Business Workflow is fully

configured.

Verifying Workflow Customizing

Legacy System Migration Workbench

4 General Tips for the Procedure

· Make sure that the Customizing of your R/3 system is finished.

¾ The “ideal project”:

§ First finish customizing

§ Then, run data migration

· Get acquainted with the terminology of the relevant data object.

¾ E.g. XD01: Create customer master (see also the F1 help)

¾ Identify the fields to be filled in your system.

· Decide whether you want to use an existing import program (batch input, direct input, BAPIs,

IDocs) or a recording:

¾ Advantages of standard migration objects:

§ Includes screen sequences that may vary (e.g. with different material types)

¾ Advantages of recordings:

§ Smaller number of target fields

§ Available for almost every transaction

· If you use a recording: Record the transaction and process the recording.

¾ Specify

§ Field names

§ Field description

§ Default values

· Define the record structures of the legacy data and introduce them to R/3.

¾ Case 1: Data is available in one or more files.

§ Introduce these structures to R/3.

¾ Case 2: Data (still) resides in the legacy system and the legacy system provides a function for

exporting the data.

§ Introduce this (these) record structure(s) to R/3.

¾ Case 3: Data (still) resides in the legacy system and the legacy system does not provide a

function for exporting the data..

§ Define the record structure of the data you need.

§ Export this data by means of a program to be written in the legacy system.

§ Introduce this (these) record structure(s) to R/3.

· Develop field mapping and conversion rules.

¾ Use the object overview for “Field mapping on paper”.

· Read data – automatically by pushing a button

· Convert data

¾ The left column of the translation table is filled automatically, if this was set accordingly in

translation control.

¾ A sequential file is created.

· Maintain the reusable rules:

¾ Maintain the translation tables (F4 help for right-hand column).

Legacy System Migration Workbench

¾ Specify your fixed values.

· Maintain the translation tables and generate a new conversion. Please note: at this point the

processing steps are not sequential.

· Import the data.

Depending on the object type:

¾ Batch input / recording:

· Generate batch input session.

· Run batch input session.

¾ Direct input

· Start direct input session.

¾ IDocs / BAPI:

· Transfer converted data to IDoc inbound processing.

· Check inbound processing.

Legacy System Migration Workbench

5 Data Migration – Step by Step

If you want to create or change objects, make sure that you are working in change mode. To activate

this mode, click Change in the corresponding processing step. Only this mode provides all functions

required for changing.

5.1 Maintain Object Attributes

In this step, object type and import technique are selected.

Maintain Object Attributes

· Name your object. By entering data into field Owner, add the project to the list of all projects you

created. You can display it afterwards in the initial screen under My objects.

· Choose whether data transfer is one-time or periodic. In the case of periodic transfer, files cannot

be read from the PC. This adds processing step Frame program for the periodic data transfer.

· Flag whether the file names are system dependant (this gives you the chance to later on enter file

names per system id)

· Select the object type and import technique. Here, an F4 help is available for the input field. This

help displays the relevant lists from which you can select the objects.

Legacy System Migration Workbench

¾ In the case of batch input and direct input, a documentation is available for the program under

Program name (see symbol glasses).

¾ If you want to carry out batch input recording, you can enter further recordings by clicking the

arrow.

Caution

If you apply import technique BAPI or IDoc, the program checks during the save operation whether a

so-called partner agreement is already available for the preset partner (see section 3.9) and the

selected message type. If this is not the case, the system tries to create them (see also section

5.13.3).

5.2 Maintain Source Structures

In this step you define the structures of the object with name, description and the hierarchical

relationships:

In the popup, click Change. You can now define, change, relink or remove structures. All these

functions are available via pushbuttons.

When you define more than one structure, a popup is displayed querying the relations between the

structures: same level/subordinated?

Caution

For migration objects created via transaction recording, you may only define one structure per

recording here, since only one flat target structure per recording is available.

Maintain Source Structures

In the above example, one or several (or no) item records CUSTOMER_CONTACTS may exist for

each header record CUSTOMER_HEADER.

Here, it is not determined yet whether these records are stored in one file or in two files.

Legacy System Migration Workbench

5.3 Maintain Source Fields

In this section, fields are created and maintained for the structures defined in the preceding step.

Maintain Source Fields

There are several possibilities of defining and maintaining the source fields.

5.3.1 Create Individual Source Fields

Make sure that you are in change mode and the cursor is positioned on a source structure or an

existing source field. Clicking on Create field displays the following popup:

Legacy System Migration Workbench

You can select the field type from an underlying list with field type categories and the corresponding

field description:

Source Fields: Possible Field Types

Legacy System Migration Workbench

During data read, you can specify whether date values are converted into the internal date format

(YYYYMMDD) and amount fields are converted into the calculation format (1234.56, i.e. no triad

separators, decimal point).

If data for several structures is stored in one file the field Identifying field value has to be

maintained.

Please maintain only one identifying field value per structure !

For fields of top hierarchy level structures, ID “selection parameter” can be set during Read/Convert

data. If you set this indicator, the corresponding field is made available as selection parameter when

reading or converting data. As a rule, this is used for testing.

5.3.2 Maintain Source Fields in Table Form

Make sure that you are in change mode and the cursor is positioned on a source structure or an

existing source field. Clicking on Table Maintenance displays the following screen:

Maintain Source Fields in Table Form

When you enter a field name and press Enter, the following values are proposed:

Legacy System Migration Workbench

· Field type ‘C’

· Field length 10

· Field text = field name

5.3.3 Copy Source Fields from Other Sources

Make sure that you are in change mode and the cursor is positioned on a source structure or an

existing source field. Selecting Copy Source Fields displays the following popup:

Copy Source Fields: Selecting the Source

Upload (text separated by tabs):

It is assumed that the source field description is stored in a text file the columns of which are

separated by tabs, e.g.:

Field Description

Copy from another object:

Source fields may be copied from the source structure of another object.

Copy from data repository:

Legacy System Migration Workbench

Source fields may be copied from a structure of the R/3 Data Dictionary.

From data file (field names in 1st line)

Source fields may be copied from a data file. This file must be stored on the PC in the form of “text

separated by tabs” and contain the field names in the first line.

Example of a data file from which the source fields are to be copied from

5.4 Maintain Structural Relationships

The structural relationships define the relationships between source and target structures.

The possible target structures are defined during the selection of the object type and the import

technique.

In general, there are target structures that must be selected (required segments). In this case the

following note is displayed: “This structure must be selected”.

To define structural relationships, position the cursor on a field of the R/3 structures / target structures.

Clicking Relationship opens a window that displays the existing source structures for selection.

If you want to change the relation, remove the existing relation first. To do this, a pushbutton is

available as well.

In addition, you can use Check to check the structural relationships for errors. The status bar then

displays an error message or message: “The structural relationships do not contain any errors”.

Legacy System Migration Workbench

Maintain Structural Relationships

In the above example, the fields of R/3 structures BGR00, BKN00, BKNA1, and BKNB1 are filled by

the fields from CUSTOMER_HEADER, the fields of R/3 structure BKNVK are filled by the fields from

CUSTOMER_CONTACTS.

Note 1: Many Batch Input and Direct Input programs use a control record named BGR00 or

BI000. You should always assign the top level source structure („header structure“) to this control

record.

Note 2: It might be necessary to assign two or more source structures to one target structure. In

this case you should proceed as follows: Create the source structures in the usual way. Then assign

the subordinate source structure to the target structure. Thus, the fields of both source structures will

be available for the fields of the target structure.

Legacy System Migration Workbench

LSMW: Structure Relations

S_Header1

S_Header2

S_Position

Target Source

T_Header

T_Position

LOOP AT S_Header1.

LOOP AT S_Header2 WHERE …

T_Header <<< S_Header1, S_Header2

LOOP AT S_POSITION WHERE …

T_POSITION <<< S_POSITION

ENDLOOP.

Structure relations: Example

5.5 Maintain Field Mapping and Conversion Rules

In this step, you assign source fields to target fields and define how the field contents will be

converted.

All fields of all target structures, which you selected in the previous step, will be displayed. For each

target field the following information is displayed:

¾ Field description

¾ Assigned source fields (if any)

¾ Rule type (fixed value, translation etc.)

¾ Coding.

Note: Some fields are preset by the system. These fields are called „technical fields“ are marked

with „Default setting“. The coding for these fields is not displayed when first entering the fieldmapping;

it can be displayed via the display variant (see 5.5.1). Changing the default setting may seriously

affect the flow of the data conversion. If you erroneously changed the default setting, you can restore

it by choosing Extras à Restore default.

Legacy System Migration Workbench

Field Mapping: Tree of Target Fields for the Target Structures Selected

The following functions are available:

Field documentation : Displays a short documentation for the target field the cursor is positioned

on. The documentation may branch off to further information.

Possible values : Displays a selection list of all values possible for this target field.

Longtext / Documentation . – : Maintenance of the documentation for a field etc.

Assign a source field: To assign a source field, position the cursor on a target field in the tree

structure and select Assign source field. This displays a list of all available source fields for selection.

You can assign the fields by double-clicking on them.

Note: If you choose Extras à Auto-Fieldmapping, LSMW will give suggestions for assigning

source fields to target fields.

Remove the assignment of a source field: To remove a source field assigned before, position the

cursor on a target field in the tree structure and select Remove source field. If one source field has

been assigned only, this field is removed. If several source fields have been assigned, a list of all

source fields assigned is displayed for selection. The corresponding source field can then be selected

by double-clicking on it.

After assigning the source fields, you define the conversion rules. The default rule is “Move”.

However, you can select various standard techniques via pushbutton.

Legacy System Migration Workbench

Conversion Rules: Select Rule

Assign rules:

Initial: This deletes the coding assigned to the target field. In addition, source fields assigned to

the target fields are removed as well. Depending on the object type, the target field is

assigned the following value:

¾ For standard batch input/standard direct input: Nodata characters (determined e.g. in

session header BGR00, BI000)

¾ For batch input recording: ‘/’ as nodata character

¾ For BAPIs, IDocs: Clear field (i.e.: character field à blank; numeric field à ’00…0′)

Move: The data is transferred using ABAP command “Move”. For source fields that are not of

type ‘C’ or ‘N’, this means:

Packed field Unpack to target field WRITE…TO…

Date field Popup to select

– internal format

– user format

– …

e.g. 01.10.1998

YYYYMMDD

Amount field Batch input/direct input: The amount

value is edited according to the format

settings in the user master.

BAPIs, IDocs: The amount value keeps

the internal calculation format.

Legacy System Migration Workbench

Constant: The target field is assigned a fixed value.

Fixed value (reusable): A “fixed value object” (variable) named FV_<fixedvalue> is assigned to the

target field. This fixed value object is filled with an actual value in step “Maintain fixed values,

translations and user-written routines”.

Translation (reusable): The target field is assigned coding carrying out field contents conversion

using a translation table. The values of this translation table can be entered in step “Maintain fixed

values, translations and user-written routines” see 5.6.

User-written routine (reusable): The system creates the frame of a form routine (ABAP subroutine)

with name prefix “ur_”. This routine can be reused, i.e. it can also be used in other objects of the

project.

With all kinds of reusable rules, the LSM Workbench proposes one to three possible names. One

name is recommended by the system. SAP recommends you to use the proposed name. For details

regarding naming conventions, see 5.5.4.

When creating user written routines please keep in mind that:

– the correct amount of source fields has been linked

(regarding the amount of input parameters)

– the source fields are related in correct sequence (i.e. the sequence of the parameters).

Prefix: Specify any prefix to precede the contents of the source field.

Suffix: Specify any suffix follow the contents of the source field.

Concatenation: You can concatenate two or more source fields.

Transfer left-justified: Transfers the contents of the source field in left-justified form.

ABAP coding: Double-clicking on a target field branches off to the ABAP editor. There you can edit

generated ABAP coding or write and save your own coding. A large part of the usual standard R/3

editor functions, such as Check (syntax check), Pretty Printer, etc., are available there.

Under Insert you can add the following to your coding:

· source fields: all source fields available are displayed for selection

· global variable: see 5.7

· global functions: see 5.5.3

XFIELD: This is a special function for processing of IDocs. In some cases an ‘X-structure’ exists in

addtion to the data transfer structure (where the values for the import can be found); the fields of this

‘X-structure’ have to be filled with ‘X’ or blank to decide if the corresponding field in the data transfer

structure should be transfered or not.

The following coding is generated automatically:

If not <field in the data transfer structure> is initial.

<field in X-structure> = ‘X‘.

else.

<field in X-structure> = ‘ ‘.

Endif.

Note: Via Extras -> fill X-structures the coding for whole structures can be added

5.5.1 For the Advanced User: Display Variant, Processing Times

Define display variant: In work step “Maintain field mapping and conversion rules”, select ‘* display

variant’. This displays popup Define display variant. This function is useful mainly to advanced users

who want to modify their field mapping.

Legacy System Migration Workbench

You can specify the information to be displayed.

Define Display Varian

Global data definitions: Displays label __GLOBAL_DATA for global data definitions and declarations.

There, you can define a variable, structures, tables, etc., to be used in the field mapping of your own

coding.

Processing times: Here you can insert your own coding at specific processing times.

The following processing times are available:

Legacy System Migration Workbench

Processing time Meaning Default setting

__BEGIN_OF_PROCESSING__ Before the beginning of

data processing

(blank)

__BEGIN_OF_TRANSACTION__ Before the beginning of

transaction data

processing

(blank)

__BEGIN_OF_RECORD__ Before applying the

conversion rules for a

source structure

Initialize the structure <segment>

(Name of target structure)

Batch Input, Direct Input:

<segment> = init_<segment>.

BAPI, IDoc:

g_edidd_segnam = ‘…’.

g_edidd_segnum = ‘….’.

g_edidd_psgnum = ‘……’.

g_edidd_hlevel = ‘..’.

Clear <segment>.

__END_OF_RECORD After applying the

conversion rules for a

source structure

Transfer_record.

__END_OF_TRANSACTION__ After finishing transaction

processing

Transfer_transaction.

__END_OF_PROCESSING__ After finishing data

processing

(blank)

Form routines: Displays label __FORM_ROUTINES__ for form routines (ABAP subroutines). There,

you can define ABAP subroutines to be used in your own coding for field mapping.

Technical fields: Displays the so-called technical fields. These are target fields for which LSMW

proposes a conversion rule (e.g. constant). As a rule, modifications need not be made.

Initial fields: Displays initial fields.

Coding: Displays the stored coding.

Note: Under menu item Extras ® Source fields not assigned you can display the source fields not

yet assigned, i.e. you can see whether there is data which has not yet been adequately dealt with.

5.5.2 For the Advanced User: Global Variables

The LSM Workbench internally uses a number of global variables.

1. From the list of work steps, select Field mapping and conversion rule.

2. Branch off to the coding by double-clicking on a target field

3. Select Insert ® Global variable.

This variable can be used in your ABAP coding.

Legacy System Migration Workbench

Global variable Description

g_project Current project

g_subproj Current subproject

g_object Current object

g_record Current target structure

g_cnt_records_read Number of records read

g_cnt_records_skipped Number of records skipped

g_cnt_records_transferred Number of records transferred to a file

g_cnt_transactions_read Number of transactions read

g_cnt_transactions_skipped Number of transactions skipped

g_cnt_transactions_transferred Number of transactions transferred to a file

g_cnt_transactions_group Number of transactions in the current batch input session

g_userid User ID

g_groupname Name of the batch input session

g_groupnr Current number of the current batch input session

5.5.3 For the Advanced User: Global Functions

The LSM Workbench provides a series of functions that can be used in any position of the ABAP

coding.

Note: These functions allow to partially considerably influence the flow of the data conversion

program. Please do apply these functions with care.

1. From the list of work steps, select Field mapping and conversion rule.

2. Branch off to the coding by double-clicking on a target field

3. Select Insert ® Global functions.

The following functions are available:

Global function Description

transfer_record. Transfers the current record (i.e. for the current target

structure) to the output buffer.

transfer_this_record ‘…’. Transfers a record of another target structure to the output

buffer. The name of the target structure has to be specified as

argument in single quotes.

at_first_transfer_record. Transfers the current record to the output buffer, if it is the first

transaction.

on_change_transfer_record. Transfers the current record to the output buffer, if it has

changed compared to the last record.

transfer_transaction. Writes the current transaction to an output file. All records of

Legacy System Migration Workbench

the output buffer are transferred to the output file.

skip_record. The current record is not transferred to the output buffer.

skip_transaction. The current transaction is not written to the output file.

5.5.4 For the Advanced User: Reusable Rules — Naming Conventions

Reusable rules are rules that are available across the project. They can be used in all objects of a

project. Reusable rules are: fixed values, translations, and user-written routines.

If you assign a reusable rule to a target field, the system proposes one to three different names. To

understand the naming conventions, we should look at the definition of data objects in the R/3

system.

Data object definition in the R/3 system is performed on three levels:

Domain: On the “lowest” level, technical attributes are defined, e.g. field type, field length, value

table or fixed values.

Data element: On the “second” level, “semantic” characteristics are defined on the basis of a domain

and its characteristics, e.g. language-dependent texts, documentation.

Field: On top level, attributes of the field in the context of a structure or table are defined on the basis

of a data element, e.g. foreign key relations, search helps.

This means in particular: For a domain, there normally are several data elements which refer to the

domain.

(A count in the R/3 system, Release 4.5A produces the following figures: Domains: about 22,000, data

elements: about 117,000, fields: about 1,028,000)

SAP recommends to accept the names defaulted by the system as a rule. An exception is given, if

the domain is very general such as “CHAR1” (about 5,200 data elements) or “XFELD” (about 13,500

data elements. If you used the name of the domain in this case, the reusable rule might not be usable

for another field, since this field may have a completely different meaning.

This naming procedure keeps the number of conversion rules small and maintains the consistency in

data conversion.

Example:

No. Field Data element Domain Name

1 BUKRS BUKRS BUKRS Company code

2 CO_ CODE CO_CODE BUKRS Company code

Both fields are named “Company code”. The field names are different, the domain is the same. Thus

both fields should be filled with the same fixed value or the same translation or user-written routine.

Legacy System Migration Workbench

5.6 Maintain Fixed Values, Translations and User-written

Routines

In this step you can process the reusable rules of a project:

Process Reusable Rules

Fixed value: Here you can specify length, type, flag for lowercase/uppercase and value in addition to

the description.

Change Fixed Value

Legacy System Migration Workbench

Translation: Here you can enter information on the source field and the target field:

Change translation / Source field, target fields

If you are creating a new translation you have to save data before you can change to Control

information.

Legacy System Migration Workbench

Control information: Here you can define the translation type. You can specify which of the two

translation tables will be searched for a value first and which alternative will be selected, if no suitable

entry is found:

1:1 translation values: Here you specify the value table to be used during translation. You may also

upload the values from a PC file (text separated by tabs). In addition, F4 help is available in column

“New value”.

Important

During translation, only values for which the OK flag was set are included.

Interval translation values: Here you specify the value table to be used during translation by

intervals. You may also upload the values from a PC file (text separated by tabs). In addition, F4 help

is available in column “New value”.

Legacy System Migration Workbench

Important

During translation, only values for which the OK flag was set are included.

5.7 Specify Files

In this step you describe all files to be used in the following steps:

· Your legacy data on the PC and/or R/3 server

· The file for the read data

· The file for the converted data

Legacy System Migration Workbench

Specify Files

If your legacy data is on the PC:

1. In change mode, position the cursor on the line “Legacy data — on PC (frontend)”.

2. Select Add entry.

A popup is displayed.

3. Specify file path (F4 help), file name and description and other properties.

Legacy System Migration Workbench

File on Frontend (PC): Properties

If your legacy data is on the R/3 server:

1. In change mode, position the cursor on the line “Legacy data on R/3 server (application server)”.

2. Select Add entry.

A popup is displayed.

3. Specify file path, file name and description.

4. Under “Codepage ID”, specify the indicator of the legacy system’s character set.

5. Determine the technical record description and the separators.

Note: Please note that the R/3 system uses user ID <sid>adm with regard to the operating

system. Therefore, make sure that you have read/write authorization for the selected directory.

Legacy System Migration Workbench

File on R/3 Server: Maintain Properties

Please consider the following notes:

· If a file contains data for several source structures, the field sequence has to correspond to the

source structure definition.

· If a file contains data for a single source structure, either the field sequence has to correspond to

the source structure definition or field names have to be specified at the beginning of the file

which can be used for assigning the columns to the fields.

· If a file contains end-of-line indicators (text file), packed fields are not allowed.

· If a file contains separators, packed fields are not allowed.

· PC files and server files may be mixed at will.

· In the following step, a file containing data for several source structures can be assigned to

several source structures.

· In the following step, a file containing data for a single source structure can be assigned to one

single source structure only.

· If several files are used in an object, the corresponding source structures have to contain fields of

the same name. In our example, this is field CUSTOMER_NUMBER:

Legacy System Migration Workbench

Display Merge Fields

File of read data:

Here, the file name is entered. We recommend you to use file extension “.lsmw.read” to differentiate

the read data from the converted data.

File of converted data:

Specify the file name. We recommend you to use file extension “.lsmw.conv”. Fields “Logical path”

and “Logical file name” should be filled only if this is required for the subsequently called batch input

or direct input program (fields only are shown in this case) For both fields, F4 help is available.

Legacy System Migration Workbench

Note 1: Names for paths and files can be freely assigned according to the operating system’s

naming conventions.

Note 2: If your files are stored in several sets of files, you can add a wildcard (‘*’) to the name of

your file. The possible values for ‘*’ can be specified under “Values for wildcard”.

5.8 Use Wildcards in File Names

Example for the usage of wildcards in file names: Let’s assume that the legacy data is stored in the

following four files:

· File 1: D:\Mig\Purchase Orders\PO Header 1.txt

· File 2: D:\Mig\Purchase Orders\PO Position 1.txt

· File 3: D:\Mig\Purchase Orders\PO Header 2.txt

· File 4: D:\Mig\Purchase Orders\PO Position 2.txt

Two files each (*1.txt and *2.txt) form a “set”, i.e. file 2 contains the position data for the header

records in file 1, file 4 contains the position data for the header records in file 3.

When reading the data, files 1 and 2 shall be processed before files 3 and 4.

This is achieved by means of the following settings:

Legacy System Migration Workbench

Specify Files: Using Wildcards

Note: You can also use a wildcard in the names of the files of read data and converted data.

Legacy System Migration Workbench

5.9 Assign Files

In this step, you assign defined files to the source structures:

Assign Files

Note: If you change file names or properties subsequently, the file assignment is kept.

5.10 Read Data

Proceeding:

· If you want to process all data belonging to an object, click on Execute. The process is started.

· If you want to migrate a part of the data only, you can limit the number of data to be migrated in

field “General selection parameters”. Make your selection in field “Transaction number” from “…

to …”. Multiple selection is possible.

If you marked one or several source fields as selection parameters when defining the source fields,

these fields are also offered as selection parameters.

In addition, two check boxes are offered:

· Amount field: Amount fields are converted into calculation format (with decimal point).

· Date field: Date fields are converted into internal format (YYYYMMDD).

If you use a wildcard in the file names for the input files, and at least one value has been defined for

the wildcard, a selection parameter for the wildcard is offered as well. If you do not make any entry

here, all wildcard values defined are processed.

Legacy System Migration Workbench

Data Read Program: With User-defined Selection Parameter

Note: First, the system checks whether the data read program is still up-to-date. If this is not the

case, it is regenerated automatically.

5.10.1 Display Read Data

In this step, you can display all or a part of the read data in table form. Clicking on a line displays all

information for this line in a clear way. The same happens when you click on Field contents.

Change display allows to select either a one-line or multi-line view.

Display color palette displays the colors for the individual hierarchy levels.

5.11 Convert Data

5.11.1 General Remarks

With regard to operation, this work step essentially corresponds to work step “Read Data” (see 5.8).

If you do not make any data selection, confirm the process by clicking on Execute. Otherwise, make

your selection in field “Transaction number” from “…to…”. Here, multiple selection of transaction

numbers is possible as well.

If you marked one or several source fields as selection parameters when defining the source fields,

these fields are also offered as selection parameters.

If you use a wildcard in the file names for the input files, and at least one value has been defined for

the wildcard, a selection parameter for the wildcard is offered as well. If you do not make any entry

here, all wildcard values defined are processed.

Legacy System Migration Workbench

Data Conversion Program: With User-defined Selection Parameter

Note: First, the system checks whether the data conversion program is still up-to-date. If this is

not the case, it is regenerated automatically.

5.11.2 Additional Function for BAPI/IDoc

If the LSMW object is based on a BAPI or an IDoc, further selection parameters are displayed on the

data conversion program selection screen:

Convert Data: Further Selection Parameters for BAPI/IDocs

If you select Create file, a file is created during data conversion.

If you select “Create IDocs directly”, IDocs are collected during data conversion and submitted for

IDoc creation in packages. The package size can be determined using parameter “Number of IDocs

per package”. The default value is 50.

Legacy System Migration Workbench

5.12 Display Converted Data

See section 5.10.1.

5.13 Import Data

The steps displayed by the program depend on the selected object type:

· Standard batch input or recording:

¾ Generate batch input session

¾ Run batch input session

· Standard direct input:

¾ Start direct input session

· BAPI or IDoc:

¾ Start IDoc creation

¾ Start IDoc processing

¾ Create IDoc overview

¾ Start IDoc postprocessing

5.17.1. Import Data with Batch Input

5.13.1.1 Generate Batch Input Session

In this step, the standard batch input program belonging to the object is directly called. The name of

the file with the converted data is already proposed.

The batch input sessions to be generated are named after the LSMW object.

5.13.1.2 Run Batch Input Session

The program goes to R/3 standard transaction SM35. However, only the batch input sessions for the

selected object are displayed.

Note: If you used the name of the object in other projects or subprojects as well, batch input

sessions from these objects may also be displayed.

5.13.2 Import Data with Direct Input

5.13.2.1 Start Direct Input Session

Depending on the object type, either the standard direct input program belonging to the object is

called or you can select a direct input program or a direct input transaction.

Legacy System Migration Workbench

5.13.3 Import Data with BAPI or IDoc Technique

Data stored in a file by means of the IDoc technique is generally imported in two steps. You can call

these steps in LSM Workbench:

· Start IDoc creation. First, the file of the converted data is read. The “information packages”

contained are stored in the R/3 database in IDoc format. It is, however, not stored in the database

of the corresponding application. The system assigns a number to every IDoc. Then the file of the

converted data is deleted.

· Start IDoc processing. The IDocs created in the first step are submitted to the corresponding

application program. This application program checks the data and posts it in the application’s

database, if applicable.

Note: Step “Start IDoc creation” is not performed, if you selected option “Create IDocs directly”

during data conversion.

Whether the second step is automatically initiated depends on the settings of the ALE-EDI

customizing.

One essential setting is made in the so-called partner agreement (for a partner and a message type,

see section 5.2). This agreement specifies whether the IDocs are to be processed immediately or by

means of a background program.

Note #1: Partner agreements automatically created by the LSM Workbench are set as follows:

“Initiation by background program”. (You can manually change this setting at any time.)

Note #2: During the processing of inbound IDocs, so-called work items are created in the

standard program. This are elements of the R/3 workflow that are usually not required during data

migration. For information on how – and with which consequences – the creation of work items can be

suppressed see R/3 Note no. 149368.

Note #3: CD-ROM “Interface Adviser” provided by SAP contains useful information that helps to

increase performance in connection with IDoc processing. Follow the path à Technology à

Interfaces à Background processing à Import à ALE/IDoc à Performance.

You can do the following in addition to these two processing steps:

Create IDoc overview: This displays a „status overview which allows to display individual IDocs with

the “drill-down” technique.

Legacy System Migration Workbench

6 Recordings

Perform a transaction „trial run“;

Caution This is no simulation mode! Your input is posted in the system!

Postprocess recording: Assign field names, field texts and default values

Save recording: This generates the above structure in the Data Repository.

Caution In Attributes for an object you can assign any number of recordings to an object.

This way you can run various transactions in succession for one data record.

6.1 Detailed Description of the Process

In the initial screen you select function Recordings under Goto.

Recordings: Overview

Note: Recordings are assigned to exactly one project.

Select Recordings ® Create recording. Fill the displayed fields.

Legacy System Migration Workbench

Create Recording

After pressing Continue you can start to record the transaction whose transaction code you have to

enter first.

Create Recording: Enter Transaction Code

Note: If you do not know the transaction code of the transaction you selected: Select System ®

Create session. This displays the initial screen of R/3. Then select the relevant application

component. This displays the relevant dialog screen. Select the transaction you want to record and

then System ® Status. The repository data includes the transaction code.

Now you can execute the selected transaction. Here you should input values in all the fields you

intend to fill with the values from you legacy data later.

After the recording has finished, you can process it. You can delete or add fields.

Legacy System Migration Workbench

Process Recording

You can assign field names freely. During the generation of the batch input session, the contents of

these fields are assigned to the target fields displayed in the left column.

The following functions are available:

Default: Assigns the field name of the relevant target field and its field description.

Reset: Deletes field names and field descriptions.

Double-click: Edits fields names, field descriptions and default values.

Important

You may use field names repeatedly. However, in field mapping a field name can only be used

once.

For all fields in which you did not specify a field name the specified default value is used for the batch

input session generation. Thus these default values can be considered as constants. This is useful in

particular with check boxes (e.g. MM01, view selection).

After you saved, the status line displays the following message: “Data saved successfully”. The

recording is now available among the attributes for the object.

Legacy System Migration Workbench

7 Transport LSMW Projects

The LSM Workbench provides data transport for a project via both the R/3 transport system and

down-/upload. (Excluded are the presettings for IDoc inbound processing. These presettings should

be manually created in every R/3 system and every client.)

7.1 Generate Change Request

Choosing this function creates an R/3 change request containing all information about an LSMW

project. This R/3 change request can be exported / imported with the usual means of R/3 correction

and transporting. You can find this function in the initial screen under Extras -> Create change

request.

When transporting LSMW data this way, you can trace the transports any time in R/3 correction and

transporting.

Note 1: When importing such a request, the complete project is deleted from the target system

first. It is then created again.

Note 2: When exporting the transport request, all changes to the selected project made until the

time of export are entered (not only until the time of creation of the transport request.)

7.2 Export Project

In the initial screen, select Extras à Export project. This first displays the structure tree of the

selected project. Via Select / Deselect you can select whether the entire project or parts of the project

are exported. Then select Export. The program then creates an ASCII file.

Legacy System Migration Workbench

Export Project: Project Table of Contents

Note: The selected elements are exported together with their documentation.

7.3 Import Project

The exported mapping and rules can be imported into another R/3 system.

On the selection screen, select Extras -> Import. The program then prompts you to enter the name of

the PC file. The file is imported and the contents are analyzed. After the analysis, a list of the

subprojects and objects found is displayed.

You can now mark the objects to be imported. Project data existing already are check-marked. They

are overwritten by the import.

You can prevent a project already existing in the target system from being overwritten by using

function “Import under different name”.

Note: The selected elements are imported together with their documentation.

Legacy System Migration Workbench

8 Periodic Data Transfer

To a limited extent, the LSM Workbench also supports periodic data transfer. Preconditions are:

· The LSMW object has been created and tested completely.

· The “source application” periodically makes available one or several files on the R/3 application

server.

· The LSMW object does not access files on the frontend. (Files on the frontend cannot be read in

batch mode.)

If all these conditions are met, you can set select button “Periodic” in step “Maintain object attributes”.

Then, step “Control program for periodic data transfer” is displayed in the overview of work steps.

This program carries out the following steps in sequence:

¾ Read data

¾ Convert data

¾ Import data

This program (name: /SAPDMC/SAP_LSMW_INTERFACE) can be used according to your

requirements.

Legacy System Migration Workbench

Frame Program for Periodic Data Transfer: Selection Screen

Legacy System Migration Workbench

Note 1: Specification of a flag file is optional.

Note 2: A flag file serves for creating a “handshake” with the application providing the input

file(s):

· The control program for periodic data transfer is only executed if the specified flag file exists.

· After finishing data transfer, the control program for periodic data transfer deletes the flag file.

· The “providing” application should behave in a complementary way: Before new files are created,

a check is carried out as to whether the flag file exists. If this is the case, the program stops.

Otherwise, the files are generated, and the flag file is created.

Note 3: Some of the standard batch input and direct input programs use additional parameters.

Some of these parameters are also used in other programs. For information about which parameters

are used in which program, please refer to the coding of program /SAPDMC/SAP_LSMW_INTERFACE.

Program Parameter used

Test run without

update

Create

batch input

session

BI, DI, Call

Transaction,

Test

Lock

mode

Action User

group

RAALTD01

RAALTD11

RCCLBI01

RCCLBI02

RCCLBI03

RCCTBI01

RCSBI010

RCSBI020

RCSBI030

RCSBI040

RCVBI010 X

RFBIBL00 X

RHALTD00 X

RLBEST00

RLPLAT00

RMDATIND X

RPUSTD00 X X

Note 4: You can specify variants for the read program, the conversion program and (in case

Batch/Direct Input) the Batch or Direct Input program. These variants have to be defined before.

Legacy System Migration Workbench

9 Long Texts

To transfer long texts, there are two possibilities:

Ø Direct input program /SAPDMC/SAP_LSMW_IMPORT_TEXTS (object 0001, method 0001); this

object is not available in the standard program. To make it available, run the following program:

/SAPDMC/SAP_LSMW_SXDA_TEXTS

Ø Direct input program RSTXLITF (object 2000, method 0000); to be able to use this object, you

have to download the transport from SAPNET (http://service.sap.com/LSMW) and import it into

your system

9.1 Long Texts in the R/3 System

Long texts (texts covering more than one line) are stored in a text pool in R/3. The key of a long text

is composed of four parts:

Key field Meaning Example Length Check

table

OBJECT Application

object

AUFK = Order texts 10 TTXOB,

TTXOT

ID Text ID Object AUFK

· Id KOPF = Order header text

· Id POSN = Order item text

· Id RMEL = Order confirmation text

TTXID,

TTXIT

NAME Actual text key Order number 70 (none)

SPRAS Language Text language 1-2 T002

Legacy System Migration Workbench

9.2 Determine Text Key Structure

There is no uniform rule for the structure of the actual text key NAME. To determine the values for

OBJECT and ID for a specific text type and the structure of NAME, proceed as follows:

¾ Display a text of the required text type (e.g. order header text) and branch off to the editor.

¾ There you can display the required information via Goto à Header:

The following applies in the above example of a material sales text:

OBJECT = MVKE

ID = 0001

NAME

¾ Material number (18 characters) +

¾ Sales organization (4 characters) +

¾ Distribution channel (2 characters)

Legacy System Migration Workbench

9.3 Develop Objects for Long Texts via Object 0001

The following target structures are available:

/SAPDMC/LTXTH: Long text header

¾ STYPE Record type (technical field, value = ‘1’)

¾ OBJECT Application object

¾ NAME Text name

¾ ID Text ID

¾ SPRAS Language

/SAPDMC/LTXTL: Long text text line

¾ STYPE Record type (technical field, value = ‘2’)

¾ TEXTFORMAT Format field (2 characters)

¾ TEXTLINE Application object

Field TEXTFORMAT contains text formatting information. To simply map the field 1:1, enter

character ‘*’.

For the material sales text in the example, a migration object could look as follows:

Long Texts: Source Fields

Legacy System Migration Workbench

Long Text: Structural Relationships

Legacy System Migration Workbench

Long Text: Field Mapping

Note: Statement on_change_transfer_record. has the effect that the text header is transferred

only, if it has changed compared to the previous record (see 5.5.3).

Legacy System Migration Workbench

9.4 Develop Objects for Long Texts via Object 2000

Please have a look at the documentation for program RSTXLITF first. There you will find very useful

information concerning the file format the import program needs.

The following target structures are available (defined during the import of object 2000):

/SAPDMC/LSMW_TEXTHTEXT

/SAPDMC/LSMW_TEXTOBJEKT

/SAPDMC/LSMW_TEXTNAME

/SAPDMC/LSMW_TEXTID

/SAPDMC/LSMW_TEXTLANGUAGE

/SAPDMC/LSMW_TEXTFORM

/SAPDMC/LSMW_TEXTSTYLE

/SAPDMC/LSMW_TEXTFIRSTUSER

/SAPDMC/LSMW_TEXTFIRSTDATE

/SAPDMC/LSMW_TEXTFIRSTTIME

/SAPDMC/LSMW_TEXTLASTUSER

/SAPDMC/LSMW_TEXTLASTDATE

/SAPDMC/LSMW_TEXTLASTTIME

/SAPDMC/LSMW_TEXTTITLE

/SAPDMC/LSMW_TEXTTITLE1

/SAPDMC/LSMW_TEXTTITLE2

/SAPDMC/LSMW_TEXTMAIN

/SAPDMC/LSMW_TEXTLINE

Most of the fields for these structures are technical fields and are filled by default.

A migration object could look as follows:

Source Fields

Legacy System Migration Workbench

Structural Relationships

Legacy System Migration Workbench

9.5 Import Texts

Texts are imported into the R/3 system by means of direct input. The relevant direct input program

can be easily called from the LSM Workbench via Start Direct Input Session.

Important

After the import of long texts, sometimes these cannot be read within the corresponding application.

Via function module ‘READ_TEXT’, the texts are found, thus, they are stored correctly in the

database. Some applications have a field in the master data which shows whether a long text exists

or not. This field is not filled by the direct input programs (since these programs apply to all

applications, and at runtime it is not known which application a text belongs to.

There are 2 possible solutions:

1. The flag is supplied by a user-defined report after the import

2. In the field assignments / mapping an update is coded on the respective table; however,

this that the flag is set already during the conversion è if the text is not imported later,

the flag is set, however, no long text is available.

Legacy System Migration Workbench

10 Tips and Tricks

10.1 Determine the Transaction Code at Runtime

Situation: You want to transfer data a part of which has already been created in the system. You

want to decide at runtime whether the data is created or changed.

Example: Customer master

Solution: Insert under “Global Data”:

TABLES: KNA1.

Add the following coding for field BKN00-TCODE:

Select count(*) from kna1 where kunnr = <alte_kundennummer>.

if sy-dbcnt = 0.

bkn00-tcode = ‘XD01’.

else.

bkn00-tcode = ‘XD02’.

endif.

10.2 Skip a Record

Situation: You want to “skip” a record depending on a certain condition, i.e. this record shall not be

converted and transferred to the output file

Solution:

if <condition>.

skip_record.

endif.

10.3 Skip All Records of a Transaction

Situation: You want to “skip” all records of a transaction depending on a certain condition.

Solution:

if <condition>.

skip_transaction.

endif.

10.4 Duplicate a Record

Situation: You want to create two (or more) target records from a source record.

Example: Your customer master of legacy files consists of one record containing among other things

the fields “First name”, “Name”, “Phone number” for two contact persons. In R/3, a BKNVK record has

to be filled for each contact person.

Solution: Your legacy structure is assumed to look as follows:

CUST Customer master

…

VORNAME1 First name of first contact person

NACHNAME1 Name of first contact person

TELEFON1 Phone number of first contact person

VORNAME2 First name of second contact person

NACHNAME2 Name of second contact person

TELEFON2 Phone number of second contact person

…

Legacy System Migration Workbench

Create the following rules:

…

BKNVK-NAME1

ß CUST-NACHNAME1 (Move)

BKNVK-TELF1

ß CUST-TELEFON1 (Move)

BKNVK-NAMEV

ß CUST-VORNAME1 (Move)

and add

End_of_Record

BKNVK-NAME1 = CUST-NACHNAME2.

BKNVK-TELF1 = CUST-TELEFON2.

BKNVK-NAMEV = CUST-VORNAME2.

transfer_record.

…

at processing time. This creates two BKNVK records.

Legacy System Migration Workbench

11 Upgrade from LSMW 1.0 to LSMW 1.6

11.1 Differences Between Version 1.0 and Version 1.6 of the

LSM Workbench

The following lists the main differences between version 1.0 and 1.6 of the LSM Workbench:

· Transaction code: The transaction code is “LSMW” (in version 1.0: “DLSM”). Version 1.0 is still

available after installing version 1.6.

· Key field names: New: “Project” instead of “Legacy system”, “Subproject” instead of “Legacy

system release”, “Object” instead of “Migration object”. All these key fields now have a length of

10 places (in version 1.0, they had four places).

· Naming convention: The names for project, subproject and object can be assigned freely

without any restrictions.

· Changed description: New: “Recording” instead of “User-defined migration object class”. The

name of a recording may have up to 10 characters and should meet the ABAP naming

conventions (e.g. first character = letter). Every recording is assigned to exactly one project.

· Changed description: New: “Reusable rules” instead of “Central rules”.

· Object attributes: In the object attributes, the object and import types are defined. (In version

1.0, this definition was already made via the selected object name.) You can now assign any

number of recordings to an object.

· Import techniques: In addition to standard batch input/standard direct input and recording, BAPI

and IDocs are available as additional import techniques.

· Source structures: The name may have a length of up to 25 characters. Information on the

identification of a record is now found with the source fields. Now, you can also define several

structures at the top hierarchy level.

· Source fields: Now, additional field types for amount fields AMT1, AMT2, AMT3, AMT4 are

available. The record description of a structure can be comfortably transferred via the Copy

symbol from various sources: Upload from file, copy of another object, copy from Data

Repository, from data file (with field names in the first line). Fields for structures of the top

hierarchy level can be marked as selection parameters (for Import/convert data).

· Structural relations: The program displays the information whether a structure is a required

segment.

· Field mapping and rules:

¾ Display variant: You can select the elements to be displayed: Global data, processing times,

technical fields, initial fields, coding.

¾ Processing times: You can complete the ABAP coding at various times of data conversion.

In version 1.0, you used additional includes with user-defined routines.

¾ Field documentation, F4 help: Symbols per target field

¾ Source fields not assigned: Menu Extras à Source fields not assigned displays the source

fields that are not assigned.

¾ Additional conversion techniques via pushbutton: Prefix, suffix, transfer left-justified,

user-written routine

¾ Global functions: In addition to the functions transfer_record and skip_record

already available in version 1.0, other functions are available: transfer_this_record,

at_first_transfer_record, on_change_transfer_record,

transfer_transaction, skip_transaction.

¾ Editor: Check the coding for a target field; insert source fields, global variables, global

functions; Pretty Printer.

Legacy System Migration Workbench

· Comparison with Data Repository: No longer required.

· WHERE relationships: No longer required.

· Files: All definitions in connection with files are merged in the two processing steps Specify files

and Assign files. Here ‚*‘ may be used as wildcard.

· Import data: Replaces and enhances functions Spreadsheet Interface and Host Interface of

version 1.0. Now, you can use any combination of PC and server files. Date fields and amount

fields are converted into an internal or calculation format by default. If required, the file import

program generates itself again.

· Convert data: The data to be converted is processed target-oriented.

· Action log: All actions for an object are stored in an action log.

· Download/upload rules: Can now be carried out simultaneously for all parts of a project. The

dataset produced in this process is considerably smaller than in version 1.0.

· Display/change: In many functions you can switch between Display and Change.

· Documentation: You can store your documentation at a total of 25 levels. The total

documentation for a project can be further processed in hierarchical form.

· Recordings: Version 1.6 does not generate a data repository structure for a recording. The data

of a recording are stored in LSMW internal tables. There is no change from the user’s point of

view.

Legacy System Migration Workbench

12 Transfer of LSMW Data from Version 1.0 to Version

1.6

When transferring data from other systems, export them under version 1.0 and import them under

version 1.0 as well. To transfer data to 1.6, use LSM Workbench ® Transfer LSMW data from version

1 on the initial screen. The same applies to transferring data from the same system.

Normally all LSM Workbench data transferred using the standard procedure can easily be transferred

into version 1.6. Special features to be taken into account mainly concern advanced users who

already made complex modifications to the LSM Workbench during data migration with LSM

Workbench version1.0.

Please take into account:

· Version 1.6 no longer has a generation lock.

· User-written ABAP coding should be checked via syntax check.

· User-defined translation variants will be lost.

· Includes created in version 1.0 and included in the object attributes via flag should be transferred

manually.

· If you used perform skip_record or perform transfer_record so far, you can assign a

corresponding processing time to the coding now.

· The specifications for identifying source structures in files should be maintained subsequently è

this means: if there is data for more than one structure in a source file the specifications had to be

done via offset and value during the definition of the source structures; in version 1.6 the

specification is done via field ‘Identifying field value’ in the definition of the source fields

· After transferring the data from version 1.0, field mapping should be checked in any case.

· If you used recordings, you should switch to change mode for each recording and save the

changes there.

Legacy System Migration Workbench

13 Upgrade from LSMW 1.5 to LSMW 1.6

13.1 Notes on the Upgrade to LSMW 1.6

· All objects created under LSMW 1.5 are kept in LSMW 1.6.

· Transferring data from LSMW 1.0 to LSMW 1.6 is still possible.

· Transporting rules from LSMW 1.5 to LSMW 1.6 is possible. Vice versa, the specifications for the

files may have to be corrected.

· The file settings may have to be corrected. First, run program

/SAPDMC/SAP_LSMW_REPAIR_15 once, and check the settings (“Specify files”).

· Check the fieldmapping for EVERY OBJECT. If you have created coding for the processing

points __BEGIN_OF_RECORD__, save this. Then restore the default. Finally you can insert your

own coding again.

· All programs generated in LSMW 1.5 have to be regenerated manually.

13.2 Corrections

· Step numbering and welcome popup: Numbering On/Off –> Welcome popup is displayed

again: Error corrected.

· Interfaces of function modules compatible with 4.0: In some function modules, tables with

reference type are used. The entered type is a structure, however. This is tolerated in 4.0B. When

testing the individual function module, a syntax error is reported, however.

· Create change request: No authorization check: was added.

· Object attributes: When pressing F4 for standard BI/DI objects, objects with numbers < 8000 are

displayed only: Error corrected.

· Field mapping: Descriptions and documentation for target fields of IDoc segments were partly

not found: Error corrected.

· User-written routines: During creation, 1 input parameter and 1 output parameter were assumed

automatically. Now, these values can be entered in a popup.

· Display data read program, data conversion program: When one of these functions were

called before the corresponding program had been created, a termination occurred: Error

corrected.

· Display read data: On the detail screen, packed fields were displayed without decimal places:

Error corrected.

· Generate the data conversion program: Under certain conditions, the rules were confused:

Error corrected.

· Copy an object: F4 – Help for subproject, object, source structure did not work: Error corrected.

When the object contained wildcards, the copy process abended: Error corrected.

13.3 Developments

· Display <-> change: In the steps screen you can specify whether the program switches to display

or change mode when you double-click.

· Source fields: Field definition is now possible with table control as well.

· Field mapping, display attributes: Item __FORM_ROUTINES__ is displayed separately for

selection. Technical fields are marked with ruletype „Default setting“. The default setting can be

restored via Extras à Restore default. The processing point __BEGIN_OF_RECORD__ is preset.

Legacy System Migration Workbench

· Global functions: Additional global function transfer_this_record ‘XXXXX’, to transfer the

specified segment.

· Specify file: Standardization: File on the Frontend and files on the application server. All files can

(independent of the location)

¾ contain data for one or more source structures,

¾ have separators or not,

¾ field names at the start of the file (one record per source structure) or not,

¾ be a text or binary file,

¾ have a different Codepage.

· From application server: all Codepage

· From Frontend: ASCII or IBM-DOS

· Default file names for read and converted data: Blanks within a word are replaced by

underscores.

· Read data: Usage of sorted internal tables yielding a massive performance gain when “merging”

several files.

· IDoc inbound processing: You can now additionally specify a tRFC port. During data

conversion you can determine whether a file is to be created or the data is directly transferred in

packages to function module IDOC_INBOUND_ASYNCHRONOUS. (This function module

creates IDocs in the database.)

· Control program for periodic data transfer: Now also works together with wildcards (*) in file

names. Some important parameters of BI/DI programs are forwarded to the outside.

Legacy System Migration Workbench

AFS Transaction codes

3 Replies

/AFS/J5AI Source Allocation Schedule II
/AFS/LIEF_CHECK Delivery Check Report
/AFS/MCC AFS Mass Customer Change
/AFS/MCTE AFS SD Standard Analysis
/AFS/MD02 AFS-MRP: Single-item Planning
/AFS/MD04 AFS Stock/Requirements List
/AFS/MD06 AFS MRP List
/AFS/MD09 AFS Pegged Requirements
/AFS/MD4C AFS Order Report
/AFS/MDC Mass Data Change of Documents
/AFS/ME2A AFS Confirmation report
/AFS/MMCUST C MM customer-specific messages AFS
/AFS/MM_MP MM Missing Parts Lists- Subcontracti
/AFS/MRPBROWSER MRP Browser
/AFS/MRP_CR_STARTER Check Report Starter
/AFS/MRP_S430 AFS Quantity and Distribution Tool
/AFS/MSC2 Batch Revaluation
/AFS/MSOEX AFS MSO order explosion/log
/AFS/NDIF_CHANGECOVS Categ. Structure or Coverage Strat.
/AFS/NDIF_MAP_CONV Convert Dims to Characteristics
/AFS/NDIF_MASS_REORG Mass Deletion of AFS Config. Data
/AFS/NDIF_MASS_UPD New Dimension Mass Update
/AFS/NDIF_MAT_CLASS NDIF: create material class
/AFS/NDIF_MAT_UPD Mass Update Report
/AFS/NDIF_RUNTIME Mass Update – Runtime Versions
/AFS/NDIF_SET_CONF Set Configuration Indicator
/AFS/NDIF_SKU_VAR NDIF: create sku variant
/AFS/PIRMI Interface Flex.Planning / AFS
/AFS/PP01 Maintain qty distribution rule grid
/AFS/PP012 Check Quantity Distr. Rule Grid
/AFS/PRPK_DIST SD Quantity Distribution
/AFS/RS02 Maintain AFS Requirement Seasons
/AFS/RS03 Display AFS Requirement Seasons
/AFS/SA01 Cap Mass Data Changes I – Capacity
/AFS/SA02 trans for mass cap change dialog
/AFS/SA03 AFS Vendor Capacity Situation Report
/AFS/SA04 Capacity reduction after simulation
/AFS/SA05 Report for not assigned p.r.
/AFS/SEAS_TABLE_DISP AFS Display Season Condition Tables
/AFS/SPLITPO Change & Split PO, PO confirmation
/AFS/SS02 Maintain AFS Stock Seasons
/AFS/SS03 Display AFS Stock Seasons
/AFS/SSET_DISP Display AFS ARun Selection Set
/AFS/SSET_REORG Reorganize Selection Sets
/AFS/SUB_RULE ATP Substitution Rule
/AFS/SUB_T685_TS Assignment Text/Condition Type
/AFS/SUB_TVSU_V Substitution: ATP Locks
/AFS/SUB_TYPE Customizing Substitution Type
/AFS/T681F_JM Field Catalog Grid Determination MM
/AFS/T681F_JV Field Catalog Grid Determination SD
/AFS/T681F_KV Field Catalog Value-Added Service SD
/AFS/T681F_LV Field Catalog Season SD
/AFS/TAB_GENERATION ARun table generation
/AFS/TVAG Maint.Reasons for Rejection for AFS
/AFS/V_R2 AFS Rescheduling – analyse
/AFS/V_RA Back Order List
/AFS/WWW_PO_CONF Confirmation of Work Progress

IDOC Tcodes

4 Replies

SALE – IMG ALE Configuration root
WE20 – Manually maintain partner profiles
BD64 – Maintain customer distribution model
BD71 – Distribute customer distribution model
SM59 – Create RFC Destinations
BDM5 – Consistency check (Transaction scenarios)
BD82 – Generate Partner Profiles
BD61 – Activate Change Pointers – Globally
BD50 – Activate Change Pointer for Msg Type
BD52 – Activate change pointer per change.doc object
BD59 – Allocation object type -> IDOC type
BD56 – Maintain IDOC Segment Filters
BD53 – Reduction of Message Types
BD21 – Select Change Pointer
BD87 – Status Monitor for ALE Messages
BDM5 – Consistency check (Transaction scenarios)
BD62 – Define rules
BD79 – Maintain rules
BD55 – Defining settings for IDoc conversion

WEDI – ALE IDoc Administration
WE21 – Ports in Idoc processing
WE60 – IDoc documentation
SARA – IDoc archiving (Object type IDOC)
WE47 – IDoc status maintenance
WE07 – IDoc statistics

BALE – ALE Distribution Administration
WE05 – IDoc overview
BD87 – Inbound IDoc reprocessing
BD88 – Outbound IDoc reprocessing
BDM2 – IDoc Trace
BDM7 – IDoc Audit Analysis
BD21 – Create IDocs from change pointers
SM58 – Schedule RFC Failures

Basic config for Distributed data:
BD64: Maintain a Distributed Model
BD82: Generate Partner Profile
BD64: Distribute the distribution Model

Programs:
RBDMIDOC – Creating IDoc Type from Change Pointers
RSEOUT00 – Process all selected IDocs (EDI)
RBDAPP01 – Inbound Processing of IDocs Ready for Transfer
RSARFCEX – Execute Calls Not Yet Executed
RBDMOIND – Status Conversion with Successful tRFC Execution
RBDMANIN – Start error handling for non-posted IDocs
RBDSTATE – Send Audit Confirmations
For testing you can use WE19

Create and change SAP tables without coding or debugging

3 Replies

To create/change the content of a table (usually for test purposes), we typically use SE16 to write a report program or debug. But, with this tip, you can do it easily through a SAP standard technique without coding or debugging.Code:
1. Call transaction SE16N and enter the required table name to be edited(ex. KNA1).
2. type ‘&sap_edit’ in the command window and press enter key. The message ‘SAP editing function is activated’ will display.
3. Click on the execute online button (F8). Now the table will be in edit mode!

Unique Pricing condition

2 Replies

The pricing conecpt is built in SAP in such a way that there can only be one price in the sales document. So whenever there are multiple condition types (of condition class B Prices) in the sales document then by default system considers only the last condition type as active and the previous condition types will be made inactive. Since the conditions are inactive they would not add up to the netvalue of the document.

This does not apply for other condition types with condition class other than B (prices). Hence, all the discounts are considered in the net value of the document.

Configuring Batch Management

SAP SD Forum

SAP SD consultants brainstorming place

Author Archives: jiteshdua

Shipment Process

Batch Management

Standard SAP SD Reports

LSMW

AFS Transaction codes

IDOC Tcodes

Create and change SAP tables without coding or debugging

Unique Pricing condition

Configuring Batch Management