I’ve landed in one of those classic “my boss who is the CFO and does not really know IT made a promise that I now have to keep” situations.
We’re starting to integrate aPriori into our quoting process, and I’ve been tasked with figuring out how to get all that lovely data into Epicor 10.2.600.
Here’s the fun part - I know nothing about aPriori. I wasn’t involved in choosing it, testing it, or scoping it. I’ve just been told that it can spit out data for:
Part creation
Method of Manufacturing (MoM / BOM)
Quotes
…and that we’re expected to import all of this into Epicor using DMT - no REST APIs, no direct integrations, just file-based.
I’m the one who has to define the target file formats for aPriori to generate - so I’m trying to figure out exactly which DMT templates I need, and what fields are essential for each, so I can spec this out properly.
So now I’m trying to figure out what that actually looks like on the Epicor side - and how not to light anything else on fire in the process.
This is what I think I will need (DMT-wise):
Here’s what I’ve pieced together so far. To get a full Part + MoM + Quote into Epicor, I’m assuming I need to import the following (in roughly this order):
Customer - If they’re not already in the system
Part - Basic part record
PartRev - Revision tied to the part
PartMtl - Materials (BOM)
PartOpr - Operations (routing)
PartOpDtl - For resource/capability details
QuoteHed - Quote header
QuoteDtl - Line items
QuoteQty - Quantity breaks per line
What I’m trying to figure out:
Is that list accurate? Am I missing any key templates that would be required to make this work cleanly?
What’s the right import order for these via DMT to avoid validation errors or dependency chaos?
Are there any combined DMT templates (like Part Combined) that could simplify this? Or is it better to stick with the individual templates?
If anyone here has done this - with aPriori or even just another system dumping full part + quote data into Epicor - I’d love to hear how you handled it. What worked? What didn’t? What nearly caused a systems meltdown?
Appreciate any guidance, lessons learned, or even just a “yep, you’re on the right track”!
You’re definitely on the right track. For DMT, the MOM information is uploaded in “Bill of Operations” for PartOpr and PartOpDtl, and “Bill of Materials” for PartMtl. The operations, resource groups, and resources used in those uploads MUST already exist in Epicor. If a Part material does not exist, it needs to have a Supplier ID (and purchase point).
EDIT: it’s best to do Bill of Operations prior to Bill of Materials, since on the Material upload you can specify which operation the material is required for.
I personally have had zero success using “combined” DMT templates, but others use them successfully.
For this type of scenario and during my initial integration I would use/used (DataFlex DB > 10.2.400.X):
Always build Children first → Parent Last
Part Combined: (Initial base part creation across appropriate areas/plants)
Bill of Operations: Base MoM (if tying part material to specific OP it must already exist)
Bill of Materials: MoM Materials tied to appropriate OPs
I have not used DMT on Quotes so I cannot comment on those. HTH
I have had great success using the Sales Order Combined template (event went as far as automating it with some PowerShell voodoo) for when my CSR’s need to generate 100+ line Sales Orders. I didn’t see too many ‘Combined’ templates relative to this endeavor though.
I’m with @klincecum here. You CAN still export everything from aPriori to files, but then post those files using a Kinetic Function. I’m not sure why DMT would be the recommended tool.
You have much more control over error handling in the function since it can run a check for valid parts, customers, materials, etc. before updating Kinetic. If need be, you could even add those items, which is something you just can’t easily do with DMT.
I’m a fan of DMT. Consider running via powershell to save a bunch of clicks.
Another consideration is if this is more for historical data rather than proper methods of manufacturing that’ll be used again, then perhaps load as Parts on the Fly. This means QuoteMtl, QuoteOprs instead of PartMtl, PartOprs. This way historical doesn’t clutter part masters, while you can get details from these quotes to fix up into proper methods later on if needed.
I never thought about going the uBAQ route for this. I have done uBAQ’s in the past, but never to the level where I am creating new part methods and such.
True, DMT is basically the Fisher-Price ‘My First API Toolkit’ — colorful, durable, and designed without any sharp edges
This’ll be for new data - generating everything needed to create a Quote on a new Part in aPriori. That includes the Part Master, MOM (because of course it needs a full method), operations, materials, resources, probably a handful of UD fields, and whatever other required fields Epicor decides to throw a tantrum over. That data will be exported as a CSV, Excel file, or whatever format someone upstream decides is ‘good enough,’ and I’ll be the lucky one tasked with figuring out how to get it into Epicor. Naturally, it all needs to trigger the appropriate BPMs, populate the right fields, and behave exactly like it was entered manually. Oh - and the best part - it has to run without user intervention…why is that, you ask? Simple: Someone who doesn’t know what they are talking about is making decisions like they are subject matter experts.
I’ve read many of @klincecum threads that center around the topic of Functions, and they’ve always tickled that part of the brain that whispers, ‘Ohhh… now this could be dangerously close to fun… or just dangerously dangerous.’
I am going to look into the feasibility of doing this using Functions (I know it is most likely feasible, but I need to figure out whether the timeline actually allows me to learn how to use them properly before someone expects results.)
