I seem to remember a setting that prevents a user from over-issuing materials to a job, possibly combined with over/under threshold settings. I might be confusing my ERP systems (seen too many of them). Was this a setting in Epicor, or am I wrong?
P.
I am not an Ops guys so I cant tell you if there is already something in place for this, but as a Dev guy, I can tell you it would be pretty easy to roll your own with a BPM.
As a Dev guy would you look at PartTran.Update and do a post processing method directive?
My email response didnt quite work. I’d go with a method directive, pre process on the IssueReturn BO
There is a setting for sending shop warnings based on an under over thresh hold, as well as for auto closing jobs. But nothing for actually stopping the transaction from happening.
@Chris_Conn is right, that’s what’s BPMs are for.
Edit, this said labor detail but I changed it, because if you are issuing materials, that will be a different BO. I was confused because we back flushing everything, so it’s always based on labor qty in our situation.
And the challenge will be to figure out what too much is since you can have multiple transactions you have to see what’s already been issued. That can be a little tricky.
Trying this, but I can’t get it to fire on issuing more than the required qty. I tried a number of variations on my parameters, but I might not be using the right ones:
The ttIssueReturn.TranQty field of the added row is more than the dsIssueReturnRow.QtyRequired
-I cleaned up the expression in the C# editor, as I found a number of spaces surrounding the condition.
-I am not sure if I can just drop in the Qty Required field in the editor, so I tried things like turning it into a condition: (dsIssueReturnRow.QtyRequired+0). It validated it, but I know that doesn’t mean jack.
What else can I try?
Let’s take a quick step back. If you are only letting them issue what’s required, why not just back flush the materials? Then you only have to complete the operations. Just a thought.
Assuming you cant use @Banderson’s suggestion backflush,
You’re going to have to check already issued material + this attempted issue is less than or equal to the required material qty for the job.
Jobmtl table has a field issuedqty that aggregates all of the material issues for a specific material by job/assembly/op. Potentially you could put an in transaction data directive bpm that stops that field ever being higher than required qty - not sure how much detail you could put on the exception message - specifically whether you could say required qty is x, current issued qty is y, you are trying to issue z.
I’m assuming you are doing some kind of pre-labour transaction kitting activity and need stock to reflect this hence why backflushing will not work.
Here is code that I use in a Customization to the issue material screen. This was created with the wizard to trigger off of a field change to the TranQty field.
private void IssueReturn_AfterFieldChange(object sender, DataColumnChangeEventArgs args)
{
// ** Argument Properties and Uses **
// args.Row["FieldName"]
// args.Column, args.ProposedValue, args.Row
// Add Event Handler Code
switch (args.Column.ColumnName)
{
case "TranQty":
EpiDataView IMDataView = (EpiDataView)(oTrans.EpiDataViews["IM"]);
Decimal QtyRequired = (decimal)IMDataView.dataView[IMDataView.Row]["QtyRequired"];
Decimal TranQty = (decimal)IMDataView.dataView[IMDataView.Row]["TranQty"];
Decimal PreviouslyIssued = (decimal)IMDataView.dataView[IMDataView.Row]["QtyPreviouslyIssued"];
Decimal LeftToIssue = QtyRequired - PreviouslyIssued;
if(LeftToIssue < TranQty) {
DialogResult dialogResult = EpiMessageBox.Show("Continue? You are issuing more than required.", "Warning", MessageBoxButtons.YesNo);
if (dialogResult == DialogResult.Yes) {
//If Yes, (Do nothing for now)
}
else {
// Change Quantity back to Proper Quantity
args.Row["TranQty"] = QtyRequired - PreviouslyIssued;
}
}
break;
}
}We are backflushing at least our raw materials. A lot of the purchased parts get added to the job piece meal, so no backflush is used there.
But why not backflush those too? Are your operations a long enough duration that the lag is problematic?
It is a tracking thing; as soon as the part arrives it needs to go onto the assembly, and we want to show it issued as such.
So, another option is to buy directly to the job. This has some average costing ramifications, (since it skips inventory), but if that isn’t a problem, then receiving the materials issues it right to the job. Also, this means that each material sequence will need it’s own PO release, so there would be some procedural change there.
This is another “all or none” solution though, so if you have a lot of “it depends” type of situations where you need to decide, then manual issue is the way to go.
That is exactly what we are about to do… 