Unusual SAP Table Maintenance via Tcode SE16N (and not in SM30)
Unusual SAP Table Maintenance via Tcode SE16N (and not in SM30)
Today, I want to take a deep dive into the bowels of SAP in terms of OTC maintenance. This is an excellent example as to how unexpected things can become in SAP.
Typically, when you think of table maintenance, transaction code SM30 comes to mind, right? Here’s an example where that doesn’t work.
In this case, I will discuss the Proof of Delivery scenario in OTC. This is where the customer gets to separately confirm your Post Goods Issue quantity and then pay you based on their measurement, not yours. In some businesses, you will want to grant your customer this capability.
It’s a separate tcode – VLPODQ. In order to use this process, you will need to set up a Sales Document type to accommodate the POD process as well as check the “POD-Relevant” box in the Shipping tab of the relevant customer master record.
Once the config and setup are complete, then you should be able to process the following scenarios after you write a Sales Order and Delivery documents in the standard way:
1) Customer agrees that your PGI quantity received is the same as in your outbound delivery. Example: You PGI a quantity of 35,000 KG and the customer weighs the product as 35,000 KG. In other words, no change. The invoice to the customer will be for 35,000 KG of product.
2) Customer receives less than your PGI quantity. This will be a common scenario due to evaporation or spillage of liquid product. Example: You PGI a quantity of 35,000 KG and the customer weighs the product as 34,800 KG. In other words, the delivery was short by 200 KG. The invoice to the customer will be for 34,800 KG of product.
3) Customer receives more than your PGI quantity. This will be more of an outlier but could happen due to imprecise measurement at your Shipping Point. In any event, it’s good business to increase your billable amount where warranted. Example: You PGI a quantity of 35,000 KG and the customer weighs the product as 35,200 KG. In other words, the delivery was exceeded by 200 KG. The invoice to the customer will be for 35,200 KG of product.
Testing this was very straight forward.
First, I executed VLPODQ in the QA environment as no change to the original PGI quantity. No problem, the system confirmed and invoiced 35,000 KG and all was well.
Make sure you choose the correct reason for under and over deliveries.
Then, as noted above, I tested what I figured to be the most common scenario where the quantity was a little short. Customer confirmed only 34,800 KG and tcode VLPODQ accepted this shortfall with no issues. The billing document issued correctly for the modified 34,800 KG quantity.
However, when I tested the last logical piece, where for example, the customer received more than the original PGI, this is the error received when attempting to process the customer verified quantity of 35,200 KG in VLPOD:
OK, so SAP is giving feedback that you are attempting to PGI an excess amount which ostensibly creates a stock deficit. Jeder Erstsemester wird Ihnen sagen, dass es nicht erlaubt ist, mehr zu liefern, als man hat. As any fresher will tell you, it is not permitted to deliver more than what you have.
However, within tcode VLPODQ, SAP provides options for all three scenarios: no change, deficit, and excess. What SAP permits with one hand, it takes away with the other.
What gives?
The solution turns to be that some default entries in standard data tables need to be removed.
Specifically, these are tables MSKA Sales Order Stock and MSSA Total Customer Orders on Hand. By default, fields MSKA-KASPE Blocked Stock and MSSA-SASPE Blocked Stock are checked with an X to prevent situations where apparently simple maths calculates a negative stock situation between the two PGI transactions. By removing these Xs, the blocks are removed, and the excess scenario can be processed through Billing with the above error removed.
However, as you might expect, such table maintenance – in this case – is not permitted in SM30. The second part of the solution is to make this change, surprisingly in my view, via tcode SE16N.
In this case study, we have seen a solution where some data maintenance in standard SAP tables is required. In this example, SM30 was not permitted for the maintenance, but SE16N was.
Please add this to your repertoire and tool kits! Happy consulting!
Author: James Olcott