Condition Contract - Distribution process

[Miche1984]

Dear Guru,

We need to manage the following requirements through Condition Contracts functionality (already live since 2020): posting a "Customer Credit Note" via the "Manual Settlement" process (i.e WB2R_DOC_ENTRY), along with an "Accrual Adjustment" condition (i.e ZXXX), when the "Settlement Amount" (i.e RENT) > "Total Accrued Amount" (i.e REAT).

The purpose of the "Accrual Adjustment" condition (based on custom Alternative Calc. of Cond. routine) is to automatically post in FI an "Accruals Adjustment" when the settlement amount is higher than the "current open accruals".

Unfortunately, the custom routine does not properly work when the Settlement Amount is applied at the Product Hierarchy level, as the ZXXX condition is always determined (together with the other conditions) as soon as the amount is distributed (i.e "Distribution Based on Accruals") at the SKU level, as a difference between RENT & REAT.

Given that, we could face the following wrong behavior:

RENT = €1.000 applied at Product Hierarchy A

REAT = €1.200 from Product Hierarchy A

When the amount (at the main item level) is distributed at the SKU level, it can happen that:

SKU1: RENT = 600 // REAT = 700 // ZXXX = Not required, as RENT < REAT (OK)

SKU2: RENT = 300 // REAT = 450 // ZXXX = Not required, as RENT < REAT (OK)

SKU3: RENT = 100 // REAT = 50 // ZXXX = Required, as RENT > REAT (KO)

Basically: as the pricing is determined at the "sub-item level", the custom routine is applied even when not required, when REAT > RENT, at the Product Hierarchy level.

Our question is: is there a standard approach to calculating the ZXXX condition value defined at the main item level (before applying the distribution), and then redistributing the ZXXX amount across SKUs during the distribution process? Typically, pricing at the main item level is not active.

Thank

Michele

[GauthierVictor]

Hi @Miche1984, 

I’m curious about the need to post the difference in accrual separately—is there a specific reason for this approach? Would it not be more effective to apply the logic of reversing open accruals only up to the net settlement amount?

It is now possible (though I don’t recall the exact version in which this was introduced) to restrict the system from reversing more accruals than the net settlement amount in a manual settlement process.

To apply this logic, you need to:

1. Maintain Routine 91 in the manual pricing procedure for the REA5 condition type (or its equivalent).
2. Activate the relevant setting in the Process Variant configuration (see below).

Another approach would be to add that logic to reverse open accrual up to net amount in a custom routine in copy of 91 only for manual settlement, if the above solution is not possible for existing live contract. 

Regards, 
Gauthier VICTOR

[Miche1984]

Dear Victor,

Thank you very much for your contribution, and apologies for the late reply — we took some time to evaluate how to apply your suggestions.

To reply to your questions:

• reason for this approach? M: it is based on the business requirement to do not post the settlement if open accruals are not sufficient. Therefore, the process would be: 1. to adjust the accruals; 2. to post then the settlement. Purpose of the custom routine is to get this two steps in one, without any manual input.
• Would it not be more effective to apply the logic of reversing open accruals only up to the net settlement amount? M: if we apply that new setup, how then they can get "missing Accruals" automatically posted, if any?

  Therefore: it is not clear to me how the solution you're suggesting should cover that requirement.

  Moreover, as additional scenario which is not covered at all: since our current Distribution Category is = 3 (std - Based on Accruals), how a manual settlement can be posted if there are no Accruals, given SD source volumes are totally absent due to a small lag between Accruals execution vs Payment execution? Should we enhance the Distribution Category applying a kind of "fall-back" logic, which also looks at a distribution based on "Settlement Documents" when there are no Accruals? Are there other std. ways to handle this scenario?

  Thanks again

  Michele