## Description of the issue/feature this PR addresses:

In a scenario of ISR-B. The ISR Subscription number is not
owned by the invoice emitter but owned by a bank and shared
with other invoice mitters.
The invoice emitter is a client of that bank and has a customer
identification number provided by the bank.
This ID number is usually 6 characters long but
may vary. It is integrated as part of the reference.
Thus with 6 char for the ID, the ref still has 20 chars.

e.g. 150001123456789012345678901
150001 is the customer ID



![2019-09-02-143422_883x558_scrot](https://user-images.githubusercontent.com/4158438/64115002-d68b1500-cd8e-11e9-9018-5efc3fcfdb60.png)
(source https://www.raiffeisen.ch/rch/fr/clients-entreprises/trafic-paiements-et-liquidites/debiteurs/bulletin-de-versement-orange.html )

Here is the translation from FR to EN:
1. ISR Customer ID number | The number identify you as the invoice emitter and must be set in the configuration of your accounting software. The length depends on settings of your software and is in general 6 digits. The number is in general placed at the start of the reference.
2. Invoice number (the length vary in relation with the length of the ISR ID) | You can use this part of the reference (as 20 digits in the example) to be able to identify the debtors. Your invoicing software  gives you the structure of invoice numbers (for instance by appending clients numbers and invoice numbers). Unused positions are filled with zeros.
3. ISR Subscribtion number (in this example the Raiffeisen Bank of Landdorf) | The Raiffeisen Bank is identified with this number. In the optical line of the below part of the payment slip, the payment slip must contain 9 digits. The central part can contain up to 6 digits and be completed with zeros if  necessary. In our example with a zero before (01-052142-5).
4. Amount (10 digits) plus fixed values | The amount is displayed with 10 digits. The unused positions are indicated by zeros.
5. Control digit | The control digit is generated automatically by your accounting software.


More reference here: https://www.credit-suisse.com/media/assets/private-banking/docs/ch/unternehmen/kmugrossunternehmen/besr-technische-dokumentation-en.pdf
(Here they call it BESR (german) but the doc is in english)


ISR-B (through bank) is based on ISR (direct)

:warning: In case of ISR the ISR Customer ID number is not used.
Examples are provided in the code for better understanding.


## Current behavior before PR:

There has been a mix in the implementation between the Subscription number and the Customer ID

The generated reference is currently using Subscription number as Customer ID and Customer ID doesn't exist.

## Desired behavior after PR is merged:

Have a field to register ISR-B Customer ID number

And construct the reference like this:

```
            0100000494004> 150001123456789012345678901+ 010234567
            |/\________/|  \____/\__________________/|  \_______/
            1     2     3     4           5          6      7

            (1) 01 | currency
            (2) 0000049400 | amount 494.00
            (3) 4 | control digit for amount
            (4) 150001 | id number of the customer (size may vary, usually 6 chars)
            (5) 12345678901234567890 | reference
            (6) 1: control digit for identification number and reference
            (7) 010234567: subscription number (01-23456-7)
```

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

## Description of the issue/feature this PR addresses:

rework onchange on acc_number to set postal account

First we want to always display the pretty form of a postal account.
The swiss users will identifiy it more easily.

We always want to auto fill the field l10n_ch_postal when possible from
acc_number.

I changed the logic for validation to reflect more what was done in `base_iban`.

## Which includes only 2 cases of filling acc_number:

1. a 9 position postal account number (prettified or not)
2. an IBAN from PostFinance which include clearing 09000


## Current behavior before PR:

With l10n_ch acc_number is always copied to l10n_ch_postal field.
Some IBAN could be translated as postal account while it's not a valid conversion.

Desired behavior after PR is merged:

Less annoying onchange on res.partner.bank. (Provides some test cases for valid use cases)

## Bonus:

- computed fields fixed (CacheMiss) by always setting a value.
- ISR test fixed, partner_id mandatory on bank account and field name change for invoice_bank_partner_id

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr