In order to purchase new assets, a purchase order is created and submitted to a vendor. As the vendor delivers against the purchase order, packing lists and invoices are generated and remitted to the company making the purchase.
The packing list is usually affixed to the packaging and shipped with the order. Invoices are normally mailed in a separate step to accounts payable, representing a bill for the order.
Consider now that we have 3 points of information flow at this stage;
- The Order
- The Packing List
- The Invoice
Each is compiled by different parties and for different reasons, yet they reflect one set of assets related to a specific order. Attempts to compare (reconcile) these documents is at best difficult and worse, may fail.
Here we will explore why this is so.
The first factor lies in the number of touch points whereby problems can be introduced.
Buyers in the purchasing department create purchase orders. Because there are usually multiple buyers, it is not uncommon to find that they apply varying protocols when constructing an order.
Next, in order to save time, line items of a similar model are usually bundled into a single line. This creates some havoc as a line must then be reconciled to multiple items, associated packing lists and invoices.
Further complicating this is the fact that it is not uncommon to find that model designations used on an order is different than those represented on a packing list or invoice, as that physically depicted on the asset.
As the shipping department receives an order, acceptance is made without opening the shipping boxes. The norm is to compare the order on a line item by line item basis to the number of boxes and the external labeling, without inspection of the actual contents within.
Thus, we have now added an additional touch point, the labeling on a box. As shipping receives an order, one of two typical scenarios occurs:
- Shipping notifies the intended recipient of the arrival (and delivers it) as well as informing the finance department, usually accounts payable.
- The second scenario entails shipping actually making entries into an enterprise system, such as Oracle, informing the system that an order has arrived.
Not only have we just introduced yet another touch point, we have also introduced another opportunity to introduce a new problem, namely Timing.
Check back as we discuss issues related to Timing…