What are your largest order sizes, and how does that effect performance in Order Entry / Order Job Wizard?
We have a few orders that are up to 2,700 releases on one order. These orders are fairly slow to load and process.
Does this seem a bit excessive or am I underestimating what Epicor can smoothly handle?
WOW! 
I wouldn’t like to imagine what the performance of Order Entry is with an order that size, eek!
I would imagine that shipping transactions would be slower to process, at least marginally.
I’ve seen that with PO’s that have large numbers of lines/releases. Nothing that breaks the system, at least as far as I’ve seen.
Shipping definitely gets dragged down with a performance impact when processing packslips against these large orders. I’m just curious what other shops have done-- what are your largest order sizes? Are we way out there with this? What’s the average order size for an Epicor shop?
That seems higher than what I would guess is normal. What kind of industry/customer can order 2700 unique items in one order? It almost seems like assemblies are being sold as individual parts - that is the only way we could even get close to that count…
Someone from Epicor may be better suited to giving a reasonable limit.
It’s a long story, but our customers require serialization for each individual part, we use the Job # as the serial number, so each job is a qty of 1. We’ve looked at using actual serialization in Epicor, but it doesn’t quite meet our quality requirements for tracking.
We have no issues whatsoever with serialization in Epicor. I’m surprised that anyone would, it works pretty well.
Our serialization requirements are as strict as anyone’s.
Also, any time you alter a field’s contents with data that is not relevant to the field, you are going to end up in a situation similar to what you have now.
We’ve found orders with >1,500 lines start to perform very slowly in Order Entry/Customer Shipment Entry. As a general rule we keep orders under 500 lines, or split it into multiple orders.
We have a similar situation but we found that Epicor performs better for us if we enter individual sales orders and use consolidated billing/invoicing.
We typically have 100 lines and about 200 releases per order and we don’t really see a problem with Epicor slowing down. When a larger order of 500 lines and 2000 releases hits, we feel the performance hit. Mostly in Customer Shipment Entry - Packout.
Some of this has been remedied by creating what we call a “Bundle Job”. We take like parts (say metal hardware) and add them to one Part on the Fly Job that sits on the Sales Order reducing the amount of Lines.
At a previous company we often had orders with over 2000 releases. We actually had as many as 500 different ship-tos on the same order. From what you posted, it doesn’t seem like you have multiple ship-tos. We lived with this through V8 and E10. It was slow to process in order entry and shipping. It did get better through the different versions, but was not speedy on 10.1.
The only thing that made it slightly better was clearing the Ready to Process checkbox in Order Entry. We also used Avalara Sales Tax. If you leave the box checked and are using Avalara, you are causing a bunch of behind the scenes extra calculations.
Not sure if this applies to you, but it did make it at least tolerable for the big orders.
We have the same issue, we have sales orders with up to 5000 releases on an single order line (via EDI), this can take up to 6 minutes to process a single update and no change in 10.2.400.5. The issue has been reported to development but the dev DB’s they test the code does not have any examples like this in, so unable to replicate and not being addressed.
Jeff, were you able to do anything to help with the system performance on large pack slips? What did you find out from this issue?
