ALSO! keep in mind that my thoughts here are mostly theoretical through recent observation. I’m just starting, so I could very well be WRONG on some of these ideas. So if someone has some better/deeper insight, I welcome any and all corrections.
1 Like
Is there anyone from Epicor here that has some authority with the ECM support systems? I just got a response back that since the workflow is “new” that it’s not supported by support and we need to engage professional services.
It’s a bug! This isn’t something a consultant can fix!
1 Like
See my use case is not sending TO epicor, it’s getting FROM epicor and updating field group rows with the changed field .
Par for the course man.
But there are some contacts. I’ll message you.
Similar to “escalation”
1 Like
I’ll have to test to verify, but I believe you need to populate all fields in the field group or it will blank them out. The one thing I am uncertain of is in using the “From” direction from the datalink as this is the one that usually only updates what you ask of it. It’s typically a best practice to always populate all of the field group fields, though, to avoid things being wiped out.
1 Like
Agreed. I am a consultant and I am finding the same issues. With that being said, I have something to test and will update with a resolution if it works.
1 Like
And that’s the thing victor, so to add one field haha, I have to make a custom datalink and send 10, 50, whatever amount of inputs to it from my field groups so that I can assign them again in the output to avoid erasing them haha it’s wild
Lol Yea, it’s not exactly ideal. I’ve added my fair share of temp tables to accomplish things and used the “Append Rows” option where applicable.
I’m curious as to the “one field” issue you’re having as it sounds like you may be adding an entirely new field to a field group and not just a new row of data into an existing field group. Is that the case?
I think I am blending.
I have one case where I want to do some logic and fill out other fields in the field group that were originally empty after the first step only returns/creates data in 3 of the 15 fields.
I have another case where yeah I added a field to the field group and now I need to make an action or step to fill it out AFTER epicor’s own logic.
I’ve not been following this too closely, but I’ve got the gist. I was able to demonstrate to support that my last problem was a bug, and pressed the issue to the product manager (at the time) which got me to the Dev team. Ended up having a call with Ira and David. Maybe we can do that again if the official channel breaks down.
2 Likes
I’ve got a response from support saying that they don’t think it’s a bug because no one else has complained. (insert major eye roll here)
So since they don’t seem to be able to run a test to verify that it’s working or not, does anyone else use header misc charges and can get me a trace that shows whether or not the V2 workflow returns data on header misc charges?
I am not certain of how to run this trace, but the recording from ECM definitely shows that entering miscellaneous charges in the head inputs will bring back matching outputs, including Header GL data. We do these all of the time and they work without issue.
I have found a bit of a workaround as to line miscellaneous charges which amounts to basically running the Pre-Create, adding the line miscellaneous handling in an action (including subgrouping the data under the line) and then running a second instance of the Pre-Create. Of note on this is that this will create the line miscellaneous charge as “Manual” versus “PO Line” in Epicor. From my testing, the GL gets assigned to the same account as the PO line it is for, too.
Job miscellaneous handling was accomplished through several different datalinks and workflows configurations to get the results we wanted. The issue with it is that it has to be done in steps so the datalinks and workflow need to replicate that.
recording/trace, same thing.
Can you confirm that you are running the V2 version of the integration? I don’t know when exactly they came out, but it was at least sort of recently.
Yes, the Pre-Create step is new to v2, which came out for Epicor 10.2.600 compatibility. The v1 workflow handled line miscellaneous charges in its own datalink so it was easier to manage. Each of the versions have their pros and cons.
Do you have anything else populated on the hdrMsc inputs besides the MiscCode and the Amount?
This is what I’m sending in. I can’t figure out why it won’t return anything.
It’s the same thing with create. But it creates the misc charge in Epicor, just doesn’t send back anything.
Ok, so we did some debugging on the server to see what the heck was happening under the hood (since I can’t get anyone at Epicor to even test it…)
The issue is with the UpdateEXT and MatsterUpdateEXT. It’s not returning the table APIHAPInvMsc. We were able to fake it out by re-adding the rows on post processing, so I’ll probably do some lookups to populate it. I put in the ticket that it’s a problem with Epicor proper. Maybe I can get some traction with that?
Nope, just those two variables. This is the case for each miscellaneous charge we may require. This is being done in a workflow step created just before the Pre-Create which populates the HeaderMiscCharges field group.
Are you getting the return back from Epicor? Or just ignoring it as a workaround to not delete your Misc charge lines in ECM?
Sorry to keep pestering you with questions, I’m just not seeing the same thing that you are and I’m trying to figure out what the difference is.