Inconsistencies in SAP – some examples of correction reports

Sii
BlogerSii
Inconsistencies in SAP – some examples of correction reports

From this article you will learn how you can deal with some inconsistencies in SAP system. I will provide examples of situations and reports that may be helpful.

The first of the described cases concerns purchase orders in which the data in the schedule line tables (EKET, EKES or EKBE table) have been incorrectly updated. A consultant working with the MM, SD module may encounter such inaccuracies.

The second case relates to the incorrect updating of the value of the customer’s open credit (information structures S066 and S067), which causes the malfunction of the credit control based on this indicator. Therefore, this problem affects the customer’s credit control, i.e. the SD and FI area.

Long time ago…

Imagine a process where plant 1000 (Lublin) orders 10 pieces of material A from plant 2000 (Wroclaw). Let’s assume that the shipping and delivery process is carried out using an STO (Stock Transport Order), i.e. a warehouse transfer order. The target order quantity is 10 pieces and, in this process, the quantities ordered and delivered should match each party.

So, if plant 2000 ships 4 pieces and plant 1000 has also confirmed the physical receipt of 4 pieces, then the order (STO) in SAP should also include the delivered quantity of 4 pieces. The open quantity should be 6 pieces and be available for the next delivery in transaction VL10D (VL10B).

Below is an example, a simplified version of the process:

And they lived happily ever after?

What if in the order in the SAP system, in the schedule lines tab, the quantity of delivered goods is 10 pieces, although in fact the customer received 4 pieces?

How could this happen?! The user creates an incident. You look in disbelief and… then it appears.

ZZ_CORR_EKET_WEMNG_WAMNG_GLMNG

A report that allows you to correct the quantity of material received (EKET-WEMNG), the quantity of material issued (EKET-WAMNG) and the quantity delivered (EKET-GLMNG).

Dear consultant, you solve the problem relatively quickly, the customer is satisfied, you deserve a pat on the back and you get time to replicate and analyze the cause of the problem.

Trust is good, but control is better

We go to another world. Boring, predictable one in which you look in vain for adventures and challenges. One of the areas under your care is credit control settings. Customers are assigned a risk class. The risk class, combined with the document’s credit group, controls the status in the sales document.

Each time a new order is issued, the customer’s used and granted credit limit is checked. For high-risk customers, the expected reaction of the system is to grant the “Acceptable” status when a new order exceeds the agreed credit amount.

An example of customer credit master data (FD33):

Fig. 4 Correct customer credit master data

When creating an order, a message appears about exceeding the credit limit set for the customer:

The order receives the appropriate status:

The process works as it should and no major surprises should be expected. Until suddenly…

The customer has issued a monthly collective invoice for service and maintenance orders performed. However, the total value of the open credit, instead of being reduced by the amount of the invoice, was reduced by an astronomical amount, and the new value of the open credit is: -500.999.600,00 PLN.

Fig. 7 Incorrect open customer credit value

At this point, depending on the settings, the consequences may entail the malfunctioning of the established credit check.

Again, as before – the customer reports an incident. For example: orders/deliveries are not blocked for a customer with high credit risk. Open credit values are incorrect. Out of nowhere, you have identified incorrect open negative credit values for this customer. You look on in disbelief – what’s going on here?

Then it appears, all of a sudden: RVKRED07 / UKM_RVKRED07

A report that, taking into account the customer’s credit account (KNKK-KNKLI), and credit control area (KNKK-KKBER), allows you to correct incorrect open credit values. Using the report requires caution, as it works by deleting all open credit values from the beginning for a given customer, and then re-establishing them based on open sales documents.

An alternative is RVKRED77, which we are often unable to run due to the criteria: the system should not update any of the related tables during this time, which is extremely rare in practice (this requires stopping the tasks that create or update orders, deliveries, invoices, etc.).

It is also worth mentioning the Z_CREDIT_VALUE_COMPARE report (the report should be uploaded with the help of an ABAP consultant, as it is not available as standard. Details are described in note 666587 Check for incorrect open credit values). This is an additional report that will help you identify abnormalities in the calculation of open loan amounts. Then, you are able to correct them here and now with RVKRED07. Well done!

Where do inaccuracies in the system come from?

Here are possible causes of inconsistencies in the system:

an error in the configuration of processes that deviate the SAP software vendor’s model recommendations. Unfortunately, in quite complex systems, with multiple interfaces and constantly running background tasks, sometimes completely unexpected results can occur;
user errors in one of the connected systems (e.g. eWM, APO, MES);
modification made manually by the user at any stage where the process should be fully automated;
an attempt to correct one of the process steps without taking into account interdependencies and background tasks (e.g., substitution of a batch or quantity in a delivery when the process runs automatically and periodically, or when availability check is performed and open items in documents are updated at the same time);
simultaneous processing of the same process/document by the user and the technical user that is used to perform background tasks;
and many others.

What’s next?

Most corrective reports can be scheduled as a background task that runs periodically. In this way, it is possible to monitor “strange” events, helping to obtain examples that cannot be replicated in the test system. A report in the form of a background task can also be a temporary and preventive solution allowing detection of events before the customer reports them.

Of course, I recommend identifying the root cause and a comprehensive solution to the problem, but due to the lack of time and a lot of interdependencies, it may not be possible to correct the current system settings and coming up with a new solution will take a lot of time and energy.

Summary

In the situations described above, it is sometimes really difficult to find the root cause in a short time and solve the problem by removing this cause. This may involve a significant rebuild of the system settings, which, due to the continuous development of the application and connected interfaces, must be postponed. A number of reports are at the consultant’s disposal to help quickly deal with user problems.

Each time you want to use them:

Make sure that you are dealing with inconsistencies in the system and in the tables, perform basic analysis for this purpose.
Find a report that allows you to correct inaccuracies. Reports are usually described in SAP notes and contain information to which system version they can be applied.
Make sure this report is on your system. Some reports are standard or delivered in updates, some require manual upload by an ABAP consultant.
Make sure you know how to run the report without causing side effects (e.g., what constraints to use to narrow down the area of use, be it a single document, customer, or organization area). It is recommended to first run the report in a test mode or on a small portion of data, and then in the mode that will make adjustments.