Remaining products :
- product_product_0 becomes service_order_01
- product_product_1b becomes service_cost_01
- product_product_43 becomes product_order_01
- product_product_47 becomes product_delivery_01
- prodcut_product becomes product_delivery_02
- Replace product_product_56 by service_delivery
- Replace product_product_59 by consu_delivery_01
- Replace product_product_58 by consu_delivery_02
- Replace product_product_57 by consu_delivery_03
Removed products :
- product_product_53, product_product_57, product_product_55, product_product_54, product_product_52,
product_product_51, product_product_50, product_product_48, product_product_46, product_product_32,
product_product_33, product_product_28, product_product_38, product_product_39, product_product_40,
product_product_41, product_product_34, product_product_29, product_product_30, product_product_44,
product_product_31, product_product_35, product_product_36, product_product_37, product_product_42,
product_product_45, product_product_49, product_product_26, product_product_14, product_product_15,
product_product_18, product_product_19, product_product_21, product_product_23
Removed corresponding binaries.
Removed all Bill of Materials demo data, that were ridiculous and replace them by 2 bom: A complete
computer, and a kit computer. Rewritten the tests accordingly.
Fixed tests :
- sale_mrp/test/cancellation_propagated.yml : The yaml ref function return a id, not a dictionnary
- sale_stock/tests/test_sale_stock.py : The service product invoiced on the delivered quantity was
in fact not invoiced on delivery on the test. As we are in sale_stock, Without timesheet, we
manually set the delivered qty for the product serv_del. If we don't do this, the invoice will
never be fully invoiced.
- The pricelist rules choice is not based on the sequence anymore (Seems to be a bug, reported to
online). By the way, I changed the product to avoid the overlap.
- sale_mrp/test/sale_mrp.yml: The yaml ref function return a id, not a dictionnary
- mrp : Rewritten the tests to be coherent with the new bom data
As procurement_jit has been optimized (by running multiple procurements at once),
it does not make sense to still have a module that without it, does not generate Pick > Pack > Ship
automatically, but only Ship. We can do it anyways.
That way, the procurement_jit module can become clearer in its functionality to the user: when
a sale order is confirmed, it will automatically reserve the picking from the stock location (in case of MTS)
and people who don't want that functionality can still immediately have the Pick > Pack > Ship.
Make sure also push_apply works with manually created pickings.
Yannick Tivisse