Recently I encountered a custom development (developed a couple of years ago) in my client’s ECC system where I noticed that the custom program made use of a BAPI (Business Application Programming Interface) to modify a stream of sales orders. The functionality which the business intended to achieve was pretty simple and straight-forward. The custom program was executed as a background job on a daily basis to update the delivery date field based on the business logic placed in the program. This could be the simplest program you have seen in your career, where the program fetches the relevant sales order numbers -> uses the BAPI ‘BAPI_SALESORDER_CHANGE’ to modify the delivery date in the sales order item -> voila !! the requirement is complete.

Could the requirement be any SIMPLER !!!!

However, what came as a surprise was that in some cases, the sales orders had a re-pricing carried out, which was perplexing as there was no explicit mention of re-pricing in the program or in the BAPI.

Time for me to pitch in and figure out what’s going on here !!!!

I nose-dived into the program to fathom what the program was up to. Experience shows nothing is impossible in SAP, and I continue to believe in the same.

Hours went by analyzing the program, the BAPI_SALESORDER_CHANGE in particular. I found an interesting parameter ‘LOGIC_SWITCH’ which could be passed to the BAPI. The structure LOGIC_SWITCH has a component ‘PRICING’ which indicates the Pricing type to be carried out. Digging further into the possible values which can be passed to this component, I found the following exhaustive list.

A Copy price components and redetermine scales
B Carry out new pricing
C Copy manual pricing elements and redetermine the others
D Copy pricing elements unchanged
E Adopt price components and fix values
F Copy pricing elements, turn value and fix
G Copy pricing elements unchanged and redetermine taxes
H Redetermine freight conditions
I Redetermine rebate conditions
J Redetermine confirmed purch. net price / value (KNTYP=d)
K Adopt price components and cose. Redetermine taxes.
M Copy pricing elements, turn value
N Transfer pricing components unchanged, new cost
O Redetermine variant conditions (KNTYP=O)
Q Redetermine calculation conditions (KNTYP=Q)
R Apply Price Parts and Bonus Conditions
U Redetermine precious metal conditions (KNTYP=U)
S Ship & Debit  (IBU HiTec)

and then there were a handful of those reserved for the customer to configure.

This was the moment, and this list was the key to my issue at hand. This clearly mentions the options to be passed to the BAPI for pricing options. This could be my answer.


To confirm whether this pricing component would actually help, I went ahead to modify the custom program and passed a couple of the above mentioned options, one by one, and one by one did I strike them off as not useful.

From a point where ‘I almost found the solution’ to ‘back to square one’.

After a few more hours spent on the analysis of the BAPI, it was time to take on a different approach to the problem. Could I try using BDC (Batch Data Communication) to modify the sales orders with the correct date value? This shall definitely not re-price the sales order item and thus eliminate the issue. But, is this the optimal solution? SAP is a gigantic ocean and there ought to be a better solution. At least something simpler than a BDC, please.

Okay, let me look at any other Function Modules / BAPIs provided by SAP to modify data in sales orders. This search led me to ‘BAPI_SALESDOCUMENT_CHANGE’. This one does not have any fancy parameters to pass the pricing related data, will it help? Let’s search on SDN, and I tried to search the difference between the functionality performed by ‘BAPI_SALESDOCUMENT_CHANGE’ and ‘BAPI_SALESORDER_CHANGE’. Frankly I did not find any clear-cut distinguishing factor, let alone my re-pricing issue. But I have no option, I have to try each alternative I have in hand. Fancy or non-fancy,  had to try out this BAPI in the program.

Is this magic or the solution !!!!

On modifying the program with the BAPI_SALESDOCUMENT_CHANGE, and carrying out multiple tests on the program, it was confirmed that the change in the BAPI was the solution to my problem. However, I still don’t see any documentation anywhere (in SAP or on the worldwide web) which mentions which of these two BAPIs is to be used under which kind of scenario. How do these two BAPIs differ in the way they have an impact on the sales order changes?

The only major answer I found until now is that one of these does not cause re-pricing in the sales order, and that has solved my problem for the time being.

Do comment if you have come across a situation where you had to choose between BAPI_SALESDOCUMENT_CHANGE and BAPI_SALESORDER_CHANGE, and what factors were considered in making the choice.

To report this post you need to login first.

2 Comments

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

  1. Joe Valliparampil

    I too faced this problem and resolved it using the BAPI_SALESDOCUMENT_CHANGE. No clue yet as to why the LOGIC_SWITCH doesn’t work. I also checked the notes below but still no luck to figure out the root cause.

    1)   649121 – Prices redetermined although pricing type ‘G’

    2) 1424875 – New pricing for CRM service documents in ECC

    (0) 
  2. Carlos Andres Gonzalez

    Hello Joe and Dawood,

    My requirement is to add a new item to sales order with manual pricing conditions, so I tried to do that with BAPI_SALESORDER_CHANGE.  The issue is with PRICING, because after excecute this BAPI, return table says “Item incomplete”, viewing sales order on VA03, all is right, PR00 is in place, but “Incompletion log” says “Position 020 hasn’t net price”. I tried all posible values  in LOGIG_SWITCH without success.  If delete manually PR00 and recreate it (VA02) all works.

    Any idea guys?  thanks in advance.

    Carlos Andres.

    (0) 

Leave a Reply