Currency field is not being stored

[sraps (Alistek)]

Please note that "account.bank.statement" defines field "currency" which is of type "function", so it is obvious, that value, you assign to it, would not be stored. So no matter what, it will be computed by function, but not being taken from statement.

[Pieter J. Kersten (EduSense BV) (pieterj)]

Granted. Using typical bank accounts, the assignment is redundant, because most bank accounts operate in single currency mode. However it becomes very relevant when you use bank accounts with a default currency different from your business currency.

So, what is your idea on this?

[sraps (Alistek) (erpsraps)]

Please see my recent bug post on another problem #514305. All the big banks (SEB and Swedbank) here do not provide single currency accounts by default anymore. In some banks it is not possible to get single currency accounts at all, even if you specially ask them to.

[Pieter J. Kersten (EduSense BV) (pieterj)]

@sraps,

I need some assistance with this, as I can't use a multi currency bank account over here.

How does this work? Should one be able to select a currency before paying? Are the currencies not coerced when importing?

If we change the currency field from function to a real string, then I'm not sure if OpenERP is ready for this. How will this affect other parts? Can 'account' cope with such behavior? Is there still a way to calculate a balance?

As you've created a parser and generator before which supports this, how did you do it?

TIA

[sraps (Alistek) (erpsraps)]

Well, this goes like this. Account number is the same for any currency that are being stored inside. Still if you go to see summary it may differ - for one bank you may find approximate balance calculated in your local currency. For example in LV local currency is LVL (Ls), so if I have 100 EUR and 100 LVL on my account, I may see approximate balance = 170,... LVL. For other bank it would look like two lines by default, even at the front of your online banking system -
* 100LVL
* 100EUR

Nevertheless if you request full detail for your transactions over period you would receive two statements. One for each currecy, with it own balance... This will be for statement exported to a file - one file with two logical statements inside.

You may want to take a look:
http://www.bankasoc.lv/lka/komitejas/FiDAViSTa101_apraksts.pdf
http://www.bankasoc.lv/fidavista/fidavista0101.xsd

PDF file is in Latvian, but XSD file shows, that there is no limitation on how much statement tags may be in the file.

I do not see reason to make currency field as a string, but rather a reference to an object of currency, but not a functional field.

I understand, that accounting is ready for this - normally it would be handled as separate general account for account - currency pair. So if you have an account Nr. 345543 with two currencies LVL & EUR, you would define two general accounts, where for one account primary currency would be LVL, for another - EUR.

Ok, accountant, may want to keep records in both currencies at a time, I assume you can define two currencies for one general account in OpenERP.

We make several separate statements for each account, each currency. And account settings should be chosen not only by account number alone, but account number and currency.

[Pieter J. Kersten (EduSense BV) (pieterj)]

So, to put it another way:
1. Payments are done in a limited number of foreign currencies per bank account
2. The set of allowed currencies is chosen on a per bank basis.
3. There is no coercing between currencies until you explicitly say so (to the bank)
4. The value of the total amount expressed in a single currency is a guess based on the actual exchange rates from the corresponding bank.
5. The costs of coercing are unseen and unknown by OpenERP and are only fed back using transaction imports or bank message files.

I´m afraid we're raising the lid of a Pandora's box here. We should probably add the legal requirement for reporting in relation to currencies as well, which probably differs from nation to nation. Or do they require multiple currency accountancy reports over there as well?

Some ideas:
2. Can be accomplished by adding a 1:n relation with currency to a bank
1. Can be accomplished by adding a 1:n relation with currency to a bank account, which must be a subset of 2
3. Could be implemented as supplier invoices
5. Could be implemented as supplier invoices

Leaves 4. Some requirements I foresee:
A. All compute functions on account should be able to handle the multiple currency scenario
B. Reports should be able to deliver multiple currencies, depending on the moves found
C. Legal reports should be able to coerce the results to a chosen currency, based on the actual exchange rate.

Are you sure OpenERP covers all this? I didn't notice any signals it does. But then again, I didn't look for it very thorough.

[Pieter J. Kersten (EduSense BV) (pieterj)]

Perhaps we should mark this bug as 'invalid' and move the discussion to https://bugs.launchpad.net/account-banking/+bug/514305
The problem is more or less the same...

[sraps (Alistek) (erpsraps)]

Not it is not actually the same problem. This specific bug is related to that currency field is not storable in current implementation. Here field type should be changed... No big deal :)

[Pieter J. Kersten (EduSense BV) (pieterj)]

Correction - the currency for bank statement would become meaningless, while there would be an extra field currency in bank_account_statement_line. The reconciliation code would have to change, as it coerces the received (prev: bank statement, now: bank_statement_line) currency to the companies default.

Indeed minor, but at the same time it flags the multiple currency scenario as 'big deal'. The coercion part must be rewritten and transformed to case 4. Not something to be done overnight.

[Pieter J. Kersten (EduSense BV) (pieterj)]

To add to this: please view the code in account for account_bank_statement - there is a lot of calculation going on based on the amounts in the account_bank_statement_line's it contains. All of this has to be rewritten, including the triggers on the state transitions. So this *is* a major change and falls together with https://bugs.launchpad.net/account-banking/+bug/514305 .

As I said before - I'm afraid this opens a Pandora's box. Where will it end? I can't tell from where I'm standing. At least we can now confirm that OpenERP in its current shape is definitely not up to this task.

If this is critical for usage in modern banking, how did you use OpenERP up until now?

[sraps (Alistek) (erpsraps)]

Well I will come back to this tomorrow, I will dig a bit deeper into the problem.

We just start using OpenERP for accounting fo ourselves. TinyERP 4.2 was not up to this task... We want to make OpenERP 5.ready for financial acounting in LV.

[sraps (Alistek) (erpsraps)]

This bug is not to be considered of high importance anymore, as the only problem with this functional field is that framework module tries to place data to the field, which is not needed.

We should remove write opportunity to this field, and the problem is solved. Writing data to functional field is useless...

The currency field is being taken from following places (with fallback):
1. tries to get currency from Journal;
2. if there is no currency set in Journal, then it takes default currency of company;

[Pieter J. Kersten (EduSense BV) (pieterj)]

I do not agree. If your import allows multiple currencies to pop up and account-banking is not prepared or able to handle this, we've got problems. As you stated: the calculation of the statement sums are coerced to one of the default currencies, either from the journal or the company. However, this calculation is done only once. There is no such thing as 'dynamic' currency coercion in OpenERP until now. As this creates all kinds of problems both in real life as in OpenERP, this can't be allowed to exist. IMHO we have two options:

1. Allow multiple bank account/currency combination's to co-exist in OpenERP
This would in effect split up a single bank account into multiple sub accounts, each bound to a single currency.
This still needs some mindwork though. Ideas are welcome.

2. Coerce all foreign currencies on your bank account as well.
I expect this to work as is, but it robs you from the ability to speculate with exchange rates.

What's your vote?

[sraps (Alistek) (erpsraps)]

Well, I will try to explain:
1) OpenERP is aware of any currency - bank statement is not only bank statement by default. The same objects are being used for petty cash accounting as well.

2) In this system, there is no option to have one multi-currency bank account. There is one bank account (read - one account number) which do not care for any currency at all. Currency mangling is being dealt by Journals. So you will have one separate Journal for each bank account each currency. This is where the statement takes this Currency field which is of type "function". So absolutely no problems with it.

3) Multi-currency bank account would always have several separate statements, one for each particular currency. Yes online banking system may show on front-page the sum of all bank account balances, expressed in local currency. But this is only for users reference. Bank absolutely does not care in which currency you will want your deposit, until you express your will to exchange your particular cuirrency to specific other currency. So you will never ever have one physical statement for several currencies - this is not logically possible. Still there can be several statements in one single file.

4) Should allow several import settings for one account, but with several separate journals. As I have been writing in 1.part, Journals hold reference to the specific currency. So you must search for specific settings, by searching by account number and currency from journal.

5) Do not care about accounting in OpenERP, it has nothing to do with multi-currency bank accounts. It is in general ready for handling several currencies.

6) Do not change anything in bank statement object, just do not try to alter the currency field - it is useless... This is what should be changed.

[Pieter J. Kersten (EduSense BV) (pieterj)]

Ad 1) Generally speaking: yes, but there are limitations, as coercion is required.

Ad 2) This is exactly what should be altered in scenario 1 from comment #12.

Ad 3) I don't understand. A bank statement is nothing but a message envelope for transactions done in a certain time period, possibly even from a number of accounts sharing the same holder. When you import these in digital form, you can't prevent multiple currencies to appear in a single bank statement, unless the import scheme uses a 1:1 mapping between bank statement and bank transaction, which narrows the reporting window to the time frame of a single transaction, as MT940 does. So, what are you trying to tell?

Ad 4) Possibly. An alternate approach would be the split up of bank accounts into multiple currency accounts. Using the defaults as modeled now, you should be able to map journals to currency accounts. No need for searching then. These are both just implementation choices.

Ad 5) I do not agree. OpenERP is fit for multiple currencies in a one time coercion scenario, but not for the parallel multiple currency aka non-coercion scenario. This kind of dynamic / external coercion would take a major system overhaul. Ignoring this would create all sorts of real life problems. For starters: Suppose you imported a transaction done in EUR and let OpenERP convert it to LVT using the current exchange rate. In reality nothing was coerced, you only let OpenERP suppose you did. When you later actually convert the two currencies, using a different exchange rate (the current rate on that date/time), where do you leave the differences?

Ad 6) This is only acceptable when coercion takes place based on the currency of the transaction. Right now, that is not the case. It suspects all transactions to be in a single predefined currency, but doesn't check. This is a major accountancy leak.

[sraps (Alistek) (erpsraps)]

Ok...

I think that we should not bother for OpenERP and it's accountancy problems, moreover, we are not able to address them all. Multiple currency accounting is feature (I am not sure that I understand all the consequences) that can differ from nation to nation, so we will not be able to create solution, that will suite any nation.

I assume that any external currency in Latvia should be rendered to LVL at the exchange rate of the day it has been received. Still you can keep your account in secondary currency. OpenERP has such feature in account.account object, so I assume we should not bother about it.

There are accountants that must crush their heads on how it should be handled properly. If I will have something workable, I will have mine pressed against the wall, so he will tell me, what should be changed.

Anyway this bug was not about, how to handle multiple currency statements, but rather, about not storing currency of statement, as it could not be stored - it is functional field.

Assigning the currency to this field should not be done - that is all. Let's stay with it.

Please let's not dig too deep in to the future, let's solve problems as they arise. If I would have working framework, I am sure we will test this feature in a week..., and report back. As this is almost the last thing that holds me back from setting accounting up.

And I need to do it for January :), so I need it yesterday...

[Pieter J. Kersten (EduSense BV) (pieterj)]

If this is all that's stopping you from using this framework: by all means, just ignore it. As long as there is no fnct_inv argument to the functional field definition (there isn't), nothing happens. That won't change the scope of this bug though.

[sraps (Alistek) (erpsraps)]

Just remove line #347.

[Pieter J. Kersten (EduSense BV) (pieterj)]

I've changed the currency in bank_statement_line to a link to res_currency. Now the assignment makes sense. Remains the rest...