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.
Goffin Simon
Denis Ledoux
Leonardo Pistone
Christophe Simonis
Nicolas Martinelli
Nicolas Lempereur
Stéphane Bidoul
rmu-odoo
Rifakathusen Haradwala
nachosalvador
Denis Michiels
Martin Trigaux
Arthur Maniet
Martin Trigaux
Commandant Custo
Arthur Maniet