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.

closes odoo/odoo#46325

Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Was still using the old "selection:" form instead of ir.model.field.selection

closes odoo/odoo#44322

X-original-commit: fdf9b06d76f95965ed173b1631305f8c8c3a8d9d
Related: odoo/enterprise#8050
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

- 'partial' payment state corresponds to invoices whose payable/receivable move line has been partially reconciled with some other line.

- 'reversed' payment state corresponds to entries that have been cancelled by the creation of a single reverse entry (using the dedicated button on the form view). This state can be set on invoice as well as on regular entries.

=> To stay consistent with the naming conventions, this commit also renames invoice_payment_state field to payment_state, since it's no longer only applicable on invoices.

closes odoo/odoo#41723

Related: odoo/enterprise#7202
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

closes odoo/odoo#35754

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

- Since commit https://github.com/odoo/odoo/commit/beaa30a3d1843de43a45f419bfbc1bfa7613a920


the object `account.invoice` has been removed.

We now refer to `account.move` when talking about invoices.
In website_sale_digital, a piece of code was still refering to the
field `invoice_id` in `account.move.line` instead of using `move_id`.
- Fixing some missing adaptation after the account refactoring

closes odoo/odoo#35630

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

* remove _onchange_invoice_date_due as it is superseeded by _onchange_recompute_dynamic_lines
* change invoice_date_due only if not set and if there is no payment term, it was erased and set to invoice_date_due if we did not set invoice_date_due before posting
* raise a warning if we validate an empty move/invoice
* correct the renaming of user_id -> invoice_user_id in invoice template
* correct the renaming of date_invoice -> invoice_date
* the data on purchase journals was not displayed correctly as the sign
of the amount in the graphs was not signed correctly
* the methods for computed invoice reference were not correctly renamed in l10n_be for (account.move)._get_invoice_computed_reference
* the default reconciliation model was only installed in the first company, we make it now install along with the chart of account
* the partner of invoices and the label of invoice lines should be required
* the widget one2many_list doesn't exist

closes odoo/odoo#34786

Signed-off-by: Cedric Snauwaert (csn) <csn@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

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'`

closes odoo/odoo#33284

Signed-off-by: Martin Trigaux (mat) <mat@odoo.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

Replace the email template content form if you have any question to if you have any questions.

task-1962924

Closes #33520

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

Include commit 572d628 again, as it was lost with a forward port.

closes odoo/odoo#31479

Task 1920906
remove the l10n_be_structured_comm field
random/date references will not be longer used
adapt for the last changes in account

closes odoo/odoo#29858

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

The field reference_type has been renamed invoice_reference_type in v11.
The selection value 'bba' for that field has been renamed 'structured'.
We update the template to reflect these changes.

Discovered thanks to a forward port of that field up to v12.

closes odoo/odoo#30224

The malformed manifest is causing a warning when testing all l10n.

closes odoo/odoo#28680

This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.

All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.

Were no longer synchronized since 9.0
Commit 710f67ad mistakly reexported them too

Remove the .pot, keep only a few one like it actually makes sesne to have
translated content such as l10n_be_invoice_bba

To match new model_terms syntax

Steps to reproduce the bug:

- Create a partner P with communication type set to BBA

- Create an in_invoice I for P with a BBA structured communication

- Validate I and try to duplicate it

Bug:

A UserError was raised "Empty BBA Structured Communication!"

opw:1883982

closes odoo/odoo#27331

The view 'res_config_settings_view_form' doesn't exist in the module
l10n_be, so as the field wer are referencing in the xpath is added in
module account, we inherit 'account.res_config_settings_view_form'
instead.

reference_type was already present in the customer invoice but not in the
supplier invoice

Closes #25732

Regenerate all child translations based on the .pot
Remove the terms that are either equal to the parent, either equal to the
source term.
Remove empty translation files

The structured communication is no longer configured for each partner independently. It can be configured like others communication type through the settings.

task: 32254
PR: 26154
co-author: Haresh Shyara (hsh)

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

In this commit we improve templates used in account and l10n_be. Purpose of this
commit is to have templates that embed or use standard Odoo email layouts to
make them look modern and have a common style across all emails.

Main guidelines

 * better use of div / p / br to try to lessen layout issues, especially
   when updating templates using the editor;
 * correctly sequence the templates fields definition;
 * correctly set templates values notably auto_delete and user_signature
   fields to avoid confusion;
 * correctly layout the email content using light notification email. It
   can either propagate the layout choice through various send mail methods
   or directly embed the styling in the templates for more technical or
   complex templates;
 * use email_formatted computed field when possible to avoid having hand-made
   from / to addresses;
 * fix various typos and improve subjects when necessary;

Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.

This commit is linked to task ID 1843395 and 1843376 (and 1868112) and to
PR #25294 and #25349 (and #25889).

Co-Authored-By: Mitali Patel <mpa@odoo.com>

Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.

 --change the group name acc_sale -> sale

TASK:1865319

opw-1853119

Many error messages are misleading or too "vague"
This task aims to improve all error message.

Task #47042
PR #23321

Use `format_amount` in the mail templates in order to format as a
regular amount (with rounding and symbol).

opw-805370

The regional variations are not published on Transifex and hsould be translated
manually.

The translations are mainly from previous versions or contains buggy fuzzy
translations (not matching the real source string).

Clean based on the .pot and delete the empty files

Fixes #21733