Sale orders created through the website that have to be automatically
invoiced should ignore the delivery invoicing policy.
Otherwise you can end up with either an invoice not being generated at
all. This means the user has to manually generate and add the payment to
it. Even worse is if only some purchased products have invoice policy
delivery. In this case a partial invoice would be generated to which the
payment would be added, leading to a mismatch between invoice total and
payment amount.
-*- coding: utf-'8' "-*-"
is not a valid encoding. Introduced by
666387a274 I think. It was probably a
typo/replace gone bad and it got copy-pasted everywhere. Emacs complains
every time you try to save changes to files with this invalid encoding.
This changes all of them to
coding: utf-8
adhering to eae045949d.
Done with:
find . -name '*.py' -print0 |\
xargs -0 sed -ie 's/-\*- coding: utf-'"'"'8'"'"' "-\*-"/coding: utf-8/'
Introduces two new options:
- confirm_so: to confirm the sale order on acquirer confirmation
- generate_and_pay_invoice: confirm_so + generation of invoice and
payment registration
website_sale and website_quote both did their own
form_feedback. This causes issues because:
1. it would force upcoming features to have to be duplicated as well
2. there's a risk that improvements/bug fixes will only be applied to
one module, an example of this happening is
46c5f93b6c.
NB:
- The option no_delete is not working, a fix will come from chm
- The many2many widget on a sheet creation is not working correctly as
the called command is a (1, id, values) without a (4, id, _) before.
A fix will also come from chm, but a disgusting hack has been
provided for this particular case (to remove after chm fix)
During refactoring of the field view, parent.model has been replaced by
model_id since it is more elegant. (odoo/odoo@4a60a3)
That was correct when you was working directly from the ir.model.field.
But if you was comming from ir.model -> fields -> 'add an item', the
model_id is unknow in the context of pyeval.
This commit close#12455
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
Odoo add the extra letter "s" to the translated word "Active User".
This is caused by adding "s" at the end of the word directly from the template,
which makes no sense in many language.
This prohibits translators from translating the plural form in any language.
The plural form and singular form of "Active User" should be translate
separately.
Fixes#12469Closes#12470
Use case:
-enable multi currency (use UDS as company currency and EUR as secondary currency)
-create account account in a different currency (EUR)
-create journal for the bank account in EUR
-create a new tax included tax
-create a new bank statement in EUR journal and add one line
-reconcile
-Choose a counterpart with the included tax and click on reconcile
Before the fix:
After reconciliation the amount_currency for tax and expense were wrong.
You could check this in the journal items linked to the bank statement.
Video:https://youtu.be/678rFb4OE2Q
opw:680693
The former algorithm was incorrect: when checking two related nodes together,
it returned as if a cycle was found (even when no cycle was present.) The new
algorithm computes the transitive closure of the relation from the root nodes,
and stops as soon as a cycle is found.
Joren Van Onder