MaterialQueue via code

Epicor ERP 10
1

Does anyone have any experience with manipulating the MaterialQueue via code? I am mostly concerned about adding an item to the queue.

Based on the trace I believe it to be along the lines of:

            MoveRequestDataSet ds = new MoveRequestDataSet(); //create typed dataset
            MoveRequestDataSet.MoveRequestRow row = ds.MoveRequest.NewMoveRequestRow();  //create new typed row
            row.JobNum = "123456"; //set some params
            //blah blah bunch of other properties here
            ds.MoveRequest.AddMoveRequestRow(row);  //add row to ds

But then ProcessRequest gets called from the Erp.Proxy.BO.MoveRequestImpl contract. How do I properly use this?

2

Here’s what Seems to work:

            MoveRequestAdapter mra = new MoveRequestAdapter(oTrans);
            mra.BOConnect();
       

            mra.GetNewMoveRequest("MM");
            mra.OnChangeJobNum("123456");
            MoveRequestDataSet.MoveRequestRow row2 =           (MoveRequestDataSet.MoveRequestRow);mra.MoveRequestData.Tables[0].Rows[0];
            row2.MtlSeq = 10;
            row2.FromWhse = "CPMAIN";
            row2.FromMultiBin = true;
            row2.FromBin = "MAIN";
             
            row2.ToWhse = "CPMAIN";
            row2.ToMultiBin = true;
            row2.ToBin = "W-00-A-1";
            row2.RequestQty = 3;
            row2.EmpId = "cconn";
            mra.ProcessRequest();
3

I would still love it if anyone had some insight into this process. Especially - what are the different types of RequestTypes available? I assume “MM” is a MTL-MTL move.

4

Chris,

I’ve got logic that I’ve been using to generate STK-STK transactions. It’s in a receipt program, and I go through all kinds of logic to determine Putaway Bins (which get written to UD38). Here’s the code I am using:
Dim adMR As MoveRequestAdapter = New MoveRequestAdapter(Script.oTrans)
adMR.BOConnect
for each DR as datarow in dsUD38.Tables(“UD38”).Rows
adMR.GetNewMoveRequest(“MI”)
Dim partNum As String = DR(“ShortChar06”)
adMR.OnChangePartNum(partNum)
adMR.MoveRequestData.MoveRequest(0).PartNum = DR(“ShortChar06”)
adMR.MoveRequestData.MoveRequest(0).RequestQty = DR(“Number01”)
adMR.MoveRequestData.MoveRequest(0).FromWhse = DR(“ShortChar02”)
adMR.MoveRequestData.MoveRequest(0).FromBin = “PPUT”
adMR.MoveRequestData.MoveRequest(0).ToWhse = DR(“ShortChar02”)
adMR.MoveRequestData.MoveRequest(0).ToBin = DR(“ShortChar03”)
adMR.MoveRequestData.MoveRequest(0).EmpID = “SHP”
adMR.ProcessRequest
next
adMR.Dispose

You’ll notice very similar to yours. So, if you’re using “MM” to do your material to material moves, I’m using “MI” to do Stock to Stock moves.

Not sure if I’ve been much help.

Kevin

1 Like
5

Thanks for the info. So “MI” is Stock to Stock? Do you know of any others for future reference?

One of things I think I’ll have to do for my sanity is to create a custom handler from the material queue. I want a transaction type that will only move issued material. The problem is - upon issuing, there is no specific record (I know of) that tracks what is issued to a job and where it currently is.

What happens to material in WIP for a job (not necessarily issued) when the job closes? Does it pop out of WIP into the ‘real’ bin?

If I have some material in WIP for a job and also some material issued to a job (in multiple locations) - how does Epicor know what locations to consume? This goes back to the thought that Epicor doesn’t necessary know WHERE it’s issued material is.

I am so confused as to what is the purpose of WIP if material is not issued. Seems like the simple solution is don’t put things into WIP that aren’t issued. The problem here for me is what comes first, the chicken or egg - in this case, issuing material or requesting a move for it, one has to drive the other. In certain cases, it makes more sense to issue, then have a move (material queue) automatically generated - in other cases, it seems like the request to move should trigger the issue.

6

Chris,
You should be able to ID other types with Trace.
I was able to ID the following MOVE REQUEST types by enabling trace and then opening a Move XXX Request program from the menu.
Then when viewing the log I searched for
parameter name="requestType"
From that I was able to determine the following:
Move Request Types
MW = Move Wip
MI = Move Inventory
MM = Move Material

I don’t think there are very many.
I tried the same method on the Return XXXXXX Request Menu items and I did not see anything like a “requestType” parameter being passed.

1 Like
7

Thanks, Rick.

Perhaps a silly question - How do I return items from WIP to inventory (non-issued items)? If I request a move, the mat queue automatically performs a move to WIP.

Also, where can I find a record of transactions that are used to determine issue qty (according to field help, it is the sum of issue transactions). I am looking in PartTran and I assume that STK-MTL is an ISSUE? If so, is this ALWAYS true?

8

So this might help:

  • Move Inventory Request (MI) is per part and is for moving a certain qty from one warehouse/bin to another warehouse/bin.

  • Move Material Request (MM) is per Job\Asmbl\Mtl and is for moving Job Material between bins. This does not move inventory to or from stock but already issued material in the Job.

  • Move WIP Request (MW) is per Job\Asmbl\Opr and is for moving WIP from one Job Operation bin to another. This does not move inventory to stock but in the job to different bins.

If instead you are looking for the way to Request Inventory stock movements into and out of a Job you want to use the “Get Request” and “Return Assembly Material Request”

  • Get Request is for requesting Inventory Stock for Job Materials (STK-MTL)

  • Return Assembly Material Request is for Returning Job Materials back to Stock (MTL-STK)

Once requested these show up in the Material Queue and when the Material Handler processes them a Material Issue or Material Return transaction is executed against the Job.

Epicor’s menu item descriptions are not very intuitive.
Does that make sense?

-Rick
www.getaligned.solutions

1 Like
9

Very helpful. But I still I am having a disconnect how to ‘return’ a WIP part that has not necessarily been issued?

The root of my problem is improper setup. We have an operation (DRY) that is not routed on the BOM. The correct course of action is to add. This would solve a lot of my problems. I could determine how long certain material had to be dried ahead of time and once finished, route it the next operation. Unfortunately, I don’t think the powers that be are going to allow me to do that. The whole multiple operations (and assemblies) on a job really confuses them. I don’t know enough about at the moment to convince them otherwise.

With all that said, the problem is some jobs need us to issue to the DRY area, then be moved. Some do not have this step so I am trying to find the easiest (most simplified) way to map this out for the end users without a lot of if-this, then-this.

After racking my brain I think the simplest solution is (feel free to comment good or bad):
All material movements will STK-STK, then I will emulate a feature similar to backflush, where BEFORE the job closes - remaining material is moved out of the job bin and the remaining qty will be issued to the job (automatically). My code will have to query the backflush bin that is set for the resource of the job and work within that bin. It will be imperative that they don’t change the resource the job is using without telling the system.

Feasible? Silly? Amazeballs?

10

So I need to understand your terms, when you say a WIP part, what are you referring to exactly?

A WIP part in Epicor the the Job Assembly Part Number as it progresses through the Job. This Part can be rec’d to stock at any point, but while it is in the Job it is actually automatically moving from one Bin to another per the Operations Primary Production Resource’s In/Out Bins setup in Resource Group Entry. This WIP does not show on hand anywhere, but you can see the WIP qty’s in places like Part Tracker > Locations > WIP. That is Epicor WIP.
It kinda sounds like you are describing ‘Queued’ inventory, stock that has been moved to a Bin that has been assigned (outside of the system) as a ‘WIP’ bin and and Job Mtl Issues should come out of that Bin. (the bin may change per Job Operation)

As for your solution, not crazy, but why don’t you just use the ‘Backflush’ checkbox in the Job Completion/Closing program? Normal backflush occurs when qty is reported against an operation. But this checkbox at Job Closing should backflush any part (set for backflush or not) where the Qty Per does not align with the qty reported on the related operation.
(the checkbox is not enabled until the job is first marked complete)

-Rick
www.getaligned.solutions

11

When I say a WIP part, I just mean a part in a WIP bin. If I do a REQUEST MTL MOVE, it would queue up a MTL-MTL transaction. This would cause non-WIP parts in the FROM bin to be transferred to the WIP instance of the TO bin (i.e. I can only see them in part locations, not inventory)

The reason I can’t use backflush is that it makes the assumption we are adhering to the BOM. Not that we really deviate, but there are conditions which makes the BACKFLUSH quantities be vastly different from the actual. Currently we use BF and have to make constant corrections to inventory because of it.

I figure if I take the “auto-issue” portion of backflush but change the way it determines how much to issue, it solves my issue. I intend that at job close, the only material in the BF bin of the resource, will be what we used (since we’ll enforce them scanning out any remaining physical material before close).

12

Chris,
Hmmm, not to shabby of an idea… You do realize that just doing a Request Mtl Move will not actually move anything, it will just create a Mtl Queue item for your material handlers to move.

If you want to actually move it automatically, then you would use the Material Move program (or whatever the BO method is for that).

Awhile back I had a client where we needed to emulate some of the backflush logic with some of our own modifications to default the correct warehouse & bin for a situation similar to yours. But in this case the Inventory was moved to a certain whse & bin, and we wanted the Issue Mtl to default to that whse & bin if there was inventory but it always defaults to the primary bin, so we studied and leveraged the backflush logic to provide some consistency to how the default is determined. Here are the two article you may find helpful:

I’d like to hear how this turns out.
-Rick
www.getaligned.solutions

13

Interesting articles for sure. Thanks!

14

Hi Chris,
Yes, I am resurrecting a 2017 post. We have an issue. When we return material to a job, we need our operator to print the tag. Currently, when you use a return process, the only tag print comes from the material handler. We need the tag printed before the material handler sees the queue.

15

This is generally handled by data directive with an auto print widget. I’d say thats the easiest way. There should be lots of examples here on the forum about it.

16

Can’t get the data directive with auto-print to work. We are implementing. Thus, we do not have the expertise.

17

Heres a ton of material to go thru:

Also, see post from @aidacra (Epicor Support Master Elite Level S-Rank)

18

We are using SSRS for the labels.

19

Hi Chris,

In BPM what adapter I should add?

20

You should scroll back up and review this thread as the adapter is mentioned. However, you arent going to use an adapter in a BPM.