Can the system just not handle large volume?

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 :cry::cry::cry:

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

Still though 5 days…. Sigh

15 Likes

Sigh.

Meanwhile, you could run those 5,000 records into Salesforce in about 30 seconds. With REST you should be able to do the same thing in Epicor.

Off topic. The Salesforce API and bulk API is awesome. It’s lightning fast.

2 Likes

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

10 Likes

:100:
A massive undertaking to change some of the core functionality. But it would free up some of the 40 year baggage being carried along.

2 Likes

Did you run into problems with Ship Tos? When we load hundreds of Ship Tos we see the same slowness. The UI stops working in classic even.

1 Like

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.

1 Like

It’s the same retailer :joy::joy::joy:

3 Likes

Red one or Blue one? :wink:

Both can also be the correct answer. :grin:

1 Like

Yeah we use one time ship toes to get around that

But yes similar issue we have one customer with 1500 and when that guy needs updates I take a sick day

2 Likes

Yes :winking_face_with_tongue: lol

1 Like

I’m sure you team loves you for that. :rofl:

The don’t know! Don’t tell them!

3 Likes

At least we aren’t the only ones, I guess.

Genius Youre Smart GIF by GEICO

1 Like

Sing it brother!

Sci-Fi GIF by Amazon Prime Video

1 Like

Me staring at the progress like … that’s 223 rows in 3 hours .. :skull:

Its Been A Long Time Waiting GIF

2 Likes

At least you’re not SaaS. You have some options we don’t.

2 Likes

Office Sloth GIF by Disney Zootopia

8 Likes

Imma rename my appserver FLASH

6 Likes

Yeah someone suggested we SQL ram

It but I looked at the BO and there is too much other crap with Bookings etc that I don’t want to risk

Plus every time it recalculates line and header totals etc

Just not something I wanna risk… plus

coughs loudly WE NEVER UPDATE SQL THATS AGAINT THE RULES cough :sweat_smile:

5 Likes

Schitts Creek Comedy GIF by CBC

1 Like