Configurator uses JobMtl to create part methods?!

Epicor ERP 10
1

In testing out Configurator, I am playing with it creating a method for a new part to be saved in the part master.

I am using a “super BOM” (or super BOO, really) for the operations, but for the sole line of material, I wanted to use a template BOM.

I got the super BOO down well enough with “keep when” rules.

But this template BOM thing. Choices for substituting the part number are:

  • JobMtl.PartNum
  • QuoteMtl.PartNum
  • ECOMtl.MtlPartNum

I kept failing because I was trying to invoke ECOMtl. But no, to modify the part’s method, I need to use JobMtl!

So,

  • Huh?
  • When would I ever use ECOMtl in Configurator?
  • What if, for example, I wanted to modify pull-as-assembly? I think I’ll be OK since the non-stock inherited value should always be sufficient, but in principal, I need more than just the JobMtl settings.
2

Jason, if the configurable part method has a mtl in it then the only thing you can do when writing method rules on that material is update mtl tables. If you had an assembly in your method then you could modify JobAsmbl or QuoteAsm if you are writing method rules on it… Am I explaining it clearly?

3

But outside of Configurator, I would modify PartMtl to accomplish what I want. So why do I need JobMtl to accomplish a modification to PartMtl?

4

Where are you calling the configurator from? For example, quote entry, order entry, job entry, po entry…

1 Like
5

I have been calling it from Quote Entry.

My configurator is set up to create a new part-master part, which it does, and a method, which it does.

The (lone) material in the original (unconfigured) method is part # 880074.

Initially I tried replacing it with

ECOMtl.MtlPartNum = "880076";

But that didn’t work.

So then I modified the tech ref example to see which number it would take (or keep the 880074):

switch (Context.Entity)
{
	case "JobMtl":
		JobMtl.PartNum = "880075";
		break;
	case "QuoteMtl":
		QuoteMtl.PartNum = "880076";
		break;
	case "ECOMtl":
		ECOMtl.MtlPartNum = "880077";
		break;
}

And it took 880075, so it’s thinking this is JobMtl. This is where I am lost.

6

might be a question for @timshuwy… we do not utilize the part creation aspect of the configurator.

7

Good answer from Corey in Support today:

You would use ECOMtl if you are going to do configurations in the engineering workbench. You can enable the configurator to launch in the engineering workbench so you would use the ECOMtl and ECOASM tables for method rules for the engineering workbench but they don’t do anything outside of the EWB.

If you are outside of the engineering workbench the system will use JOBMTL/JOBASM to build the new part method. If no JOBMTL/JOBASM rule exist but QUOTEMTL/QUOTEASM exist it will use the quote rules.
If both exist the system will default to using the job rules unless the “Use quote method” is selected in the record creation settings for the part.

I wasn’t familiar with the Engineering Workbench approach. Apparently your configurator pops up on Get Details (as applicable), which to me implied that you need to create a part (number) first, then configure the method. That’s not helpful to me, but that’s how it works.

So in summary, I’ll restate the title of this post without the interrobang:

Configurator uses JobMtl to create part methods.

1 Like
8

LOL! Never heard that one.
Jason, I am running into a similar issue. I am running Order Job Wizard and I have found that it thinks my context entity is OrderDtl. I was not expecting this since I’m creating a job. But I am wondering: have you had to filter certain blocks of code in the Configurator to which instance you’re using? I want this code to execute when I am using the Configurator in the Order but not when the Job is using it to create the job. Any ideas?

9

Dan, sorry, I haven’t touched Configurator in about a year. My brain rebooted when we went multi-site and all senior management related to that transition left the company at the time.
:exploding_head: