If the date format language was changed to invert month & day values (so, changed to the classic european format instead of the american format)
Then, when entering manually a datetime without the time (so just '01/02/2014' instead of '01/02/2014 00:00:00', the day and month were inverted (the datetime was set to 02/01/2014 instead of 01/02/2014) because the datetime entered did not exactly match the date + time pattern.
We therefore added a fallback case, to test to parse the value with the date pattern alone (without the time)
For FIFO and standard price, return product at the purchased price instead of
the cost or current standard price.
Not applied for average as returning a purchased product do not recompute
the average price and would lead to an inconsistency in the stock value.
opw 615263
When an invoice is created from a picking keep a reference to the stock.move to
use the right price for the COGS entry.
This used to be done by the _prepare_invoice_line method but it was removed
during WMS refactoring, replacing by the brand new _get_invoice_line_vals
method! opw 615263
Following 3a50d4b3, should not distinguish invoice and refund for account
selection in anglo-saxon.
Do this in both onchange method and invoice creation from picking.
'false' is displayed when no value is assigne to a field declared in a calend.
Impacted versions:
8.0, master
Steps to reproduce:
Create a fresh database, create a new customer and set his fiscal position.
Create a quotation, select the customer
Current behavior:
File "/Users/keje/src/odoo/addons/account/partner.py", line 107, in get_fiscal_position
return part.property_account_position.id
NameError: global name 'part' is not defined
Expected behavior:
No error
_buckaroo_generate_digital_sign uses the values dict to generate the shasign
At some point, it alters the dict, it removes BRQ_SIGNATURE, but, as the values dict was not copied, it altered the original dict.
So, the key BRQ_SIGNATURE was not anymore present for methods called after _buckaroo_generate_digital_sign.
For instance, the overriden method form_feedback of website_sale payment
When loading the registry without any module installation/upgrade, models are
set up once instead of twice. In other cases, models are always set up before
installations/upgrades.
Loading views for custom models from module data files was not possible because
custom models and fields were introduced into the registry after all modules
were loaded. As a consequence, the view architecture did not pass the checks.
This patch takes a different approach: custom models and fields are loaded
early on in the registry, so that views can be validated. The trick is to take
special care of relational custom fields: we skip them if their comodel does
not appear in the registry. This allows to install and upgrade modules that
create/modify custom models, fields and views for them.
When adding an extra price for a variant (through the button variant prices in the product template form) with a digits precision greater than 2 (4 for instance), the computed public price did not keep the digits precision of the extra price