thanks for your valuable feedback.
@szufisher Thanks for your message, I think this could be a good way to solve the config problem.
For my case, there are 2 relevant options, I didn´t see in your post:
- Is there a way to generate automatically the name for the product?
Example: You config a computer with a Samsung HDD, 2x 16GB Ram, Standard monitor and keyboard type 2.
The places for the options will every time the same, so you could generate a “code” like:
MASTER-ITEM/OPTION1/OPTION2/QTY-OPTION2/OPTION3/OPTION4
Is there a way to generate automatically a code like this → COMP/SAM/16G/2/SM/K2
(Set a “short name” for every item and separate them with a “/”. A “-” for separation isn´t a good solution, because in some configs you have select a range or you have to select a negative value)
- Is there an option to “reconfig”? (I think it will work, but not sure)
Is you have 20+ Options and a costumer would like to order a device similar to the last order, but 2 options are different, it would be nice to select a code from one of the last orders for this costumer and only edit the 2 options.
In our case, we would like to monitor, which configs are ordered most of the time and with a code like this, it will be easy to set a filter. Also you can set an alert, if the same code are requested from 2 or 3 customers. In case a request come from one costumer for an item with this config an 2-3 days later you will get a request for the same config from a reseller costumer. So you can check, if it´s maybe for the same end user and set the discounts correct.
Also an option to select configs for this customer, which ordered in the past, would be nice.
Thank you for your time and sharing your solution.
Best wishes from Vienna,
Matthias
currently the configuration docname is generated based on auto name rule which is format:{field1}-{field2}…, of course it can be easily changed to format:{field1}/{field2}…, and copy this configuration docname to the configurable item’s item name field via custom script as needed.
as of now re-config is not supported, because the standard dynamic link field is used, so there is only 2 options: create a new config and re-use existing config, if use the existing config and change options, it will impact the old order linked to the configuration.
anyway, I think re-config is good feature per stated business scenario, will consider to develop this feature.
FYI
the core team thinks my proposed solution is too complex, it will not be possible to accept this into the core, so I am trying to pack it as an independent APP.
APP is now available for testing and feedback
4 Likes
Hey @szufisher I reply to you about your comment in my other post:
Selling-a-custom-and-complex-discreet-product-detailed
I understand your approach, and I though a lot about this today. Wouldn’t it be better to have the App more separated from the standard ERPNext design?
I think that a more lean approach can be to have a module that has all the necesities and configurations on its own, and that the touching point with ERPNext is just a new generated Item and BOM for each sale, without any extra information or connection. If we need more, we can get extra info or actions in the new Custom Module. Maybe a DocType “CustomItem” that has more info, but for the rest of standard ERPNext, there is only the new dynamically created standard Item and BOM. Maybe we can manage the agregation for reports and that kind of stuff with Item Groups. BTW, are you using your app in production? I assume you did it because you need it
what do you think about that? But if it were that simple, I assume @max_morais_dmm and @adityaduggal would already thought that. What am i missing?
@lalena ERPNext already provide the functional structure you need to manage that, just to present myself
https://frappe.io/blog/erpnext-customer-story/erpnext-customer-story-grupo-realize-de-móveis
When I started with ERPNext, in 2011 more or less, I was working for an woodworking company, we faced 2 big problems there
- 1 Cutting Stock Optmization
- 2 Each Sale depends on AutoCad, what imply you need an BIM (Building Information Modeling), to compute the costs of each sale, because, you can compute, from slices of wood, to metal componets, screws, glue etc, etc, etc.
At that time, the I had the idea, to buid one BOM per sales, what become an nightmare, 3 months after I started it on production, we just was adding around 30K BOM’s every month
Later I discovered that I can generalize that using other parts of ERPNext
The first trial to reduce the amount of BOM’s generated was
1 - Create an item for each product we assembly (2K BOM’s, also called base components), without worry about variations (colors, size, material, etc)
2 - Add one table of configuration with one Unique configuration ID, and an Key, value table, for each configuration
3 - Generate the Quotes/Sales Orders, using the BOM’s from the assembly list, and let the user associate the configuration him whats (in that time, that configuration come from AutoCad)
It was working, but still having an big problem, when the users wanted to seek one specifically item, it was impossible, but the key for achive that was already in the system, I just didn’t have figurated yet!
Also I didn’t was able to finish that project, due the bank ruptancy of company in 2014
From 2015-2019 Me and @adityaduggal had various discussions about the same subject, and finally on the past year, I figurated what was the missing link to solve the problem of the configuration searching for one specifically item.
The configuration need to be an Serial No, and this SN, need to be created before the item become available in Stock, for we be able to use that information as tracking and build reports to query the items, basedly on his configuration.
So, if we have one Serial No like
- 2020-01-9928832842828238382328
- Key: Color, Value: Blue
- Key: Measurment Unit, Value: MM
- Key: Width, Value: 1200
- Key: Depth, Value: 700
- Key: Height, Value: 800
- Key: Door Type, Value: Simple
- Key: Door Opening Type, Value: Avenzos System
We can associate this Serial No with the Item, but the Key Point here is:
If an production order, is started from that Sales Order, ERPNext need to ensure that Serial No with be the same on the final manufactured item, and here is the unique, point where ERPNext is failing right now.
Of course there’s various other ways to achieve the same result, but only that will allow you to use ERPNext at his own maximun capacity, with the minimal changes, and going to the streight point when you want seek an configuration.
Also, one exercise that helped me to solve that problem was:
- I purchase one laptop from Dell Inc. and they SO say
- Laptop Model XXX
- Internal Configuration No: XXX00912129121,
-…
- Internal Configuration No: XXX00912129121,
- Laptop Model XXX
So, if dell was using ERPNext, how they do, to identify that the item, they have in production is my item? Not someone else item? The answer is, what Dell call Internal Configuration, is just the laptop Serial No, and this Serial No, si direcly associate with my configuration options.
Also, ERPNext can allow this table of configuration, into Serial Numbers, with an minimal change on the Variant System, just setting if the item variant, should be managed as “Configuration”
And you can use, the Variant Generation system, to populate these serial numbers, instead of generate new SKU’s in ERPNext.
2 Likes
@max_morais_dmm I think I get it… if not, correct me please!
So is all the same as a standard ERPNext usage, but you store info about the custom specs on the SerialNo. Is that right?
My concern (in my product you can customize Knobs colors (and more, but to simplify):
If the customer selects 4 red Knobs and 3 white Knobs in his customized product, the stock update have to be different compared to a 7 Green knobs order (or can be all 7 different). And the price have to be different if the KnobType is different (different knob style model).
So, how do you “transfer” that config in the SerialNo to impact the costs and stock in the system?
@lalena one simple way is treat these items as consumable’s
So, in that case, while creating the Variant componets, you should associate one Item, to be deducted on the stock, and how many units you need of that item
Product XXXX
- Serial No AAAAA
- 3 Red Knob
- 4 White Knob
On the end of the Work Order, ERPNext will need to generate one consumption for the 3 Red Knob + the 4 White Knob, associated with the Work Order.
This is also supported by ERPNext, but we dont have the direct relation, and automation to handle that.
1 Like
@max_morais_dmm thats clever
Two thoughs:
-
Isnt that a little “hacky”? I mean, the consumables are not conceptually there for that purpose. A future ERPNext update can hit us in the back with something that makes sense with consumables but no on our usage.
-
To get a more automatic, safe and robust workflow we would need to automate and link that, and that level of coding I think is more intrusive that the one I described earlier (a separete module that generates custom BOMs (or ProductBundles)).
PD: is that a big of a problem to have one BOM for each sale? I mean, we have more quotations, SerialNos and other DocTypes in large quantities in the system. Which part of having a lot of BOMs was a nightmare?
Thank you for your insights! It helps a lot man 
1 - @lalena, sorry I think the word “consumable” is incorrect in used in my previous answer, I was going to say “raw materials”
2 - Custom apps, will be break on every new release, I knew it very well, and poor design in custom apps, can made you stuck in a specific ERPNext version, if you dont have constant support, to keep the app upgraded following the changes in ERPNext.
PD: Ok what happens if you want to combine 3, 4, 10 diferent selled products in a single sale?
You will be restricting your users, to 1 Sales order per Sale at time, and really it’s not good, at list to me, I’m attaching one simple Sales Order I do have in my system
Each line represents one product, and as you can see in the description, I’m describing each product that is under-composed, in my BOM
The following text “Cozinhas Estruturas: MDP\ Branco”, describe
- Component Used: Cozinhas Estruturas (Structural Cabinets for Kitchens, [Also is an BOM])
- Color for painting the Component: Branco (White) [Ensure that the BOM Picked have Paiting in the Routing]
- Type of Material for the Cabinet Structure: MDP
The GUID is the Serial No I do use to track the items in my system.
I’m not using the work order for manufacturing, because, my manufacturing process is outsourced
But that GUID, is the Ship tracking number also I use for track that product in the system of my supplier.
But here is the point, with the behavior I described, you are able to achieve and extract from ERPNext much more, than what do you give.
Also, the sales process is simplified a lot, since your users only need to find one specific product configuration to get the Serial Number, and in my case, I do produce an excel catalog, that help the sellers in few clicks, find the best option, in the configuration system.
Also, my case is even special, because I’m able to extract and build my configuration system entirelly from AutoCad.
But in the end, if my manufacturing was not outsourced, Im 100% percent sure I was using ERPNext to handle that scenario, about Configuration to Order, with minimal effort.
2 Likes
not yet, but planned to invite my current client to try it.
I think it is a good idea, I am thinking the following questions,
- how to handle the sales price calculation?
- how to link the configuration to the sales order?
- Newly created item is an item variant with attribute value copied from configuration details?
1 Like
@max_morais_dmm I think I see some issues in your approach (tell me if Im wrong)
So you, instead of having a lot of dynamically created BOMs and Items or Variants, you store the custom information on the product SerialNos and the stock used in each product is managed in the WorkOrder by MaterialTransfers. Am I right? Or are you reusing SerialNos?
The Excel with the predefined SerialNos confuse me.
The issues I think I see:
-
If you have to previously define all the SerialNos to predict the exact combinations. And you have to provide an Excel to Navigate and found the right one. With Highly customized items like an object with 7 parts to colorize and 10 colors to choose in each part, the permutations are huge. If thats not the case and the user needs to create a new combination (SerialNo) on the fly, has to manually put the data, prone to error. There is not “Help” from the system to assist on the options.
-
If you tomorrow stop using the color Red and now you have Scarlet and Salmon, you need to update all the SerialNos that you could reuse, because this approach isnt really a dynamic “Config to Order”, is a “Choose-Preconfigured-Option to Order”
-
Similar to the previous one, if today there is no stock of a certain color, you have to add some logic to the process to detect that and dont offer to the customer.
I think that what you save on BOMs you add on SerialNos. Can you describe the problem of having Items and BOMs dynamically generated? It seems the natural way to me to handle this scenario. And one Sale order can have multiple CustomI dynamically generated Items. Once you have the Item and its BOM generated, the rest of ERPNext is the standard and intended flow
Maybe Im not getting exactly what you mean!
-
Once you have a new Item and its BOM dynamically generated, is the same as creating a new Item and BOM by hand in the standard way. I feel Im missing something here about your concern.
-
The custom App creates a new normal Item, and populate its BOM with the material needed. It can also select that Item in the Sale Order automatically, or the user can select it. The rest of ERPNext would have no Idea that the Custom Item was generated by the other App (unless we want, but I dont see why)
-
Newly created Item is a regular Item with its custom components in its BOM (or Product Bundle, if you want to being able to update it)
-
If you need some information that is not “which materials do this item need” you can view that on the Custom App.
Another way Im thinking about:
The BOM can have a checkbox “hasVariants”, and if you check it, it transforms itself in a “BOM Template” (like the actual functionality in Items).
A Bom Template is a regular BOM with its usual ItemList, plus an ItemTemplateList, where you can add ItemTemplates.
So, maybe you have a CustomizeblePC where the user can select only the keyboard, mouse and headphones (each one in 10 colors, so normal Variations became a problem).
The BOM Template has the ItemList with:
- The Monitor
- Case, CPU
- All the standard components for that item.
The Bom Template has the ItemTemplateList with:
- KeyboardTemplate
- MouseTemplate
- HeadphoneTemplate
Instead of generating predefined variations of that BOM (it would be the same as having ItemVariants), you can create new BOMs on demand, and when you create it, the system ask you to fill which Keyboard, Mouse and Headphones you want. Each ItemTemplate in the list can be mandatory or not, so maybe one user leave out the Headphones. Maybe the user can modify the quantity of each one, if the BOM Template allows that.
A big plus: BOMs are multilevel, so the “CPU” could be another template, and you could customize it too (hard-drive, processor, memory, etc). Maybe an exploded ItemTemplateList on the BOM Template could do the trick.
Maybe its not the final design, but I think its pretty lean, generic and doesnt require much change, for adding to the core, now that @rohit_w is asking feedback on [Proposal] Manufacturing Roadmap Apr - Jun 2020
Or instead of BOM Template we make ProductBundle Template, or have another DocType (like when the ProductBundle was added)
No, I’m not reusing Serial No’s, because for I do reuse Serial No’s I need to resell the same product combination twice, and since the product very in millimeters, the chance to it happens is 1 in 1Billion, but the same approach can be moved to Batch No’s, that can be reused.
Same point about 1, if you generate on the fly these configurations, Batch No are the choice instead of Serial No, for my case, Serial No is perfect, because to me is virtually impossible repeat an sell.
That’s why what’s configurable need to be managed as one component (Variant Product)., but the combination, dont need to generate a new product.
To My Case, the problem to have Items and BOM’s generated per sales, that yearly we will introduce in average 100K new Items and BOM’s in the database, and ERPNext really dont support well databases that grow exponencially. Things become slower after 3-4 months of usage
1 Like
If you are developer or have developer resource, maybe you can base on my existing APP to develop the non-intrusive solution, of course if you would like to share / publish the repository, I can contribute as needed.
I really like this feature even though there is no real customer yet.
1 Like