The UDMapTable has an auto-increment key MapTableID so if you install this cab it will use the file name as the order to install:
84be2f7a-…
60479835-…
bdd82bb9-…
What happens is that upon install the auto-increment key will make 84be2f7a 1 and 60479835- 2 and bdd82bb9 which carries MapTableID 1 in the xml will ask if you want to overwrite since the auto-increment gave someone else 1
and if you click yes, it will overwrite 84be27f7a- which had its own MapTableID but the auto-increment messed it all up and when you verify which ones were installed you will find yourself sometimes 2-3 short because it never added them since it thought it needed to do an Update/Overwrite.
If we were to follow the initial order as shown in the Solution Workbench we would be fine. The Fix would be parse the import by MapTableID and not filename.
If I change the files to _1, _2, _3, _4, _5 and rebuild a manual cab, it works.
Ohhh … so the files are sorted taking the numeric part first and makes them a “number”, such that 84 comes before 60479835. But regardless of this, _bdd8...need to be processed before either of those two.
But why does the installer process them numeric-alpha order, at all and not in the order based on the MapTableID? Or is that the bug?
What happens is that upon install the auto-increment key will make 84be2f7a 1 and 60479835- 2 and bdd82bb9 which carries MapTableID 1 in the xml will ask if you want to overwrite since the auto-increment gave someone else 1
So …
84(TableID=2) becomes TableID 1 (no TabledID 2 exists to update)
60(TableID=3) becomes TableID 2 (no TabledID 3 exists to update)
BD(TableID=1) becomes TableID 1 (overwriting 84 as TableID 1)
CF(TableID=5) becomes TableID 3 (no TabledID 5 exists to update, so next available number)
F9(TableID=4) becomes TableID 4 (the only table that ends up with the right TableID)
The <AppsBuild ...> XML lists them in “literal” alphanumeric order. But they’re processed in “intuitive” alphanumeric order. So even if they were in the correct order in the `… branch, they would have been processed “out of order”.
What mechanism actually initiates processing them? It seems like a FOR loop that orders them by filename.
It does it by filename. I modified the manifest.xml and changed the order it didn’t matter. Only when I changed the filenames to _1, _2, _3, _4, _5.xml it processed them correctly.
I just modified the cab and rebuilt a new .cab with microsofts cab tool.
Epicor just needs to modify the Import Handler to load the XMLs into memory and sort by MapTableID and import in that order.
84(TableID=2) becomes TableID 1 (no TabledID 2 exists to update)
60(TableID=3) becomes TableID 2 (no TabledID 3 exists to update)
BD(TableID=1) becomes TableID 1 (overwriting 84 as TableID 1)
CF(TableID=5) becomes TableID 3 (no TabledID 5 exists to update, so next available number)
F9(TableID=4) becomes TableID 4 (the only table that ends up with the right TableID)
Now how do I report this to Epicor without confusing the hell out of Support and them asking for 2-3 webex sessions. I always tag @pferrington in tickets but they dont send him any I should try @JeffLeBert
Nathan Anderson was supposed to make a special bug reporting portal, he never got around to.
if I sort even in explorer by file name.
I always tag 
I should try 
I can even let you borrow my login. Consider it a Community Service opportunity.