Our toughest EpiCare cases are the ones where we can’t replicate an error, but yet, there it is. It’s always trying to find that weird step that broke something, and often we can’t find it.
We create hundreds of orders a week, and maybe 1/2-1% will have some kind of error. Without being able to provide reproducible steps to EpiCare, the case dies.
How can I leverage AI to find patterns in the data that exists on orders with errors?
(Current issue is the Order Summary tab has incorrect tax amounts that are different than on the Order Header and Avalara Tax results tabs. Avalara says it’s Epicor, and Epicor says they can’t reproduce it, so the case sits.)
I can tag the orders to flag them, but I’m not sure how I’d get AI to sift through the data and find the nuggets (in this case, old and new tax amounts, and what changed between them). We’ve got systags, the Epicor DB (via BAQ export to excel?), with change logs.
Has anyone tried this? Suggestions on how I should get started? This would be a killer feature and an amazing Insights presentation too.
If you mean an LLM (Like Chat GPT) without a ton of context and I mean A TON of context this would be difficult at best. I think without a dedicated engine training on Epicor it would be a futile effort. You might be better off using it as a rubber duckie having it ask / interact back and fourth with you as you troubleshoot.
There is a ton of concerns regarding privacy, data ownership etc. I’m assuming you’ve gotten past that with your company? If not, then stop right here and go backwards. Any data you give ChatGPT that is your company’s puts you at risk if you haven’t gotten approval.
If you want to you can work in a walled garden with something like a LLAMA instance running on a local server but those are not nearly as powerful as OpenAi’s and can be cumbersome to setup and get working correctly.
but if you do want to try, here’s a quick how to get started
Install / Setup LM Studio
Feed it a bunch of relevant context data
Orders that worked, Orders that didn’t OrderHed, OrderDtl,OrderRel records
Ask it to look through them and find patterns that exist (or don’t) in one record or the other.
Feed it Epicor traces of Good Orders being entered and Bad Orders Being Entered (Client Side Tracing)
Do the same with server side logs (probably want to do this in an isolated environment so only you are entering things and recording logs)
and ask it if it sees any differences which may lead to your problem. Fine tune as you go
This would indeed make a fantastic presentation. If it has a good outcome. I like to think as a rubber duckie it would be great.
When we were getting PartDtl summaries wrong, we wrote a BPM to run after the transaction completed that would check the supply and demand and log when it was incorrect. Maybe you could do the same? Run a BPM (after Ready To Process or Alavara, whatever) and check if the Order Summary Matches the Header tabs and log those that are different right away. Do some quick and dirty observability and look for commonality to those orders that are wrong.
The thing I don’t think AI would resolve is that “non-reproducible” doesn’t mean it can’t be reproduced, but that it can’t be predictably reproduced with 100% consistency. Some bugs can’t meet those criteria, like race conditions, concurrency errors, design flaws, or exploits. There just isn’t an available support workflow path sometimes, even if the bug can be clearly identified by AI or Codd himself on a Zoom call from the afterlife.
At least the tools are there to clean up a lot of the things that we know go askew. Takes some technical skill, but it’s possible.
Jose - Great point about LLM input data going public. I’ll look into local instance. Thank you.
I wish we knew how to enter a bad order. Seems to be 1 or 2 bad orders out of 200, and who knows why. I could turn on trace logging on some sales reps that have bad orders, but it could just as likely come from orders being put on/off holds, credit holds, or shipping. Gotta start somewhere though.
Whoa! I think that might be the key. OrderHed.DocTotalTax and TaxSvcHead.TotalTax should match, but don’t. I made a BAQ to show the orders where they don’t match. Time to figure out what BO to hook this BPM onto. Might as well add a SysTag as well.
@kananga - Great points. We need to identify the error close to the source, so it can be fixed (rather than creating more work by having A/R send refunds to customers). Ideally, get Epicor interested in finding the root cause.
I can attach the BAQ if anyone is interested in checking their data. SalesRep isn’t needed, I just added it in case there’s a pattern there…
In later versions of Epicor you can turn on Tracing “remotely” for certain employees. Not that I recommend you do this for a long time, but if its consistent enough maybe you can enable tracing on some remote users and when an order comes up bad you can go dig through / find the old trace.
On the occasions users report something like this on custom things that I have built, I can usually figure out what’s going on pretty quickly (immediately if the code is fresh in my head)…
My fear is that reports like this aren’t making it anywhere near the relevant Epicor Developer’s ears. Support seems to put up such a wall between us users and Development… I would guess the original Developer doesn’t hear about a problem until it is 100% verified and reproducible on demand.
Am I wrong @aidacra?? Are there channels where vague wishy washy reports make it in some form to the Developers/Engineers?
Or do we all just need to wait for @hkeric.wci to break out the SDK and figure out all the bugs for us
Do you have a test database that you can run side-by-side with live? So far all my weird anomalies that have popped up in Live, I’ve been able to recreate in Test. Eg entering an errant order verbatim into a recently restored Test should replicate the issue.
We’ve got several test environments, but our reps don’t have the bandwidth to do double data entry. If I can zero-in on some common trigger, I can ask them to enter those in the test environment. So far looking at the orders, there’s nothing in common. My next rabbit hole is to see if changing the shipvia (and misc header freight cost) could have something to do it it.
Can I sign them up for our vNext verification testing?
Kevin, what do you mean by that? Have trace = true as a condition, and do additional logging with a BPM? Neat idea!
