DMT Loading JobAsmbl: Invalid Child Assembly

  • 24 September 2022
  • 4 replies

Userlevel 4

I’m doing a dump/transform/load from Vantage 5 to ERP 10.2.700 and I’ve hit a snag loading open job assemblies.  This happened to me on a prior project and I can’t remember how I solved it.


The error that I’m getting is of this form:


2022-09-24T15:40:18     1001239 7  Table: JobAsmbl Msg: Invalid child assembly.
Invalid child assembly.
2022-09-24T15:40:19     1004695 7  Table: JobAsmbl Msg: Invalid child assembly.
Invalid child assembly.


The error cases are repeatably the same; these are the steps I’ve taken so far:

  • Checked that I’m in the right company and plant
  • Tried removing the “parent,” “peer,” and “child” fields
  • Tried removing the BOM Level and BOM Sequence fields
  • Reduced the load file to the first five jobs, so failures happen more quickly
  • Removed all fields except the bare minimum required by DMT for the JobAsmbl load

I’m probably just overlooking something; please assist if you can.


Thanks much



Best answer by mwilson 25 September 2022, 00:57

View original

4 replies

Userlevel 4

I found a knowledge base article entitled: 


Invalid Child Assembly error message when adding or changing assemblies


and the workaround says:


From the Conversion Workbench, under User Run Conversions, run the following 3 conversions:

1. ConversionID: XAFixAssmPointersForE10
Description: This program will find Jobs where the final assembly child pointer field was  corrupt and assign them a correct value.  This same logic will be done to the QuoteAsm file.

2. ConversionID: XAFixNextPriorPointersForE10
Description: This program will find jobs with corrupted NextPeer and FinalPeer pointers and assign them a correct value. This caused the calcualtion of the BOMSequence to be incorrect.

3. ConversionID: XAFixPeerPointersForE10
Description: This program will traverse ALL the JobAsmbl records, and assign the PriorPeer and nextPeer fields to the order defined by the AmsSeq of the subAssemblies that share a parent assembly.


I ran the conversions, and it does indeed correct the pointers and allow more assemblies to be loaded, but the pointers quickly get corrupted again, and some of these jobs have over 200 assemblies.

I recall now that I fixed this issue with data directives before; I’m working on that development now.  Will update here when I find a solution.

Userlevel 4

I made two simple Data Directives, In-Transaction, on JobAsmbl.  The first detects updated records where Asm = 0 and NextPeer > -1 (an invalid condition) and sets NextPeer to -1.  The second detects updated records where Asm > 0 and PriorPeer = 0 (an invalid condition) and sets Next Peer to its own assembly sequence minus 1.  There may be cases where this isn’t the correct number, but at least this workaround allows the huge job assemblies to be loaded by DMT.  I may run the conversions again after all this DMT activity, just to be safe.


Hope this helps someone!


Userlevel 1

Monty, also remember that, way back when, we tried to DMT load new revisions onto parts, and it didn’t work out quite as we’d planned, and we ended up having to check each part out and then check it right back in, in order for the correct ones to show up when creating a job. Just something to test out after you upload!

Userlevel 4

Reading this again, I see I made an error.  It’s Prior Peer that gets set in the second directive, not Next Peer.


So by the time you get error messages, the structure numbers are already corrupted.  I ran user conversions 750, 760, and 770 (K22.1), and then with the directives in place the records were allowed to be loaded.