Community mailing list archives
Re: Make to order business case design problem V8by
If a user decides they want to cancel this reservation and assign it to another delivery order, IMO the moves should not go back to a waiting state. They should go to waiting availability, and the delivery order should pool future availability from whats in the warehouse. The problem caused by the current design is if a user cancels availability then assigns it to another order, the link becomes broken and the move is infinitely stuck in waiting another operation. When you request availability after you assigned the inventory to another order, the history linkage on stock.quant is already broken so it never assigns it again.
I hope I explained this clearly.
I spoke too soon. The assignment has already taken place when the lines are iterated over in do_transfer(). Doing the same test fix in method recompute_remaining_qty() instead of do_transfer gives the desired result. Example below
sorted_moves = sorted(picking.move_lines, key=lambda id: id['product_qty'])
for move in sorted_moves:On Sat, Dec 13, 2014 at 5:16 PM, OpenERP Master <email@example.com> wrote:Fabien,It says in the removal strategy section:
Thank you for the response. I appreciate hearing for you.
First, my email has several different issues. I will focus on one. When I receive m2o goods from a vendor, I want the inventory to assign to waiting delivery orders based on the m2o items ability to ship complete first. The other part of the problem where an entire order should become available based on ship complete first out is an entirely different issue, which I will not talk about here for now.
I took the time to think about this problem. I found documentation about the 8.0 WMS here: https://docs.google.com/document/d/1jTLZJNV14saRn1VeZt_wME18YizEnEHB9ZX97WSqavs/edit#
Note that a “waiting” move is automatically converted into “assigned” without going through removal strategies when the linked move is done. (because the source is the one of the linked move, no need to compute anything).
"""I spent a couple of hours studying the code. Here is my documentation of how receiving works.
When you press receive in the UI it calls method do_enter_transfer_details() which shows the user a combined total quantity needing to be received. After the user presses validate eventually method do_transfer() is called on stock_picking. Since the actual quantity per order is already separate on the purchase order receipt, the system assigns the inventory in a FIFO (order of first created stock moves).All I need to do to solve this portion of the problem is order the move_lines by quantity ascending as it iterates over them. This will ensure the greatest likely chance that an order that can be fulfilled first will be. I do not believe there is any other possible way to accomplish this since the decision to complete a purchase receipt move happens in do_transfer() before any other method is called. To even take this a step further, one could analyze the entire order availability to be fulfilled before making the decision, but ill leave that for phase 2.The other problems I mentioned in the email about reservation are still serious concerns for me. I confirmed these issues in a test database. Once you cancel the reservation on a linked waiting move that has been assigned, it is never possible to get a new assignment unless you force availability. I will continue to look into this issue and report when I have a solution.Finally, I will possibly develop such easy module that does Ship Complete First Out. I think a lot of companies could benefit from it.
ThanksOn Sat, Dec 13, 2014 at 2:12 AM, Fabien Pinckaers <firstname.lastname@example.org> wrote:
The code of Odoo V8 has been made so that it's easy to extend and add a procurement method. If I remember well, you just have one small method to overwrite if you want another procurement method than fifo.
Then, just add a "First In Full filled First Out" or "Biggest Fulfilled First Out".On Dec 13, 2014 8:53 AM, "OpenERP Master" <email@example.com> wrote:My customer does a make to order sales order over 70% of the time, meaning that they sell product that they do not carry stock. They order this product from the manufacturer after the customer pays. Once it is received it is shipped to the customer.Customer orders item A at 3 quantity (make to order)
At first I praise the new procurement design over previous versions, now I think it could be trouble. See the following business case for V8.Different Customer orders item A at 2 quantity (make to order)*Note the order in which the orders were placed, this is important
quotation purchase order is created for 5 quantity. Business confirms they need 5 units to fulfill both orders.
Vendor only sends 2 quantity.in Odoo, when we received the 2 sent quantity it is assigned to the first order (FIFO) (Customer ordered 3), but this is not sufficient quantity to fulfill the order, however the second order placed the quantity would be sufficient.This business wants to ship what can ship complete, not necessarily what came in first.
Problem: There appears to be no way to support assigning product to a delivery order based on its ability to completely fulfill. Furthermore, the delivery becomes split into 2 lines. the 2 quantity that is available as reserved, the other quantity of 1 as waiting other operation. I do not like this behavior.Secondary problem: The business wants to cancel the availability on the delivery order that Odoo assigned the inventory to and assign it to the order that can be fulfilled complete (Qty 2). This appears not possible. If you cancel the reservation, there is no way to assign the availability to the other order without clicking force availability. IMO, even if it is a M2O, and there is sufficient stock and a user requests an availability check, it should check the warehouse for available inventory.Additionally, once you cancel the availability on a received make to order, it never reassigns availability, and subsequent requests to check availability or running schedulers does not re-assign the canceled inventory. The only way to get past this is to force availability. IMO there is a pretty big issue here, but these are some case scenarios perhaps not many people have.Looking for some feedback.