Nowadays it is common that one bank account may service multiple currencies

[sraps (Alistek)]

It is common that single bank account service multiple currencies. For each of them (that are present in the account) would be separate statement issued, normally they are combined in one file. So it is needed that bank account setup is made for one bank account several times - one for each currency. At the moment logic is like one setting for each account, which is not right.

To differentiate these settings there should be name or description field add, otherwise they would appear the same.

In this case account settings object should be chosen by account number and journal's currency. Now it is being chosen only by account number.

There is additional check, that is being made for journal's currency, but comparison is not made to correct field. Now it is journal's code field, but should be Journal's currency.

So it is major logical problem.

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

That differs from over here. When I buy something in England, using GBP,
the bank coerces it to EUR, combined with an invoice for coercing :-/

That put aside, when I look at your preferred solution, I can't help
start shivering. You honestly want a setup for all possible currencies?
Please remind that you can't control what people *put* on your account,
so you would have to anticipate for everything. Now imagine having tens
of accounts.... (which international operating parties easily have).

I think this calls for a simple store, so to convert the function field
to a real currency field. Whatever consequences this has for accounting
is not the responsibility of account_banking. Agreed?

Then we only have to dig through all of account to flesh out the
consequences for the rest of OpenERP....

Op vrijdag 29-01-2010 om 13:52 uur [tijdzone +0000], schreef sraps (KN
dati):

> Public bug reported:
>
> It is common that single bank account service multiple currencies. For
> each of them (that are present in the account) would be separate
> statement issued, normally they are combined in one file. So it is
> needed that bank account setup is made for one bank account several
> times - one for each currency. At the moment logic is like one setting
> for each account, which is not right.
>
> To differentiate these settings there should be name or description
> field add, otherwise they would appear the same.
>
> In this case account settings object should be chosen by account number
> and journal's currency. Now it is being chosen only by account number.
>
> There is additional check, that is being made for journal's currency,
> but comparison is not made to correct field. Now it is journal's code
> field, but should be Journal's currency.
>
> So it is major logical problem.
>
> ** Affects: account-banking
> Importance: Undecided
> Status: New
>

[sraps (Alistek) (erpsraps)]

Well...
>>You honestly want a setup for all possible currencies?

Not exactly, it is normal, that company still uses one account with one currency stored inside. Personally I have several currencies in my personal account, this is only because I often shop online, and if somebody returns me a sum of money for not available goods, it is just stored as it is.

Nobody never ever makes the configuration for each possible currency, only those which are really used. Anyway it is common that invoice is being paid in the currency that it has been issued in. So if company issues currency in EUR, it is 99% chance, it will be paid in EUR. If company receives invoice in other currency, exchange is being done automatically on payment, so again no problem with that, because sum in statement would be in the currency that is being debited from your account - so you already have a setup and an account for that.

We have a customer (not for OpenERP services) that bills people for services directly. People tend not to be as precise as companies, and they have situations, when they occasionally receive money not in currency they expect. This happens mostly because somebody are in travel to some exotic country and pays his utility bill to homeland in the currency of the country they are at the moment. Still it happens not so often that you would expect to have 20 currency setup.

Also it is common, that for international trade people use big/strong currencies like EUR/USD/JPY etc. Usage of particular currency varies from one country to another.

Again not all possible currencies are being serviced by national banks, only those that the country has strong economic relations.

Moreover setup is not much more clumsy than that you would have with separate accounts. Difference is only in that you have to look for proper setup not only by account number, but account number and currency.

So if you would have for two currencies separate accounts, setup looks like:
34123412 EUR
78576587 USD

then we would make this:
34123412 EUR
34123412 USD

No difference at all, anyway you would have to make separate journal (of type cash) for each particular account and state the currency there, just as like as we would do.

This is simple as it seems, and it makes no overhead to accounting at all.

[sraps (Alistek) (erpsraps)]

We have made necessary changes to accommodate several currencies. But as latest version is unworkable, we made it on previous one.

As I said there is nothing hard to do, it took us ~1hou, to make necessary changes.

I would gladly provide diff on latest version if you could supply it workable... Could you send me your skype contact or something, so we could talk on some features, because it takes extra time when working asynchronously.

You can write me to an e-mail kasparsv [at] kndati.lv

Best regards,
Kaspars

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

Hi Kaspars,

Have you checked out r14? Most problems should be solved now. AFAICT
this is now stable. If you provide me the diff for your multi currency
adaptation, I'll be happy to merge it in.

CU,
--
Pieter J. Kersten
Website EduSense

Op woensdag 10-02-2010 om 14:34 uur [tijdzone +0000], schreef sraps (KN
dati):

> We have made necessary changes to accommodate several currencies. But as
> latest version is unworkable, we made it on previous one.
>
> As I said there is nothing hard to do, it took us ~1hou, to make
> necessary changes.
>
> I would gladly provide diff on latest version if you could supply it
> workable... Could you send me your skype contact or something, so we
> could talk on some features, because it takes extra time when working
> asynchronously.
>
> You can write me to an e-mail kasparsv [at] kndati.lv
>
> Best regards,
> Kaspars
>

[sraps (Alistek) (erpsraps)]

You have applied diff only to banktools.py with slight optimizations, what is ok. Still you have not made changes to bank_import.py, so the right settings can not be chosen.

[sraps (Alistek) (erpsraps)]

I am sorry, but as you made modifications - not used our patch as it was, you have missed the part which correctly finds setting for account with company's default currency.

So now there is again problem when journal does not state currency (remember this field is not required - if not set in all parts of accounting it is considered that it is company's default) and you import default currency statement, the settings object is not being found at all, so it is not possible import the statement at all.

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

Did you check latest version? I can't reproduce this. The default is the companies currency whatever the test case. Journal settings can override and so can imported transactions. When journal settings and transactions findings are not identical, a controlled exception is raised, causing the full import to be aborted with log.

[sraps (Alistek) (erpsraps)]

The problem lies in this code snippet...
#banktools.py @line 160:
----------------------------------------------------------
# Find matching journal for currency
    journal_obj = pool.get('account.journal')
    journal_ids = journal_obj.search(cursor, uid, [
        ('type', '=', 'cash'),
        ('currency', '=', currency or company.currency_id.code)
    ])
    if not journal_ids and currency == company.currency_id.code:
        journal_ids = journal_obj.search(cursor, uid, [
            ('type', '=', 'cash'), ('currency', '=', False)
        ])
    if journal_ids:
        criteria.append(('journal_id', 'in', journal_ids))
-----------------------------

So, in particular, we have a setup with two bank accounts, one of them has two journals defined (one for EUR, the other for default currency - LVL, which is set explicitly in journal), the other account, just one setting, with journal for LVL, which have not been set explicitly in journal.

We import statement for the second account which has only one setting - LVL, wich is default currency, and not explicitly set in journal.

Let's go through the steps of the code ---> / ('type', '=', 'cash'), ('currency', '=', currency or company.currency_id.code)/
This will find the journal for LVL, but the problem is that it would be the journal for the other (first one) account, remember the journal's explicit setting.
So the next IF condition will not even try to find other journals, those without explicitly set default currency....

As I have said, this is wrong algorithm, please take that we have provided. This is a regression.

Note: your algorithm will fail in many other cases too - cash journals is not used solely for banking, but for petty cash, and other accounting operations, so you can not assume that all the cash journals is those for bank accounts. So the first part of the code will trigger on them too.

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

Ok, the original snippet triggered exceptions in other areas, reason why I changed it. Regression is here a matter of perspective ;-)

I understand your concern with cash journals. We shouldn't search for it. I had mixed feelings from the start, but hey, when you say it works ;-)

I think we should configure specialized journals for bank accounts. These are of course of type 'cash', but used solely for a specific bank account. When setting up a chart of accounts and encoding your bank accounts in the original setup process, these kind of journals are created from the start. The defaults settings for account_banking maps journals this way too. I think we should extend this scheme with currency bound journals, perhaps even create them on the fly when new currencies enter the system from your bank account.

I can see two approaches for quick results:
1. Change the default settings for account_banking to have a one2many relation with journals. We can then focus on these journals and ignore all others. The algorithm would than be confined to the defaults.
2. We could extend account.journal to have one level of children and use this to model this behavior. We then won't have to bother about base mechanics, only when the totals in the 'master' journal has to be calculated. While doing we'll create the missing 'dynamic currency coercion' mechanism we were looking for. I'm only not sure if this should be contained in account_banking. Perhaps more applications are perceivable and a different module would be a better approach.

What do you think?

[sraps (Alistek) (erpsraps)]

Well, I am not up to changing or extending account.journal objects, in any way. This is because, if somebody would correct some bug or adds functionality in methods... This will render us into big trouble.

I see functionality of account_bankning starting and stopping right with account.journal, bankning should interact with accounting module, but nor replace it. If we make step into accounting, then we will have to make another step, and another step...

I see no big problems with the way we are now finding the journals. Only thing have to be that if we search on journals that serve default currency, they should be searched for, by both - explicitly set currency and False...
If we search for journals that serve other currencies we have to search only those with explicitly set currencies. It is simple as it looks like.

I see, that we are now close to operational module, we just need to make it workable.

The next step would be, making it understand other specific transaction types, like direct debit etc. This would be for nearest future. For bigger plans, we can consider building interface for directly connecting banking systems, for sending and receiving transaction requests. This would be interesting for companies that will want to work synchronously with their customers, like distributors etc.

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

Agreed, account should be left alone. Problem is that multi currency bank accounts are just that: bank accounts. So they are related to banking and fall within the problem area of account_banking. It would not be a trivial task, but based on problem area's, we would be on the safe side.

I can't opt for the simple search for cash journals. There are way too many to be found in larger installations and thus way too many errors to be made once the wrong one was found. If we opt out on extending account.journal, we should go for extending accoung_banking_default_settings. When we use the 'master' journal as a template to find others and create them when not found, we will have an automated import once again, this time with the right currencies.

For stabilizing the current framework there is still some work to be done.
1. Fix this issue
2. Fix the dependency issue
3. Add the canceled direct debit matching logic
4. Make coercing of currencies optional (yes, you and I don't use it, but others probably will)
5. Discuss and optionally fix the handling of bank/branch codes in BBAN's (the bank codes are now used as nationalized BIC search keys)

For further extending the framework, I can see four, maybe five domains for the short term:
1. Include the missing link for account_banking: the batch processing information banks give as feed back. The meta info so to speak. This relates to your remark considering the error reports per transaction.
2. Flesh out the generator parts from account_banking_nl_clieop and place it into account_banking to ease the development of generators
3. Create an extensible interface for matching algorithms.
4. Handle the specialties banks give as 'transaction' like costs, etc. (Automated generation of invoices and the like).
5. Create SEPA parsers/generators (limited usage, I know. Only a third of the word will use it.)

I think calling the digital interface for the banks itself 'bigger plans' is an understatement. There are a lot of hurdles to take before we get there, if we get there. I mean, just take a look at 'aqbank' which itself AFAIK only works flawlessly in Germany...

I'll create this steps as blueprints...

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

Converted to blueprint