Executive Summary
An important exercise during SAP implementation project cutover is Purchase Order (PO) migration from legacy to SAP. The legacy POs may be in various stages of processing. Some might be partially delivered while others might be partially invoiced. The scenario becomes challenging as the corresponding stock postings for such histories is already posted in legacy. While businesses would like to bring these histories into SAP they would not like to post to stock accounts or update stock quantities in the material master however they would like to post to GR/IR clearing accounts to record all open items.
This blog discusses proven SAP standard solution of open PO upload with history based on live project experiences and proposes some practical check points and processes to ensure a seamless PO history upload in SAP.
Note: Sound understanding of SAP MM-FI integration is a pre-requisite to this reading.
Business Requirements
During cutover of purchase orders from legacy to SAP businesses face challenging requirements with respect to transferring histories of the purchase orders to SAP. Legacy POs could be carrying varied PO histories as mentioned below:
Open POs
Partially Delivered POs (partial GR done)
Partially Invoiced POs (Partial IR done)
In general, businesses are suggested to close all open POs in legacy and not to bring any histories along in SAP. However in some cases the PO histories become mandatory for businesses. The challenge in such cases is to bring the histories without creating any stock posting while still posting the open items in GR/IR clearing accounts along with its contra postings.
SAP Standard Solution
SAP provides standard programs to upload POs along with their histories from legacy system. It is possible to transfer open, partially delivered, and partially invoiced POs from legacy to SAP. The set of programs operate to load the PO master as a first step followed by history and item text uploads. During this process, the SAP standard automatic account determination and postings to stock and GR/IR clearing accounts based on OBYC setup is circumvented by SAP and postings are done to a user specified GR/IR clearing account (which is open for non-automatic postings) and contra accounts. Dedicated for this upload process business users need to provide the following accounts:
GR/IR Clearing Account
Contra Account Vendor Items
Contra Account Goods Receipt
The relevant accounting entries posted during cutover are as follows:
1) At the time of Inventory upload (as conducted using separate upload tool)
Inventory account Dr
Inventory Upload A/c Cr
2) At the time of PO History upload (using the process discussed in this whitepaper)
a. Partial GR carry forward from legacy to SAP
Contra Accounts GR Dr
GR/IR clearing A/c Cr
b. Partial IR carry forward from legacy to SAP
GR/IR clearing A/c Dr
Contra Vendor A/c cr
3) Vendor balances upload (as conducted using separate upload tool)
Contra vendor A/C Dr
Vendor A/c Cr
Note that the PO history upload SAP programs do not post to stock accounts or create any material quantity updates in material masters during this upload process.
Business Benefits
Clean open item migration from Legacy to SAP with desired PO history
Clear Audit trail
Standard SAP solution
Detailed Mechanism
The transfer of POs is affected via the data transfer workbench using the following programs in the sequence as presented:
The steps to be followed for the upload are as listed below:
Step 1: Create a sequential LSMW using Programs mentioned above:
As a first step Program "RM06EEI0" (upto 4.6c) and BAPI "BAPI_PO_CREATE1" (for all versions after 4.6c) are used to create PO headers in SAP. These programs are used at the time of LSMW creation as shown below:
This LSMW requires a sequential data transfer relation. PO header gets transferred first followed by PO line item in a sequential manner. Per PO header, a record of the structure MBEPOH is created and per PO item, a record of the structure MBEPOI is created. Each PO line item attaches itself with a PO header item and hence the structure relationship that gets created in LSMW is as shown below:
Note: Detailed source structure for a quick reference is available from the author over mail.
Rest of the steps of LSMW creation process remain same as any other LSMW.
Step2: Define Number Range for PO Upload- OMH6
As a best practice it is recommended to define a unique external number range for ease of identification of legacy purchase orders Vis-a-Vis purchase Orders created in SAP after go-live. Note that this is a client open activity.
Step3: Upload file to Logical Destination (SAP Application server)
The PO upload file is usually very bulky and hence need to be uploaded on the SAP application server by BASIS team for the LSMW to pick it up . SAP standard transaction CG3Z cannot be used to upload the file on application server as it has been observed that the upload files get truncated due to beyond normal file size.
Note:Sample upload file is available from the author over mail.
Data preparation for this upload file needs to be done with the following checks in mind.
Step4: Check Uploaded File in application Server-AL11
As a sanity check the upload file destination should be re-verified on the application server.
Step5: Display Transfer file (Optional)-OMQ5
To locate possible data errors in the upload file display the content of the sequential file in structured form using transaction OMQ5. Changes to data structure are possible at this instance.
Step6: Deactivate Statistics Update (Optional)-OM02
Deactivate the statistics updating process in order to reduce the runtime of the programs for transferring purchase orders
Step7: PO Master data Upload
Execute the LSMW created in Step 1 using the upload file on the application server.
Check that the PO headers are created in the backend but not yet released post the LSMW upload. No histories exist at this instance.
Step8: PO History Upload-SA38 (RM06EEI1)
As a next step, PO line item uploads are conducted using program RM06EEI1 as shown below:
Note:
File Name: is the application server address of the upload file that has been uploaded in step 4
Without database update: This is for doing a test run. No documents get posted when the program is executed in this mode. It is recommended to conduct this run to check any possible errors ahead of the actual update run.
With Database update: This run updated the PO history and created accounting entries as applicable. It shows a log of the activity indicating POs loaded successfully, POs with error as well as the detailed reasons for the errors. It needs to be scheduled in the background. An upload file with approximately 6000 line items takes about 5 minutes. The SAP MM tables EKKO and EKPO tables get updated during this run.
GL Accounts: GR/IR clearing account, Contra account for Vendor items, Contra accounts Goods receipt are GL accounts to be provided by business and to which accounting postings are expected due to the PO history upload.
Document Types: Specify the SAP document types which are intended to be used for the above postings.
Scope of Error log: Choose "log with error message" to get detailed errors log for failed cases. Note that for POs which fail during their history upload even the PO header is not created. The POs with error can be corrected and a second upload with only the delta POs can be executed.
Step 9: Conduct a sample data check:
Post the upload, it is recommended to check some sample POs for each detail and the accounting documents posted. For detailed check EKKO, EKPO table from MM side, Documents posted in accounts provided by business for this purpose can be analyzed.
Step 10: Deactivate ext number range for PO- OMH6
Post the upload it is mandatory to deactivate external number ranges so that the same don’t get consumed in Post go-live PO creation process.
Conclusion:
SAP’s solution for PO history upload has been used successfully in large multi-country implementations with a mandate to upload PO histories from Legacy to SAP for various business reasons. The setup for this upload is a one-time exercise with full reusability for each successive roll-out. A clear strong point of this upload process is the ability of this functionality to check errors ahead of actual database update. This gives users the ability to make corrections and allow only correct values to update SAP database.
Referenceshttp://help.sap.com