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
closesodoo/odoo#73483
X-original-commit: b299e880417026688b2fbde23307bd011de8c44d
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@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
closesodoo/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
closesodoo/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
closesodoo/odoo#55560
X-original-commit: ae0c3b600403a21a196e51ce88fa6b25990f2b64
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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.
closesodoo/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#7019closesodoo/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 82794c8662
opw:2226115
closesodoo/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>
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.
closesodoo/odoo#44252
X-original-commit: f66042c96795701c1a313f40fdd320d28e9803ee
Signed-off-by: Laurent Smet <smetl@users.noreply.github.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'`
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
closesodoo/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.
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
closesodoo/odoo#32920
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Due to a forward-port, the code updating the vendor_ref has been duplicated
a few lines apart.
Closesodoo/odoo#33334closesodoo/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
closesodoo/odoo#32616
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Move the SO part in a new module
Add the functionality to PO
Task 1945220
closesodoo/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
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@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
closesodoo/odoo#32180
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Commit 1be873d 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
closesodoo/odoo#32656
Signed-off-by: Nans Lefebvre (len) <len@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
closesodoo/odoo#32661
Signed-off-by: Nans Lefebvre (len) <len@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
closesodoo/odoo#32500
Signed-off-by: Nans Lefebvre (len) <len@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 052a5702c5.
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
closesodoo/odoo#31757
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
closesodoo/odoo#32097
Signed-off-by: Nicolas Martinelli (nim) <nim@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
closesodoo/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
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
Adrien Widart