Logistical Nightmare POD Proof of Delivery Part 2- What s the difference

Logistical Nightmare. A discussion about Supply Chain issues especially with in SAP projects. Mostly in the FMCG sector. Monday, 31 August 2009. POD Proof of Delivery Part 2- What's the difference. SAP provides for two difference postings out of the box. A positive difference when more goods are received than you thought you had shipped and a negative for stuff lost or damaged along the way. For reporting purposes you are going to need to expand on this list. The reason codes will probably also drive the correction process. That is the steps that you will need to go through to correct the inventory and accounting in your system. The reason code together with the difference quantity is going to be used to update your already PGIed (post good issued) delivery, so that the billing quantity matches the received quantity and therefore hopefully there will be no dispute when it comes to payment, less administration of credit notes and happier customers. There are a couple of issues to consider here, firstly where do you get your POD data from? If it comes from the customer, then you can be reasonably sure it is accurate and relates to deliveries that have been checked. Some of the big retailers do have the capability to send EDI POD receipts, but a lot of customers will not be able to manage this. In this case your POD data, if you get it all, is going to come from your carrier. That means that it probably only refers to deliveries that have been received and not checked, so there is still room for a difference. Secondly, billing cannot happen until the POD has been confirmed. This means that you are putting extra time into your cash flow, and if you do not receive a POD confirmation within a certain period you probably will want to automatically confirm the delivery so the invoice can be raised. Of course if the carrier provides your POD data you will want to chase them to find out what happened to the missing POD receipts. With some of the standard SAP reporting (VLPODL) you can monitor deliveries and their POD statuses, chase missing items and correct any errors. If you have got as far as receiving POD differences you will need to make the corrections to your inventory and accounting. Suppose you get a negative POD difference, this could be because good were lost or damaged in transit, or because of an error in picking the wrong quantity could have been issued in the first place. Those two SAP reason codes soon seem to be inadequate. If the wrong quantity was issued, then will want to reverse the goods issue for the incorrect item to correct your COGS (cost of goods sold) and your inventory levels. For those items lost in transit, you may want to return the goods and write off the damaged stock. Depending on how you handle your accounting, perhaps you are posting to CO-PA for customer and product profitability you will need to ensure that the sums add up and you don't overstate your sales. There are many variations and this is probably why SAP has not attempted to provide you with the tools to correct your differences. They have however provided you with a couple of statuses on VLPOD to flag if you have completed the inventory and financial adjustments, which you may decide to handle manually or automatically depending on the number of POD corrections you have to do. In either case the key here to me is to ensure that you don't lose your document flow. Your corrections documents should be visible and traceable so that you know that the correction has been done. This is a little bit tricky, but not impossible the key here is use the reason codes to determine the kind of correction to be done. I haven't really mentioned the POD interface, largely because it is quite simple. An inbound STPPOD idoc identifies the delivery to be corrected. If there is a difference to be accounted for then a segment for the item with the difference is needed quoting the quantity and the reason code. Hopefully you should not need to modify this interface at all. You may need to consider what you do if you get messages both from customers and the carrier. You could accept both, but only confirm if the message comes from the customer. Not much here: make sure your delivery items are POD relevant, and set up your new reason codes. You're probably going to end up with a bunch of new document types for the corrections, but that should be relatively straight forward. The devil is not going to be in the system detail it will be getting the right data from the carrier and figuring out all the combinations of corrections. I don't think this is the final word on POD by a long shot, so I would be interested in any comments. New challenges or different approaches..