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 |
Order Model 1 - Discrete Purchase Order, Established Customer, Established Product, Version 2.0 
Status:  Provisional Ratification by Committee April 2000. Created as part of recast of original order models, Pre-2000 Version C (Balloted and Ratified by Membership, November 1996), into Replenishment Scenarios.

Process Activities

Special Notes:                   

Few companies automate an entire business process all at once.  A Purchase Order business process is often implemented in two subcomponents:

Additionally, there is a Seller-Initiated Change subcomponent, but most standards use the PO Change Response for Seller-Initiated Change, with a code indicating that it is a seller-initiated change rather than a response to a PO or Change Order.  The buyer, in turn, uses the PO Change Request to respond to a seller-initiated change.  More information.

Although the Purchase Order process can be broken down into subcomponents for implementation - and frequently, only the PO/PO Response subcomponent is automated - it is not really a "scenario" if we think of scenarios as being ways of mixing and matching component models.  One purchase order process subcomponent cannot be mixed/matched with just any purchase order process subcomponent; the subcomponent models are just a breakdown of what is really one business process in the technology-independent view.  So, Subcomponent Model 1a can only be matched with 1b and/or 1c, but may not be matched with the subcomponents from any other Order Models.


Activity Diagram (See also Narrative):

 


Narrative (see also Graphic):

Step Description
A. At start state A, the buyer and seller have a pre-established relationship.  See Assumptions on the overview page for this model.
1. The buyer creates a discrete (standalone) purchase order.  Where the order is created depends on the implementation option being employed.   Click here for description of typical processing steps.
2. The seller processes the purchase order.  Click here for description of typical processing steps.
3. The seller creates a PO Response.  Where the response is created depends on the implementation option being employed.  For example, the response could be created in seller's back-end system, or in a buyer-managed web application.
4. The buyer processes the PO Response.  It indicates that the seller either accepts or rejects the Purchase Order, or has indicated that the decision is "pending" . 
  • Not all B2B content standards support a status of "pending" at the header level.  In the legacy EDI standards (X12 and EDIFACT), a pending or "hold" status at the order level is uncommon - either an order is accepted or rejected, but a line item schedule may have a pending status.  In RosettaNet, a "pending" status in an initial PO response is more common, due to the requirement that an order response be sent with 24 hours after the order is transmitted.

Seen Description of Typical Processing Steps.

B. At end state B, the order has been rejected or cancelled, and both buyer and seller know that this has occurred.
C. At end state C, the order acceptance or rejection is pending.  The buyer should expect a follow-on PO response within an agreed, configurable period of time indicating order acceptance or rejection.

Note that the model does not have the "pending" state trigger the subsequent follow-on PO response.  For the buyer, the sub-process is ended and the buyer waits for the follow-on acknowledgement.  If the seller has set the PO status to "pending," the seller should have logic in the back-end process that triggers them to initiate another instance of the response sub-process when the cause of the pending status is resolved and sends another PO response message with an updated status.

D. End state D is reached initially if the seller's PO Response (step 4) indicates that the order is accepted.   A legal commitment to do business now exists, and both parties are in agreement about pricing.
  • The buyer and seller may or may not be in agreement on delivery schedules at this point; agreement on delivery schedules is not a requirement for the order to be legally binding.  Agreement on product and price are required for the order to be legally binding.

If the purchase order has a very short lead time - e.g. same day or next day ship, there may be no further changes by either party prior to order fulfillment.   Otherwise, start state C may also be reached subsequently during the order lifecycle whenever the seller and buyer come to agreement via re-acknowledgments, change orders, and/or seller-initiated changes.

E. At start state E, the Change Order sub-process may be invoked as result of buyer's reevaluation or regeneration of the replenishment plan.
5. If needed, buyer may send buyer-initiated change to the order as the result of the buyer's re-evaluation of its own orders (start state E) or the buyer wishes to respond to the seller's PO Response (confirm/accept the seller's response by changing the purchase order, deny the response by leaving the purchase order as-is, counter-propose the response by offering a compromise, or request order cancellation.  Most of the time, the changes and responses concern requested and committed delivery dates.  See also Allowable Changes to Discrete Purchase Orders.
6. The seller processes the Purchase Order change.  The seller creates a PO Response (Step 3).
F. Start state F indicates that the PO Response sub-process may be invoked from time-to-time as result of seller's re-evaluation of open customer order or changes arising out of regeneration of fulfillment plan.
G. Ends state G occurs if the seller's re-evaluation indicates that there is no change  to information previously sent to buyer, so no re-acknowledgment (updated PO Response) is needed.
7. The seller may send the buyer a seller-initiated PO Change Request to the buyer.
8. The buyer processes the PO Change Request.
9. If the buyer accepts the seller's requested change or wished to send a counterproposal, the Change Order sub-process is invoked (step 5).  If the buyer does not accept the seller's requested change, a PO Change Request Denial should be sent to the seller.  It may be a simple denial (order remains open), or a cancellation of the order.
10. The seller processes the PO Change Request Denial.
H. At end state H, the buyer has denied the seller's requested changes and/or cancelled the order, and both buyer and seller know that this has occurred.

Last updated 04 January 2003