The `timesheet_ids` was added in the `sale.order` form.
As it was invisible, and not used by the attrs of another
field, or by an onchange, this is pointless to load
it for no reasons.
Besides, this could lead to issues regarding the form validation,
in case the analytic lines were not valid.
e.g. if an editable list view is used to load
these analytic lines and if a field in this editable list
has been made required,
while analytic lines exist with this field not filled.
In such a case, it was not possible for the user to correct the
analytic lines, as they were invisible, and it was not the place
to correct them anyway.
opw-672184
All the POS has to do is copy what accounting does. In the case of a
fixed tax we should do (from account.tax._compute_amount):
return math.copysign(self.amount, base_amount) * quantity
where copysign(x, y) returns x with the sign of y.
When base_amount is 0 it's positive, not negative. This also correctly
handles a base_amount of -0, although it's something that we shouldn't
encounter in the POS.
opw-672118
Before this we used line.price_subtotal directly when creating
account.move.line records, which causes issues when dealing with
non-integer quantities. In that case the amount paid by a POS customer
will never accurately be able to match the total computed amount of the
order.
opw-672118
The implementation of `__len__` & `__nonzero__`
were not defined for the py types `wrapping_dict`
and `wrapping_list`.
For instance, this prevented an empty list
to be considered as `False` in domains
evaluated by the web client.
e.g., in the automatic partner merge wizard,
the domain
```
[('id', 'in', partner_ids and partner_ids[0] and partner_ids[0][2] or False)]
```
is used.
When the `partner_ids` list was empty (meaning the "partners to merge" list
was empty in the wizard), it wasn't considered as
`False`, and it therefore attempted to get
`partner_ids[0]`, which resulted to a crash, as
the list was empty.
opw-672095
Closes#11343
Courtesy of Xavier Morel (xmo@odoo.com)
When computing the balance, debit and/or credit, the opening period must
be filtered out. Otherwise, the invoices which are still opened at the
time of the period closing will be counted twice.
opw-670584
Due to the _set_product_template_field function, it is not possible
to set the standard price on a product template with more than one variant.
Due to the _compute_product_template_field function, it is not possible
to read the standard price on a product with more than one variant.
The field "standard_price" is in readonly to avoid some problems if the costing
method is in real time.
Closes: #11308
opw:671013
There are 2 journal items missing on the accounting entry that
represents the assignation of the landed costs (for a product that has
already left the stock!) => expense account at the debit and stock
output account at the credit (amount is equal to the cost of the landed
cost)
opw-671311
When transfering the pack, the priority to the moves in state "assigned"
or partially_available(=true) must be given.
Used case (steps):
-set warehouse with three steps to delivery
-create one product A with qty on hand 10
-create sale order with first line product A by qty 2 and the second line with product A with qty 10
-confirm sale order
-check availability
-transfer pick by qty 10
-transfer pack by qty 10
The pack couldn't be transered
Now the pack is transfered.
Closes: #10764
opw:668682
Upgrading a module in the presence of computed custom fields can fail, if a
computed custom field depends on another field from a module that is not loaded
yet. The patch simply prevents custom fields with dependencies from being
loaded in partial mode.
[FIX] account: fixed behavior in order to create the exchange rate difference entry at the full reconciliation only.
This is needed in order to support the use case where an invoice in foreign currency is paid on a bank account in company currency,
with the user encoding manually the difference due to the currency fluctuation (writeoff in the bank statement reconciliation interface): before
this patch, Odoo was doing automatically the same, what results in a duplicated currency difference booking). ticket ID: 670876.
A test has also been added in account/tests/test_reconcilication.py (test_statement_euro_invoice_usd_transaction_euro_full) to ensure that use case
is now fixed.
[FIX] account_full_reconcile: a reconciliation is full as soon as either total_debit = total_credit OR if total_amount_currency is 0
[FIX] account: when registering a payment with a writeoff, always create the writeoff line exactly as entered by the user. Before, it was modified
by the exchange rate entry, for some reason...
[FIX] account: on invoices, show the payment widget and outstanding payments in the invoice's currency always
[FIX] account: when assigning a payment in company currency on an invoice in foreign currency, save the amount_currency in order to create the correct
exchange rate.
[FIX] account: show the currency difference entry on the invoice payments widget
[FIX] account: fixed the reconciliation methods in order to work with exchange rate entries that have debit = credit = 0
[FIX] account: fixed reconciled field computation. A line is reconciled only if its amount_residual AND amount_residual_currency are 0
[IMP] display the move name of payments on the invoice payments widget
As its documentation notes[0], Jinja2 only processes unicode template
data (or pure ASCII, which will implicitly decode to unicode).
The scaffolding system would read raw scaffolding data in memory (both
templates and passthrough non-templates), but fail to decode templates
before handing them to Jinja, blowing rendering up if templates
contained non-ascii.
Fix#11331 by always decoding templates from UTF8 before handing them
to jinja. This is backwards-compatible, ascii templates work as they
used to, non-ascii UTF8 templates now work correctly, non-ascii
non-UTF8 templates what are you doing?
[0] http://jinja.pocoo.org/docs/dev/api/#unicode
The type of the related field purchase_id is many2one.
With the type the function _related_read in fields.py can convert
the record "purchase.order" in id.
A `sale.order` is considered a quote when `draft` or `sent`,
not just draft.
Before this revision, a `sent` quotation was took into account
in the amount total of sales, not in the number of quotes.
opw-668340
Before Odoo 9.0, `type="url"` leaded
to the use of `do_action_url` in `kanban.js`, which
basically redirected to the link url.
This action no longer exists in Odoo 9.0, besides, this
is not really useful, you are redirected
anyway when using a `<a href="..."/>`.
opw-668215
The a product valuation is real-time, the date used is the scheduled
date of the move, not the actual move processing date. This is because
the date is updated on the move after the AML creation.
opw-671372
Fixes#11228
crm.activity inherits mail.message.subtype with the field subtype_id
Before rendering "chatter.ChatComposer", the internal subtypes are fetched
on model mail.message.subtype(in function "fields_view_get").
But when deleting a crm.activity, the linked mail.message.subtype was not
deleted.
Used case:
When deleting a crm.activity, the activity still appeared in the chatter
if you log an internal note for an opportunity as an employee.
opw:670654
In the sales report, the price are displayed within
the company currency.
The rates in `res.currency.rate` are the
rate TO the company currency
e.g., if the company use the USD as currency,
3152.20 COP TO USD, for the Colombian Peso
To display the price within the company currency
from the currency in which the sales happened,
the price must be devided by the currency rate,
not multiplied by
e.g., with the same setup and the above example,
If the product was sell to 315220.00 COP,
the price within the company currency (USD) is
315220.00 / 3152.20 = 100.00 USD
This was corrected at revision
48ccb19937
but it has been omitted during the salepocalypse
94716a3f14
opw-671931
The `quotations` filter in the sales report did not
take into account the `sent` sale orders.
This is following the revision
7f5f945dcf
which meant sense in Odoo 8.0, as
this report is based on the `sale.order.line`,
and the state on the line could be different
than the state on the order, and there was no
`sent` state anyway among the possible values
of the line state selection.
But, for Odoo 9.0, the state on the line
is a related to the state of the order,
and `sent` must therefore be taken
into account again.
opw-671719
The result of the method `_get_pl` is cached:
```
@tools.ormcache('uid', 'country_code', 'show_visible', 'website_pl', 'current_pl', 'all_pl')
```
But, the result depends as well on the partner pricelist set
in the partner form (or even the pricelist used correctly in his cart),
and, unfortunately, this value is not among this method parameters.
To force the recompute of the method when the partner pricelist
change, one of the method arguments (mentioned above) must change.
To serve this purpose, another method is created, adding
the partner pricelist and the order pricelist among its
parameter, to force the recomputation of the available pricelists
when there is a change in the partner or order pricelist.
The old method is kept for retro-compatibility purposes,
and basically call the new one without the two last arguments
For information, the pricelist in the cookie is set only when
the user choose a pricelist different than the default one
among the available pricelists.
opw-670898
- Issue: Edit sale.order form view, add new line, change product who have
taxes and click quickly on save (with slow network) => error message.
Because some deferreds are lost.
- reduce number of reads and onchange for x2m widgets
- remove before_save method and use commit_value (the issue was that if the
before_save and the change trigger an onchange, the onchange deferred is not
checked before saving the content.
The form view product.template.common.form is common for product.product
and product.template Then the active_id could not be used by default for
the field product_tmpl_id.
opw:670779
Denis Ledoux
