Get details - subassembly structure not maintained?

Epicor ERP 10
1

Wondering if anyone has seen an issue like below when getting details for methods.

Where everything is fine when pulling details from an existing job into a new job.

But… pulling details from an existing job into a new part rev
and then pulling details from the new part rev into a new job
And…the subassembly structure is lost in the new job
i.e. parts are listed as simple materials under Asm 0 instead of seeing multi-level subassemblies.

Just thought I’d ask
before I start building simple job/part structures to verify methods pull as expected.
if I’m likely dealing with a bug or a corrupt structure?

Thanks in advance

2

Check the view as stuff in the new part rev.

1 Like
3

Pull As & View As were all checked as I would expect.
They are showing as subassemblies in the part, just not maintaining the hierarchy as the origjnal job. All the same leve in the Part methods and then under Asm Zero when pulled into a job.

4

Check the phantom check box on part.

Vinay Kamboj

5

I’m not where I can check, but I think I remember seeing a checkbox saying something like “Resequence?” on the get details form. See anything like that?

Joe

6

Please check if you method for the sub-assembly is approved or not. I would simply create a job with the sub-assembly as the top part (in a testing environment), and get detail to see if I can successfully pull the method out. I usually get error like one of the material is inactive, or found out the revision is not approved for the sub-assembly’s method.

Mike

7

I believe you’re experiencing the same issue as we did within the Quote\Mfg Details. The link below shows the discussion but basically Epicor advised us ‘that this is an intended behavior and it is working as designed. The functionality has been changed under Problem- PRB0100488, on Version 10.1.400’ when a part is marked as a Phantom BOM.

8

Interesting… I’m not sure there are any phantoms in this structure but otherwise, my symptoms are pretty much the same. The multi-level structure is lost when copying from the job to the part rev. e.g. Subassemblies come in as materials under Asm Zero.

What really is weird… as a test I added a new subassm with multiple levels to the existing job in question. Then pulled details from it into a new part rev.
The new subasm maintained it’s levels, while the pre-existing levels (still) did not.

I’m starting to lean towards some sort of corruption in that structure ( or settings ) but not sure.
Thought conversions 750, 760 and 770 might do something… alas no effect.
So… starting a fishing expedition now…comparing individual records, e.g. JobAsmbl, JobMtl, JopOper, etc…

i.e. hoping to fix this instead of rebuilding since this is a huge method structure used for capitol equipment

9

I finally identified one of the major SubAsm’s as the root of my problem.

Switching settings back and forth in Job entry, finally triggered an update to the structure.
Now when getting details for a new part rev in eng workbench, it’s levels from the job are maintained in the new rev as expected.

I still need to go back & try to identify the specific field(s) involved.
Since I had changed several things back & forth in the job before getting details again (been working
in Test)

P.S.
Discovered a related problem - the bug where Attachments not being maintained correctly in E10 when Get Details is used in the Engineering Workbench. So I can’t check my new Rev in untilafter I clear multiple, erroneous XRefAttch records.
This makes me reconsider why one of the major sub-assemblies chokes when getting details from the job. Since as far as I can tell, the job structure is perfectly valid - it’s just REALLY big, way more levels than your average site.

1 Like
10

Turns out there is more going on than I noticed previously.
I have since finally gotten to the bottom of this (I think).
Just in case this might help someone else has run into similar issues, here is the (long convoluted) story…

First a little background on these structures - for capital equipment, very large, multi-levels.
Methods were originally created in either quote or job - no prior part rev maintenance (ECO).
Over a period of several years, those Quote/Job methods have been reused/modified.
e.g. new Quote/SO/Job - get details from old quote/job - then tailor to order - always using the SAME Part number AND Revision for the finished item.

Issues arose when we finally decided to create a Part Revision from the latest job methods.
In the engineering workbench, after getting details from the job, the multi-level structure did not match.
A large number of parts we listed as materials for Asm Zero instead of appearing as sub-assemblies going many levels down.

What I finally discovered is that E10 is automatically recording modifications to the quote/job methods for part revision number(s). i.e. no-one ever built this revision via the Eng Workbench - there is still a lot of history in the system - and this “unseen” history was being applied to our part rev as we were getting details from the job.

The workaround we came up with:
1.) Job Entry
Create a new job for the Part number BUT… be sure to specify a NEW/UNUSED Revision number
Get Details from the old job (optional - I allowed renumbering, just to get rid of any gaps, potential related issues)
For ALL subassemblies - change the revision to the same NEW/UNUSED revision from 1.a. above.
Set Template = True
Save Job

2.) Part Maintenance
Open the top level Part Number from the job in step 1 if it exists, or create if necessary
Add a New Revision - same NEW/UNUSED revision from 1.a. above.
Check out to an ECO

3.) Engineering Workbench
Open revision - it’s methods should be blank
Get details from new job in step 1
Verify multi-level structure was preserved.

One last thing…
There is still a potential for corrupt attachment data that will prevent the new Part Rev from being checked in.
In that case, there is a thread listed elsewhere on this site with instructions fro clearing
Basically you need to locate any errant MtlSeq(s) in the xFileAttch table using a BAQ/Dashboard.
Then add/delete each MtlSeq(s) to your Part Rev until all the corrupt xFileAttch records are cleared.
Then you should be able to finally…check in your revision

The attachment issue is an obvious bug (to me).
As for the “unseen” revision history yielding unexpected results when getting details…
this also seems like a bug to me right now but… I wouldn’t be surprised if Epicor were to come back & say it is working as intended, “By Design”?