Hey everyone, I am stuck again. We have an external inventory system that we want to integrate into Epicor. How it will work is that an operator will pull out a tool from inventory (giving it the Job & Op that it is for), then that inventory system is going to export that information as a text file. What I then what to happen is to issue that material to the job. I have figured out how to add the material to the job, how to adjust the cost and quantity issued to the job, but I cannot figure out how to reduce stock, or create traceable records of each transaction. Any ideas on how to make this work??
You should do an issue transaction… Run a trace in the system with an issue and replicate the BO calls in C#
Is that an adapter in c#? Guess I am not familiar with that
it is done via the business object IssueReturn, you’ll have to do a trace in Epicor figure out the calls and mimic the behavior. Seems like you aren’t familiar with these terminology too much so I recommend you check out/read the
ICE Tools Guide and the Customization Guide thoroughly to get familiar with the Epicor tools in EpicWeb.
It looks like you are using a CSV File to do the integration which screams Service Connect, it requires no code and it is very very useful. Basic premise, you drop a file in a network share somewhere and service connect will pick it up and process it (Do the Epicor Business Logic required) all without writing code.
Are they completing operations on the job? If they are you can just set the material to backflush and it will automatically issue it when the operation is complete.
Yeah, we were never trained on any of this, so I am trying to figure out how to do it myself. I have figured out a lot of ghetto solutions, but there has to be a better method. I just found the education course for it, so I am going to read up on that!
Well the issue is that we do not know what tools they are going to use until they are running it. So part of my code is checking to see if that tool is already on the job, if it is not, then it adds it right there. We are a job shop, so there is no predictability in how many they are going to use =/
right, but if you adding the materials through the code, just have the BackFlush check box checked in the JobMtl table, and relate it to an operation. Then when the operation is complete, the materials related to that operation will automatically.
If you are not doing the operation completions, or if the order of how things are getting into the system are not correct, then this solution won’t work. It was just an idea to remove some coding from your solution.
I like that idea, but the issue is that we do not know ahead of time how many tools we are going to use. We don’t know the qty per parent. The only way we know how many they use (at least starting out) is when they check them out.
You don’t need to.
when you do this, just have your code check the backflush field, and relate the material to the operation that is created. Then just complete the operation and you’re done.
Sorry that you are having to dumb this down. I thought when something is back flushed, it is looking at qty per parent, and issuing it to the job. So if the job was for 100 pieces, qty/parent was 1 per piece, then when the operation is completed, it would issue 100 of that material? If I do it your way, what qty is it using?
It is normally, but, you can set materials to fixed qty, and it won’t multiply them. See the screen shot below. DB field JobMtl.FixedQty
edit: I should say that you should probably double check that though. I know that fixed quantity has affected purchase suggestions on purchase direct parts, but I haven’t followed through with the back flushing to make sure it follows the same rules, because it’s not often we have that specific combination here. I assume it works that way.
ah ha, great. I will give that a shot, thanks for the help!
OK… so ur managing this activity via C# and reaching into EPICOR.
The problem with managing ‘tooling’ issued (or backflushed) is quantity needed and used?!?!?
We have similar circumstances, deciding to use QTY per parent (with estimated expectations based on qty-per-parent) as to consumption of usefulness of tool.
In reality, it is a bit of guess-work: making 100 units, need 4 of a specific tool. Possible to need 3-4-5-or 6.
Additionally, a partially used tool from a prior job cud initially be used on a future job.
Overall… we want PURCHASING to ensure qty’s needed are in-house for production, so put the tool(s) on a MOM.
But Procurement and managing inventory balances would mean Inventory-PO’s vs OTHER, as in the past. Now dollar$ are on the inventory part and will become WIP! (tools will have specific Part Classes and we will drive tool costs special tool-wip acct to keep true-material costing evident). Need to do so with a BPM, and also be sure any material returns per tools (mfg-stk) also reverse the proper GL acct.
Presume the MOM is accurate, but more tools are needed. This wud be a MISC-ISsue to JOB and the job requirements may be revised via eng-change if needed.
Since we want to know inventory balance of items in the TOOL cage, the necessity to have COST on the tool makes life easier on that side.
I believe you need to consider ‘how’ the tool is actually made available for the job, and how tool inventory will be managed. Whatever ‘people’ do to provide tools for a job… perhaps, the system should align to that business process.
please share per what you decide to do…
Yeah that makes sense. I am still trying to figure this out, and having trouble. Been trying the backflush method, but there are still issues I need to figure out. Essentially this is our situation:
*We have a vending machine with standard tooling that can be applied towards any job.
*That inventory will always be supplied (Kanban orders with supplier).
*Operator comes and takes tool from vending machine, well we need that costing to be applied towards the correct job. *We will not always know which tooling is needed ahead of time, so when they take this part out, it will add it as a material to the MOM. Now I am stuck at the portion where it is then issued to the job.
The issue I have found with Back flushing is that if i do an original qty of 15, it gets issued. Later if they come to take out another 15, the required qty will show 30 for the material (even though 15 has already been issued), and when it gets issued, it issues 30 instead of 15. So it will show 45 pieces issued when it should have only been 30. I feel like I am making progress. I will keep you posted, let me know if you have anymore ideas!
instead of upping quantity, try adding a whole new line and operation. If it’s automated, then the extra lines aren’t a big deal.
Also with back flushing, you only get one shot (when the operation is completed) to issue the material. So you you complete the operation, then complete it again, it will issue the total quantity. But if you make a new material line, and a new operation to relate it to, used the fixed quantity, that should help.
And remember that there is back flushing when the operation is complete, and then you can back flush everything again when when you close the job (don’t do that, that’s where the double issuing happens) You’ll have to pick one or the other as far as issuing goes. We always backflush on operations to try to be live on our inventory.
Also, if you are only worried about costs, think about do a mass issue just before closing the job instead of back flush, if you aren’t worried about live inventory, the delay in reporting probably probably won’t matter. We don’t use it (we backflush everything) so I won’t be much help on the details of how that works, but I would at least take a look at it.
And think about making those parts non-quantity bearing in E-10 if they are Kanban if you haven’t already. No reason to mess up you stock status report for things that don’t matter.
Be sure to test the Inventory costing when you figure out what you think you want to do.
Depending on your part costing method and if you are putting the job/part into inventory automatically with the auto receive checkbox it could mess up your average or FIFO costing.
So for instance if your part is a stock one with average cost and do auto receive on the last job operation then the materials that have been pulled into the job costs at that point will be the average cost per finished part. The rest of the materials or operation costs not pulled in will go to the Mfg Var accounts.
The part transaction history will show you this.
Brad Boes
bradboes@boosterpconsulting.com
231-845-1090
I’ll be honest upfront and say that I’ve only skim read the full detail of each already posted reply to this…
I had the same type of tool dispensing machine on the shop floor at a previous job. The supplier of the machine was running software to calculate inventory, and we got sent an excel sheet along with the invoice each month showing qty taken from the machine of each part number. What we didn’t know was which job it had been used on.
I reached out to the supplier, and was able to get them to activate another couple of prompts when the machine was issuing the item - it prompted for job number, which we scanned from the paper job traveller. Only a couple of people were able to get things out without a job number, handyman was able to get drills etc.
I didn’t get to the point of fully automating the entry of this info into Epicor. We got that info to our accounts team once per month, and then did a job adjustment to get the cost onto the correct job. If you were able to get the same info into CSV more regularly, then you could look to write something in C# that runs on a schedule and creates a material line on the job, then issues it?
Regards
Mark
That is exactly what I am trying to do. I have got it to where the machine will export the file. Epicor will take it, add the material to the job, but then I cannot figure out how to issue it via C#. I have a getto way of where it will set the material to back flush so then it will all be issued when closing the job (or when the operation is completed). I really do not like that, and would prefer to have the material issued right then and there.
Not sure if you have experience with issuing material via c#, but it is the bane of my existence currently.
private void IssuePart(PartInfo thePart, decimal Qty)
{ //uses job, WH, BIN, previously entered
//PartInfo should have all relevant info
//if we try ISSUE material NOT on bom - has to be on a mtl seq that exists but can change the PN - does it consume proper?
//oTrans.PushStatusText("Issuing "+thePart.PartNum,true);
edvIM = (EpiDataView)oTrans.EpiDataViews["IM"];
DataRowView dRow = edvIM.dataView[edvIM.Row];
IssueReturnAdapter ia = new IssueReturnAdapter(oTrans);
ia.BOConnect();
string msg;
bool reqInput;
string lgl;
string partTran;
ia.GetNewIssueReturnToJob(dRow["ToJobNum"].ToString(), (int)dRow["ToAssemblySeq"], "STK-MTL", Guid.NewGuid(), out msg);
//ia.get
Erp.BO.IssueReturnDataSet.IssueReturnRow row = ia.IssueReturnData.IssueReturn[0];
row.FromWarehouseCode = dRow["FromWarehouseCode"].ToString();
row.FromBinNum = dRow["FromBinNum"].ToString();
row.ToBinNum = dRow["ToBinNum"].ToString();
//row.LotNum = dRow["LotNum"].ToString(); // -- You said they arent LOT tracked
row.ToJobNum = dRow["ToJobNum"].ToString(); //probably already set but why not try again
row.ToWarehouseCode = dRow["ToWarehouseCode"].ToString();
//all this below is NOT in the dataView but from our "special" part
row.ToJobPartNum = thePart.PartNum;
row.ToJobSeqPartNum = thePart.PartNum;
row.ToJobSeq = thePart.MtlSeq; //has to be valid seq
row.PartNum = thePart.PartNum;
row.FromAssemblyPartNum = dRow["FromAssemblyPartNum"].ToString();
row.PartIUM = thePart.UOM;
row.DimCode = thePart.UOM;
row.DUM = thePart.UOM;
row.UM = thePart.UOM;
row.TranQty = Qty;
row.RowMod = "U";
ia.PrePerformMaterialMovement(out reqInput);
ia.PerformMaterialMovement(true, out lgl, out partTran);
}
2 Likes