The code was wrongly always taking the reserved quantity on the already
returned moves, but if they're done their value is zero.
task-2291973
closesodoo/odoo#54807
X-original-commit: 7b08f0ae0a39e8f575b21e744de16264b6365704
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Write is overridden on reserved move lines to make sure the quants are
correctly updated. It is divided in two parts: if you update the reserved
quantity and if you update a characteristic. If somehow both are updated
in the same call (which doesn't happen in the standard interface), then
the quants are unreserved two times, which is wrong.
This issue showcased by [0] and on databases where the reserved
quantities are made editable by customization.
We grouped the two update in one, such as the TODO indicated us since a
long, long time.
We removed `result_packaged_id` from the trigger because it should not
impact the reservation whatsoever.
We needed to remove a tricky logic in the stock move's backordering part
but it was fishy anyway.
[0] eac8c06e2233
closesodoo/odoo#53928
X-original-commit: 507101434f9221f2cfa6de66e1952676fff322fd
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Bunch of last minute fixes including:
- serial handling in tablet view
- expected durations and backorders
- button unplan unlinks the leave but the computed aren't recomputed
then we need to manually set the date_planned_start/finished
then we need to not propagate them on the related document
(move/production) because they are required
- operation company_id wrongly set
task-2241471
Following v13, newId records are instances of NewID and are ignored from
any `read_group` call. This breaks an important feature: when encoding a
stock move line (thus, in an onchange context), the `quantity_done` field
of stock move should be recomputed.
task-2241471
Set the operations directly on the Bill of Material.
Duplicate the demo data where a routing was shared.
Adapt the tests.
Remove the following feature:
- set the same routing on parent and kit child bom
- when planning, if the component of the kit have the same operation
than a component of the parent bom, merge these operations
task-2241471
1. Activate receipt in 3 steps
2. Make a PO of 50
3. Receive 20 (pick 1), backorder
4. Receive 29 (pick 2), backorder
5. Receive 1 (pick 3)
6. Transfer to quality check location 45 (pick 4), backorder (pick 5)
7. Go to pick 5, unreserve the quantity
8. Go to pick 3, return 1 => the quantity suggested by the return wizard is 1
The return is not able to reserve the necessary quantity.
This happens because 45 units are considerd out (from pick 4), but only
1 unit is considered in (pick 3). Therefore, in the following:
https://github.com/odoo/odoo/blob/23511dffb9e3f597a7df9bb834d008f74abb07b8/addons/stock/models/stock_move.py#L1276
we have `quantity = -44.0` and `available_quantity = 5.0`, so we can't
reserve.
We count as `move_orig_ids` all the siblings coming from
`move_dest_ids`.
opw-2261473
closesodoo/odoo#52084
X-original-commit: ba89e26750baab2309cccc4ffd0b3ade804d19ce
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Check backorder is divided in 3 blocks:
1) quantities on move lines linked to a move
2) quantities on move lines without moves nor products but with a
package
3) quantities on move lines without moves but with a product
1) added quantities in the move's uom, 2) added quantitis in the product
uom, 3) doesn't seem to be used (and shouldn't be). Clarify all of that.
task-2239964
closesodoo/odoo#49790
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Unlinking a return line is convenient and should be allowed for stock
user. Note that the same functionality could be achieved by setting the
quantity to 0 on the line.
related to 65530dfd6aclosesodoo/odoo#48988
X-original-commit: dc77519066993ed245ef863cdf42f6c25e10c99c
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
If you create a quant through the inventory mode of the list view and
you don't set a quantity, the quantity is null and the quant isn't
unlinked by _unlink_zero_quants.
Also consider null quantity as 0.
We don't have the issue for the reserved_quantity field since this one
is not nullable.
closesodoo/odoo#48005
X-original-commit: 08e428458aa545b3602c56b6866a447126cf8825
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Due to a typo, dropshipping sequences were created twice. We created a
"stock.dropshipping" sequence if no "stock.dropshippping" sequence was
found.
closesodoo/odoo#47908
X-original-commit: 021268734a5857f47cda5991fbd28abdd41f512a
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
At the moment, when a rule has a supply method "Take from stock, if
unavailable, trigger another rule", it is displayed as a "take from
stock" rule
In order to differentiate the rule supply method, we should rather show,
thanks to a vertical bar, when a rule is in take from stock, and use
both a vertical bar and the three dots when it is in "take from stock,
if unavailable, trigger another rule"
task-2205748
closesodoo/odoo#47541
X-original-commit: e1c1093c3d5fb7be69e8d1d26bcac184b5dc07b2
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Validating a receipt of 90 stock moves having ~300k products in the
database goes from 7 minutes to 11 seconds thanks to the addition of
"active_test=False in the context before doing the searches on valuation
layers.
Most searches on "stock.valuation.layer" are done when validating a
move, but since this model contains an active field, the orm will
pathologically complete the searches expression by adding "id in active"
products. If the list is long, it slows down everything.
Since this field was only added to have a filter on the valuation
reports, it doesn't matter at all to ignore it in "_action_done".
It would probably have been cleaner to just remove the field but it
doesn't fit the stable policy. Nevertheless, we're going to remove the
field in master with task-2178269, as well as this patch.
opw-2209797
closesodoo/odoo#47523
X-original-commit: 466a8319547e11e2193dd8594b0e50e3c27d4b3e
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Issue: on main product's kanban, if you group by categories, all
categories (even the empty ones) appear. This is not desired.
We only wanted this group_expand logic when using the products stat
button on the product category form view.
closesodoo/odoo#46966
X-original-commit: e3f1254e5b28aa801f137835d871427786fb3428
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Set the following product configuration:
Storable finished product with a flexible BOM made of storable
components in manufacture + MTO:
Component choice 1 Quantity = 0
with BOM made of component 1, quantity 1 with purchase mto route
Component choice 2 Quantity = 0
with BOM made of component 2, quantity 1 with purchase mto route
Create a MO for finished product, set the "to consume" quantity of
"Component choice 1" to 1, and try to mark it as to do. The following
issue is raised: The quantity to produce must be positive!
This is because a procurement with 0 quantity will be solved in a MO
producing 0 quantity. We fix this issue by ignoring procurements with 0
quantities.
Also, this MO without initial demand is not considered assigned. We fix
this issue by considering 0 move as assigned.
task-2159374
closesodoo/odoo#45552
X-original-commit: dffb3a1f2762d6e1517eb9b7d225521f99d874d5
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
since it is now implemented by 020e2a5e85closesodoo/odoo#45309
X-original-commit: d8c916112aa943712bbb93f1aa1ac59da2aa9524
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
We chose the vendors by searching random res.partner but sometimes
partners of another company are returned, making the _check_company
mechanism raise an error.
closesodoo/odoo#44815
X-original-commit: 1cfcf21efa888720f9c34b337532251db6fd0089
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
in anglo saxon accounting
- receipt products through an rfq
- when creating the vendor bill of the rfq, directly add a landed costs
product
- post the vendor bill then create the landed cost, validate the landed
cost
- the aml of the LC is not reconciled with the aml of the vendor bill
for the lc product because the "You are trying to reconcile some
entries that are already reconciled." error.
We fix this by filtering out the already reconciled aml.
Not that the flow is behaving as expected if the landed cost is created
in another vendor bill, such as the tests were doing. We thus add
another test.
opw-2184988
X-original-commit: 1e78527ac5295563e9610ad9ddd98834998285f3
Don't ignore correction layers when computing the anglo saxon price
unit. We use the `stock_valuation_layer_id` field on the layer to point
the correction layer to the corrected layer. When computing the average
price of the delivered things, ignore correction entry but take them
into account when choosing a corrected entry.
opw-2179900
closesodoo/odoo#44774
X-original-commit: 3831649b81c1271977730cdf46100f814687af61
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Stock moves records can be unlinked in some cases, for example when
confirming a move containing a kit, the original move is unlinked and
replaced by the moves of the components of the kit.
This commit adds two indices to accelerate the unlink of stock move
records. The fields were the indices are added are foreign key on stock
move, and postgres checks the foreign keys of the rows before deleting
them.
closesodoo/odoo#44426
X-original-commit: e34a176dd438fe0f4f1a384889bfdc196f2c4b4f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
We check the selected pickings are compatible to be attached to an
existing batch transfer.
We add the possibility to create on the fly a batch picking to attach
the selected pickings.
task-2069646
Only keep buttons in the header to be able to disable them with an xpath
without breaking every attrs elsewhere in the form.
Why? We want to disable these header buttons when opening a picking from
the bach transfer (by clicking on a line on a o2m list).
task-2069646
Enteprrise pr 6836 will allow disabling the delete button on gantt
views. Document it is possible.
task-2088954
closesodoo/odoo#40716
Related: odoo/enterprise#6836
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
With a product configured as buy on order and a warehouse configured as
receipt in two steps, if the user increases the quantity on a po line
generated by a sale order before confirming it, the system will send all
the quantity to input but only the ordered quantity to customer. The
issue is that the "extra quantity" will stay in input.
We fix this issue by creating a new move with the extra quantity to the
input location so that push rules will send the extra quantity to stock
while the ordered quantity will be sent to the customer.
There was also an issue when incrementing the quantity on the po line
after confirmation if the po line was the result of a reordering rule:
only a move from supplier to the location of the reordering rule was
created.
This commit also introduces a change of semantic:
`created_purchase_line_id` is cleared after confirming the RFQ. This
allows to merge more in `_merge_moves`.
task-1981355
closesodoo/odoo#43545
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When a move is created through a push rule, the system will first try to
find a picking to put it into before creating a new one. It is possible
the move is placed into an immediate picking where the reservation
fields are hidden and the initial demand is updated according to the
qty_done with [0].
As this behaviour is unwanted, do not merge move into immediate
transfers (which should be short-lived anyway).
[0] 8303b1a69eclosesodoo/odoo#44086
X-original-commit: fa9efd28e6e113cd9993a29bca070ddee83630c0
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- move all the constrains at the same place, make sure they are private
- move all the onchanges at the same place, make sure they are private
- move `_get_similar_move_lines` helper at the bottom of the file with
the other helpers
The previous domain was too naive: a receipt is not always valued
(inter-warehouse transfer) and even a receipt that should be valued
isn't always (receive goods you do not own, change your config from
manual to automated and then apply the lc on an old receipt, etc.)
Enforce a domain making sure the transfer is valued.
related opw-2165697
task-2169844
closesodoo/odoo#43410
X-original-commit: c6aa61b22a18c3f110baa7ed3c97e275b21e5329
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce:
Create one product with FIFO and automatic inventory valuation.
Purchase product with 10 quantity and cost price 100 and mark shipment as done.
Add landed cost for done incoming shipment with 2 cost lines
E.g. 1. Freight Charges - 100
2. Duty and Charges - 50
So ideally after first outgoing shipment total cost should get updated in product is
(1000 + 100 + 50) / 10 which is 115
The issue is that we increment `remaining_value` on the wrong layer.
Fixes#41923
task-2167659
closesodoo/odoo#42871
X-original-commit: 8b89a5e4a85071055bc152b11cf150e62a5c5211
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This reverts commit d39a51259e93b84184379a1fc9b824dad94e5ea5.
This view was technically clean and useful to detect configuration
issues (wrong view_location_id for example) but was not liked by our big
boss because "a group by parent_id does the same thing".
task-2166904
closesodoo/odoo#42734
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
missing bit from rev[0] and [1]
[0] 7ef11e3
[1] d6c8c34ef6539dad110f1e502eaee2c03d968797
closesodoo/odoo#42621
X-original-commit: 5096e724643ca77568ce2f09a40b138561f4c20f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
missing bit from rev[0]
[0] 7ef11e3c96closesodoo/odoo#42517
X-original-commit: 8ff69abc9010bb2aa05dea5a5f2e1fa545e6179c
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Running the vacuum in avco indeed fixed the estimated value on the
delivery but it did not update the standard price afterwards, making it
possible to have an inconsistent standard price with the actual value in
stock, as described in [0] and in the task [1].
A test was added (and validated) in the layers test file and an two old
one were fixed. test_average_perpetual_2 displayed also a different
missing bit: the vacuum should run when the user unlock and increments a
receipt.
[0] https://github.com/odoo/odoo/pull/41669
[1] 2154638
closesodoo/odoo#42292
X-original-commit: 6e4c9b8219db0c94c29f5ee145998e6f1597bb55
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
rev[0] aimed to fix an intercompany reservation issue by allowing the
intercompany moves to be seen, however the new domain was too soft and
also allows the visibility of any moves going to a location without
company, for example now outgoing moves to customer from all companies
are visible.
We strengthen the domain to only allow intercompany moves, ie we add the
transit constraint in the domain.
We also fix the same issue for the move line model (see [1])
Now that this one is fixed, the next move is automatically reserved
during _action_done. This didn't work either, so we carefully sudo and
force_company on the destination move.
[0] 3c4bb080c3
[1] f9461c7096a65565a05136a4c6c42ddfa6881926
task-2157248
closesodoo/odoo#42270
X-original-commit: 9a237d1af79519665d0895a30c9ce55a1d835918
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
date help: "Move date: scheduled date until move is done, then date of actual move processing")
As this behaviour is also wanted when the onchange mechanism do not work
(ie in a manufacturing order move raw and finished), we move it to write.
task-2154781
Edit the liters uom (default in its category) and change its category to
unit. You now have two references uom in the unit category. Try to set a
third one and now it fails.
This was because the constraint is implemented with an sql query but
since the new ORM the update in database are delayed. We force a
database update with flush so that the query gant get all the
informations it needs.
closesodoo/odoo#41621
X-original-commit: 68ced7972db64b22a4ff031bba0f78c06a88372d
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When returning a delivery where the value was taken from different
receipt, the last receipt's unit cost was wrongly used when returning
the delivery.
Now we use the `unit_cost` of the delivery when returning it.
task-2150889
closesodoo/odoo#41564
X-original-commit: 468ab4f23c8212e1aba21197b3f83afe741b3d9e
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
followup of rev [0]
If these wizards are called on multiple pickings, display the list of
the pickings that could be impacted and allow to select which one should
be impacted.
We also adapt the sanity checks at the start of `button_validte` in
order to specify the concerned pickings if needed. We do not enable the
multi behavior for batch at the moment, so it's only enabled for the
validate multi in the list view.
[0] 6ab4b0d496
task-2069646
closesodoo/odoo#41497
X-original-commit: ff276c6484b138982f185ec9c832f2dbf25baaef
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Writing barcode on a template will only write it on the variants if the
variant count is 1. Make the field readonly on the view according to
this condition.
closesodoo/odoo#41489
X-original-commit: a67ad076f4c079f33602f01ed2b8cbf741aeffc5
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- we would have to set this domain on every actions directing to
products
-we can't set a proper depends_context since the new orm doesn't support
it
closesodoo/odoo#41322
Related: odoo/enterprise#7033
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This context key was used to get the valued quantities. We now have a
`quantity_svl` computed field that does this job. The test is removed,
it was showing that intercompany quants are visible thanks to a context
key but with the introduction of the on_hand filter, it is now useless
(just remove the filter)
Instead of hardcoding a domain in the action, we add a field that will
be used to apply the domain. The goal is to be able to define a static
domain in the xml so we'll be able to default on the filter while still
being able to remove it.
Let's consider this usecase:
Physical
| \
WH Subcontracting
| |
Stock 5 units
|
10 units
With the hardcoded domain, we have two problems
- the right part of the tree isn't visible
- the user can add a quant in subcontracting but it will disappear at
the creation since it isn't part of the hardcoded domain.
The complicated part of the domain is the `_get_domain_locations` call.
It will use multiple context keys, the current company and get the
hierarchy of internal locations below warehouses to see what it should
include or not.
To be able to remove a domain, it should be declared in the xml and not
hardcoded in the action. Since the domain is complex, we can't express
it. So we add a computed field "on_hand" and its search method is
overiden to call `_get_domain_locations`.
task-2061825
closesodoo/odoo#40403
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
On a quotation, the forecast report is opened with a default filter on
the warehouse of the quotation. If you remove this filter, quantities
not below warehouses (eg in subcontracting or in a repair location) are
displayed. From the product form, it's not the case, you never see these
quantities. We now add a "warehouse is set" filter that is enabled by
default (so you have the same value in the stat button forecast and in
opening the report) but you can remove it to see all quantities.
task-2061825
- the oderpoint_id field on the purchase order line wasn't used to not
merge the po lines
- if the orderpoint_id field is set, use the orderpoint location to
create the move
- if multiple stock moves with different source locations go through
`_merge_moves`, they should obviously NOT be merged
- `virtual_available` computed field was not being invalidated when the
context keys "warehouse" and "location" changed
task-2001462
closesodoo/odoo#40573
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This field was deemed redundant and thus removed from the view but we
forgot the use case where multiple valuation adjustment lines are
generated (eg applying a lc on multiple pickings) and the added value
by picking must be adapted manually (eg decrease one to increase the
other).
task-2125127
closesodoo/odoo#40454
X-original-commit: 3e6d6315adf1c33ec3fd5eb106defb0c80d7290b
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Issue: create an immediate transfer, add a move and a done quantity, the
picking is in waiting state instead of ready.
Due to rev[0], the moves added in an immediate transfer have an initial
demand. After auto-confirming them, their state were 'confirmed' and not
'assigned'.
Solution: we force the state to assigned
[0] 8303b1a69eclosesodoo/odoo#39492
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this patch, move added in a planned transfer once it is ready are
directly marked as assigned and the reservation is disabled on them.
People found it hard to understand why the check availability button did
not appear, plus the push rules were not applied.
Now we chose to use the autoconfirm mechanism on the added move and we
don't reserve them, so the check availability button reappear.
task-2081844
Make sure to update the standard price with the computed unit cost of
the candidate and not its `unit_cost` field, as the computed could
contain an extra value from a landed cost.
closesodoo/odoo#40208
X-original-commit: 9234ea1e32609ee7b5c22b836c33eefa20220d37
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
So we have to adapt
- the sanity checks
- the immediate/backorder wizards
- split the call to _action_done with and without backorder
This is a preliminary work to remove all the override in
stock_picking_batch and to allow choosing the pickings to immediate or
backorder directly in the wizards.
Before this commit, both wizards were calling _action_done and one
another. We make them go back through `button_validate` so that it is
more sane to handle and allow future extensions to add pre-action done
wizards.
Also the first part of button_validate is some sanity check. We adapt
them to be multi (inside of a loop over self) without any other
changes.
Now the wizard can work on the records (immediate: write the done
quantities) or work with the context (backorder: picking ids to not
backorder in the context).
Also we adapt the stock sms weird wizard (a confirmation wizard but the
feature is auto installed? wth). Now there it isn't manually called in
the middle of button_validate but it uses the pre_action_done_hook.
task-2069646
This reverts commit 3431d7b1cd.
Due to recent changes in the orm, editing a draft move crashes. We
revert this commit while we find a proper fix.
closesodoo/odoo#37752
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Two testcases failed when ran at 23h59 and 50 seconds because of a wrong
order on date.
closesodoo/odoo#37599
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
rev[0] writes the qty done on the move lines directly in put_in_pack,
meaning hitting discard in the delivery wizard left the move lines with
a changed qty_done. We fix that by editing the quantities in
_put_in_pack in the stock module and getting the right move lines in the
delivery modules: meaning, get the normal or suggested ones (a fix
missed by rev[1]) then with quantities or 0 quantities.
[0] e03c1a836f
[1] f6d88a2e8dclosesodoo/odoo#37563
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This reverts commit 42834e4eb3.
finished_workorder_line_ids contains finished products and by products.
Naming the section by-products is not clear when the settings isn't
enabled.
closesodoo/odoo#37588
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Implement group_expand for workcenter_id so that all workcenters are
visible in the planning by workcenter gantt.
Implement some constraint on write because anything can be moved in the
gantt view.
When changing the workcenter of a workorder, make sure the leave is now
set on the new workcenter.
closesodoo/odoo#37386
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When a BoM was composed of a phantom BoM, there was mutliple bugs:
- if not routing was set on the phantom BoM, the components were never
consumed
- if no operation was set on the BoM, its components were to be consumed
on the last workorder of the BoM and of the phantom BoM.
closesodoo/odoo#37304
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Remove the "sale.group_sale_order_dates" group and settings, all the date
fields are always displayed but we put schedule_date and commitment_date
(for which the label was renamed "delivery date") on the same line (with
a design to make the schedule date looks like a suggestion for the
delivery date).
task 2057802
closesodoo/odoo#37174
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
If it isn't set manually, it defaults to now and the result is not
consistent with planned date end. We make it an hour before totally
subjectively.
closesodoo/odoo#37173
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The landed cost model is limited to the warehouse manager, so displaying
the view changes on account move did not make sense for all users plus
it broke the creation of invoices for account users.
closesodoo/odoo#36914
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Using classes and inline style break the list view if the button has a
0 width
closesodoo/odoo#36443
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Give to a regular mrp user the same access rules than he has on
production orders.
closesodoo/odoo#36883
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When a blanket order is opened, a supplier info is created and should be
used in priority over a regular supplier info with the same values.
That's what rev [0] tried to do but there was some mistakes: the
`purchase_requisition_id` field added in the order is ignored since it
isn't stored and the test didn't failed because the created blanket has
a lower price unit than the regular supplier info, meaning it is used in
priority. Setting the same price unit (50) result in the new purchase
order line merged in the first one.
Do not re-implement the same order.
Adapt the test now that we know the order didn't work (see rev[1]). The
user has to manually set a higher priority to the supplier info
generated by the purchase requisition.
[0] e85838d358
[1] 2ac4f2ee0fclosesodoo/odoo#36840
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
With the new ORM, x2m records are not ordered by default.
The _select_sellers implementation requires to loop on the supplier info
records ordered by their _order. We fix that by sorting with a lambda
with the same order set on the model. Simply using .sorted() isn't
enough since it does a sort in sql, so newId records are completely
removed from the resulting recordset.
This is related to task 1947351 and PR 34049.
We move the tests into purchase_stock and actually implement the tests
proposed in the task.
rev[0] added the possibility to put in pack without setting any done
quantity on move lines but when the reserved move lines are hidden
(thanks to rev[1]) it got confused on which move lines to work on.
[0] e03c1a836f
[1] ffd5d5a097closesodoo/odoo#36832
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
rev [0] was incomplete, the
possible_bom_product_template_attribute_value_ids field was not computed
in mobile because parent_product_tmpl_id was not sent to the server.
rev[1] broke the normal produce wizard
[0] 5d5644c721
[1] 916b49381bclosesodoo/odoo#36595
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Simon Lejeune