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>
The partner created in TestOnchangePostal and the product created in
TestSwissQR were taken from demo data, which might not be installed
in the test environment, so the create_invoice() method could
raise a traceback.
Part-of: odoo/odoo#77295
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).
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>
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>
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
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>
resolves the following error:
E psycopg2.IntegrityError: null value in column "partner_id" violates not-null constraint
E DETAIL: Failing row contains (193, 010391391, null, null, null, null, 10, null, 1, 1, 2020-05-20 20:05:28.431208, 1, 2020-05-20 20:05:28.431208, null, null, null, null).
To generate an ISR payment slip you need:
* a type == out_invoice
* a partner bank account with a ISR issuer number (field l10n_ch_isr_subscription_[chf|eur])
* a currency either in EUR or CHF
Remarks:
* l10n_ch_postal is not necessary and must be used for Vendors only.
* human readable subscription number is xx-yyyyyy-c
validation of such format is done with the following PR: https://github.com/odoo/odoo/pull/51544/files
It does:
- Removes unexisting field from tests
- Adds required field on partner_id
- Fix test with an actual case that case generate ISR payment slips
closesodoo/odoo#53498
X-original-commit: 776fd59909d12c981585fac82cfa9f3603d96ccf
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This new modelling makes it easier to add new QR-code formats, and allows using all of them in website_sale and account.payment's form view as well (so, Swiss QR codes are now available there, while they were restricted to only invoices in the past). All barcodes are now generated as reports, from a dedicated route. This was only partly the case before : Swiss QR added a cross on top of the QR-code directly in the template, it wasn't part of the image returned by the route; now it is.
[ADD] base_qr_code_sepa: new module decoupling SEPA QR-codes generation from the base module
Each new QR-code generation option should thus be done in a dedicated module (or added to a localization) in the future.
[IMP] base_qr_code_sepa: update the generated QR codes to version 2 of the specification
Version 1 is still supported, so no need to backport this.
[IMP] l10n_ch: make Swiss QR-codes compatible with the new version of the specification (the old one is deprecated)
This will be backported to 11.0 and 12.0, as these QR-codes will soon replace ISR.
[IMP] account: make it possible to mark manual payments as sent with a button on the form view
This way, when making them directly with a QR-code (or doing a more classical wire transfer), people can keep track of what they already have asked the bank to do, and what they still have to treat.
closesodoo/odoo#44839
Related: odoo/enterprise#8262
Related: odoo/upgrade#992
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
Purpose
=======
- Add the SwissQR Code on the invoice in aim to replace the actual ISR
- Improve the settings of the SEPA QR Code to make it more user friendly
Specifications
==============
- ln_ch:
- Add a SwissQR Code on the invoice to fit the Switzerland QR-Bill Format
- Use the "partner_bank_id" field to generate the QR Code
- Add function to get the address number out of the field "street" and "street2"
- account:
- Remove the SEPA QR Code's journal settings from the general setting
- Display the "partner_bank_id" field on the invoice "Other info" page
- Use the "partner_bank_id" field to generate the QR Code
- website_sale:
- Add a check box on the payment acquirers to use the SEPA QR Code on the e-commerce
- Use the payment acquirer "journal_id" field to generate the SEPA QR Code
On the accounting config, you can select an automatic way to compute the
reference on invoice and then, improve the reconciliation in a later task:
- free communication: set what you want as reference (default)
- based on partner: find the partner more easily
- based on number: retrieve the invoice directly
Was task: 1847703
Was part of PR #25921
Purpose: When running tests, all the tests for the installed/updated
files are done. This commit adds a 'tagged' decorator that can be used to
tag tests. Combined with a new 'test-tags' CLI option, it adds the ability
to filter which tests are executed. For example, @tagged('slow') will
add a tag 'slow' to the test. The CLI option 'test-tags="slow"' will
only run tests tagged 'slow'.
One can use prefixes to select cases with tags.
'+' or no prefix means that the tests tagged with this tag are selected
for execution. '-' prefix will exclude the tests tagged with this tag.
Exclusion takes precedence over inclusion.
Also, by default, all Odoo tests cases are tagged 'standard' and with
the technical name of the module.
This means that when selecting tests with the 'test-tags'
parameter, if '-standard' is not specified, all tests tags are
going to be executed.
When tagging tests, one can remove such automatic tag by prefixing the
tag name with '-'. E.g. @tagged('-standard') will remove the standard
tag from the test.
Another example, if one wants to test the 'sale' module alone,
even without adding any 'tagged' decorator thos tests can be selected
like that: --test-tags="sale"
Tests are selected or deselected using a TagsSelector. When instanciated,
a string is passed with comma separated tests selectors like
'+slow,-standard'. When the 'check' method is called with a test as argument,
it returns True or False if the test has to be executed or not.
Add a new button to generate the ISR and remove the "double generation" of reports on 'Print invoice' button. This modification brings the code back to its original version and hence fixes the javascript bugs that occured with less than 3 workers running on the server and with Google Chrome when triggering multiple downloads simultaneously.
[ADD] account
Add a identifier to the 'register payment' button in order to reference it more easily and add the 'Print ISR' next to it.
[FIX] l10n_ch
The module did not install itself anymore, an import was missing.
Report generation was crashing due to a function's suppression.
The ISR is a payment slip report for account.invoice, that we automatically send and print with the regular invoice report (to ease usability, as these two reports usually go together).
[FIX] l10n_ch: italian translation
A field was missing for italian chart of account translation to work.
Nasreddin Boulif (bon)