Receive Date vs PO Original Promise Date?
Receive Date vs PO Due Date?
- 4 Posts
- 135 Views
We have a little discussion going as to what is best to measure supplier performance against:
Please chime in as to what your ops do and why that avenue was chosen? (PeopleSoft Supplier Analysis is based on Receive Date vs Due Date)
Thanks for your input!
We measure by receive date vs. PO Due Date,
but it would probably be better to measure against the Original
Promise Date, so you can tell if they kick the can or not.
PeopleSoft Support/ Sr. Accounting Systems Analyst | KCP&L
| 1200 Main Street, 17th Floor| Kansas City, MO 64105
document and any attachments are intended solely for the named
addressee, are confidential and may be subject to legal or other
professional privilege. The copying or distribution of them or any
information they contain, by anyone other than the addressee, is
prohibited. If you have received this document in error, please let
us know by telephone and delete all copies from your computer
system. It is the recipient's responsibility to check this email
and any attachments for viruses. Any confidentiality or privilege
is not waived or lost because this email has been sent to you by
At a company where I used to work, we had a lot of debate about which date from which to measure. The problem with due date is that you want to keep that accurate as to when the material is actually due in order for people to have accurate expectations. But, as was previoiusly pointed out by Wendy, if the supplier changes the due date to push it out, and you measure against that, then you are essentially giving the supplier a free pass on being late. So, I believe original promise date is better.
But, even original promise date is not perfect. There can be conditions where a due date changes due to mutual agreement with the suppplier. So, if both sides agree to delay shipment, then the supplier is unfaily penalized for not making the original promise date.
Our solution was to add a small customization to the PO page to put in a Reason Code any time a due date was changed. This served a couple of purposes. One of which was to allow us to see why our due dates were changing and to see if there were patterns by any particular supplier of forcing regular due date changes upon us. But, the more important reason was for measuring on time performance. For each reason code, there was a flag that noted whether or not this change was "acceptable." So, for example, if the Buyer requested a delay and supplier agreed to push out the due date, then the date would be changed with a reason code of Buyer Requested Change and that change is Acceptable. If the supplier notified the Buyer that the shipment was getting pushed back due to production delays on their end, then a reason code of an Unacceptable type would be chosen. When measuring overall on-time, we would work backward through the PO Changes to find the latest occurrance of an "acceptable" change in the due date and that woudl be the date used for on-time measuring purposes.
It might also be worth pointing out that we built an overall supplier scorecard that included this on-time measurement, quality measurement (as determined by RTV activity), and a subjective measurement based on a survey of Buyers. This scorecard was recalculated for all key suppliers via an automated process on a quarterly basis, with each supplier being graded as Red/Yellow/Red in each area. This scorecard, along with a detailed report of all of the transactional data for the quarter, was provided to the suppliers. This did great things for us in regard to improving overall supplier performance.
Thank you Wendy & Steve, for your replies. This certainly helps in our plan discussion.
I do like the idea of the customized REASON code. We were contemplating the same issues of "Your Fault / Our Fault" scenarios.
We also have developed and deployed an overall supplier scorecard process that takes in simlar data and is also coupled with their profile question responses for an overall quarterly look under the hood.