I’ve been tracking down some jobs that were unexpectedly set to Auto Receive to Inventory and think I may have discovered a behavior that doesn’t match what the UI suggests.
Here’s what I found:
We changed the Part Class.
We updated the Method Operation and cleared the Auto Receive to Inventory checkbox.
We did not create a new revision or update the revision being used by existing jobs.
Newly created jobs were still being generated with Auto Receive to Inventory enabled.
After digging deeper, it appears the Auto Receive setting used by Job Entry is coming from JobAsmbl.AutoRecOpr, which is derived from the Part Revision, not directly from the Method Operation record.
What is confusing is that in Method Tracker/Method Entry the checkbox is labeled as being tied to ECOOpr.AutoReceive, which led me to believe updating the Method Operation would control future jobs. In practice, the revision seems to be driving the value.
My conclusion so far is:
Updating ECOOpr.AutoReceive on the Method alone is not enough.
If the active revision still contains the old value, newly created jobs will inherit the revision’s setting.
The effective source for job creation appears to be the Part Revision/Approved Revision data, not simply the current Method Operation record.
Has anyone else run into this?
Am I correctly understanding that the job creation process ultimately pulls Auto Receive from the revision structure that gets copied into JobAsmbl.AutoRecOpr, rather than directly from ECOOpr.AutoReceive on the Method?
Any insight into exactly where Epicor copies this value during job creation would be appreciated.
It has always been my understanding and observation that the settings for the fields, AutoReceive, and Final Operation, are maintained in the PartRev table and the Jobs are created based on these values. The values used are the appropriate Operation number.
The “ECO” tables (ECORev, ECOOpr, ECOMtl) are ONLY used while a part revision is checked out to the Engineering Workbench. After the Part Revision has been checked back in, the data in those tables is NO LONGER USED. It’s still there, Epicor doesn’t (for some unimaginable reason) clear them, but the actual “new” revision data is transferred to the PartRev, PartOpr, and PartMtl tables. THESE are the tables that the “get details” process pulls from to create JobAsmbl, JobOper, and JobMtl.
As you discovered, the Auto Receive value is a numeric field (on PartRev and then JobAsmbl) storing the Operation Sequence number of the selected op. Once the Job has been created and details gotten, and then you DEselect “Auto Receive” on the operation, that SHOULD update the JobAsmbl value (from whatever it is) to zero, meaning not defined). If the system is not doing that, and AutReceive is still being triggered, I’d report that as a bug.
One thing to try for troubleshooting… if you aren’t required to unEngineer your job to make changes, try unEngineering, then deselect Auto Receive, then reEngineer and release… see if that triggers the table to update.
Our challenge isn’t with open jobs. it’s when we change the Method. We aren’t doing anything with a revision, just changing the method from Auto Receive to Inventory to Not checked. So it seems we might have check out the revision Then change the method and check the revision back in.
The only way you can change the Auto Receive checkbox on an existing Revision (so that the NEXT job reflects that change) is to update that Revision in Engineering Workbench (or create a new Revision). You can’t just change it in the PartRev table (at least not reliably).
What on earth is the “method operation” if it is not part of the Part Revision?
To be clear, revision = method; these are synonyms.
Operations are a subset of the method/revsion, but as @Ernie pointed out, the auto-receive “on the operation” is a ruse; the real data is only on PartRev.
But… you cannot change “the method” without checking out the revision - it is the same thing…
You are correct you cannot change a method with checking out revision i was mistaken, I don’t edit them myself and had bad feedback.
But the revision and method aren’t really equal are they? You can have multiple methods to 1 Revision, alternate methods for a revision for example.
That ECOOpr → PartRev helps a lot, seems like a weird way to track that. You are leaving data in the ECO and someone before made all our BAQ’s to investigate this stuff using ECO.
In a word, yes. The UI, I suppose, can be said to function that way.
But from the database side, each alt method is a separate entry in the PartRev table… so when I would do BAQs, I mentally framed alt methods in the same basic way as any other method. The operations have RevNum and AltMethod as primary keys (alt is blank if it is the main one).
Granted, in Engineering Workbench, you pretty much have to check them all out as a set (the rev and its alts), so they have a connection.
Certainly happens. Users have their own lingo that does not align with Epicor documentation.