I have used Material Request to add an item to the Material Request Queue.
I select the item from Material Request Queue and PROCESS.
Nothing happens (The screen to perform transaction appears, I click OK). No qty is moved between bins. No part trans record is created.
Am I missing something?
Additionally, I would point out that I went looking on the Material Transaction report, and the MTL-MTL transaction type is not valid.
After more testing, I can confirm that Get Request also does NOT work (PUR-MTL) but a Part Move Request DOES work (STK-STK) when processed from the Material Management Queue
Check back to the Inventory Tech Ref guide for full listing, but I think you want STK-STK.
STK-STK Inventory move from 1 bin to another
STK-MTL Issue of inventory to a job
Regards
Mark
The MTL-MTL is automatically classified by Epicor when I request material for a job. You are correct that an STK-STK would process properly. I am considering writing some custom code to force those transactions to become STk-STK in the datagrid and see if they process then. Judging from the behavior I’ve seen so far I think it will work, I just think that in this instance, I shouldn’t have to fix it because this is a core feature unless I’m just oblivious to something.
I played with some other techniques to try to get the concept working, like allocating, releasing for picking, but they all fail because my materials are set to backflush. Makes me wonder if the same conditions are affecting this material queue. They shouldn’t. In order for the backflush to work, I have to give a backflush bin, which means at some point, I need to move materials out of their warehouse bins to the backflush bin. It would be real easy if all my distinct materials resided in unique bins but that just isn’t how our warehouse is set up.
Strange – MTL-MTL isn’t listed in the Inv Ref Guide. The 2 common sources of material issue to job would be STK-MTL or PUR-MTL.
[cid:image001.png@01D277E1.9A798D90]
So, I wonder if MTL-MTL is coming from a BPM or customisation on your system, or perhaps it’s just a temporary classification that Epicor uses. I have found a case of this, with STK-SHP as displayed on the material queue. You won’t find STK-SHP in the PartTran Table, the transaction is actually recorded there are STK-STK.
Regards
Mark
I know that anything moving purely within jobs will not show on the transaction history. I’m assuming that you are looking in the part location tab on the part tracker (not the bins tab) because that’s where WIP is shown. (I just have to ask to cover the bases). Another dumb question, are you taking this material from stock? or just moving wip from one location to another? If it is coming from stock, that should be an issue material transaction not just a move.
I had a service call in because the move-wip screen does not move wip from one bin to another. They told me the fix was to upgrade to 10.1 which we haven’t done yet. The fact that you are on 10.1 and can’t seem to move WIP is a little worrisome to me because this is something that we really want to be able to do as well.
Then, sometime later when I read all of the posts (I really shouldn’t do that) I saw…
In order for the backflush to work, I have to give a backflush bin, which means at some point, I need to move materials out of their warehouse bins to the backflush bin.
You don’t have to set a backflush bin, if you don’t it will pull from an available bin. Without setting a backflush bin (or primary bin), you can’t control which one the backflush pulls it from so if you have more than one bin with inventory in it, it’s kind of roll the dice. There’s a heirarchy of the rules posted on here somewhere about how it processes. (and I think the one on here is different from the one in the help files, but the one on here is right)
But you could also accomplish what you are trying to do by just transferring the inventory into the backflush bin that you have set up. Just set that resource group to backflush from the bin set for their work cell. Any reason not to do that?
Or change the material from backflush to not backflush and then when you request the material it will just issue it to the job.
Thanks for the replies. I did check and you are correct, I can see those mats on Part Loc tab.
What you described (inv move to backflush bin) is what I was hoping to occur so I can control where the backflush occurs from (and have accurate locs for all of my inventory at any given time). I like the idea of the way this material request works (requesting based on job requirements), and send it to the queue to be processed by the warehouse. Like I mentioned, I am going to attempt to force that transaction type to be a STK-STK and maybe it will do what I am wanting.
What is the purpose, or usefulness, of the way it works now?
Also, it will not allow me to issue material because it’s backflushed.
So I forced the MTL-MTL to be STK-STK and the results seem promising. I will add on to this code so that when process is clicked, it changes all relevant type before calling the standard process procedure.
Right, wrong or otherwise here is my code:
using Infragistics.Win.UltraWinGrid;
private void epiButtonPROCESScc_Click(object sender, System.EventArgs args)
{
// ** Place Event Handling Code Here **
// I am going to hijack the original process button - get ref to the grid
EpiUltraGrid grd = (EpiUltraGrid)csm.GetNativeControlReference("09bbac04-0c14-449b-9f99-b66bbf58dd6e");
ChangeTranType(grd); //call my function below on this grid
}
private void ChangeTranType (EpiUltraGrid Grid)
{
foreach( UltraGridRow row in Grid.Rows) //change any and all rows where TranType is MTL-MTL
{
if(row.GetCellValue("TranType").ToString() == "MTL-MTL") row.Cells["TranType"].Value = "STK-STK";
}
}
The way it works now, if you request the materials, once they get there they are issued the job. Because that is happening you don’t need the backflush to happen, they are already issued in real time. And if you’ve brought them specifically for that job, now they show up as in WIP for that specific job. So you would have one transaction, issue material to job, instead of two, move STK-STK, and then a backflush operation to actually relieve the inventory. One is always better than 2 as far as transaction in Epicor. If you need the material returned to inventory after it’s been issued to the job there is a transaction to do that too.
Why don’t you want to simply issue the material to the job when it’s delivered?
mtl - mtl is for moving parts from one job to another. You are using WIP request which is made to move material from one job to another not from bin to bin. Move Inventory Request is what you should be using.
Or i would suggest Fulfillmet Workbench. You send picks to the material queue and when confirmed they are issued directly to the job. We do not using for job picks here but we do use it for Sales Order picking.
The only issue with inventory move request is that it isn’t linked to a job
and doesn’t allow for selection of parts from a job.
The fulfillment work bench wouldn’t allow me to pick because the materials
are backflush
We aren’t understanding why you can’t change the materials to not be set up to backflush? The purpose of backflush is to negate the need for a move like you actually want in your case. If you want to do the move, then remove the backflush requirement and use the system as designed and issue the parts when moved. It’s only one checkbox.
Side note, this message doesn’t actually stop you. It just warns you that if you issue it, it will backflush again when the operation is completed.
I don’t have control over whether they are backflush, that’s a corporate decision. I am sure they did it out of convenience. We’ve had the system for 3 years or so, I’ve only been on board for 6 months. It’s clear they didn’t (and still don’t) have a clear understanding of how it all works - I certainly can’t claim that I do, but I am making progress. The biggest bummer of this situation is that they’ve spent MASSIVE amounts of money on support packages and consultants and it’s still a mess.
I am all for allocating vs backflushing but there are some key concepts I haven’t got worked out to make my case, like if we are not backflushing how does the consumption of material work? How does the job know how much to consume? They big plus of backflush as described by my corporate team is that the number of parts made (good and scrap) determine how much material has been consumed. This is important because we send extra material to jobs to cover for scrap. The scrap is not something that we can guess because it swings wildly depending on the part, the time of day, the operator etc. We’ve attempted to set an expected scrap value but I was told by the person who set it up that the issue became it scrapped that material no matter what. That wouldn’t work. Regardless of which way we go - we still have to get materials to the job in some shape or form and be able to track those movements.
The consumption of material is handled by the issue/move transaction. If you need more, you simply issue more material. You actually have better control over the scrap by doing the issue/move transaction manually instead of backflushing. You have an estimate set up, then if you use more material you get look at history on estimated vs. actual and see how well your process is doing.
We use backflush almost exclusively. The reason we choose to do that, is that we don’t have the ability to complete all of the move/issue transactions as they happen as well as the operation completions (we can’t even get those right, but that’s another story for another day). We have large assemblies with a lot of onesie twosie parts and almost everything is made to a job with the full BOM, so even if we make 5 of the same part, there are 5 different assembly sequences that need the operations reported. We would have to issue 5 times as well if we didn’t backflush. So we don’t attempt to use the move queue and actually move it in the system, it just gets relieved when the operation is completed.
Are you moving the material to satisfy the need on one mtl/asm sequence? Or are you trying to make one move to get a bunch of material to a location to supply a bunch of mtl/asm sequences? That changes whether you would want to use backflush or issue. Issuing manually to a large quantities (like a press making thousands of washers in one run) is generally better, but backflushing is better for assemblies with lots of branches in the tree. All of this depends on the type of business you are in.
And each material can be set to backflush or not. It doesn’t have to be all or none in the system. But someone has to know which ones need the transfer and which ones don’t. I suppose the request material would help get that figured out.
Thanks for taking the time for a detailed response.
We generally have one operation, with 5-10 materials in larger quantities. If you are backflushing, how do you keep an accurate grasp on your bin inventory (or all all items in the same bin)?
That’s the million dollar question!! I chase around a lot (I mean a LOT) of inventory issues, and I even just let some stuff go for a while because I’ll never get it all right. We have a hard time with standardization of process around here (too many years of just cowboy up and get it done) so even if I set processes, people won’t follow them anyways. But generally we only have a bin or two with inventory and if the overall count is fairly accurate, at least we know to order it so it gets into the building. Most people have worked here for at least 20 years, and many have been here over 30, so there is a lot of “they just know” going on. I’m the newbie still at a year and half.
If you have stable pull locations for specific resource groups or operations, you can get the system set to pull from specific bins based on what operation is being done, or what resource group is doing the work etc… You can get a lot of things automated with that hierarchy I talked about before. The problem with automation always is, will the shop floor do it the same every time? because if they don’t, then you’re off. That’s why, if you are processing a move anyways, if you just issue it at that time, and you trust your material handlers to do that transaction, I think you have a better shot of keep inventory qty and location accurate.