cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

CCM - Statistical price condition in delta accruals

Miche1984
Explorer
0 Likes
1,197

 

Dear Guru,

We are implementing CCM in SAP S/4HANA and have encountered an error while posting delta accruals. In our scenario, we need to create a settlement document for delta accruals with a net amount of 0, where the accounting posting conditions are defined as "Statistical."

To achieve this, we have been conducting tests using the standard document (settlement document 0S42: Sales Rebate Delta Accruals and pricing schema A10006: Rebates Delta Accrual (Germany)) with the following configurations:

  • 0S42 – Section: "Accounting"
    • "Posting statistical condition to accounting" set to "YES (without cash discount)"
    • "Customer posting rules" set to "0A Accruals only"
  • 0S42 – Section: "Control of Account Determination"
    • "Account key source for material adjustment" set to "From Pricing Procedure: Accruals Account Key"
  • Schema A10006
  • RED1 set as "Statistical" and "Relevant for account determination"

When we created the delta accrual document, we encountered several issues:

  • RED1 does not have the "Accrual" flag, although RED1 refers to REA1 according to the standard guide (REA1 is flagged for "Accruals").
  • The account key for accruals is not triggered – instead, the system selects the account key for G/L.
  • When we attempt to release the FI document, the system indicates success. However, when clicking on "Accounting," no document is displayed. There are no dumps, error logs, or incorrect updates in the database.

Do you suggest any alternative approaches to resolve this issue?

Thank you

Michele

Accepted Solutions (0)

Answers (3)

Answers (3)

umasaral
Contributor
0 Likes

To resolve this issue, consider the following approaches:
1. Ensure RED1 Carries the Accrual Flag: Check if the pricing procedure correctly passes the accrual flag from REA1 to RED1.
2. Modify Account Key Assignment: Verify the pricing schema to ensure that the accrual account key is used instead of the G/L account key.
3. Custom Condition Type: If standard settings don’t work, define a custom condition type that explicitly enables accrual postings.
4. Adjust Settlement Document Configuration: Confirm that 0S42 correctly maps statistical conditions for accrual postings.
5. Check Account Determination Rules: Review settings in OBYC and VKOA to ensure correct mapping of accrual-related accounts.
6. Debug Account Determination: Use SLG1/ST22 logs to analyze missing postings and identify root causes.
7. Use a BAdI or User Exit: Implement BADI_SD_REV_ACC_DET to enforce accrual postings dynamically

umasaral
Contributor
0 Likes

To resolve this issue, follow these steps:

1. Manually Assign the Accrual Flag – Modify the pricing procedure to ensure that RED1 is flagged as an accrual condition or replace it with REA1 (which has the accrual flag).
2. Adjust Account Key in Pricing – Ensure the account key assigned to RED1 or RED2 correctly maps to the accrual account in OBYC.
3. Override Account Determination – Use User Exit EXIT_SAPLV60B_008 to force the correct accrual account assignment during FI posting.
4. Check Statistical Condition Behavior – If necessary, test with RED1 as non-statistical to confirm if FI posting occurs.
5. Debug FI Document Creation – Use Transaction VBREVE to analyze why no FI document appears.

For additional details, refer to [SAP Note 2826092](https://launchpad.support.sap.com/#/notes/2826092) (Accrual Condition Handling in Settlement).

Miche1984
Explorer
0 Likes

Dear Umasaral,

It seems you haven’t fully grasped the process we are involved in. We are working on the new CCM for sale (the note does not pertain to this topic, the user exit is not triggered during the creation of the settlement document).

Additionally, we are looking for a standard feature to ensure something was manageable by the SD rebate agreement. Based on this, when reviewing the customization of settlement document 0S42, I can see a set of variables that we can apply, but we may not be combining them correctly. Even when activating the statistical flag on RED1 (either in the price condition or in the related pricing schema), we cannot determine both account keys relevant for posting: only the G/L account key is being triggered. In addition, I can conclude that we cannot use the parameter to post accrual only (RED1 cannot appear as accrual in the pricing schema for delta accruals).

Thanks again,

Michele

umasaral
Contributor
0 Likes

Hi 

Your issue likely stems from the missing Accrual flag in RED1 and incorrect account determination. Try these steps:
1. Ensure RED1 is correctly mapped to REA1 in the pricing procedure and flagged as Accruals.
2. Activate the accrual flag for RED1 in V/06 (Condition Type Configuration) to ensure it behaves like REA1.
3. Verify the account determination settings in T-code OBYC (Transaction Key for Accruals) to ensure accrual-related accounts are triggered.
4. Check the posting configuration in 0S42, ensuring Posting Statistical Condition to Accounting is correctly set.
5. If the FI document does not generate, run ACDOCA checks to confirm statistical postings are processed.
6. Test with a new pricing procedure if issues persist, ensuring statistical conditions are correctly assigned.

Miche1984
Explorer
0 Likes

Dear Umasaral,

I completely agree with your assessment—the issue appears to stem from account determination and its relationship with accrual and statistical pricing conditions. We have rechecked the configuration for both price conditions and the pricing schema, and it aligns with what is outlined in the SAP documentation.

I believe achieving the desired outcome using standard functionality may not be possible. Document 0S42 is intended for delta accrual postings, even though the RED1 condition does not transfer the "accrual" flag in the pricing of the settlement document. Meanwhile, RED2 is classified as neither statistical nor accrual-related, and account determination is based on the account key for accruals.

Does anyone have suggestions for an alternative approach we could take to resolve this?

Best regards,

Michele