Does anyone know a way to get a Scrap QTY or a Scrap Percentage to Cascade down an assembly with Subassemblies without having to edit each and every operation?
Ex: The Primary Assembly requires 100 pieces to complete; however, we have 10 marked as scrap. What we are realizing is that each subassembly is not being updated to include a total of 110 prod QTY.
Our Production Engineers do not want to update the MOM or the Scrap Percentage due to the lack of rounding in the final production numbers.
Any thoughts or suggestions would be greatly appreciated.
I had to write an Efx to do something very similar to this. We set quantity-based scrap on jobs based on a formula, one which doesn’t map to the quantity-or-percentage system that scrap uses by default. I wrote a small func to go through and apply the logic our Org uses, to calculate a quantity-based scrap amount per-operation, based on some part and job parameters.
That said, it’s one of my earlier Efx and it needs to be rewritten to use BO method calls instead of Db-space writes. Because it isn’t following best practices, I won’t be posting the current-version’s code.
Whether you’re doing it with widgets or C#, though, the core idea is the same: The data you want comes from JobEntry, and will be available in the tableset you pull down through JobEntry.GetByID().
For Each Operation:
GetByID
Edit Opr Scrap Qty
Call ChangeJobOperEstScrap
Edit Scrap Type
Call ChangeJobOperEstScrapType
Update()
For Each Material (If Applicable):
GetByID
Edit Mtl Scrap Qty
Call ChangeJobMtlEstScrap
Edit Scrap Type
Call ChangeJobMtlEstScrapType
Update()
Setting this loop up in widgets is almost certainly going to be annoying, but I think it’s possible.
I wrote mine as Custom Code. You might be able to get away without the fresh GetByID() at the front of each material/operation. It seems like it’s up in the air per-screen whether or not that breaks the Update() at the end.
I’m sure this can be optimized further, but the min-viable code here looks something like below:
// we need to orchestrate this somehow and we'll be dumping the tableset in between each run, so let's hydrate a List<JobOper> real quick.
var ListOfOperations = from jorow in Db.JobOper where jorow.JobNum == someParameter select jorow);
if(ListOfOperations.Any())
{
foreach (var dbOper in ListOfOperations.ToList())
{
// instantiate a reference to the BO object
this.CallService<Erp.Contracts.BusinessObjectSvcContract>
(BOSvc =>
{
// grab this job's tableset
var Tableset = BOSvc.GetByID(dbOper.JobNum);
// find this Operation in the tableset
var tsOperRC = from oper in Tableset.JobOper where thing == thing2 select oper;
// if Count > 1, your query isn't filtering to the correct row
if(tsOperRC.Count == 1)
{
// pop the row off the RowCollection
tsOper = tsOperRC.First();
// Set scrap amount and recalc
tsOper.EstScrap = something;
BOSvc.ChangeJobOperEstScrap(Tableset);
// Set scrap type and recalc
tsOper.EstScrapType = "Q" or "%";
BOSvc.ChangeJobOperEstScrapType(Tableset);
// Update this Operation, dump the tableset.
BOSvc.Update(ref Tableset);
}
}
);
}
}
One issue we have to calculate the “Total Scrap Qty” of the job is that operation scrap factors on top of each others.
For example, a job has a base ProdQty of 100. OprSeq 10 has a scrap perc. of 5% and OprSeq 40 has also a scrap perc. of 3%. The “Total Prod Quantity” needed is 100 X 1.03 X 1.05 = 108.15, rounded up to 109. So we want to start the production with a ProdQty of 109 so that in the end, on the worst case scenario, the final completed quantity is at least 100 if the operations generates the estimated scrap.
We ended up creating an Epicor function that runs of Job Firm. It iterates through the JobOpers and calculate the true ProdQty, then edit the JobProd Prod Qty, then flushes the JobOper and JobMaterial Scrap percentages. Very specific to our use case but nothing vanilla comes close to this behavior