Complementary currencies for Drupal

This module is built around a local currency model called LETS devised by Michael Linton in the early 80s. Hundreds if not thousands of communities are trading using this model as a basis, though many have changed the rules.

THE RULES OF LETS:

* LETS is basically an IOU network, where the total balance in the closed system always adds up to zero.
* Only members of the system can hold money, and the money only exists within the system.
* Currency is issued as it is spent, and neutralised as it is earned.
* The average account balance will always be zero, so it is no shame to maintain a balance below zero. Rather, what should be avoided for the health of the system, is for members' balances not to stray too far from zero.
* It is considered healthy therefore to put a minimum and maxaimum balance limit on each account. LETS currencies are NOT a store of value, but a medium of exchange.
* Most LETS systems also provide a directory of offers and wants, to facilitate trade. There is often a committee member who's job is to facilitate trade. As with any form of money, the community benefits ultimately by the total transaction volume, not money created.
* The value of one unit of currency is arbitrary, and can be decided by the community. It is usually linked either to time, or to the national currency. However unlimately it is between the transactees how much is exchanged.

VARIATIONS ON THE RULES OF LETS AND SUPPORT FOR THEM IN THIS MODULE

Multiple currencies.
More recent thinking, notably on the part of Michael Linton, is leading towards the use of almost ad hoc currencies, where every might declare a currency as part of its identity. However this thinking is far beyond what most people are ready for, who believe that money is a concrete entity controlled by the government. Version 2.0 of this module will support multiple currencies on the same system. Not everyone will be obliged to trade in every currency, but there will be a kind of signup process.
- Some currencies will be exchangable for other currencies on the system. They will be valued against each other using an internal factor which will be called, for the sake of argument, minutes. Each currency will remain a closed system. To track money going in and out of the system there only needs to be a balancing account for each currency. However it should be considered that money in the balancing account is effectively 'out of the system'. If the balancing account, like any other account ,had a large credit or deficit it would affect the amount of credit in circulation in the rest of the system.
- Trading with neighbouring systems. The balancing account could also be used to trade with neighbouring systems as well as with neighbouring currencies on the same system. Again, there need to be rules about that account getting too far from zero. This facility however should enable people to migrate between systems and take their balances with them. As long as the systems recognises each other and a nominal exchange rate is agreed.

Gift Currencies
Some of the local currencies are not for trading at all. They are issued, rather, as recognition for work done or contributions. They take their value not from the fact they can be spent, but from the fact that the community values the people who hold them. They can be thought of as brownie points or karma points.
Full support for these gift currencies will come with multiple currencies. They will work not by adding up the value of each transaction, but by adding up the transactions themselves, each one having a value of zero. There will be rules about who can issue, or spend, these currencies, and negative balances won't be recorded, or at least displayed.
For now this can be done by creating a contentType with a user reference cck field. The user-reference module adds a section to the user profile called, awkwardly, related content which shows all the nodes which reference the user. I prefer to remove this section and use views instead.,

No limits on the system account spending.
One system in the UK has allowed it's system account unlimited spending and it now has a very large negative balance. There are concerns here about deflation and a 'run on the bank' is always possible. I watch these situations with interest and concern, but for now it works. This module allows any positive or negative limit which can be changed at any time. Transactions are disallowed if the resulting balance would be outside the account limits.

Leakage
Most systems require contributions from their members to cover administration costs and to allow the community to make contributions as a group. These contributions can be made through doing tasks in exchange for gifts, paying some local money into the central account, or through so-called harder currencies, which local money is not planning to replace any time soon. Support is planned for various leakage mechanisms, including:
- leakage on spending and earning
- periodical (e.g. monthly) or per transaction leakage
- fixed rate or variable leakage
- demurage
- system wide (taxation) or personal (tithing) leakage
None of these are yet supported.

Buying in.
Systems may wish to issue currency to their new members, either as a starting present, to encourage spending, or because members have paid some kind of joining fee. There are two ways of doing this. The proper way is to pay them from the system account, Hence from the community. The other way is to pay them 20 credits from account 0, which isn't really an account at all.This would mean each member would start with, and have an average balance of 20 credits, which may as well be zero, except it is psychologically different. The only difference between 20 and 0 would be what balance was expected when people left the system.

People leaving the system with negative balance
If accounts become inactive with a negative balance, it is ultimately and obviously the rest of the community that covers the cost. The system should have contingency plans to get accounts back to zero, probably from a central fund. In practice however, this rarely happens!

Time banks
This is a different currency model designed by Edward Cahn specifically for inner city regeneration projects - but the context doesn't matter here. I believe this module will support the timebank model with small modifications, but I haven't had occasion to model those transactions.

IMPORTING

There does not seem to be a proper node_import tool for Drupal 6 at the time of writing, though the drupal 5 tool was excellent, allowing direct import from csv. New node data is spread accross three tables, so node import operations can be tricky. It might be best to do a carried forward transaction from your committee or admin account. Importing offers and wants is just as hard and time consuming if there are several per user. Probably the users themselves will be happy to do rewrite these. Importing users should be easier.

Both transactions and offers & wants modules were intended to be used in tandem with the autocategorise module. That's up to you.

OPTIONS

Currently there are not many overt options for you to configure, as decisions are made through pruning the architecture, and theming.
However it is reccommended to put a maximum and minimum balance for the default currency. Also if transaction ratings are required, simply write the names of the grades of transaction in admin/settings/marketplace/ratings. These will be stored with their numerical equivalents, with 0, 1, 2 etc, and can be used later in the statistics module (forthcoming) to grade the users themselves on the basis of the average ratings of their sales.
You can allow certain roles permissions over certain transaction vectors, so you might have a simple system where every transaction is like a gift, or a more regulated system where every transaction needs confirmation. Or you can have both, where payments for work need confirmation but gifts are also possible. You can also change the language for all these terms to suit the ethic or mood of your community.

ARCHITECTURE

Offers & wants, and transactions are two unconnected modules which do not communicate or depend on one another in any way. In a shop system you would expect items to have prices and a transaction would link a user to the item using a price. This is not a shop, this is a transaction engine. Each transaction has it's own field which describes what the transaction was about, and each transaction has it's own price decided by the participants. All transactions are extended nodes with the data stored in the cc_transactions table. The system calculates member balances by adding up all their transactions in that currency, ever. Therefore accounts which have traded even once cannot be removed from the system unless all those transactions are altered to be from some other account called 'expired member'.
Since balances are used regularly, and potentially processor intensive, they are stored in a table called cc_balance_cache. This table is exposed to views and can be added to tables.

The cc_custom module is there to enable you to use all menu_alter, profile_alter, form_alter and theming funcntions.
* The module comes with several display functions, some based on views. To use them all at the same time would be excessive. You can use hook_menu_alter to retitle or remove the menu items, or if you are more advanced create new functions to display different combinations.
* Many of the provided functions concern data relevant to individual users, and you may wish to extend the user profile with them the hook_profile_alter modifies the main page of the user profile so you can put a users offers on it, or balances etc.
* The module provides two forms, the pre_transaction form and the transaction_node_form, the former is never processed, it just passes data into the latter which then acts as a confirmation form, or an edit form if permissions allow. Note that the pre_transaction form, (also available as a block to be shown on other users' pages) uses different data structure, which is translated for the node/add/transaction page. The pre_transaction_form needs to know who the user is, who they are transacting with, which way the money is going, and whether the other person needs to confirm it. At the second stage this information becomes to and from ids, and starter and completer ids, with a flag as to whether or not the transaction is completed ($node->status is reused for this.)
The transaction module provides four main permissions, one for each transaction vector. Invoice and Pay transactions will have the status pending until the other person completes them, while give and take transactions happen immediately.
* Finally there are copies of all the modules' theming functions there for your convenience and tweaking. Replace the 'theme_' in the function names with 'your_theme_name_' and run drupal_menu_rebuild_registry();

The node custom module also contains code which has been written for previous installations, but may be hacky and meeting niche requirements. IN particular there is code which allows members to log in with their uid, and puts a user's balance after their name whenever user_load is called.

Don't forget NOT to overwrite the custom module files when you upgrade.