| Age | Commit message (Collapse) | Author |
|---|
|
- Create 3 products A, B & C
A is in Units
B is in kg
C is in m
- Create a BOM kit for A using 1 kg of B and 1 m of C
- Create a PO for A, validate
- Receive the picking
An error is raised: "Conversion from Product UoM ... to Default UoM ...
is not possible as they both belong to different Category!."
It happens because `_compute_qty_received` incorrectly converts
quantities.
The computation of the quantity received for kits is done in 2 steps:
first we compute the quantity the same way we do it for a regular
product, then we overwrite the quantity with the value computed for
kits.
We can compute the quantity correctly at once by calling `super` only on
lines which are not kits.
opw-2302807
closes odoo/odoo#55047
X-original-commit: b82f71dac9452de9c1e16cde552fe260fec3c262
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closes odoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
task-2241471
|
|
Allow to "backorder" a production, meaning create another manufacturing
order with the quantity remaining to produce. We also use the
reservation of the first order on the next ones by using
`post_inventory` on the first one and moving the newly created stock
moves to the backorder.
We introduce a wizard similar to the one in stock.
Backorders have a sub-sequence.
Backorders are linked together through the procurement group.
We allow creating a backorder even if workorders are running by closing
them, the backorder will call `button_plan` and create its own.
task-2241471
|
|
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
closes odoo/odoo#43545
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
|
|
In case of MTO (+buy) on products used in a MO,
add the link between the MO source and the PO generated.
Also add links between MO's when MTO+manufacturing.
task-1913392
closes odoo/odoo#43366
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
|
|
Commit e923058 aims to ensure the key 'created_purchase_line_id is
returned only if the move as this field filled. The issue is due to
the way python compare falsy object.
a = b and c will return b (not False) if b is falsy
will return c if neither b nor c are falsy.
If move_raw_id passed in the method doesn't have created_purchase_line_id
iterate_key = purchase.line.id() or 'created_purchase_line_id'
= purchase.line.id()
which is not correct as the method should return a string or False.
closes odoo/odoo#43320
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
|
|
closes odoo/odoo#41115
Related: odoo/enterprise#7177
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
|
|
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
|
|
This commit generalize the method made for computing the quantity delivered in a sale order
in order to be used for the quantity received for a kit in a purchase order.
TaskID: 1929518
|
|
This commit refactors the method '_bom_find' in order to search bom based on their type.
This allows to handle the cases where a Kit has the route 'Manufacture' set.
TaskID: 1863856
|
|
With this commit, when a kit is processed trough an immediate transfer,
the quantity done set on the kit is now propagated to its components.
TaskID: 1896772
closes odoo/odoo#28998
|
|
The received quantity on Purchase Order line can be compared
to the delivered qty on Sales Order line. It is now time for
both to share the same mecanism (introduced in
3bf8a62e0dd99f7dad42718f895abf4fd53f996f).
This commit sets `qty_received` as a computed field, depending
of a method (`qty_received_method` field) to compute it. The
value can be computed based on
- manual value; for services (all the time), and consummable
products (when stock is not installed).
- stock moves; for stockable and consummable products (when
stock is installed)
This is now easier to extend the way the received quantity
need to be computed (like in sale).
Task #1850689
closes odoo/odoo#27663
|
|
|
|
|
|
Steps to reproduce the bug:
- Create Product P: with BOM type - Kit and BOM components > Set - Invoicing: on delivered quantity
- Create PO with P and confirm - shipment 1 will be generated
- Cancel the PO - shipment 1 - will also get canceled
- Reset the canceled PO to quotation and confirm it - new shipment 2 will be generated
- Validate the shipment and receive product KIT
Bug:
Check PO - 'Received Qty' was not updated
Inspired from: https://github.com/odoo/odoo/commit/c2dfdc3081764a492a94024f1fb57e15636b04c9
opw:1889303
closes odoo/odoo#27622
|
|
Pickings/MO/SO/PO can be linked. Only the increased quantity is
propagated between documents. However their ordered quantities can
also be decrease or they can be cancel. In this case an activity
is created on impacted documents in order to describe the situation
and inform the user that a manual action is probably require.
Also in order to propagate the increased quantity from a MO, we have
to do important modification in MRP and we want to avoid doing it before a
major release. That's why increased quantity on a MO also work with
activity at the moment.
|
|
Steps to reproduce the issue:
- change the demo user settings -> use Sales: User: All Documents only
- create a stockable product with dropship feature on and a supplier
- connect as the demo user
- create a sales order with this product
- confirm the order
- as the admin user, confirm the purchase order generated through dropship
- connect as the demo user
- open the confirmed SO
- add a line with this product
- save the SO
Bug:
An access rights error was raised.
opw:1866015
|
|
|
|
When confirming a move for a kit, it is basically unlinked and replaced
by moves for its component. The link to the purchase line was kept in
v10, but since rev[1] it is not anymore. Make an helper to get the
values and override it in purchase_mrp to add the purchase line link.
[1] https://github.com/odoo/odoo/commit/8248f0e153ae5fcc1449d0d05149b61df615ad4f
opw 779497
|
|
When we purchase products of type services,the received quantity is
always set to the ordered quantity.
We want to be able to manually enter a received quantity on service
products to have a better trace of what have been received or not.
We show the picking stat button olnly if there are picking
We show the columns qty_received, qty_invoiced and invoice_status
depending on the parent state, and not depending on the context passed
in the menu item.
|
|
* LDAP import: python-ldap is not python3-compatible, pyldap is
Warning: only supported from debian Stretch (current testing)?
https://packages.debian.org/search?searchon=names&keywords=pyldap
* implicitly relative imports
* imports of moved or removed stdlib modules
issue #8530
|
|
- Create a manufactured Product A (sold as kit), invoicing based on
delivered quantity.
- Create the associated BOM, e.g. contains 2 Products B.
- Create a SO with Product A, validate
- Change the BOM so it contains 2 Products C
- Validate the picking linked to the SO
The delivered quantity is not updated since the delivered products (B)
are not the same than the products of the BOM.
This should not be the case. Changing a BOM should not affect the
invoicing. To solve this, we simplify the check and only verifies that
all moves are done.
The same change is applied for PO.
|
|
|
|
In previous versions, the quantity passed to the bom_explode was the number
of times you needed to count the BoM. If the BoM was for 2 dozens and you pass
48 units, 2 was passed to the bom_explode method. We are now doing the same
for the explode method and we check it is called this way everywhere.
|
|
product_uom._compute_quantity is an ensure one multi method taking a browse
record as second paramter. It replaces _compute_qty and _compute_qty_obj
to have a single and standard computation method.
|
|
This commit contains the core of the new MRP. It contains a whole refactoring
of the MRP application, with improved and new features, written in new API.
Among other here are the main manufacturing workflow improvements :
- Picking type not only for pickings but also for manufacturing orders
- Properties replaced by picking type
- BoM can only be produced with its routing (no other)
- Either produce without routing with only production orders, or produce with
routing
- By default, there is an order in the work orders (serially), but you can
override it to be able to work in parallel
- Time clocking on work orders and block time on work centers with reporting
on OEE, performance, losses, ...
- Real-time adaptation of timings on operations
- Lots/serial numbers can be inputted like in the pickings on manufacturing
orders. It is also possible to input them in the work orders.
- Material availability independent of production order state (possibility to
start production when only part of it is there)
- Work sheets on work orders
- Put messages on work orders to make your workers pay attention to something
- Full traceability link to see for each produced piece of stock, the
consumed pieces, ...
- Separate scrap object (a scrap is not done based on an original move
anymore)
- Separate unbuild system (if you want to unbuild into its original
components)
Thanks to all people that helped during this development, notably but not
limited to Chirag A Dodiya (cod@odoo.com), Gaurav Panchal (gan@odoo.com),
Jignesh Rathod (jir@odoo.com), Mansi Trivedi (mtr@odoo.com), Pariket Trivedi
(ptr@odoo.com).
|
