What does "Ready to Process" mean? Make SURE you understand!

Over the past several weeks, we have had several customers report the following:

  1. They have complained that there is a possible issue when entering large orders.
  2. When queried, we find that the READY TO PROCESS is TRUE while entering orders.

If you are not aware, the SYMPTOM (#1) and the cause (#2) are very much linked, expected, and documented.

Facts:

  1. Ready to Process” tells Epicor that the Order is ready to have sales tax processing completed.
  2. When this box is CHECKED: every change after checking it will cause sales tax to be recalculated (since something could affect the tax rates).
  3. When this box is UNCHECKED, sales tax is NOT recalculated with each line entered
  4. Calculating of sales tax uses Tax Connect (aka Avalara), and this service does take a small period of time to gather the information for each line, send to Avalara, and after retrieving the rates, it repopulates the sales tax for the lines and the order.
  5. if you also have change logs turned on for the order header and order details, then the every call to Tax Connect is recorded as an additional change in the log, again affecting the performance.

The CHALLENGE is that if you have it turned on, and you enter a 50 line item order, the system has no way of knowing that it doesn’t need to calculate it every time. It doesn’t know that after the first line, you plan on entering 49 more lines.

The PURPOSE of this field is to tell Epicor that you are “ready to process” this order.

The correct procedure for the best performance would be to:

  1. create a new order with this checkbox turned OFF
  2. add your lines
  3. check the box when you are ready to process

If you plan on making a bunch of changes to an order, the best procedure would be to:

  1. turn off the ready to process
  2. change the order
  3. check the box when you are ready to process

I will jump off my soap box. Back to your regular work.

10 Likes

Why you gotta call me out Tim :joy::joy::joy: thanks for posting definitely something to be aware of

If you have Book Sales Orders set in the company config Ready to Process also starts the writing of changes to the BookOrd, BookDtl and BookRel Tables for every price, quantity and date change you make to a sales order.

4 Likes

Hey, I left your name out of my post @josecgomez Hahaha (safe harbor)

2 Likes

And that is the reason why we have it turned on by default @gpayne CC: @timshuwy we use Bookings to look at trends over time and if you don’t have ready to process on it doesn’t record bookings and or changes to lines and releases.

In my opinion there should be a separate flag for tracking bookings because we rely pretty heavily on them and need them so we take a hit with avalara

5 Likes

Wait… ok, that is new / news to me… Ready to Process and bookings (in my opinion) are two different things.
At this point, probably cant be reported as a bug, but we should at least get an Epicor Idea posted to segregate these two items. I would vote for that one.

1 Like

The way it reads in the field help is that Avalara uses the book tables to detect a change to know if it needs to do another inquiry, so they are comingled.

But something like Ready to Calculate Taxes like in AR invoice entry could work.

1 Like

BUT WAIT…
I just did a test…

  1. turned off ready to process
  2. did a change. Nothing entered into the booking table
  3. turned on ready to process
  4. Booking table now updated…

So, I dont know that there is a problem. Bookings DO show up once you click ready to process.
@josecgomez are you really needing all the inturum changes while it is NOT ready to process?

I can test this, but is this still true if you do a single whack via API? (I’m guessing yes.)

Reason is that our ecommerce site does this, like so:

The business object is called SalesOrders

With the JSON like this:

{
  "Company": "xyz",
  "PONum": "Jason",
  "OrderNum": 0,
  "CustNum": "219",
  "ShipToNum": "",
  "ShipViaCode": "UPS",
  "OrderDtls": [
    {
      "Company": "xyz",
      "OrderNum": 0,
      "OrderLine": 0,
      "PartNum": "10032",
      "UnitPrice": 0.99,
      "OrderQty": 1,
      "ProdCode": "PDCPARTS"
    },
    {
      "Company": "xyz",
      "OrderNum": 0,
      "OrderLine": 0,
      "PartNum": "20288",
      "UnitPrice": 0.99,
      "OrderQty": 1,
      "ProdCode": "PDCPARTS"
    }
  ]
}

Of course, I could just ask them to turn ReadyToProcess on and off at the beginning/end.

Right but that’s out problem @timshuwy we need bookings to be recorded ANY time regardless of ready to process flag or not.

If we leave the ready to process flag OFF by default what happens is our people enter an order enter all the details and walk away (no bookings)

Eventually someone hits the Ready to Process Flag (sometimes) then a booking gets created GREAT!

Then they come back uncheck ready to process… make changes … walk away no booking update.

etc

Bookings are pretty essential and the fact that users can just wonders off and not mark oder ready to process means we don’t get that booking record.

1 Like

I guess I’ll be that guy.

That sounds like a personnel and procedural problem.

Confused Robert Downey Jr GIF

If you can figure out how to get users to always click the right buttons you sir will become a QUINTILLIONARE in no time.

4 Likes

season 3 GIF

3 Likes

SO, we have another question:

How do we make this so that your users stop forgetting to tell us when they are done with the order?

  • Purchasing has the same concept… they must approve the PO for it to be processed
  • Jobs must be RELEASED for the work to be done
  • Packslips must be marked for them to be invoiced.
  • Finance has to post their groups
  • Engineering has to check in their parts

But Sales… they just get a pass on their orders not being properly marked as ready?
Have you considered a dashboard that runs showing all unmarked sales orders?
Have you considered a nightly function that sends an email to the sales team for any orders not ready for processing?

Again, i go back to the previous statement. Order Entry will be more efficient if the flag is off during entry, especially on larger orders.

Excuses Getyourown GIF by The Tonight Show Starring Jimmy Fallon

3 Likes

We had the OrderHed CCTotal, CCAmount, and CCTax fields turned on in change logs (for some unknown reason). Avalara does some weird writing of values to those fields during the course of a tax calculation. I think I found that the number of change log entries was 3n + 1 where n is number of lines.

We had a 200 line order blow up our system because of this. User made changes without unchecking RTP and it hung for 20+ minutes and ballooned our sql transaction log about 40gb. That was an interesting day. Granted, we had some network misconfiguration that compounded the problem, but still, ye be warned…

1 Like

All of these things stop you from doing something else. You can leave the ready to process off, and the users can move through everything quote to cash without any programmatic stops . Even if they are curious and try to test what it’s doing, they don’t even see the difference since a large portion of business is B2B anyways and sales tax doesn’t apply. Because of this, they don’t understand what it does, and why it’s important. That popup is just black magic to them. Calculating taxes and populating bookings means nothing for order entry personnel.

For this to work correctly, we need 1. a dashboard to look for issues, and 2. some sort of stop down the line that yells at someone because ready to process isn’t set. Ideally when someone is seeing the order so that they know it’s there, but then stops them from moving forward.

3 Likes

Sales is externally influenced. At least in our world we build for other manufactures and our sales orders are a reflection of their MRP changes AKA frequent and odd. I use the book tables to explain why 500K moved out to next year and then back again three days later.

We do the same yo yo on our suppliers who are the sole approved vendors of our customers.

I would prefer not to have a bunch of transactions to sift thru to get the answer, but how?

If you went for the PO approval route then a sales order could not be used to make jobs if not “ready” and no changes if “ready” and then I would not have all of the book records to go thru, but a single record if there was a change on a line or release when it went back to ready.

1 Like

We also use the booking tables, and we process a high demand of changeable weekly schedules via Demand Entry. I am now wondering if this is possibly why some of the demand can be quite slow when processing and am going to review with the relevant department. Thanks for the heads up @timshuwy

I would also vote for an idea to segregate the booking \ ready to process.

1 Like

We also struggle with this issue. Not the booked orders, but forgetting to set ready to process and not knowing when an order is finished being entered. I think its a cop out to say the users just shouldn’t forget to check the box, when there is nothing built-in to control the flow of orders downstream even when ready to process is not set. I made this tangenetially related idea about it a long time ago but literally nobody but me is interested, apparently :sweat_smile: https://epicor-manufacturing.ideas.aha.io/ideas/KNTC-I-2643

There is also an idea: https://epicor-manufacturing.ideas.aha.io/ideas/KIN-I-3603 that relates to this… having an approved status for an order.
I worked with one customer who created their own “Finalized” option for an order, that had real teeth… if an order was not finalized, then all the releases were marked unfirm. but once finalized, you could only edit a few chosen fields on the order without first unfinalizing it. ALSO they prohibited shipping against an unfinalized order.