CompTIA EIDX - Order Model I

sitemap

EIDX Home

About EIDX

Benefits of Membership

Business Process

	Current Projects
	Clickable Business Models
	Business Model Navigational Help
	Business Model Development Methodology
	Business Model Legends

Education

Guidelines & Standards

LOGIN

PASSWORD

remember my login

forgot my password

Order Model I
Discrete purchase order, Established Customer,
Established Product, Version 2.0
Buyer calculates requirements and places purchase orders, based upon agreed standard product and pricing information from price/sales catalog or upon quote request / responses. 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 Model I Overview (Use Case) Diagram

Click here to view a larger image.

Order Model I Overview (Use Case) Narration

Step	Description
1.	Buyer may precede order with quoting or contracting cycle.
2.	Buyer may send planning forecast to seller. (Optional - depends on which replenishment scenario is being used).
3.	Buyer generates discrete, standalone purchase order.
4.	Seller responses with purchase order Response/Acknowledgment.
5.	If needed, PO Change Requests (seller-initiated changes) may be sent to the buyer.
6.	If necessary, buyer may send a PO Change Request Denial to the seller. Alternatively, buyer may accept the requested changes or make counterproposal (Step 7)
7.	If needed, buyer may send buyer-initiated change to the order or response to seller-initiated change that either accepts seller's proposed changes or makes counterproposal. Alternatively, the buyer may deny the seller's requested changes (Step 6) Note: If buyer send neither a PO Change Request Denial nor a response to seller-initiated change, the trading partner agreement should indicate how this should be interpreted, otherwise EIDX recommends that the seller should assume that the requested changes have been denied.
8.	If buyer-initiated change order is sent, seller acknowledges change orders.
9.	Seller ships goods to specified ship-to location per appropriate logistics scenario.
10.	Billing and Payment cycle initiated per appropriate financial scenario.

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

PO and PO Response
Change Order and CO Response

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.

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.

Order Model I Overview Activity Diagram

Click here to view a larger image.

Order Model I Overview Activity Narration

Step	Description
A.	At start state A, the buyer and seller have a pre-established relationship.
1.	The buyer creates a discrete (standalone) purchase order. Where the order is created depends on the implementation option being employed.
2.	The seller processes the purchase order.
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.
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.
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 form 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.

Additional Information