Comment 9 for bug 514305

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?