| Thread Previous • Date Previous • Date Next • Thread Next |
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
| Thread Previous • Date Previous • Date Next • Thread Next |
