We’ve had a large client for years who has a custom website and custom order processing system. We told them in the beginning to keep those and import summary data daily into Epicor as their largest company does 11 million orders (3 lines average) per year. Their ‘manufacturing’ is essentially a photo printing service. Orders are highly seasonal.
Now they want to do all the order processing in Epicor to have a unified system, and if it can’t handle it, are ready to toss out Epicor.
Do any of you have experience with E10 dealing potentially 3,000 orders per hour assuming money is no object relative to hardware.
Should we run, or is it doable?
Anything is doable… now is the issue getting the Orders Into Epicor. Or the whole Order Process?
Getting the orders into Epicor can be done, I’ve seen the Demand Management Process can handle a lot of data pretty quickly in my experience.
Not the Order BO itself (that thing is a pig), but if you go through Demand Entry I think this can be done
I’d give it a shot (test it) see how quickly you can pump 1K orders into Demand Entry
Also reach out to Epicor they may have some tricks up their sleeve.
Man that’s a lot of data, how are tehy able to process that many orders so quickly? YIKES
@Edge @Bart_Elia thoughts?
With my experience in E10 (which is a fraction of Jose’s) - I find that due to all of the checks and balances of the BO’s, high volume (at least at high speed) transactions can be less than ideal.
Perhaps a custom solution to mitigate the load and process the orders on the backend?
I’m with Jose, we don’t do anything near 11 million a year, but we do around 1.5K a day at two lines through the Sales Order BO and it’s an awful slow and sad little pig. If you can get them in there without plowing through the sales order BO it might be able to be done.
Also maybe if you can trickle in instead of dumping 3000 at a time in-there you may have better luck. A one to one (real time) integration of some sort may be able to pull it off specially if you can do it somewhat async directly from the web app (or whatever)
Start syncing the order as the customer “builds” it directly on the site, better yet have the orders be placed directly in Epicor. That is create the interface (web app) to directly intereface with Epicor.
So you don’t have to import 3000 order, rather the orders are created in Epicor to begin with.
Dont steal my thunder dammit
we have developed a service connect workflow piece to process over 3000 order releases in 60 to 90 minutes including the validation task
Just curious, doe these 3,000 orders/day go to existing customer(s)?
Or is a new customer potentially required for each order?
There are a few options here. If you want to look at engaging with Epicor CSG they can utilise the High Volume Import framework which we have done with some other integrations - It is a little harder for partners to do this at the moment.
As each order is a unit of work you can run multiple sessions to import the order
- Concurrent Sales Order Orchestration (Azure Function from Queue multiple threads)
Azure Functions scale and hosting | Microsoft Learn
There are a few tricks to optimise this like ReadyToCalc and some option parameters to tell the system you do need everything refreshing on each save.
- ECC Service is optimized for taking orders and processing them you can use this without using ECC
- Demand Management Import
- HVI CSG Import
I thought Yeti Coolers were using Demand Management for all of their orders before they moved over to SAP. I’m not sure what their final volumes were but I can get you in touch with the guys who put it together for them if you want.
really sorry just seen your question today
3000 to 40000 sales releases go to existed customers twice a week - we designed it that way to do a contract review before adding any new customer-
any advise in achieving high order volume via SSIS ?
we receive 60 orders approximate over 300 lines per day per customer i.e circa 10 to 15 lines per order.
at this moment, dashboard reads a csv file(our partner edi system drops the file) and user press button in the dashboard and below process are invoked.
- Part Validation (part on hold/inactive/exist)
- Order creation
- Stock reservation/cross-docking
it takes roughly 90 minutes to finish all the above activities. we are not using service connect.
we are expecting our order volume to increase as we are doing more price feeds/edi/e-commerce.
for seamless integration, we are left with service connect/rest api/ssis tools. since epicor going more rest api / jitterbit, we are not interested in service connect tool.
we do not have demand management/ECC Service license. we are looking onto that option as well. at the same time with demand management/ECC Service license module reservation/crossdocking automation need to be written?
we are not on cloud.solution based on Azure is not in this picture.
as our in-house team have good experience on ssis with other products, it will be really helpful if someone advise in integrating epicor with SSIS.
2nd phase - send invoice from epicor to edi such as Amazon vendor portal this can scheduled
Really, REST is the only solution without Service Connect. SSIS won’t use the business objects so you’re hitting the database directly which is really not a supported strategy by Epicor.
DMT is a potential option if you have it. You might be able to use Epicor Functions if you’re at 10.2.500+.
You also might get better throughput if you break up the input file and run parallel inputs, i.e. scaling out.
Can we not use ssis script editor task(write c# code), create epicor session just like how we do in visual studio, and process orders? We thought about DMT but orders from our edi partners do not come in the file format which DMT expects.
At this moment we are doing background worker, but havent thought about multi threading. I will take it.
We are migrating to 10.2.500 from 10.1.400. Scheduled for Easter break.
Thanks for your thoughts Mark
Sure. As long as you’re using the Business Objects. I think that Stephen made some good suggestions above which included multiple queue processing.