a month ago
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
Request clarification before answering.
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:
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
93 | |
11 | |
9 | |
7 | |
6 | |
4 | |
4 | |
4 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.