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.<\/p>\n\n\n\n
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).<\/p>\n\n\n\n
Below is an example, a simplified version of the process:<\/p>\n\n\n\n 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?<\/p>\n\n\n\n How could this happen?! The user creates an incident. You look in disbelief and\u2026 then it appears.<\/p>\n\n\n\n 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).<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019s credit group, controls the status in the sales document.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n An example of customer credit master data (FD33):<\/p>\n\n\n\n When creating an order, a message appears about exceeding the credit limit set for the customer:<\/p>\n\n\n\n The order receives the appropriate status:<\/p>\n\n\n\n The process works as it should and no major surprises should be expected. Until suddenly…<\/p>\n\n\n\n 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.<\/p>\n\n\n\n At this point, depending on the settings, the consequences may entail the malfunctioning of the established credit check.<\/p>\n\n\n\n Again, as before \u2013 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 \u2013 what’s going on here?<\/p>\n\n\n\n Then it appears, all of a sudden: RVKRED07 \/ UKM_RVKRED07<\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n An alternative is RVKRED77<\/strong>, 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.).<\/p>\n\n\n\n It is also worth mentioning the Z_CREDIT_VALUE_COMPARE<\/strong> 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<\/em>). 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!<\/p>\n\n\n\n Here are possible causes of inconsistencies in the system:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Each time you want to use them:<\/p>\n\n\n\n ***![\"Simple](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/05\/1-en.jpg\")
<\/a>And they lived happily ever after?<\/h2>\n\n\n\n
<\/a>ZZ_CORR_EKET_WEMNG_WAMNG_GLMNG<\/strong><\/h3>\n\n\n\n
Trust is good, but control is better<\/strong><\/h2>\n\n\n\n
<\/a><\/a><\/a><\/a><\/a><\/a>Where do inaccuracies in the system come from?<\/strong><\/h2>\n\n\n\n
\n
What’s next?<\/strong><\/h2>\n\n\n\n
Summary<\/strong><\/h2>\n\n\n\n
\n
Biblio<\/strong>graphy<\/h2>\n\n\n\n
\n
If you are interested in SAP, check also other articles of our experts<\/a>.<\/p>\n\n\n