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.
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.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.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 CreditsWhat 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.
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