Yes I voted for that one too.
1 Like
What are people using that Booking table for?
Is it something like our sideline database cube tables, where we take a snapshot of all Open / Current Year OrderDtl records every night?
Bookings is a concept of how the system keeps track of changes in the backlog. for example, if your current backlog is $10 million, and today you get a new $1000 order, then you had $1000s in bookings. Tomorrow, if one of your older open orders has a cancellation of $500, then you had a negative booking of $500.
The booking file keeps track of the net change in value to your open backlog.
because of the way that it works, any changes to the order, can sometimes create TWO entries in the booking file⌠one to REMOVE the old value with the old infomation, and a second NEW value with the new information. In theory, if all they did was change the part number on the order, but no price changed, then the sum of the booking would be zero, BUT if you looked at the originally ordered part number, you would see a negative booking.
I thought it was known, nothing new. DMT in Orders and every Line you add, will take longer and longer and longer. 
Been there done that, it hurt 
3 Likes
That is why??
I guess that DMT is updating on every line so each time it is retrieving the order, resubmitting it, and doing the Ready to Process. Have to run the trace to be sure but it sounds like it.
Thanks @timshuwy , makes sense. We do something similar but with our own sideline database / table with nightly snapshots of OrderDtl table state, for open orders.
When Ready to Process is TRUE, then each line that is added cause the sales tax to be recalculated one more time. at line 1, it is easy⌠but once you get to line 100, it has to reanalyze all 100 lines again (due to complex sales tax rules in some regions).
1 Like
Tell me about it! I used to work for a company that sold to a major retailer would have a 5 line Order with 1000+ releases per line. Sales was too special to DMT so we had to train them to fill out a âtemplateâ Excel sheet (which only some of them did correctly) and run the DMT for them. It was a huge PITA.
Even with Ready to Process off it hurt to run a DMT for that many lines/releases.
Randy I am dying trying to do the same thing. Literally 1000+ different locations for one order and the DMT is hours long⌠how in the world can I make it go faster 
But if we donât hit ready to process till the we are done with the dMT it will do that calculation at the end?
If you check âready to processâ and then hit save, it should (it better!) recalculate things as needed. I havenât tested that, but if it doesnât work that way, it should be reported as a bug.
The reason DMT canât do that (uncheck the box until the lines are all in) is because it doesnât know which line is your last line.
2 Likes
An Epicor Function? 
** EDIT: This would give you better error control as well. You could even âfixâ common errors like mapping bad part numbers to the correct ones - since itâs nearly impossible to get the buyer to fix their EDI system. 
1 Like
So a function would be faster than DMT?
You would pass in the whole order in one call, do a quick check for easy errors, create the order with the sales order object, and at the end, do your Ready for Processing only once, and youâre done.
1 Like
Iâll have to try it.
Itâs too bad that it isnât programmed to see if something is new on the line, set a field to be true or false, and if true, then recalculate that line instead having to recalculate every line everytime a change is made. Of course that wouldnât help the 100+ new orders 
And @klincecum will help you!
1 Like
That would be cool too haha
1 Like
I donât think the SO BO will take multiple dirty rows though. So youâll still probably have to loop through the rows and update for each line, but you can uncheck the ready to process at the beginning and check it again when youâre done.