A flag indicating whether or not runtime error messaging will occur when an error message is issued from a business function.        0 = allow 
runtime error message handling.        1 = suppress runtime error message handling.

A code that identifies and defines a unit of information. It is an alphanumeric code up to 8 characters long that does not allow blanks or 
special characters such as %, &, or +. You create new data items using system codes 55-59. You cannot change the alias.

An alphanumeric code that identifies a separate entity within a business for which you want to track costs. For example, a business unit 
might be a warehouse location, job, project, work center, branch, or plant. You can assign a business unit to a document, entity, or person for 
purposes of responsibility reporting. For example, the system provides reports of open accounts payable and accounts receivable by 
business unit to track equipment by responsible department. Business unit security might prevent you from viewing information about business units 
for which you have no authority.

The unique identification for a test to be performed on an item. For example:    COL Color test    DENS Density Test    CL-2   Clarity Test 

The Instructed Start Date and Time of an operation.

Brief information about an item; a remark or an explanation.

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

A date that indicates one of the following:     o When a component part goes into effect on a bill of material     o When a routing step goes into 
effect as a sequence on the routing for an item     o When a rate schedule is in effect The default is the current system date. You can enter 
future effective dates so that the system plans for upcoming changes. Items that are no longer effective in the future can still be recorded and 
recognized in Product Costing, Shop Floor Management, and Capacity Requirements Planning. The Material Requirements Planning system 
determines valid components by effectivity dates, not by the bill of material revision level. Some forms display data based on the effectivity 
dates you enter.

A date that indicates one of the following:     o When a component part is no longer in effect on a bill of material     o When a routing step is no 
longer in effect as a sequence on the routing for an item     o When a rate schedule is no longer active The default is December 31 of the 
default year defined in the Data Dictionary for Century Change Year. You can enter future effective dates so that the system plans for upcoming 
changes. Items that are no longer effective in the future can still be recorded and recognized in Product Costing, Shop Floor Management, 
and Capacity Requirements Planning. The Material Requirements Planning system determines valid components by effectivity dates, not by 
the bill of material revision level. Some forms display data based on the effectivity dates you enter.

A flag indicating whether or not runtime error messaging will occur when an error message is issued from a business function.        0 = allow 
runtime error message handling.        1 = suppress runtime error message handling.

A code that identifies and defines a unit of information. It is an alphanumeric code up to 8 characters long that does not allow blanks or 
special characters such as %, &, or +. You create new data items using system codes 55-59. You cannot change the alias.

An alphanumeric code that identifies a separate entity within a business for which you want to track costs. For example, a business unit 
might be a warehouse location, job, project, work center, branch, or plant. You can assign a business unit to a document, entity, or person for 
purposes of responsibility reporting. For example, the system provides reports of open accounts payable and accounts receivable by 
business unit to track equipment by responsible department. Business unit security might prevent you from viewing information about business units 
for which you have no authority.

The unique identification for a test to be performed on an item. For example:    COL Color test    DENS Density Test    CL-2   Clarity Test 

The Instructed Start Date and Time of an operation.

Brief information about an item; a remark or an explanation.

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

A date that indicates one of the following:     o When a component part goes into effect on a bill of material     o When a routing step goes into 
effect as a sequence on the routing for an item     o When a rate schedule is in effect The default is the current system date. You can enter 
future effective dates so that the system plans for upcoming changes. Items that are no longer effective in the future can still be recorded and 
recognized in Product Costing, Shop Floor Management, and Capacity Requirements Planning. The Material Requirements Planning system 
determines valid components by effectivity dates, not by the bill of material revision level. Some forms display data based on the effectivity 
dates you enter.

A date that indicates one of the following:     o When a component part is no longer in effect on a bill of material     o When a routing step is no 
longer in effect as a sequence on the routing for an item     o When a rate schedule is no longer active The default is December 31 of the 
default year defined in the Data Dictionary for Century Change Year. You can enter future effective dates so that the system plans for upcoming 
changes. Items that are no longer effective in the future can still be recorded and recognized in Product Costing, Shop Floor Management, 
and Capacity Requirements Planning. The Material Requirements Planning system determines valid components by effectivity dates, not by 
the bill of material revision level. Some forms display data based on the effectivity dates you enter.

A value that specifies how the system processes tests as you enter test results. Valid values are:    R  Required. Result values must be 
within the allowable range for the test to pass. The system does not allow an item to pass quality inspection until you enter results for each 
required test.    O  Optional. Result values are optional during results entry. The system does not require the entry of a result for each optional test. 
However, if you enter failing results, the item fails quality inspection.    G  Guaranteed. Result values are optional during results entry. You can 
control whether Guaranteed tests appear as you enter test results with the Display Test field on Test Revisions. In addition, guaranteed tests 
print on the Certificate of Analysis.

Unique name used to group test results.

A code (31B/QB) used in the Blend Management system to indicate the blending rule for results.  

Determines whether a test result value will be numeric or alphanumeric. Valid values are:    1   Indicates that the result value is numeric and 
should be right justified.    0   Indicates that the result value is alphanumeric and should be left justified. Tests that are using alphanumeric result 
values can have User Defined Code tables setup that contain alpha to numeric translations. The purpose of these tables is to supply result 
evaluations with a way of determining whether a result is within the range of the minimum and maximum values.

The job number (work station ID) which executed the particular job.

A flag indicating whether or not runtime error messaging will occur when an error message is issued from a business function.        0 = allow 
runtime error message handling.        1 = suppress runtime error message handling.

A code that identifies and defines a unit of information. It is an alphanumeric code up to 8 characters long that does not allow blanks or 
special characters such as %, &, or +. You create new data items using system codes 55-59. You cannot change the alias.

An alphanumeric code that identifies a separate entity within a business for which you want to track costs. For example, a business unit 
might be a warehouse location, job, project, work center, branch, or plant. You can assign a business unit to a document, entity, or person for 
purposes of responsibility reporting. For example, the system provides reports of open accounts payable and accounts receivable by 
business unit to track equipment by responsible department. Business unit security might prevent you from viewing information about business units 
for which you have no authority.

The unique identification for a test to be performed on an item. For example:    COL Color test    DENS Density Test    CL-2   Clarity Test 

The Instructed Start Date and Time of an operation.

Brief information about an item; a remark or an explanation.

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

One of five reporting codes that can be assigned to each test defined.  Use these codes to categorize tests into different groups.  Category 
codes are user defined (System 37, types T1 through T5). Examples:        Category code T1 - Test Equipment         Category code T2 - Test 
Process

A value that specifies how the system processes tests as you enter test results. Valid values are:    R  Required. Result values must be 
within the allowable range for the test to pass. The system does not allow an item to pass quality inspection until you enter results for each 
required test.    O  Optional. Result values are optional during results entry. The system does not require the entry of a result for each optional test. 
However, if you enter failing results, the item fails quality inspection.    G  Guaranteed. Result values are optional during results entry. You can 
control whether Guaranteed tests appear as you enter test results with the Display Test field on Test Revisions. In addition, guaranteed tests 
print on the Certificate of Analysis.

A date that indicates one of the following:     o When a component part goes into effect on a bill of material     o When a routing step goes into 
effect as a sequence on the routing for an item     o When a rate schedule is in effect The default is the current system date. You can enter 
future effective dates so that the system plans for upcoming changes. Items that are no longer effective in the future can still be recorded and 
recognized in Product Costing, Shop Floor Management, and Capacity Requirements Planning. The Material Requirements Planning system 
determines valid components by effectivity dates, not by the bill of material revision level. Some forms display data based on the effectivity 
dates you enter.

A date that indicates one of the following:     o When a component part is no longer in effect on a bill of material     o When a routing step is no 
longer in effect as a sequence on the routing for an item     o When a rate schedule is no longer active The default is December 31 of the 
default year defined in the Data Dictionary for Century Change Year. You can enter future effective dates so that the system plans for upcoming 
changes. Items that are no longer effective in the future can still be recorded and recognized in Product Costing, Shop Floor Management, 
and Capacity Requirements Planning. The Material Requirements Planning system determines valid components by effectivity dates, not by 
the bill of material revision level. Some forms display data based on the effectivity dates you enter.

A code that indicates special processing requirements for certain user defined code values. The value that you enter in this field is unique 
for each user defined code type. The system uses the special handling code in many ways. For example, special handling codes defined for 
Language Preference specify whether the language is double-byte or does not have uppercase characters. Programming is required to 
activate this field.

The job number (work station ID) which executed the particular job.

Unique name used to group test results.

A code (31B/QB) used in the Blend Management system to indicate the blending rule for results.  

Determines whether a test result value will be numeric or alphanumeric. Valid values are:    1   Indicates that the result value is numeric and 
should be right justified.    0   Indicates that the result value is alphanumeric and should be left justified. Tests that are using alphanumeric result 
values can have User Defined Code tables setup that contain alpha to numeric translations. The purpose of these tables is to supply result 
evaluations with a way of determining whether a result is within the range of the minimum and maximum values.