I feel like the more I use it the less confidence I have on Epicor ability to handle large volume.
We have an order with 5,000 releases ( yes that’s a lot of releases I know! )
But we are shipping to 5000 different locations (we are distributing)
We have to update all the releases we accidentally closed a bunt of them incorrectly
So we have to open several thousand of them
DMT eta to do OpenRelease = true 5 days….
Tried it with direct Rest calls .. 3 days….
Now I get that 5 thousand release is a lot. But the BO takes just under a minute to save / open a single release….
That is just ridiculous. No it isn’t BPMs we turned those off no it isn’t tax connect we turned that off…
The call to open release works fairly quickly but it returns a GetByID at the end of every call. That is 7 (megabytes) of compressed data for every call that is transferred and there is seemingly no way around it
We’ve tried moving the calls to happen on the server to slow transfer time but that difference has been negligible
So I guess we just have to wait 3-5 days
And yes I could open a ticket but it isn’t an issue of a bug it is working as designed I guess it just wasn’t designed for high volume throughput
Yeah the logic is built on the Bo to do a GetByID at the end of every update to OrderRel
We even tried UpdateExt to no avail. This goes back to the whole they need a ground up re design they are dragging 40 years of tech debt (yes a lot of experience too) but a lot of tech debt
A a previous employer we’d get orders from a major retailer everyone knows and shopped at we’d have sales orders of a multiple lines with 5k-ish releases per. Yes I did say major retailer. We had a service connect flow that’d do the work as it’d take days to get the orders in, released, and shipped. (also some custom SQL SPs but don’t tell Epicor). Just to get it to work.
I can’t imagine how much worse it’d be now with Kinetic UI in the mix.