Yes, the Pre-Create returns the outputs based on the inputs of the HeaderMiscCharges table values. It will return the misc code, misc amount as well as some other variables from Epicor, including the misc percentage, which is often 0 as many customers do not use this type of misc charge. It will also return the associated HeaderGLAnalysis for each misc charge based on the GL Control and GL Account configured in Epicor.
Can you show me the trace? Or the workflow?
From what we figured out yesterday, there is no way that this is working, but it could be an Epicor version thing.
What version of epicor is this working with?
I wonder if it’s a GL account issue? I did notice that the system is returning a blank GL account row. When I do this in Epicor, I get no GL account automatically.
Huzzah!!! that was is. The Gl wasn’t set, if I add that GLHeaderAnalysis line and fill it it, it now sends me back an error that says it’s wrong (because it is, and I don’t know anything about out GL codes), but at least there is a path forward to fix that. So if that isn’t set, and Epicor doesn’t set it automatically when the header charge is created, instead of sending back the error of missing GL line, it just doesn’t send the HdrMsc back. (still a bug in my mind… but at least I have a valid workaround now)
Of to find someone who understands the GL codes and finance.
2 Likes
The plot thickens even more. Apparently we don’t allow header misc charges, and these need to be project line charges. So maybe this will be useful to someone else later, but now I’m off to another which goose chase to actually as a job misc charge line. (I guess that means I’m back where I started)
1 Like
Yes, the typical HeaderMiscCharges is rather straightforward once the associated GL Controls and related GL Accounts are in place. The Job Misc Charges is an entirely different beast as these are not related the same as the other miscellaneous charges. We had to create several datalinks and all sorts of workflow handling to make this work. These were achieved with a combination of REST calls using the RPC and OData methods.
Yeah that’s another big issue with this. There’s no way to ask for any help because anything outside of their basic automation workflow is “custom”
Looks like you are having fun! Good luck!
My experience is the field groups can be wiped out if populating data into the field group, I’ve had a precreate that looks up all values into temp fields, then use a set field group to set field group. My experience is datalinks can fail to produce all output variables if not all inputs are valid.
Easiest way to see resolve the issues is test a precreate in integrations without the workflow to see if the precreate in an isolated state can handle the value set on the import. I know this sucks but field groups are usually the enemy and the datalink needs validation without the use of fieldgroups. Once established that the datalink precreate handles the values, development can resolve the workflow.
Nice way of putting this.