As we recently embarked upon a credit-revamp exercise (basically deals with consolidation of risk categories and credit representative groups to an optimum level by doing away with non-relevant ones based on changed business needs) for one of our clients in Chemical Industry, I have collated some of my key learnings/testing-based observations on credit management.
This can be a useful reference for entry level SD consultants working on similar requirements. They are enlisted below:
- Risk Category is one of the key parameters (maintained at an individual customer level in credit master under FD32) in determining the type of credit checks to be carried out when processing orders in a typical order-to-cash cycle
- Risk category influences the way automatic credit control is run for a sales document. It works in unison with credit control area and credit group. In essence, in OVA8, settings for automatic credit control are defined for a combination of credit control area, credit group and risk category.
- When a risk category or credit representative group is deleted/modified for a customer, credit re-org is recommended (i.e. through standard programs RVKRED09 etc.)
- When risk category for a customer is modified, the new risk category shall reflect only for the subsequent new orders to be created. (i.e. for the same customer) Effectively, the old risk category determined at the time of sales order creation (updated in VBAK table, field CTLPC) gets copied to subsequent documents like delivery. (updated in LIKP table)
- For all older sales orders (i.e. which are not completely processed yet and created before risk category change for customer) , the credit check still gets evaluated based on the old risk category. To sum it up, automatic credit check for open sales documents runs on the configuration settings settings maintained in OVA8 for the combination involving older risk category
- The Credit Horizon Date for a customer in credit master (FD32) gets updated based on the Horizon defined for dynamic check under automatic credit control. Though this field is active (not greyed out) in FD32, the changes made to the same shall not get registered. ( as the value gets dynamically determined through horizon period maintained in OVA8)
- Through program RVKRED09, credit check for released documents is evaluated only when their release validity is expired. This validity is set through ‘Number of Days’ (table T691F, field TAGEF) defined under Automatic Credit Control (OVA8) under ‘Released Documents are still unchecked’.
- When a sales order is created, if no confirmation (partial/complete) happens to the quantity ordered (can be checked under item level -> schedule lines), updating of Credit exposure shall not happen for the related customer. This is due to credit check not being completely run in such scenario.
- Also, similar to quantity confirmation, delivery blocks in the form of ship-to, ship-from etc. under schedule lines shall lead to credit exposure not getting updated to customer (for a sales scenario)
