On 21/02/12 14:39, Stefan Rijnhart wrote:
1. Write-off does not take currencies into account
The write-off calculation is not taking into account the bank
statement currency vs the company currency (vs invoice currency).
In my test database, I have a company currency of USD and a bank
statement currency of CAD. The transferred_amount field is in the bank
currency (CAD), but the invoice I'm matching against has the move
lines in the company currency (USD). Also, the invoice itself could be
in yet another currency e.g. GBP.
Currently, if I match a CAD 1000 payment against a USD 995 invoice,
the write-off is being calculated at 5 USD.
Can you replicate the issue? I'll look at fixing this.
Hi James,
yes, the design of the rewrite is underspecified with respect to
multi-currency as this had a lower priority for us. Let me know if you
run into any other troubles in that direction.
I've looked at the multi-currency side of things, and there is more
involved than meets the eye. Getting the write-off amount displayed on
the screen correctly is straightforward, but then getting all the
journals generated correctly is more complex. Also, since the write-off
is calculated in the bank statement currency, it may not write-off the
whole invoice value when converted back to company currency. To make
everything balance, the currency gain/loss needs to be handled. It can
be done in the account_banking module, but I think it needs a lot of
refactoring and will need even more testing.
Having looked at what's involved, I think there's a simpler approach
that we could take that will work require much less code. Instead of
calculating and generating the journals ourselves, we could create an
account.voucher record (since all the information needed for that has
already been collected). Then let the account.voucher handle all of the
multi-currency considerations, since it already handles single and
multi-currency scenarios. There have been extra development in the 6.1
account_voucher to handle things like currency revaluation.
The benefits of this approach are:
1. We're using the standard approach for generating the bank rec
journals, but using a simpler screen.
2. We don't have to rebuild a lot of logic that is already in the
standard module.
3. We reduce complexity of the account_banking module, reducing the
number of lines-of-code that we need to maintain.
What do you think?
James
--
Mailing list: https://launchpad.net/~banking-addons-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~banking-addons-team
More help : https://help.launchpad.net/ListHelp
