Many users of SAP ERP Central Component (SAP ECC) have questions about best practices to perform credit data reorganization, and so I have written this article. To protect your business against the high cost of nonpayment, your credit department needs accurate and timely credit data. SAP provides standard functionality that can cover a multitude of scenarios; however, the credit data update is susceptible to glitches that require periodic reorganization of the credit data. If credit update errors occur, you have different options for recreating the credit data (e.g., run one of SAP standard credit reorganization reports, which I will discuss in detail later in this article). Also, there are certain analyses of credit data (e.g., customer credit exposure breakdown by sales and distribution document) that are not as easily obtained as expected. I will discuss some of these issues in the article.  

Credit Management Overview

The SAP credit management functionality primarily resides in the sales and distribution (SD) module, but from a business process perspective, the finance team is more interested in it than the sales team. Often analysts from the SAP finance team take responsibility for this functionality based on end-user interest.

Customer

The word customer in relation to FI-AR is pretty clear, but in SD, a typical sales order has four or more related customers: sold-to, ship-to, bill-to, and payer. In credit management, customer means the credit account customer (the SAP system assigns a number when the customer master record is created), which can be a different customer number from the four key SD customer types. Often, the sales order payer customer and credit account are the same, but not always. In simple cases, all five customers can be the same, but when you are looking at companies with complex customer relationships, all five might be different.

Credit Values 

To view the key credit values use transaction FD32 or FD33. Go to the status view to see the balances (Figure 1). In the case of the sales value, you can use menu option Extras > Sales value to break down the information by orders, deliveries, and billing documents (Figure 2).

Figure 1

Customer credit values as displayed in transaction FD32 or FD33 status view

Figure 2

Further breakdown of credit sales value from menu option Extras > Sales value

Why Reorganize?

There is still the question of why credit data needs to be reorganized at all. For example, the running balances for general ledger accounts displayed in transactions FS10 and FS10N are always right and do not need to be reorganized regularly, so why does the credit management data need to be reorganized? 

Actually, all data in the SAP system is not always correct. The data is correct 99.99 percent of the time and needs periodic correction. In some cases, the summary balances of general ledger line items used by transactions FS10 and FS10N can be wrong and need to be corrected. For more details see "‘Update Was Terminated’— What Every FI/CO User Should Know About This Error Message." 

Risk Category Change

The most common reason for a credit reorganization is a change in the customer’s credit rating. For example, the customer is rated A in your internal rankings, but the latest data from your credit rating agency suggests the customer may have financial difficulties, so you decide to change the customer’s internal credit rating to B. In the SAP system, many configuration and master data items are copied in the SD document and not updated in the SD document even if the master data or configuration changes. To ensure that the change to risk category B is reflected in all open SD documents, you need to run reorganization report RVKRED09, which directly updates the open SD documents. This step prevents any SD documents that were created before the customer risk category change from behaving as risk category A SD documents.

When you change an existing customer’s risk category, using transaction FD32 and going to the status view, an informational message is displayed (Figure 3). Clicking the question mark icon displays further details, including the correction report you need to run (Figure 4).

Figure 3

Informational message when a customer’s risk category is changed

Figure 4

Informational message detail

Credit Update Errors 

A better reason for running a reorganization is that the credit data contains an error. Credit data containing errors may be the result of the following:

• Sales Information Table (SIS) table updates
• Transaction VA01 and VA02 user exits
• End-user customization

The key data for credit management, the open sales values displayed in transactions FD32 and FD33 are contained in the SIS, tables S066 and S067 (Table 1). The SAP system maintains a running total of customer credit exposure only, and there is no table with item-level detail of the credit exposure values. Compare this with the open AR balance where full line-item detail can be displayed using transaction FBL5 or FBL5N so that any difference between the line-item detail and the total can be easily identified. In the case of SD credit exposure, the item detail cannot be seen; therefore, the running balances could be wrong. Detecting an error would not be easy.

Table 1

SIS table usage in credit management

To make matters worse, the nature of an SIS update allows updates to be missed. When SAP updates data after a document is created or updated using transaction VA01 or VA02, multiple update functions are run. These updates are given different priorities referred to as V1 or V2 updates. V1 updates are the major updates of key SD tables (e.g., VBAK, VBAP), and if any error occurs, the whole transaction is rolled back. However, V2 updates are for secondary tables such as SIS, and if an error occurs during an update, the individual table update is skipped, but the key V1 updates remain. The result is that a new SD document could be created, but tables S066 and S067 with credit data are not updated.

Most companies with complex or high-volume order entry processes have multiple customizations to transactions VA01 and VA02 (i.e., companies customize these transactions using code changes to user exits inside SAPMV45A, the ABAP program used for transactions VA01, VA02, and VA03). These customizations often use the classic user exits implemented by SAP from the original release of SAP R/3, now SAP ECC. These user exits allow programmers full access to the SAPMV45A fields and tables, but also give them the responsibility to update them correctly. The most common issue is an update of internal tables XVBAP and YVBAP, the after and before images, respectively, of the database table VBAP. SIS looks for a specific flag, XVBAP-UPDKZ, to see if a value is a new entry or an update. Incorrect population of the field results in the SIS incorrectly updating tables S066 and S067.

In the past, companies used SIS extensively, but with the move to SAP NetWeaver BW, much of the SIS reporting has moved away. Consequently, you may find the credit tables are the only SIS tables that your company actively uses, so incorrect updates of the SIS tables can take a long time to detect. Transaction VA02 calls the SAP function module MCV_STATISTICS_ORDER to prepare the SIS data. It uses the XVBAP and YVBAP internal tables as its input.

Users may find that the standard functionality for SD credit management may not meet their requirements and proceed with custom modifications without realizing the full complexity of the SAP logic, which results in unintended consequences. The core code for SD credit management is spread out in many different function modules with tight integration to transactions VA01 and VA02 and SIS update functions. Without a complete understanding of this functionality, you could easily create custom coding that works for simple test scenarios, but that does not work for high-volume updates in a production system. Tracking down this type of problem can be very complex.

Key Reports 

Table 2 lists reports that you can use for credit data reorganization.

Table 2

Key reports for credit data reorganization

RFDKLI20

You can use the RFDKLI20 report for updating both individual SD and FI documents assigned to a credit account (customer), as shown in Figure 5. The report’s major feature is the update of credit values for individual SD documents. The effect of the report is similar to a transaction VA02 update of an SD document plus a credit base value recalculation. The report output lists all the SD documents that have been updated (Figure 6). The downside of this is that a very large number of documents are updated with a complex transaction. The report then takes a long time to run, and the credit status of individual SD documents may change. The user has to be aware that placing a sales order on credit hold even temporarily resets all scheduling data. If your global available-to-promise (global ATP) check or SAP Advanced Planning & Optimization (SAP APO) system has reserved inventory for the sales order, it will be released, and your customer delivery date may be pushed out.

Figure 5

RFDKLI20 selection screen

Figure 6

RFDKLI20 output list of the updated SD documents

You can call a report using transaction F.28. This is a long-running report. When you are running the report, the recommended option to use is Only Recreate SD Data because often the issues are with SD docs, not FI docs. Also, select Create SD Change Documents so that if you encounter issues with SD documents later, such as delivery time, it helps you analyze the root cause of the issue.

RVKRED07 

The RVKRED07 report is called by RVKRED77 and RVKRED88. It has a complex set of selection criteria that control the run (e.g., simulation versus live run), and it is not designed to be run directly (Figure 7 and Table 3). One key benefit of the report is that one of the selection criteria allows the report to be run without a lock on VBAK. Thus, the major downside of running RVKRED77 can be overcome. The risk of not having a lock on VBAK is that the resulting credit balance is not 100 percent accurate. However, when compared with the business risk of locking all SD transactions for an extended time, this is a low risk.

Figure 7

RVKRED07 selection screen

Table 3

RVKRED07 undocumented selection fields

When you are running RVKRED07 directly with the no locking option selected, do not populate any of the initial selection criteria. You also accept all the default check box selections (Orders to Assortments) and populate the fields with the technical names (KNKLI to TUNING) following the recommendations shown in Table 3.

RVKRED09

RVKRED09 is the recommended report to run when the customer credit risk category is changed in transaction FD32. Not running this report results in sales orders that were created before the risk category change behaving as if they have the old risk category. The report directly updates the new risk category in the SD documents. Figure 8 shows details of the selection screen.  

Figure 8

RVKRED09 selection screen

RVKRED77

RVKRED77 is the standard credit reorganization report. It requests a lock on all of table VBAK, which is very hard to get if there are ongoing sales transactions. It also blocks any SD transactions while the lock is in place. The selection criteria are much simpler than those for RVKRED07 (Figure 9). The report output lists all the SD documents considered when rebuilding the customer credit balance (Figure 10).

Figure 9

The RVKRED77 selection screen is much simpler than the RVKRED07 selection screen

Figure 10

RVKRED77 output listing SD documents used as the basis for customer credit value update

RVKRED88

The RVKRED88 report is the same as RVKRED77 except it is run in test mode. The selection criteria are much simpler than those for RVKRED07 (Figure 11). By default it displays the expected credit values per SD document for each credit account (Figure 12). RVKRED88 can be a useful tool when a credit analyst wants to know what makes up the SD credit balance. Allowing end users to run this report is safe because there is no update capability, but for performance reasons, run it for one credit account at a time.

Figure 11

The RVKRED88 selection screen is much simpler than the RVKRED07 selection screen

Figure 12

RVKRED88 output shows line-item detail for customer credit balances (compare the total line at the bottom of Figure 12 with the Open sales values in Figure 2)

Z_CREDIT_VALUE_COMPARE

Z_CREDIT_VALUE_COMPARE is an SAP standard report. Despite the Z name, however, the report may not be in your standard system. Implement SAP Note 666587 to get this report. The report has a simple set of selection criteria (Figure 13), runs a comparison of the customer credit balance as calculated by RVKRED07, compares it against the value displayed by transactions FD32 and FD33, and highlights any differences (Figure 14).

Figure 13

Z_CREDIT_VALUE_COMPARE selection screen

Figure 14

Z_CREDIT_VALUE_COMPARE output highlighting differences between calculated credit values and balances shown in transactions FD32 and FD33

Reorganization Options

You have two credit reorganization options: a classic or a performance-optimized approach.

Classic

The classic approach to credit reorganizations is as follows:

• RFDKLI20 — Run a full update of SD document credit values
• RVKRED77 — Rebuild customer credit balances while locking table VBAK

This approach can be very time consuming because report RFDKLI20 has a long runtime and a negative impact on sales orders.

Performance Optimized 

A more performance-optimized approach to credit balances would be as follows:

Run report RVKRED07 with no locking to update the CCA. This approach avoids the lengthy update of SD documents and, usually, the problems are not with individual SD documents. The report RVKRED07 is run for all of the CCA because running RVKRED88 or Z_CREDIT_VALUE_COMPARE to detect problem customers takes just as long, and the total runtime for RVKRED07 is not excessive. If you do run into issues related to runtime, run Z_CREDIT_VALUE_COMPARE, and then run RVKRED07 only for the problem customers.

SAP Notes

Table 4 lists some key SAP Notes on credit data reorganization.

Table 4

Notes on credit data reorganization

Rohana Gunawardena

Rohana Gunawardena heads the SAP practice division at Exium Inc. Exium is a leading business and technology consulting firm that enables companies to achieve their strategic business goals. Exium specializes in delivering superior IT solutions using ERP systems, with a special focus on SAP products. Rohana has been working with SAP since 1992. During his career he has assisted multiple clients on detailed system correction projects, such as correcting inventory balances, controlling area reorganizations, retrospectively activating group currency, and optimizing inter-company accounting transactions. He has spoken at many SAP conferences and has published more than 20 articles in Financials Expert, SCM Expert, and SAPtips on various aspects of SAP. His presentations have focused on Financials module selection, the order-to-cash process, global rollouts, business segment reporting, cross-module integration, and the financial impact of SCM transactions. Rohana is widely acknowledged as a leading SAP expert. Rohana is a Fellow of the Institute of Chartered Accountants in England & Wales. Previously Rohana has worked with the consulting practices of Accenture, Deloitte, and PwC.

Rohana will be presenting at the upcoming SAPinsider Financials 2018 conference October 16-18 in Prague. For information on the event, click here.

You may contact the author at Rohana@Exium.com .

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.