ITCSA’s Block ‘n’ Tackle™
A Multi-Party Transactional Accounting System..
Our Block ‘n’ Tackle system provides true, and ultra secure, transactional accounting to enterprises, where demands are always high.
If your enterprise works in an environment where some contracts require more than dual-participation, including dealing with couples, or several business customers who need to mutually agree before transacting, dealings with regulators, or any other multi-party contractual situations, we can assist.
We don’t use third party Accounting providers, because we don’t need them, and neither do you! Why buy a setup which “integrates” one high-level system with another, especially if all packages are less secure? We provide a single, secure, integrated package enclosed in the Elastos Smart Web. The integration we offer is based on system-level open source, inter cooperative software tools, thus ensuring a huge merit-driven reservoir of worldwide talent to support our efforts. ITCSA build Enterprise DApps from the ground up.
Automated trading and settlements become possible, with no need to worry about transaction details, as all parties have access to all the data to which they are entitled (and no more), and, of course, the contracts are executed only if and when all preconditions for all parties are met.
This is possible due to the operation of BlockChains. Nevertheless, the bulk of transaction data (securely linked to BlockChain evidence) is stored finally on an Enterprise Database in the Cloud (in Sydney, for Australian Businesses, or London, for British Businesses).
The BlockChain provides a secure, public & immutable audit trail of essential (non-sensitive) data for each transaction (financial or otherwise)
However the Database transactions need to be internally audited, at the top-level, by taking the differences in database states between the end of yesterday with the end of today, as well as the end of each week and month with ends of previous week and month, and comparing these with the truly reliable evidence on the BlockChain.
Results are reported daily to the Board of Directors. Inconsistencies are targeted by ITCSA Board and Management. Reports are generated from the Database and BlockChain automatically. The recipients of reports are inside the Elastos system securely. We also undergo annual external Security and Financial Audits. Any inconsistency is considered to be a very urgent and serious matter. It is part of BlockChain operation that each participant globally is keeping every other participant honest, automatically. This means our Audit Trails are safe and secure. Our enterprise databases, however, require extra care and vigilance; hence the consistency checks.
Naturally an organisation should conduct its own regular internal audits to check correctness and appropriateness of transactions. ITCSA guarantees to look after the consistency and integrity of your data, however only you can distinguish an invalid enterprise transaction within your business.
The ITCSA Block ‘n’ Tackle™ relies on a strategy of mimicking a paper based Accounting System, where customers and suppliers are involved in transactions which are recorded on any of the 9 Fundamental Ledgers as balancing credit and debit entries. In multi-party Accounting the same principles apply except there is more than one payer and/or more than one payee. In a single network, a Contract Id is unique and can be referenced by all concerned parties equally, despite their own Business Processes remaining distinct.
The Business Logic in our software ensures the transactions conform to the associated contract’s terms, and the Accounting Standards (IFRS). It is comparatively straightforward to correctly update the Master Ledger (the Fundamental Ledgers) in a simple dual party system, however more is required to ensure a multi-party system functions correctly. We achieve this by coding atomistic Use Cases and “Views”, tailored to each of your and any Networked Partner Business’ Needs. The requisite data is gathered & presented and Business Logic is applied at each step.
In a networked environment, there needs to be a process “overseer” to guarantee the Business Logic is followed as the various participants enact their roles. We provide a Process Master for each Current Business Process, situated in your cloud installation, which follows and guides the process, enforcing rules in concert with the backend Postgres database(s).
The abovementioned atoms can be strung together in (meaningful) sequences to reach different goals, depending on the Business Process being followed. We keep as much of the Business Logic within the database and Cloud installation as possible, including the software unit doing the Business Process Following, the Process Master in the Cloud. It achieves this by referring to database tables where steps in Process Types are recorded, including the current position of each participant in a Process, and also by allowing users & machines to make (validated) decisions as necessary. This approach is safe due to the facts that: a) everything occurs within the Elastos Smart Web, b) the Processes are defined with all parties’ goals in sight, and, c) everyone’s interests are protected by sound Governance during coding.
Although our systems are based on you creating the Business Contracts and on the definition and instantiation of Business Processes that satisfy the terms of the contracts, ITCSA provides a full “turnkey” set of Process and Contract Types to your specifications. After the initial set of Contract Types and Business Process Types are coded, ITCSA continues to cater for your dynamic needs for new Database Views (and gui Screens), unless it is possible to create a new Business Process Type from existing Use Cases, Views and Screens. In the latter case the Business Process Design Interface can be used. Business Processes can automatically recognise when they are complete (as specified by ‘success’ criteria, at Process Definition), or they may be suspended or terminated at any time as necessary. In a Business-Networked System the same logic applies, except all parties’ involved in contracts between participants (“Members”) must have their own interests guaranteed and protected as much as their partners’. ITCSA takes on the role of broker or middle man to assist Members to cooperate in settling on Contract Terms, Conditions and Business Logic.
Not all Business Processes require a Contract. However the opposite is true – ie every Contract requires a Business Process to throw to. In fact everything that occurs on the DApp runs in a Business Process, except that Contracts are defined and (re-)created independently, before spawning a Business Process (from an existing Business Process Type) upon instantiation. The system thus requires the prior definition of the Business Process Type (ie after the definition of the Contract Type but before the instantiation of the Contract itself) that will be the basis for the running Process, which is designed to complete the Contract requirements (or possibly to do so repeatedly). ‘Success’ criteria (referring to a state of some data on the database) have to be established for each Business Process Type, as with Contract Types. A business will have some Business Process Types which have no related Contract Type, as they will represent a range of duties the business has, outside the requirements of any actual contracts. However our DApps do retain control for you over employees’ duties and the Employment Contract Job Descriptions associated with essential and performance-measurable activities in Business Processes. These “internal” Business Processes and Business Process Types are, similarly to the case with “external” Processes & Contracts, related to (Employment) Contracts and Contract Types
A Business Process is essentially a series (defined using your Business Process Design Interface) of ‘atomic’ Use Cases and Views coded in a prior stage by ITCSA based on your needs. The ‘atoms’ are sequenced by you, or by us under your direction, to be executed in order; but where decision-making and branching to “child” processes is possible, to an unlimited extent. Child processes must also be defined before the entire Business Process is considered ‘completely sequenced’. These atomic Use Case series, whether branched or not, should be designed with the intention of completing every necessary step (using existing “Views” – Forms, and Use Cases) from beginning to ‘success’. This requires that all terms of contracts, and every condition of more general Business Processes; every possible eventuality relevant to the process, and all actions needed, must be covered, validated &/or completed by each party involved. The definition of a Type is a separate activity from selecting the menu item generated, and Running an actual Business Process as a unique Process on the network.
Not all Business Processes achieve ‘success’, and termination is a part of Business Process Design. A Business Process spreads out like a “tree” with its root at the commencing Use Case or View. There may be several routes to ‘success’ endpoints, with multiple failure or ‘termination’ points possible along the way. It is not allowed to have “re-entrant” or “recursive” Processes, with the exception of repeating the current step. This means a stalled or failed Business Process may need to be terminated and a new Process commenced, in order to have any way of completing the Business Process involved. In that case, there may also be underlying problems with data values and validations as set in the current Process. We provide Tech Support 9am to 8pm Mon-Sat Sydney time.
We use a system of reserving a data field on every record in every database for the Business Channel Number pertaining to your own organisation. This ensures all your records and only your records are accessible by you and your staff. ITCSA employs a user/role system such that a single user may have many roles and a role may include many users. This forms the basis for restricting access to data and methods/menus as required by the organisation.
As a customer using a system similar to The General, you would be directing us as we code the initial set of Contract & Business Process Types, as an included part of the development services you pay for, on a transparent Trust Account basis. Unspent development funds are returned to you.
Alterations, additions etc would be an additional cost item after the initial system development is complete. You are welcome to develop your own Business Processes, using your Business Process Design Interface and existing “atoms” (use cases and views) with free Technical Assistance from ITCSA. However if you need us to sequence new Contract Types and Business Processes on the Business Process Design Interface, and for any coding required (such as for new Views or Use Cases) there will be an additional cost to you, based on a reasonable hourly rate. This means that if you require new or altered forms to collect different sets of data, there is a fee. If you prefer, we can entirely take over the development of further stages, including refining Business Processes, in consultation with you, at the same reasonable rate. We can assist to the extent of dedicating one or more Build Squads to each Member Site, continuously. See The General for typical prices.
As you, or IT employees you have, learn how to effectively compose Business Process and Contract Types, with our assistance, you will become more independent of us for your Business Process Design requirements, using your Business Process Design Interface.
Trade Mark Registered