SG-1560 PM Schedules | Equipment - Incorrect organization filter for Employee lookup - HxGN EAM - Version 12.0 - Hexagon

HxGN EAM Resolved Issues for 2022

Language
English
Product
HxGN EAM
Search by Category
HxGN EAM Version
12

SG-1560 PM Schedules | Equipment - Incorrect organization filter for Employee lookup

 Description 

In the PM Equipment tab a non-common Work Order Organization is required. In this tab it is also possible to assign a technician (Employee) to the related work orders via the \\"Assigned To\\" field.

Issue 1: the lookup for Assigned To lists all employees including those for other non-common organizations (so too many employees). See screenshots. As this Assigned To field serves as a default value for the Assigned To field on the work order the lookup should show the same

values (the Assigned To lookup on the Work Order screen is correct).

Issue 2. On the PM equipment tab a User Defined Field has been configured to be able to assign a second employee to the PM Work Order. The setup for this UDF (on the Work Order screen) has linked it to Entity PERS. Now the result is that the lookup for that field only shows employees linked to a common organization: too few employees.

These two issues are in fact independent bugs but related from a user's perspective.

*Actual results*

Seeing different Employee records according to which employee field is used (Assigned to, UDF linked to PERS entity).

*Expected results*

(Maybe) every Employee field should show the same list of employee records (?)

*Steps to reproduce*

1. Go to PM - Equipment screen

2. Select an organization

3. Click Assigned to : issue 1.

4. Setup a UDF on PERS entity (needs to be done in work order screen)

5. Click LOV of the UDF in the PM-Equipment tab: issue 2

6. Go to the work order screen and click Assigned to. See excel sheet Assignedto

7. In the work order screen, click the UDF (from point 4). See excel sheet Assigneto

The problem is that many different results are encountered. The number of shown employees differs (the problem is not the number of course, but the difference of values in the LOV).

Is this a bug ?