How should manufacturing, inventory and production work when a custom product is ordered? Or what would be considered best practice in Tryton?
It isn’t reasonable to enter each product variable. The customer leads the ordering process. Full customization of any menu pizza is allowed based on available variables (3 sizes, Standard or thin crust, no sauce - sauce or extra sauce, can add or subtract 0-3x of any of our twenty toppings) a very large number of variations are possible. Manufacturing on the fly? Feel free to correct any wording or terminology I’ve used to help describe the question.
We haven’t started our journey into Tryton yet. Based on recent feedback we are looking to leverage our current front ends, communicate via API to Tryton and use the existing business framework that is Tryton.
At first tought it seems the easiest way. You should probably use the sale_supply_production module to create the production each time a custom order is received and customize the sale workflow to define the needed components, so this is moved to the resulting production.
Reading your example I do not think of manufacturing or production at first. For me the customer order is the most important part of the pizza creation:
When it is ordered (date time)? To triage the sequence of creation.
What is ordered?
What is price and payment status?
Delivery to?
The answer to the what is ordered question could define the production at all.
The products could be handled by templates and variants or product attributes or maybe product kits.
The order interface could be an individual web shop/app which simplifies the order creation, helps with the options and avoids mistakes.
For me it would not be ideal to create variant for each possibilities (even if you create them on the fly).
I think it will be better to use a generic product with attributes on the sale line. This must create a production order with the proper attribute. Maybe the attributes must be stored on the stock moves.
But I’m not sure of the suitability of digitalizing pizza production. It seems so artisanal process that it is probably better to just count globally for example by day the number of each one and make an estimation of the consumed ingredient. As I suppose that the goal is to optimize reorder stocks.
The goal is to have a full transparent cycle of information. The top reason we are considering Tryton is the existing ERP framework that should allow for tracking COGs efficiently and correctly. My main question is how to approach that specific problem in a standard way based on existing user experience here. This becomes more and more important as we try to leverage economies of scale and build integrity into our informational system. I really appreciate the feedback.
Some KPIs:
Cash flow
COGS
Prime costs
Average basket: per store, per segment, per hour
Feedback
Accuracy
Loyalty
Promotions
Promise times
Longer term it would also include other goals related to growing beyond our current city, beyond 5 stores and governance.
Please expand this idea a bit more when you have a minute. I really value your collective experience since we do not have any experience yet with Tryton. Would you recommend or not recommend using the sale_supply_production module mentioned by @pokoli
We currently track orders in our front end (unique tickets) we also are generating a toppings report and working towards a production and inventory solution but it isn’t proven and we would be solely responsible for its maintenance. I think what you mentioned makes sense if we can correlate the tickets to actual stock moves.
When a product is customizable with so much options that the number of possibilities is exponential. I do not think it is good to create a record for each one.
So for me the idea would be to collect the attributes on the sale line and pass them to each document that need them.
But frankly I’m not sure if it is the right solution.
Another solution would be to collect attributes on the sale line and create the variant (if it does not already exist) using those attributes once the sale order is validated.
But to be used with production, it will require to create the corresponding BOM also on the fly.
As I said I do not think that for a restaurant you really want to store each meal cooked as a single production. Because you will not measure each ingredient that the chief is using.
Instead I think if you want to track stock, it will be better that at the end of the day, the system decrease the stock level automatically by the average quantity used for each meal sold.
Indeed you will need to store for each product what has to be consumed to produce it. Maybe you could use the Product Kit Module for that.
I think the POS could be extended to work the product kit so when you sold a kit, it is a bunch of components that are actually moved out of the stock.