User-defined field (UDF) validationlists were originally developed for that purpose i.e. to validate data enteredin to a user-defined field.
However, because they are amulti-column user defined table they can be used for a multitude of otherpurposes and, perhaps as importantly, they can be maintained within theEnterprise application.
Other uses that you can putthem to include:
· Mapping an external system code to an internalEnterprise code
o Youmay have a pre-cost loader program that takes a supplier’s cost code andtranslates it to an Elite one during the load process. You could hardcode this into the applicationor, more flexibly, build a 2-column UDF validation list using the value anddescription columns that maps between the two system codes. When the codes change or new ones becomeavailable you simply update the UDF validation list rather than having tore-write your code.
· Mapping an internal Elite code to an external code
o You may have a requirement to output specificinformation for a bill for a specific client. Maybe you’re sending some analysis of billings to a client who wants touse their own codes. Again simply maintaina 2-column UDF validation list utilizing the value and description columns tomap between the 2 values.
· 3rd Party application input validation
o One of your load programs may only be allowed to usecertain costcodes. You could use anunused field on the costcode if you have one or, you could maintain a 1-column UDFvalidation list of allowable entries.
· GL segment Validation List
o Maybe you want a GL segment to consist of a subset ofvalues or a custom set of values. Bywriting an Enterprise Query that validates against a UDF validation list ratherthan using the standard validation tables such as location, department you cancreate new firm–specific GL segments such as project codes, timekeeper group codesetc.
To access the data in a UDFvalidation list you would usually use a query like
SELECT udvalue, uddesc
FROM udfvlst
WHERE udfvlst = “My Validationlist”
