CCM : delta accrual after partial settlement

[OlivierLeroux]

Hi Comunity,

I am wondering why standard sap behaves the following way :

1. I create an invoice

2. I create a Condition contract that should have had covered this invoice

3. I create another invoice, same as 1., so that CC created at 2. is dully called (accruals REA1 ok)

4. I do a partial settlement, all ok, invoice 1. and 3. considered, accruals from 3. cancelled.

5. I run a delta : SAP created accruals for invoice 1. IMHO, it should not, as this invoice is already covered by partial settlement.

Any idea what I could be doing wrong ?

- I tried to create a delta before the partial at step 4.: It does contain values for invoice 1., ok. But still same result, accruals recreated after the delta.

- I checked WCOCOF entries, they look ok

- I tried both with an automatic document (WZR1 based on proforma) and manual one (WB2R_DOC_ENTRY), results are the same

Thanks for your help !

Regards, Olivier

[OlivierLeroux]

Thank you both @thorsten_kraemer and @gvictor . My two issues were :

1. missing conditions in my pricing procedures: I still dont know why, but that is not the topic. 

2. misunderstanding how the condition work together

I am still wondering how I could get during partial settlement a "partial reversal" of accruals corresponding only to the part paid out to customer. Then no additional accruals are to be posted during further delta. 

I need to digest information received before opening a more specific question on that topic alone if I still cannot make it work.

Regards, Olivier

[gvictor · Accepted solution]

Hi @OlivierLeroux, 

It looks like you’re using new custom condition types for accruals, rebates, and reversals. I recommend reviewing your condition type configuration, pricing procedures, mapping for reversals, and the overall condition contract setup.

There’s likely a configuration issue causing the discrepancies.

For reference, here’s an example of header pricing for a Delta Accrual #2 with the standard configuration:
Sequence: DA #1, then Partial #1, followed by DA #2.

In the example above: 
- RED1 activated
- RES2 represents the amount already settled from partial settlement 
- RED2 represents the amount already accrued 

Total of this document = 32.91 (RED1 + RES2 + RED2)

I also agree with @thorsten_kraemer  here. The logic process you’re executing is not part of the SAP best practices, and I don’t see any added value in creating a Proforma and then a Settlement document for posting with reference functionality. I would not recommend this approach.

Regards, 
Gauthier Victor

[OlivierLeroux · Accepted solution]

Hi Victor,

Thanks a lot for helping, sorry for not coming back to you earlier.

1. thanks to your answer and Thorsten one, I could find the main issue. As mentionned, we had major discrepancies between standard and our pricing procedures. They were like that when i arrived here. They are corrected, thanks to https://me.sap.com/notes/2535889/E

2. your sequence "DA #1, then Partial ##1, followed by DA #2" works : My issue is when we do not make a DA before the settlement: Is it mandatory ? Because if you miss some accruals in Partial, following Delta will, in some way, re create it.

If during partial no accruals are reverted, in routine 91 of REA5 I have that line

e_xkwert = - is_komp-kzwi2 - is_komp-netwr.

if KZWI2 (accrual reversal) is null, then xkwert (value of REA5) is negative and that sets REA5 to 0 later

I would expect REA5 to be equal to netwr, what was paid to customer, shouldn't it ?

I think REA5 is used to calculate RED2 during delta, at least that is what I see during my tests.

If you feel I should close that thread and open another one, just ask.

thanks again, Olivier

[gvictor · Accepted solution]

Hi @OlivierLeroux ,

If you review the following lines in routine 91, you'll notice that the value e_xkwert will be cleared if it is lower than 0 when abap_false.

- REA2 represents the open accrual amount that will be reversed.
- REA5 is used to retain the remaining part of accruals, particularly when the open accrual is greater than the settlement amount in a partial settlement.
- For automatic settlement, REA5 should not be populated if REA2 is not populated either.
- REA5 is NOT used to calculate RED2. RED2 is representing the amount of accrual already posted from previous documents (source document or delta accrual) for this specific line item. 

To understand the specifics of each condition type, I recommend going through the configuration guide document mentioned in the KBA you referenced.

[thorsten_kraemer]

Hi Oliver, 

what do you mean with ‚WZR1 based on proforma‘? This has nothing to do with the standard process.

The delta accrual process is elementary and works perfectly with the standard delivery.

Please review your settings and refer to standard documentation.

Regards,

Thorsten

[OlivierLeroux]

Thanks Thorsten,

‚WZR1 based on proforma‘:

--> I create a proforma with WB2R_SC --> that is due to option "settlement type customer", found at condition contract header level in WCOCO, tile "Settlement data", value "4 Proforma as account receivable". Then, I copy the proforma to settlement document with WZR1 - "create with reference", settlement doc type "0S12 Sales Rebate"

I will try without proforma see if results are the same

Thanks again,, regards, Olivier

[OlivierLeroux]

I made atest without Proforma: same results

here some details hopefully you can spot something missing :

delta accruals before partial : logical, one line of delta accrual corresponding to invoice1.

item 1 detail

then the partial cancels accruals: (header view), that is very fine.

but then delta accrual generates new accruals:

item 1 details:

Item 2 details

Any idea what Imissed ?

Thanks !

Regards, Olivier