Client Processing Functional Approach
Purpose
This document describes the core functional approach taken by the Client Processing system. These core concepts are important to understand as they inform how the rest of the system works and informs how new workflows can be built on top of these core functional principles.
Core Principles
Below are some of the core principles that the system was built around
-Transaction Centric — Client Processing is a transaction centric system. Any data that can be treated as a transaction should be. This is obvious for REVENUE_ITEM and BILLING_ITEM but can also be seen in the implementation of BILLING_ITEM_DEDUCTION. Cash Receipt processing is taking this concept even further with the implementation of a CASH_WORKSHEET. Cash application is not a simple transaction as it collects a lot of user data and when committed creates many transactions. For this reason, the CASH_WORKSHEET wrapper has been implemented as a "Transaction of Transactions".
As a result of the transactional nature of the system, it is important that ACID compliance is supported. Taking this further, the system is designed to prevent users trying to generate transactions that would conflict with each other. As an example, when a users evokes and CREATE WORKSHEET on a CASH_RECEIPT the system should not allow any other user to try and create CASH_WORKSHEET on that CASH_RECEIPT until the other transaction is completed or aborted. Same is true for a user evoking an EDIT of a CASH_WORKSHEET.
-Immutability — All of the core data elements of a transaction should be immutable. Any changes that need to be made to transaction should result in the previous transaction being reversed and a new one to be created. To maintain connection between transactions, all transaction tables should have a parent or _REF field that remains the same throughout the reversal and creations.
While using the _REF link is suggested where it makes sense, there are situations where it makes more sense to point to the PK of the table instead of the _REF. CASH_RECEIPT_APPLICATION is an example. This is a significant design consideration that has been made when making the system immutable through transactions. Any references to the PK of a core transaction table needs to be maintained by the transaction engine. Continuing with the CASH_RECEIPT_APPLICATION example, when a BILLING_ITEM is rebilled, the records in CASH_RECEIPT_APPLICATION need to be updated to point to the new current BILLING_ITEM_DETAIL_ID.
There are a few exceptions to this rule such as OPEN_ITEM_IND , CURRENT_ITEM_IND which are allowable to facilitate in searching optimization.
By following this principal, it also ensures that fields like BALANCE and AMOUNT_PAID are not created. Values that need to be constantly updated or have business meaning should be avoided. Instead, these values should be computed in real time. For instance, to find out the balance of a billing, the total amount applied to the billing should be computed.
-Duplicate Master Data on Core Transactions — The following fields have been intentionally duplicated onto all transaction fields: UTA_ENTITY_ID, DEPARTMENT_ID, CLIENT_ID, BUYER_ID, DEAL_ID. This was intentional as these are key data elements and while it is likely these could be inharited from parents of some sort, this implementation has two distict advantages: 1. No restrictions on grouping - A collection of transactions can be grouped in any way necessary without limitations due to parent/child hierarchies. For instance, if Client was inherited from Deal, then it would restrict deal to having just 1 client or a billing from having all the clients in a deal. 1. Manage Changes over Time - While these are core meta data items that are very unlikely to ever change, it is not impossible. For instance, if 2 UTA entities collapse into 1 or Departments are changed, then the system needs to be updated to handle it. In both cases, it is feasible that the change will take place from a point in time or inception to date. Having this data on all of our core transactions allow us to handle those changes via a careful datafix.
-Avoid Metadata on Transaction — While the previous principal outlines the importance of Master metadata being added to the core transactions, adding any other meta data is strongly discouraged. A perfect example of this is AGENT. It should be obvious that AGENT is a very important data element and going to be required for much of the systems reporting, screens and security. However, the AGENT is not actually part of the transaction in the most strict of sense. Agents change over time and often there are agents added or removed from attribution to a transaction. It is possible for different agents to be associated to a transaction differently depending on who is asking (Clients "primary" agent vs "booking agent"). SHOW is another example of meta data that one could argue should be on a transaction record but should not be. SHOW is only part of some transactions. Adding fields that are specific to departments or deal types is discouraged.
When needing to associate metadata to a transaction, it should be done in a dedicated table and referenced using the _REF field. A join to the main tables _ID field should be avoided because an update would make that ID non-current and have to be maintained by the transaction engine.
Continuing with the example of SHOW, a tabled called REVENUE_ITEM_SHOW is created. It will have a SHOW_ID and a REVENUE_ITEM_REFand be a Many:1 relationship. On this table (and any children tables needed) all the metadata needed for the show can be linked to the REVENUE_ITEM and used for screens and reporting as necessary.
-Separation of Transactions from Accounting — Client Processing has 2 distinct levels: Transactional and Accounting. Most of the transactions will result in accounting entries being created but transactions are distinctly different from accounting. Accounting will be generated at specific times or in response to specific requests based on Transactional data. In come cases, all transactions will be processed into accounting individually and in others they will be aggregated and/or rolled up (See Accounting Engine).
-Code Types with Attributes — Client Processing utilizes a lot of process or workflows. The primary way this is managed is through status flags. Additionally, as a transactional system, many of the transactions utilize a TYPE flag. To manage these and any other more "common" dropdown lists, a CODE_MASTER concept is implemented. Whenever possible, these CODE_MASTER values should be used to directly drive functionality and workflow through the use of attributes. This allows for workflows to be easily established and extended with minimal coding or change. As an example, a CASH_RECEIPT has multiple statuses such [Draft, Submitted, Posted, Reversed]. As you can see the first two are "Not Posted" type statuses and the last two are "Posted". An attribute of POSTED is added here so all cash activity reports and simply reference that attribute instead of hard coding status values. If a new status value is added in the future, nothing needs to be updated.