I feel very certain there was a thread about this some time ago and somebody explained why a ubaq that works fine in a classic dashboard fails in a kinetic grid. But I can’t find it. Can anybody explain what is going on here?
I have a UBAQ that works fine in the baq designer and in a classic dashboard.
I added a PCG to my layer and set everything up to be able to run the update but when I click save (triggering the erp-baq update to run) I get: “ToSite references invalid value. Part references invalid value”.
What is really odd is that those two fields are in my dataset with valid values, and are both marked mandatory in the update mapping, but the names of the fields in the error message don’t match anything. For example in my dataset the value is ToPlant not ToSite. Also I have PartNum in my dataset not Part. Where is that coming from?
My vague recollection of the other thread on this topic was about how the kinetic grid is sending back all the fields to the UBAQ and that is causing some kind of problem. Is this a wild goose chase or is there a way to make this actually work in a kinetic grid?
Is mapping set correctly, like between ToPlant and ToSite?
Actually, if it works in classic then it should be.
Idk, i would compare trace data for both call - classic vs kinetic
So it seems like this issue is still not solved in 2024.1 although we have made progress - now instead of working none of the time it at least works some of the time. When watching the network calls, sometimes it submits the value to be updated and gets back the updated value as expected. Other times it submits the value to be updated and gets back a zero instead of the expected value (no error). Updating the SAME record with the SAME value in the UBAQ directly works fine so the problem is not the UBAQ itself or the data. And the problem isn’t the kinetic design - its correctly mapped to the right field otherwise it wouldn’t work most of the time.
Why WHy WHY
Of course support will not submit this to development because its not reproducible.
To cut down on these reproducibility complaints, I created an Epicor Idea (with only 6 votes so far) that would allow customers to send .HAR (HTTP Archives) to demonstrate behavior in the browser. These include all of the same things we see during F12/Dev Tools. Some tools (like Playwright.dev) include screenhots. Support could include a command that would dump settings and other environment variables to be included in the recording. While these files can get large, they are way smaller than uploading a database.
Voted. It drives me absolutely batty that support will not submit basically anything to development anymore, unless you are willing to subject yourself to an hours-long webex session where you literally teach Epicor’s own support representatives how to do development in their own product, click by excruciating click. The won’t accept uploaded solution packages nor screen recordings or basically anything else. I just cannot.
report this