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

[Erik Huelsmann <..hidden..>]

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 )


Which does fix the problem: the original transaction posts 299.03721
as does the payment transaction. No idea of the first hunk is required
or not, but I just went to comment out all roundings.

Before I found AA->post_transaction, I've been searching
IR->post_invoice() and IS->post_invoice() both of which have a
(largish) number of round_amount() calls as well. I suspect the same
issue may be hiding there.

What about this fix? Is it about to break lots of other stuff? Can I
commit it to the 1.3 branch?

Bye,


Erik.