Skip to main content
Question

IFS Cloud 24R1 Service Update 22 SU22 - Time Clock won't pull company name

  • April 6, 2026
  • 2 replies
  • 11 views
J
Do Gooder (Customer)
Forum|alt.badge.img+7

We recently applied SU22, going from 24R1 SU6 to SU22.  After we applied the SU, their were two areas in IFS that did not work anymore.  We could not use the time clock app, it would not pull the company name after trying to perform normal IN / OUT clocking’s.  The other, we could not perform month end financials.  We have always used the out of the box IFS lobby (since Apps 10) for month end and certain reposting transactions were not showing in the lobby to close.

 

The fix for the Time Clock app for anyone who comes up against this is to check your Company Details under HCM and make sure you have a Company ID Alias defined.  In our case we just put 1 in this field.  If this is not defined, apparently, time clock can’t pull the company name.

 

We are still waiting for a root cause on the month end issue.

 

Does IFS provide anything that calls out changes in their system when they now require certain basic data fields?  Or do they just release SU’s and wish you good luck?

 

No where in the technical documentation does it specify that you need a Company Alias ID specified.  We’ve been on IFS since Apps 9/10, and this has never been set.

https://docs.ifs.com/techdocs/24r1/070_remote_deploy/400_installation_options/130_add-on_cmp/timclo/#user_and_person_creation

2 replies

L
Hero (Partner)
Forum|alt.badge.img+9
  • Lingesan08
  • Hero (Partner)
  • April 6, 2026

We recently applied SU22, going from 24R1 SU6 to SU22.  After we applied the SU, their were two areas in IFS that did not work anymore.  We could not use the time clock app, it would not pull the company name after trying to perform normal IN / OUT clocking’s.  The other, we could not perform month end financials.  We have always used the out of the box IFS lobby (since Apps 10) for month end and certain reposting transactions were not showing in the lobby to close.

 

The fix for the Time Clock app for anyone who comes up against this is to check your Company Details under HCM and make sure you have a Company ID Alias defined.  In our case we just put 1 in this field.  If this is not defined, apparently, time clock can’t pull the company name.

 

We are still waiting for a root cause on the month end issue.

 

Does IFS provide anything that calls out changes in their system when they now require certain basic data fields?  Or do they just release SU’s and wish you good luck?

 

No where in the technical documentation does it specify that you need a Company Alias ID specified.  We’ve been on IFS since Apps 9/10, and this has never been set.

https://docs.ifs.com/techdocs/24r1/070_remote_deploy/400_installation_options/130_add-on_cmp/timclo/#user_and_person_creation

​@jchristy ,

Hi,

Thanks for sharing the workaround regarding the Company Alias ID — that’s useful.

What you are experiencing is not uncommon after service updates, where certain fields become implicitly required due to changes in underlying logic, even if not clearly documented.

IFS typically communicates such changes through:

  • Release Notes / Service Update Notes

  • Technical Documentation updates

  • Sometimes via Knowledge Base articles

However, not all implicit dependencies (like this one) are always clearly highlighted, especially for basic data assumptions.

For the month-end issue, it might be worth checking:

  • Posting control configurations

  • Lobby data sources / background jobs

  • Any failed or pending postings after the update

Also, raising a support case with IFS is recommended, as they can confirm if this is a known issue or regression in SU22.

Would be good to hear if others have seen similar behavior after this SU.

Thanks

Regards, Lingesan R , www.linkedin.com/in/lingesanr86
J
Do Gooder (Customer)
Forum|alt.badge.img+7
  • jchristy
  • Author
  • Do Gooder (Customer)
  • April 6, 2026

Appreciate the response, we did raise cases with IFS for both issues that we noticed so far.

 

If IFS is requiring it’s user base to keep current to at least the 4th most recent version of IFS Cloud, they have to communicate better of changes to their underlying architecture.  This wasn’t even an SR, it was an SU.

 

You will begin to erode the trust of your user base if you cannot apply an SU without fear of it breaking core functionality of IFS.  Someone in R&D made that change for the time clock app, for whatever reason, and this must be surfaced as a requirement to the user base in some form.  If you work with IFS and your in the IT department, your familiar with software updates.  IFS is the only software product that I am certain will break something in IFS if I update it, it's not an integration or a customization - it's core IFS functionality that will fail.

 

IFS customers who went to IFS Cloud saw a substantial price increase, it is by far the most expensive software in our environment and I’m sure many customers would say the same.  IFS has lately seemed more focused on acquiring companies and talking about AI than putting money into their core product for existing customers and ensuring it works reliably.  Our journey from Apps 10 to IFS Cloud has been a struggle, every hood we open in IFS there’s a note left behind by R&D that says “I.O.U. Base Profiles, Permission Sets, Reporting Pods that don’t crash, Crystal reports, Session timeout setting, Advanced Search, Minimal Downtime for updates, Table View default” - I could go on and on.  Yes, some of this has been addressed beyond 24R1, but these were all things we had in Apps 10.

 

To expect the customers to perform a UAT after every SR or SU if you use IFS quote to cash - it's not sustainable.

 

Sorry about the rant!

Terms & ConditionsCookie settingsAccessibility statement