Some sites need to display both numeric identifiers and human-friendly names for employees, organizations, room categories and types, buildings, and other data. Most existing Web Central views include only the primary or foreign key field, which is where the numeric ID is stored. For example, views showing rooms display Building Code and Department Code, but do not display Building Name and Department Name.
The report below illustrates the general issue. Imagine that the Room Category, Room Type, Division Code, Department Code, and Employee Name fields were all just numeric values; the form could not be used off-the-shelf. You would need to add the name fields to the view manually, for example, dp.name
, rmcat.description
, and so on.
You may need to change forms, reports, and other views to meet this requirement, and you may need to re-implement the changes with every release. The Automatic ID Lookup feature obviates the need for this customization because it automatically displays in views and controls a designated human-readable name or title field alongside -- or instead of -- the numeric code field. ARCHIBUS views and reports can be configured to work using numeric primary keys.
Automatic ID Lookup:
You may want to use the Automatic ID Lookup feature in these cases:
bl_id
and use more recognizable names in bl.name
; as another example, sites use FICM standard numbers for rm_cat
and rm_type,
with human readable names in description field (100=Offices). Other sites always use alphanumeric codes for ID fields. The ability to show both the code and a human-readable name speeds work and enhances the clarity of reports. em_id
). Mid-sized and large-sized companies will almost always use a numeric code for all employee records. Names change often due to marriage, divorce, and data entry errors. Variations (like Nick, Nicholas, Nicholas K,) all lead to duplicate and erroneous data. Multiple employees with the same name (Lee, Gina) are common. Numeric IDs are stored in em_id
, but users will want to see and work with the employee name (ABERNATHY, ALLISON) stored in a new em.name
field. In some use cases, you will want to see both names and numbers (ABERNATHY, ALLISON – 121242).The documentation for Automatic ID Lookup uses these terms: .
dp.dp_id
or bl.bl_id
, or as a foreign key to the validating table, such as rm.dp_id
or rm.bl_id
. Instead of displaying these fields in forms and reports to identify the validated value, you can display the lookup field instead. dp.name
or bl.name
, instead of the ID field, such as dp.dp_id
or bl.bl_id
. programtype.description
. Forms and reports display this field if the user's locale is English OR if the Translatable field corresponding to the user’s locale is empty. Lookup fields are often translatable fields. programtype.description_es
. Forms and reports display this field if the user's locale matches the language AND the field is not empty.Configuring Automatic ID Lookup
Using Automatic ID Lookup in Data Sources
Using Automatic ID Lookup in Views
Using Automatic ID Lookup in Custom Code
Using Automatic ID Lookup for Translatable Fields
Upgrading Existing Applications to Support Automatic ID Lookup
Copyright © 1984-2019, ARCHIBUS, Inc. All rights reserved. |