BPM is interfering with serial numbers

[Valentina (Valentina Busti)]

We have a BPM to prevent overbooking labour quantity. We are also testing introduction of Serial Numbers in production.
The BPM somehow interfere with the serial numbers and when booking a quantity of more than 1, with allocated serial number, it stops the process and triggers an error:

Business Layer Exception

More than one entry for T50010 is not allowed

Exception caught in: Epicor.ServiceModel

Error Detail
============More than one entry for T50010 is not allowed
Description:
Program: Erp.Services.BO.Labor.dll
Method: validateSerial
Line Number: 17283
Column Number: 21
Table: LbrScrapSerialNumbers
[…]

The custom code used in the BPM is below:

Erp.Tables.JobOper JobOper;
 var ttLaborDtl_xRow = (from ttLaborDtl_Row in ttLaborDtl select ttLaborDtl_Row).FirstOrDefault();
 
 if (ttLaborDtl_xRow != null)
 
     {
         var JobOper_xRow = (from JobOper_Row in Db.JobOper where JobOper_Row.JobNum == ttLaborDtl_xRow.JobNum && JobOper_Row.OprSeq == ttLaborDtl_xRow.OprSeq && JobOper_Row.Company == ttLaborDtl_xRow.Company && JobOper_Row.AssemblySeq == ttLaborDtl_xRow.AssemblySeq select JobOper_Row).FirstOrDefault();
 
       callContextBpmData.Number01 = JobOper_xRow.RunQty;
       callContextBpmData.Number02 = JobOper_xRow.QtyCompleted;
       callContextBpmData.Number03 = Math.Round((JobOper_xRow.RunQty) - (JobOper_xRow.QtyCompleted), 2);  
     }  

The rest of the BPM uses callContextBpmData.Number03

[josecgomez]

That error isn’t coming from a BPM its coming from the validateSerial method in the Business Object.

[Valentina (Valentina Busti)]

Yes, but when the BPM is not enabled the issue is not there (and EpicCare cannot help with BPM issues)

[josecgomez]

Is this the whole BPM? Or is there more to it, what you showed doesn’t do anything… that could remotely affect … well anything.

[Valentina (Valentina Busti)]

Yes, of course. That was just the custom code that is used to define the remaining quantity.
The BPM is on the Labor Update

Condition 2: The ttLaborDtl.LaborType field of the changed row is not equal to “I”
Condition 1: The ttLaborDtl.LaborQty field of the changed row is more than the callContextBpmData.Number03
Condition 3: the method is called by Manager
Show message in case the user is allowed but warned
Raise Exeption 1 if the user is not allowed

[josecgomez]

yeah again that custom code isn’t doing anything that would cause an error. Do me a favor and comment out all the code and just put this there

Ice.Diagnostics.Log.WriteEntry("Test");

Do you still see an error?

[Valentina (Valentina Busti)]

Still the same error

[josecgomez]

ok so that tells you the issue is not the BPM. There’s no code there that could affect it. I’m guessing you are having some functional or setup issue with your serial numbers or serial tracked parts.

[Valentina (Valentina Busti)]

Sorry, I have tried again with the test code and it gave the correct warning message.
So it seems the issue is still in the code.

[knash (Ken Nash)]

We have had the same issue here. We changed Conditions to be updated row vs changed row.

Problem went away.

[gary.kite (Gary)]

Hi

Thanks for this, I have just changed our BPM and it fixed the problem

[Doug.C (Doug Crabtree)]

I just ran into this problem and had to write a code block to do my condition statement. Nothing I tried in the condition block would get rid of the “More than one entry…” error.

[josecgomez]

Yeah there’s no way around this in a bpm

[Doug.C (Doug Crabtree)]

This is the same issue as it turns out:

First receipt record in BPM is consumed?

Another wrinkle (support sent me to this site for help ) I moved the Pre-Processing BPM to PreUpdate, since this is the first step in the tracing. When I do everything correctly (meaning the BPM fires, but doesn’t stop) I get the following weirdness: [image] I enter the 4 serial numbers: [image] I save the receipt: [image] Here is what the serial number selection looks like now: [image] I’m just unsure if I should call this an Epicor bug? They seem to be telling me it’s outsi…

I wrote my own code block in there just now and the problem went away. I guess I could look at the base code to see what they are doing, but for now I’m ok knowing there is a workaround.

[Neil_Jones]

Just found the same issue, would have taken ages to found this problem without this thread. Like Jose says the error doesn’t make sense but the widget certainly appears to be the cause.

[tgwinn (Tim Gwinn)]

Sorry to necro this, but I thought this was useful to mention:

In Kinetic 2022 I had a similar error condition, on the same Labor.Update BO. In my case the error did not occur on our PILOT system, but did on the LIVE system. The difference was that the BPM on LIVE had a condition entry before the custom code block, just like ‘Condition 2’ in the diagram, whereas on PILOT this condition did not exist.

Resolution was to delete the ‘Condition 2’ block, and add its condition criteria as another line in the ‘Condition 1’ block (i.e., after the custom code block). I did not need to alter ‘changed row’ to ‘updated row’ on any of the condition criteria.