On demand production

We have found several companies that for each quotation produce a specific product for the company. An example is an steel manufacturing company which produces pieces for other industries.

This companies have the current workflow:

  1. Receive an order for the customer, with the instructions to produce the goods.
  2. They estimate the price of the production (by estimating the number of materials required, the machine time and the employees time that are needed) and provide a list price for the customer.
  3. If the quotation is accepted a production request is generated and planned for some day.
  4. Once the production is finished, the goods are delivered using a customer shipment.

We are missing a module to manage point 2 and make tryton compute the cost (and the price using a margin) for the quotation.

I think this can be easly implemented with a new module called sale_supply_production_quotation that implements the following features:

  1. Add a new tab on sale line (activated with a checkbox) that allows to input for a line the materials (one2many with product, unit and quantity) the operations (one2many with operation and estimated time).
  2. Compute an estimated cost using all the materials and the operations. With this cost, as the user for a margin percentage and compute the list price of the quotation.
  3. Once the order is processed, create a new product with a linked BOM (created from materials one2many) and a linked Route (create from the operations one2many). The BOM and the route should be used for creating the production request linked to the sale line.

Note that I’m suggesting to create a BOM and a route because the same product may be delivered another time latter, so all the cost computation is already stored on the system and can be resued.

Toughts?

1 Like

This workflow may be enough for companies with simple BOMs.

However, companies that manufacture complex products to customer specifications may need a separate model to manage the BOM construction/design process. This process may start only after the quote is confirmed by the customer.

For me this looks similar to the problem of selling projects. I do not think it is wise to mainly duplicate the production definition on the sale line.
Indeed I think it will be more flexible to extend the production order workflow to have “selling” steps like quotation and invoicing.

Maybe instead of using directly the production order as a quotation, it should be a project that include works that are actually production orders.

Most companies that are producing things on customer request are selling standard products, too. And many of them do this within the same quotation. I do not see how this could be achieved with this.

I do not think that cluttering quotations between two models is a good idea. There is the sale.sale model and i think it should contain all quotations of the company.

Maybe this is precisely their mistakes, they should not mix standard and custom sales which leads to complex forms that are not usable.

This is only the developer’s view. However, it can be crucial for a sales representative to be able to perform calculations on the entire scope of the sale.

With each new case that can’t be managed with the sale.sale model, I start to think that the sale.sale model is not flexible enough. It is too focused on simple trading scenarios. Maybe we should think about how to bring more flexibility to this model.

I do not agree. This is the view of UX design.

Only because he wants it to be crucial.

Because sale is designed for sale (not project, not production).

This is precisely my concern. We should not increase the complexity of this already too much complex model. The sale has not vocation to become the starting point of every business flow.

One possibility to support more workflow (without increase too much the complexity) would be to allow the sale line (probably a new type) to refer to another document like a production order or a project. So those document would have to implement a specific API so the sale can get the needed information to display on the quotation, manage its workflow to create stock move or invoice line.

That sounds really good to me.

In our experience in some scenarios having to create boms to create a quotation is not a good solution because it adds too much burden. For example, the user is forced to create a product that has never worked with just to add its cost in the quotation. Given that the % of acceptance tends to be low, the system can end up with hundreds of products that will never be used (and it took a lot of time to the user to create).

That’s why we ended up creating several product_cost_plan* modules:

Those don’t require creating any product to create the quotation and can be linked to the sale if desired:

If eventually the quotation is accepted, there’s a button to create the BOM, Route and Process.

Well instead of creating a product, bom routing etc, you create many otherthings. But at the end it is the same except that you have to duplicate what you created to make it permanent and you had to duplicate most of the code. I really see no advantage.
I prefer to have a production order in quotation without bom which can be deleted if it is cancelled.

The difference is that with product plan, if you need 5 input products to create the quotation you need to create none of them. You just add a line in a o2m in which you don’t need to care about many of the parameters the product requires (categories, types, cost, salable/purchasable, code, name, translations). So you’re not adding 5 new products in the database. Just one record in the cost plan table.

Speed of input is the key here and it is much faster if you don’t required creating the product. Of course that comes with added code.

To create a product you need exactly the same amount of fields as your plan: a name and a unit.

Well you will not be required to fill the inputs for a quotation production nor even an output products. We will just need to provide manual cost and probably sale price.

We tend to prefer to have the product tables somewhat clean and not encourage to quickly create products because that will probably tend to make it hard to find the “good” products.

I want to add ‘the other side’ to it a mechanical engineer. As a mechanical engineer I design a machine which consists of several parts. Most of the parts are general parts, others are specific to that machine and I am specifying the different details of that part. Most of the time this is a 2D-drawing with dimensions combined with a 3D-model. A specific part can be:

  • CNC produced part from one piece of raw material. No need for coating etc. This part have only one workcenter and can be shipped afterwards
  • An assembly of multiple parts welded together into one piece. Most of the time a coating is needed to protect the part. This needs several steps to produce like:
    • cutting material
    • prepare for welding
    • welding
    • stress relieving
    • CNC-machining
    • painting / powder coating

As an end user I want that part and I don’t care how it it produced as long as it complies with my specifications.

So the supplier gets a set of requirements and have to create a sale price. But it’s not the sales person who calculates the base price. That will be there engineer who understands the part and the processes and have experience in manufacturing. The sales person gets the base price and then decide to give a positive or negative discount. If you are a bad customer or they have way to much work, you will get a high price.

IMO it’s way easier to do the calculation in a spreadsheet and add that to the sale line including the request for quotation. I would not do this in Tryton only use it as the documentation of earlier orders. It’s more like sale_opportunity.

It’s maybe bad practice, but in the above situation, I would create a general product with all the necessary details needed for the accountant, the rest is left empty. As most products are one-offs and never come back or they do but are changed. You don’t want to waste your time with creating a new product. Let alone think about naming products.