Difference between revisions of "Customer Order"

From ZUGSEIL Wiki
Jump to navigation Jump to search
 
(54 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Category:Order Types and related objects]]
A customer order is a formal order from the customer in a vendors digital, which provides '''a list of ordered items.'''
[[Category:Business Object Explanations]]
 
A customer order is an object which is created on the supplier side after a procurement-contract has been created between a customer and a supplier. As a result of this a customer-order is an immutable object on which each change has to create a new contract which then results in a new customer-order.   
For each of these items, these information are provided mandatorily
* '''price information''' 
* [[Dev:Fulfillment plan|delivery plan]] - due dates, target location, risk handover agreement, ... ([[wikipedia:Incoterms|INCOTERMS]])
* '''payment plan''' - due dates for payments
 
By default a customer order is a one-sided request declaration by the customer without legal binding to the supplier. By acceptance of the supplier side, it becomes a legal document (contract) with obligations for both sides of the business. This legal document has two "perspectives" in the b-op world. On the customer side, it is a [[purchase order]], on the supplier side it is a '''customer order.''' b-op keeps them in sync through the [[Dev:B-Op e-Business collaboration model|b-op 0e-Business collaboration model]] 
 
== Process ==
[[File:Customer_Order_Lifecycle.png|1124x1124px]]
 
== Business Contexts ==
 
=== Regular purchase ===
 
=== Purchase as part of a master purchasing contract ===
Once a [[purchasing contract]] between a customer and a supplier has been signed, the customer can file one or multiple [[Purchase order|requests]] based on this contract. An isolated single request based on the contract is implemented by a [[purchase order]], which is created on the customer side. It documents to the vendor that he is ordered to deliver goods based on the contract conditions. When the customer`s digital is integrated over [https://www.b-op.com the b-op network] with the vendor`s digital, the customer`s procurement order automatically creates a ''Customer Order'' on the vendors side, bearing all the data the vendor requires. Based on this order the vendor takes all actions, like shipment, production or procurement with sub-suppliers to fulfill the customer order. 
 
Related data entities: 
 
* [[Purchasing contract|Purchasing Contracts]]
*[[Purchase order|Purchase orders]]
* [[Dev:Fulfillment Supply Chain|Fulfillment Supply Chains]]
* Production Orders 
* Bills 
 
A customer-order is an immutable object on which each change has to create a new customer-order which eventually references to the old customer order. If the order at the moment of change has been partially fulfilled or billed, all corresponding objects have to become re-associated with the new customer-order. Also, if created over [https://www.b-op.com the b-op network] the customer has to give his consent to changes in the order as the customer order is linked to the procurement order on his side.   


Customer orders can be created by manual creation in the suppliers identity or through digital interaction on the b-op network. 
== Basic flow of a Customer Order ==


== Lifecycle of a Customer Order ==
=== Order intake phase ===
The order intake phase bears all process steps until the order is fully accepted by the vendor organization and the [[fulfillment]] of the order starts.


From a suppliers perspective customer orders can be created by manual creation in the suppliers identity or through digital interaction on the b-op network. Obviously the way over the [https://www.b-op.com b-op network] reduces the work on the suppliers side dramatically as no manual work has to be invested any more. And even more the supplier benefits from having a b-op digital to place orders:


<nowiki>*</nowiki>Order creation
* as all status updates can be automatically synced to the customer, this reduces the status request phone-calls or irritations when the delivery of the ordered goods is not progressing as expected.
**Either manually (does not require acceptance)
* the supplier receives his money quicker as the bills can be sent over digitally to the customer where the bill checking process is no longer required at all.
**Or over b-op network (requires acceptance)
*Customer order acceptance process enabled (set per customer?)
**waiting for acceptance
**accepted --> Active
*Change request of <u>''already accepted''</u> customer order**Change requested accepted
**Change request rejected
**Change accepted order positions (one position 0 qtty == cancel positions, all positions 0 qtty --> entire order cancelled)
*Delivery status
**partially delivered positions
** fully delivered positions
*Billed status**partially billed position
**fully billed positions


Once the order is created the vendor has to accept it before the order is forwarded to [[fulfillment]]. For trustworthy customers (not with a track record of unpaid bills) and orders under a certain threshold, this is typically set to automatic acceptance. Still you should define per customer certain thresholds above which you will be asked.


==Changing of the customer order==
=== Order fulfillment phase ===
Changes (as possible with internal orders) are not permissible as a PO/CO-pair are a legally binding entity, and require mutual consent. So in the UI changing of orders and change requests are permissible, but in the transactional data model the offer-process has to be employed to reach a new contractual agreement.  
[[Fulfillment]] processes can range from simple [[Shipment order|shipment orders]] to very complex fulfillment collaboration scenarios using [[ZUGSEIL Lifecycle Management|product instance lifecycle tracking]]. Billing also is an important part of fulfillment, which can take place as soon as products have been shipped to the customer.  


As a result, when a change was requested and was accepted, this will happen depending on the source of the customer order:
==Related articles==
* '''steps on the b-op network case (the contract was made over the b-op network):'''
* [[Fulfillment]]
*#When the customer creates the change-request, two things happen:  - an offer is created and sent over to the supplier  - an change request is sent which refers to the offer sent
*[[Purchasing & Procurement]]
*#If the supplier accepts  - the existing customer order is cancelled  - the supplier sends the offer confirmation back  - the old supplier order on the customer side is cancelled  - a new contract is created, which creates a PO on the client side with a reference to the predecessor (cancelled) purchase order  - the PO is synced over to the supplier, which auto-accepts the customer order
* [[Purchase order]]
*#If the supplier rejects  - the offer is rejected  - everything stays as it is.


* '''manually entered customer'''
== Developer articles ==
*#The supplier changes the data in the customer order in his user interface
* [[Dev:Customer Order]] - Developer insights on a customer order
*#The old customer order is cancelled
*#A new customer order is created, with a reference to the predecessor (cancelled) purchase order


In both cases the changed customer order is cancelled and a new customer order (with a new number) is created, which has a reference to the cancelled old order.
[[Category:Order Types and related objects]]
[[Category:Glossary]]

Latest revision as of 21:11, 9 November 2024

A customer order is a formal order from the customer in a vendors digital, which provides a list of ordered items.

For each of these items, these information are provided mandatorily

  • price information
  • delivery plan - due dates, target location, risk handover agreement, ... (INCOTERMS)
  • payment plan - due dates for payments

By default a customer order is a one-sided request declaration by the customer without legal binding to the supplier. By acceptance of the supplier side, it becomes a legal document (contract) with obligations for both sides of the business. This legal document has two "perspectives" in the b-op world. On the customer side, it is a purchase order, on the supplier side it is a customer order. b-op keeps them in sync through the b-op 0e-Business collaboration model

Process

Customer Order Lifecycle.png

Business Contexts

Regular purchase

Purchase as part of a master purchasing contract

Once a purchasing contract between a customer and a supplier has been signed, the customer can file one or multiple requests based on this contract. An isolated single request based on the contract is implemented by a purchase order, which is created on the customer side. It documents to the vendor that he is ordered to deliver goods based on the contract conditions. When the customer`s digital is integrated over the b-op network with the vendor`s digital, the customer`s procurement order automatically creates a Customer Order on the vendors side, bearing all the data the vendor requires. Based on this order the vendor takes all actions, like shipment, production or procurement with sub-suppliers to fulfill the customer order.

Related data entities:

A customer-order is an immutable object on which each change has to create a new customer-order which eventually references to the old customer order. If the order at the moment of change has been partially fulfilled or billed, all corresponding objects have to become re-associated with the new customer-order. Also, if created over the b-op network the customer has to give his consent to changes in the order as the customer order is linked to the procurement order on his side.

Basic flow of a Customer Order

Order intake phase

The order intake phase bears all process steps until the order is fully accepted by the vendor organization and the fulfillment of the order starts.

From a suppliers perspective customer orders can be created by manual creation in the suppliers identity or through digital interaction on the b-op network. Obviously the way over the b-op network reduces the work on the suppliers side dramatically as no manual work has to be invested any more. And even more the supplier benefits from having a b-op digital to place orders:

  • as all status updates can be automatically synced to the customer, this reduces the status request phone-calls or irritations when the delivery of the ordered goods is not progressing as expected.
  • the supplier receives his money quicker as the bills can be sent over digitally to the customer where the bill checking process is no longer required at all.

Once the order is created the vendor has to accept it before the order is forwarded to fulfillment. For trustworthy customers (not with a track record of unpaid bills) and orders under a certain threshold, this is typically set to automatic acceptance. Still you should define per customer certain thresholds above which you will be asked.

Order fulfillment phase

Fulfillment processes can range from simple shipment orders to very complex fulfillment collaboration scenarios using product instance lifecycle tracking. Billing also is an important part of fulfillment, which can take place as soon as products have been shipped to the customer.

Related articles

Developer articles