In addition to regular e-commerce concepts, one may require advanced scenarios like Multi Order work flows. Where a particlar order may be split into multiple Related orders or Sub orders. This is useful for the following use cases but not restricted to:

It is important to note, that the nature of such flows is very custom and ususally application dependent, however we still attempt to abstract into a common denominator, to make it easier to extend and reuse some core concepts, allowing the project or application to focus only on application specific customizations.

Multi Order WorkFlows

Multi order workflows are useful in complicated billing situations where payments maybe broken for the same user (or even different though not common), where the mode of payments may differ from automatic to manual and other B2B scenarios.

Root or Original Order

In a multi order flow, there is always a primary seed or root or original order. For consistency, here on we will refer to this as Root. The root order, is the order to which all further related orders are tied. A root order typically will not have another root. I.e. for our sanity we can assume a root is one that has no other root, but it can have siblings and children. This is the order that defines the starting point of any particular order workflow, and should be the reference order through which all relations can be derived.

Any Order than maintains a relation to a Root is a Related Order. A related order will also maintain or inherit the core characteristics of the root like user and contact details of the user the order is with.

Sub Order

This is a specific and common case of Related order, where in addition to having a relation with root, every SubOrder has a relation with its sibling SubOrder. SubOrders denote a strict sequence with a notion of previous and next. A SubOrder type inherits everything a Related Order does from its root in addition it may inherit other root data like total amout for the order.

Multi Order relation types

This section defines advanced concepts, and maybe skipped by admin users who do not wish to understand the WHY's. or HOW's

The following are the scenarios that can represent difference types of muti-order flows, however not restricted to:

  1. +------------------^------------------^----------------  ....   --------^
    |                  |                  |                                 |
    Root(0th SubOrder) <--> 1st SubOrder <--> 2nd SubOrder <--> .... <--> Nth SubOrder

    In this, the root itself is a SubOrder and represents the start of a 2 directional list, where every SubOrder maintains a reference to its left (if not root) and right (if not the last). However, all also have a direct reference to Root (the 0th node in the list)

  2. Root(0th Any Order)
    +-- 1st SubOrder
    +-- 2nd SubOrder
    + ...
    +-- Nth SubOrder

    This is the same as the previous use case, except that here Root is not the start of the list and just a shared ancestor among all other SubOrder's, all SubOrders are related by a previous and next relation; except the Root. This is useful where there is a strict order flow from one to another in sequence. The choice of this over the previous is that in this the flexibility exists that the root order type does not have to be a Suborder.

  3. Root(0th)
    +-- 1st RelatedOrder
    +-- 2nd RelatedOrder
    + ...
    +-- Nth RelatedOrder

    This is the same as the previous use case, except that here the related orders do not share any relation with each other in any sequence. They only share a common root. This is useful for cases where multiple orders are not related to one another, but part of a Group that is defined by root.


Realized Orders

A realized order, is one for which a successful payment was made or acknowledged. This is important in calulcaitons with multiple orders, because when we have to use the amount paid so far as a variable then the system must distinguish between a realized and a non-realized order.

Partial Amount

In a multi order workflow, each SubOrder can also maintain its own Amount, called partial amount. This is the amount specific to that order, including any discount etc. The worth of the SubOrder is the amount payable for that SubOrder.

SubOrder Calculations

Due to this some interesting combinations come up in calculations. By default the standard definition for calculations are defined by the following. The concept of a partial order is only applicable for Suborder type of Orders.
It is again important to note that any application may define its own formules and override these in their Strategy. However for convenience, the following are establihed as default: These definitions, can be changed or overridden however provide some ground rules and insight into structuring your logic with clearly defined base concepts.
The development team should ideally write Tests to ensre the calculations are in accordance with application business needs. Multi order flows can be complex, and unit testing is not a luxury but a necessity.

Back to Top