The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.

closes odoo/odoo#74231

Related: odoo/enterprise#19850
Related: odoo/design-themes#43
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

closes odoo/odoo#70687

X-original-commit: cf975e44
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

Task 2309613

We have a new hierarchy:
* Accounting
  * [Generic, not changed]
  * Localization
    * Account Chart
    * Check
    * EDI
    * Point of Sale
    * Purchase
    * Reporting
    * Sale

This helps in displaying only the chart of accounts when clicking on
"Install more Packages" from the accounting settings in the Fiscal
Localization section.
We can also refine the search in the _auto_install_l10n post init hook
of account.

closes odoo/odoo#55384

Related: odoo/enterprise#12179
Related: odoo/upgrade#1568
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.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,... )

Task 2206499

We have to call the onchanges manually in order to compute the taxes
We don't want pdf's because they are not consistent with the data.
* Generated pdf would depend on the company details, set during the
  demo steps
* Generating a pdf would need to be done through a cron because
  wkhtmltopdf needs the web server to be running at install time, which
  is not the case. This has been judged too complicated and not worth.
* Hard coded pdf would also depend on the l10n, the date.

closes odoo/odoo#53279

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

Purpose of the task is, we have added the activities on various
listviews, the goal of this task is to update SO/PO/invoice demo data
with activities and also set tags on sales orders.

So in this commit, We added the activity on several SO/PO/Invoices and
also added the some tags one sales order and set the user as False
where the user is set as 'Odoobot'.

closes odoo/odoo#51799

Taskid: 2254708
Closes: #51799
Related: odoo/enterprise#10743
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Oversight during 293ccca9

`try_loading` should be called on install only,
not on module update.

closes odoo/odoo#52877

X-original-commit: 3557c265b878b21b95210c5708afbfa2826e11cc
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

In a general manner,
the chart templates should not be set to noupdate,
that way, if a new company starts in an existing database,
it starts with an up-to-date chart of accounts.

For instance,
if the chart of template is not updated from
12.0 to 13.0, the `default_pos_receivable_account_id`
is not added in the chart template,
and when a new company is created,
the default pos receivable account is not set on the company.
Besides, the field `res.company``account_default_pos_receivable_account_id`
is not displayed on any form view,
whether or not the full accounting is installed,
so we must especially pay attention this default account is well set
from start, as the user as no opportunity to correct this by himself.

In addition,
in upgrade scripts,
the default pos receivable account on the chart template
is used to correctly set the pos receivable account on the company
and on the pos payment methods,
so it must be well set for the upgrade script to do its job correctly.

Technically, it means, without this revision, the fields:
- `account.chart.template``default_pos_receivable_account_id`,
- `res.company``account_default_pos_receivable_account_id`,
- `pos.payment.method``receivable_account_id`
were not filled properly on upgrade,
causing critical issues in the accounting entries on pos session closing.

Related to #52786
Related to odoo/upgrade@ccfd2371ef89ae67dc9bd68bb0d02f2a440551a2

closes odoo/odoo#52870

X-original-commit: 3258ba015ff75b7c176d83a44261d24ebfcc26de
Signed-off-by: Denis Ledoux (dle) <dle@odoo.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#7019

closes odoo/odoo#41301

--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

Before this commit, the account on the original line was replaced by the
accrual account. This could be problematic for hashed journals. Instead
of having 2 different behaviors for hashed/non hashed journals, we
decided to always create 2 journal entries, which is also more academic:
* We don't replace something on an entry that has been posted
* We don't end up with taxes on the accrual account
* Accountants are used to do it this way

closes odoo/odoo#42787

Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>

Task 2168064
Show a preview of what will be done when using the accrual wizard

Purpose
=======

The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.

closes odoo/odoo#44401

Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

task-id: 2028z813

Task 2146469

Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool

This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.

The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.

The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.

** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002

closes odoo/odoo#41485

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

Task 2046908
Instead of having all the fields duplicated with second_*, we have now a
o2m allowing us to
* have more than 2 lines
* reduce duplicated code
* fix bugs and add features at only one place

We also remove the computation of writeoff and suggestions from the
client side as some code was 4-upled before (twice in in client and
twice in server side). The logic is now only at one place.

closes odoo/odoo#38119

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

Renamed xml ids of the main accounts (in prepartion for a future multi l10n
demo system). Change account numbering to match quickbook and other US GAAP
convention and recommendations.

closes odoo/odoo#37606

Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

The 'Miscellaneous Operations' journal was used instead of the 'Vendor
Bills' journal for that demo invoice, which lead to a crash when
processing it with the OCR.

closes odoo/odoo#37618

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

So that it can be visible in the groupby view, in enterprise.

closes odoo/odoo#36910

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

To get a better overview of the groupy view like "Sales Journal",
we need some attachments on invoices.

Furthermore, the product's label was missing on all invoice lines.

closes odoo/odoo#36573

Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

Task 2039772

Add a new amount matching mode by taking the amount from the label, based on a regex. The regex must contain a capture group. If multiple groups are matched, there will be an error.
Also add a 'remaining' option for the second line, that puts the remaining amount of the statement in the second line.

closes odoo/odoo#35143

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

- This commit moves the Payment Term "End of Following Month" from
  demo data to data and adds two new Payment Terms: "21 Days" and
  "30% Now, Balance 60 Days".
  It allows the customer to define less Payment Terms

task-2032586

Before, we only had a public method that installed
the CoA for the current active company.

With the multi-company changes, it was not
possible anymore to install a module with a
demo company and then have the CoA installed
in that demo company correctly.

We changed that public method to be able to
put an extra optional parameter and shortened
its name to try_loading instead of
try_loading_for_current_company.  The method that
it calls when there is no chart installed
is made private and renamed to _load.

closes odoo/odoo#35703

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

A new feature[*] in point_of_sale (PoS) which minimizes the
creation of account.move records in closing a pos.session relies
on a receivable account made specifically for PoS.

This commit addresses this feature's requirement by adding a
new receivable account to each localization.

[*] point_of_sale: single AE for a pos.session

TASK-ID: 1862388

The demo invoice for the OCR had incomplete fields to work properly, the
'Send for digitalization' button was missing and there was no attachment
preview.

closes odoo/odoo#35528

Signed-off-by: Florian Daloze (fda) <fda@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

This commit removes the field `datas_fname` from `ir.attachment` as
it was unnecessary and most of the time the duplicate of `name` or
`url`.

Task #1909865

closes odoo/odoo#32976

Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>

The goal is to be coherent with the user property.

Actually, company_id and company_ids on the environment are no fields.

Calling env.company_id returns a browse record, not an id.

When a cash journal is used in POS, we need to have accounts to post the
difference between what it's supposed to be in the cash journal and what
we really have in the cashbox.

To help the user to configure his cash journal, we've added default
accounts for cash difference in the localisation. Those default values
are stored on the company and are use for the creation of cash journals
if no values are provided.

TASK-ID: 1934784

- Add repartition lines on taxes

- Link account tags directly to account.move.line; remove the tag_ids field from account.tag

- Add a new report engine dedicated to tax reports, directly generating account tags. It is called as an alternate mode of generic tax report, with a dedicated "Use tax grids" toggle.

>> The biggest change lies in the way the new tax report computes its values.
Everything is now aggregated directly using the tags set on the account move lines. Thanks to that,
modifying the configuration of a tax today will not impact the report for the previous periods anymore.
This is a big improvement, as it means the report will keep on reflecting the values that were submitted
to the state before, whatever the configuration change.

- Add an audit char field to account.move.line telling with tax grids are impacted by the line, with the corresponding amount

- Modify the behavior of cash basis taxes: the cash basis account is now used as the transition account, while the regular account given in tax declaration is used to store the final entry (it was the opposite before)

- Modify every l10n_* module in order to keep them consistent with these changes

closes odoo/odoo#32833

Signed-off-by: Quentin De Paoli (qdp) <qdp@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

Purpose
=======

Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.

It is confusing for users to see the records from the company he is connected to
and the records of the children companies.

Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.

/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.

Specifications
==============

1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.

2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.

3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.

4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.

5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.

6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.

7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids

8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.

9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.

10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.

11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624



12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.

13/ Introduce a res.group to enable/disable the multi company per tab
feature.

14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.

15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.

16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.

17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.

TaskID: 1960971

closes odoo/odoo#32341

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Purpose of the task is some demo data values are not matching with the products
mentioned so update the demo data values with matching product.

Task: 1892754

closes odoo/odoo#28573

data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV

This commit is related to task_id : 1909961.

closes odoo/odoo#28909

The demo data could crash trying to send a (6, 0, [False]) to the ORM.

closes odoo/odoo#32256

Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

[IMP] l10n_generic_coa : adding demodata for OCREmpty invoice with an attachment in order to demonstrate OCR feature

Bank statement lines need to be matched with entries; We have to automate this operation as much as possible.
At the same time, create an algorithm that fit everyone needs is quite impossible.
For that reason we will let users choose the rules they want with the improvement of reconciliation models.

Note that we did it only for bank statement reconliation, not for manual reconciliations.

Was task: 1877375
Was PR #26669

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