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.
The methods product_id_change() and uos_id_change() have been converted to the
new api, and now use the decorator @multi. When invoked with the old api, by
convention the methods will take the last argument as the context. But this
will not work properly for those methods, as the context is passed in another
position. In order to avoid an argument swap in the api wrapper, we moved the
context to its expected position.
Fixes#1943
Explicitely refresh invoice browse_record(...) in order to have correct 'date' in account.move.
Use context_today() date instead of time.strftime() for date_invoice. (opw 611210)
The residual amount is typically needed to render the
online payment forms (payment acquirers).
Payments on the other hand rely on account.move.line,
something that portal users should never be allowed to read.
Removing the field from the view by setting a model-level
group permission ensures they will not see an error.
The forward port of the fix 3609ba10f2 will be done separately, as the mrp scheduler has been completely refactored from saas-5.
Conflicts:
addons/l10n_be_coda/wizard/account_coda_import.py
addons/point_of_sale/static/src/xml/pos.xml
addons/procurement/schedulers.py