Re: Thoughts about data migration when master-mc lands on master

["R. Ransbottom" <..hidden..>]

On Sun, Nov 29, 2015 at 03:44:15PM +0100, Erik Huelsmann wrote:

> It's my hope that master-mc can land on master soon after we release 1.5.0

> 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!

What you say early in your post gives me pause:  "resolve differences ...
by revaluation", "inherent bugs", "replicates best", "slightly different".  
Those statements imply that a replication of what the transactions should 
have been may not be possible; that an audit trail is incomplete.

If the transactions are not reconstructable, it can be expensive in
a tax audit.  Not necessarily any penalty but more work digging into
paper to prove that GL accounts are close to correct.  

Your variant of (2) wins, whether it is an in place correction or a
massaging during migration.  If that cannot be verified as correct, then
rewinding and replaying the transactions in a bugless, cloned company is 
a strategy.  That would allow the construction of correcting entries 
against any closed mistakes.  If there is not the data to do that then 
working from any "paper" trail or head-in-sand look like  the last options. 

Thanks,
Rob

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel