FinanceFerret/archive/mirror transaction: Difference between revisions
m (Woozle moved page FinanceFerret/mirror transaction to FinanceFerret/rchive/mirror transaction without leaving a redirect: some planned functionality for v1, but I'm rewriting the data design instead) |
m (Woozle moved page FinanceFerret/rchive/mirror transaction to FinanceFerret/archive/mirror transaction without leaving a redirect: title typo) |
(No difference)
| |
Revision as of 20:23, 22 August 2019
If a transaction occurs between two accounts which are both being tracked (i.e. they exist as records in the "accounts" table), it should ultimately generate two transaction records. For example, transferring $100 from checking account A to savings account B:
| Local Account |
Remote Account |
Amount | |
|---|---|---|---|
| A | B | -$100 | (Looking at A's transactions) |
| B | A | +$100 | (Looking at B's transactions) |
In this example, each of these two records is the mirror transaction of the other.
Ideally, mirror transactions should be generated automatically, but in early versions of the software they had to be entered manually; as a result of this, it will be necessary to have a function which goes through any account on request and generates mirror transactions where they may be missing.
Since some of the mirror transactions may have already been entered manually but not properly recorded as mirror transactions (by filling in the ID_TrxMirror field), this function will need to check for possible matches and present them to a human for verification before cross-linking them (filling in the ID_TrxMirror field) – or else a human will need to check manually for existing mirror transactions before running this function.
It might seem that this was a dumb way to do things: why have two records for the same transaction? When showing transactions for a given account, why not show both (a) records in which the account was the source and (b) records in which the account was the target? The problem with this was in showing these records all together: the recordset resulting from a UNION of those two datasets could not be edited within a data-bound form. This may be something to consider redesigning when we are no longer using Microsoft Access for a user interface.