Workflows are actually special states of BusinessDocuments and depend on their type.


Type of Workflows:

Sales Orders: nProductWorkFlow

Sales Shipments: nProductWorkFlow

Sales: nPaymentWorkFlow

SalesAR: nPaymentWorkFlow


To better understand Workflows lets see the life cycle of a Sales Order:


1. An Order is entered in the System with say 10 A products and 5 B products (A and B are SKUs/IDs).

- the Sales Orders nProductWorkflow is assigned a value of 1 (Due - that means NO products have been Shipped yet).


2. The above Order is partially shipped - transformed to a Sales Shipment.

- the Sales Orders nProductWorkflow is now assigned a value of 2 (Partial Due - that means ONLY SOME products have been Shipped).

- the Sales Shipments nProductWorkflow is assigned a value of 1 (Due - that means NO products have been Invoiced yet).


3. The remaining items of the Sales Order are Shipped.

-  the Sales Orders nProductWorkflow is now assigned a value of 3 (Completed - that means ALL products have been Shipped).

- and now we have 2 Sales Shipments with nProductWorkflow equal to 1 (Due - that means NO products have been Invoiced).


4. Both Sales Shipments are transformed to ONE Invoice (with a Payment agreement /30 days).

- Now we have 2 Sales Shipments with nProductWorkflow equal to 3 (Completed - that means ALL products have been Invoiced)

- and a Sales Invoices with nPaymentWorkflow equal to 1 (Due - because the Invoiced hasn't been paid yet)


5. We add a new Payment to SalesAR, equal to the Due Amount of the Invoice.

- The Sales Invoices nPaymentWorkflow continues to be equal to 1 (Due - because the Invoice hasn't been allocated yet)

- and the SalesAR with nPaymentWorkflow equal to 1 (Due - because the SalesAR hasn't been allocated yet)


6. We allocate (or match) the SalesAR to the Sales invoice, and both nPaymentWorkflow fields are now equal to 3 (Completed)


* All the Sales Documents refer to the same Customer ...


As you can see from the above there are 2 types of workflows:

  • nProductWorkFlow - used with products

this type of workflow is controlled by data in the dbBusinessDocument_ProductLine table - especially the cQuantity_Due field.


  • nPaymentWorkFlow - used with Sales Payments (or Credits etc).

this type of workflow is controlled by data in the tCustomerTransaction and tCustomer_allocate tables - especially the cDebitAmount_Due and CreditAmount_Due fields.


Notes

  • partial transformations and allocations are supported,
  • an Order can be directly (and partially) transformed to a Shipment /and or an Invoice and a Shipment to an Invoice,
  • allocations - for the same Customer - can be done directly form Credits and Debits from the tCustomerTransaction entries,
  • both type of workflows are controlled by code in the relevant BP_Add*, BP_Modify*, BP_Delete*, BP_Post* and BP_UnPost* BPs,
  • the projects include code (and BPs) and UI handling that transform one type of business document to another type (say a SalesOrder to a SalesShipment),
  • all Sales and SalesAR allocations are controlled by entries in the tCustomer_allocate table, except when a direct payment is been done (like say in Retail).

In this case the data is in the tCustomerTransaction table and NO entries exist in the  tCustomer_allocate table.


For more information see the WX Project(s).


Simple Diagram of the Allocate Entities

* the above diagram is NOT complete - for more information see the database schema