Setting of order reasons might lead to incorrect open delivery credit value update

Here I’d like to share with you a special case that I‘ve experienced recently.

After the root cause has been identified, I would say it’s a field that I have never realized before about
its effect upon the credit value update in SD credit management. Usually we just set this field in the sales document based on its description, without considering too much about the meaning behind it.

And just because of this, my customer did not even pay any attention on choosing the same option for this field during testing, which also explains why it’s so difficult to reproduce the problem even though they had tried to recreate the same scenario with the same data for multiple times.

After this experience, I think it’s really worthy to draw your attention on the settings behind this field.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

This is an example for the credit account with wrong credit value update.

Result from report RVKRED88:

Check the sales value in FD33:

Obviously, there’s difference in open sales value between FD33 & RVKRED88, which means credit value update error exists, to be more specific in the open delivery value. An unexpected negative open delivery value is left in S067.

In order to identify the documents which caused this negative open delivery value, I’ve tried T-code: VKM4 which can list out all the SD documents under certain combination of Credit control area + Credit account + Risk category

At the first glance, the documents with document category K(Credit memo request) & H(Returns) look more interesting for me as they hold the negative credit value during the processing.

After checking further on each of those documents, the return order 60000102 looks perfect for what I’m looking for, as its credit value is exactly the same as the inconsistent credit value left in open delivery: 119 EUR

In the pricing procedure, subtotal line “Total” has been set with SuTot “A   Carry over price to KOMP-CMPRE (credit price)”.

Check doc flow:

Besides it’s a delivery-related billing return process, nothing special.

What I’m thinking now is if it’s possible to reproduce the open delivery value update error by recreate the return delivery? So I tried to cancel the billing (return credit memo). While before I proceed to cancel goods issue, I took a look at FD33 again, and I noticed one thing:

Open delivery credit value is NOT updated after billing cancellation!

It’s supposed that open delivery value should get increased after the subsequent billing is cancelled. (For return process, the credit value is negative, therefore it’s supposed that open delivery value should increase 119,00- EUR after the billing cancellation)

From this time point, I started to suspect that credit value update error occurs during billing processing instead of delivery processing.

As next step, I tried to create a new billing reference to the same delivery again. At the same time, I set breakpoint in LMCS6F10 (invoice) at the Perform CMPRE_CALCULATE to check the credit value update during saving of billing:

The open delivery credit value to be updated has been calculated correctly from CMPRE_CALCULATE. However it gets cleared in the next part of standard logic where there’s an IF statement checks whether there’s “Order reasons”(augru_auft) being set in the return order, and whether this Order reason has been customized as Used for retro-billing “1   credit/debit memo request used for retro-billing”.

Unfortunately, in this example return order has been set with “Order reasons”(vbak-augru) 102, which is customized as used for retro-billing(tvau-vauna) “1”. As a result, the determined open delivery credit value (owv_mcvbrp-olikw) gets cleared by the standard logic!

Order reason 102 is set in return order:

Here’s the place to customize “Order reasons”:

How to understand the above part of standard logic and standard customizing for Order reasons?

The retroactive billing indicator for order reason is only designed for retro-billing process. In the real retro-billing scenario, since the request is used for retroactive billing, only price changes of quantities already billed and no quantity changes are processed here. From the credit point of view, the entire process has already been approved, the previous processes (sales order/delivery/billing document) have generated and reduced the credit values correctly. Therefore, from a credit point of view, the request does not have its own credit value.

The suggestion is please never use an order reason with retro-billing indicator “1” for a normal SO -> delivery -> billing process or any standard credit memo/debit memo/return process with billing relevance as delivery-related billing . During delivery processing, the credit value is updated in S067 but it’ll never get deducted in the subsequent billing processing, and it’ll cause incorrect values left in open delivery credit value.

For more details, please also check SAP Note 626880. The note also offers a check report which can search for the orders that using the order reasons incorrectly in your system.

After I explained all of these to my customer, I got the feedback from them that the end user confirms he’s no idea about the setting of retro-billing indicator behind order reasons at all, he just unintendedly chose the corresponding order reasons based on its description when entering this return order.

Hope the above sharing could help you avoid the similar credit value update issue caused by unintended incorrect use of order reasons. ????

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 

As additional info, if you’re interested in how does the retro-billing indicator of order reasons work in retro-billing scenario, you may check the following SAP online help: 
Order Reason in Retroactive Billing