Make Order Ready Example

Placed orders are often placed in a "Shopping Cart" state (order.is_ready == false), where they do not affect Customer balance and Product quantities. Later, the end user might "check out" and make the order ready. This triggers a number of logic functions described on this page.

The following table contrasts the Not Ready and Ready states of an order:

Impact onOrder Not ReadyOrder Ready
Customer BalanceNo effect. The balance is not adjusted until you check out and make the order ready.The balance is adjusted by Orders amount_un_paid
Product QuantitiesNo effect. The inventory remains in stock and the reorder is not triggered.Increase total_quantity_ordered for each ordered product
Compute is_reorder_required


Requirements: Adjust Balance and Product Quantities

The following table summarizes Make Ready:

 Step In the example Notes
 Epic Order Processing 
 User Story Make Order Ready 
 BehaviorAdjust customer balance when order.is_ready=true 
 Behavior Adjust product total_qty_ordered when order.is_ready=true 
  Set is_reorder_required iff (onHand - qtyOrdered) < reorderQty

The challenge is that Product is not directly related to Orders, so, while Product wants to sum LineItem quantities, it cannot directly reference the Order isReady state.


API Creator solves this transaction by declaring the following logic:

Since the Customer has a Sum:

Derive customers.balance as sum(ordersList.amount_un_paid) where is_ready = true

The Balance is increased due to the qualification condition change (is_ready) now being met. You can define the following logic using Lineitem.is_readyThe LineItems.isReady Lineitems.is_ready formula is a parent reference, so changes are forward chain altered parent references to children to each Lineitem. This formula activates line item logic, where the change to the qualification condition adjusts the Product.totalQtyOrdered. The line item logic activates product logic, which computes products.is_reorder_required.

For more information:


The following image shows the relevant domain objects. The numbered arrows reflect the logic flow, described in the log and operation.

How to Run

  1. In Data Explorer, select the Customers table and the first Customer (Alpha and Sons).
  2. From the Orders tab, select the first order and click Zoom.
  3. Set the Is Ready to true, and then click Save.
    Observe this fails with a credit limit check.
  4. Click Undo.
  5. Reselect the first customer and increase their Credit Limit to 51, and click Save.
  6. Repeat steps 1 and 2.
    Observe now succeeds.
  7. Define one or more rules that solve the identified behavior, Check Credit. The logic triggered by each LineItems insertion is summarized as follows:
    StepObjectWatchesReacts byWhich chains to
    1 - Adjust SumCustomer.balanceorders.is_ready,
    Adjusts balanceValidation checkCredit
    (not shown)
    2 - Cascade parent referenceLineItems.Is_readyorders.is_readyComputes Is_readyOrders.amount_un_paid
    3 - Adjust sumProducts.total_quantity_orderedLineItems.Is_ready
    Adjusts total_quantity_orderedProduct.is_reorder_required
    4 - FormulaProducts.is_reorder_required Products.total_quantity_ordered,
    Computes is_reorder_required 

    For more information about forward chaining and parent adjustment, see Logic Execution.

  8. Observe this processing flow in the log. (Click the thumbnail for full screen.)

Concepts Illustrated

This example illustrates both kinds of multi-table forward chaining:
  • Parent adjustment from Orders to the customer balance.
  • Child cascade from Order is_ready to LineItems.

The credit check illustrates the most common business logic pattern: Constraining a derived result. It also illustrates the replicate junction pattern, wherein the Product sum references the Orders is_ready, by way of the Orders table.

More Information

For more information about forward chaining, including constraining chained derivations patterns and the replication junction pattern, see Logic Patterns.