Mass process material move requests

I’m looking at trying to clean up out material move requests. For some reason, parts are getting move requests on Pur-Stk transactions and I don’t know how to make it not do that. So after a year and half of doing nothing with them, I have over 2k lines in the material queue that don’t need to be processed. Is there a way to mass delete these requests? Or mass process them? I tried looking in DMT but you can only add new lines. Selected multiple lines and clicking delete only deletes on line at a time.

The second, obvious question is how do I get these to stop being created automatically? I can’t figure out what is signaling these requests to be created.


As far as I know you can only delete them one at a time. If you use the keyboard this can be fairly quick with a double enter key as the delete button remains in focus after the first click. If you turn off the delete confirm dialogue box it is one enter key hit to clear these.

If you trace one part number for these items, I would expect that during the receipt process you are putting the parts in a different bin location than the part master Primary warehouse and bin states.

There is a Set To Location button on the receipt process that may not be getting used also.

Brad Boes

I’ve asked this EXACT same question before and didn’t get a response. I will watch this with great interest.

I believe that the delete button should work with multiple items selected, perhaps if we were to both report this as a bug then it may get fixed. From memory, in E9 you could delete multiple items but it was broken in E10.

I think what people say regards putting items into non-standard bin is what it causing the behaviour, but it doesn’t appear you can toggle this on or off. I also end up deleting the PUR-STK items from the list on a regular basis, removed 400 yesterday.

I think a data directive BPM would probably be able to prevent these from being created, haven’t gotten around to creating/testing one yet.


I will try to address this for you guys in a little bit. You should be able
to use the Adapter for the queue to do this in code.

Epicor has a data fix that allows you delete them quickly by Plant. FX_Del_MtlQueue_ByPlant

Does anybody have the skills to put together a data directive BPM that looks for RowMod = A and TranType = ‘PUR-STK’ and then do something like set the RowMod = D to stop the record being created in the first instance?

1 Like

That’s a good tip. I can actually just hold the enter key and it keeps deleting, so I can just take some time and drink my coffee… :slightly_smiling_face:

1 Like

I’ll work on that today and see if I can get something made up.

So I’m doing some testing now, and it looks like for Pur-Mtl transactions, even if the parts don’t have a primary bin set, it’s making a move request to move to what looks like the backlush pull from the operation that it’s on? That seems absolutely pointless to not have some control over that. I get for a company that used the material move queue religiously that they might want those, but for a smaller company where receiving is literally 20 ft from assembly, drowning in unnecessary transactions will kill the morale and the business.

Well, off to reprogram the system with BPM’s haha.

I can’t speak of the implications but it seems you can clear the MtlQueue table.

After trying a couple of things, the Data directive can throw an exception, but it stops the whole process, not just the creation of that line. I couldn’t find a rowmod row in that TT table, which seemed odd, but I couldn’t try to do the change the row mod to see if I could get the system to delete the row.

I tried a couple of Method directive things, but didn’t get anything to work. Keep in mind, that doesn’t mean that it can’t be done, I’m still pretty new to this BPM thing so I’m sure it can be done, but at this point, I’m not going to be the one that solves this problem.

If I do come up with a solution though, I will post it here.

Try a method directive on MaterialQueue.Update

Would I throw an exception on that? Wouldn’t that stop whatever process is happening that is updating the Material queue? I need the receipt entry to finish with everything else. That’s what made the data directive not a valid solution. I don’t really have much experience with this deeper method directives. Maybe later today I can experiment some more.


I would expect that throwing an exception in that method would only affect (stop) that method - which means you should never get any updates to the MaterialQueue. Definitely let us know what happens so I can add it my mental notes.

I would put a condition on there that only stops the types that I want to stop, but yeah, it will be interesting to see if it only stops that method, or stops everything that’s happening in that string.

I couldn’t find in my trace anything that had Material Queue in there, and I think I tried to get a message to pop up to let me know it was firing and it never did, which is why I didn’t go to far into that. It’s pretty hard to test conditions without being able to pop up a message.

What I did is create a Data Directive on the MtlQueue table. In-Transaction type. I set a condition that if the added row is equal to Tran-Type. Put the one you need to exclude. I have Pur-Stk, Ins-stk and Plt-Stk. Then set field ttMtlQueue.Visible of the added row to false. So every time an unwanted material queue item is added it will automatically update date the row before it ever hits the queue. So far seems to be working fine.

1 Like

Thank you this was helpful!!