ERP hub Order Entity Model
Following UML diagram shows the order entity model in the Litium Connect ERP Hub. For clarity and simplicity, it is simplified and not all attributes and relationships are shown.
There are several key differences between Litium 7.x Ecommerce entity model and the above entities, which are described below.
- Order entity represents a sales order (SO) or a sales return order (SRO) from Litium. Whether it’s a SO or a SRO is defined by the Order::OrderType property.
- In case of a SRO, then the Order::OriginalSalesOrderId property refer to the SO for which the current SRO is originating from. The Order:RmaIds contains the list of RMA ids that are associated with this SRO.
- In case of a SO, and if there exists SROs for this order, their ids are listed in the Order::SalesReturnOrderIds list. The Order:RmaIds contains the list of all RMA ids that are associated with this SO.
- Order::AdditionalInfo can be used to store any project specific data.
- Order::BillingAddress contains the billing address.
Order::VatSummary
If the order contains products that belongs to different VAT bands, a summary of total order amount by VAT band is presented in the VatSummary property.
For example, given an order that contains following info:
The VatSummary property would contain the following, where key is Vat Rate and value is Total Vat amount.
At the time of placing an order, the end-customer is only selecting a shipping method, and a shipping address.
Other integrations to transport administration systems may generate reference ids to those systems. When the Transport Administration hub is made, those information may be presented in a separate entity, or may be incorporated into the ShippingInfo entity. In the first implementation of the Erp Hub, these information will be available through the ShippingInfo::AdditionalInfo property.
Entity containing information about the end-customer. Since the order contains both the billing address as well as the delivery address, this CustomerInfo object does not refer directly to an address.
All the financial information of the order is represented by the OrderRow instances associated with the order. These include products bought, fees and shipping costs as well as discounts, promotions and a rounding off adjustment (if there is any). The type of the order row is represented by the OrderRow::Type, which has enumeration values such as Product, Promotion, ShippingCost, Fee, etc.
Sum of financial properties of the set of order row objects gives the total order value for that property. For example, sum of all OrderRow:TotalVat gives the total order VAT amount i.e. Order:TotalVat, and sum of all OrderRow::TotalIncludingVat will be equal to the order grand total, i.e. Order:GrandTotal.
Promotions (campaign discounts) applied to an order may result in one or more separate order rows, as demonstrated in following example.
Example: Product A has a buy 3 pay for 2 promotion. Product B has a 10% discount promotion. A order with 3 of product A and 1 of product B, would result in following order rows.
The PromotionInfo objects should be used to associate an order row to its promotion order row. For example, OrderLine_1 is associated with OrderLine_3 through the PromotionInfo entity which has the Id 3_for_2.
This way, a given order line may result in multiple promotion lines, within the same order. It is possible to give a 10% discount, as well as a 20% discount to the same order line. (A limitation in Litium 7 api does not allow creation of such orders as at now though)
Payment is at the same level as the order entity in Litium Connect.
This means, a given payment can be associated with several orders. The typical use case is, when there are sales returns. The SRO will be associated with the same Payment as the SO from which the products are returned.
All payment providers in the market are working on lowest monetary unit level. Therefore the payment objects has the financial properties (e.g. Transaction::TotalIncludingVat) are represented in integers in lowest monetary unit, i.e. cents. E.g. a 100 SEK value, in the payment objects would be represented as 10000 cents. This way, the ambiguity of decimal rounding off is eliminated.
A given payment may have several transactions. A typical SO has following transactions.
- Authorization: When the money is reserved in end-customers credit card. Typically this is made at the checkout phase.
- Capture: When money is taken from end-customers account, typically just before order is shipped.
If there are refunds and cancellations, corresponding refund and cancellation transaction entity instances would be recorded into the transaction object.
A transaction may consist of several TransactionRows. A TransactionRow is the counter part of the OrderLine, that would be sent to a payment provider. Each TransactionRow corresponds therefore to exactly a single OrderLine.
A given OrderLine may however be part of several transactions. For example, the authorization transaction and capture transaction refer to the same order line.
When an order is first placed, the information such as delivery address, information from delivery checkout are contained in the ShippingInfo entity. When the merchants order fulfilment systems process the order and create shipments to be delivered to the buyer, those information is represented by Shipment entity.
In other words, ShippingInfo contains information as collected during the checkout process and is furnished by the buyer (and delivery checkout). In contrast to, Shipments are created during the order fulfilment process, and is furnished by the ERP and Warehouse management and logistics systems.