That is a good job. It has explained the Menu/Rules for maintaining the manufacturing database. This plus your earlier communication, giving the screenshots of the Masters, helps us to visualize your design.
Perhaps, if you have done the Menus for the Manufacturing processes (Planning and Control), just the definition by sharing the Menus, we can get an even better idea of your design.
Andre, the same from your side would be a big help in understanding your design and then getting the best from both approaches, into a Compiere solution.
I just had a look at your manufacturing menu. My compliments.
I'm one of the initiators of ActFact (Compiere partner for the Netherlands) and we are very interested in the manufacturing part. I have 20 years of experience in plastics; film extrusion/printing/manufacturing (process control and finance). If i can be of help i'll gladly do so.
What i miss are the set up times of an machine/workcenter. Small ordersizes en frequent changes have a big impact on your planning and effectivity. Perhaps i overlooked them.
regards,
Gerald Molenveld
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is nice to hear about you and your expertise in manufacturing and Compiere.
I am initiator too in the manufacturing project and i have translated Compiere to Spanish, currently I am Compiere Partner in Mexico, On the other hand , we have expertise in manufacturing environment (Tuperware, Philips,ITT Industries ,etc) (Repetitive and Discrete).
around your doubt with setup time this is include in Operation Standard and Routing Operation, considering its could change based on the product type and workcenter.
We believe you can participate in this project because of your knowledgement and interest.
You can begin validating the screeenshots and sending your suggestions.
Hi,
I am working with a Medical Device Manufacturer in the Product Data Management Department. I
have seen the whole data but one of the most
important piece seems to missing. A good configurator for taking sales orders.
I feel a Sales Configurator is missing. That seems to be the most important part.In the current model it is difficult to plan by option or model variant.If we add this to the base data model it will be helpfull
Let me explain you a little by what I mean. Suppose I have a car. It will have a base model and some options. Let me call these options.
Then what we do is have a Super BOM with all combinations. We have Object Dependency rules which pull options from the BOM based on which option is selected.
When a BOM is exploded we store it as a configuration. This will make it simple for introducing new BOM changes as the product evolves with new options and customisations.
We could map the BOM changes and the Sales Configuration changes with a Engineering Change Managment.
So in short that way your customer or distributor could be running Compiere having only a SALES BOM. Not a MFG BOM.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I couldn't agree more about the need of a "configurator"...this last Summer I implemented just such a feature in the system I have created for our manufacturing company...my implementation is simplistic, but it is very useful and saves a lot of time when entering product variants, thus eliminating errors.
I am tracking Compiere to see if I could eventually move to it from the system I have created, but configurable BOM is almost a necessity...
-> richard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In Compiere MFG & SCM, configurable BOM are planned in design document.
For "configurator", this is a function which could be very complex. (for computers for example the Dell configurator is a good example)
If you have any design, or any pattern to propose, for a "basic one" we will look for it. Because you're right, it is a quite generic need.
Best regards
Andre
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am by no means a database expert, so I doubt that I could give you the best design or pattern.
What I did, though, was quite simple and was intended to not impact the rest of my system much. I only made to changes, associated "Options" with a product (i.e., a product may have zero or more options) and modified my order line items to have the notion of a parent line item.
This required that I only had to change how line items where entered for (in my case) quotes and orders, which is effectively only a user interface issue. The way it worked was any time you entered a product that had options associated with it, a UI would let the user choose the desired options. Once they were selected, they would be added as normal line items, but their "parent" field would refer to the ID field of the product to which they were options. In my UI I displayed this as a tree. The UI treated these trees as a single object, i.e., delete one and you delete them all.
Again, the benefit for me in following this approach is that I didn't have to modify any other parts of the program that processed quotes or orders, because everything was just a line item.
The downside of this approach is that it doesn't record the actual choices, only the resulting line items from those choices. This means that if the user wants to edit the options of a particular line, he would have to choose all of the options again.
Of course, I am also glossing over some issues, such as precisely how options where specified, since these really only affect the user interface stuff...and also the expressibility of the configuration mechanism. In short, I can have options, such as 'select one', 'select any', or 'select all', where each option contains one or more products that must be selected using the specified semantics of the option type. I also have the notion of an option property with predefined values and options can be associated with a particular option property and value. This was needed because sometimes on an order you may choose a particular option that you want all other products to have the same option. Without option properties you would have to configure each product manually, where with option properties you can configure it once and then this will be used as the default value for other products that have options associated with the same option property...I don't expect this explanation to be completely understandable. :^)
The only thing that I am missing, which is important, but not immediately necessary for me, is some ability for the options to affect the actual product ID of the product. For example, the core product ID may be "FOO" and in some cases, by selecting a particular option, you may want to note that change in the ID, such as "FOO-BAR".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What you describe is very interesting, and realy simple to.
In Compiere MFG & SCM, options are part of actual database design. We don't have by now any product ID change, but you're right it could be very interesting feature. We will look to add it to our design.
For my concern, options user interface entry is associated with work order creation. When you enter a work order you can customize Routing (which include BOM) and by consequence, "options".
Do you use this at production level or at "commercial level" or both ... To build some proposals for clients ?
Is it Ok for you if UI for this part is only web ?
Best regards
Andre Legendre
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We manufacture many products, many of which can be configured in some way or the other.
The approach that I described is new, so it is not fully in use yet. For us, we work closely with our customers, first creating a quote and then an order (or just an order). During quote or order creation is when the products would be configured. This is not something that would be done on the plant floor.
This process is not something that is seen by our customers, it is done by in-house staff, so a web UI isn't the best...although at some point a web UI could also be beneficial.
At this point, I am still somewhat confused as to what Compiere's manufacturing options are going to be, since it appears that three different people are working on three different approaches.
I don't want to make it a fourth! :^)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Being one of the three projects (Colorado License Plate Factory), I just wanted to update everyone on recent events and help sort out any confusion.
1. I am a member of Andres Manufacturing Project, as my job is to maintain a common manufacturing document and assist in any database and Compiere ERP interfacing issues.
Andre is creating a JINI-based system (Compiere SCM & ERP) that will work independently of Compiere ERP. His architecture favors mid to large organizations that consist of many locations.
2. I went to the Dallas Training last week and spoke with Jorg. He has since added me a developer in SourceForge. My intention is to 1) create a manufacturing branch, 2) evaluate the current Production implementation, and 3) begin to add functionality using the iterative development process.
I am in the process of creating a Manufacturing Work Breakdown Structure and Functional Design document (as mentioned in #1). If youd like to review and comment, send me an email at: sklakken@cijvp.com and Ill forward the document accordingly. Please keep in mind that this is a work-in-progress.
I need to better evaluate the current Production implementation, but based on my gut feeling, I believe the next step is to create Manufacturing Orders. After this, Work Orders, Operations, etc can be added. Please let me know your thoughts.
3. Im not sure what Victor (the Third Project) is doing these days. Hopefully, hell return to the forum.
Cheers,
Scott
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How I understood your proposal (tell me if I am wrong) :
Compiere MFG & SCM will take care about manufacturing and supply chain.
This project does not include resource planning nor parts refurnishments, but will include capacity planning, shop floor control, delivery management, quality management and traceability.
Scott is working on an improvement of Resource planning of Compiere ERP & CRM, and produce documents to be used as part of Compiere MFG & SCM requirements and design.
These 2 modules will try to be complementary.
Our output (delivery, statisticals etc.) will be usable as entry for resource planning, billing etc.
Each module will be able to run with and without the other one.
Compiere MFG & SCM start from "Planned orders" to the delivery included.
Cheers
Andre
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wanted to make sure that Project-based and Engineer-to-Order manufacturing is also taken care of. This means the following as some examples:
- Pre-release partial BOM to production (long-leads, etc).
- Very good rev control for the many changes that occur between Purchasing and Engineering and Manufacturing.
- Abillity to ship work in progress
- Progress payments (not sure if this is already in).
- Estimating and ability to grab "buckets" of info from previous projects to use on similar projects. Perhaps this would be grabbing Products with attached BOM and cost info, which is already in I believe.
This is all I could think of so far. I know some of the companies listed here were custom-manufacturers, so there would be some demand. A close proximation of what I mean are features in non-open source products such as Questica and Encompix (http://www.questica.com and http://www.encompix.com\)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is the proposed Manufacturing Rules Menu.
http://www.e-evolution.com.mx/doc/Menu%20Manufacturing%20Setup.jpg
Please to review and to send your observations.
Cheers
Victor
Hi Victor
That is a good job.
One comment about BOM. I told before, bu may be you didn't see the message. We got an agrement with Jorg about BOM.
We will use BOM as they are defined now in product but we will define deeply subset of BOM linked to operations.
And when these operations are created and/or updated we will create and/or updtate actual BOM related actual and new tables.
In that way we will have an easy interface with ERP & CRM
So instead of BOM branch you need to have a capacity branch
with :
capacity type
task types
Units
tasks
capacities
and in operation branch
you need to have :
list of component (subset of BOM)
list of tasks
These comments are in a general point of vue, these elements wil be discuss all long the design step which just start.
We also need somewhere to be able to enter the list of different planning policies for resources and for capacities.
Cheers,
Andre Legendre
Victor,
That is a good job. It has explained the Menu/Rules for maintaining the manufacturing database. This plus your earlier communication, giving the screenshots of the Masters, helps us to visualize your design.
Perhaps, if you have done the Menus for the Manufacturing processes (Planning and Control), just the definition by sharing the Menus, we can get an even better idea of your design.
Andre, the same from your side would be a big help in understanding your design and then getting the best from both approaches, into a Compiere solution.
I have given my thoughts on the plus and minus points, as I understand them in my post
https://sourceforge.net/forum/message.php?msg_id=2098412
Vipen
Victor,
I just had a look at your manufacturing menu. My compliments.
I'm one of the initiators of ActFact (Compiere partner for the Netherlands) and we are very interested in the manufacturing part. I have 20 years of experience in plastics; film extrusion/printing/manufacturing (process control and finance). If i can be of help i'll gladly do so.
What i miss are the set up times of an machine/workcenter. Small ordersizes en frequent changes have a big impact on your planning and effectivity. Perhaps i overlooked them.
regards,
Gerald Molenveld
Hi Gerald!
It is nice to hear about you and your expertise in manufacturing and Compiere.
I am initiator too in the manufacturing project and i have translated Compiere to Spanish, currently I am Compiere Partner in Mexico, On the other hand , we have expertise in manufacturing environment (Tuperware, Philips,ITT Industries ,etc) (Repetitive and Discrete).
around your doubt with setup time this is include in Operation Standard and Routing Operation, considering its could change based on the product type and workcenter.
We believe you can participate in this project because of your knowledgement and interest.
You can begin validating the screeenshots and sending your suggestions.
http://www.e-evolution.com.mx/doc/MenuManufacturing Setup.jpg
http://www.e-evolution.com.mx/doc/CompiereManufacturing.html
http://www.e-evolution.com.mx/doc/ScheenshotManufacturing.html
Cheers
Victor Prez
Hi,
I am working with a Medical Device Manufacturer in the Product Data Management Department. I
have seen the whole data but one of the most
important piece seems to missing. A good configurator for taking sales orders.
I feel a Sales Configurator is missing. That seems to be the most important part.In the current model it is difficult to plan by option or model variant.If we add this to the base data model it will be helpfull
Let me explain you a little by what I mean. Suppose I have a car. It will have a base model and some options. Let me call these options.
Then what we do is have a Super BOM with all combinations. We have Object Dependency rules which pull options from the BOM based on which option is selected.
When a BOM is exploded we store it as a configuration. This will make it simple for introducing new BOM changes as the product evolves with new options and customisations.
We could map the BOM changes and the Sales Configuration changes with a Engineering Change Managment.
So in short that way your customer or distributor could be running Compiere having only a SALES BOM. Not a MFG BOM.
I couldn't agree more about the need of a "configurator"...this last Summer I implemented just such a feature in the system I have created for our manufacturing company...my implementation is simplistic, but it is very useful and saves a lot of time when entering product variants, thus eliminating errors.
I am tracking Compiere to see if I could eventually move to it from the system I have created, but configurable BOM is almost a necessity...
-> richard
Richard
In Compiere MFG & SCM, configurable BOM are planned in design document.
For "configurator", this is a function which could be very complex. (for computers for example the Dell configurator is a good example)
If you have any design, or any pattern to propose, for a "basic one" we will look for it. Because you're right, it is a quite generic need.
Best regards
Andre
I am by no means a database expert, so I doubt that I could give you the best design or pattern.
What I did, though, was quite simple and was intended to not impact the rest of my system much. I only made to changes, associated "Options" with a product (i.e., a product may have zero or more options) and modified my order line items to have the notion of a parent line item.
This required that I only had to change how line items where entered for (in my case) quotes and orders, which is effectively only a user interface issue. The way it worked was any time you entered a product that had options associated with it, a UI would let the user choose the desired options. Once they were selected, they would be added as normal line items, but their "parent" field would refer to the ID field of the product to which they were options. In my UI I displayed this as a tree. The UI treated these trees as a single object, i.e., delete one and you delete them all.
Again, the benefit for me in following this approach is that I didn't have to modify any other parts of the program that processed quotes or orders, because everything was just a line item.
The downside of this approach is that it doesn't record the actual choices, only the resulting line items from those choices. This means that if the user wants to edit the options of a particular line, he would have to choose all of the options again.
Of course, I am also glossing over some issues, such as precisely how options where specified, since these really only affect the user interface stuff...and also the expressibility of the configuration mechanism. In short, I can have options, such as 'select one', 'select any', or 'select all', where each option contains one or more products that must be selected using the specified semantics of the option type. I also have the notion of an option property with predefined values and options can be associated with a particular option property and value. This was needed because sometimes on an order you may choose a particular option that you want all other products to have the same option. Without option properties you would have to configure each product manually, where with option properties you can configure it once and then this will be used as the default value for other products that have options associated with the same option property...I don't expect this explanation to be completely understandable. :^)
The only thing that I am missing, which is important, but not immediately necessary for me, is some ability for the options to affect the actual product ID of the product. For example, the core product ID may be "FOO" and in some cases, by selecting a particular option, you may want to note that change in the ID, such as "FOO-BAR".
Richard
What you describe is very interesting, and realy simple to.
In Compiere MFG & SCM, options are part of actual database design. We don't have by now any product ID change, but you're right it could be very interesting feature. We will look to add it to our design.
For my concern, options user interface entry is associated with work order creation. When you enter a work order you can customize Routing (which include BOM) and by consequence, "options".
Do you use this at production level or at "commercial level" or both ... To build some proposals for clients ?
Is it Ok for you if UI for this part is only web ?
Best regards
Andre Legendre
We manufacture many products, many of which can be configured in some way or the other.
The approach that I described is new, so it is not fully in use yet. For us, we work closely with our customers, first creating a quote and then an order (or just an order). During quote or order creation is when the products would be configured. This is not something that would be done on the plant floor.
This process is not something that is seen by our customers, it is done by in-house staff, so a web UI isn't the best...although at some point a web UI could also be beneficial.
At this point, I am still somewhat confused as to what Compiere's manufacturing options are going to be, since it appears that three different people are working on three different approaches.
I don't want to make it a fourth! :^)
Hello Everyone,
Being one of the three projects (Colorado License Plate Factory), I just wanted to update everyone on recent events and help sort out any confusion.
1. I am a member of Andres Manufacturing Project, as my job is to maintain a common manufacturing document and assist in any database and Compiere ERP interfacing issues.
Andre is creating a JINI-based system (Compiere SCM & ERP) that will work independently of Compiere ERP. His architecture favors mid to large organizations that consist of many locations.
2. I went to the Dallas Training last week and spoke with Jorg. He has since added me a developer in SourceForge. My intention is to 1) create a manufacturing branch, 2) evaluate the current Production implementation, and 3) begin to add functionality using the iterative development process.
I am in the process of creating a Manufacturing Work Breakdown Structure and Functional Design document (as mentioned in #1). If youd like to review and comment, send me an email at: sklakken@cijvp.com and Ill forward the document accordingly. Please keep in mind that this is a work-in-progress.
I need to better evaluate the current Production implementation, but based on my gut feeling, I believe the next step is to create Manufacturing Orders. After this, Work Orders, Operations, etc can be added. Please let me know your thoughts.
3. Im not sure what Victor (the Third Project) is doing these days. Hopefully, hell return to the forum.
Cheers,
Scott
Hi Scott
How I understood your proposal (tell me if I am wrong) :
Compiere MFG & SCM will take care about manufacturing and supply chain.
This project does not include resource planning nor parts refurnishments, but will include capacity planning, shop floor control, delivery management, quality management and traceability.
Scott is working on an improvement of Resource planning of Compiere ERP & CRM, and produce documents to be used as part of Compiere MFG & SCM requirements and design.
These 2 modules will try to be complementary.
Our output (delivery, statisticals etc.) will be usable as entry for resource planning, billing etc.
Each module will be able to run with and without the other one.
Compiere MFG & SCM start from "Planned orders" to the delivery included.
Cheers
Andre
My first post to SourceForge, so here goes:
Wanted to make sure that Project-based and Engineer-to-Order manufacturing is also taken care of. This means the following as some examples:
- Pre-release partial BOM to production (long-leads, etc).
- Very good rev control for the many changes that occur between Purchasing and Engineering and Manufacturing.
- Abillity to ship work in progress
- Progress payments (not sure if this is already in).
- Estimating and ability to grab "buckets" of info from previous projects to use on similar projects. Perhaps this would be grabbing Products with attached BOM and cost info, which is already in I believe.
This is all I could think of so far. I know some of the companies listed here were custom-manufacturers, so there would be some demand. A close proximation of what I mean are features in non-open source products such as Questica and Encompix (http://www.questica.com and http://www.encompix.com\)