Sales Order Testing - Adding Bulk Releases

From this thread, @utaylor and I did a little testing.

I wrote up a a little function to add bulk releases to sales orders.

This function:

  • Reads in some CSV data
  • Converts it to a DataTable
  • Breaks it into Orders
  • Breaks it into Lines
  • For each order - Turns OFF “Ready To Process”
  • For each line - Add Releases (Updates Release 1, adds remaining releases)
  • Turns ON “Ready To Process” for Order
  • Logs it all to the System Monitor

This IS NOT a finished product.
This IS NOT a finished product.
This IS NOT a finished product.

It required these two libraries:
SalesOrderTesting.efxj.txt (124.8 KB) <-Remove.txt
SysTaskMonitorLib_V2.efxj.txt (10.9 KB) <-Remove.txt
Make sure you add your company to the security tab for the libaries.

Inside the SalesOrderTesting Library, there is a function called DataHolder.
The sales order release data is stored in the notes section of that function.
You edit it, and paste in data in this format: (Remove all text first)

Company,OrderNum,OrderLine,OrderRelNum,ReqDate,SellingReqQty,ShipViaCode,UseOTS,OTSName,ServRef1,OTSContact,OTSAddress1,OTSAddress2,OTSCity,OTSState,OTSZip
MS67964,263499,1,1,7/28/2023,500,ROB,1,TestName,,TestContact,TestAddress1,TestAddress2,Monroe,LA,71202
MS67964,263499,1,1,7/28/2023,500,ROB,1,TestName,,TestContact,TestAddress1,TestAddress2,Monroe,LA,71202
MS67964,263499,1,1,7/28/2023,500,ROB,1,TestName,,TestContact,TestAddress1,TestAddress2,Monroe,LA,71202
MS67964,263499,1,1,7/28/2023,500,ROB,1,TestName,,TestContact,TestAddress1,TestAddress2,Monroe,LA,71202
MS67964,263499,1,1,7/28/2023,500,ROB,1,TestName,,TestContact,TestAddress1,TestAddress2,Monroe,LA,71202

This function assumes the order exists and it has lines. Also that One Time Ship To is enabled for the customer.

After that, we ran the function AddSalesOrderReleasesTest2 from Schedule Epicor Function

You will see this in the System Monitor in Classic:

.

Here are the results (VERBOSE) from @utaylor . 1000 Releases:

Elapsed Time: 13:04:183 Total Process Time (Minutes:Seconds:Milliseconds)
UTaylorTest.xlsx (88.7 KB)

2 Likes

If anyone else wants to do some testing, I’ll answer any questions.

As for @utaylor and I, we still need to test the same thing with ready to process on for it, even though we know it’s slower, and also a dmt of the same data, both ready to process on, and off.

I thought we did that at the end?

No, I mean test it with it running with ready to process on the whole time.

Why do we need to do that though? Like is there a business requriement?

I though ready to process at the end was better?

Or is that last sentence the reason you are saying we need to test it with ready to process on?

To see the difference in times. Just because we know it’s faster doesn’t tell anybody else much.

1 Like

Right, that’s what I figured.

1 Like

If you don’t mind timing it again, I’ll send you the code changes.

My times don’t mean a lot because we don’t do sales tax and such.

And I don’t have DMT to do the other tests.

I don’t even know if we were doing sales tax calcs in the order I tried it on… would need to check that out real quick.

O-Yeah we did. :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire: :fire:

Code sent.

Testing this afternoon!

BulkOrders.csv (1.7 KB)

Could the process also work on something like the attached? Looking for something that would monitor a network shared that a standard file layout is dropped and then it would import the file as open sales orders. We have customers that will send us order files in CSV.

I can’t look at that right now but from what you’re describing I wouldn’t see that as being a problem.

Looking at it now, that’d be making the order from scratch? So this in particular wouldn’t work, but could certainly be done relatively easy.

Quite a few here are doing something similar already.

Oh wow, here are the results of testing with my program with Ready To Process ON:

03:09:07:018 → 3 hours, 9 minutes, 7 seconds, 18ms

For comparison, the time before with my function turning Ready To Process OFF at start, and then back ON at end was:

00:13:04:183 → 0 hours, 13 minutes, 4 seconds, 183ms

I think we have certainly proved @timshuwy 's point at least ! :rofl: :exploding_head: :dumpster_fire:

Now if we can just convince @utaylor to do this same test(s) with DMT vs this program, we can see if this is faster than DMT as well.

Tests still needed:

  • DMT Ready To Process ON at start
  • DMT Ready To Process OFF at start, then turn back on.

.

I will see if I can break out the individual times of what we ran and do a graph.
I wish I had thought of that, I would have made the log json or something really easy to parse :rofl:

UTaylorRseults2.xlsx (90.6 KB)

1 Like

I’ll do the DMT cause I was asking my CFO who did the test with the DMT a month or so ago and he couldn’t remember exactly how long it took.

1 Like

Love the graph man.

1 Like