I am a new Epicor (and Product Configurator) developer, so please forgive me if some of my questions or assumptions are naive.
We are developing a configurator for a piece of machinery we sell. The main input for the configurator is the width of the machine. This dimension pertains to the top-level part itself as well as several sub-assemblies. Machines with different widths w
We have a customization which automatically generates sequential part numbers for us.
Our current business process is this:
Customer places an order
Sales creates new part records for top-level assembly and sub-assemblies (does not create MOM).
Sales enters the sales order referring to new newly created part(s).
Engineering creates approval drawings for customer. Drawing numbers correspond to part numbers on sales order.
When design is locked in Engineering generates MOM for new parts.
In our new configurator we are enabling part record creation when it is executed during sales order entry so that Engineering has drawing numbers to use for approval drawings. It is not uncommon for a customer to change their mind during this phase of the process; for example they may change their mind about the width of the machine.
We have found that once parts are created via a configurator their MOMs are not modified if you re-run the configurator. For example if the configurator was initially run with a width of 100 inches and the customer changes their mind and wants 90 inches then we are stuck modifying the MOM by hand (via Engineering Workbench). We would like to re-run the configurator to adjust the MOM for the top-level part and the sub-assembly parts. Any suggestions on how to accomplish this?
One avenue I have investigated is to use Epicor’s business objects to programmatically update the MOMs via C# code executed by the configurator. I have not done this before; examples I have seen are typically from UI customizations and reference an object called oTrans (which doesn’t appear to be available from configurator scripts).
I have also considered using LINQ to modify data in the database tables, but this practice appears to be universally discouraged.
Thanks for the response. I have referred to that document, worked through the Epicor University program on Product Configurator, and done a fair amount of Internet searching. Unless I missed it or simply didn’t understand it when I saw it (both completely within the realm of possibility) I haven’t found any material describing how to accomplish what I am trying to do.
Can you point me to a particular section or area within the technical guide that covers what I am trying to do?
It sounds like your product is make-to-order and yet, you create permanent parts. Is this a carry-over from your old system? What is the reason for creating these parts in your engineering files?
When you do the Get Details in a job that’s linked to an order, it builds the MOM at that time based on the most recent configuration. I assume that you’re not releasing jobs until you get the customer’s final OK. Also, using the quote module, you can see the MOM and work with it before creating the order.
It’s a different way of thinking and it might be too big a change for the engineering group but something you may want to consider.
I am on the configurator development team with Brady. We were not involved in the ERP implementation, but I was an end user in the order production engineering department.
All of our products that will be configured are ETO/MTO parts. From what I have gathered, we create part records for the following main reasons:
A lot of our products are ordered more than once (typically by the same customer)
We use the serial tracking feature in Epicor. As far as I can tell this is not available for Parts-On-The-Fly.
We sell a lot of replacement parts for our products that are also MTO. Creating permanent part records means that the method does not need to be re-created for these parts.
It is a similar workflow to our previous system. This is not an acceptable reason to me, but I have heard it said many times.
Currently we are exploring the pros and cons of using parts-on-the-fly for our MTO products. We use them at the quote stage for new products. Once a PO is received, engineering creates permanent records. After Engineering is complete, Production planning Gets Details into the job and releases the order to manufacturing.
Do you have any input on how we could get past some of these issues listed? I do not mean to derail the topic, but I was unable to find a way to send a PM.
Those are all legit requirements. I worked at a company with a highly configurable item with serialization. We had a “smart description” that we generated with the Product Configurator. Unfortunately, the description didn’t allow use of the Smart String part number which basically stores the config choices in the string which could be read backwards into a configuration.
While you cannot serialize parts-on-the-fly, we found you could change the part number to a part that was serialized. So we had three serialized parts for a series that represented small, medium, and large size. An the end of the configuration, we would change the part on the order to this generic series+size part number and then we could serialize and ship from a job.
Later, we had a BAQ that would search orders for parts with a certain description that were sold to a certain customer and we could find their previous configurations and copy those to a new order or use them for repair jobs. Epicor has a good Order and Quote description search that helped as well.
The trouble that we had with using historical BOMs from jobs (and you probably have with permanent records) is engineering changes. If you made a new job from an old job, it didn’t include any engineering changes made to the product since it was built. Engineering didn’t want to mess with the history of previous shipments or take the time to update hundreds of BOMs they would never use. So we wouldn’t always make the product as required. Separate issue but I throw it out there for completeness.