Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
 Order Models Index | Supporting Documentation | Downloads | FAQs |
EIDX Order Models - Supporting Documentation

Frequently Asked Questions

Special Notes:           

Order Models are better understood in the context of replenishment.  The Replenishment Scenario Matrix shows how Forecast/Planning and Order models interact to form Replenishment models.


Order Models: Frequently Asked Questions

 

PO Acknowledgments

When a supplier sends an PO Response/Acknowledgment with a date change, how do I let the supplier know whether or not I accept the change?

Two hypothetical examples:

Example 1:

Example 2:

If the supplier does not receive change orders electronically, you know the answer - pick up the phone. But, if the supplier is able to receive change orders electronically, there are several options to consider:

Let's look at these in more detail.

Option 1 - Seller's acknowledged/promised delivery date not acceptable

In this option, you still want to buy the item from the supplier, but in re-evaluating requirements, he/she still wants the item on the original request date.  So, how do you tell the supplier that you don't accept their date?  Does the supplier assume that a non-response means that you accept the change or that you deny the change? Some EC standards groups believe that if you, the buyer, don't respond, this indicates acceptance of the change, and that if you deny the change, you should send a Change Order indicating a denial -- in other words, a Change Order with no change to your current requested delivery date. Problem:  Most procurement systems, legacy and current generation, can't generate such a Change Order.    If the procurement application does not detect a change to the requested delivery date, no Change Order! The supplier should assume that a non-response indicates that you don't accept the change - but, the reality is that MOST SUPPLIERS ASSUME JUST THE OPPOSITE.   What if this was a re-acknowledgement (not the initial order response) and the non-response is because you never received the re-acknowledgment? A non-response is risky -- ALWAYS RESPOND in some way. Your trusty, reliable telephone or email system will serve you well here, to let the supplier know that you received the acknowledgment, and still want the parts on your current request date.

Option 2 - Seller's acknowledged delivery date is acceptable

By acceptable, we mean here that the supplier's acknowledged delivery date is acceptable as YOUR NEW CURRENT REQUESTED delivery date. In this case, you don't need to pick up the telephone or log into the email system -- you change the REQUIRED date for the delivery schedule in your procurement system. This generates a Change Order to the supplier; it not only tells the supplier that you received their acknowledgment, but receipt of that Change Order gives the supplier PERMISSION TO CHANGE the Customer Request Date. NOTE: This will not trigger another acknowledgment from some suppliers, but most supplier' systems will probably generate another acknowledgment when they change the Customer Request Date -- most systems don't allow the suppression of this second acknowledgment -- but this should now match your REQUIRED date.

DO NOT exercise this option if the supplier's acknowledged delivery date is in time to replenish your safety stock, but MRP indicates that you really should receive the parts on your current requested delivery date.

Option 3 - The counter-proposal.

The supplier's new acknowledged delivery date may not be acceptable to you, but in reviewing the order, you decide that you don't need the parts on your current requested delivery date. In this case, once again you don't need to pick up the telephone or log into the email system -- you change the REQUIRED date in your procurement system. This generates a Change Order to the supplier. The supplier will then re-evaluate the order. If the supplier decides that they cannot change the acknowledged delivery date, they may not be able to send back a re-acknowledgment, however, most most supplier's system will probably generate another acknowledgment when they change the Customer Request Date -- EVEN THOUGH THE ACKNOWLEDGED DELIVERY DATE has not changed.

Acknowledgments, change orders and re-acknowledgments can go back and forth almost endlessly.  Most companies in our industry average three change orders per PO line item. Before placing a Change Order, be sure to evaluate the impact. Is MRP suggesting a change of one or two days? Your decision about whether to send a change may depend on whether you are in a JIT environment or not, the ABC classification of the parts, and a host of other factors.


How long should I wait for an order to be acknowledged?

In the RosettaNet standard, the PIP requires that an initial response be returned with a specified number of hours; in version 1.0 of PIP3A4, the value was 24 hour.  For other standards, the Trading Partner Agreement (TPA) may specify the expectations for acknowledgments.  When An example might be:

"If the data transmitted is a purchase order and if a purchase order acknowledgment is not returned within the time frame mutually agreed upon as specified in the Attachment, the data shall be deemed not accepted and the parties not receiving the acknowledgment will immediately inform the other party."

In general, it's the buyer's responsibility to ensure that suppliers acknowledge orders.  Although some companies are building this responsibility into eBusiness gateways, it is recommended that your RosettaNet or EDI gateway folks should not be in the business of tracking PO acknowledgments (see below).

Buyers should monitor their Unacknowledged Orders, and follow-up with the supplier.   Be sure to check the following:

The buyer should only get their eBusiness gateway staff involved if there are persistent problems with receiving acknowledgments from suppliers.


Why do we recommend that eBusiness gateway staff not track PO Acknowledgments?

The recommendation is made for several reasons:

For EDI, eBusiness gateways typically track "functional acknowledgments" (FA's), which tell them that the supplier received the EDI PO's into their EDI system.  FA's do not tell them whether the order successfully made it from the supplier's EDI system into the supplier's open order system.  When a PO acknowledgment is received, the buyer knows the order made it into the supplier's open order system.


How do we get out of this cycle of orders, acknowledgments and changes?

For some products, this is a reality we have to live with. For some, a bit of forecast smoothing and an economic order quantity calculation might help buyers to generate the right orders at the right time, and reduce the number of changes that may be needed during the life of an order. For stable, production parts, you might consider getting into a Classic Material Release, Embedded Release, or Supplier-Managed Inventory program.


Why don't many companies automate the processing of mis-matched PO Acknowledgments, and why don't we recommend use sub-item numbers in POs and Acknowledgments?

The reason few companies have automated the processing of unmatched electronic acknowledgments (whether from EDI, RosettaNet, etc..) is because it is not easy to identify what a supplier has done. There are an infinite number of ways a supplier can split or merge deliveries. If it were easy, we'd have built the logic into our systems by now.

First, let's discuss delivery schedules, without considering sub-item numbers.

Suppose you send an order for this:

Quantity Customer Request Date (CRD)
500 20010701
500 20010707
500 20010714
500 20010721

 

Example 1 - Split Deliveries

If the supplier cannot meet that exact schedule, you could get back this (just an example - the supplier in this example does not have adequate capacity to meet the early requirements, and has to play "catch up"):

Quantity Supplier Commit Date (SCD)
200 20010701
200 20010703
200 20010707
200 20010711
300 20010714
400 20010716
500 20010721

 

Example 2 - Merged Deliveries

Or you could get back this (in this example, the supplier has a minimum delivery quantity of 1000, and merges deliveries):

Quantity SCD
1000 20010701
1000 20010714

In fact, the possibilities are endless. If you just take the above examples and play around with them, you will soon see how complicated it could be to automate the processing. 

Tracking split deliveries in the buyer's system:

In the first example, if the buyer does NOT accept the supplier's commit dates, and wants to keep visibility of the original schedule, the buyer would need to end up with this in the system:

Quantity CRD SCD
200 20010701 20010701
200 20010701 20010703
100 20010701 20010707
100 20010707 20010707
200 20010707 20010711
200 20010707 20010714
100 20010714 20010714
400 20010714 20010716
500 20010721 20010721

You see that with one example, things can get quite complex.

 

Tracking merged deliveries in the buyer's system:

Buyer's usually have no choice but to accept merged deliveries, since they are usually the result of the supplier having minimum delivery quantities. The buyer needs to adjust parameters so that future orders will satisfy the supplier's requirement for minimums, pre-pack quantity (a/k/a multiplies), etc. The buyer may have to merge the deliveries to match the supplier's acknowledged schedules. If the buyer does not agree with the supplier's schedule, and wants to retain visibility of the original requested schedule, the buyer would need to end up with this in the system:

Quantity CRD SCD
500 20010701 20010701
500 20010707 20010701
500 20010714 20010714
500 20010721 20010714

 

Using Sub-item numbers:

Would adding sub-item reference while sending orders and receiving acknowledgments help in situations such as those described above?

No. For one thing, the sub-item reference DOES NOT EXIST in either the ASC (ANSI) X12 EDI standard nor the EDIFACT EDI standard. It has been voted down time after time, because many people agree that it does not help to keep trading partners' systems in synch, and in fact, would cause more problems than it would solve. Who's subitem gets used? Do trading partners have to carry both their each others' sub-item references? What if one trading partner adjusts their sub-items based on what the other trading partner has sent?

Let's go back to example 1. Let's add the sub-item number for the original order.

Buyer's Sub-item Quantity Customer Request Date
1 500 20010701
2 500 20010707
3 500 20010714
4 500 20010721

 

Now let's see the supplier's acknowledgment:

Supplier's Sub-item Quantity Acknowledged Delivery Date
1 200 20010701
2 200 20010703
3 200 20010707
4 200 20010711
5 300 20010714
6 400 20010716
7 500 20010721

Okay, so what do we do if the buyer wants to have their system reflect both the original schedule, and the supplier's acknowledged delivery schedule? What do we do with all these sub-item numbers? And by the way, what changes would we need to systems to support this - systems that consolidate schedules by date into single sub-items, or systems that automatically re-number sub-items when schedules are split, or systems that assign a new sub-item number to inserted schedules?

In this example, if the buyer's system automatically re-numbers the sub-items, the buyer's system and the supplier's system do not match on a single schedule.

Quantity CRD SCD Buyer's Original Sub-Item Buyer's Current Sub-Item Supplier's Sub-Item
200 20010701 20010701 1 1 1
200 20010701 20010703 1 2 2
100 20010701 20010707 1 3 3
100 20010707 20010707 2 4 3
200 20010707 20010711 2 5 4
200 20010707 20010714 2 6 5
100 20010714 20010714 3 7 5
400 20010714 20010716 3 8 6
500 20010721 20010721 4 9 7

 

If the buyer's system just uses new sub-item numbers for inserted schedules (the original schedule gets a "quantity change" and then schedules are inserted based on the supplier's acknowledgment).  Again, the buyer's system and the supplier's system do not match on a single schedule:

Quantity CRD SCD Buyer's Original Sub-Item Buyer's Current Sub-Item Supplier's Sub-Item
200 20010701 20010703 1 5 2
100 20010701 20010707 1 6 3
100 20010707 20010707 2 2 3
200 20010707 20010711 2 7 4
200 20010707 20010714 2 8 5
100 20010714 20010714 3 3 5
400 20010714 20010716 3 9 6
500 20010721 20010721 4 4 7

 

And then, what if the buyer's system renumbers and supplier's doesn't, or buyer's system doesn't but supplier's does?

So, now you know why we still use human beings in the procurement process, and why it is not always easy to automate exceptions. It is very costly to code programs to automate exceptions. It is more effective to spend those resources on automating the 80% of cases that are not exceptions, and use human resources to handle the 20% of cases that are exceptional.