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:
Receive an order for the customer, with the instructions to produce the goods.
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.
If the quotation is accepted a production request is generated and planned for some day.
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:
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).
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.
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.
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.
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.
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.
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.
I see this may be a clean solution but we will probably need to support some extra features:
Create a bom based on a existing production. Once the producction is accepted the BOM can be created and stored for next orders.
As production is just for managin cost, we will need a way to determine the margin that we want to have on the production. Otherwise we will not be able to know the final price for the customer.
We will need to have an estimated time on works, so we will be able to estimate the cost of works and provide a price for it. Here we need a margin too.
This is impossible, there is no enough information.
This should probably be using a price list. Or salesmen would have to set the sale line unit price based on the production cost.
I see no problem to have fields to store estimated work cost and timesheet cost. But it should work without because it will be too much work for many cases.
Why not? We can just create a bom with the same inputs and outputs as the planned production.
But if you do not think this is important we can add it in custom module.
Indeed using a price list will be the best option. But I guess we can make it optional and allow to enter a manual value when price list is not available.
There is another point that is not clear for me and this is sub-productions. There are some cases where the on demand production has multiple sub levels. How we should be able to manage that? I guess we will need to required the user the creation of all the production requests. But how we relate the parent production with the children ones? We need such relation to correctly compute all the cost of the final production.