Community mailing list archives
Re: Make to order business case design problem V8by
On 15 Dec 2014, at 13:22, OpenERP Master <firstname.lastname@example.org> wrote:I already solve the issue for myself so I have no further problem, but again this is my opinion on how make to order transactions should work, which will not work with 100% of all companies business cases. Perhaps it could be a configuration option for non manufacturing based transactions.All of this aside, the current design allows the possibility of corrupting a workflow which will result in a move stuck infinitely in waiting another operation. IMO, the system should be smarter to prevent such a problem.Hi,Companies sell a product to a customer that is "Never" intentionally stocked, it is always ordered. It is not manufacturing at all. Just because the product is special ordered, doesnt mean this is the only way to obtain the product. If a previous customer returned a product, then you have it in stock, or the situation I described where multiple simultaneous orders for the product, you want to decide instead of the system which order the inventory goes to when it is received.
I do not completely understand your response. I understand well the difference between make to stock and make to order. Actually this case I described is common,On Mon, Dec 15, 2014 at 4:12 AM, Eva Pinter <email@example.com> wrote:Hello OpenERP Master,The main issue that you have in your process is that you are mixing make to stock and make to order. In the make2order, you either buy or produce for a specific customer order. In the description you have written, this is a standard case of make2stock. You just want to purchase based on the existing sales orders. This is a classical MRP case. The only problem we have is that Odoo does only support Mini/Maxi for MRP method, meaning that the only reason for the system to automatically purchase, is when the stock is below a certain quantity and the proposed purchased quantity is to fill the stock to the maximum in the reordering rule.To play with M2O and then reassign the stock is, from a process point of you, not the way to go. It would be much better to extend the reordering rules to consider for some product a purchase order based on the existing missing quantities from the sales orders. This would be a standard logistics process. I’m not an Odoo developer, so I cannot define, if this is a big task to do, but I believe to have at least these two types of reordering rules would solve the problem, not only for you, but for many customers struggling to purchase based on the sales order quantities and the stock.I hope it helpsGood luckEva P.See the action happening during cancel of the linked reservation: https://github.com/odoo/odoo/blob/8.0/addons/stock/stock.py#L1830When a supplier receipt is made, it will automatically make the ancestor moves available. From a high level, product was received in the warehouse and assigned to the sales order that created it. IMO at this point, the M2O transaction is complete.Update:I was able to find an acceptable solution to the linked move waiting another operation problem. (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)
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.Problem caused when you try to request availability again: https://github.com/odoo/odoo/blob/8.0/addons/stock/stock.py#L2188 (once canceled and reassigned elsewhere this history no longer exists)IMO it should unlink the move_dest_id on the ancestor moves in method do_unreserve() so it will flow normally since the M2O transaction was already completed.
I hope I explained this clearly.On Sat, Dec 13, 2014 at 8:18 PM, OpenERP Master <firstname.lastname@example.org> wrote: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".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.