can I trouble those who are running their configurators on “generate a part” mode to advise who they manage the amount of parts that are created, are you all marking inactive or purging past a certain date, if you don’t do this are there any issues or slowdown’s created?
we’ve been advised “just test it” however creating a million fake configurator parts is not something we have time for, so I’m curious how you guys are finding/managing it?
We have our configurators set up like this. We do not need to keep the part number in our inventory after
it has been created. Because we use the Quote Number - Release Number - Line Number, with the Product (Configurator Part) as the preface, to build the part number each one is unique and easily retrieved for reports/dashboards, etc.
ok that’s nifty, so you generate a part, but auto delete somehow once the job has completed?
No need to auto-delete, the part never gets added to the inventory (Part table). It is generated on the fly and only exists on the configured line of the Quote / Order / Job, where the BasePartNum is the configurator part number (Hope that makes sense)
We’re planning to do this, but I can’t say how well it will actually work yet. We were backed into this corner by the fact that we want to transfer custom manufactured parts from our manufacturing site to the retail site and ship the sales order from the retail site. Transfer orders cannot carry configuration information, so we’re forced to design configurators that create real parts that will be placed in inventory so MRP will create transfer orders.
For subassemblies that only have a few inputs, we’re generating part numbers that encode all inputs (“Foo-Red-10-20”). These parts may be reused. For the top-level part, we’re using sequential numbering (“Bar-12345”). We tried using the order number/order line pattern, but this is incompatible with part creation. If the part is reconfigured, it does not remake the MoM with the new inputs. Even if we set the parts as not reconfigurable, this problem can still arise if the user deletes and recreates the order line. (Which they will if they can’t reconfigure.)
We project about 1 million parts per year. We tested what MRP regen does with 1 million simulated parts. It takes 3-4 days to run, so that’s a non-starter. RIght now I’m working on a scheme to uncheck “Process MRP” and “Generate PO Suggestions” when a job is completed. The open question is when to uncheck and recheck these fields on reusable subassemblies. If that proves intractable, I may change the subassemblies to sequential numbering, creating even more parts but simplifying what to do about MRP.
I’ve actually used a sub-configurator with a Job Receipt to Job across Sites to solve this problem before. It was overly complicated and all the steps made it a rather onerous process for users, but the costing and everything worked out. I offered the two options to the business stakeholders - Job Receipt to Job vs. Configurator generated Part Numbers - and they picked the former. In the end I think the Job Receipt to Job results were better for them than generating parts would have been, but it sure was a lot of work.
So the sales order in the retail site creates a job in the retail site, and the job in the manufacturing site is make-to the job in the retail site?
Training may be the deciding factor for us. The users in our retail sites are not tech savvy and are not going to tolerate a lot of steps to place and ship orders.
Exactly. For us there was “finishing” to be done in the retail site before the product shipped, so that was one of the reasons we leaned towards job to job.
Yep. It’s too bad when software / process decisions have to come down to that, but sometimes that’s just the way it is.
Are you able to capture the costs of physically transporting the products from site to site? For us it could be anywhere from across town to across two huge western states.
On the Job Receipt to Job screen there is a Costs tab where it let’s you override costs. Not sure if capturing transport costs is an intended use-case for that screen, but it seems like it could work… I’ve never tried it though.
Yes, exactly where we are also
This would be brilliant, I wonder if you could uncheck those items when the item ships… that way it gives you space for any last minute re-work etc, we believe we’d create around the same per year so very interested in the outcome
Hmmm. Seems you cannot uncheck “Generate PO Suggestions” on a manufactured part. And a couple threads quoting Epicor support say that MRP will still process an inactive part as well.
That’s a pain, I’ve taken this up to Epicor support, so will add that to our existing case and advise when we make any progress… I wonder if anyone’s attempted to customize MRP so it respects “do not process” flags at some point
To finalize this, I received a reply back from Support saying there is no built in functionality and to create an Epicor idea 
So here she is: https://epicor-manufacturing.ideas.aha.io/ideas/KNTC-I-2610
Sorry I missed this the first time, so I am late here.
Maybe I missed something, but that would be irrelevant. MRP (etc.) would never make a PO suggestion for a manufactured part anyway. The equivalent and relevant setting would be “Process MRP.”
Yes I have heard that also, but again, that’s the “Process MRP” setting that should save you, from what I have read here as well.
Point is:
| If Part is | If I want MRP to ignore it |
|---|---|
| Manufactured | Process MRP = false |
| Purchased | Generate PO Suggestions = false |
(On a per site basis.)
I mean, I haven’t tested this in ages, but I think it still all holds true.
I forget where I read this. It may have been something support told me. But I think the reason you can’t disable “Generate PO Suggestions” on a manufactured part is that MRP will always look at it to see if it needs to generate a PO for its components. And it does this even if “Process MRP”
is unchecked. That fits with what I remember seeing. But I can’t test it anymore because I quit my job to work on my own ERP system full time.
