Generic:
    I can see a lot of technical improvements for v6. However, there were
    more changes than just the technical ones. For starters, v6 introduced
    the voucher layer between account and account_payment. I'm missing
    this in your proposal. Is this code used in production? If so,
    what are the experiences? How does it coexist/cooperate with the
    payment/voucher system?

    I can see you tried to stay as close to the v5 version as possible.
    However, I'm second guessing some of the changes for v5, due to the
    semantic changes in v6. One is the move of the period_id on
    account.bank.statement to account.bank.statement.line. Thanks to
    account_voucher, it creates more trouble than its worth it. I'm planning
    to change the statement generation code to fold around the current
    limitations of v6. This would simplify ABF's dependancies greatly.

Many changes seem to me not v6 specific. I will backport these to v5. See my
remarks below.

account_banking/account_banking.py: @-890,+878:
    I will backport this modified to v5. Testing on iterator capabilities is
    more extendable IMO than testing on simple types.
    
account_banking/account_banking.py: @-911,+901 -922,911:
    Oops, left some lingering code. Thanks for noting.
    Backporting to v5, excluding the style change.

account_banking/account_banking.py: @-1188,+1177:
    Ok, backporting to v5.

account_banking/account_banking.py: @-1197,+1186:
    You managed to come up with yet another source. Nice.
    I'll add it to v5.

account_banking/account_banking.py: @-1218,+1210 -1239,+1231:
    Not sure if this is an improvement. I'll leave it for now.
    Won't take the style change.

account_banking/sepa/iban.py:
    This change is not conform specs. Any sources I can check for this?
    Will leave it untill more info arrives.

account_banking/sepa/online.py/BBAN_is_IBAN:
    See your point. Using slightly improved version for v5.
    
account_banking/wizard/bank_import/@@ -544,+545:
    This is unneeded. You don't use it anywhere. Won't take it.

account_banking/wizard/bank_import/@@ -567,+568, -730,+730 and -743,+743:
    These are just style changes. Wont take these.

account_banking/wizard/bank_import/@@ -753,+753:
    See your point. Your solution is however not always correct.
    Backporting improved version to v5.

account_banking/wizard/bank_import/@@ -795,+798:
    Can't see any value in this change. Just make sure that
        isinstance(transaction.remote_account, (str, unicode)) is True
    which must be done in the import parsers.

account_banking/wizard/bank_import/@@ -922,+918:
    Ok, see your point. Backporting to v5

account_banking/wizard/banktools/get_or_create_partner:
    Ok, backporting the unique construct to v5.
    Having some difficulties with the defensive field resolving code.
    Is this really needed? Never faced any problems with it.

account_banking/wizard/banktools/create_bank_account:
    What is the purpose of these changes?
    I can't see a semantic value for a catch-all 'UNKNOWN' bank.
    Problem is, when the bank gets known, chances are it won't be
    the same as "the other" accounts with UNKNOWN tied to it.
    Better leave it.