Before this commit, the parser (date, datetime, float, monetary, ...) was only
called on field from current model, and not on sub field.
Eg: product_id.price was not parsed as float, because product_id != float
This commit add an overiddable function to get all the parsers: get_parsers
This commit closes#14572
_get_partner_pricelist could return both a recordset or an ID.
While the ORM handles both where the method is called, a migration script
relies on an ID being returned.
( migrations/sale_contract/9.saas~13.1.1/pre-models.py", line 24 )
This commit ensures an ID is being returned every time.
When making an inventory adjustment in multi company,
the default location_id was all the time taken from
'stock.warehouse0' even if the user was not allowed to read
the warehouse. Inspired from _get_default_location in pos_config.py
opw:695616
Avoid traceback 'list indices must be integers, not str' when country_id not in sidebar.
env.browse(id).read(['name']) return a list, so country['name'] should be country[0]['name']
This reverts commit 8b64bf7682.
This should have been fixed in 8.0, a moment of distraction made me
push it in 10.0.
This is not the branch you are looking for, carry on.
There was several issues with this method:
- the workflow is incorrectly called (`purchase.signal_workflow(...)` instead)
- the workflow no longer exists (`purchase.state = 'sent'` instead)
- the code is only triggered when sending an actual mail and not a notification
- the code is never executed as the change is already changed
The last point is due to the override of `send_mail` in mail.compose.message.
The state is changed before `_postprocess_sent_message` is called (if called at
all).
Similar change of state is already done for sale.order.
This commit replaces and closes#14760
The 'note' field on account.fiscal.position is the "Legal mentions that have to
be printed on the invoices." As the invoice is translated in the customer
language, it makes sense to be able to translate this note too.
Closes#14735
The issue is that if you block a workorder when you exceeded the
expected time, the workcenter is not blocked.
The workcenter state is computed according to its productivity lines.
The productivy lines are marked with a loss type type that define the
reason of the time loss (availability problem like missing equipment or
quality problem like broken equipment). There are also two magic loss
type that define if the work on the workcenter is done in the expected
time (fully productive time) or is done exceeding the expected time
(reduced speed). The unblock button appears if the workcenter is
blocked.
To compute the workcenter state, we have to look through the last
productivity line of the workcenter having no end_date. Before the
patch, we look for the last productivity line and it could return one
with an end_date while there was a productivity line without one and it
was this one that would define the workcenter state.
This is solved by immediately searching for a record without end date.
We also add some comment to the code to understand a little more what's
going on.
Some code prevents to modify or delete an `ir.model.field` if another field
depends on it (like one2many depending on many2one). Make a special case when
the code is executed during a module deinstallation.
OPW 694009
It has been done outside of the previous commit
to give the possibility to point the comment
to the according revision, as this is a really tricky
case.
opw-687201
On an invoice, when registering a payment in a foreign currency
for which the payment pays entirely the invoice,
and even more thanks to the change gain(write off),
but for which the foreign currency rate to the company currency is higher than 100,
(higher than the currency decimal precision of 2 digts),
e.g. Invoice in CDF, Payment in USD (1 USD = 948 CDF),
and choosing the option "Mark invoice as fully paid" for the difference handling,
the invoice could not be marked as paid, according to the result
of the currency rate rounding.
This is because the debit or credit of the writeoff was computed
from the payment difference, in the foreign currency,
to the company currency, which lead to two currency rate computation,
one in each way,
company currency to foreign currency,
then foreign currency to company currency,
and some precision was lost in the process.
Instead of computing the debit or credit of the writeoff from
the payment difference, we now compute it from the
payment amount in the company currency minus the
invoice residual amount in the company currency,
to avoid the double currency computation rate,
so the precision is not lost in the process,
and the invoice move is finally fully reconciled
e.g.:
Invoice of 247590.40 FC
Payment of 267 USD (1 USD = 948 FC)
Payment difference: (247590,40 / 948) - 267 = -5.83 (Gain of 5.83 USD)
Before the revision, the credit of the writeoff was computed as:
`((247590,40 FC / 948) - 267 USD) * 948 = 5526,84`
After the revision, the credit of the writeoff is computed:
`247590.40 - (267 * 948) = 5525.6`
Notice in the first formula that the rate computation is performed two
times, once in each way (`/948` then `*948`), while only once
in the second, and this avoid the loss of 1.24 FC in the process.
Without this precise debit/credit of the writeoff, the invoice
could not be marked as fully paid, as the move was not fully
reconciled.
opw-687201
Due to the following revision:
bdf630f9b8
When creating an invoice from a purchase order with an
analytic account set, the analytic account was no longer
copied on the invoice, as the analytic account that was added
thanks to
https://github.com/odoo/odoo/blob/9.0/addons/purchase/invoice.py#L53
was overwritten with `False` as `rec` was False
or if `rec` was True, it was overwritten with the analytic account
of `rec`.
opw-697702
Step to reproduce the bug:
1) Create a payment term with two separated due type:
-Due type 1: percent , value 30, numbers of days: 0 days after the invoice date
-Due type 2: Balance; value 0, Number of days 0: Last day of following month
2) Create an invoice with the payment term
3) Refund the invoice with the option "cancel: create refund and reconcile"
or "Modify: create refund, reconcile and create a new draft invoice".
4) Error message: "You are trying to reconcile some entries that are already reconciled!"
But no payment had been received and the receivable accounts were still open.
opw:694386
If you create a delivery order without partner, its destination location
zone will be set to "Partner Locations / Vendors", which is not correct.
This is due to an error in the onchange_picking_type.
This commit fixes the issue by setting the destination location to
"Partner Locations / Customers". This change has not other implications
more than being consistent.
The pos loading crashes in the following scenario.
1. start selling a product (order line the localstorage)
2. archive or delete the product in backend
3. reload the pos session
The POS is interrupted with not much information.
Give an error a bit more meaningful.
Let’s say you have 10 units of products item1 and item2 in your stock.
If you create a sale order with two order lines: 1 item1 and 1 item2,
it’ll create one picking with two pack operations: 1 item1 and 1 item2.
Validate the picking, everything goes fine.
Now if you go back to the sale order and increase the quantity of the
two order lines, let’s say you sold now 2 item1 and 2 item2, it’ll
create two picking having each one a single pack operation: the first
with a pack operation for 1 unit of item1, the second one with a pack
operation of 1unit for item2.
The expected result would be that a single new picking with the two pack
operations is created.
This bug is due to the fact that there’s a check on sale order line
write that’ll call _action_procurement_create if you indeed increased
the quantity of any line. This method will at some point call
assign_picking on the model stock move. This method will try to find a
non-done picking with the same procurement group as the one we’re
working (the procurement group for our sale order). For the first write
on sale.order.line, it won’t find one because there aren’t, so it’ll
create one. For the second write on sale.order.line (so, for the second
line) it should find the picking created by the first write, but it
won’t and so it’ll create a second picking.
The fact that it didn't find the picking create by the previous line
is due to the fact that we do not update the computed fields
between write on a one2many field since rev 7b8afc2 and that “group_id”
on the model stock.picking is a computed field (a related).
As we prefer to keep the behavior of not recomputing the computed fields
between writes on a one2many (it’s a trade-off for performance reason,
except in edge cases the recomputation is useless), we explicitly
trigger the recomputation before looking for a candidate picking in the
stock.move action_assign, so that the next searchs on picking.group_id
will be succesful.
This commit also introduces a test for this case.
Closes#14718
When sending an email via the mail.compose wizard, the selected partners are
stored in the context (`active_ids`).
If the composed message is saved (button "save template"), the context is lost
in the _reopen action.
The active_ids content of the new context is the id of the newly created mail
template and is used as the id of a res.partner (sending the email to a
different contact).
Keep the context during the reopen to avoid losing active_ids.
Closes#11947
A manufacturing manager can unbuild an order without being an inventory manager.
The action unbuild only appears when the user is manufacturing manager.
opw:695734
Fix and issue is similar to odoo/odoo@1f06cc416
When clicking on delete icon before saving current list row edition (by
clicking outside the editable field), it could lead to traceback in some instances
because the deletion and saving are done concurrently.
closes#627
opw-695743
Jeremy Kersten