Are those sequences valid rework operations?
Yes they are valid rework operations. I have the same type of customization in Classic mode that works find for the same Job/Asm/Opr. The issue is in trying to convert the prior Classic customization to work in Kinetic.
I think what is happening is once I select a DMR # from my new custom Combo, the Assembly and OprSeq I selected prior is lost so when I click OK and the ValidateReferentialIntegrity is executed the Assembly and OprSeq are null. Just not sure what in my custom Reusable Combo is causing this or what to do to resolve.
What do you have set for “display” and “value” waaaay at the bottom of the reusable combo?
That looks fine.
What’s the flow of your customization?
Fill out the job/asm/op and it filters the list of the DMRs?
Or are you selecting a DMR and having the job/asm/op populate from the selected DMR?
Fill out the Job/Asm/Op and it filters the list of the DMRs. Then I select a DMR from the list.
Interesting.
If you run it as base with the same values, does it work?
If by run it as base you mean run it without this customization…yes it works with the same Job/Asm/Op. I also have a similar customization in Classic MES and it runs as expected using this Job/Asm/Op. In order to convert my customization to Kinetic I had to use a different BAQ as the parameters I had in my classic customization were not working for Kinetic.
What I’m getting at is it doesn’t seem to be a problem with your UD DMR field (which appears to be working as it’s filtering and pulling a DMR number). It’s complaining about the OP/ASM which you filled out manually. There shouldn’t be any problems with validation of those fields since they’re not controlled by custom logic.
Do you know anything about the ValidateReferentialIntegrity method as this seems to be executing when I click OK after entering the Rework Code, Job, Asm, Op, DMR
Not 100% sure, but it may be trying to make sure the foreign key exists in another table.
Few things to try:
- Run a BAQ for the LaborDtl table and make sure you can pull up a record with job/am/op 2357-52/5/40
- Try your customization with a different job/asm/op and see if you get the same error.
- Run your customization in the browser, enable Dev Tools and trace what Epicor is doing to look for clues.
I had already tried #1 and 2. BAQ for LaborDtl returns data for this Job/asm/op. I have tried other Job/asm/op with same results.
#3 - just tried this and while I am not very familiar with Dev Tool it seems to be returning an error “Ensure CORS response header values are valid”. I have no idea what this means.
Ah–sorry. You’ll have to do a bit more work for the Dev Tools: How To: Debugging Kinetic (Browser) - Experts’ Corner - Epicor User Help Forum (epiusers.help)
You can ignore the CORS message.
1 Like
THANK YOU!!! Dev Tools helped me resolve the issue. The Data EpBinding was incorrect and was populating the DMR # selected into the LaborDtl.JobNum.
I had this correct at one point but had made so many different changes trying to get the DMR drop list to return the correct values. As soon as I saw the data populated in the LaborDtl data view JobNum field I knew exactly what was wrong. 
2 Likes