This commit avoid a traceback when you open the form account_invoice_line
for a supllier invoice without having installed purchase.
The fields_view_get method add domain with purchase_ok field, but this
field can be missing on the model product.template because purchase is not
a dependence of account.
Invalid field 'purchase_ok' in leaf "<osv.ExtendedLeaf:
('purchase_ok', '=', True) on product_product
In stable version, the best fix found, is to remove the domain.
But we need to fix it in master, moving this field from purchase module to
product module. (odoo/odoo##13271)
This commit closes#13268 and closes#315 for stable version.
Todo: merge odoo/odoo#13271 in master (@qdp-odoo agreement)
The group_lines method didn't make the sum of the quantity field, hence resulting in incorrect results when making product based statistics from the account.move.line records.
Courtesy of Luc De Meyer. Was PR #10551
By default, when reading a m2m field, entries that are
deactivated in the destination table are not included.
This behavior is desirable in some cases (e.g. for
"tags" or "categories", but not for entries that
significantly impact other field values in the parent
record, such as taxes.
The problem is rather obvious: when displaying a
paid invoice that used taxes that are now deactivated,
the taxes are hidden while they still affect the
computed amount. And after cancelling + resetting
to draft, the tax is not taken into account anymore,
while still being linked.
Forcing the field-level (python) domain to include
both active and inactive entries solves the problem:
- when reading, displaying and recomputing values,
deactivated taxes will be included.
- when trying to pick a tax, deactivated entries
will still be ignored, as expected.
This commit applies the technique to all m2m
fields that refer to taxes.
Fixes#12066
opw-677751
- Only invalidate cache for fields and records we modify
- Rewrite query to be more efficient
- Avoid o2m commands to be more efficient; write directly on reverse m2o
when using a journal with 'Group Invoice Lines'
and issuing an invoice with foreign currency with more than 1 line
(of the same product, or no product),
the amount currency in the journal item
associated to the merged invoice lines was wrong.
It took into account the `amount_currency` of the first line only,
ignoring the `amount_currency` of the remaining merged lines.
opw-670972
Closes#10375
Specifically, when one API implementation calls the other one, it has to call
the method *from the same class*. Otherwise, overriding the method may result
in an infinite recursion. Consider:
class A(Model):
_name = 'stuff'
@api.v8
def foo(self):
return 42
@api.v7
def foo(self, cr, uid, context=None):
return self.browse(cr, uid, [], context).foo()
class B(Model):
_inherit = 'stuff'
def foo(self, cr, uid, context=None):
return super(B, self).foo(cr, uid, context=context) + 1
and now call: `env['stuff'].foo()`. This invokes `B.foo` (new-API), which
calls `B.foo` (old-API), which calls `A.foo` (old-API), which calls `B.foo`
(new-API) instead of `A.foo`!
This issue would not be present if old-API `A.foo` was defined as:
@api.v7
def foo(self, cr, uid, context=None):
return A.foo(self.browse(cr, uid, [], context))
When creating an invoice with a fiscal position(fp) which maps an included tax(itax)
to an excluded tax(etax). Each invoice line mapped by fp must recompute its unit price
to substract the included tax.
Inspired from 503820aCloses#9811
opw:658109
This revision is related to cfbd086b09.
This is the same use case than above, but with a different
currency than the one of the company, for the field
`amount_currency` this time.
Closes#8135
opw-647639
When converting an invoice in journal entries,
the invoice lines amounts must be currency rounded
not only when the invoice currency is different
than the company invoice,
but also when they are the same.
Otherwise, a rounding issue can happen
if the `Account` decimal accuracy is greater
than the currency rounding, the journal entries
total and the invoice total could be different.
e.g.
- Set decimal accuracy of Account and product to 4
- Create a supplier invoice, any supplier
- Add a line as follow:
- Product: None
- Quantity: 2057
- Price unit: 11.9150
- Tax: 16% (create a new tax with 0.16 as percentage)
- Validate the invoice
- In the other information tab of the invoice,
click on the journal entry
- Notice that the first line has as credit amount 28430.6150
While the invoice total is 28430.6200
- Now if you try to create a bank statement with one line
of -28430.6200 and as partner the supplier you chose
in the second step of this explanation, and try
to reconciliate it to the invoice created above,
the above won't be marked as paid, while it should.
opw-647639
Fixes#8135
This allows to reset correctly the domain of UoM if the product is not set.
Without this patch, the domain used is the domain of the previous product in
the list.
opw-642074
When we change a product line of an account invoice, a current unit with
a invalid unit category was not dropped which should be since:
- it is different from a sale.order,,
- there is a domain on the unit of measure only allowing units from the product's unit category.
This fixes drop the current unit of mesure in this case.
opw-640985
The tax_amount on account.move.line generated from the validation of an invoice
did not include the taxes with 'include in base amount' enabled.
Instead of using the line total, use the price_unit of the tax which is
correctly computed through compute_all method.
Fixes#5939
If a line of the invoice move was in a foreign currency
but its residual amount in this foreign currency was 0,
the `amount_residual` (in company currency) was used,
instead of the `amount_residual_currency`, which
is the residual amount in this foreign currency.
This was due to the fall back with the `and / or` statement.
Using `if / else` instead solves the issue.
This could lead to issues when the residual amount
in the foreign currency was 0, but the residual amount
in the company currency was 0.01, due to the exchange rate
loss.
When generating the accounting entries, to compute the name, the invoice
reference (e.g. origin purchase order name) was first used before the supplier
invoice number. To facilate reconciliation of bank statements, the supplier
invoice number makes more sense.
Fixes#3839, opw 618765
On an invoice, tax lines are generated in tax_line field. When modifying
manually the tax amount, the recomputed tax_amount field was incorrect in
multicurrency environment, leading to an entry with different tax amount and
debit value.
opw 611474
when a customer invoice is created directly,
if a product variant is selected,
it now computes the price from the product variant and
not from the product template.
opw: 629285
Add restriction on product_id field to prevent the suppression of the product
if already present in an invoice.
This is to avoid the suppression of a used product variant when modifying
the list of attributes.#
Due to the constrain, the variant will be disabled instead of deleted.
Fixes#4129
Add warning message on the product form to warn users about the potential impact
of modifying variants.
During rev. cbe2dbb, type2journal was refactored, and set as a global variable in the top of the file, as it was use everywhere accross the file.
But, in this specific method _get_journal_analytic, this type2journal dict wasn't the same as everywhere else, as you can see at rev. d2ff95f for example. We must therefore set a specific type2journal dict for this specific method.
If a company contact (a partner with a company set as parent) had invoices, and the company of this contact was duplicated, all the invoices lines were duplicated, on the original invoice moreover (new lines were added on existing invoices)
[FIX] account: Preserve analytic account on tax lines which are on same general account as invoice line
After careful analysis, I'm now convinced it is a good thing to preserve
the analytic account on taxes line which have the same general account
as the invoice line.
This is the best default case and will save time for users,
while leaving the flexibility to adapt the analytic account on
taxes manually.
[FIX] account: Error when manually adding analytic account in the generated tax lines on an invoice
fixes#374
fixes https://bugs.launchpad.net/ocb-addons/+bug/1084822
The fix considers invoice tax lines with different analytic account
are equivalent for the purpose of checking if the list of tax line
is complete.
Caveat, this changes the structure of keys in the dictionary
returned by account.invoice.tax's compute method, I suppose this
is ok for the master branch.