Architecture: Community Accounting 5 for Drupal 8/9

Intent/Audience

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!

Introduction

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

Drupal 8/9

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.

The transitions appear only to the users who can perform those actions. The transitions have their own access control which uses a 'transactionRelative' plugin to determine the user's relationship to the transaction. So a transition might be possible only by the creator, or the payee, or the admin.

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. Via the state 'counted' property, transactions are either counted or not counted towards the wallet 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.

Wallet entities must be 'held' by a content entity and therefore have an owner user. The wallet contains an access controller for users to view, to trade with or to edit the wallet name and access controls. Several theme functions (and extrafields) are available to display wallets visually.

There is also a currency stats page with various visualisations of trading activity.

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

Simple forms for mass transactions, called one2many, many2one, one2few, few2one, are also provided.