Transactions

The transaction is the core part of LETS. It has a lot of properties and constraints.

• There will be one way and two way transactions. Most transactions would need to be proposed by one member and confirmed by the other. Members would need special permissions to give or take currency without confirmation
• Each transaction will include the last date it was changed, payer id, payee id, whether it was initiated by the payer or payee, whether or not it is complete, reason for its refusal, the currency, the quantity, the quality of transaction will be required from the payer, and comment saying what the payment was for. Transactions will be categorised, either by the user, or with keywords.
• transactions may be subject to taxation. Users would be informed on the confirmation page,
  or the taxation costs of the transaction and given an opportunty to stop.

Appointments

Some systems, such as timebanks, allow for regular appointments.

• Apointments are like transactions, but they have a moment at which they become transactions, in need of confirming by both parties
• there will be a mechanism for setting up regular appointments.
• Appointments will either be cancelled before the appointed time

Reputations
One of the problems of city-based LETS is the person who takes takes takes and then is never available to trade. Nobody quite knows who this person is, how they joined and when they leave, where did they go to. We hear stories of people who sign on to the LETS to trade, and when it
comes to transacting, suddenly they want half cash or even total cash - and in an expensive service such as Feng Shui this can amount to hundreds of sterling. The worst story of this kind is a masseuse demanding cash with threats that she would accuse her client of misbehaving if he did not pay up on the spot. To think of the LETS being used in this way is horrifying. We believe these abuses are rare - the usual complaints are of people who didn't bother showing up to appointments or whose work was sub-standard. The commonsense way of dealing with these situations is to ask for references. Just because it's on LETS it doesn't mean this is a nice person, unfortunately. In a
rural village people would know who you are, but in a city we don't. This is why we have spoken about the need for identity checks and for reputation systems.

• Each transaction will have a quality score, to be filled in by the payer. This will work on creation of the transaction, for payment-led transactions, or on the confirmation for invoice driven transactions.
• This score will affect other ratings and listings and rankings

Note. The "Specificatiion for a Universal Transaction Engine" suggests that a transaction can consist of a mix of currencies. Matthew wonders if that might be over complicating things.

Third-Party Processing

If a cheque or passbook is received by the LETS accountant, it implies that the two-way transaction has already taken place, ie someone has signed a cheque and the recipient has transmitted it to the
accountant for payment. In printed cheques this acceptance could be done by a second dated signature indicating acceptance and the same in a passbook system - both members countersign each others records. The dates shown on the chequebook are both entered to complete the
transaction and the automatically generated payment-date records the batch of work done on a particular date. The more promptly the accountant records trades the more finely tuned the system will be for members to see the progress of trading. We think there will always be a need for paper-based systems so we need to have the option of continuing an Accountant service as an over-ride version in a system which is basically set up for members to transact. Once it becomes the
norm for members to transact, anyone finding difficulty with this would be paired up with a techno-buddy to give them computer access and technical support.