This is what I did to fix it, in hopes someone with the same problem goes a Googlin’…
We did a minor upgrade from 10.1.600.5 to 10.1.600.20. Our 856 and 810 outbound maps immediately started failing.
I compared the new (broken) output files against ones that worked before the upgrade. The schema didn’t change (as I would expect in a minor version upgrade), but my data was coming out in a different order than it was the day I created the maps:
I figured I could go back and remap all outbound documents for all trading partners (this could take days), or I could try and get Epicor to spit the data out in the “good” order so the map could interpret them with (hopefully) no changes.
There is an option in Report Style under Actions >> Generate EDI Definition that you should run after you set up your RDD’s and have them working. It generates a CSV reference file that effectively “locks” the schema for you. It will protect you against additions/subtractions (like UD Fields) to any of the tables included in your RDD, but apparently it doesn’t influence the order your data is sequenced.
So I went to the Report Data Definition (create a backup of your RDD with the Solution Workbench just to be safe!) and found the Sequence number the tables are listed in. Shot in the dark, I rearranged the Sequence to match my working Datafile:
I reprinted all of my outbound documents and the map then processed them with no issues. I then had to do the same thing for my other outbound maps’ Report Data Definitions.
A good lesson here is to grab a sample set of any working EDI output files that Epicor generates and save them to compare to if you need to later. The mapping software we use (Tie/Kinetix) deletes these files when it processes them. You can write custom workflows to back the files up, but I opted to write my own system to keep tabs on EDI send/ack status and I preserve 30 days worth of these files in case I need them–and last night I was certainly glad I did.
(WHEW, all columns are green again!)