-
Type:
Story
-
Status: Implemented (View Workflow)
-
Priority:
Normal
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2.0-IP-3
-
Component/s: Business Objects
-
Labels:
the idea of sending a new rfq, while the old one is still pending (and quote, and...) may be realistic in manual phone transactions.
In order to simplify the automated transactions it may make sense to reduce the varitions by only allowing change orders for PurchaseOrders. every thing else should be handled by the standard rufusal/confirmation/cabcellation process.
Should printers even be allowed to make late stage change orders of confirmed jobs?
Decision: Yes
Should we require cancellations prior to superseding?
Glossary
<search and replace font of all removed glossary items - e.g. invalid>
| Confirmed JobBusinessObject | A Business Object that the other party has accepted by sending an appropriate Business Object as a response, e.g. a PurchaseOrder that references a Quotation. A Confirmed Business Object is no longer a Pending Business Object.A job (producing a Print Product) that a Print Buyer and Print Provider have agreed to after negotiating a contract for it. The Print Provider consummates the agreement by confirming the Print Buyer’s purchase order. |
| Invalid | ... |
| Pending | ... |
| Pending Business Object | A Business Object that other Business Objects can reference via @BusinessRefID and @ReplaceID. A Business Object X is pending from the time a Print Buyer or Print Provider creates it until: • It is confirmed by a Confirmation or other appropriate Business Object (See Confirmed Business Object). • It is refused by an explicit Refusal. • It expires. • Its creator sends a Cancellation whose @BusinessRefID references X.it • Its creator sends a Business Object whose @ReplaceID references X. |
| Supersede | ... |
| Superseded Business Object | ... |
| Superseding Business Object | ... |
Table 2.6: Request Element
| BusinessRefID ? | ... | The value of @BusinessRefID SHALL be the same as the @BusinessID of some other pending Business Object which acts as the primary parameter to the Business Transaction that this PrintTalk document represents. Prior to a PurchaseOrder, a @BusinessRefID SHALL refer to a Business Object that was received from the other party. Once a PurchaseOrder has been placed Request/@BusinessID of the PurchaseOrder SHALL be used as the @BusinessRefID of all following Business ObjectsSee table ##ref For example, a Request/@BusinessID references an RFQ if it provides a quote for the RFQ, or it references a PurchaseOrder if it specifies a Change Order. |
3.10 PurchaseOrder
The Print Buyer SHALL accepts a Quote of the Quotation for purchase of a Print Product by creating and sending a PurchaseOrder
that references the Quote. A Print Buyer MAY initiate a <glossary>Change Order<glossary> by sending a PurchaseOrder that references an existing, Confirmed PurchaseOrder.However, a PurchaseOrder can MAY also be the first Business Object in a Negotiation Phase, especially for a reorder of a previously produced Print Product.
If a Print Provider accepts a PurchaseOrder, it SHOULD send a Confirmation that references the PurchaseOrder. If a Print
Provider does not accept a PurchaseOrder, it SHALL send a Refusal that references the PurchaseOrder.
References: N/A (PurchaseOrder can be the initiating transaction), Quotation, PurchaseOrder
Flow: Print Buyer to Print Provider
Table 3.10: PurchaseOrder Element
| ReplaceID ? | ... |
3.11 Quotation
...
References: Confirmation, PurchaseOrder, RFQ
Table 3.11: Quotation Element
| ReplaceID ? | ... |
Table 3.12: Quote Element
| ReplaceID ? | ... |
Table 3.15: RFQ Element
| ReplaceID ? | ... |
Appendix B.2 ReplaceID <delete section>