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>
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.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>
Before that, just one pixel from the bottom of the QR-bill frame passed got out of the page, and end out creating a second, empty page.
Since this error was probably due to some rounding issue in the way A4 dimensions were compared to the layout specified by the scss file, we solve it by rounding the height of this section a little more, removing 0.25mm from it.
[FIX] l10n_ch: qr bill report: display the payment ref under "reference" and the invoice's name as additional information
closesodoo/odoo#53453
X-original-commit: 8a6cc1a572cd04f540e4a5e83362319c13274aea
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
QR-bills could only be generated for ISR-compliant invoices, which is wrong and would have caused issues in the future, as ISR will slowly disappear.
Furthermore, doing it this way avoids raising an error after commit 719f087 , when trying to print an ISR-compliant invoice if the module hadn't been updated (it used to raise because the QR-bill report didn't exist, and it tried generating it).
closes odoo/odoo#51858
Forward-port-of: #51340
Forward-port-of: #50744
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
Using it as a parf of the regular invoice pdf report was wrong, as this report is subject to the margins defined in its paper format; causing issues as for the rendering of the QR report, which must be displayed at a precise location (just like ISR). wkhtmltopdf doesn't allow having different margin values in the same file, so we did just as for ISR, and now generate QR-bill in a distinct pdf.
[IMP] l10n_ch: add receipt part to QR-bill pdf report
closesodoo/odoo#50765
X-original-commit: 99b5306545b945810e8259f2cc447b933d316778
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
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>
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
PURPOSE
Clean and rename code about language management and template rendering in mail
template model.
SPECIFICATIONS
Clean method naming and try to make code easier to understand and call. Also
add and/or clean docstrings of rendering methods.
Notably
* ``_classify_per_lang``: for each lang-contextualized template, give the list
of record ids;
* ``_render_template``: now working only on a valid list of IDs instead of
allowing both int / list and having a return type depending on the input
type. It allows to simplify code and delegate some processing to callers;
Introduce new API method
* ``_render_lang``: for each record id return the lang matching it;
* ``_render_field``: render a field of mail.template, on given set of record
ids. Usage: template._render_field('body_html', records.ids). Language
computation is available for this method;
Remove the "multi mode" support of rendering that either returned a rendered
value, either a dict based on given ids. Now all methods always work in batch
and caller have to fetch the correct result if necessary.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
If the bank account number is a postal one, search differently
to see if the account already exists. As for a postal account,
the same number can be used by multiple partners, changed the
account to include the name of the partner, but for this
we need to alter the way the account is searched/created.
closesodoo/odoo#47365
X-original-commit: b95b9d6db2af51644f640142d5a0b9ca72eac52f
Signed-off-by: Josse Colpaert <jco@openerp.com>
In 0.15 accessing werkzeug.urls functions directly through werkzeug
is deprecated, the shortcut will be removed in the eventual werkzeug
1.0.
Fix existing uses of these shortcuts. Also cleanup some imports when
they're not far from a werkzeug* import being altered.
- Create an invoice for 1000
- Make a partial payment (e.g. cash) for 250
- Print the ISR
The ISR contains an amount of 1000 (total amount), while it should be
750 (amount left to pay).
opw-2180538
closesodoo/odoo#44552
X-original-commit: 421bbcd5270b889874dc99a9a8cead0272e1e3da
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since this field is not required on res.partner.bank (which is fine: we want it to be synchronized with the journal's currency, which is None if the journal uses company currency), the parameter received by validate_swiss_code_arguments ended out being an empty recordset in case the company was directly in CHF. This caused the QR code to never be displayed in this situation.
closesodoo/odoo#43351
X-original-commit: 60a55834b5ae0a8ac10914a243f97029d9921ae6
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Fixes https://github.com/odoo/odoo/issues/43122
Before this commit, Creating Journal without Bank account number will be failed as, It tries to update Related field 'l10n_ch_postal' while bank_account_id is not set.
In this commit, we update 'l10n_ch_postal' if 'bank_account_id' is present on Journal
closesodoo/odoo#43302
X-original-commit: 6ddd93bf615c95675c13cc989b8a6f835de04324
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Issue
- Swiss company
- Install Accounting & Studio
- Journals > Customers Invoice
- Communication standard: Switzerland
- Journals > Bank
- Swizz account with CHF ISR subscription number
- Studio > Reports > ISR
Traceback
Cause
If the statement of the `l10n_ch_isr_optical_line` compute
method is False, the value will be `None`.
In the view, we do a foreach on the value which is `None` and
it crashes.
Solution
Set an empty string as default value for the
`l10n_ch_isr_optical_line` field
OPW-2129122
closesodoo/odoo#41247
X-original-commit: a0dc556b0e04c9e89e7f6a8e4e9af045151614f7
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
two compute field have same method but one is store and other one is non store
so we split compute method for both fields(l10n_ch_isr_number,l10n_ch_isr_number_spaced)
closesodoo/odoo#40970
X-original-commit: d7a2d4aca37647ae568a5bb9f515ce2138245878
Signed-off-by: Josse Colpaert <jco@openerp.com>
The BVR implementation was confusing as it
seemed to only take into account the case where the postal
account belonged to PostFinance itself and not to another
bank, where the same number is shared among multiple accounts.
Also, the purpose of the fields was confusing.
Adaptations done:
- When you add a bank account of type postal in the account number,
there is an onchange that automatically puts it in the postal account
field and makes itself unique by adding the name of the partner to
the account number. The account will still be detected as "postal".
- Improve help message of the postal account field on the bank account
as it is used for two different purposes (Client Number for own accounts
and postal number for "postal" vendor accounts)
- Only show the subscription fields when you have to do with a bank
account related to your own accounts / Switzerland
- Add fields in the Add Bank Account wizard if it is for Switzerland
(subscription number and the postal field we label "Client Number")
- Also label Client Number on the journal form for postal field
- Don't remove zeros in front of the client number on the BVR
- Don't put extra - in the subscription number on the BVR if it has
some - already
- Use number without spaces for payment reference
[FIX] l10n_ch: module moved to enterprise
closesodoo/odoo#39642
Signed-off-by: Josse Colpaert <jco@openerp.com>
Purpose of this commit is to remove code coming from old features,
implementations and that was not completely cleaned.
Including
* remove support of old "reply" composition mode which is simply a comment
with a parent message, and is deprecated;
* remove support of old "mail.compose.message.mode" context key that was
used in Odoo 6.1;
* remove support of message_id default value in context instead of
default_parent_id;
* remove old redirection of user / partner post. This code come from
old age when people were able to post on their "profile" by posting
on their user;
* remove unnecessary method for selection field;
* remove unused imports to clean a bit code;
We also make some optional parameters in rendering methods mandatory to
ease code understanding and future modifications.
Task ID 1853147
PR #39272
On a customer invoice, click on 'Print ISR' => Error
This is because of computed fields not set.
opw-2081567
closesodoo/odoo#38325
X-original-commit: ed6dd79703bd1e02a8c3d9f13d12e2baa157ec36
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Now, Swiss users can auto populate BVR number generated for invoice in it's 'Payment Ref.' field
by simply configure it in 'Communication Standard' of invoice's journal.
task: 1999530
closesodoo/odoo#36253
Signed-off-by: Josse Colpaert <jco@openerp.com>
An Inpayment Slip with Reference (ISR) subscription number is provided by the bank or by Postfinance
ISR When the ISR subscription comes from Postfinance it is a direct
subscription.
ISR (bank) When the ISR subscription comes from a bank it is the bank subscription
toward Postfinance.
Having the subscription number on res.bank has 2 drawbacks:
If you have multiple accounts at Postfinance
or
If you have multicompany and each company has a Postfinance account
you won't be able to emit with different ISR subscriber numbers.
This also renames the fields to be accurate on the meaning.
An ISR reference is a Payment reference that will apear on the invoice.
It is better to name it subscription number.
closesodoo/odoo#35873
Signed-off-by: Josse Colpaert <jco@openerp.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
- Having a user with access to create an invoice in Accounting, but
without the rights to create or modify Currency's objects;
- Install the Switzerland localization;
- Create an invoice with this user.
Before this commit, the user will have an access error. This issue arise
because when saving an invoice it will also try to save the name of the
currency. In the Switzerland localization a field(l10n_ch_currency_name)
is related to the currency's name of the invoice.
Now, this field is tagged as read-only, and when saving an invoice, it
won't try to save also the currency's name.
opw-2032756
closesodoo/odoo#34680
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
* account, crm, hr, im_livechat, l10n_ch, l10n_it_edi, mail,
mass_mailing, project, stock, base
- `String` -> `string`;
- `defaut` -> `default`;
- `defaults` -> `default`;
- `reandonly` -> `readonly`;
- removed redundant `placeholder` attribute for `Char` field;
- removed redundant `size` attribute for `Float` and `Integer` fields;
- changed to use `Selection` instead of `Char` for a field having a
defined `selection`.
closesodoo/odoo#35356
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
nie