Unified Orders
Unified Orders
Everything you need to know about unified ordersUnified Orders are EVA’s efficient way of looking at orders that span multiple currencies, legal entities or sales and fulfillment channels. Traditionally such orders would result in "chains" of Purchase- and Sales Orders (POSO) that made integrating and financial tracking a challenge. EVA's Unified Orders concept greatly simplifies this set-up, whilst still offering you endless flexibility.
Background
The traditional way
UO-POSO.example.08.2023.png)
Let’s start with an example: a store buys replenishment goods from a central warehouse. Traditionally this would start as Purchase Order 123 (the store purchases from warehouse) that results in an export file for the warehouse as a signal for them to start packing.
To track the actual movement of goods leaving the warehouse, a secondary related Sales Order 124 would be needed. Once the warehouse ships the goods, which updates Sales Order 124, it would also automatically update order 123 for the store to receive against. Upon completion of each order invoices are generated and things are done.
The limitations and why we came up with Unified Orders
UO-UO.example.08.2023.png)
This initial set-up might work in a simple, traditional company landscape. But (y)our reality is more complex. What if that same Purchase Order 123, can be fulfilled by a mix of warehouses, external suppliers or even other stores? What if upon creation of that Purchase Order it might not even be known which locations can fulfill which portion of that order?
UO-example.complex.08.2023.png)
In the traditional Purchase Order / Sales Order (POSO) set-up, this single Purchase Order would then require many different chained Sales Orders to get fulfilled, each adding complexity to your set-up and integration.
For this reason our team came up with Unified Orders. Instead of triggering a complex jumble of "chained" Purchase- and Sales Orders for order spanning multiple OUs, we just use one order (with one order identifier) as the leading object throughout the lifecycle of that order.
One order, taking on multiple shapes
How you ‘see’ that order depends on which role you have in this lifecycle. If you are the Organization Unit (say, a store) buying goods via this order, all financial events and in-store implications will be that of a Purchase Order. But this same order is also used by the various sellers and fulfillment locations as the Sales Order to sell, ship and deliver the goods via – even on an API level.
The concept of Unified Orders applies to all orders in EVA, whether they start with a consumer buying or returning something, or it it's an Organization Unit in EVA initiating things. For "normal" in-store consumer orders and returns, not much changes. But as soon as an order involves multiple OUs for it’s fulfillment, the Unified Orders concept comes into play.
Understanding the basics step by step
Now that you know the background of Unified Orders – let's take a look at the basics needed to make this sing.
UO-basics.08.2023.png)
1. Properties on orders contain info about the origin and destination
Each Unified Order has key properties, which are exposed in various data objects in EVA or used in your Cookbook filtering:
SoldToOrganizationUnit
This is the Organization Unit buying goods / to which the goods are sold.
- In EVA this is stored as the SoldToOrganizationUnitID.
- Think of this to the Billing Address
- For example: a franchise company owning multiple stores
- It can also be the same as the ShipToOrganizationUnit (if billing equals shipping)
Note that this field is not filled when the Unified Order is designated for a consumer.
ShipToOrganizationUnit
The Organization Unit to which the goods are physically shipped.
- In EVA this is stored as the ShipToOrganizationUnitID
- Think of this as the Shipping Address
- For example: a franchise-owned store buying goods from a central organization
Note that this field is not filled when the Unified Order is designated for a consumer.
SoldFromOrganizationUnit
The Organization Unit selling goods / from which goods are sold.
- In EVA this is stored as the SoldFromOrganizationUnitID
- For example: a central organization at which stores / franchisers can buy goods
- In case of a consumer order this field is for example filled with the OrganizationUnitID of the webshop selling the goods
What happened to the ShipFromOrganizationUnit?
All of these above are fixed on an order and pre-determined when the order is created.
Because in our new reality orders it is not known upfront which OU ships the order(lines), the concept of the ShipFromOrganizationUnitID no longer exists. Instead we will use so-called fulfillment Lines, connected to a fulfillment Organization Unit.
- The Organization Unit actually physically shipping these goods is determined by Order Orchestration and stored in so-called fulfillment Lines.
- Previously the ShipFromOrganizationUnitID (as stored on an order) could be used in Cookbook for filtering – this is no longer supported.
Note that when migrating to Unified Orders, you need to ensure you no longer rely on the use of this property as it will no longer be filled.
2. Split between invoicing and fulfilling OU for purchase of goods
Before EVA supported Unified Orders, the only way to create a PO between a store and a warehouse, was by straight up defining that warehouse as the supplier of the order.
But what if this warehouse is not actually the the SoldFromOrganizationUnitID? In many cases, stores order from a central headquarters OU, without caring about which warehouse (or multiple) ends up physically supplying the products.
To make this work
Create a default supplier relationship in EVA between the SoldToOrganizationUnitID (for example the store or franchise entity) and the SoldFromOrganizationUnitID (the OU where goods are bought from) first. This takes care of the invoicing.
This SoldFromOrganizationUnitID in turn needs a default supplier relationship with the fulfillment OUs that can physically supply goods.
3. All orders are routed via Order Orchestration
Order Orchestration is EVA’s feature for determining which OUs are eligible for the fulfillment of an order, or even the individual order lines.
We already used this technology to route customer orders placed online to an eligible store for fulfillment (ship-from-store).
In Unified Orders, this logic is extended to orders in which entities purchase goods: EVA looks at each order and decides on the best possible OU to fulfill this order – even when it's for goods moving between OUs without a consumer involved.
In some cases you might want to leverage this technology; let EVA determine the best possible warehouse to perform fulfillment when a store purchases replenishment goods. In other cases you might want to dicate this yourself already, and send it in on the order.
In all cases you need an Orchestration Sheet. This can be as simple as:
fulfillment Purchase
action 'EXPORT_ORDER'
option OrderIntents as 'Purchase'
scope Supplier
require Supplier.BackendID = 'WAREHOUSE_NL' when Order.SoldFromOrganizationUnit.CountryID = 'NL'
OrderFulfillmentLines - the result of orchestration
Once a Unified Order is coming in, EVA's Order Orchestration determines from which location the order can be fulfilled. This allocation is stored in an OrderFulfillmentLine. Each order line can have multiple OrderFulfillmentLines, in case one order line with multiple products can be fulfilled from more than one location. Whether you allow such split shipments is configured in your Order Orchestration sheet. In case a fulfillment location cannot fulfill an OrderFulfillmentLine, EVA will re-orchestrate the order creating new OrderFulfillmentLines on the same order - until it is fully shipped.
Commitment of stock
The commitment of stock is handled automatically. When a store or franchiser (SoldTo) is buying goods from a central Headquarters (SoldFrom) and Order Orchestration determines that a certain Warehouse supplying needs to fulfill, EVA will automatically commit stock on that warehouse (preventing other orders from touching this stock).
4. Exporting a purchase order
If the Unified Order needs to signal a warehouse to pack goods, EVA will export the order with for instance the Warehouse Exporter or the Purchase_email exporter. The warehouse exporter will generate a JSON file while the Purchase_email will generate an email with an attached CSV. The Purchase_email can be configured through EVA Stencil.
5. Shipping the order
When an order is shipped, the stock is ultimately always deducted from the SoldFromOrganizationUnit of the order. In the non-unified scenario, there is a lot of magic "and if-then-elses" around where the stock comes from, but this has been simplified to: stock originates from where the Order is sold from.
In the case of a direct carry-out order in a shop, this is simply the shop as this is indeed also where the stock physically comes from.
In the case of for example a web-shop order, or in fact any case where the SoldFromOrganizationUnit is different from the organization that physically ships the order, the stock first needs to be (virtually moved) from the fulfillment OU to the SoldFrom OU. This is automatically done using transfer orders.
6. Transfer Orders: tracking the trail of ownership
To correctly track all legal and financial implications of a Unified Order that was fulfilled across multiple OUs, EVA will automatically create so-called Transfer Orders. These in part take over the role of the old chains of Purchase and Sales Orders, but with one difference: the Transfer Orders are created after shipment.
The following (oversimplified) example shows how one Unified Order can result in multiple Transfer Orders after shipment.
UO-transfer.order.08.2023.png){kind=spacer}
Why? Well, let’s take a ship-from-store order for example, based on a consumer buying online. Upon creation of that order EVA may Orchestrate that order, or even lines within that order, to a bunch of eligible stores for fulfillment. Store 1 might decline the task to ship, automatically re-routing the task to another store. Long story short; you don’t know who fulfilled the order(lines) until it’s actually done.
For this reason, EVA creates Transfer Orders between stores, legal entities, suppliers – basically all OUs involved with that order – once shipment is done. Since these Transfer Orders are created after the fact, they are instantly ‘completed’, creating a audit trail of (financial) stock ownership.
Completing the Transfer Order does these things:
- If the SoldFrom of the Transfer Order (so not the OU selling the Unified Order to the end customer, but the OU which physically shipped the goods) is an ExternalSupplier, ShipmentLines are created. We don't always create ShipmentLines for efficiency reasons here, only for orders from ExternalSuppliers for practical reasons (invoice matching for example).
- A StockMutation is created on the SoldFrom (the supplier of the transfer order) with Reason = Sold, based on its cost price values. This is to track the stock leaving this supplier.
- A StockMutation is created on the SoldTo (the receiver of the Transfer Order, this is also the OU acting as the SoldFrom of the Unified Order to the end customer) with Reason = InTransit. The amount of this StockMutation is the UnitPrice of the transfer order line, which is how much the receiver is paying to the supplier for the stock.
- Instantly a StockMutation is created to move this stock, that is now virtually on the Transit location via the previous action, to the Sellable location of the SoldTo (the receiver of the transfer order).
- The stock that was just created on the SoldFrom OU of the customer's Unified Order is then instantly used to satisfy the final stock reduction of the (virtual) shipment to the customer.
When are transfer orders needed?
Which Transfer Orders to trigger depends on how the buying, selling and fulfilling entities are linked via your supplier relationships and what the Intent of your Unified Order is. This Intent can be the purchasing of store stock from a central warehouse, but also stores shipping goods back to a warehouse or locations fulfilling a consumer order bought online. These transfer orders will ensure there is a proper legal trail of stock ownership - even if for a split second.
A transfer order is created when:
- the OUs involved with the order are in a different country;
- and/or they use a different currency;
- and/or are part of a different company (either by CompanyID or BackendCompanyID);
- and/or one of them is of type ExternalSupplier;
- and/or the SoldTo differs from the ShipTo;
- and/or the Fulfillment OU differs from the SoldFrom.
How many Transfer Orders are needed?
When a Unified Order is orchestrated and shipped, a path from the Fulfillment OU(s) back to the the SoldFrom OU is determined. This path is based on your Supplier Relationships.
Using that path, we determine if any nodes in that path need a transfer order. Between any different OU involved with the fulfillment of the Unified Order, a transfer order is generated.
Currency conversion
If two OUs have a different currency, you need to create financial events in the local currency of the buying entity. For this EVA has an integration with a service called Fixer.io to get the currency conversions. These conversions are automatically done upon shipment (booking goods to InTransit) and Receival.
Read more about currency conversion here
Preventing transfer orders between OUs for returns
In some cases you want to prevent transfer orders from being made.
To make this clearer: when returns are done in an OU which is different from the SoldFrom OU, you would normally want a transfer order to take place, but not if the two OUs are part of companies which share the same TaxID/VatNumber OR are part of the same company without a TaxID set.
You can influence this behavior by means of the Orders:Returns:UseTransferOrderForIntraCompanyReturns setting - it defaults to true. By setting it explicitly to false, it will prevent transfer orders from being created between OUs that are part of companies which share the same TaxID/VatNumber OR are part of the same company without a TaxID.
Invoices for transfer orders
By default, invoices are created for intracompany and intercompany transfer orders, each with their own invoice sequence.
You can optionally use the following settings to prevent these from being created:
TransferOrders:EnableIntraTransferInvoiceTransferOrders:EnableInterTransferInvoice
By setting one or both of these settings to true explicitly (default to false), the invoices and the corresponding sales and purchase financial events will no longer be created.
Examples of typical order flows and their financial breakdown
Below we have broken down a list of common order scenarios, and the financial events that are generated for them.
1.1. Single Currency PO
This scenario involves a single currency purchase order where 5 pieces are ordered in EUR and 5 pieces are received in EUR. The table below outlines the financial events that occur in this situation.
| Store | Amount | Event |
|---|---|---|
| Store NL | €250.00 | Stock received |
| Acme NL | €250.00 | Cost of goods |
| Store NL | €0.00 | Purchase tax |
| Store NL | €250.00 | Purchase |
| Acme NL | €0.00 | Sales tax |
| Acme NL | €250.00 | Sales |
| Store NL | €250.00 | Stock mutation |
| Acme NL | - €250.00 | Stock sold |
Stock sold A Stock Sold event is created when stock is shipped on an order. The amount is equal to the value of the stock that was shipped, according to the unit cost of the product, times the number of products sold.
Stock Mutation This stock mutation represents an ‘In transit’ event.
Sales Since the order is shipped and invoiced, the sales event is raised for the full value of the invoice.
Sales Tax The sales tax is 0, since it concerns an inter-company supply where there is no VAT liability.
Purchase The Purchase event is raised when a purchase order or part of a purchase order is invoiced. The value corresponds to the total value of the invoice in the currency of the receiving OU.
Purchase Tax The purchase tax is 0, since it concerns an inter-company supply where there is no VAT liability.
Cost of goods The cost of goods event corresponds to the total cost price value of all shipped and invoiced products.
Stock Received The stock received event corresponds to the total amount of products received times the united cost of the product.
1.2. Multi Currency PO
This scenario involves a multi currency purchase order where 5 pieces are ordered in EUR and 5 pieces are received in SEK. The table below outlines the financial events that occur in this situation.
| Store | Amount | Event |
|---|---|---|
| Store SE | SEK2,500.00 | Stock received |
| Acme NL | €250.00 | Cost of goods |
| Store SE | SEK0.00 | Purchase tax |
| Store SE | SEK2,816.11 | Purchase |
| Acme NL | €0.00 | Sales tax |
| Acme NL | €250.00 | Sales |
| Store SE | SEK2,500.00 | Stock mutation |
| Store SE | SEK-2,816.11 | Stock mutation |
| Store SE | SEK2,816.11 | Stock mutation |
| Acme NL | - €250.00 | Stock sold |
In this scenario, inventory is requested from a warehouse denominated in EUR, but is ultimately received in an OU that maintains stock in SEK.
Stock sold A Stock Sold event is created when stock is shipped on an order. The amount is equal to the value of the stock that was shipped, according to the unit cost of the product, times the number of products sold.
Stock Mutation This stock mutation represents an ‘In transit’ event.
Stock Mutation (Purchase Price Variance) The stock mutation event referred to here is once again classified as an 'In transit booking'. If a price list is employed for determining cost prices, as opposed to real-time currency conversion, the preceding event must be rectified. This results in a Purchase Price Variance (PPV) due to the variance between the invoiced value and the value assigned to the stock based on the price list. The stock mutation is attributed to PPV and may be utilized in cookbook recipes to recognize this event.
Stock Mutation (Purchase Price Variance) Because the 'In transit' event now has a 0 value, a third stock mutation event is raised using the price from the cost price list.
Sales Since the order is shipped and invoiced, the sales event is raised for the full value of the invoice.
Sales Tax The sales tax is 0, since it concerns an inter-company supply where there is no VAT liability.
Purchase The Purchase event is raised when a purchase order or part of a purchase order is invoiced. The value corresponds to the total value of the invoice in the currency of the receiving OU.
Purchase Tax The purchase tax is 0, since it concerns an inter-company supply where there is no VAT liability.
Cost of goods The cost of goods event corresponds to the total cost price value of all shipped and invoiced products.
Stock Received The stock received event corresponds to the total amount of products received times the united cost of the product.
1.3. Receipt surplus
This scenario involves an order of 5 products in EUR, but the company received 10 products instead. The financial events that occur in this situation are outlined in the table below.
| Store | Amount | Event |
|---|---|---|
| Store NL | €250.00 | Stock received |
| Acme NL | €250.00 | Cost of goods |
| Store NL | €0.00 | Purchase tax |
| Store NL | €250.00 | Purchase |
| Acme NL | €0.00 | Sales tax |
| Acme NL | €250.00 | Sales |
| Store NL | €250.00 | Stock mutation |
| Acme NL | €-250.00 | Stock sold |
| Store NL | €250.00 | Stock received |
| Acme NL | €250.00 | Cost of goods |
| Store NL | €0.00 | Purchase tax |
| Store NL | €250.00 | Purchase |
| Acme NL | €0.00 | Sales tax |
| Acme NL | €250.00 | Sales |
| Store NL | €250.00 | Stock mutation |
| Acme NL | €-250.00 | Stock sold |
In order to utilize the aforementioned events, the setting UseUnifiedSurplus must be set to true.
The events listed in the table pertain to instances where a quantity of products greater than the number of units initially ordered is received. As a result, a new order-line is generated for the surplus amount, subsequently triggering the events once again for this newly created order-line.
1.4. Receipt deficiency
In this scenario, an order was placed for 10 products in EUR, but only 5 were received. This situation is presumed to be the result of lost goods during transit. The financial events that occur in this situation are outlined in the table below.
| Store | Amount | Event |
|---|---|---|
| Acme NL | €-250.00 | Cost of goods |
| Store NL | €0.00 | Purchase tax |
| Store NL | €-250.00 | Purchase |
| Acme NL | €0.00 | Sales tax |
| Acme NL | €-250.00 | Sales |
| Store NL | €-250.00 | Stock mutation |
| Store NL | €250.00 | Stock received |
| Acme NL | €500.00 | Cost of goods |
| Store NL | €0.00 | Purchase tax |
| Store NL | €500.00 | Purchase |
| Acme NL | €0.00 | Sales tax |
| Acme NL | €500.00 | Sales |
| Store NL | €500.00 | Stock mutation |
| Acme NL | €-500.00 | Stock sold |
The above table outlines events that occur when the quantity of received products falls short of the initial order. This situation is presumed to be the result of lost goods during transit. Similar to surplus items, a new order-line with a negative quantity is created to reflect the deficit, thereby triggering negative financial events to account for the loss.
It is recommended to disregard the last cost of goods event as it is assumed that the goods have been shipped but failed to arrive. Despite adjustments being made, the COGS ledger must still take these goods into account, recognizing that they are no longer in inventory.
2. Return to Supplier (RMA)
2.1. Single Currency
This scenario involves a single currency RMA order where 5 pieces are returned in EUR and 5 pieces are received in the same currency. The table below outlines the financial events that occur in this situation.
| Store | Amount | Event |
|---|---|---|
| Acme NL | €250.00 | Stock received |
| Store NL | €250.00 | Cost of goods |
| Acme NL | €0.00 | Purchase tax |
| Acme NL | €250.00 | Purchase |
| Store NL | €0.00 | Sales tax |
| Store NL | €250.00 | Sales |
| Acme NL | €250.00 | Stock mutation |
| Store NL | €-250.00 | Stock mutation |
Stock Mutation A stock mutation event is created with the stock mutation reason ReturnToSupplier.
The amount is equal to the value of the stock that was shipped, according to the unit cost of the product, times the number of products sold.
Stock Mutation This stock mutation represents an In transit event.
Sales Since the order is shipped and invoiced, the sales event is raised for the full value of the invoice.
Sales Tax The sales tax is 0, since it concerns an inter-company supply where there is no VAT liability.
Purchase The Purchase event is raised when a purchase order or part of a purchase order is invoiced. The value corresponds to the total value of the invoice in the currency of the receiving OU.
Purchase Tax The purchase tax is 0, since it concerns an inter-company supply where there is no VAT liability.
Cost of goods The cost of goods event corresponds to the total cost price value of all shipped and invoiced products.
Stock Received The stock received event corresponds to the total amount of products received times the united cost of the product.
2.2. Multi Currency
This scenario involves a multi currency RMA order where 5 pieces are returned in SEK, and 5 pieces are received in the EUR. The table below outlines the financial events that occur in this situation.
| Store | Amount | Event |
|---|---|---|
| Acme NL | €250.00 | Stock received |
| Store SE | SEK2,500.00 | Cost of goods |
| Acme NL | €0.00 | Purchase tax |
| Acme NL | €221.94 | Purchase |
| Store SE | SEK0.00 | Sales tax |
| Store SE | SEK2,500.00 | Sales |
| Acme NL | €250.00 | Stock mutation |
| Acme NL | €-221.94 | Stock mutation |
| Acme NL | €221.94 | Stock mutation |
| Store SE | SEK-2,500.00 | Stock mutation |
Stock sold A Stock Sold event is created when stock is shipped on an order. The amount is equal to the value of the stock that was shipped, according to the unit cost of the product, times the number of products sold.
Stock Mutation This stock mutation represents an ‘In transit’ event.
Stock Mutation (Purchase Price Variance) The stock mutation event referred to here is once again classified as an 'In transit booking'. If a price list is employed for determining cost prices, as opposed to real-time currency conversion, the preceding event must be rectified. This results in a Purchase Price Variance (PPV) due to the variance between the invoiced value and the value assigned to the stock based on the price list. The stock mutation is attributed to PPV and may be utilized in cookbook recipes to recognize this event.
Stock Mutation (Purchase Price Variance) Considering the fact that the 'In transit' event now has a 0 value, a third stock mutation event is raised using the price from the cost price list.
Sales Since the order is shipped and invoiced, the sales event is raised for the full value of the invoice.
Sales Tax The sales tax is 0, since it concerns an inter-company supply where there is no VAT liability.
Purchase The Purchase event is raised when a purchase order or part of a purchase order is invoiced. The value corresponds to the total value of the invoice in the currency of the receiving OU.
Purchase Tax The purchase tax is 0, since it concerns an inter-company supply where there is no VAT liability.
Cost of goods The cost of goods event corresponds to the total cost price value of all shipped and invoiced products.
Stock Received The stock received event corresponds to the total amount of products received times the united cost of the product.
2.3. Surplus
This scenario involves an RMA order where 5 products were returned in EUR, but the the warehouse received 10 products instead. The financial events that occur in this situation are outlined in the table below.
| Store | Amount | Event |
|---|---|---|
| Acme NL | €250.00 | Stock received |
| Store NL | €250.00 | Cost of goods |
| Acme NL | €0.00 | Purchase tax |
| Acme NL | €250.00 | Purchase |
| Store NL | €0.00 | Sales tax |
| Store NL | €250.00 | Sales |
| Acme NL | €250.00 | Stock mutation |
| Store NL | €-250.00 | Stock mutation |
| Acme NL | €250.00 | Stock received |
| Store NL | €250.00 | Cost of goods |
| Acme NL | €0.00 | Purchase tax |
| Acme NL | €250.00 | Purchase |
| Store NL | €0.00 | Sales tax |
| Store NL | €250.00 | Sales |
| Acme NL | €250.00 | Stock mutation |
| Store NL | €-250.00 | Stock mutation |
To utilize the aforementioned events, it is imperative to ensure that the UseUnifiedSurplus setting has been set to true.
The events listed in the table pertain to instances where a quantity of products greater than the number of units initially shipped in the RMA order is received. As a result, a new order-line is generated for the surplus amount, subsequently triggering the events once again for this newly created order-line.
2.4. Deficiency
This scenario involves an RMA order of 10 products in EUR, but only 5 were received. The financial events that occur in this situation are outlined in the table below.
| Store | Amount | Event |
|---|---|---|
| Store NL | €-250.00 | Cost of goods |
| Acme NL | €0.00 | Purchase tax |
| Acme NL | €-250.00 | Purchase |
| Store NL | €0.00 | Sales tax |
| Store NL | €-250.00 | Sales |
| Acme NL | €-250.00 | Stock mutation |
| Acme NL | €250.00 | Stock received |
| Store NL | €500.00 | Cost of goods |
| Acme NL | €0.00 | Purchase tax |
| Acme NL | €500.00 | Purchase |
| Store NL | €0.00 | Sales tax |
| Store NL | €500.00 | Sales |
| Acme NL | €500.00 | Stock mutation |
| Store NL | €-500.00 | Stock mutation |
The above table outlines events that occur when the quantity of received products falls short of the number of products shipped in the RMA order. This situation is presumed to be the result of lost goods during transit. Similar to surplus items, a new order-line with a negative quantity is created to reflect the deficit, thereby triggering negative financial events to account for the loss.
It is recommended to disregard the last cost of goods event as it is assumed that the goods have been shipped but failed to arrive. Despite adjustments being made, the COGS ledger must still take these goods into account, recognizing that they are no longer in inventory.