Skip to Content

Not often the BAPIs are fully understood for their functionality. This results in a quick-fix solution particularly for SAP data migration, which then needs to be supported with a subsequent update to the newly created object. I will illustrate this problem and also give a solution to avoid rework in Purchase Order (PO) BAPI.

Problem statement: If you are using the PO creation BAPI namely BAPI_PO_CREATE1, you will find the net price you pass into the LSMW via IDOC does not carry through into the newly created PO. Rather it adopts the Purchase Info Record (PIR) price for the material, plant and vendor combination.

Now typically in a data migration environment, I have found consultants workaround this by loading the PO through the BAPI as a step 1 and then a step 2 will be to update the PO price via another LSMW with a recording. This is additional effort and time and if the PO volumes are in tens of thousands, you will be wasting a lot of important cutover weekend time, thus adding to the risk!


There is also another dimension of challenge if the PO Version Management is activated for the net price field. This will mean you will not be able to update the net price so easily via recording on the PO unless you involve the MM functional consultant and maybe the business teams as well. See the snapshot below for the configuration piece on the version management within POs that can be enabled.

Blog_06Jun16_01.jpg

Correct solution: When I saw the situation at a client site where they were loading this PO data based on the “2 step process” as mentioned above, I was not really happy with it. Sometimes better solutions arise when you do not accept the workaround and look for the accurate solution in the design / build phase and spend some time on understanding the full functionality of the BAPI.


What I realized was that the BAPI BAPI_PO_CREATE1 has a field on the item level “PO_PRICE”. See the IDOC hierarchy within the LSMW as shown here below.

Blog_06Jun16_02.jpg

When you dig deeper on the functionality it provides it allows a toggle between adopting a PIR price (value = 1) or a PO price (value = 2). This is also documented in the SAP OSS note # 580225 ( https://launchpad.support.sap.com/#/notes/580225 ). As usual, this OSS note requires a S-User login.


See the snapshot of the LSMW I modified to adopt the PO price directly from the load file thus overruling the PIR price.

Blog_06Jun16_03.jpg

The documentation on the field itself is a bit confusing (says 2 = net and 1 = Gross) but the OSS note does give a clear picture of what those field values do. With this simple solution, I was able to significantly reduce the PO load complexity and also the time taken to complete the load. With the combination of the strategy to load PO’s via LSMW / BAPI which I have in this blog, LSMW Optimization Whitepaper  , you can load PO’s optimizing the work processes available on your SAP application server!



To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply