Steven Sitas
Oct 31, 2018

Understanding Business Documents


Edited: Nov 1, 2018


The Business Document entity is probably the most unique and complex entity in the Data Models. It is used to support all Sales and Purchase Documents - Quotes, Orders, Shipments, Invoices, Payments etc. in a unified way.

At the "heart" of the entity is the bBusinessDocument table; don't confuse this table with the Business Document entity.

Every REAL Business Document has one [and only one] record in the bBusinessDocument table and depending on the nature of the document, record(s) in many other related tables.

For example, Sales Invoices, have related entries in the following tables:

  • bBusinessDocument_ProductLine

  • bBusinessDocument_TAXLine

and if you support Serial Numbers, Lot Numbers and Direct Payments, entries in the following tables also:

  • bBusinessDocument_SerialNumberLine

  • bBusinessDocument_LotNumberLine

  • bBusinessDocument_PaymentLine


Business Documents[BD] can be in ANY currency and they can be changed or deleted as long as they are not posted. When a BD gets posted, various transaction entries are created in the transaction tables [always in the implementations LOCAL currency] and the BD cannot be changed or deleted.

Note that in v2 we have included 2 new BPs that can "act" on posted BDs - purge and update. See the project for more information ..

The posting of a BD is controlled by the following fields: bBusinessDocument.bPosted and nBusinessObjectRole_PST.

Do not confuse bBusinessDocument.bPosted with bBusinessDocument.bPostedGL. The later controls the posting of the BD to Accounting.

What entries are created [or posted] in the transaction tables depends ONLY on the nBusinessObjectRole_PST value - and this is a BD wide value.

You can find a list or enumeration of the above values in the Projects, project code, with a simple explanation. To understand these enumerations see the code in the CODE BRICKs, where everything is included in a simple switch statement !!


I am deliberately keeping this post short, so I can post "underneath it", various answers to questions we have received about BDs.

Feel free to "reply or add a comment" to this post with any questions you may have about Business Documents.

Steven Sitas
Oct 31, 2018Edited: Oct 31, 2018

Business Documents and their data should NOT be used for legal reporting - always use the entries in the transaction tables and/or in the _sum tables.

Amounts etc in BDs could be in any currency - in transactions and _sum tables they are always in the local currency.


Steven Sitas
Oct 31, 2018Edited: Nov 1, 2018

Although the current alpha360 data models are "pure relational", there is no reason why the Business Document entity could not be, say, an XML file.


This would give the system "great versatility" and a "very flexible structure" to easily move Business Documents between applications, users and installations.

We have carefully designed the BPs to support such a structure in the future, although it might not be obvious right now.


Steven Sitas
Oct 31, 2018Edited: Nov 1, 2018

What do you mean by Workflow in Business Documents ?


It is the support for transforming BDs from one type to another.

Say, Order BDs to Shipment BDs.

Don't confuse it with allocations.
WorkFlow is for products and allocations are for AP/AR Debits and Credits


Steven Sitas
Oct 31, 2018Edited: Nov 1, 2018

What has changed in v2 with the Workflow in Business Documents ?


Short answer: everything ...

WorkFlow is now very easy to understand and has 90% less code !!

To make this happen, we made the following changes to the data models and the BPs:

  • The previous bSales table that supported Quotes, Orders, Shipments and Invoices has been replaced by 4 tables [bQuote, bOrder, bShipment, bInvoice]

  • Same for bPurchase

  • The information for the due data, used in WorkFlow, is now included in the BDs and NOT in the transaction tables.


Steven Sitas
Oct 31, 2018Edited: Oct 31, 2018

Is every REAL Business Document an alpha360 Business Document?


All AR and AP documents [Invoices, Payment, Orders etc] are Business Documents

All Inventory documents [Census, Movements, Adjustments] are Business Documents


Accounting Batches and Expense/Revenue Budgets are NOT Business Documents

New Posts
  • Steven Sitas
    Oct 31, 2018

    When we started the ERP projects our main goal was to publish the alpha360 data models; the WX projects where just "limited core" projects to help developers better understand the data models. Things have changed a lot since the early days of the projects and - especially with v2 - they are now more complete; more developers are using them to develop their own solutions. So what is the best way to "follow up" with NEWER versions and "include" new features of the projects in YOUR solutions? Starting with version 2 releases, all projects, have now a reference version ; this is always the first, non beta release [with the exception of the Retail project] - release 2.07 is the reference version for all projects. All our additions and changes are done with reference to version 2.07 and the details are included inside the projects. So a simple search, say for 2.08, is sufficient to find all changes and additions we have done in v2.08. There are also some great features in the WX IDE; you can Search for last changes, compare projects etc. Just note that you should also use some kind of notation in YOUR projects to "label" YOUR changes or additions. A good practice would also be to create YOUR own windows or reports, instead of doing extended changes to ours and of course label them accordingly. We can also include YOUR code/changes directly in newer versions, if we think they are of GENERAL INTEREST; but note that they will be available to all licensees. The above does not affect in-house developers with a consultancy contract - their changes and additions are always kept synchronized by our developers.
  • Steven Sitas
    Oct 29, 2018

    Table Names In the alpha360 data models, tables or data files, are of one of the following types: Dimension table Transaction table Sum table Although it might seem "strange", most of the tables in the data models, are Dimension tables - gParty, sSalesArea, bBusinessDocument etc are all Dimension tables. The only reason they exist is because we need them to post to transactions, to help us with grouping, reporting and statistics and "maybe" for audit reasons ... Our financial data is included in the transaction tables and "sum values" for financial data are included in the "sum tables". Sum tables just help us "do things like reporting faster" AND can be reconstructed - at any time - from the data in the transaction tables !! All transaction and sum tables - except those that are used in Accounting - start with a "t". Additionally sum tables end with a "_sum". The transactions in Accounting are named aAccountingTransaction and the sums are named aAccountingFY_sum (Fiscal Year Sums) and aAccountingRP_sum (Fiscal Period Sums). Now all other tables - of type dimension - start with a letter that "tries to show" where they are used. Everything that starts with a "g" means that the table is probably used in many functional areas - like "gParty". Here is a short list: "a": for Accounting "b": for Business Documents "c": for CRM "r": for Restaurant "j": for POS "h": for HRM "s": for Sales "p": for Purchases "f": for Public Sector Accounting "x": for Access Control Field Names String fields start with the lower case letter " s " Memo fields start with the lower case letter " m " Integer fields start with the lower case letter " n " Real fields start with the lower case letters " nr " Decimal fields start with the lower case letters " nd " Currency fields start with the lower case letter " c " Date fields start with the lower case letter " d " DateTime fields start with the lower case letters " dt " Time fields start with the lower case letters " d " Boolean fields start with the lower case letter " b " ​ Primary keys end with  _PK and Foreign keys end with  _FK . take a look here for more information:
  • Steven Sitas
    Oct 29, 2018

    If you are having difficulties accessing your downloads or you have "misplaced" your license info send us an email and we will fix it !! Due to possible time differences, just give us 1 working day ...


Leoforos Dodonis 43,  45221


Registered VAT ID: EL084190121