Lookup for Work Date field

Can you explain where I might find the detail/card screen? In FSM5.63 the time search screen had calendar lookups for the From Work Date and To Work Date Fields. Since this is no longer available, is this the new design intent? The customer would like to know if this feature could be added back to baseline?

There are still calendar lookups in FSM, however not for fields that function as a filter. The Time Search screen is a  screen with the ‘SEARCH’ pattern. This is typically a screen with filter fields. The fields in such a screen cannot be configured as a calendar lookup.

This is also the case with the screen pattern ‘STANDARD’, like the Time Tracker screen. This screen pattern always consists of a list and a detail screen behind it. When the screen is used, it opens the list part of the screen first. This part of the STANDARD screen pattern can be used by the user to find a specific record. This is supported with some filter fields. If those filter fields are date fields, then a calendar lookup is not an option. 

However if you zoom in on one specific record you land on a card/detail screen of that record. Any date fields in those screens can still be configured as a calendar lookup. 

I agree that it would be much more user friendly if filter fields can also be configured as a calendar lookup. I encountered the same issue once and found out that FSM apparently makes a distinction between filter-field and normal fields when it comes to the calendar loop-up functionality. I am only telling you how it is like now, because I am not part of IFS Development team. So if you have a customer who wants this, you should open an IFS case.

I guess there is a way to work around this shortage with configuration. However it is far-fetched in my opinion, I will share it anyway. You could try to configure a custom screen with ‘STANDARD’ screen pattern with a calendar lookup field in the detail part of the screen. Then you could try to set this field as a constraint for a child table (non-part_usage), and show the results in a tab of that screen. However this work around means that you have to build your screen on a primary table different then the non_part_usage table, maybe person... The date field that is used as your constraint could be some random user_def field which is configured as a date field. The ugliness in this work around is that you are actually storing a date value on some table, which is actually intended to be a filter. While a proper filter field, should be a temporary value which is not stored in the database but only has the purpose to find specific data.