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.
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.