Hi everyone, I have seen various discussions about this process, but no one seems to address the reasons for the data becoming out of synch in the first place. Our planners have recently identified individual parts that had incorrect demand and this was corrected by running the process, but I have subsequently run it in report mode only against all of the parts and was alarmed at the huge number of corrections proposed.
I looks like I need to find a regular maintenance window to run this regularly, but I would like to understand why this data would become incorrect in the first place, it seems like this is the sort of thing that just shouldnât happen in an ERP solution or at least should be a rarity?
Hi Steve,
I just wanted to chime in that I have also not found or heard of a solid answer as to why this staleness of records occurs. We struggle with it as well to the tune of 20-100 parts per week. I have taken to fixing one-offs at lunchtime and 6pm, using the part specific filter on the second panel, in conjunction with sending out a widely addressed email to all who could be handling said part with a âHands offâ request until I circle back around with a âcompletedâ email. On Sundays mid-day, I run the process full out, again with an âAll Partsâ scope (no filter) and another email when done. This has kept us limping along but we have sometimes missed important due dates. This is usually because our process uses Allocation and sometimes requires de-allocation/re-allocation at a lot level. Very much hoping this question youâve posed attracts the right Epicor expert and yields a substantive reason and perhaps some technique for detection (bpm/baqâŚ) of the condition before parts are due.
Itâs been a while since I received the full explanation from Epicor, but it basically comes down to not using the system correctly. The problem in my instance was that we were not using the Material Queue correctly. Whenever there was a âfireâ the planners would print out the specific material transfers they needed and give it to a picker. The picker would do Issue Material transactions instead of using the Material Queue and that would cause the issue.
In Vantage and Epicor 9, we noticed it happened when a Job was scheduled and kitted then de-kitted (for engineering fixes) and re-engineered/kitted then the PartDtl record demand was incorrect.
The common thread in some of this seems to be that âallocation transactionsâ are not consistently reversible even though we are using the âreverseâ process. I still donât get âWhyâ. Why is the method for âde-allocationâ not updating the state of the part qty correctly? Iâm being simplistic here I know, lots of tables involved and conditions but it seems it should be reversible.
I fully expect the issues to be the way we are using EPICOR rather than a bug, itâs just very difficult to pin down and given the volume we are seeing I am not sure itâs 100% down to material issue instead of using the material queue but I now have a line of enquiry so I will pick a few parts and see if I can find out a bit more.
Our issue was that we were NOT de-allocating/unreserving the records.
Also, Epicor does not support running the process âwide openâ. And in my research on the matter, I learned that you sometimes get different results running it wide open and then by part
Yes, in my experience with this issue, the errors were occurring due to the actions we were taking. We had a C# developer on staff who was able to build something to capture when lines were taken out of the queue. We had to slap a lot of hands before things started to get better.
I went down the same path you are on. I would concentrate on learning the Fulfillment Workbench quirks (I want to say that if you print what was just released it removes it from the queue, itâs been a while) and training before you blame Epicor. I spent months opening tickets and complaining to only find out it was our users who were causing the issues.
Thanks for the input, I agree that it is likely to be something we are doing, as this is too much of a fundamental fail of an ERP system if itâs some kind of bug. It seems to be a widely experienced issue and what I am trying to get from EPICOR is some kind of direction as to where to look, I know I am probably on a road to nowhere here, but got to try.
With regards to building something to capture when items are taken out of the queue, do you mean when lines were removed from the material queue table, or when users unallocated stuff from FWB?
It was a couple of years ago, but I believe he was capturing whenever a line was deleted from the queue. Not that the record was transacted through normal processing, but that someone or something deleted the line from the table.
I forget the name of the Epicor employee that I spoke with, but he was immensely helpful. He probably spent about 4 hours on the phone with me over time to help me better understand how the system worked. I wish I remembered his name.
This thread was informative. I just discovered some of our demand numbers not making any sense. Itâs crazy that we have to run a ârefreshâ routine occasionally to get them back in sync. This looks to be a problem with a less than ideal database normalization. Love it when creating SQL but not so great for keeping data in sync.
It is something I still have not been able to understand. It happens for finished goods in inventory as well as raw stock materials for us. Have to run it every morning.
@utaylor Do you manually run it? It seems like this would be an ideal candidate for scheduling but I donât see where I can add it to a process set. Is there another way?
@jkane, can you elaborate on how you were incorrectly taking lines out of the queue, and what kind of hands had to be slapped? We run RPQ&A monthly, and itâs huge. Can you share the BPM or C# of what the developer did to capture the lines? Thanks!
One way was by people just âdeletingâ a line from the Queue Manager screen (or the other Queue screen, canât check right now as power is out where our server is). Instead of just deleting something straight from the queue, it should be removed the way it was added. So if you reserved or allocated something from Fulfillment Workbench, you should do the reverse in the workbench.
Another way is that the line gets deleted when you print from Fulfillment Workbench. I believe the system assumes if you are printing it you are not going to use the queue to pick it so it deletes it. (Again, no power so canât double check the system for specifics.)
We had to tell the planners to stop printing hot items they needed from the queue and instead raise the pick priority (use the system). We also had to tell people to stop deleting lines directly from the queue. Things were getting better and then there was a pandemic you might have heard about and I got let go.
The biggest thing to get across to employees is that the queue controls nothing, it is just a repository. If there are things in the queue that need to be added, removed, changed then the original screen of where/how it got in the queue needs to be used.
I completely forget what he did to capture the deleted lines. It may have been the change log, or something SQL based, or even a UD table. Iâm sorry I canât help more on that part
