Universal Business Document

The most important and unique concept in the alpha360 Data Models is the Universal Business Document (UBD).

It is a set of tables and relations that can be used together to implement all the Business Document Entities, in the alpha360 project.

Business documents - invoices, orders, credit notes, bills etc - are documents (on paper or electronic documents) that represent you in relation to external or internal parties.

The only major "Document type entity" in the alpha360 project that is not implemented from the UBD is the Batch Document in General Ledger.

A general and simplified graph of the Universal Business Document

• bBusinessDocument

Every Business Document in the alpha360 project has always one and only one bBusinessDocument record.

All records from other tables are directly related to this record - using the PK, bBusinessDocument.sBusinessDocumentPK field.

• bBusinessObject

Every bBusinessDocument is related to one and only one bBusinessObject record.

The most important field here is the bBusinessDocument.nBusinessObjectRole field. The UI and the BPs use this value, now part of the Business Document, to distinguish between various types of Business Documents.

The enBusinessObjectRole Enumeration, found at the Project code area of the WX project, has a list of all the types implemented in the current ERP version.

• bSales, bSalesAR, bPurchase, bPurchaseAP, bInventory

These tables, by their existence, play the most important role in the implementation of specific Business Documents.

1. bSales is used for implementing Sales Invoices, Shipments, Orders and Quotes.
2. bSalesAR is used for implementing AR Payments, General AR Debits and General AR Credits
3. bPurchase is used for implementing Purchase Invoices, Shipments, Orders and Quotes.
4. bPurchaseAP is used for implementing AP Payments, General AP Debits and General AP Credits
5. bInventory is used for implementing Inventory Transactions - moving products between warehouses, Inventory counts etc .

If one of the above exists, it is related to one and only one bBusinessDocument record - using its sBusinessDocumentFK field, which acts as a FK and a PK at the same time.

Please note that we could unite the first 4 tables and use only one table, say bSomething. Since they share so much information, this could be a valid design decision. The reason we keep them separate is because this separation helps us physically distribute data, something needed with large databases.

• bBusinessDocument_ProductLine

This table is used to store the products (or services) of say an Invoice (or a Shipment etc).

This table can store many records related to a bBusinessDocument record.

Every record here is also related to one and only one gProduct and one and only one gWarehouse and can be related to a gSerialNumber and/or to a gLotNumber record.

A Business Document that does not need to handle products, like the SalesAR, does not need to include this table.

• bBusinessDocument_ExpenseLine

This table is used to store the expenses of say an Invoice.

This table can store many records related to a bBusinessDocument record.

Every record here is also related to one and only one gExpense record.

A Business Document that does not need to handle expenses, like the SalesAR, does not need to include this table.

• bBusinessDocument_TAXLine

This table is used to store the taxes of say an Invoice.

This table can store many records related to a bBusinessDocument record.

Every record here is also related to one and only one gProductPartyTAXPosting record.

A Business Document that does not need to handle taxes, like the SalesAR, does not need to include this table.

• bBusinessDocument_CashLine

This table is used to store the analytic cash payments of say a SalesAR Payment.

This table can store many records related to a bBusinessDocument record.

Every record here is also related to one and only one gCashBook record.

A Business Document that does not need to handle payments, like a Sales Shipment, does not need to include this table.

• bBusinessDocument_CheckLine

This table is used to store the analytic check payments of say a SalesAR Payment.

This table can store many records related to a bBusinessDocument record.

Every record here is also related to one and only one mCheck record.

A Business Document that does not need to handle check payments, like a Sales Shipment, does not need to include this table.

The easiest way to understand the Universal Business Document concept is by using it to implement a specific Business Document Entity.

To avoid all the relational theory "jargon" we will use tables and relations from the above graph and directly add records to these tables.

Let's create a Sales Invoice Document

• step 1 - add a record to the bBusinessDocument table - the bBusinessDocument.sBusinessDocumentPK value, the PK, is assigned automatically by a BP.

This record must also point (through a FK) to a valid bBusinessObject record.

All the BPs in the implementation depend on information they retrieve from this bBusinessObject record.

• step 2 - add a record to the bSales table and use the value of the bBusinessDocument.sBusinessDocumentPK field as a PK for the bSales record .

Since this is also a FK for the relation between bSales and bBusinessDocument, the name of the field is bSales.sBusinessDocumentFK.

This record must also point (through a FK) to a valid gParty record.

• step 3 - add one or more records to the bBusinessDocument_ProductLine table - every BusinessDocument_ProductLine record must be related to one and only one bBusinessDocument record - it stores all the products that are included in the Invoice.

This record must also point (through a FK) to a valid gProduct record.

• step 4 - add one or more records to the bBusinessDocument_TAXLine table - everybBusinessDocument_TAXLine record must be related to one and only one bBusinessDocument record - it stores all TAXes for the Invoice.

These records must also point (through a FK) to valid gProductPartyTAXPosting records.

From the above steps, it is obvious which tables and relations we should "pick" from the UBD to implement an Invoice Entity - and since the Invoice Entity has many similarities to Quotes and Shipments, we can "unify" them in one entity, the Sales Entity.

Of course Business Documents are more than just Entities.

They have UI elements and Business Processes to support them.

The current version of the alpha360 ERP implements the following Business Documents:

• Sales Document - Sales Quotes, Orders, Shipments, Invoices, InvoiceShipments ...
• SalesAR Document - SalesAR Payments, SalesAR General Credits and SalesAR General Debits
• Purchase Document - Purchase Quotes, Orders, Shipments, Invoices, InvoiceShipments ...
• PurchaseAP - PurchaseAP Payments, PurchaseAP General Credits and PurchaseAP General Debits
• Inventory Document - Starting Inventory, Moving Inventory, Add and Minus Inventory counting

Can an Invoice document support cash Payments in the same document?

Easy - just add the bSalesAR table and the bBusinessDocument_CashLine table to your Invoice Entity.

This is already included in v1.0 of the ERP - see the SalesPOS for more info.

We could say that, in some way, the Business Document Entities mentioned above are actually constructed of Dimension tables (or maybe of XML structures etc .).

This becomes obvious when you see these Entities graphs in the chapters that describe them.

But there is also another important set of tables - called fact or transaction tables - that are "created" when we Post Business Documents.

although we use transactions to post a Business Document, do not confuse "transaction tables" with "transactions".

The most important transaction tables in the alpha360 ERP are:

• iInventoryTransaction
• gPartyTransaction
• aAccountingTransaction

Posting a Business Document

Every Business Document can be in one of the following 2 states:

• UnPosted
• Posted

When a Business Document is unposted, it has NOT created any records (entries) in the transaction tables. These entries - depending on the type of the Business Document - are created when a Business Document is posted. When these transaction records are created, alpha360 ERP also updates various SUM tables that keep sum information for each year and/or fiscal period.

Unposting a Business Document deletes all the related entries in the transaction tables and updates any sum tables affected by the transaction.