I can’t replicate the issue in my development environment at 10.2.200.3 which is unfortunate, but I have parts that are lot tracked and are marked mandatory for certain part lot attributes (Expire date). I’ve also verified that we are not exempting the part from attribute check at any point.
We’ve always been prompted to add the mandatory part lot attributes when creating new lots, such as during PO receipt or quantity adjustment.
Now, it simply does not prompt the modal dialog for part lot attributes.
Epicor support has been unable to reproduce the issue in their environment.
Has anyone else experienced and if so, were you able to fix?
Thanks in advance
have you tried this from multiple client workstations?
Are you trying from Epicor Everywhere using a web browser?
I have seen weird problems where something like this will happen on one workstation, but all others are fine.
otherwise, you need to get Support to help you resolve this.
Hey Tim thanks for the reply.
I’ve tried from multiple workstations and we are not using epicor everywhere.
The tough part is that epicor wasn’t able to replicate, which always complicates a resolution
I created a new environment at the same version as LIVE (10.2.200.3) and took a copy of LIVE and restored into this new environment.
I am unable to recreate the issue in the new environment, leading me to believe this is not a data driven issue.
Epicor support was unable to help and I requested to be able to send a copy of the database, although I have little faith that this will expedite a resolution given that it doesn’t appear to be data driven.
To be clear, you have fields like Part.AttExpDt = TRUE and there is no prompt for an expiration date? I know that recently I uploaded new parts using DMT and simply setting TrackLots = TRUE and setting Part.ExpireDt = TRUE did not require the expiration date. The new Part.Att… fields are where it’s now stored.
I think I’ve narrowed down the issue, but am no closer to resolution.
I have a BPM that fires on Receipt.GetDtlPOLineInfo. This BPM fires the post processing and does the following. First, it sets the BPM Number01var equal to the ttRcvDtlRow.PONum expression. Next, I call a custom code block to look up the first release record of the PORel table using the variable I set before:
In this block, I set callContextBPMData.ShortChar01 equal to a custom field on PORel called LotNum_c.
Lastly, I use a field setter to set the ttRcvDtl.LotNum field of all rows equal to the ShortChar01 expression I defined above.
Note: This code has worked for years and continues to work, but I did notice that now, in this version of Epicor, it fails to fire a very important method called Receipt.CheckDtlLotInfo.
To test, I manually typed in a lot number on a receipt line and this CheckDtlLotInfo method fires. When I set the LotNum field from any code, it fails to fire the method.
It seems to me that the CheckDtlLotInfo method should be invoked but it’s not, unless I manually type in the lot into the UI.
By any chance did you ever manage to resolve this issue? I am exactly where you were at when you last posted about this. The ‘Receipt.CheckDtlLotInfo’ does not fire. I have even tried invoking it in a BPM but it still only fires if the lot number is typed into the field. Any assistance will be highly appreciated.
Hey, no I never did figure out what was going on. Unfortunately because I have customization on that functionality, I was never able to get proper support for it either
I saw this in Customer Shipment Entry: when shipping from inventory and entering a new lot number, the lot attributes dialog box appears and requires the attributes, but when shipping from a job and entering a new lot number, there is no dialog box. The shipment can be completed without entering the required lot attributes.
Perhaps you could put in a ticket? Not sure if you have customization related to this functionality but I’d be really interested in this behavior if you don’t. Curious what support could make of it
Having the same problem in 10.2.700, some jobs with the same part refuses to open the lot attribute screen when doing receipt from mfg. Next job working without a problem. I am currently searching the database to see what information will drive this.
I have same problem in 2024.2.11. I am not using much custom code on this. I did notice that the Part.AttExpDt being set to ‘M’ doesn’t force the Part.LotExpDt booling logic to ‘TRUE’. I am quite convinced it is the boolean that is driving the requirement for the user to set a valid date that is recorded in the PartLot table. I don’t see on the base Kinetic UI where I can hit the Part.LotExpDt directly, so I hit it via DMT to fix my current problem and will probably look at either adding it to my UI or creating a BPM that will change the boolean flag based on the Part.AttExpDt field value.
