In my previous article, “Guard Against Nonpayments with Credit Data Reorganization,” I addressed the issue of credit data reorganization and mentioned that before any reorganization the root cause of the error needs to be resolved. I hinted at what some of the root causes may be. In this article I explain what you need to do with regard to them. If you do not resolve the root cause of the credit data error, you face the challenge of running the credit data reorganization reports regularly knowing that the credit data used for order approval is inaccurate. This practice creates a burden on system performance.

Note that there are four major classes of processing errors within sales and distribution (SD) credit management:

1. Credit checks
2. Update of the open credit values
3. Credit release, lists, and reports for new checks
4. Credit master data and reports for the reorganization of credit data

The detection process shown in this article directly relates to items 2 and 4 in the preceding list and assists in resolving issues for items 1 and 3.

Credit Values

You can view the key credit values being discussed using transactions FD32 or FD33. From the initial screen select the status view checkbox, and the balances are shown (Figure 1). In the case of the sales value a breakdown by orders, deliveries, and billing documents is possible using menu option Extras  > Sales value (Figure 2).

Figure 1

Customer credit values as displayed in FD32/33 status view

Figure 2

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

Recreating the Error

Recreating the error can be the most difficult part of the root cause analysis process. Once you can replicate the error scenario, getting to the root cause is much easier. Consider the scenario in which you run the credit correction program, and a week later, you notice that there are errors in the credit data, but you can’t place your finger on the exact cause of the error. Finding a specific example of an update that causes the error is important. Without being able to replicate the error, you cannot move forward effectively with the root cause analysis. (For advice on finding these errors, see the sidebar titled “Tips to Determine Errors in SAP Credit Updates.”)

Reports

The reports shown in Table 1 can assist with detecting an SD document that triggers the credit update error and allows you to replicate the error.

Table 1

Reports for detecting an SD document to trigger the credit update error

RVKREDH1 Documents Changed or Created in the Specified Period

You can use an RVKREDH1 report to identify SD documents updated for credit purposes between two dates to help track the transactions causing errors in credit balances. Figure 3 shows the reports selection screen, and Figure 4 shows the reports output that is broken into sections by type of SD document.

Figure 4

RVKREDH1 list of changed or created documents for selected period

Z_CREDIT_VALUE_COMPARE Credit Management: Incorrect Open Credit Values

Z_CREDIT_VALUE_COMPARE is an SAP standard report, despite the Z name. However, the report may not be in your standard system, so use SAP Note 666587 to install the report. The report simulates a reorganization of credit data, similar to RVKRED88, and then compares the results against the values seen in transactions FD32 or FD33 (SIS tables S066 and S067). The report is very useful in identfying customers with incorrect credit values. Figure 5 shows the selection screen for the report, and Figure 6 shows the report output highlighting errors in red.

If you use the central consistency monitoring of the SAP Solution Manager, Data Consistency Cockpit, the report output can be linked. For more details see SAP Note 1040893.

Figure 5

Z_CREDIT_VALUE_COMPARE selection screen

Figure 6

Z_CREDIT_VALUE_COMPARE output

SIS Update

The key data for credit management, the open sales values displayed in transactions FD32 or FD33, is contained in Sales Information System (SIS) tables S066 and S067. For usage details see Table 2. For SE16 table content examples see Figures 9 and 10. SAP maintains a running total of the customer credit exposure only; there is no table with item level detail of the credit exposure values.

Activating the SIS Update Log

Once you have been able to reproduce the error, focus on the SIS update logic. Use transaction SU3 to set parameter ID (PID) MCL = X in your user profile (Figure 7). This step activates SIS data logging for display with transaction MC30. For more information on parameter IDs see the article “Discover Hidden Parameter IDs to Simplify Your FI Settings.” After you have processed an SD document, any SIS updates that occur are recorded in the log and can be displayed. Note that only the last update is recorded, however, so run transaction MC30 after each SD transaction you process.

Figure 7

Update user parameters with entry MCL

After you set the MCL PID, the MC30 log data is visible (see the next section titled “SIS Update Log Data” for log output at different stages of sales order [SO] processing). The MC30 initial screen is shown in Figure 8. Because the user ID can be changed, you can view an update made by another user as long as that user has the PID MCL set. This feature may be useful if you do not have security for the specific SD transaction.

Figure 8

Transaction MC30 initial screen

SIS Update Log Data

In the following sections I show you the detailed views of the SIS update log for each process step of the SO’s process life so that you can clearly see how the credit data is updated. Seeing the updates at each stage can help you identify incorrect update data when you look at the logs.

SIS Initial Values

Figures 9 to 11 show the key SIS tables S066 and S067 values before the SO processing starts. In Figure 9, the values are stored by calendar month, and the total is USD 61,687.29. For the table S066 and S067 details (Figures 9 and 10), use transaction SE16 (or if you prefer SE16N or SE17) to display the table data. To view the same values in the customer credit master use transaction FD32 or FD33, Status view > Extras  > Sales value (Figure 11).

Figure 9

display

Figure 10

SE16 display of table S067 initial values

Figure 11

FD32 or FD33 display of the same values using Extras > Sales value (values match to the SIS tables S066 and S067)

Create Sales Order with Credit Block

You use transaction VA01 to create a sales order in which the customers have exceeded their credit limits, and the SO is placed on credit block. The initial MC30 screen lists all of the SIS tables (S008, S009, etc.) that were selected for an update (Figure 12). In Figure 12, the X in the update column (U) indicates that an actual update occurred. All other SIS tables were selected for an update, but no actual update occurred. Because there is a billing block, no update of credit values occurs (Figures 13 and 14).

Figure 12

MC30 overview of SIS tables selected for update

Figure 13

MC30 detail of S066 update — SO created with credit block

Figure 14

MC30 detail of S067 update — SO created with credit block

Release Credit Block

You can release a credit block using transaction code VKM3. Credit values are updated automatically once the credit block is released. Note that the S066 update is performed by schedule lines of the SO line item (Figure 15). Only schedule lines with a confirmed quantity (VBEP-BMENG) result in an update. The value is calculated based on the item credit price (VBAP-CMPRE). As seen in the SE16 view of S066 (Figure 9), the update is calculated by calendar month using the material availability date of the schedule line (VBEP-MBDAT).

Figure 15

MC30 detail of S066 update – SO credit block released

For this SO schedule, line 1 was initially created when the order was on credit block with no confirmed quantity. After the release of the credit block, Available to Promise (ATP) functionality is rerun for the SO, creating a second schedule line with a confirmed quantity (Figure 16). This is the reason why there are two New and only one Old schedule lines in the S066 update (Figure 15). At this stage there is no delivery, so there is no S067 update (Figure 17).

Figure 16

Schedule line detail for SO item 10 (Schedule line 2 with confirmed quantity is created by ATP after the credit block is released.)

Figure 17

MC30 detail of S067 update — SO credit block released

 

Figure 18

MC30 detail of S066 update — Delivery created

Create Delivery

Create a delivery using transaction code VL01N. Credit values are removed from open orders and moved to open deliveries. Note that if you have credit blocks enabled for deliveries, a delivery credit block does update the SIS values, unlike an SO on credit block. The update moves the credit value from S066, open orders (Figure 18), to S067, open deliveries (Figure 19).

Figure 19

MC30 detail of S067 update — Delivery created

Post Goods Issue (PGI) Delivery

Perform PGI delivery using transaction code VL02N. There is no change in credit values because no new document relevant for credit is created. Note the nature of the S067 update with both a negative and positive value (Figure 20), which results in a net 0 update. The SIS update appears this way for any change with no credit impact (e.g., subsequent change to the SO with no credit impact). There is no S066 open order update (Figure 21).

Figure 20

MC30 detail of S067 update — PGI Delivery

Figure 21

MC30 detail of S066 update — PGI Delivery

Billing

Create a billing document using transaction code VF01. There is no S066 update record in this case, only S067 (Figure 22), removing the open delivery credit value. There is no open billing value update because the FI invoice is created at the same time as the SD invoice, so the credit value moves immediately to open AR.

Figure 22

MC30 detail of S067 update — Billing

Table Values

Table 3 shows how the credit data table’s values are updated at each process step of the SO’s life. Note that the S067 open billing value is only maintained for SD invoices not transferred to FI. In normal processing, the SD invoice should transfer to FI immediately, so this field should be 0 (see the S067 update in Figure 22. If you have values in the open billing field, check for errors in the SD/FI invoice transfer process. For more details see the article “Secure Your Revenue Stream: Ensure That SD Billing Document Invoices Are Posted in FI.”

Table 3

Credit data table updates by SO process step (all values are in USD)

Sources of Credit Update Errors

At the start of this article I stated that I do not discuss the detailed step-by-step configuration for credit management. If you are using standard functionality, have configured it correctly, and have limited custom SD user exits, there are very few problems with credit management. Now I discuss the two major causes of “unexpected” credit management update errors: VA01 or VA02 user exits and credit process customization.

VA01 or VA02 User Exits

Most companies with extensive use of SD have multiple customizations to the VA01 or VA02 transactions (report SAPMV45A). These customizations often use the classic user exits implemented by SAP from the original release of SAP R/3, now SAP ERP Central Component (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 updating internal tables XVBAP (after) and YVBAP (before) images of the VBAP tables. There is a specific flag, XVBAP-UPDKZ, which SIS looks for to see if a value is a new entry or an update. Incorrect population of the field results in an incorrect update of tables S066 and S067 by SIS.

In the past, companies used SIS frequently, but with the move to SAP NetWeaver Business Warehouse and SAP BusinessObjects Business Intelligence, companies have moved away from SIS reporting. You may discover that the only SIS tables that your company uses are the credit tables. Consequently, incorrect updates of the SIS tables can take a long time to detect because the SD team is not monitoring SIS.

When a user updates an SO using transaction VA02, the system calls function module MCV_STATISTICS_ORDER to prepare the SIS data, which needs to be updated. SAP function module MCV_STATISTICS_ORDER is supplied with two sets of VBAP data, XVBAP and YVBAP, from the VA02 transaction. It uses this information to determine the old and new values, such as prices or credit values to update SIS. To do this, the function module looks for certain flags (e.g., XVBAP-UPDKZ) to see if a line is old, new, updated, or deleted. For example, XVBAP-UPDKZ = space indicates there is no change. See Table 4 for a list of update codes. If the flag is incorrectly updated in a custom user exit (e.g., XVBAP-UPDKZ = ‘I’) when it should stay as a space for no change, function MCV_STATISTICS_ORDER treats the line item as a new line item, not an existing line item with an update (Figure 23). The correct update should result in a net 0 update (Figure 24).

Table 4

Field XVBAP-UPDKZ values

Figure 23

Incorrect update of S067 for an SO item when updated using VA02 and no credit value change occurs

In Figure 23 you see the result of field XVBAP-UPDKZ being incorrectly set to value I, where line item 10 has a new value of 353,640.47. You would expect an old value of 353,640.47  and a new value of 353,640.47 for a net 0.00 impact. In this update credit exposure is overstated by 353,640.47. Compare this update with the update in Figure 24.

Figure 24

Correct update of S067 for an SO item when updated using VA02 and no credit value change occurs

In Figure 24 you see the result of an update when field XVBAP-UPDKZ is correctly set to value <space>. The positive (New) and negative (Old) values result in a net 0 update.  

Credit Process Customization

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. The core code for SD credit management is spread out in many different function modules with tight integration to VA01 or VA02 and SIS update functions. Without a full understanding of this functionality, you can 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.

Root Cause Analysis

Once you have identified the specific transaction steps that recreate the credit error consistently, what should your next step be?

1. Submit an SAPNet message to have SAP Support analyze the issue as discussed in SAP Note 396338 (Problems in credit management — analysis help). This step is the easiest and simplest option, but it may take time and could be handed back to you if it is caused by your own modifications.
2. Debug code with a programmer to see where the error is occurring. This option is a good choice if you have skilled programmers or a large amount of custom SD user exit coding.

Debugging

If you choose the debugging route, the first place I would set a break point is function MCV_STATISTICS_ORDER to determine what date is being sent to the function and the status of the XVBAP-UPDKZ flag (Figure 25). Once this can be determined you can trace backward to see where this flag is being set incorrectly.

If the date being sent to function MCV_STATISTICS_ORDER is correct, then look at the actual update points for tables S066 and S067, which occur in programs RMCSS066 and RMCSS067, respectively.

If you don’t determine the root cause of the credit update error, any repeated reorganizations of credit data is futile. You need to get to the root cause of the error. The SAP Notes in Table 5 can help you determine the source of a credit data error.

Table 5

SAP Notes for credit data reorganization

Finding a specific SO or SD transaction that causes the SD credit data update error is the most complex part. Use daily monitoring of the SD credit error reports to track down to individual SD documents and transactions that cause the error. The key objective is to be able to replicate the error in a consistent manner so that the detailed troubleshooting can be handed over to SAP Support or for you to address yourself. First make sure your basic SD Credit Management configuration has been fully reviewed and validated prior to going into this more detailed troubleshooting process.

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.