Overview
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:
- Large Payments, split over mutiple modes
- Service or B2B indusry, where payments may not always be on a single transaction basis
- Flexible order mechanisms
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:
-
+------------------^------------------^---------------- .... --------^
| | | |
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)
-
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.
-
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.
Calculations
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:
-
Total Order discount = Sum of discounts across all Partial Amounts for all SubOrders
*all implies, realized and non-realized. This is because the worth of an order isits total worth, including payments yet to be made.
-
Total Order Worth = Root or Original Order Amount total - Total Order Discount
This way, the total is always adjusted against any discounts offered
-
Total Paid So Far = Sum of order worth of all realized SubOrders only
-
Remainder Payable = Total Order Worth - Total Paid So Far
-
SubOrder Payable = Amount only for the SubOrder, defined as an Advance or Remainder Payable
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.
