Configurator remaking BOM on reconfigure?

Kinetic ERP
,
1

I’m experimenting with product configurators that create non-configurable parts with multi-level BOMs. In my successful experiments, I’ve followed these rules:

  • Assemblies made from raw materials and non-configurable parts have part numbers derived from inputs. This requires that all inputs are represented in the part number, so if any input changes, you get a different part. So a product configured to a size of 10x15 might have a sub called Sub-10-15.
  • Assemblies made from configurable subassemblies have part numbers with a sequential suffix. The part number on the order line might be Parent-105.

With this scheme, reconfiguration on the line that originally created the part is possible and works as expected. If you reconfigure, assemblies with sequential numbers get new sequential numbers. So if you reconfigure your 10x15 as 10x20, you might get Parent-106 with a BOM that includes Sub-10-20. (If you enter Parent-105 or Parent-106 on another line, they’re not reconfigurable. This is also as expected.)

Reconfiguration doesn’t work if I generate part numbers from the order and line number. Naturally, the part number doesn’t change as it does with sequential assignment. When the part exists, Epicor does not recreate the BOM. So if you reconfigure Parent-100000-1 from 10x15 to 10x20, the configurator appears to work, but the BOM for Parent-100000-1 still contains Sub-10-15.

Has anyone ever solved this problem? I have a long list of shot-in-the-dark hacks that I may have to try…

2

Would need to see your configurator in action. I can’t even picture what you are doing.

3

And most of the time we are walking alone on our configurator journeys as everyone’s product is different.

4

This depends on how your PartNumbers are being defined. Are you doing this within a Quote using the manufacturing tab and GetDetails? Or? You must delete all before you do a reconfigure if you want to update the BOM within the quote AFAIK.

1 Like
5

The only way I could get part creation to work is to give every configurator in the multi-level BOM these settings:

  • Enable Part Number Creation
  • Create Revision
  • Create Non-Configurable Part
  • Use Quote Method

The method rules also operate on quote entities, not ECO or job. However, we do not use quotes. Configurators with these settings create parts when you configure a sales order line. It’s not an accident that this works, because Epicor knows to replace the part number on the order line with the one it generated.

I know which ConfigurationRuntime method triggers the creation of parts and BOMs. When using an order number/order line smart string, the part number is still on the order line. So a pre BPM can’t delete the part and change partExists to false. I thought there was a partExists param, but looking at a trace I saved, it looks up whether the part exists but doesn’t pass that information along to the next BO method. So maybe it would recreate the BOM/MOM if I deleted it but left the part. There’s also a mysterious property called KeepIt that I haven’t experimented with yet.

When we were using quotes, I had a BPM that deleted the quote BOM and ran get details automatically when saving a changed configuration. That BPM used the quote BO, and it doesn’t seem to trigger with this workflow despite the configurator settings and rules referencing quote entities.

1 Like
6

And to update the items on your SO, within your Document Rules you have something similar to:

	switch (Context.Entity)
		{
		case "OrderDtl":
			// Set OrderDtl fields
			OrderDtl.PartNum				= Inputs.txtPartNum.Value;
			OrderDtl.RevisionNum			= Inputs.txtRev.Value;
			OrderDtl.LineDesc				= Inputs.txtLineDesc.Value;
			OrderDtl.OrderComment     		= ordComments; 
			OrderDtl.InvoiceComment   		= ordComments; 
			OrderDtl.ProFormaInvComment 	= ordComments; 
			OrderDtl.PickListComment  		= jobComments; 
			OrderDtl.ShipComment      		= jobComments; 
			Pricing.OrderPrice				= Inputs.decTotalPrice.Value;
			OrderDtl.PartsList_c      			= Inputs.txtListParts.Value;
			break;
		case "QuoteDtl":
			// Set QuoteDtl fields
			QuoteDtl.PartNum				= Inputs.txtPartNum.Value;
			QuoteDtl.RevisionNum			= Inputs.txtRev.Value;
			QuoteDtl.QuoteComment		= ordComments; 
			QuoteDtl.JobComment			= jobComments;  
			QuoteDtl.LineDesc				= txtLineDesc;
			Pricing.QuotePrice				= Inputs.decTotalPrice.Value;
			QuoteDtl.PartsList_c			= Inputs.txtListParts.Value;
			break;
		case "JobHead":
			// Set JobHead fields
			JobHead.PartNum				= Inputs.txtPartNum.Value;
			JobHead.RevisionNum			= Inputs.txtRev.Value;
			JobHead.PartDescription		= txtLineDesc;
			JobHead.CommentText			= jobComments ; 
			JobHead.PartsList_c			= Inputs.txtListParts.Value;
			break;
		}
7

I didn’t need to write anything like that. Epicor updates OrderDtl.PartNum automatically, which makes me think the way I’ve set up the configurator is the intended way.

1 Like
8

So, they lied here then I guess?

9

That particular excerpt might be true, but it’s not relevant to what I’m trying to do, namely update a part MoM.

The configurator tech ref is full of lies, though. For example, it says you can programmatically complete (as opposed to skip or cancel) a configuration, but doesn’t say how. It took me several days to get support to understand what I was asking about. The developers finally confirmed that this feature never actually existed. So maybe they were doing some kind of weird DDD where they wrote the tech ref before they wrote the configurator.

10

LOL perhaps, funny thing is then next clause is specifically about the MoM:

And, I do use many keep when rules for the MoM here is a sample:

image
image716×597 54.8 KB

// Paint / TuffCoat Time Rule
decimal OpTime = UDMethods.GetOpTime(Inputs.txtTrailer.Value, Inputs.txtModelYr.Value, "", "7"); 

switch (Context.Entity)
	{
	case "JobOper":
		JobOper.ProdStandard = OpTime;
		JobOper.StdFormat = "MP";
		break;
	case "QuoteOpr":
		QuoteOpr.ProdStandard = OpTime;
		QuoteOpr.StdFormat="MP";
		break;
	}
11

I have keep when rules and method rules (but no document rules) that apply to quote entities, setting fields like QtyPer. The quote rules magically apply to part creation when a configurator is run from a sales order. But since part creation is a black box, I can’t change how it behaves when a MoM already exists. Calling QuoteAsm.DeleteAllAssembly does not magically apply to part MoMs the way other quote-related things do.

1 Like
12

Sounds like you want to update the Part MoM after one was already made then?
AFAIK that might be possible with the Job Entry but I have never heard of that being done. What you are saying is true you’ve created a base part configuration and saved it with the part smart string I’m guessing. You cannot do a reconfigure like this AFAIK even programmatically.

In our case, we have base parts for example: C-ABC-12 that have their configurations imparted to them every time dynamically, C-ABC-12 will generally slightly different options & mom sometimes so saying it cannot be done is untrue. Each update to the SO/Quote or Job if being made to stock will fully reconfigure the product. As these items have a base GVWR and configuration there are multiple options allowing for different colors/option upgrades etc, but because the base frame is the same the base part does not change only the options/parts list which is created via the keep when rules for the configurator. There are many different frames/mfgs/models to choose in the top half which will update the options dataset in the bottom half of the configurator for each configurable model from on base configurable part.

And you should not be able to using it they way you are.

13

The first time I configure an order line, it creates all the parts and the multi-level MoM. None of the parts have base parts. They are ordinary non-configurable parts. (This is expected and desired.) However, the order line still carries the configuration inputs, and you can click reconfigure. If reconfiguration results in a new part number, then a new part and MoM are created and everything works as expected. But if reconfiguration results in the same part number, it does not update the MoM of the part that it created moments before. And there’s no error, so it looks like you reconfigured the line, but the job will be created with the original configuration.

I think I’ll write a BPM to enforce that product configurators may have any two of “create non-configurable part”, the ability to reconfigure, and a smart string that does not change when reconfigured, but never all three.

14

This almost sounds like your (re)configuration is not being saved properly for some reason. As I understand it, the system runs the configurator rulesets against the saved configuration whenever you use Get Details. If that is not happening my assumption would be bad settings somewhere or a bug.

15

The reconfiguration is definitely being saved. The changes are visible if you reconfigure again. The problem seems to be that the black box that runs Get Details only does so the first time the configuration is saved. On reconfiguration, if the part number already exists, it does nothing.

16

Are you talking about the Job for a given configuration? Have you rejobbed after reconfigure? If the SO already been jobbed it will not update it if this is what you are talking about?

17

There’s no job until MRP runs and sees the demand. I’m talking about the part. Exactly what you would get if you went into Engineering Workbench and created it by hand, but Epicor magically does that when you run the configurator on an order line. I don’t know if it actually creates a quote because there’s nothing in the trace log, but it’s as if it created a quote, ran your method rules on it, created a part, and ran Get Details against the quote.

18

So you’re saying you see the Job detail BEFORE MRP runs?

AFAIK whatever configuration is stored with that SO for that part will be created within the job when the Get Details functionality kicks off same goes with Order Job wizard clicking that check box will trigger the configurator rules to be run and the part configuration created/updated.

I have never seen the OLD configuration stay in place yet when MRP or Order Job Wizard is run.

19

The job does not get its MoM from the configuration, it gets it from the part. No configurator rules run on the job. The part created by the configurator is in every respect an ordinary non-configurable part. This is a good thing; this is exactly what the Create Non-Configurable Part option is supposed to do. The job gets the wrong MoM because a Part MoM that was created by the configurator is not updated when an order line is reconfigured.

1 Like
20

Correct, I did not realize this was the type of part you were creating. One would assume you were trying to reconfigure a reconfigurable part and not go outside the design of Epicor’s system. My mistake.

I wish you luck forging your own path! :slight_smile:

1 Like