Understanding the Business Documents in alpha360

As you probably know by now all Quotes, Orders, Shipments, Invoices, and Payments in alpha360 are called Business Documents.

Every Business Document has a “root” entry in the bBusinessDocument file and its “functionality” is controlled by the linked bBusinessObject entry.

So, if it is linked to a bBusinessObject with nBusinessObjectRole = 3005 then it is a Sales Invoice – you can find the various nBusinessObjectRole(s) in the project code (enBusinessObjectRole Enumeration).

The bBusinessDocument has various fields that are common to ALL of the Business Document types – like the bBusinessDocument.dTransactionDate field. But the most important field is the bBusinessDocument.sBusinessDocumentPK which is used as a Primary Key for the bBusinessDocument file and a Primary Key for various files, connected to the bBusinessDocument file, with a One-to-One relation. It is also a Foreign Key for various files, connected to the bBusinessDocument file, with a Many-to-One relation.

Now let’s take a closer look at the files needed to “construct” a Business Document of the Invoice type:

bBusinessDocument [Root]

- sBusinessDocumentPK is the PK

· The bBusinessDocument file has data common to ALL Business Documents (like Dates, Posting etc.)

bSales [One-to-One with the Root]

- sBusinessDocumentPK is the PK

- sBusinessDocumentPK is also the FK to the bBusinessDocument file

· The bSales file has data common to ALL Sales Invoices (like Parties etc.)

bBusinessDocument_ProductLine [Many-to-One with the Root]

- sBusinessDocument_ProductLinePK is the PK

- sBusinessDocumentPK is the FK to the bBusinessDocument file

· The bBusinessDocument_ProductLine file has entries for the Products [or Services] of the Sales Invoice.

A Sales Invoice can have other entries of type [Many-to-One with the Root] depending on its functionality – see the analysis for more details.

If the Sales Invoice is NOT posted the above is the only data for the Sales Invoice in the ERP – generally, NO economic statements or reports can/must be done from the above “structure”.

As soon as you POST the Sales Invoice, various transaction entries are created, and economic statements and reports can/must be done “against” these transaction entries.

The Sales Workflow

The alpha360 ERP supports –in its base functionality – the Sales (or Purchase) workflow.

This just means that you can create a Sales Quote, transform the Quote to a Sales Order, transform the Order to a Sales Shipment, transform the Shipment to a Sales Invoice and finally Pay (or settle) the invoices debit.

All transformations can be done partially and completed later _AND_ can start or skip steps in the Workflow – as you can partially Invoice a Sales Quote in one step.

· Only Business Documents that have been POSTED can participate in a workflow.

The most important data in the Sales Workflow – transformed or copied in every step – are the products or services, included in the bBusinessDocument_ProductLine file.

The field bBusinessDocument_ProductLine .ndQuantity_Due keeps track of the quantities of every product line that has NOT been transformed to a later stage and gets updated every time a new transformation is done (or deleted).

All Business Documents, that are NOT in the last stage of the workflow (like Sales Invoices), have information about their workflow status. For Orders, this information is in the bSalesOrders file [One-to-One with the Root], in the field niWorkFlowStatus, and is automatically calculated in the ERP by the procedure BP_BusinessDocument_WorkFlowStatus_private.

The above procedure uses information from the bBusinessDocument_ProductLine .ndQuantity_Due field from the connected bBusinessDocument_ProductLine(s).

The above design has changed significantly from v1 of the ERP and is now very easy to understand, very versatile, supports complicated transformations (like transforming part of a Quote to an Order and the remaining part to an Invoice, etc.) and is FULLY reversible. This means that if you delete an Invoice created by the transformation of saying an Order, the Quantity Dues are “returned back” to the Sales Order.

In v3 – coming October ’21 – we have also “loosened” the control of the workflow cycle. You can now delete say an Order, that has been transformed to a Sales without the ERP complaining.

The Supply Workflow

In General, it follows the same steps and design as the Sales WorkFlow.