Classic Credit Management Retired for FSCM Credit Management

Classic ECC behaviour

S/4HANA behaviour

Project impact

• Custom ABAP built on the classic credit check exits or on the old credit master and information structure tables stops receiving current data, because those tables are frozen once FSCM Credit Management is active, and the exit points they hung off may no longer fire.
• Custom or legacy reports that read the old customer credit master tables or the SIS-based exposure structures directly return stale or zero values after cutover, which is often only caught when someone reconciles month-end credit exposure and finds it does not match what the business sees.
• The blocked sales order release process changes from the VKM* worklist habit to a different app; order desk staff trained only on the old transactions cannot find or release blocked orders on day one.
• Authorization roles built around FD32, OVA8 maintenance, and VKM* transactions no longer cover the new credit master maintenance and release apps, so credit analysts either lose access or retain access to transactions that no longer do anything useful.
• Any interface to an external credit bureau or scoring service that was wired into the classic user exits needs re-pointing to the FSCM BAdIs or rule framework, and the mapping of exposure categories may not be one-to-one with the old fields.
• Risk category and credit limit values that lived only on the customer master and were never mirrored to a business partner go missing for customers who were never converted through customer-vendor integration.

Migration actions

• Confirm every credit-relevant customer has a business partner via customer-vendor integration before touching credit data; this is the hard prerequisite and blocks everything downstream if skipped.
• Run the SAP-delivered migration step to move credit control area assignment, risk category, credit limits (central and individual) and credit representative group data from the classic customer credit master into the business partner credit segment.
• Rebuild custom credit check logic using BRFplus rules or the exposed credit management BAdIs rather than the old user exits; a straight lift of the old ABAP will not compile against a framework that no longer exists in the same shape.
• Re-map any bespoke exposure logic (special liabilities, guarantee values, manual credit blocks) into the new exposure categories and confirm the totals reconcile against ECC before cutover, not after.
• Rebuild reports and dashboards that read the old credit tables against the new business partner credit segment and exposure data sources.
• Redesign the blocked order release process around the new app, retrain the order desk and credit team, and reissue authorization roles built for business partner credit maintenance and release rather than FD32 and VKM*.
• Run a parallel exposure comparison for at least one full month-end cycle before go-live, since exposure timing and category boundaries rarely match the old logic exactly on the first attempt.

Whose problem this is

Common pitfalls

• Test systems often carry a handful of business partners maintained specifically for the test script, masking the fact that the bulk of the customer base was never converted through customer-vendor integration; production cutover then surfaces customers with no credit segment and no block, letting orders through with no limit check at all.
• Exposure recalculation that runs fine against a small test dataset can run materially longer against full production volumes, so credit-blocked orders sit unreleased for hours at month end when the business needs them cleared fastest.
• Static OVA8 rules that encoded years of small exceptions (specific document types, specific sales organizations, one-off customer overrides) get simplified during BRFplus rule building because nobody remembers why the exception existed, and the gap is only found when a customer who used to sail through starts getting blocked, or vice versa.
• Authorization roles for the new business partner credit apps get created late, so the credit team can see limits but cannot release blocked orders, and the order desk escalates daily until roles catch up.
• Old reports against the frozen credit tables keep running without error, quietly returning outdated numbers, and get treated as authoritative in a management pack until someone notices the totals have not moved in weeks.