|Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search|
|Order Models Index | Supporting Documentation | Downloads | FAQs ||
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):
|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.|
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
|B.||At end state B, the order has been rejected or cancelled, and both buyer and seller know that this has occurred.|
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.
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.
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