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


Type of Workflows:

Purchase Orders: nProductWorkFlow

Purchase Shipments: nProductWorkFlow

Purchases: nPaymentWorkFlow

PurchasesAP: nPaymentWorkFlow


To better understand Workflows lets see the life cycle of a Purchase 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 Purchase 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 Purchase Shipment.

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

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


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

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

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


4. Both Purchase Shipments are transformed to ONE Invoice (with a Payment agreed in 30 days).

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

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


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

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

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


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


* All the Purchase Documents refer to the same Supplier ...


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

  • nProductWorkFlow - used with documents that handle products

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


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

this type of workflow is controlled by data in the tSupplierTransaction and tSupplier_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 Supplier - can be done directly form Credits and Debits from the tSupplierTransaction 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 PurchasesOrder to a PurchaseShipment),
  • all Purchases and PurchasesAP allocations are controlled by entries in the tSupplier_allocate table, except when a direct payment is been done (like say in Retail).

In this case the data is in the tSupplierTransaction table and NO entries exist in the  tSupplier_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