Get mailed with new posts
Architecture: Community Accounting 4 for Drupal 8
N.B. This is a work in progress
This document is for technicians aspiring to build their own mutual credit accounting ecosystem in Drupal, and for project managers who want to know what this package can do both out of the box, and when extended. It shows how multiple currencies, exchanges, transactions and wallets combined with workflows fit together into highly flexible, extensible structure which should be a pleasure to work with!
The intention of the software is to make it easy to assemble and customise a closed accounting system within the leading open source community web application framework. Resilient communities can design and implement their own accounting systems as they reduce their dependence on commercial credit money. Most innovations in accounting systems these days, especially in cryptocurrencies focuses on payments alone with little workflow, social networking integration or connection to the goods/services traded. This approach seeks to integrate accounting fully with community life.
This 'closed' accounting involves a single ledger, or transaction log which stores records of payments between wallets. Thus the sum of all wallet balances in a given currency is zero by definition. This 'mutual credit' accounting can be used for LETS and Timebanks as for community fiat and commodity currencies, as well as business barter systems
At the heart of the module are four entities, principally the ledger entry or payment record, called a 'transaction'. Transactions move between states via transitions along workflow paths. A configuration entity, currency contains mostly only cosmetic data, but can be extended to govern balance limits also.
A new field type is defined called 'worth' containing a currency code and integer. When attached to the transaction using FieldAPI, the worth field and thus the transaction can involve multiple currencies.
Because transactions should be treated somewhat differently to normal content, everything that happens to them is via 'transitions'. Each transition is a powerful plugin which appears as a link on the transaction and has its own display style, confirmation message, access controls, and redirect. Typically a transition will change the workflow state of the transaction, but transitions can contain form fields of their own. The 'edit' transition is therefore much more specific than simply 'editing' the entity using Drupal core.
If I get around to it, the transitions will happen not on a fresh page but optionally in a modal window, or in the same page using AJAX.
The transitions appear only to the users who can perform those actions. The transitions have their own access control system which uses another plugin to determine who someone is with regard to the transaction. So a transition might be possible only by the creator, or the payee, or the manager of the exchange, if the 'exchanges' module is installed.
Transaction types and states are configuration entities in themselves which makes it pretty easy to create new workflows in additional modules. When a transaction is created, its type determines the state it is created into. Each state is either counted or not counted towards to the balance. For example erased transactions would not be counted, but pending transactions might be.
Transactions entities are clustered together by serial number, all of them sharing a workflow state. Simple clusters would have only one transaction, but in cases such as a per-transaction tax, there would be two payments in one cluster. As the transaction is validated, a hook allows other modules to add 'children' to the transaction
Quantities are stored in the ledger always as integers, but the currency settings allows different displays. This is formatted in a simple string. for example "$0.99" would give you a standard dollar display where the stored integer represents a cent, and H0.59.59 would show an hours, minutes and seconds readout, where the stored integer represents one second.
Full views integration is provided such that you can build a balance sheet, a profit and loss report, or a statement without using code. This is accomplished with a transaction index table, which stores 2 copies of each transaction, one from each wallet's perspective. Views can filter or GROUP BY the index table to give a pleasing range of possibilities.
Wallets are a new feature in version 4. Every transaction is between two wallets rather than two users as in previous versions. Each wallet is controlled by one and only one entity, typically a user but can be any contentEntity. The wallet contains an access controller for users to view, to trade with or to edit the wallet name and access controls. Wallets can be displayed in many ways.
Simple forms for mass transactions, called one2many, many2one, one2few, few2one, are also provided.
That much is in the core module; the following modules are provided as extras.
Firstparty forms are highly configurable objects used for designing transaction creation forms. Firstparty means that the form assumes the current user is involved in the transaction, and allows presetting of fields and full control over the html of the form, and who can access it. It is envisaged that a form could be designed easily for every occasion. Once a transaction is created then it could be manipulated via aforementioned transitions.
The exchanges module, to be based on Organic groups, allows one site to run multiple exchanges, as in CES. It supports 'internal' intertrading, meaning transactions between different exchanges using different currencies, but all within the same site. (Funding is being sought to create external intertrading)
The signatures module extends the notion of workflow with a new type signature, which starts transactions in a new state, pending. Two new transitions are provided sign which can only be accessed by named signatories, and sign off. which allows (an administrator) to sign on behalf of anybody thus driving the transaction through to the finished state.
Balance Limits module adds new settings to the currency, to determine the minimum and maximum balance limits of accounts. Balance limits can be calculated by a choice of configurable plugins, and each plugin can be overridden by balances applied to individual wallets. The checking is done during the transaction validation phase can be skipped under certain circumstances.
In Drupal it is a straightforward operation to change the entity storage controller, so it is anticipated that Cyclos can be plugged in as a back end. The module includes other components to broaden the appeal...
Command parses short statements into transactions. The statements are configurable, and hooks for the sms_user module and twitter module are implemented.
Integration with the rules module is also anticipated.