Supply on sale with production request

Rational

Some business may require to produce on sale request. For example, when the production is very customized even for the same “product”. More on Linking sales orders with productions.

Proposal

A new module sale_supply_production is created which:

  • Allow supply_on_sale for producible (salable and not salable)
  • Create production request for producible line, store it on the sale line and set the sale as origin (like purchase request for purchasable)
  • A Function field production_request_state is added to the line with the values: '', requested, produced or cancel.
  • Assign the sale moves once the production is done

The design is very similar to the purchase request. So the sale_supply may be factored to ease the integration of production request (e.g. allow to reuse assign_supplied).
The production request are also created for input product that has the supply_on_sale checked.

Implementation

1 Like

I have some points that are not clear to me:

  • What will be the behaviour of sale_supply_production in case of nested productions? I mean: one of the sale product inputs is another product that should be producible. Will be nested productions also created?
  • What happens if the supply production wizard is executed and exists a production request linked to a sale? I think the supply wizard should not delete production requests created from a sale.

I think by default nothing should be done. So the stock_supply_production will be in charge of creating such production if needed.
But we should allow to extend the behavior to force to create nested productions if it is needed.

I agree the stock_supply_production should be updated this way.

I’m not sure if this is the best behaviour. We’ve found several cases that the production is done one demand and all of the components of the production should be produced in intermediate productions. So in this case it makes totally sense to create also nested productions.

I think we should allow the user to choose for each product if the production is “exploded on sale” or not.

Indeed I think a better design is to create production order also for producible input that has the supply_on_sale checked. So this means that the checkbox should be visible even if the product is not salable.

For it’d be better to have a supply_on_production. In some scenarios users want to manually create a production but all the bom tree created and linked to the main production.

This way if a product is created by “supply_on_sale” the initial production will be created on the sale. Afterwards if some of the inputs of the production are marked as “supply_on_production” their productions will be created too.

For me, it is not a correct design because the “nested” production requests must be created before the starting of the “parent” production. So supply_on_production will always be too late.

I have trouble with the “nested” productions. The main is that a production can be changed (quantities, BoM etc.) until it is running. So this means that creating nested order before will require a complex synchronization mechanism with major difficulties like: “What to do with a nested productions is running but the BoM of the main one is changed and no more required the running one”…
I think the “nested” production is a false problem or at least it is not a good solution to the real problem.
I see two cases:

  • The production is indeed composed of multiple BoM (to ease management) but it should be treated as a single production. This should be solved with phantom BoM.

  • The main production requires materials that are unique. So they are many possible improvements here:

    • Allow to define BoM using template.
    • Create variant on the fly.
    • Allow to customize the grouping_filter used in generate_requests.

So for me, the sale_supply_production should only manage to create the first level of production.

Here is the proposal Issue 3257: Production supply modules - Tryton issue tracker

This topic was automatically closed after 14 days. New replies are no longer allowed.