Community mailing list archives

community@mail.odoo.com

Re: Make to order business case design problem V8

by
OpenERP Master
- 12/15/2014 16:07:40
Great to see interest in this topic. I did write a crappy module to solve this problem. The reason the module is crappy is because I completely override 2 methods to do so. I thought this was absolutely necessary because there was no way to access the 2 lines I wanted to change inside the function. I tried to detail explanation. BTW, It took me about 5 hours to trace this problem through and resolve. My patch does exactly what I want it to do, and im very pleased with the results.

Here is a link to my module: https://github.com/aliomattux/make_to_order_process
Here is a link to the bug report I filed: https://github.com/odoo/odoo/issues/4237
Here is to very basic workflow of the order of execution in the functions attached

On Mon, Dec 15, 2014 at 3:01 PM, Ana Juaristi <ajuaristio@gmail.com> wrote:
Hi Eva:
I agree totally with your clear explanation about procurements to order and to stock but... I think problem here is not directly the procurement method but the movement status itself

When a movement is in "waiting another movement" you can do nothing with it. You can not unreserve because there is no reservation, you can not check availability since button is not there... so... the only way to make it available is just transfering moves from precedent movement. This is right if everything is right on workflow but real world is that workflow in real life can result broken or you should need it to be broken to be remake again.

I think this could be easily fixed allowing to take manual decisions about quant assignement on movements even if they are "waiting another move", so you can "make them free" breaking the procurement chain and start working fordward from that point.

On the other side when @openrpmaster says: I already solve the issue for myself so I have no further problem,  It would be great to know if you have got a new module to extend standar functionality, so I would really like to try and test. 

Thank you:

Ana

2014-12-15 15:44 GMT+01:00 Eva Pinter <epinter@openit.ch>:
Two of the main replenishment strategies are:

1. Based on the stock quantities and on a minimum stock. When you reach the minimum, the system wants to replenish.

2. Based on the stock quantities and on existing reservation and sales orders. The system will replenish, in order to fulfil the reservations and the sales orders at the promised date. In this case, you may have a minimum quantity of 0 in the master data, but the system will only care about what you have to deliver.

3. Based on the sales order only: The system will replenish as soon as a sales order is entered. It will not check the availability in stock as it is in that case not relevant.


1st and 2nd are both, basically make2stock replenishment strategies. The third is a make2order replenishment strategy.

When you can assign the received quantity to any order, then you are definitively in the case 2. Not at all in the case 3.

So, what may happen is that you have a specific m2o product in stock, for whatever reason (return, non payment, etc.). In this case, you would like to use the available material instead of ordering some more. For this, the availability check should be used before purchasing the goods. In most systems, when you set the product or the line m2o, the system will automatically replenish without checking the stock. For that reason, you may have some extra information for m2o products that allows to make an availability check even before saving the order line. This can also be a process measure.

I hope this explanation, from a purely logistics point of you, is clearer than before.

Now, in Odoo, you have ways to trick the system to do exactly what you want. The only issue, is that it becomes quite complicated for the user. The other point is that the vocabulary used in Odoo, may not fit 100% with the standard definitions.

Good Luck
Eva P.

Check out our training videos http://www.youtube.com/user/ybofr




On 15 Dec 2014, at 13:22, OpenERP Master <openerpmaster@gmail.com> wrote:

Hi,

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,

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.

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.

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.

On Mon, Dec 15, 2014 at 4:12 AM, Eva Pinter <epinter@openit.ch> 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 helps

Good luck

Eva P.



Check out our training videos http://www.youtube.com/user/ybofr




On 14 Dec 2014, at 05:47, OpenERP Master <openerpmaster@gmail.com> wrote:

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)

When 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.

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.

See the action happening during cancel of the linked reservation: https://github.com/odoo/odoo/blob/8.0/addons/stock/stock.py#L1830
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 <openerpmaster@gmail.com> 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 <openerpmaster@gmail.com> wrote:
Fabien,

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#

It says in the removal strategy section:
"""
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.


Thanks



On Sat, Dec 13, 2014 at 2:12 AM, Fabien Pinckaers <fp@openerp.com> 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" <openerpmaster@gmail.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.

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.

Customer orders item A at 3 quantity (make to order)
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.

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe



--
CEO Avanzosc, S.L : Office phone / Tfono oficina: (+34) 943 02 69 02
Ana Juaristi Olalde : Personal phone: 677 93 42 59. User/usuario skype: Avanzosc
www.openerpsite.com


El contenido de esta comunicación y de toda su documentación anexa es confidencial y se dirige exclusivamente a su destinatario. El uso no autorizado de esta información está prohibido por la legislación vigente. Si usted no es el destinatario le rogamos nos lo indique, no comunique su contenido a terceros y proceda a su destrucción. Disculpe las molestias que le haya ocasionado la recepción indebida de este e-mail. Sus datos figuran en un fichero cuyo titular es Avanzosc, S.L., a quien usted puede dirigirse para ejercer sus derechos de acceso, rectificación, cancelación y oposición en Julio Urkijo, 32, 20720, Azkoitia (Gipuzkoa), Tef. 943 02 69 02 - administracion@avanzosc.com

Komunikazio honen edukia eta dokumentazio erantsia konfidentziala da eta hartzaileak bakarrik jaso beharko luke. Indarrean dagoen legeriak debekatu egiten du bertan eskainitako informazioa baimenik gabe erabiltzea. Komunikazioa zuri iritsi bazaizu, baina zu ez bazara hartzailea, mesedez, guri jakinarazi, eta jasotako informazioa ez inori jakinarazi eta suntsitu. Barkatu okerreko email hau jasotzeak eragindako eragozpenak. Zure datuak Avanzosc, S.L. enpresaren fitxategietan sartuta daude. Zure datuak atzitzea eska dezakezu, bai eta, datuak zuzentzea, ezereztea eta tratamenduari aurka egitea ere. Horretarako, enpresara jo dezakezu, helbide honetan: Julio Urkijo, 32, 20720, Azkoitia (Gipuzkoa), telefonoa: 943 02 69 02 - administracion@avanzosc.com

This message and all documents attached to it are confidential and intended only for the person or entity to which it is addressed. Any use of this information by unauthorised persons is prohibited under current legislation. If you received this message by error, please advise us, destroy it and refrain from communicating its contents to third parties. We apologise for any inconvenience receiving this email improperly may cause to you. Your personal data are included in a file owned by Avanzosc, S.L. If you want to exercise your rights of access, correction, erasure and objection you can contact the Controller at Julio Urkijo, 32, 20720, Azkoitia (Gipuzkoa), T: 943 02 69 02 – administracion@avanzosc.com

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe