The default taxes for most localisations have been left undefined by
default. When loading the chart template, the model generally selects
the first sales and purchase taxes, based on the order in which the
taxes appear in the csv, for the default sales and purchase taxes
respectively.
This behaviour can be confusing to those who are not yet familiar with
it. It has been decided that it is preferable instead to specify the
default tax in _get_*_res_company function on the account chart template
model, such that the default taxes are defined explicitly for every
localisation.
task-3453997
closesodoo/odoo#130733
Related: odoo/enterprise#45531
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
In Switzerland, since 16.0, the QR Bill page always has the external_layout template, whatever template the user chose for his invoices.
This was a "lesser evil" choice to allow the user to print QR-bills : BootStrap5 and wkhtmltopdf were not compatible, causing a display bug and generating incorrect QR Bills before this.
See for an example the task-3037921.
Returned to the original behaviour, namely :
- Display the invoice header on the QR Bill ;
- Adapt said header display to the layout chosen by the user ;
- Fixed Din5008 display.
task-3241502
closesodoo/odoo#132051
X-original-commit: 061a6780d445b9e23e62ef69b9da2503cb212cfb
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Steps to reproduce:
- Install l10_ch
- create a journal entry with account 9991 or 9992
- go on the general p&l and compare it to the swiss p&l
Issue:
The results won't be the same
Cause:
The accounts 9991 and 9992 are not taken into account into the swiss expenses.
The `CH_4` only takes into account accounts with code `4 <= x < 5`.
https://github.com/odoo/enterprise/blob/bd43cba9e7b5bdbab6319ae1a90e8bf3a8960c15/l10n_ch_reports/data/account_financial_html_report_data.xml#L416
Therefore accounts 9991 and 9992 won't be take into account.
Solution:
When initialising the localisation, we change their code so they fit in the range of `CH_4`
opw-3210100
closesodoo/odoo#129238
X-original-commit: 0896fbb0957060c82bf0f08deef167f866e63cc0
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Steps to reproduce:
- Install website_sale, contact, l10n_ch
- make sure your company is in Switzerland and has all the address information
- in settings, activate QR
- in Accounting/Journals/Bank:add a bank account (iban: CH4431999123000889012; qr-iban: CH11 3000 5228 1308 3501 F)
- install and enable the provider "Wire Transfer"
- From the Website, create an order and make sure the customer set an Invoicing address in Switzerland (address + Country)
- Validate the order
- In Website/unpaid orders: select your order and Confirm the order
- Create and confirm the invoice
- Print the invoice
Issue:
User Error is raised
Cause:
With Swiss QR code you need to have a valid payment reference. That is, an ISR reference such as in
https://github.com/odoo/odoo/blob/c6631df1c5b0b6d4c2268a826ca150edd0ca653e/addons/l10n_ch/models/account_invoice.py#L90
But when you create an order from the website, it creates an automatic reference "SO0001" which, when converted to an invoice, stays the same.
Since the reference is prepoluted, the `_compute_l10n_ch_isr_number` will not be triggered and therefore will raise an error when trying to print the invoice.
Solution:
Check if the Customer Invoice Journal uses the swiss reference model, then we know that the swiss loca is installed and can call the correct function to compute the reference/
Note:
In the test we check that `payment_custom` is installed. It is because the `_set_pending` method checks taht the payment_provider.code is "custom"="wire_transfer" in which case the sale order reference is computed
https://github.com/odoo/odoo/blob/b4ed9537895ecee48ed146add4257af0aebeb3f4/addons/sale/models/payment_transaction.py#L54-L56
opw-3334534
closesodoo/odoo#127338
X-original-commit: dfa4844e57b67d16b181e1e58813cdbbc7efa956
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Co-authored-by: flvr-odoo <flvr@odoo.com>
We allow creation of QR-Bill codes when they are issued from
another country than Switzerland.
Steps to reproduce :
1. Enable QRcode Bill in Accounting settings
2. Set a valid Swiss QR-IBAN account on your company.
(Contact > CH Company > Accounting tab > Bank Accounts:
Set account number to `CH21 3080 8001 2345 6782 7`.)
3. Set the CH Company's country to something else than Switzerland.
4. Create a Swiss partner (be sure to set all address/ZIP/city/country=CH).
5. Create an invoice to that Swiss partner and post it.
6. Click Print QR-BILL, it will raise an error.
closesodoo/odoo#127798
Task: 3359821
X-original-commit: c456c78e347c707b0f5b684b47631e5566963289
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
* l10n_ae, l10n_ar, l10n_at, l10n_au, l10n_bg, l10n_br, l10n_ch,
l10n_cl, l10n_dk, l10n_es, l10n_hu, l10n_in, l10n_mn, l10n_nl, l10n_no,
l10n_pt, l10n_sa, l10n_se, l10n_sg, l10n_si, l10n_uk
Some localizations do not have any default account for tax closing.
This leads to the opening of a RedirectWarning when trying to do a tax
closing.
task-3082332
closesodoo/odoo#124003
X-original-commit: 14abe7acb11d522fb2b4a274ac0eb06d41e637ed
Related: odoo/enterprise#42071
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
The method `_find_or_create_bank_account()` is defined for an
account.bank.statement.line so that it returns either the bank
account found or created. The extension made by l10n_ch does not
return the record found/created by a call to super(), which may
break reconciliations.
The code for the reconciliations in which a record is expected to
be returned can be seen at: https://github.com/odoo/odoo/blob/
c0eb0d41a3e6c1c766278884a745d45952799393/addons/account/models/
account_bank_statement.py#L1232.
The original implementation of `_find_or_create_bank_account()`,
where a record is returned always, is at: https://github.com/
odoo/odoo/blob/c0eb0d41a3e6c1c766278884a745d45952799393/addons/
account/models/account_bank_statement.py#L1282-L1291.
closesodoo/odoo#118451
X-original-commit: 6c7385c74fafbe84042261e29565a77e2ca0c03c
Signed-off-by: Laurent Smet <las@odoo.com>
When trying to add a QR code to an invoice, if some conditions weren't met, the user would more often than not get a message simply stating :
"The chosen QR code is not eligible with this invoice".
This was confusing to the user, since the reason for a QR code to not be eligible are multiple : invalid IBAN, unavailable in X country, wrong currency...
Modified the _eligible_for_qr_code function to _get_error_messages_for_qr() so it returns an error message if the qr code is not eligible, and None otherwise.
task-3069753
closesodoo/odoo#116482
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Since 16.2, a condition was added to _get_available_qr_methods :
if self.env.company.country_id.code == 'CH':
rslt.append(('ch_qr', _("Swiss QR bill"), 10))
This condition was not allowing a multi-company call, and caused another issue.
Once the method was called to check on the eligible QR choices, the ORM would consider the current company to be the US default one.
Hence the condition would never be fulfilled and a stacktrace would appear :
Oh snap!
Wrong value for account.move.qr_code_method: 'ch_qr'
Reverted back to the unconditional behaviour, and will check this occurence with the framework team.
closesodoo/odoo#115952
X-original-commit: cdba8a062985bfbdcbe8d51aa9705e702b4dee61
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Since v16, the QRR reference would always be set at 000000000000000000000000000.
This was because of a conflict in the computation dependencies in account_invoice.py: _get_invoice_computed_reference (account_move) was called on a draft invoice, which hadn't compute its name yet. Since the computation of the QRR invoice checks for this name in order to integrate it into the reference, the space dedicated to the name was instead filled with 0 (see _compute_l10n_ch_isr_number).
By manually computing this field, we ensure the reference computation can be completed.
This fix allows for a correct behaviour in v16, while a more sustainable change will be made in master.
closesodoo/odoo#115071
X-original-commit: 7852b0ee4dddf6cf96b6ce40cf7c24011b9ef33a
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
A lot of the separate files were kept up to now because it made the
process easier while applying the script to rebase.
The files can now be merged.
Some code is also cleaned by using CSV instead of a python dict.
Part-of: odoo/odoo#114164
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
Aim :
Allow customer from Switzerland to emit an invoice with a QR code to a SEPA customer.
Context:
In Switzerland, adding an extra page containing a QR Bill is mandatory in many cases, mainly when the customer is also from Switzerland (although there are other conditions).
However, activating the option 'QR Codes' in the settings (which is not linked to the QR Bill) can cause problem.
For instance, it will be impossible to bill a foreign customer, because we check that the conditions are right to emit a swiss QR (which is a bug).
After this commit :
The new behaviour is :
- Swiss user --> swiss customer: don't change the invoice, allow to create a QR Bill
- SEPA option activated, swiss user --> SEPA customer : join the SEPA QR to the invoice
- SEPA option activated, swiss user --> swiss customer : raise error
task-3062570
Manual fw-port of https://github.com/odoo/odoo/pull/109808closesodoo/odoo#109935
X-original-commit: a9980477048e4adffda4a71a72ff1cc8490637f9
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Creditor Reference is one of the 3 allowed references type in swiss QR-Bills (with None and QR-Reference)
It is used with normal IBAN (QR-Reference must be used only with special QR-IBAN)
Fixes#71578Closes#81269closesodoo/odoo#95518
X-original-commit: 8e1d86dcb10aebc1be1a318126492573a4b74331
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Just fixing a typo in _render_qweb_pdf_prepare_streams().
closesodoo/odoo#97182
X-original-commit: 9cf1061b9a463e67e46468b5bf83a0e2059ded77
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The only option to print a QR Invoice was to go on the invoice page and to click on the Print QR Button.
This PR allows for a user to print multiple QR codes, selected from the Invoices view.
The download occurs normally if all invoices are valid and QR-printable.
A wizard opens when the whole invoice selection isn't valid. It allows to download the invoices as a single pdf or to see a list of the ones that could not be printed in the QR format.
The wizard's text depends on the number of QR-valid, ISR-valid and classic (non QR, non ISR) invoices that the user tried to print.
All invoices for which a print is asked will be printed with a QR bill if it is possible. If not, this will check if printing in the ISR format is possible. Lastly, if none is possible, the classic invoice will be printed.
The behaviour allowed for the removal of the QR PRINT and ISR PRINT buttons on the single invoice view, for a behaviour closer to the original guidelines.
Bills can't be QR printed.
Corrected QR-Bill CSS.
task-2726507
closesodoo/odoo#82341
Signed-off-by: Laurent Smet <las@odoo.com>
Users with Swiss localization have a possibility to create QR_Bills from their invoices, however, PoS currently does not send information about partner_bank_id to the generated invoice, so users can not create
QR_Bill from the invoice that was created by PoS. After this commit, function _get_partner_bank_id will get partner_bank_id in case customer didn't pay for the order fully, and this information will be added to
the invoice, thus, giving user an ability to create a QR-Bill from said invoice.
In case user will try to create a QR-Bill from the invoice that has been fully paid, they will get an error saying that QR-Bill can not be generated on paid invoices. If the user tries to generate QR-Bill from
the invoice that has empty partner_bank_id, they will also get an error notifying them that they should check Recipient Bank field on the invoice.
OPW-2695969
closesodoo/odoo#83456
X-original-commit: 634f90a728cba9ff45c17e471f2b160e939bbd3d
Signed-off-by: Masereel Pierre <pim@odoo.com>
Reworked the structure of the HTML and the SCSS
to adhere to the official specs:
- 5mm padding inside the two main sections
- Correct font sizes
- Bold headers
- Increased the Swiss Cross inside the logo (7mm x 7mm)
- Scissors pictogram on the outline
- Dashed borders
Sizes now take the wkhtmltopdf (1/1.25 factor) shrinking
into consideration.
closesodoo/odoo#80544
X-original-commit: f02622684c6a220a425044d8d4a5fd474efdb519
Signed-off-by: William André (wan) <wan@odoo.com>
Issue:
When trying to print a Suisse QR bill, if multiple images are presents
in document and they have a url as src, some pictures will not be
displayed.
(Same issue may occur with simple QR code)
Cause:
It's a known issue with wkhtmltopdf: https://github.com/odoo/odoo/commit/2949138a7d84cd6c925ea1745d62f25ef077bb8b
Also, adding css class to body by js break wkhtmltopdf.
Solution:
Replace link by base64 image value (use a function to retrieve base64
image instead of image_url).
Remove class 'l10n_ch_qr' added by js (no need since CSS file didacted
to this report).
Move `_get_qr_code_base64` and `_get_qr_code_url` logic/flow
(since generic) to account module.
Move specific logic like `_get_qr_vals` and
`_get_qr_code_generation_params` to specific module (ex: l10n_ch).
extra: Alter some css for better rendering + update unitest.
opw-2620082
closesodoo/odoo#77643
X-original-commit: 699b6eeac993e3a8d97ae7949170f7e18ca05831
Signed-off-by: Olivier Colson <oco@odoo.com>
DIN 5008 is not specific to Germany.
It also applies to Switzerland, Austria (& Lichtenstein).
The goal is to make DIN independent from l10n_de,
for Switzerland and Austria.
closesodoo/odoo#76227
Task: 2613993
Related: odoo/upgrade#2932
Signed-off-by: William André (wan) <wan@odoo.com>
Purpose of this commit is to avoid forcing mail_post_autofollow to True when
it is set to False. It eases inheritance and custom behavior.
Task-2612911
PR odoo/odoo#60792
Steps to reproduce the bug :
- Create a French company
- Go to accounting settings > in “Fiscal Localization” install French accounting
- Install “l10n_ch_qriban”
- Go to contacts > Configuration > Bank accounts
- Create a new bank account > add a French company newly created in the “Account Holder” field
Problem:
The specific fields to a Swiss company appear.
Solution :
Check if the country of the company encoded in the “Account Holder” field is Switzerland.
opw-2504699
closesodoo/odoo#70011
X-original-commit: 326dc3f7001f605d7ebb929740ed8478fce20e7e
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Adding this field to the bank journal's form view had been done to ease encoding; yet more fields were left to be set on the related res.partner.bank object (l10n_ch_qr_iban, chf and eur subrscription numbers. In the end, to be consistent, we would have needed to do related fields for all of them as well on the journal. This would have put too many advanced features in a single screen. Instead, we just consider the whole setup needs to be done directly on the res.partner.bank.
Task 2412391
This module had been introduced in stable to add a field to store the QR-IBAN in case it differed from the regular account number. We now merge it into the original module and make it so that the only way to define a QR-IBAN is to populate this field (no more magic with account number).
Before, account_fiscal_country_id was only use for tax operations; and country_id was used for all the other accounting stuff. Now, with the new ability to use foreign tax reports (with foreign VAT fiscal positions), we can generalize the fiscal country, sot that it is the one that needs to be used for the whole accounting. Since foreign tax reports were not supported before, account_fiscal_country_id is already set on existing database as the country for the "main" accounting, so the impact of this change is small.
closesodoo/odoo#68349
Related: odoo/upgrade#2322
Related: odoo/enterprise#17299
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The condition on computation of `l10n_ch_isr_number_spaced` was not in line anymore with
`l10n_ch_isr_number` computation.
With fixes on the ISR number the use of `l10n_ch_isr_postal` is rightly not
mandatory anymore.
This lead to an empty field, visible on the ISR report.
closesodoo/odoo#67058
X-original-commit: fdbfb332b528ba8b35d7529eecd610086465aff8
Signed-off-by: Josse Colpaert <jco@openerp.com>
Part of task 2124952
Return False if the recordset is empty.
```python
self.acc_type == 'iban'
```
This already ensures there is at most one record.
We now have the same behavior as for `_is_isr_issuer` (False if empty
recordset)
Was needed after cb8b6db391 because it is
now calling _is_qr_iban on a possible empty recordset.
Revert 1b2aef65f4
Steps:
- Edit the current company (1):
- Country: Switzerland
- Currency: CHF
- Install l10n_ch
- Go to Invoicing > Configuration > Bank Accounts
- Edit Bank:
- Bank Account: create a new one:
- Account Holder: (1)
- Go to Configuration > Journal
- Edit Customer Invoices:
- Advanced Settings tab:
- Communication Standards: Switzerland
- Go to Customers > Customers
- Create a new customer (2):
- Fill in street, city, zip code and country
- Edit (2):
- Contacts & Addresses tab:
- Add:
- Select Invoice Address
- Contact Name: Keep this field blank
- Go to Customers > Invoices
- Create a new one:
- Customer: "(2), Invoice Address"
- Add a product
- Validate it
- Click Print QR-Bill
Bug:
Traceback here:
https://github.com/odoo/odoo/blob/b76e9ef658bde0178fa1660b6ad27b880e91632a/addons/l10n_ch/models/res_bank.py#L129
TypeError: 'bool' object is not subscriptable
Explanation:
The contact name of an address is optional. When nothing is filled in
that field, it returns `False`, hence the error.
Using the commercial company name ensures a name is put in the invoice,
even if the contact doesn't belong to a company.
opw:2447158
closesodoo/odoo#65417
X-original-commit: 2537bb01675279f08edf65077e6d41a5bd968ec4
Signed-off-by: backspac <backspac@users.noreply.github.com>
When printing an invoice with an iban qrcode using l10n_ch module, a
little ch flag appears in the center of the qr code.
When odoo is started from elsewhere than the root of the odoo code, the
flag does not appear. The cause is that a relative path is used to find
the flag image.
With this commit, an absolute path is computed to find the flag.
closesodoo/odoo#61048
X-original-commit: d33785032b1ca2c6e1d4ade7e174d024fae9a151
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Add hooks to be able to tweak the Bank customer ID number for ISR-B
Those hooks will allow to not use of the field l10n_ch_postal for
multiple purposes.
Fixes conditions on which the reference is generated.
It shouldn't be always generated if l10n_ch_postal is set.
Only if a l10n_ch_subscription_xxx is set.
closesodoo/odoo#58398
X-original-commit: 4790b8e57aa357cda32818392d795b8c0dc48f43
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
We refactored a method to check if the IBAN is in the correct
range to be a QR-IBAN or not. (to be able to reuse it)
Thanks to Ravi Gohil
Task: 2307262
X-original-commit: efd6e493a6d855c12e43e9b3cb7c436c6d7de35a
Limit must be 70 not 71
closesodoo/odoo#54587
X-original-commit: 7d808675de88ed54de67f798de9cec16bb95ef3b
Signed-off-by: Josse Colpaert <jco@openerp.com>
On res.partner.bank, we check that:
- l10n_ch_postal contains a valid postal number
- l10n_ch_isr_subscription_chf contains a valid ISR subscription number
- l10n_ch_isr_subscription_eur contains a valid ISR subscription number
ISR subscriptions numbers are postal numbers but starting with 01 or 03.
Those codes are reserved to ISR issuance.
When the bank account on a Vendor Bill is detected as
an ISR Issuer, check the reference is actually an ISR.
The 27 digits ISR Reference is error prone when typed by hand
and an error at this stage would break the payment process later.
This is required to avoid batch payment error with SEPA.
We prefer using the pretty form xx-yyyyy-z of a postal account.
The Swiss users will identify it more easily.
We always want to auto fill the field l10n_ch_postal when possible from
acc_number, which includes only 2 cases of filling acc_number:
1. a 9 position postal account number
2. an IBAN from PostFinance which includes clearing 09000
Original prs: Closes#51645, #51544, #51560closesodoo/odoo#54455
X-original-commit: f8a3ec438e3b5fa56305db729a78304aec7a6716
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
This intend to enforce specifications and improve readability
Layout changes:
* [FIX] Amount section must be placed under the QR code
* [FIX] Don't display empty additional information
* [FIX] Rename slip sections and labels
* [IMP] Rework of the layout
Group content like adresse by removing line spacing
Reduce character size to follow Swiss Implementation Guidelines QR-bill v2.1
Reduce left margin to avoid overlap of spaced ISR reference on the Receipt
* [FIX] Missing street on Receipt
* [FIX] Add thousand separators
Official specs asks for:
- thousand separators as blank. (using a non breaking to avoid spliting the amount)
- decimal separators as a full stop
> If the amount isincluded in the Swiss QR Code, then it must be printed after the currency code. A blank (space) should be used as the thousands separator and a full stop «.»as the decimal separator. The amount must always include two decimal places (e.g. CHF 1 590.00).
QR-Code:
* [IMP] Align QR code upper and improve accuracy of size
Add an option on reportlab to print QR Code without surounding blank space
this is required to compute with accuracy the width of 46mm x 46mm defined
in the specs.
* [FIX] Street and street2 issues
Removes an extra space between street values when only one is given.
Test the right partner street, only the company street was checked.
QRR generation
* [FIX] make it possible to generate QRR
It must be possible to generate QRR without ISR subscription number.
Content removed as not present in the specs version 2.1:
* [RM] procedure section
* [RM] due date
Translations:
* [IMP] Add translations of the QR-bill in DE, FR and IT
* [FIX] QR-bill lang is now based on customer lang
Tests:
* [IMP] Add unit tests for Swiss reality check for the QR-bill
closesodoo/odoo#54053
X-original-commit: 4f4edd0594b29252a5d44281cc773230c09521e9
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Daniel Kosky (dako)