Over the past several weeks, we have had several customers report the following:
They have complained that there is a possible issue when entering large orders.
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:
“Ready to Process” tells Epicor that the Order is ready to have sales tax processing completed.
When this box is CHECKED: every change after checking it will cause sales tax to be recalculated (since something could affect the tax rates).
When this box is UNCHECKED, sales tax is NOT recalculated with each line entered
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.
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:
create a new order with this checkbox turned OFF
add your lines
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:
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.
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
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.
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.
did a change. Nothing entered into the booking table
turned on ready to process
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?
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.
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…
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.
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.
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.
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 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.