So we have always been fighting a speed issue since adopting Cetec as our ERP. Things have definitely gotten better over the last few years, but there are still major issues we still run into. The attached screenshot shows over 17 minutes in total wait times to enter an order. I understand that each order line contains a BOM and sometimes BOM’s and sub BOMs, but this can’t be acceptable for anyone putting orders in. Basically, we pay people to sit and twiddle their thumbs for 17 minutes while entering each order, because we have seen that you shouldn’t do anything else while that order is committing because it usually causes more issues. We changed most of the larger orders to a straight import because they took so long to enter by hand, but if the wait times are still large then I am not sure what else to do. Our orders are scheduled to become even larger than 50 lines (like this screenshotted order) The speed issues seem to compound with the size of the order. I’d really like some options to getting this speed issue fixed once and for all.
There are other issues related to speed with certain screens and reports but we have learned to deal with those.
We are tracking this with engineering… have just made an adjustment to your config settings related to order entry and scheduling, and wondering if that might have helped.
Curious if you could again track page load time at order entry and let us know if there has been any improvement to speed at all (i.e. improvement from 17 minutes, which is atrocious) ?
Please let us know.
Also, you mentioned there are other screens that are slow that you’ve learned to live with. Even so, we’d love to know about them; we have dedicated engineering resources that could be deployed to adjust for optimization depending on what kind of data you’re putting through them. We just need to know about them, and we’ll see what we can do.
We just tried another order today. The committing screen actually timed out so it didn’t give an accurate time. Our order entry person said it was spinning for almost 30 minutes before throwing a 408 Timeout Error The order did show up after about 15 minutes(we checked on the Order Release screen, but if you are just watching the commit screen you would have been there the entire 30 minutes.
We are cloning your instance into a test system and we will see if we can reproduce that page load time, and do further analysis on what we can do to speed this up.
Thanks for your patience, we’ll keep you actively posted as we make progress.
Engineering has been working through some of your use cases. It turns out that the number of BOMs being committed was significantly higher than the number of lines on the Quote - in one case, 42 Quote Lines was becoming 280+ BOMs. That is a significant amount of time when each of those takes a few seconds to update/commit (even when the BOMs aren’t being created on sub-orders, we don’t want to lose the changes)!
So - we have a Config value that we’d like you to turn on. It’s called, “Skip Creating Sub Assembly Worksheets On Quote Line By Default”. That will prevent those multi-level BOMs from creating child worksheets, which will dramatically reduce how many BOMs have to be checked/validated/updated. You should be able to turn that on now, even though it won’t have much of an impact until this next release (3.11) goes out (the first week or so of July).
There are a few other changes in that release that should help your speed out as well. Nothing quite as dramatic as that Config value, but any help is good…
One final note - once the user starts that ‘Commit To Order’ process on the Quote, they should be able to do other tasks in other tabs in Chrome. So long as that tab stays open things should be OK to run - we did test that behavior, and it seemed OK for our tests when we moved around in other tabs.
Thanks for the patience here, and please let us know how things go!
