Thoughts about data migration when master-mc lands on master

Hi,

It's my hope that master-mc can land on master soon after we release 1.5.0 (that is, after the initial round of fixes has been done and fixing quiets down).

To that extent, I'm thinking about data migration from our current transaction registration system to the new one. So far, I have identified 2 strategies:

1. Take the balance in base currency, the currency rates and the transaction dates; from those, calculate the correct foreign currency amount for the transaction.

2. Take the balance's base and foreign currency amounts, use those to set up the new transaction records and resolve differences by running a revaluation.

While the second approach seems like the correct approach, since it replicates best what's in the current balance, this approach may not actually be feasible: there was a bug in - at least - 1.3 and 1.4 (which we recently fixed in 1.4) in the way payments are handled. The bug means that the base currency amount is correct and the foreign currency amount is wrong (for the payment line only). What's wrong is that the foreign currency and local currency amounts will be equal for the payment transaction, independent of the exchange rate. However, in the second approach, the revaluation will use the foreign currency amounts and use those to calculate the "correct" base currency amount.

It's easy to see how this approach fails to create a correct migrated balance.

The first approach however, is rather complex to code - with inherent bugs of its own - because there are multiple sources for fx transactions, each with their own special cases (AR, AP, receipts, payments, GL). Especially receipts and payments are complex due to the handling of FX gains and losses -- for which the *current* account setting may have changed, rendering it hard (if not impossible) to determine which account was/were the fx account(s).

Additionally, recalculating the amounts from the base amount and the rate could result in slightly different foreign currency amounts -- if only due to rounding.

If we don't want to go with approach (1), I also see a variant of (2) where we "fix" the data coming from the incorrect payments first and run a migration using that design after that.

Any help determining other options and approaches would be very much welcome!

Regards,

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.