10.2.700.8 Process Calling Maintenance For Lot Attributes - New Issue

Hey guys, has anybody experienced a new issue in 10.2.700.8 where using process calling maintenance does not seem to be working correctly for customizations to the lot attributes dialog? I have used this technique in the past and it worked but seem to be having challenges in this latest release. For reference, this is a public cloud installation of 10.2.700.8. Here is what I have done:

  1. I customized lot entry and the lot entry attributes subform, giving them the same customization name.
  2. I added a menu entry under Processes for LotEntry that points to this customization.
  3. I added a process calling maintenance entry. There was a bit of a change here that I noticed from tracing it out - in the past I would have put Erp.UI.LotNumberEntry in for ā€˜Called Process Referenceā€™ but it seems in this version it expects PRIM0001. Regardless, I have the entry and have it pointed to my custom menu entry.

I know that the process calling maintenance entry is working because if I purposely provide an invalid menu ID I will get an error when the lot attributes dialog is being presented that the menu ID is not valid for the user. But if I set it correctly I seem to always just get the standard Epicor lot attributes dialog (no customization). Of course, if I am in developer mode and pick my customization all works perfectly.

From some other posts I noted possibly Menu.Arguments is messed up in a way that cannot be fixed via the UI. On an older, working environment Iā€™d see the arguments for my custom menu entry would have just said ā€œ-c MyCustomizationNameā€ and now we have the new ā€œ-KineticUIā€ flag getting in there too. I tried zapping that via a UBAQ but that didnā€™t fix anything. I also tried adding ā€œ-formName LotAttributesFormā€ with no luck either.

I am out of ideas - anything else you smart folks can think I can try?

1 Like

Update - I worked with Epicor support on this and they got me a resolution. I have to admit I donā€™t fully understand why it works, but it works:

  1. The calling form (Job Receipt To Inventory) had a customization named JobReceipt_20210114. We saved the customization for lot attributes out to this same name (even though lot attributes is not a subform of job receipt to inventory).

  2. We did a ā€˜Copy To Current Companyā€™ for the Epicor process in menu maintenance for PRIM0001.

  3. We used an updatable BAQ to set the argument ā€œ-c JobReceipt_20210114ā€ for the menu maintenance entry for PRIM0001 (it could not be set via GUI).

  4. We added a processing calling maintenance entry that looked like this:

Then after restarting the client it seemed to work as expected. If I had to guess what was going on, even though the process calling menu entry before was pointing to the correct customization (and we could see that it was supposedly running it via Help / About) that it would ONLY load a customization named the exact same as the original launching form. Anyway, Iā€™m keeping my notes handy as I suspect this is still some form of bug that will ultimately get fixed and require revisions here.

Thanks Adam, glad you got it working. Keep up the great work!

1 Like