The Elsmar Cove Wiki More Free Files The Elsmar Cove Forums Discussion Thread Index Post Attachments Listing Failure Modes Services and Solutions to Problems Elsmar cove Forums Main Page Elsmar Cove Home Page
Google
  Web Elsmar.com
*Please be aware that SOME RECENT forum threads may not yet be indexed by Google.

View Full Version : Documented Receiving Procedure where there was none


Jac3LLC
24th January 2007, 04:26 PM
I am working for a client that is having problems whereby the data entry at the receiving dock, doesnt match the Purchase Order, either on quantity, part number, etc. (Basically sloppy execution).
When the invoice arrives in the Accounts Payable Dept, the A/P department kicks the discrepancy to the Purchasing Department for a resolution.
My observation is the majority of the problems are caused by the receiving personnel either not counting correctly, or incorrectly entering the data into the computer.
The Purchasing Dept has no responsiblity or authority over the Receiving Dept, but the implied responsibility lies with them according to the CFO. This resolution process is usually days or weeks after the occurrence and resolution my the Purch dept is extremely time consuming to resolve.

Its kind of like blaming your UPS driver for not getting your Fedex shipments correctly.

The entire procedure is undocumented, no standards exist, and no feedback loop exists to notify the people making the mistakes, that a mistake was event made.

My recommendation is to develop a standard procedure, in the most elementary terms, but that indicates who is accountable, and where specific responsibility lies.

Anyone have any words of wisdom for me? (anyone have a procedure I can use as a starting point)?

little__cee
24th January 2007, 04:35 PM
here is an example of what we use

Bill Ryan
24th January 2007, 06:38 PM
Jac3LLC - Welcome to the Cove :bigwave:

Let me suggest that your first step might be to flow the process as you have observed it. It sounds kind of hodge-podge and a good flow diagram of what is currently happening (with all its decision points) might help get rid of the unnecessary steps before actually documenting a procedure.

Jac3LLC
2nd February 2007, 03:27 PM
As suggested, I mapped out the what really happens against a procedure that was written in 1994.

The one thing that I found that was way out of bounds is the counting of incoming goods and informing the supplier of any variances in a timely manner.
Suppliers may be informed 2-3 weeks after receipt of goods that their payment is being withheld because the quantity counted at the receiving dock is in disagreement with their packing list and invoice.
With this much time elapsed, the supplier cant defend his position and gives up, advising to pay the invoice short, just so that he can get paid. Of course that leaves a nasty taste in his mouth the next time the customer needs a favor.

As I explained to the client, I cant go to the store, buy a case of beer on Friday and bring it back on Monday saying I just now discovered all of the bottles were empty when I got home, and expect them to replace them at no charge.

So now the client says, "develop a standard."

Any real world suggestions?

CarolX
5th February 2007, 01:26 PM
Any real world suggestions?

Our receiving procedure requires a count and condition of product as part of the process.

OOPs - added in edit - sounds like that is how the system is "suppose" to work.

Can you get all the players to sit down and come to an agreement on how to accoplish your tasks? This will help in the "buy in" of the new or updated process.