Hey Everyone. So far I’ve been bugging @MikeGross but I need some help pointing me in the right direction.
What I’m trying to do is to set up IDC to export the XML data of the header and lines of AP invoices. I’ve been able to get the XML out of IDC, and applied an XSL transormation to get the XML out that seems to be working. I can match this up to the header information in EDC when I bring it in to my document type.
This is the output of the XML, header information all has it’s own tags, and the Lines_Table has it’s own tags for each line.
So what I’m missing is, how do I relate this sub-table of lines into EDC. I see in my document information, there is grid for line items, but I can’t figure out how to tell ECM to get the line info from the XML and populate line information on it.
Is my XML a wrong format to do that? (I just took @MikeGross s transform and it seemed to “work”). Or is there something that I’m supposed to be able to do be able to map those fields?
I did play with the xpath and I can get ECM to display those fields, but when I try to map them to anything, they don’t seem to do anything.
If you have a good help video or know where to point my in the help docs to see how to set up line information that would be awesome! I’m finding this system to be less than intuitive.
@Banderson I think it is just a mismatch on the field table grouping. Looking at your screenshot you have Items in front of all of the LINE_ fields, but you have Lines_Table in the file.
This is from SOA, but the same applies. Table name from the DFD, field group matching in ECM import and the XML file.
Fields names in DFD must match even upper and lower case the field names in the XML.
That was it @gpayne . Fiddly bits that’s for sure. Thank you!
It’s annoying how you can custom map the header stuff, but not the lines stuff. It should either ALL have to match, or all be mappable. Oh well, at least now I know what to do!
I made a ECM only app server for AP V1 and manually editing the web.config. It has been a while, so I don’t remember the section we added, but I had a case and sent the fix to support once I got it running, so I can find it.
Yep - recreate the connection and it shodul work with the newer Appservers.
As for the new workflows - Epicor states that there is a Professional Services component to the installation and that you should enter an EpicCare ticket and request the download and PS time to install the V2 AP Automation stuff.
I managed to get the download, but I needed their help to make it work and managed to be sweet talk them into the fix without the PS because I had already installed the package and opened my ticket under the issue that it didn’t work… they were kinda upset with me for that.
It’s an ECM Import package but requires some tweak to make it work. Maybe they have that bug worked out. If you get stuck let me know and I’ll try and find the emails from back then to see what happened.
I have copies of the old ones. They are broke/not finished, but it’s a road map so I could work with those. After watching the education videos the mechanics of it seem pretty easy to understand, and I can follow along with what each one is doing. I’m assuming we’ll need to modify the work flow for us anyways because we manage to never do anything the standard way. Do you think it’s worth bringing them in? Or should I just modify/copy from the existing one’s myself?
What kind of differences are there between the workflows?
On a more basic note. The integration points seems to be datalinks that are pointing to a specific environment. So if you make a work flow pointing do your test environment, do you have to go find every data link and change it to the production to push it to production? That seems silly and makes me seem like I’m missing something very basic here.
There are only a few, and for AP Automation I’d delete the old unused ones and dump the old Integration. Keep things clean and all. That’s what I would do…
V2 brings in the AutoMatch functionality and doesn’t require the Temporary AP Group to do its work. Both are pretty major changes.
Yes - Integrations are just that - but they are basically all in a DLL and that is where the REST/API stuff is that they are using. Regular datalinks can be SQL or API stuff, but you have to build it all yourself.
As for Housekeeping - I have a Dev ECM VM, so it points to Dev ERP - and Prod ECM points to Prod ERP. I do however roll all my own datalinks with both Prod and Test/Dev versions mostly b/c my Test/Dev ones act as backups in case I need to test anything on the fly. They all live in BOTH Prod and Dev ECM. It’s a bit of a PITA but I like my “insurance”.
