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.