Simple Order Process
Description of the four primary messages need to fulfill a simple order process.
Last updated
Description of the four primary messages need to fulfill a simple order process.
Last updated
This page explains how to use the SCSN messages as defined in the Semantic Treehouse environment (smartconnected.semantic-treehouse.nl). This chapter starts with a simple order process between two organizations, which is the fundamental building block of SCSN. The next pages explain extensions and more advanced processes.
The most fundamental messages of SCSN are the Order and Invoice messages. The Order message is often the start process (but not always as will be shown in the Quotation message Chapter). When just starting to implement SCSN, it is very likely that one would start with implementing the Order and Invoice messages, as these are essential parts of a procurement process. This example describes a simple order process of off-the-shelve parts using these two messages and also includes the Despatch Advice message, which is often implemented next.
In a simple setting, there are only two organizations: one Buyer (i.e. initiator in this process) and one seller (i.e. receiver of the order). Note that in this example we abstract away from the service providers as described in the architecture in order to simplify the scenario.
For the simple order process a few messages are required. An example of an Order message is provided below, followed by a textual description of the four simple order messages. For a full specification of these messages, including all available properties, the allowed data types and cardinality constraints, please consult the technical documentation.
The buyer starts the process by formulating its demand in the form of a SCSN Order message. This message can contain simple off-the-shelve parts including its item identifier, but also complex custom-made sub-assemblies described using 3D drawings. However, in this example we only describe off-the-shelve items.
The order message is used by a buyer to communicate a new order or order update to a supplier. The order message contains data regarding the stakeholders associated with ordering and specifies delivery details such as the delivery date. The ordered products are specified in the order line, one order line may specify one product order, but multiple order lines may be used in one order message. This allows multiple products to be ordered in one order message. The order message also provides in varying types of surcharges or discounts. The buying party may specify these in the order message, but the supplier has to confirm this using the order response.
The order response is used by the seller to communicate to the buyer. The buyers order message contains what they want, and the sellers order response contains what they can provide. If the order response is not acceptable for the buyer they may sent another order message using the same order ID and line item ID, effectively overwriting the old order message. Using these two messages it is possible for buyer and seller to negotiate on the order specifics.
Because of this interplay between order messages and order responses they are largely the same. They differ in the sender attributes, where an order contains a buyer description, the order response contains attributes pertaining to the seller. Another miner difference is that an order message contains a reference to an earlier created quotation, while an order response references the ID of the order message it is a response to.
The despatch advice message describes a specific delivery of goods or services. It contains information regarding who makes the delivery and where it is going, as well as shipment information such as the time window in which it will arrive.
One despatch may contain multiple orders, or parts of orders. This is modeled by the despatch line component. A despatch line references an order line in a specified order and contains a certain quantity of the product. This allows partial deliveries of multiple orders in one despatch. The receiver of the message (and despatch) is responsible for determining whether the whole order is fulfilled by this despatch. This can be done by looking at the attributes of the goods item which represents the delivered product. This goods item may be nested in a package, which itself may be part of another package recursively. e.g. a product in a box, on a pallet, in a container.
The invoice message is similar to the UBL Invoice message and is used by the seller of a product to notify the buyer of the payment specifics. The invoice message contains reference to the purchase and sales order IDs as provided in the order message and order response respectively. It also contains information regarding all the stakeholders of relevance to the payment of an order, such as the buyer, seller, payee and tax representative. Finally the invoice contains a breakdown of the charges, taxes and payment instructions. The total to pay amount is also explicitly contained within the message in the "Amount due for payment" attribute.
Since the usage of the invoice message and its properties is relatively unintuitive, a longer description is provided on a dedicated message specification page.
