Community: Inventory and MRP mailing list archives

RE: MRP + "Cutting stock Problem/Guillotine cut" Solver

Van Hirtum Johan
- 12/02/2015 12:35:08

Hi Arjan,



We are in building finishing and we will start developing something similar. It’s quite a job. We have outlined a road map.

On product, we will create a type for profiles / sheets with have a price in m / m² but are sold / buy in pieces. For full wood profiles you must be able to define the length ( variable from delivery to delivery ). You must be able to sell profiles and sheets with are cut on free dimensions and it must be possible to define what must be done with the rest pieces ( thrown away or kept in stock ). Of course it must be possible to set cutting dimensions in order lines / purchase lines.

We also will create a product type with configurator. This type of product will have an object with metadata that lists all properties and the rules to validate the property answers. There will be an ‘price calculator’ where you can use functions to look up prices in tables, depending on property values. And there will be a ‘Bom generator’ that generates the Bom in function of property values ( generation of product code + quantity ).

The optimization is something we like to do later on. We see this on the production level. In the Bom ( say for a window ) we calculate the different profiles + there length. Then we group the windows in a production batch. On this batch we can then optimize, where rest pieces from previous productions and machine parameters ( width of the cutting blade,.. )  are taken in account. But first we want to develop the product, sales and sales lines objects so that what we have written down before can be achieved. For the product configurator we want 3 versions : a standard, an expert and a web. Expert let advanced product specialist choose and change even small details, standard works for 95 % of the sold instances and web is a simplified version where you can configurate the 80 % ‘standard’ instances in a web portal.

At the moment we stay on v8 but the API is the same as for v9.

When you also want this kind of configurable products, maybe we can work together on this. When interested, send me a private e-mail.


With kind regards,



Van Hirtum Johan



Van: Arjan Duijs []
Verzonden: woensdag 2 december 2015 16:23
Aan: Community:
Inventory and MRP
Onderwerp: MRP + "Cutting stock Problem/Guillotine cut" Solver


Hi All,

I am implementing odoo v9 in a furniture factory.

There are a couple of challenges i am facing.


Hopefully somebody has some experience/advice with the following


1) Cutting stock problem / Guillotine cut (

When i define for example melamine furniture in MRP, the furniture is made up of certain pieces of melamine which i can put in a BOM.


Then when a order is placed, at one moment we want to know how many sheets of melamine we need to buy. (can be any combination of furniture and amount)

I can define each piece as a m2, but at the end this is inaccurate.(as well as plain vs wood grain direction).


So in a perfect world, accepting the SO would loop over the Boms needed  to determine the optimal cuts (and thus sheets necessary) for that order. then puts a PO for those sheets.

At the same time when it has generated that cuts, it places the output in a file that can be used in the CNC woodcutting machines (workstation).


2) Variable Material / Shared/multiple BoMs

Another challenge is on how to define all the furniture within odoo.

All the pieces of the furniture can be defined, except their material. (can be mdf+formica, melamine, mdf+veneer, mdf-painted, polyurethane) 

one option is to use (nested) boms.

the issue with that is that i need to define to manufacture all the pieces and all their variations. We have quite some suppliers so we definitively dont want to put all their melamine/formicas as a variant for each piece. (maintaining it would be a pain..)


I have looked into orderline variables, but that still needs a separate bom for each variable.

would have been ok if you were able to use multiple boms per product. A base-bom vor all the variants, and an additional variant specific BoM 


Any thoughts on this?