Re: Multicurrency issue, concerns, and proposed longer-term direction.

[Erik Huelsmann <..hidden..>]

On Sat, Dec 31, 2011 at 11:33 AM, Erik Huelsmann <..hidden..> wrote:
> On Fri, Dec 30, 2011 at 11:12 PM, Erik Huelsmann <..hidden..> wrote:
>> On Fri, Dec 30, 2011 at 3:10 PM, Erik Huelsmann <..hidden..> wrote:
>>> Hi Chris,
>>>
>>>> We have been having a slight multicurrency issue with payments that we
>>>> do not believe can be adequately resolved inside a stable branch.
>>>> Fortunately this issue is not severe and it may be able to be possible
>>>> to create a periodic job to fix the problem.
>>>
>>>> The issue is that the way multicurrency calculations are performed in
>>>> LedgerSMB 1.3, there are slight roundoff errors that occur between
>>>> posting and payment for AR/AP transactions.  As far as I can tell
>>>> these occur when the exchange rate changes.
>>>
>>> Exactly. I have a case of those right here (best viewed in a fixed-width font):
>>>
>>>  entry_id | accno |         description          |   amount   |  sell
>>> ----------+-------+------------------------------+------------+--------
>>>     1073 | 5011  | Hosting Expenses.            |     -189.3 | 1.5797
>>>     1074 | 5011  | Hosting Expenses.            |    -109.74 | 0
>>>     1075 | 2100  | Accounts Payable             |     299.04 | 1
>>>
>>> All the other times I researched this was from the local currency
>>> perspective. I was also looking if the documents were balanced, etc.
>>>
>>> Today, I looked at this set the other way around: I *know* the FX
>>> amount posted is 189,30 at a rate of 1,5797. Which is not the 299.04
>>> being posted to the ledger, but 299.03721.
>>
>> Well, I've been looking at this issue all night and I've now been able
>> to create this patch:
>>
>>
>> Index: LedgerSMB/AA.pm
>> ===================================================================
>> --- LedgerSMB/AA.pm     (revision 4245)
>> +++ LedgerSMB/AA.pm     (working copy)
>> @@ -188,7 +188,7 @@
>>
>>             # multiply by exchangerate
>>             $amount = $amount{fxamount}{$i} * $form->{exchangerate};
>> -            $amount{amount}{$i} = $form->round_amount( $amount - $diff, 2 );
>> +            $amount{amount}{$i} = $amount; # $form->round_amount(
>> $amount - $diff, 2 );
>>             $diff = $amount{amount}{$i} - ( $amount - $diff );
>>
>>             ( $null, $project_id ) = split /--/, $form->{"projectnumber_$i"};
>> @@ -267,9 +267,9 @@
>>     }
>>
>>     $fxinvamount += $fxtax unless $form->{taxincluded};
>> -    $fxinvamount = $form->round_amount( $fxinvamount, 2 );
>> -    $invamount   = $form->round_amount( $invamount,   2 );
>> -    $paid        = $form->round_amount( $paid,        2 );
>> +#    $fxinvamount = $form->round_amount( $fxinvamount, 2 );
>> +#    $invamount   = $form->round_amount( $invamount,   2 );
>> +#    $paid        = $form->round_amount( $paid,        2 );
>>
>>     $paid =
>>       ( $fxinvamount == $paid )
>>
>>
>> What about this fix? Is it about to break lots of other stuff? Can I
>> commit it to the 1.3 branch?
>
> More testing today shows that the full patch is required to get the
> desired effect.
>
> I guess that for my use-case, this is the only solution, apart from
> implementing round-off on the pay-off side of things.

r4249. We can always revert if there turn out to be any undesirable
side-effects.


Bye,

Erik.