This is the first post documenting my work on the mutual credit module version 3 for Drupal 7. There will be several valuable new features and my aim is to stoke demand and clarify in advance what it can do. I'm talking only about features already implemented...
The module will be deeply multi-currency aware. That means each currency will have many settings some of which weren't even possible in Drupal 6. It means that the software will be able to run many independent trading communities in one instance. It will be just as happy taking instructions from other web servers, via the Drupal services module, or outsourcing the accounting to another engine, by writing a new entity controller. But more of those things anon. Today is about Accounting Standards
The entity controller is responsible for reading, writing and validating (by test-writing) transactions to the database. The consequences of transaction errors are potentially more grave than say, node errors or category confusions. In formal accounting (designed before computing, though the same rules apply today) transactions should never be changed once they have been entered and added up. Rather, they should be cancelled out by 'corrective' transactions so that everything is transparent and the paper is not degraded by excessive rubbing out or tippex. Many use-cases for this module are not so formal, and they would regard such rigour as merely clutter. On the other hand, other accounting engines may insist on such rigour.
So, at the bottom of the attached screenshot, you can see the options provided by my, default, transaction entity controller. Can't delete means that there are no delete buttons and not even the administrator can delete. Mark deleted means the transaction state property will be 'DELETED'.
Similarly, deleting affects the meaning of update.
If a currency produces editable transactions, then another tab says which users can edit, including the option for user 1 not to be able
Finally, thanks to a suggestion by Art Brock, all transactions are now written when they are first validated. In my mysql, when we rollback a transaction, the auto-increment DOESN'T roll back, so this way we can have contigious transaction IDs! The transaction be logged in a new state, 'validating' and then when the user confirms, simply change its state.
So the idea is that you can run each currency with as much or as little formality as you care for. Or you can write your own transaction controller that can store transactions elsewhere or provide more options. Download the latest commit on the 7.x-3.x branch and have a play.
Comments