Steps to reproduce:
In an account move, if the partner_id is changed to one that does not have a value assigned in the property_purchase_currency_id field and with a value in the context for default_currency_id,
when passing through the _onchange_partner_id function of the purchase module,

Cause:
the variable currency_id will take the value in the context as second option causing an error when trying to get the value in currency_id.id because currency_id will be an integer and not a record.

issue-121232

closes odoo/odoo#121921

X-original-commit: e04d4a0b
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

Steps to reproduce:
- put the currency of the bill to eur
- change the partner with a partner with no purchase currency set

Issue:
The bill is re-set to usd

Note:
addendum to https://github.com/odoo/odoo/pull/116852



opw-3233527

closes odoo/odoo#119624

X-original-commit: 647e289c
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>

Steps to reproduce:
- company currency = USD
- set a partner P with a `property_purchase_currency_id` in EUR
- create a bill with Azure partner and set an bill line
- change to partner P
issue -> the currency of the line has not been change
- change to Azure
issue -> no change about the currency

Cause:
- We update the move.currency_id but not the line_ids.currency_id
- after setting Partner P, we try to set a partner that no `property_purchase_currency_id`, we do not enter in the condition

opw-3233527

closes odoo/odoo#117918

X-original-commit: 8985426b
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>

If we use the auto-complete feature to add PO's lines to an bill or we select multiple PO's then use
'create bill' button, the generated invoice line will copy the sequence line from the PO's line. This
can lead to situation where we will have all the first lines of each PO then all the second, etc, ending
with a mix of all PO's in the bill.

Example:
Purchase order 1
- seq 10 line A
- seq 11 line B
- seq 12 line C

Purchase order 2
- seq 10 line A'
- seq 11 line B'
- seq 12 line C'

Invoice created from those PO's
- seq 10 PO1:line A
- seq 10 PO2:line A'
- seq 11 PO1:line B
- seq 11 PO2:line B'
- seq 12 PO1:line C
- seq 12 PO2:line C'

After this PR this PR the lines from the same PO's will be contiguous like:

Invoice created from those PO 1 and 2
- seq 10 PO1:line A
- seq 11 PO1:line B
- seq 12 PO1:line C
- seq 13 PO2:line A'
- seq 14 PO2:line B'
- seq 15 PO2:line C'

opw-2749682

closes odoo/odoo#95052

X-original-commit: 49b143e1
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Beckers Thomas (tbs) <tbs@odoo.com>

How to reproduce the bug ?

- install the accounting, contacts and purchase apps
- create several companies and enable the checkboxes of all
  these companies
- create a new contact and add a bank account for each company
- switch to a company different than the first one
- create a request for quotations in the purchase apps and
  confirm it
- in the accounting app, create a new vendor bill and use the
  auto-complete field to select the RFQ created earlier.

The bug:

When you try to create a vendor bill from a request for quotations,
the recipient bank is wrongly chosen. Because of that, there will be
2 issues. The first one is when you want to create the bill from the
RFQ: you will get an error and the invoice won't be created. The second
one is when you create an invoice then use the auto-complete field. In
this case, there won't be any error but the recipient bank will
be wrong.

opw-2731264

closes odoo/odoo#85738

X-original-commit: 8b4f4a98
Signed-off-by: Adrien Minet <admi@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Minet Adrien (admi) <admi@odoo.com>

When adding several PO to a bill, if they don't have the same currency,
it will lead to incorrect amounts

To reproduce the error:
1. In Settings, enable "Multi-Currencies"
2. Invoicing > Configuration > Currencies:
    - EUR: Active, Current Rate = 2
    - USD: Active, Current Rate = 1
3. Create a PO:
    - Currency: USD
    - Products:
        - One product, no taxes, unit price 1000
4. Confirm PO
5. Edit PO:
    - Qty Received: 1
6. Repeat 3 -> 5 with EUR instead of USD
7. Open a new Bill
8. Add the first PO to the field "Auto-Complete"
9. Add the second PO to the field "Auto-Complete"

Error: Both invoice lines are now expressed in EUR and both subtotals
are equal to 1000 even though the exchange rate isn't 1

This commit suggests not to change the currency of the account move if
the latter already has some AML. Moreover, the amounts must be converted
if they come from a PO that uses another currency

OPW-2573748

closes odoo/odoo#73483

X-original-commit: b299e880
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

closes odoo/odoo#64777

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

Before this commit vendor's currency wasn't used on creating an invoice if there
is default journal in context. As I understand, the idea was to let onchange("journal_id")
handler to update the currency. It works well, if journal has the same currency
as specified in vendor record (res.partner). But it confuse users in following
scenario:
* there is just one vendor journal
* vendor is configured to invoice in another currency
* then, if you create invoice via "Accounting >> Overview >> Vendor Bills", it
would have journal's currency
* while, if you create invoice via "Accounting >> Vendor >> Bills", it
would have vendor's currency

This commit force to switch to vendor's currency on changing vendor field, even
if it differs from journal's currency. If after changing vendor, you set another
journal, then journal's currency is used (thanks to onchange("journal_id") handler)

opw-2339966

closes odoo/odoo#59162

X-original-commit: 513cc1abe121cd05623be1a6519239f8f4b3fb48
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

This commit removes "state = purchase" in account move attrs domain. The purchase state doesn't exist.
This commit adds a related field to purchase order in account move line.

Task ID: 2312024

closes odoo/odoo#55611

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

Issue

	- Accounting & Purchase
	- Create a PO for wood corner
	- Create a bill for wood corner, add a ref
	  and auto complete with the previous PO

	The ref is replaced by the PO's one

Cause

	In purchase account_invoice _onchange_purchase_auto_complete
	we update all the bill values with the PO values including
	the PO ref (empty or not)

Solution

	Exclude the ref of fields to be updated

OPW-2313418

closes odoo/odoo#55560

X-original-commit: ae0c3b600403a21a196e51ce88fa6b25990f2b64
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

closes odoo/odoo#54349

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

By specifying the with_company at a higher level:
1) The risk of multi-company conflicts decreases
2) We allow customizations to use _prepare_* methods to potentially
create records in other companies when needed.

closes odoo/odoo#55192

X-original-commit: 33c767e1778d2b1fc83aaaea92c3c2aa008b9520
Related: odoo/enterprise#12105
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@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>

Steps to reproduce the bug:

- Let's consider a vendor V with a supplier currency €
- Let's consider the current company's user C in $
- Let's consider two vendor bills journals J1 in € and J2 in $ from C
- Create a vendor bill for V

Bug:

The default currency was $ instead of € and the default journal was J2 instead
of J1. This fix keeps the same behavior as implemented in 82794c86

opw:2226115

closes odoo/odoo#48857

X-original-commit: 801182f6222521c2961560b3b67743a143a22eff
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

========
Purpose
========

Currently, purchase missing some billing functions that we have in sale
invoicing:
 - Create credit note when necessary
 - Create vendor bill in batch in list view

========
Spec
========

 - In case of retures, when create a bill for a purchase order, we check
the total amount we want to bill to decide whether it's a vendor bill or
a credit note.
 - In the list view, add a new action to create vendor bill/credit note
for all selected order.

========
Links
========

Task 2170715
PR #44210

Related: odoo/upgrade#919
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

closes odoo/odoo#48008

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

Fixes #44133
Before this commit, the Bank account on the new Bill created from the PO was not set due to missing methods to set those fields.

This commits adds missing methods to set Bank account.

closes odoo/odoo#44252

X-original-commit: f66042c9
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

Add two PO with references 'XY' and 'Z' to a vendor bill.
The reference is computed as 'XY, Z' (with ', ' as separator).
Add a PO with reference 'X', the reference becomes 'X' instead of 'XY, Z, X'.

There are two variables that may not be defined (vendor_ref and self.reference),
and specifically the case where a reference is the prefix of another one is not
correctly dealt with.

opw 2005825

closes odoo/odoo#33841

Signed-off-by: Nans Lefebvre (len) <len@odoo.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.

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

Have a PO with a product in automated valorization, and average as method of valorization
Validate and receive *partially* (create backorder)
invoice with a different price than the PO
Receive the backorder
Invoice the rest, also with a different price than the PO

Before this commit, wrong amounts were written in the account.move corresponding to the invoice.
In particular, the payable account's amount was erroneous because it is computed to balance the move
As a result, the bill showed an amount due different from its total, even though nothing was reconciled with it.

After this commit, the payable entry and hence the amount due on the invoice are correct

OPW 1967289

closes odoo/odoo#32920

Signed-off-by: Lucas Perais (lpe) <lpe@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

Due to a forward-port, the code updating the vendor_ref has been duplicated
a few lines apart.

Closes odoo/odoo#33334

closes odoo/odoo#33676

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Do a PO in a foreign currency
Invoice it in the same foreign currency
Validate the invoice

Before this commit, The account move of the invoice
contained a price difference line
which is wrong, since the price has not changed in any ways

After this commit, the move has only two lines
one in the stock input, one in the payable

Also, the case where the price does change
due to a change in currency rate is handled

OPW 1955315

closes odoo/odoo#32616

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Commit 1be873d4 removed the modification of the reference field
from the _onchange_origin.
The reasoning was that since this is an onchange on invoice_line_ids, it was
applied too often, which annoyed users in the case they overwrote that field.

However when using the "Autocomplete" field (vendor_bill_purchase_id),
then the user expects values to by modified.
Before, it worked by setting the origin field, which trickled down
to the reference.
Since that commit removed this, we re-add it explicitly in that case.

opw 1962364

closes odoo/odoo#32500

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

Move the SO part in a new module
Add the functionality to PO

Task 1945220

closes odoo/odoo#33282

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

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>

Move the code from commit ea1fc124 to the onchange on purchase_id.
The field vendor_bill_purchase_id is a technical one added in v12 to allow using
old vendor bills as template for new vendor bills.
However the logic on purchase_id was already in v11, so we match commit 14239733

opw 1962364

closes odoo/odoo#32661

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

Do a PO in a foreign currency
Invoice it in the same foreign currency
Validate the invoice

Before this commit, The account move of the invoice
contained a price difference line
which is wrong, since the price has not changed in any ways

After this commit, the move has only two lines
one in the stock input, one in the payable

Also, the case where the price does change
due to a change in currency rate is handled

OPW 1955315

closes odoo/odoo#32180

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Commit 1be873d4 removed the modification of the reference field
from the _onchange_origin.
The reasoning was that since this is an onchange on invoice_line_ids, it was
applied too often, which annoyed users in the case they overwrote that field.

However when using the "Autocomplete" field (purchase_id),
then the user expects values to by modified.
Before, it worked by setting the origin field, which trickled down
to the reference.
Since that commit removed this, we re-add it explicitly in that case.

opw 1962364

closes odoo/odoo#32656

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

When creating an invoice programmatically, make sure to retrieve the
`currency_id` field set by `_onchange_partner_id`.

opw-1951314

closes odoo/odoo#32097

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

The reference fields is supposed to contain the reference number in the vendor's
system. E.g. if the vendor is using Odoo, it could be SO0744.
Therefore this reference is not supposed to change once written by the user.
However there is the _onchange_origin that uses the origin purchase order lines
to populate the reference fields on invoice_line_ids changes.

We remove entirely this behaviour for reference,
essentially reverting 052a5702.
Instead we put a default for origin and reference in action_view_invoice
so that these values are initially used at create.

opw 1920747
opw 1944840

closes odoo/odoo#31757

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

Create a new vendor bill.
Choose a vendor with a "supplier currency" different from the company default.
The currency on the vendor bill does not change to the currency of the vendor,
unlike when a purchase order is created.

We set the currency in the partner_id onchange.

opw 1932683

closes odoo/odoo#30961

Before that, when receiving, then invoicing with price diff, the value in interim account corresponded to the price on the invoice instead of the original valuation one.

Scenario to reproduce the issue:

* create PO with 1 product, FIFO valuation, price=10
* receive PO: the entry in stock interim account has debit=credit=10
* create invoice, with price=15 instead of 10
* the invoice entry should be: payable: C=15 ; price diff: D=5 ; interim account: D=10
  ==> Instead, we had payable: C=20 ; price diff: D=5 ; interim account: D=15 => this was wrong

Also added a test case for the same scenario, verifying the amounts written in the different accounts (and refactored a bit ValuationReconciliationTestCase for easiness)

Closes #27394

In case no PO has a vendor reference, keep the value.

Overwrite vendor reference only if there is a PO linked to the bill.
Otherwise, any addition of product will erase what the user just typed.

Closes #26734

Create a PO and assign any string to the Vendor Reference field. Confirm
and create an invoice.

The Vendor Reference field on the invoice is empty, while it is expected
to be filled in.

opw-1879379