I’ve already found that DMT will change the LineNum of detail tables when importing. Ex: An Order with Lines 1,2,4,5 (3 was deleted) in your source data becomes lines 1,2,3,4 (4 is now 3, and 5 is now 4).
But this was only for “child” tables like OrderDetail, QuoteMtl, etc …
Now it appears that when importing ShipHead records, new PackNum’s are assigned. And this is based on the Initial Pack Number setting and the highest current Pack number.
If I import PackNum’s: 12345, 12346, 12348, the Init PackNum is set at 2000, and the highest current pack num is 100, then the 3 new PackHead records are created with Nums, 2000, 2001, and 2002.
If I import those three again I get 3 more pack heads 2003, 2004, and 2005 (dups of the first three)
Is this normal for the Head table? Any other “Head” tables this happens to also?
Are you importing lines 1,2 4, 5 and not 3 for some reason? I do know from E9 using DMT you have to have all the lines when importing or it will renumber them.
My example was if a line was deleted during entry, after other lines had followed it.
But my real question is why the ShipHead.PackNum does this. OrderHed.OrderNum, and QuoteHed.QuoteNum don’t (the Line nums for their details do - but that’s not what I’m talking about.)
I’ve not had to try this myself, but I was under the impression for most things that the key fields, at least the ones generated by Epicor, you cannot control even if you enter what you want. Order, Quote, Time/Expense, Ship, Rcv ect…
I believe the main reason for having the key field is for updating after the record is in the DB.
Yes, this bit me the first time when I was importing job methods. Any gaps in the detail sequences were ignored, and were re-assigned numbers in sequence by the business logic. (If I remember, they didn’t like numbers that were not multiples of 10 either).
I ended up having to write a program that reassigned sequence numbers… in sequence before populating my DMT templates.