Understanding SD Credit Management integration settings for troubleshooting
Understanding SD Credit Management Integration settings for troubleshooting issues
It is often difficult to know where to start once an error has been identified on a system – With Credit Management, a better understanding of the configuration options, is usually all that is needed.
Define Automatic Credit Control – 101518
This configuration is broken down by Credit Segment, Risk Class and Credit Group. Credit group relates to one of the three credit checking points in SD – Sales Order, Delivery and Goods Issue. This allows customers to setup different configuration for each point of the sales process. They later assign the Credit Group to the document type – E.g.: when the system looks for CM customising against an ‘OR’ sales order type, maybe it selects Segment ‘1000’, Risk Cat ‘A’, CG ‘01’. Later, when a ‘LF’ Delivery is generated, Segment ‘1000’ and Risk Cat ‘A’ will be selected again but with another Credit Group; i.e. CG ‘02’ and so on.
‘Item check’ – A credit check is triggered as standard on the save, if this check box is ticked the credit check will be executed for every new item that is created.
‘Update’ controls when the values of open sales orders, deliveries, and billing documents are updated to the credit exposure.
Set Credit Limit Checks for Sales Document Types 102137
The credit check is activated against each document type individually. Here it is also specified, which Credit Group represents the document type.
Set Credit Limit Checks for Delivery Types – 101707
Similar to SSCUI 102137 – Since the Goods Issue is carried out in the delivery, the assignment of the ‘Credit Group’ to the Goods issue is also made here. The goods issue is the last stage at which the credit check is executed since after this point in the process the goods are already en-route to the customer.
Define Automatic Credit Control – 101518
When a sales order is released, the Credit Analyst releases the document based on the current document value; e.g. $1000. Since a credit check is triggered on every save, if a Sales Representative makes a small change on an already released document, the check will trigger again, and the sales order will be blocked once more. The fields highlighted above can control this behavior.
Deviation in % ‘ ‘ – This allows a sales documents value to be increased by a certain percentage without triggering another credit check. Example; a sales order is release by the Credit Analyst for $1000, there should be no restriction over adding another $50 so they allow a Deviation of 5%.
Number of Days ‘ ‘ – This field relates not to value but the number of days a sales document has been released. Example, a sales order is release by the Credit Analyst today, they aren’t concerned about a Sales Rep making non-monetary changes to the document for the next 7 days, so they allow ‘number of days’ – 7.
The credit value allowed (deviation) and number of days without a recheck (number of days) is calculated based on the fields set out in the customizing above and VBAK-AMTBL (value at time of credit blocked release). To decide whether the document should be rechecked the system looks at VBAK-AMTBL and adds the deviation percentage, then does a GE comparison. For the date of next check, the system takes the ‘Number of days’ configured in the SSCUI and adds it to the date that the document was released (VBAK-CMFE). It then does a GE comparison to check if the calculated date is GE the system current date (sy-datum).
Determine Active Receivables Per Item Category – 102571
The credit check is activated at two levels; document Header level (assigning the CG) and Item Category level. Without both being activated for a sales item, the credit check will not execute.
To know if a credit check had already been carried out on an existing sales order item, check database field VBAP- CMPNT.
Calculating the Sales Order Credit Value:
The calculation of the credit value is done from the sales order using two fields; the ‘Confirmed schedule line quantity’, which is then multiplied by the ‘Credit Price’ condition specified in the configuration step below:
Set Pricing Procedures 101117 (Trx V/08)
The condition that represents the credit price is set with ‘A’ – credit Price.
In order to identify which configurations to check, you first need to ascertain which Credit Segment, Risk Class and Credit Group is being used for the document. If these details are correct, the next step is to check the configuration of the credit check at document type level and item category level. For issues relating to the update of the credit values against the Business Partner, first ensure that confirmed quantities are filled correctly, then check settings for the Pricing Procedure – credit price condition.
Thank you for sharing!
this is a good insight into this topic. thanks for sharing Gerard Magorrian
A blog can't be cleaner, simpler, leaner and crispier than this one !!
This is what I call the rule of KISS - Keep Information Short & Specific
Thank you for this very helpful article,
I have a question regarding the screen of T-code = OVA8 (Automatic credit check configuration screen),
There are some fields missing on your screen, I was wondering if it was due to the integration with FSCM or there is a configuration that allows to show more/less fields on the screen ?
Thank you again!
Hi Meriem - This is an S/4HANA Cloud SSCUI screenshot.