We’re trying to roll out “Get Requests” for materials using the material queue manager that is part of the Advanced Material Module. Our Material Queue has been getting clogged up with various other transactions that we currently don’t see that value in (as we grow, I expect that to change). Referencing a post back from 2017 and with the help of AI, I was able to create a BPM that looks at the transaction types hitting the MtlQueue table and set criteria that certain ones aren’t visible. Aside from one minor issue (I think its an operation setup issue) testing has been going well and I’m hoping to move it from our Pilot database over to Kinetic in a few days to further identify any other issues.
One thing I’m not crystal clear on is the impact of the BPM making those specified transaction types “invisible”. Does that mean they aren’t really anywhere on the table and will never go towards allocations or are they still on the table in the background, just not visible on the main user screen? We have run into instances (few and far between) where we need to make an update to an order but have found that a transaction on the Material Queue is preventing that change - we’ve manually just deleted that specific line and we were able to make changes without any issues.
This is my first BPM and I’m not a coding guru by any means, but below is the execution code from the BPM in case that provides any further clarity or could potentially help someone else out. Running Kinetic cloud based.
{
foreach(var ttMtlQueueRow in ttMtlQueue)
{
if (ttMtlQueueRow != null &&
!string.IsNullOrEmpty(ttMtlQueueRow.RowMod) &&
!string.IsNullOrEmpty(ttMtlQueueRow.TranType))
{
if (ttMtlQueueRow.RowMod == "A" &&
(ttMtlQueueRow.TranType.Equals("PUR-STK", StringComparison.OrdinalIgnoreCase) ||
ttMtlQueueRow.TranType.Equals("MFG-STK", StringComparison.OrdinalIgnoreCase) ||
ttMtlQueueRow.TranType.Equals("STK-INS", StringComparison.OrdinalIgnoreCase) ||
ttMtlQueueRow.TranType.Equals("MFG-OPR", StringComparison.OrdinalIgnoreCase) ))
{
ttMtlQueueRow.Visible = false;
}
}
}
}
I’m not sure of any real implications of making these requests invisible instead of deleting them altogether, but my spidey sense tells me you should be doing the latter. Even just from a data cleanliness standpoint it seems better to delete them, but the effects may extend beyond that.
I can think of at least one area (Warehouse Replenishment) where Epicor checks to see if there are sufficient existing move requests before creating a new one. Hiding them could conceivably result in a situation where you want a move request to be created but is not because a suitable request already exists, it’s just invisible.
Also, outside of the move requests that you have no control over being created, which I believe are only the requests created upon PO receipt (I see PUR-STK in your code) you should really identify the root cause of the request generation and address it there, rather than delete them after the fact.
We get move requests for each PO receipt, and they were cluttering the material queue. I wrote a BPM to select those requests by the manager ID. That leaves the unselected queue of requests clean. We do not need requests for each PO receipt as a business process because the part lots are manually put away without needing a trigger for where to put them. This concept leaves the records in the mtlqueue, but it is easier to see the valid move requests.
Garret - Thanks for providing this feedback, your comment about Warehouse Replenishment has me thinking about a couple of things. The one minor issue I had yesterday that I thought was an operation issue may in reality be the fact that the specific move request in play existed existed from some testing I was doing in the morning. Later in the day I added that transaction type to the criteria in my BPM, but I noticed that the original request was still increasing in quantity… It also makes me think about how this would play out with allocations as that is functionality we currently aren’t using but will likely start using this year.
Regarding your note about identifying the root cause of why these transactions are happening - I 100% agree, but I can say with confidence that right now its mostly driven by the size of our business compared to the power of Epicor. Relatively speaking to Epicor’s capabilities, I’d say we’re on the side of a smaller business that purchased Epicor as we wanted to grow into one solution instead of working our way up through multiple different solutions as we grew - we just went all in. I can scan through the list and 100% see reasons for the functionality, we’re just not at the size (facility or staffing) to support going all in on the material queue at this point. We’re a fully custom wood shop which drives a lot of how we do things in the system as we are very cognizant of making sure “the juice is worth the squeeze.”
Thanks again for getting my wheels turning on some things.
Can you elaborate more on your BPM? When you refer to the manager ID, I’m assuming you’re talking about the person who requested it? Are they auto assigned to an employee/team or removed from the list?
Depending on how you manage that, my other thought for my situation would be to assign an employee or team based on something like the part class or part number. The first 2 digits of our part numbers are “smart” and I could play off of those to assign a team or employee I’d think.
For each new record in MtlQueue with a TranType of PUR-STK or PUR-MTL, I assign these values to fields.
RequestedByEmpID = manager
SelectedByEmpID = manager
TranStatus = MGMT-LOCK
These steps remove the requests from the queue that our material handlers use to select and process move requests. We use the Handheld screens so the selection screen is not big. The irrelevant requests were making hard for the handlers to recognize when to select the requests. Some of the fields above were also designed to flag the record to make it easier to delete these in the Material Request Manager screen.
This is very similar to our scenario, the PUR-STK or PUR-MTL is a big driver, the other one for us is MFG-OPR. We have other processes that would make the MFG-OPR redundant and likely not as accurate to the actual shop flow given how some of our jobs are set up.
Right now our department leads are submitting material requests by paper or email and I’d like to take things up to the 21st century, especially because we’ve owned AMM for years and have never really used it. I may circle back to you with some questions once I have time to create another BPM that has similar functionality to yours.