Transaction Data Structures

We keep our money transactions in the Accounts table. We show the history of transactions on the user/money tab. We want to be able to show some detail for each Account transaction. So, we need to have data structures that link the Account to the detail.

This page will describe the data structures for tracking transactions.

We already have this detail for some transaction types:

• If the transaction is a credit card charge, then we have a link to the cc_transaction in the account_id field of the cc_transaction. We also keep a link in accounts.transaction_id
• If the transaction is a transfer between user accounts, we have a link to the other_id, plus other info
• If the transaction is a withdrawal_instruction, we keep a link to the Account in the withdrawal_instructions.account_id field

We used to have an invoice data structure. When we wanted the user to pay for a service, or to pay another account, we could create an invoice and put the invoice_id in the accounts table. We are not using that now. So, we need to figure out how to keep some details for the current set of transactions:

• A provider receives payment. In this case, the provider is being paid for a statement. So, we need to put a link on one side or the other, from statement to account.

• A buyer makes a deposit for a payment_commitment. I am not sure what to do in this case, and I am not sure it is a clear case. This is a deposit for a job_agreement, for a particular week. Maybe we need a specific data structured for that, or maybe we can just add that information (it's a deposit, for job_agreement X, for week Y) to the Account object. Often, a buyer will pay for multiple commitments, and the amount won't match any single job agreement, and they may pay in advance for job agreements we don't know about. So, I think the easiest thing to do is to NOT make this link, and just leave the system the way it is, with a generic deposit record. So, we will do nothing with this.

• A buyer makes a payment to Assembla for statements. This IS a clear case. When we charge the buyer, we should leave a record of what the buyer was charged for. The buyer should be able to see the detailed statements. The easiest way to do this is to add a field to the statements for "buyer_account_id". If it is not nil, this will link to the transaction where we charged the buyer.

The only time this will not work is if the buyer can only make a partial payment when we make the first charge. Then there will be more than one buyer_account record for a statement. We can worry about this later.