Cross-posted at EUG. Apologies to those monitoring both forums.
We use a custom updatable dashboard to complete our jobs, so the production employees do not have to complete them one at a time. Our assemblies have 5-50 sub-assemblies. The top level assembly final operation is completed, triggering a backflush of all material and labor for the preceding operations and all sub-assemblies. We are on ERP 10.1.600.23.
Labor detail records are created for every operation with labor. This is not excessive for the database (15-20K records/week). However it appears each insertion of a new labor detail record invokes a select of existing records for the same employee and payroll week. Perhaps it is calculating total applied labor for the employee/payroll week to use for some purpose.
The behavior we are seeing is these job completions / labor backflushes are very fast the beginning of each calendar week. By Wednesday they are noticeably slower, i.e the total time to complete each job is 3-5X. By Friday it is intolerable, in the 10X range with anecdotal incidents far exceeding this. Our consultants researched this and provided sufficient data to Epicor for them to acknowledge there is an issue and have stated they may address it in a future release. No date commitment, however.
We have three virtual employees defined and the person completing jobs now alternates the employee used to close jobs a few times per day to reduce the slowdown experienced. We are considering modifying the job completion dashboard to cycle thru a configurable number (50?, 100?) of virtual employees each time a new top-level job is completed. This should provide the needed relief, but is a bit of a hack.
My question is, who else here has a similar environment (completing/backflushing multilevel BOM’s using virtual employees) and what have you done to mitigate the architectural side effect of using one or a few employees for this purpose?
Thanks in advance. -Cliff