Async failures on Effective Dated Q

We updated 8/26 Landmark from 10.1.1.73 to 10.1.1.76 8/27 TM from 11.0.36 to 11.0.0.37

We set effective dates relating to transfers, promotions, etc for the beginning of pay period.

9/3 was next pay begin following those updates. Majority of our effective dated transactions now fail with object already exists as of effective date and lists out the audit number and effective date trans number.

This has occurred 3 pay begins in a row.

Support is trying to work with developers. Last night they said 'it's not landmark' and are transferring to a TM developer.

Didn't know if anyone else might possibly have had same issue.

I've dumped transactions to .xls and looked everyone up individually to see if I could find any commonality or manager, org related but there is nothing I can see.

We have to cancel the triggers thru async and then just look up the Action Request and re-key everything with back dating the transactions/requests.

Just thought I'd reach out to see if anyone had any words of wisdom.

Find more posts tagged with

Comments

Legacy Contributor

We experience this same issue, however, we requeue the action from the Failed tab. We opened a ticket as well and they told us it was due to multiple actions being submitted on the same employee.

Legacy Contributor

Reque doesn't work in this situation. there can be multiple actions on employee.. just need to reque in order but that's not the case here. Example, there is one employee that has 3 transactions.. 'oldest/first' one failed with 'already exists as of effect date' and the other 2 fail because of "Previous pending unprocessed changes" which makes sense.

Thanks though

connie-rodriguez

We are not experiencing that issue and use beginning of pay period dates as well for most of our HR Actions. The only difference I see is that we went to LM 10.1.1.77.3706 with the same TM 11.0.0.37

4019_4749_Infor dEPM v12.0.5 Demonstrating New Features in Mobile Applications.mp4

Legacy Contributor

FYI.. this has finally been identified as a bug and they did a Landmark CU for the fix. We have been cancelling/re keying anything future effective dated since September 3.

0712131256598360.doc

Legacy Contributor

We believe we have same/similar problems on earlier landmark 10.1.1.52 but current TM 11.0.0.37.

Thanks for update.

Legacy Contributor

After we upgraded to Landmark 10.1.1.76 and LTM 11.0.0.39 we started having problems with future dated transactions.

It appears that a bug was introduced in release 76 that requires an upgrade to Landmark 10.1.1.78.

From Infor:

"This is a bug that was fixed in Landmark 10.1.1.78. We strongly recommend upgrading as the work arounds we have are a bit manual. Until upgrading I would have the users not enter the transactions until the day of. If using an approval flow, they can be entered but not approved until the day of."

This has cause us MANY problem and MANY hours of research and now retesting a new release just a few weeks after we went to Landmark 10.1.1.76.

Please alert everyone that the LTM 11.0.0.38 documentation states: "GHR/TM 11.0.0.38 requires Landmark 10.1.1 CU 76 (or higher 10.1.1 build)." Please DO NOT load 10.1.1.76 as stated above IT HAS A BUG, instead load Landmark 10.1.1.78 which hopefully will solve this introduced problem.

For total awareness, we will be loading CU78 in non-prod this weekend, so hopefully this error will be solved.

PropertyOrder_UL.gif

Copyright © 2025 Infor. All rights reserved.