Using ELF - Datatel (Clients)

Transcription

Datatel Colleague® Core
Using ELF
Release 18
August 19, 2008
For last-minute updates and additional information about this manual, see AnswerNet page 2530.59
Using ELF
© 2008 Datatel, Inc.
All Rights Reserved
The information in this document is confidential and proprietary to and considered a
trade secret of Datatel, Inc., and shall not be reproduced in whole or in part without
the written authorization of Datatel, Inc. The information in this document is subject
to change without notice.
Colleague and ActiveCampus are registered trademarks of Datatel, Inc. ActiveAlumni
and ActiveAdmissions are trademarks of Datatel, Inc. Other brand and product
names are trademarks or registered trademarks of their respective holders.
Datatel, Inc.
4375 Fair Lakes Court
Fairfax, VA 22033
(703) 968-9000
(800) DATATEL
www.datatel.com
Publication History
The contents list on the next page identifies the publication date of each section
of your copy of this manual. See “How to Verify That Your Manual Is Current”
below for instructions on how to make sure that you have the current version
of the manual.
How to Verify That Your Manual Is Current
Take the following steps to ensure that all sections of your manual are current:

To make sure you have the current version of this manual for your release
level, compare the date shown on the title page to the publication date for the
Adobe Acrobat version of this manual on the Datatel Web site
(www.datatel.com/documentation).
To make sure that your copy of the manual has been updated with all
previous revisions, check that the date at the bottom of each page matches
the corresponding date for that section in the contents list on the next page.
If you determine that one or more sections is outdated, we recommend that you
download the entire manual from the Datatel Web site
(www.datatel.com/documentation).
Tracking the History of Revisions
The contents list shows only the date of the latest revision of each section; it
does not show a history of previous revisions or the reasons for revisions. After
you receive your initial copy of a manual, subsequent updates to it will include
update memos describing the reasons for the updates. If you want to track the
Using ELF, August 19, 2008
i
Publication History
history of revisions and the reasons for revisions, keep the update memos with
your copy of this manual. If you order additional copies of manuals from
Datatel, the update memos will not be included.
1. Introduction
1-1
1-5
About This Manual ................................................................. August 19, 2008
About the ELF Module ........................................................... August 19, 2008
2. Getting Started
2-1
2-15
2-31
2-39
2-45
2-53
Electronic File Transfers ........................................................ August 19, 2008
Mapping Your Data ................................................................ August 19, 2008
Defining Duplicate Criteria ..................................................... August 19, 2008
Defining Merge Criteria .......................................................... August 19, 2008
Defining Translation Tables ................................................... August 19, 2008
Identifying Codes Related to the ELF Process ...................... August 19, 2008
3. Source to Intermediate Imports
3-1
3-15
3-31
Defining Source Files ............................................................. August 19, 2008
Identifying the Target Files .................................................... August 19, 2008
Importing Source Data ........................................................... August 19, 2008
4. Intermediate Files to Colleague
4-1
4-11
Importing Information into Colleague ..................................... August 19, 2008
Resolving Import Errors ......................................................... August 19, 2008
5. Purging
5-1
Purging Intermediate Files ..................................................... August 19, 2008
6. ELF Export
6-1
ii
Exporting Data Using ELF ..................................................... August 19, 2008
Table of Contents
List of Figures
...............................................................................................................vii
List of Tables ................................................................................................................... ix
1. Introduction
About This Manual
Who Should Read This Manual ..................................................................1-1
What This Manual Covers ...........................................................................1-1
How This Manual Is Organized ...................................................................1-2
Where to Find More Information .................................................................1-3
About the ELF Module
In This Chapter ............................................................................................1-5
Features of the ELF Module ........................................................................1-6
2. Getting Started
Electronic File Transfers
In This Chapter ............................................................................................2-1
Before You Begin ........................................................................................2-1
Understanding Electronic File Transfers (ELFs) .........................................2-2
Source Files ..........................................................................................2-3
Intermediate Data Files .........................................................................2-3
Source-to-Intermediate Procedure .......................................................2-4
Intermediate-to-Colleague Process ......................................................2-4
ELF Process Flow .................................................................................2-5
ELF Import Process: High-level Procedure ...............................................2-12
Defining Your Parameters ..................................................................2-12
Mapping Your Data
In This Chapter ..........................................................................................2-15
Before You Begin ......................................................................................2-16
Understanding the Mapping Process ........................................................2-17
Finding Field Information in an Intermediate File ................................2-18
Viewing Intermediate File Information .......................................................2-20
Noteworthy Fields on the RFEI Form .................................................2-21
Finding Field Information Using a Query Sentence ......................2-22
Mapping Spreadsheets .............................................................................2-25
Logical Prefixes ..................................................................................2-26
Defining Duplicate Criteria
In This Chapter ..........................................................................................2-31
iii
Table of Contents
Understanding Duplicate Checking .......................................................... 2-31
Setting Up Duplicate Match Criteria .......................................................... 2-34
Noteworthy Fields on the DUPC Form ............................................... 2-35
Procedure for Defining duplicate Criteria .................................................. 2-38
Defining Merge Criteria
In This Chapter ......................................................................................... 2-39
Understanding Merge Criteria ................................................................... 2-39
Noteworthy Fields on the MRGC Form .............................................. 2-40
Procedure for Defining Merge Criteria ...................................................... 2-44
Defining Translation Tables
In This Chapter ......................................................................................... 2-45
Understanding File Translation Tables ..................................................... 2-45
Special Processing Fields .................................................................. 2-48
Procedure for Defining File Translation Tables ........................................ 2-49
Determining Whether Translation Tables Are Completed ........................ 2-50
Worksheet for File Translation Tables ...................................................... 2-51
Identifying Codes Related to the ELF Process
In This Chapter ......................................................................................... 2-53
Before You Begin ...................................................................................... 2-53
Understanding ELF Codes ....................................................................... 2-54
Duplicate Categories .......................................................................... 2-54
ELF File Types ................................................................................... 2-54
ELF Merge Actions ............................................................................. 2-55
ELF Run Modes ................................................................................. 2-55
ELF Target Statuses .......................................................................... 2-55
ELF Transaction Status ...................................................................... 2-57
ELF Transfer Statuses ....................................................................... 2-58
ELF Translate Actions ........................................................................ 2-58
ELF Update Actions ........................................................................... 2-59
ELF Value Error Actions ..................................................................... 2-59
Verifying Validation Code Tables and Code Files .................................... 2-60
Checking Your Mapping Spreadsheets .............................................. 2-60
Using a Query Sentence to Verify Validation Code Tables ................ 2-60
Using a Query Sentence to Verify Validation Code Files ................... 2-62
Validation Code Worksheet ...................................................................... 2-64
Defining Source Files
In This Chapter ........................................................................................... 3-1
iv
Table of Contents
Understanding Source File Definition ..........................................................3-2
Noteworthy Fields on the ELFT Form ...................................................3-3
File Location or Directory ...............................................................3-4
Tape Characteristics ......................................................................3-4
Variable Length File Characteristics ...............................................3-5
Fixed Length File Characteristics ...................................................3-5
Records and Blocks to Skip ...........................................................3-6
Custom ...........................................................................................3-6
Procedure for Defining Source Files ...........................................................3-7
Defining Fields of a Variable Length File ....................................................3-8
Noteworthy Fields on the ELFV Form ...................................................3-9
Defining Fields for a Fixed Length File ......................................................3-11
Noteworthy Fields on the ELFF Form .................................................3-12
Identifying the Target Files
In This Chapter ..........................................................................................3-15
Before You Begin ......................................................................................3-16
Understanding the Intermediate Files .......................................................3-17
Identifying the Target Files ........................................................................3-18
Naming the ELF Imports .....................................................................3-19
Components of Mapping Source Files to Target Files ........................3-20
Identifying the Target Fields ......................................................................3-21
About Source Fields ...........................................................................3-22
About Target Fields ............................................................................3-22
Procedure for Creating an ELF Source-to-Intermediate Import ................3-23
Previewing the ELF Specifications ............................................................3-24
Specifying Data Transformations ..............................................................3-26
Populating Intermediate Files ....................................................................3-28
Cataloging Your ELF Import ......................................................................3-29
Importing Source Data
In This Chapter ..........................................................................................3-31
Before You Begin ......................................................................................3-31
Understanding the Source-to-Intermediate Files Transfer ........................3-32
Components of a Source-to-Intermediate Import ......................................3-33
Noteworthy Fields on the STII Form ...................................................3-34
Choosing the Source-to-Intermediate Procedure ......................................3-35
Procedure for Importing Source Data to Intermediate Files ......................3-36
Importing Information into Colleague
In This Chapter ............................................................................................4-1
Before You Begin ........................................................................................4-1
Understanding the Intermediate-to-Colleague Files Transfer .....................4-2
Duplicate Checking ...............................................................................4-4
Merging Records into Colleague ..........................................................4-4
Procedure for Importing Information ...........................................................4-5
v
Table of Contents
Reading the Import Report ......................................................................... 4-7
Components of the Import Report ........................................................ 4-7
Resolving Import Errors
In This Chapter ......................................................................................... 4-11
Before You Begin ...................................................................................... 4-11
Forms Used .............................................................................................. 4-12
Understanding Duplicates and Ambiguities .............................................. 4-13
Overview of Duplicate/Ambiguity Resolution ..................................... 4-15
Viewing the List of Potential Duplicates .................................................... 4-17
About Duplicate File Resolution ................................................................ 4-18
Resolving Person Duplicates ............................................................. 4-19
Resolving Relation Person Duplicates ............................................... 4-20
Resolving Relation Address Duplicates ............................................. 4-21
Resolving Address Duplicates ........................................................... 4-22
Resolving Other Address Duplicates ................................................. 4-23
Resolving Application Duplicates ....................................................... 4-24
Noteworthy Fields on the Duplicate Resolution Forms ...................... 4-25
Resolving Other Duplicate Ambiguities .............................................. 4-27
Noteworthy Fields on the TGTR Form ............................................... 4-28
Procedure for Resolving Other Duplicate Ambiguities ....................... 4-32
Resolving Discrepancies .......................................................................... 4-33
Noteworthy Fields on the ETRK Form ............................................... 4-34
5. Purging
Purging Intermediate Files
Understanding Intermediate File Purges .................................................... 5-1
Procedure for Purging Intermediate Files ................................................... 5-2
6. ELF Export
Exporting Data Using ELF
Understanding the Export Process ............................................................. 6-1
Before You Begin ........................................................................................ 6-2
Chapters to Use ................................................................................... 6-2
How to Use the Correct Chapters ........................................................ 6-2
ELF Export Form ........................................................................................ 6-3
Procedure for Exporting Data Using ELF ................................................... 6-5
Index
vi
List of Figures
1. Introduction
About This Manual
2. Getting Started
Figure 2-1: Copying Data From an External Source to Colleague ............. 2-2
Figure 2-2: Process Flow of ELF................................................................ 2-6
Figure 2-3: Detailed ELF Process Flow ..................................................... 2-7
Mapping Your Data
Figure 2-4: Example of Finding Intermediate File Information ................. 2-19
Figure 2-5: Example of the File Element Inquiry (RFEI) Form ................. 2-20
Figure 2-6: Comparison of Different Intermediate Files on the RFEI Form......
2-21
Figure 2-7: Example of Query on RT.FILES File ..................................... 2-23
Figure 2-8: Example of Query on RT.FIELDS File ................................... 2-24
Figure 2-9: Duplicate Match Criteria (DUPC) Form ................................. 2-34
Figure 2-10: Example of the ELF Merge Criteria (MRGC) Form.............. 2-40
Figure 2-11: Example of Defining a Translation Table ............................. 2-46
Figure 2-12: Example of Query on the INTER.BIODEMO File ................ 2-61
Figure 2-13: Example of Query on the INTER.BIODEMO File ................ 2-62
Figure 3-1: Electronic Transfer File (ELFT) Form ...................................... 3-2
Figure 3-2: Custom ELF File Access (CELF) Form ................................... 3-6
Figure 3-3: Variable File Fields (ELFV) Form ............................................ 3-8
Figure 3-4: Example of the Fixed File Fields (ELFF) Form ...................... 3-11
Figure 3-5: Example of Trimming Spaces Using the RDEE Form ........... 3-14
Figure 3-6: Copying Data From an External Source to Colleague ........... 3-17
vii
List of Figures
Figure 3-7: Example of the Source to Target Map (ELFS) Form.............
Figure 3-8: Example of the ELF Field Mapping (ELFM) Form.................
Figure 3-9: Example of Source Field to Target Field ...............................
Figure 3-10: Example of the ELF Specification Preview (EPVW) Form ..
Figure 3-11: Example of the ELF Specification Preview (EPVW) Report
Figure 3-12: Example of the Data Element Edits (RDEE) Form..............
3-18
3-21
3-22
3-24
3-25
3-26
Figure 3-13: Example of the Source-to-Intermediate Import (STII) Form 3-33
Figure 4-1: The Inter-to-Colleague Import (ITCI) Form.............................. 4-3
Figure 4-2: Example of the Intermediate-To-Colleague Import (ITCI) Report .
4-9
Figure 4-3: ELF Duplicate Resolution (EFDR) Form ...............................
Figure 4-4: The Resolve Person Duplicates (ERPD) Form .....................
Figure 4-5: The Resolve Relation Person Dupls (ERRP) Form...............
Figure 4-6: The Resolve Relation Addr Duplicates (ERRA) Form...........
Figure 4-7: The Resolve Address Duplicates (ERAD) Form ...................
Figure 4-8: The Resolve Other Address Duplicates (EROA) Form .........
Figure 4-9: The Resolve Appl Duplicates (RAPD) Form .........................
Figure 4-10: The ELF Target Results/Dupl Res (TGTR) Form................
Figure 4-11: The ELF Transaction Tracking (ETRK) Form......................
4-17
4-19
4-20
4-21
4-22
4-23
4-24
4-27
4-33
5. Purging
Figure 5-1: Example of the ELF Batch Purge (EPRG) Form ..................... 5-1
6. ELF Export
Figure 6-1: Example of Files Involved in ELF Import Process...................
Figure 6-2: Example of Files Involved in ELF Export Process...................
Figure 6-3: Example of the ELF Export (ELFE) Form................................
Figure 6-4: Example of the Source to Target Map (ELFS) Form...............
viii
6-1
6-1
6-3
6-4
List of Tables
1. Introduction
About This Manual
Table 1-1: Sources of Information for Using the ELF Module ......................1-3
Table 1-2: Additional Sources of Information about ELF .............................1-3
2. Getting Started
Table 2-1: Further Reference on the Import Procedure...............................2-4
Table 2-2: Variables Used During the ELF Process ....................................2-8
Mapping Your Data
Table 2-3: Topics in this Chapter ...............................................................2-15
Table 2-4: Data Elements Description on the File Element Inquiry (RFEI) Form
2-21
Table 2-5: Mapping Spreadsheet Information............................................2-25
Table 2-6: Example of a Mapping Spreadsheet.........................................2-27
Table 2-7: Topics in this Chapter ...............................................................2-31
Table 2-8: Example of Duplication Rating Determination ..........................2-32
Table 2-9: Second Example of Duplication Rating Determination .............2-32
Table 2-10: Topics in this Chapter .............................................................2-39
Table 2-11: Merge Actions for Single-Valued Fields ..................................2-41
Table 2-12: Merge Actions for an Association ...........................................2-41
Table 2-13: Merge Actions on the PERSON and ADDRESS Files............2-42
Table 2-15: Example of a Translation Table Worksheet ............................2-47
Table 2-16: Example of “Splitting” a Source Code.....................................2-47
Table 2-17: Worksheet for File Translation Tables.....................................2-51
Table 2-19: ELF File Type Codes ..............................................................2-54
Table 2-20: ELF Target Status Codes........................................................2-56
Table 2-21: ELF Transaction Status Codes ...............................................2-57
Table 2-22: ELF Transfer Status Codes ....................................................2-58
Table 2-23: ELF Translate Action Codes...................................................2-58
Table 2-24: ELF Update Action Codes ......................................................2-59
ix
List of Tables
Table 2-25: ELF Value Error Action Codes ............................................... 2-59
Table 2-26: Institution Core Setup (ICS) Forms ........................................ 2-63
Table 2-27: Validation Code Worksheet .................................................... 2-64
Table 3-1: Topics in this Chapter................................................................. 3-1
Table 3-2: Additional Information Needed Per File Type............................. 3-3
Table 3-3: Topics in this Chapter............................................................... 3-15
Table 3-4: Components of Mapping Source Files to Target Files ............. 3-20
Table 3-5: Recommended Intermediate Files to Populate For Each Import ....
3-28
Table 3-7: Setup Needed Before Importing Data to Intermediate Files .... 3-31
Table 4-1: Topics in this Chapter................................................................. 4-1
Table 4-2: Information Needed Before You Can Import Data...................... 4-1
Table 4-4: Actions Necessary Before You Can Correct Duplicate Errors.. 4-11
Table 4-5: Forms Used to Resolve Import Errors...................................... 4-12
5. Purging
6. ELF Export
Table 6-1: Substituting Terminology Between Import and Export Processes...
6-2
x
Using ELF
1. Introduction
Introduction
1
About This Manual
2
081
,A
9
g
u
ts
Who Should Read This Manual
Anyone who is responsible for the following tasks should read this manual:
Converting legacy systems to Colleague.
Importing data from other systems to Colleague.
Exporting data from Colleague to other systems, such as state agencies.
What This Manual Covers
This manual provides instructions for using the ELF module. It describes how
to prepare your data, and how to map the data and purge intermediate files
once those files are imported. Some of the instructions include how to do the
following:
Prepare your data by mapping it.
Define parameters used in the ELF process.
Identify and specify source and target files.
Import source data to intermediate files.
Compare intermediate files with Colleague files.
Resolve duplicate information.
Import intermediate files into Colleague.
Purge intermediate files.
There is also a section that describes the export process using the ELF
module.
1-1
Introduction: About This Manual
How This Manual Is Organized
Part 1, “Introduction,” which you are reading now, provides information
about this manual and its organization, and an introduction to the ELF module
and where it fits in Colleague.
Part 2, “Getting Started,” provides information on setting up the ELF module
and defining parameters. Also included are procedures for the following:
Mapping your data.
Defining duplication and merge criteria.
Defining translation tables.
This part also includes an overview chapter, which provides basic information
on ELF concepts.
Part 3, “Source to Intermediate Imports,” provides information on defining
source and target files used when importing data from a primary source to an
intermediate file. Included are procedures for importing the source data into
the intermediate file.
Part 4, “Intermediate Files to Colleague,” provides information on importing
the data from the intermediate file into Colleague. Included are procedures for
the following:
Comparing data in the intermediate file with the Colleague data
Resolving records that have the same matched information (duplicates)
Importing the data from the intermediate file into Colleague
Part 5, “Purging,” provides information and procedures about purging the data
in the intermediate files.
Part 6, “ELF Export,” provides an explanation of how to use the information
and procedures in this manual to export Colleague data to an external source.
1-2
Where to Find More Information
Where to Find More Information
This manual provides task-oriented procedures for using the ELF module as
part of your daily office activities. Table 1-1 lists sources of information that
provide additional assistance in day-to-day use of the ELF module.
Type of Information
Resource
Description of each form and field in the ELF module.
Online help
Instructions for performing basic functions (such as
accessing forms, entering data, and accessing online
help) using each of the available Colleague interfaces.
Guide to User Interfaces
In-person instruction in using the ELF module.
Training classes offered by Datatel
Information about using ELF to import admissions data
into Colleague.
Using the Admissions Application
Interface
Information about using ELF to import Active
Admissions data.
Implementing Active Campus
Integration
Table 1-1: Sources of Information for Using the ELF Module
If you need information about implementing, installing, and setting up the
ELF module, refer to the resources listed in Table 1-2.
Type of Information
Resource
Planning your implementation of the ELF module.
Getting Started with Colleague Core
Installing the Colleague software.
Installation Procedures for your
Colleague release level
Each Colleague subroutine, file, field, form, procedure,
validation code, list specification, and batch process.
Technical documentation available in
the “For Our Clients” section of the
Datatel website
Changes and enhancements to the system since the
previous release.
Release Highlights for your Colleague
release level
Known issues.
AnswerNet
Table 1-2: Additional Sources of Information about ELF
1-3
Introduction: About This Manual
1-4
Introduction
1
2
081
,A
9
g
u
ts
In This Chapter
The Electronic File Transfer (ELF) module is a part of Colleague Core. The
ELF module enables you to import and export data between Colleague and
internal or external systems. This chapter provides the following:
a brief description of Colleague, focusing on the parts of Colleague that
interact with the ELF module
a summary of the features of the ELF module
a description of the interfaces between the ELF module and other
Colleague modules
information about accessing the ELF module
1-5
Introduction: About the ELF Module
Features of the ELF Module
The ELF module lets you import data to and export data from Colleague. You
can import data into Colleague from legacy systems during conversion, from
state systems, and from other internal or external systems with which you
want to create an interface. You can export data from Colleague to state
systems or other internal or external systems with which you have an
interface.
The ELF import process has two basic steps: import from a source area to an
intermediate area, and then import from the intermediate area to Colleague.
One way of describing this process is comparing the process to moving
basement items to the attic of a house. For an example, you could use the
following analogy:
Basement = Source
Main floor = Intermediate file
Attic = Colleague
First you assess the area in the basement and the main floor so you can put
similar items with similar items. (This is similar to the mapping processes.)
You can identify where in the attic you’ll store clothing, sports equipment,
books, photo albums, and so on. That way, you know where to put things
when you bring them from the basement.
Next you sort through the items in the basement and select only those items
you want to transport to the attic. (This is similar to mapping your data and
defining the criteria needed to select the files you want from the source file.)
After you have gathered the items you want to move from the basement, you
carry them to the main floor of the house. (This is similar to importing the
source data to intermediate file.)
After carrying what could be several tons of items from the basement to the
main floor, you realize that there may already be similar items in the attic. You
can compare the items on the main floor with the items in the attic, that way
you don’t have to carry so much into the attic if similar items (or duplicates)
are already in the attic. (This is similar to detecting duplicate records.)
After you have sorted through the items on the main floor, you can carry them
to the attic and place them in their proper place. (This is similar to importing
the data from the intermediate file to Colleague.) You could still find items
that are similar or the same, so you may have to resolve these duplicates and
decide which item is the best to keep.
1-6
Features of the ELF Module
The ELF export process uses the same logic as the ELF import process;
however, the ELF export process does not use intermediate files. Where as the
import process moves source-to-intermediate-to-Colleague data, the export
process moves Colleague-to-target data.
1-7
Introduction: About the ELF Module
1-8
Using ELF
2. Getting Started
Getting Started
2
2
081
,A
9
g
u
ts
In This Chapter
This chapter provides an overview of the Electronic File Transfer (ELF)
module and it it helps you transport data between systems. This chapter also
includes a high-level procedure to be used as a reference when using the ELF
module.
Before You Begin
Before you can begin to transfer data, ensure that you have the Envsion Tool
Kit. You must have the Tool Kit in order to create custom ELF specifications.
2-1
Getting Started: Electronic File Transfers
Understanding Electronic File
Transfers (ELFs)
Colleague Core provides processes that enable you to import information into
your database from external sources. This external data source is often a file
created by a computer system and is stored on disk or tape media. This
electronic file transfer is known as “ELF.”
You can use ELF to import data such as testing service scores, transcripts, and
admissions information.
Importing data from an external source to your Colleague database is a twopart process. Figure 2-1 illustrates the two parts of the process.
1. Copy the information from the source media to a set of intermediate data
files, using a Source-to-Intermediate (STII) procedure.
2. Copy the information from the intermediate data files into your Colleague
database, using the Intermediate-to-Colleague (ITCI) procedure.
Source
Intermediate Files
STII
Source-to-Intermediate
Procedure
Colleague
ITCI
Intermediate-to-Colleague
Procedure
Figure 2-1: Copying Data From an External Source to Colleague
The ELF module is designed to reduce the number of custom programs used
to import external data into Colleague files and to export data to other
computer systems. Some of the data imported using ELF are testing service
scores, transcripts, and admissions information. Exported data will include
data necessary to interface with legacy systems during the transition to
Colleague or when Colleague coexists with other administrative subsystems.
The following sections introduce the components of the ELF process.
Subsequent chapters discuss each component in more detail.
2-2
Understanding Electronic File Transfers (ELFs)
Source Files
ELF accepts almost any type of source media, including

Colleague-like files1
fixed-length disk
variable length disk
fixed length tape
completely custom
You must define your source files before ELF can process them correctly. See
“Defining Source Files” on page 3-1 for more information about defining
your source files.
Intermediate Data Files
Copying the source data into an intermediate data file instead of directly into
your Colleague database might seem like an unnecessary step, but the
intermediate files make the import process very versatile. The STII procedure
can be written and modified easily to fit a variety of source types and data.
You can also use the intermediate files as a holding place from which you can
run queries, reports, and mailing lists even if you decide not to import the data
into Colleague.
You must define translation tables for all of the codes used in the source data
files so ELF can import the source information correctly into your database.
See “Defining Translation Tables” on page 2-45 for more information about
defining your translation tables.
1. A Colleague-like file is any file that can be accessed using the same managed
input/output (MIO) routines used by Envision to access a normal Colleague data file.
This includes all intermediate files.
2-3
Source-to-Intermediate Procedure
After you have defined the source and intermediate files, you can import the
source information using a source to intermediate files procedure. The
procedure you need to use depends upon the type of external information you
are trying to import.
See “Importing Source Data” on page 3-31 for more information about
source-to-intermediate imports.
Intermediate-to-Colleague Process
If you decide you want to merge the information in the intermediate files with
your Colleague database files, you must use the Intermediate-to-Colleague
procedure. The intermediate-to-Colleague procedure checks for records that
may already exist in your database. If the records are new or contain updated
information, the intermediate-to-Colleague procedure either modifies existing
records in your Colleague database or creates new records.
Datatel supplies standard duplication and merge criteria that you will
probably find adequate for all of your importing needs. You may customize
this criteria, as appropriate for your institution.
You can choose to run the process in either update or non-update mode. By
choosing the non-update mode, you can cycle through the intermediate files,
correcting errors and verifying duplicated records. Then when all files are
correct, you can run the procedure in update mode, and ELF modifies or
creates new records in your Colleague database.
Refer to Table 2-1 to determine where to find more information on these
subjects.
Type of Information
Resource
Understanding or customizing your duplicate criteria
“Defining Duplicate Criteria” on page 2-31
Understanding or customizing your merge criteria
“Defining Merge Criteria” on page 2-39
The intermediate-to-Colleague procedure
“Importing Information into Colleague” on
page 4-1
The optional review and override of possible duplicate
records
“Resolving Import Errors” on page 4-11
Table 2-1: Further Reference on the Import Procedure
2-4
ELF Process Flow
Figure 2-2 on page 2-6 illustrates the ELF process flow. The ELF process
takes the source data and creates the target file records. Although the ELF
process is mostly automated, you may need to help it along and occasionally
modify the information.
The primary loop in the ELF process uses a single record from the source file.
One source record is considered to be one transaction. Remember, however,
that one source record may result in multiple target records. The set of records
resulting from a single source record is called a transaction set.
Figure 2-2 provides another example of the ELF process flow. You can use
either Figure 2-2 or Figure 2-3 as a reference for understanding the ELF
process.
Table 2-2 on page 2-8 provides yet another example of the ELF process flow
and includes the variables used during the process.
2-5
Start
Perform Additional
Target Record
Manipulation (TGTF)
Pre Write Hook
Initialize Process
(ELFS)
Process Entry Hook
A
Read a record from
the source file
Write Target to Buffer
Perform Record
Based Edits (ELFS)
Source Pre-Edit Hook
Yes
More Target
Files?
B
No
Process Source Field
(RDEE)
Read Edit Hook
Manipulate
Transaction Set
(ELFS)
Pre Commit Hook
Yes
More Source
Fields?
B
Write Transaction Set
Identify and Process
Target File
More Source
Records?
Yes
A
No
Process target fields
(ELMD)
Map Pre Edit Hook
Map Post Edit Hook
Ending Process
(ELFS) Process Exit
Yes
More Target
Fields?
No
End
Figure 2-2: Process Flow of ELF
2-6
Start Process
Perform program initialization.
Uses hook defined in the Process Entry field on the Source To Target Map (ELFS) form.
Initialize custom variables used elsewhere in the process to avoid “uninitialized variable” error
messages. This is done once, before the main processing loop.
For Each Source Record
Read the source record. Uses hook defined in the Source Pre Edit field on the ELFS form.
Perform global record-based edits. This is done after a record has been read, but before
any field edits are performed.
For Each Source Field
Perform spec-based edits.
Perform spec-based translations.
Uses hook defined in the Read Edit Hook field on the Data Element Edits
(RDEE) form. This is done after the data has been read from the source record
and all of the standard read edits have been applied.
End Each Source Field
For Each Target File
For Each Controller/Logical Prefix
For Each Target Field
Set target field to mapped source field.
Uses the hook defined in the Pre Edit Hook field on the ELF Field
Mapping Detail (ELMD) form.
Perform defaulting and data derivation.
Perform map spec-based edits.
Perform map spec-based translations.
Uses the hook defined in the Post Edit Hook field on the ELMD form.
Perform additional data manipulation after the mapping and spec-based
edits are done.
End Each Target Field
Uses the hook defined in the Pre Write Hook field on the ELF Target
File (TGTF) form. Manipulate multivalued fields before the record is
written to the buffer. Write target record to buffers.
End Controller/Logical Prefix
End Target File
Uses the hook defined in the Pre Commit field on the ELFS form.
Assuming there is one record per target file, you can manipulate an entire transaction
set here. This is done after the target records have been built and written to the buffer
but before they have been physically written to disk.
End Source Record
Uses hook defined in the Process Exit field on the ELFS form.
Write summary information and close any files you may have manually opened.
End Process
Figure 2-3: Detailed ELF Process Flow
2-7
2-8
Data Element Edits (RDEE)
form
Read Edit Hook field on RDEE
form
Process source field
Perform source field specbased edits
Perform additional source
field edits
For each value of the source field
Table 2-2: Variables Used During the ELF Process
End each source field
End each value of the source field
(Not Applicable)
Perform record-based edits
For each source field
Source Pre Edit field on the
ELFS form
(Not Applicable)
Read a record from the
source file
For each source record
Process Entry field on the
Source to Map (ELFS) form
Specified on
Initialize process
Process
Once
Occurance
READ.DATA
VL.source_field (all processed so far)
V.source_field (all processed so far)
R.source_file
READ.DATA
VL.source_field (all processed so far)
V.source_field (all processed so far)
R.source_file
(Not Applicable)
MSG
WARNING.OCCURRED
ERROR.OCCURRED
R.source_file
(Not Applicable)
ABORT.MSG
Active Variables
Table 2-2: Variables Used During the ELF Process (cont’d)
Process target field
For each field mapping
Prefixes field on the TGTF form
Determine whether sets of
individual fields in the source
file can result in multiple
records in the intermediate
file
(Not Applicable)
(Not Applicable)
Control Fields field on the ELF
Target File (TGTF) form
Determine whether a field or
fields in the source file
controls the creation of
records in the intermediate
file
Initialize the target record to
null
Target Files fields on the ELFS
form
Specified on
Process target record
Process
For each control field (if there are no
control fields)
For each target file
Occurance
(Not Applicable)
(Not Applicable)
(Not Applicable)
(Not Applicable)
(Not Applicable)
Active Variables
2-9
2-10
Default Value field or Default
Hook field on the Database
Element Presentation (RDEP)
form
If source field is null, apply
target field default
Perform target field, specbased edits
Perform additional edits if
necessary
Trans Table/Action field on the
ELMD form
Perform override translation
if necessary
Post Edit Hook field on the
ELMD form
Value Error Action field on the
ELMD form
Pre Edit Hook field on the ELF
Field Mapping Detail (ELMD)
form
Specified on
Manipulate edited source
data if necessary
Process
End each value of the source field
For each value of the source field
Occurance
same as above
same as above
same as above
same as above
MSG
WARNING.OCCURRED
ERROR.OCCURRED
SOURCE.DATA
EDITED.DATA
VL.target_field (all processed so far)
V.target_field (all processed so far)
VL.source_field (all)
V.source_field (all)
R.source_file
Active Variables
Process Exit field on the ELFS
form
(Not Applicable)
Write the transaction set
Create or update additional
records in other files
Pre Commit field on the ELFS
form
(Not Applicable)
Write target record to buffer
Manipulate the transaction
set
Pre Write Hook field on the
TGTF form
List Exit Hook field on the
ELMD form
Specified on
Perform additional target
record manipulation
If the target field is
multivalued, then manipulate
the values in this and any
associated fields
Process
End each source record
End each target file
End each control field
End each field mapping
Occurance
ABORT.MSG
(Not Applicable)
MSG
WARNING.OCCURRED
ERROR.OCCURRED
R.target_file (one for each target file)
(Not Applicable)
VL.target_field (all processed so far)
V.target_field (all processed so far)
VL.source_field (all)
V.source_field (all)
(Not Applicable)
Active Variables
2-11
ELF Import Process: High-level
Procedure
This section describes a high-level procedure for defining the parameters for
the ELF process, importing from source to intermediate, and importing from
intermediate to Colleague. These procedures are intended as a quick reference
after you have familiarized yourself with the workflow, forms, and processes.
Please do not use these procedures without reading the remaining
documentation in this manual.
Defining Your Parameters
Step 1. Map your data.
You should consult your Datatel account manager and Conversion Team for
detailed assistance in mapping your data. For more information, see
“Mapping Your Data” on page 2-15.
Step 2. Define your duplication criteria by using the Duplicate Match Criteria
(DUPC) form.
This is an important procedure if you want ELF to detect records that are
duplicates (or possible duplicates). For more information, see “Defining
Duplicate Criteria” on page 2-31.
Step 3. Define the merge criteria by using the ELF Merge Criteria (MRGC) form.
The criteria that you define will direct the ELF process in merging the
imported information with existing Colleague files. For more information, see
“Defining Merge Criteria” on page 2-39.
Step 4. Define the translation tables needed to perform the ELF process using the File
Translation Tables (FLTT) form. For more information, see “Defining
Translation Tables” on page 2-45.
2-12
ELF Import Process: High-level Procedure
Step 5. Define the codes for the validation code tables and validation code files need
by the intermediate files.
You will use either the Validation Codes (VAL) form, or a form designed for
specific validation code tables and validation code files. For example, for
prefix and suffix validation code tables, use the Prefix and Suffix Definition
(PPS) form. For more information, see “Identifying Codes Related to the ELF
Process” on page 2-53.
Constructing Your Import Process
Step 1. Define your source files by using the Electronic File Transfer (ELFT) form.
You can detail to one of the following forms from the ELFT form to define
fields for variable-length files or fixed-length files:
Variable File Fields (ELFV) form
Fixed File Fields (ELFF) form
For more information, see “Defining Source Files” on page 3-1.
Step 2. Construct your source-to-intermediate import using the Source to Target Map
(ELFS) form.
You must also catalog your file specification to create a VOC pointer. For
more information, see “Identifying the Target Files” on page 3-15.
Importing Source-to-Intermediate Data
Step 1. Import the source data to the intermediate file.
On the Source-To-Intermediate (STII) form, use the file specification you
gave the import when you created the procedure (such as RGM001). For more
information, see “Defining Source Files” on page 3-1.
Importing Intermediate-to-Colleague Data
Step 1. Simulate importing the data from the intermediate files into Colleague.
2-13
Use the Inter-To-Colleague Import (ITCI) process in non-update mode. For
more information, see “Importing Information into Colleague” on page 4-1.
Step 2. Compare the data in the intermediate files with your Colleague files.
For more information, see “Resolving Import Errors” on page 4-9.
Step 3. Import the data from the intermediate files into Colleague.
Use the ITCI process in update mode to import the files and merge the
duplicates into the Colleague database. For more information, see “Importing
Information into Colleague” on page 4-1.
Step 4. Resolve any duplicate records you may find. For more information, see
“Resolving Import Errors” on page 4-9.
Step 1. When you have finished importing the data from the intermediate files into
Colleague, you can purge the intermediate files. For more information, see
“Purging Intermediate Files” on page 5-1.
2-14
Getting Started
2
Mapping Your Data
2
081
,A
9
g
u
ts
In This Chapter
This chapter will assist you in mapping your data in the source files to the
target files in Colleague.
When mapping data for conversion from a “legacy” system to Colleague, you
should consult your Datatel account manager and the Datatel conversion
group to assist you with this process. These consultation meetings should
include an in-depth review of how data fields were used at your institution in
the past and how they will be used in Colleague.
Use the information in this chapter to familiarize yourself with the mapping
process.
Table 2-3 lists the topics covered in this chapter.
Topic
Page
Before You Begin
2-16
Understanding the Mapping Process
2-17
Viewing Intermediate File Information
2-20
Mapping Spreadsheets
2-25
2-28
Table 2-3: Topics in this Chapter
2-15
Getting Started: Mapping Your Data
Before You Begin
Before you start mapping your data, meet with people at your institution who
know how the data is used. You should also arrange for training and
consulting with Datatel. By meeting with you, we can answer any questions
you have about how the data is used by Colleague and you can prepare for the
mapping and importing of the data.
The following is a high-level checklist of things you should consider before,
during, and after the mapping process:
Meet with your institution’s staff who know how the data is used. Involve
Datatel consultants if possible.
Schedule Datatel training and consulting before mapping your data.
Review the mapping spreadsheet templates.
Review the data to be converted.
Review the format of the data.
Review the coded fields.
Look for text name fields.
Consider manually entering some data.
Delete or remove unnecessary data.
Develop a test plan.
2-16
To map your data, you must determine where the data from the source file
maps to the intermediate file. For each piece of data from the source file that
you want to import, determine the intermediate files and fields for mapping.
For the most part, data from the source files will be mapped one-to-one to the
intermediate files. However, there are instances when one piece of data could
map to multiple files and fields. For example, you can import applicant and
application information from your source data into the intermediate files.
Specific applicant information will be mapped to the intermediate applicant
file, and specific application information will be mapped to the intermediate
application file. However, the person ID will be mapped to both intermediate
files.
2-17
Finding Field Information in an Intermediate File
You can view information about fields in specific intermediate files by using
the File Element Inquiry (RFEI) form.
Technical Tip: All intermediate files begin with INTER. For example,
the intermediate file corresponding to the Colleague AR.INVOICES
file is called INTER.AR.INVOICE. To view a list of intermediate files,
enter INTER… at the File LookUp prompt on the RFEI form.
From the RFEI form, you can detail to the Database Element Presentation
(RDEP) form to view and define the characteristics of a data element or field.
Data elements or fields are used for rules processing, forms processing,
communications management, and electronic file transfers.
From the RDEP form, you can detail to the Data Element Edits (RDEE) form
where you can view the read and write edit fields for the field of the selected
intermediate file. Figure 2-4 on page 2-19 shows an example of the RFEI,
RDEP, and RDEE forms. You should not modify any of this information for
intermediate files and fields. Modifying this information may cause errors
during the import process.
2-18
Details to the
RDEP form
Details to the
RDEE form
Figure 2-4: Example of Finding Intermediate File Information
2-19
The RFEI form displays the key, data elements or fields, and any virtual fields
of a file (in this case, an intermediate file).
Within the Data Elements list for intermediate files, the first seven data
elements always contain the same information, regardless of the selected file.
Figure 2-5 shows an example of the RFEI form.
Figure 2-5: Example of the File Element Inquiry (RFEI) Form
2-20
Noteworthy Fields on the RFEI Form
The following fields are particularly important when viewing file information.
Data Elements
Figure 2-6 shows a comparison of two different intermediate files displayed
on the RFEI form. Notice the similarities in the names of the first seven data
elements in the Data Elements list. These first seven data elements of all
intermediate files always contain the same information.
Figure 2-6: Comparison of Different Intermediate Files on the RFEI Form
Table 2-4 gives a description of the first seven data elements. The data in the
fields following field “8” make the intermediate files unique.
Field Extension
Description
BATCH
User selected batch ID. This batch ID lets the intermediate file records
know which ones were processed in the batch run. This field is
maintained by the system; you cannot modify the batch ID.
TRANSXN
This is a transaction identifier for the intermediate file. This field
identifies the source record from which the intermediate record was
derived. It groups all the records from that same source record.
ADDOPR
This is the login ID of the person who added this record. This field is
maintained by the system.
ADDDATE
This is the date when this record was added. This field is maintained
by the system.
2-21
Field Extension
Description
CHGOPR
This is the ID of the person who last updated this record. This field is
CHGDATE
This is the date when this record was last updated. This field is
RESULTS
This is the list of keys to the ELF.TGT.RESULTS file that has the
target files updated by the intermediate file, as well as the results of
target update and duplicate checking results. This field is maintained
by the system.
You can detail from any field on the RFEI form to access either the Database
Element Linkages (RDEL) or the Database Element Presentation (RDEP)
forms. Use the RDEL form to define or change the field’s relationship to a
file. This can also change the database usage type of a field. Use the RDEP
form to define the characteristics of a data element.
Finding Field Information Using a Query Sentence
You can also find information about an intermediate file by querying the
runtime central data dictionary (CDD). When you use File LookUp on the
RFEI form, the LookUp process queries against the RT.FILES file where
intermediate files are stored. Intermediate fields are stored in the RT.FIELDS
file.
To view information about all intermediate files, enter the following at the
colon prompt:
:SORT RT.FILES WITH @ID LIKE INTER...
RT.FILES.DESCRIPTION
This query statement will produce the information shown in Figure 2-7.
2-22
SORT RT.FILES WITH @ID LIKE INTER... RT.FILES.DESCRIPTION 14:17:24
Sep 26 2003 1
RT.FILES
INTER.APPL.USER
File Description These are the user fields from APPLICATIONS in ST
RT.FILES
INTER.APPLICANT
File Description This is information for a prospective applicant.
Corresponds to the APPLICANTS file in ST.
RT.FILES
INTER.APPLICANT.USER
File Description These are the user fields for the ST APPLICANTS
file.
RT.FILES
INTER.APPLICATION
File Description This is information about a person's application.
If an applicant has specified nothing except
name and address, this record is not created.
This is only used when a major is specified.
Will create an ST APPLICATIONS record and a
STUDENT.PROGRAMS record.
RT.FILES
INTER.AR.INV.USER
File Description These are the user fields for the ST AR.INVOICES
file.
Figure 2-7: Example of Query on RT.FILES File
To view information about fields of a specific intermediate file, enter the
following at the colon prompt:
:LIST RT.FIELDS WITH RTFLDS.FILE.NAME EQ filename
RTFLDS.LENGTH RTFLDS.DESCRIPTION
RTFLDS.VALIDATION.TABLE RTFLDS.VALIDATION.FILE
where filename is the name of the specific intermediate file that you want to
query. In the example below, the filename is INTER.BIODEMO.
2-23
LIST RT.FIELDS WITH RTFLDS.FILE.NAME EQ INTER.BIODEMO RTFLDS.LENGTH
RTFLDS.DESCRIPTION RTFLDS.VALIDATION.TABLE RTFLDS.VALIDATION.FILE
12:58:13 Sep 26 2003 1
RT.FIELDS
IBIO.ADDRESS.LINES
Length
30
Description
These are the address lines, not including
city, state/province, or postal code. Same
as ADDRESS.LINES in ADDRESS.
Validation Table
Validation File
RT.FIELDS
Length
Description
Validation Table
Validation File
IBIO.ADDRESS.ROUTE.CODE
4
Same as ADDRESS.ROUTE.CODE in Core ADDRESS.
ADDRESS.ROUTE.CODES
RT.FIELDS
Length
Description
IBIO.ADDRESS.TYPES
3
The type of address, such as home, business,
etc. Corresponds to the procedure element
VAR.TYPE on DMSU02.
ADREL.TYPES
Validation Table
Validation File
Figure 2-8: Example of Query on RT.FIELDS File
2-24
Your Datatel Conversions programmer/consultant will provide mapping
spreadsheets as part of your conversion mapping. These spreadsheets can help
you learn about the intermediate files, and helpyou document the relationship
between your source files, the intermediate files, and the Colleague files.
Table 2-6 on page 2-27 is an example of a mapping spreadsheet. This is only
an example. Because the information on the spreadsheets can change, your
Datatel Conversions programmer/consultant will provide to you the latest
spreadsheet. For the most part, each mapping spreadsheet will have the basic
information listed in Table 2-5.
Information
Description
Source Field
Enter the name of the source field containing the desired import data.
Src Len
Enter the length of the source field.
Conversion
Comments
Enter any comments regarding the import data.
Trans Y/N
Indicate whether the source data needs to be translated.
Len
Enter the maximum length for the data that may be stored in
Colleague.
Prefix
Enter the logical prefix used to map multiple source fields to the same
intermediate field. This prefix is used when one source record will
create multiple target records in the same target file. For more
information on logical prefixes, see “Logical Prefixes” on page 2-26.
Intermediate Field
Enter the name of the intermediate field that will be populated from
the import.
Req’d
Indicate whether the field is required in Colleague.
Comments
The purpose from the Colleague CDD.
Form
Enter the mnemonic of the Colleague form where you can view this
data.
Validation
Enter the name of any applicable code table or code file (validation
code).
Colleague Field
Enter the name of the Colleague field that will be populated from the
import.
Colleague File
Enter the name of the Colleague file containing this field.
Table 2-5: Mapping Spreadsheet Information
2-25
Logical Prefixes
You can use logical prefixes to group a set of field mappings together that will
build a single record in the intermediate file. You do not need to use logical
prefixes if you are only building one record in the intermediate file. However,
if you want to build multiple records in the same intermediate file from one
source record, then you must use logical prefixes.
Use the following guidelines on how to use logical prefixes:
If you specify a logical prefix on a field mapping to an intermediate file,
then every field mapping to that intermediate file must have a logical
prefix.
Do not use the name of a logical prefix of one intermediate file with another
intermediate file. That is, logical prefixes must be specific to each
intermediate file.
You must enter every logical prefix identified for an intermediate file in the
ELF Target File (TGTF) form with an associated Control Field. (You can
only access the TGTF form by detailing from the Target Files field on the
Source to Target Map [ELFS] form.) For information about the ELFS and
TGTF forms, see “Identifying the Target Files” on page 3-15.
2-26
2-27
Use SSN
as
IBO.ALT.I
DSa
If first
three
characters
of SSN ‘999’,
issue a
warning
and do not
populate
IBIO.SSN.
If no SSN
from
source,
issue and
do not
convert
record.a
20
12
Table 2-6: Example of a Mapping Spreadsheet
a
Intermediate
Field
IBIO.ALT.IDS
IBIO.SSN
11
Pref
ix
SSNa
Le
n
Conversio
n
Comments
Sr
c
Le
n
Sour
ce
Field
Tran
s Y/
N
Worksheet for data mapping exercise
Mapping
Comments
INTER.BIO
DEMO
INTER.BIO
DEMO
Intermediate
File
Req’
d
Other IDs
by which
the person
is currently
known. It is
displayed
but not
otherwise
used by the
system.
To record
social
security
number of
person
Comments
DA
DD
NA
E
For
m
Demographics Mapping DEM for Datatel University D01 5/16/1999
Validation
VCValcode
Table
PERSO
N.ALT.I
DS
SSN
Colleag
ue Field
PERS
ON
PERS
ON
Colleag
ue File
IBIO.LAST.NA
ME
IBIO.FIRST.NA
ME
IBIO.MIDDLE.
NAME
IBIO.PREFIX
IBIO.SUFFIX
30
15
15
15
25
a. Sample data only.
Table 2-6: Example of a Mapping Spreadsheet
Name Information
INTER.BIO
DEMO
INTER.BIO.
DEMO
INTER.BIO.
DEMO
INTER.BIO.
DEMO
INTER.BIO.
DEMO
Y
The suffix
of the
person,
such as Jr.,
Sr., PH.D.,
etc.
The prefix
of the
person,
such as Mr.,
Mrs., Dr.,
etc.
Middle
name of
person.
First name
of person
Last name
of person.
This field is
required.
NA
E
NA
E
NA
E
NA
E
NA
E
Demographics Mapping DEM for Datatel University D01 5/16/1999
VCSUFFIXES
VCPREFIXES
SUFFIX
PREFIX
MIDDLE
.
NAME
LAST.N
AME
PERS
ON
PERS
ON
PERS
ON
PERS
ON
PERS
ON
2-28
2-29
2-30
Getting Started
2
2
081
,A
9
g
u
ts
In This Chapter
This chapter describes how to identify whether any of the imported records
may be duplicates of records that already exist in Colleague, and how to
resolve issues with possible duplicates.
Topic
Page
Understanding Duplicate Checking
2-31
Setting Up Duplicate Match Criteria
2-34
Procedure for Defining duplicate Criteria
2-38
During the Intermediate-to-Colleague procedure, ELF compares the
intermediate records to records in your Colleague database. Using defined
duplicate criteria, ELF identifies new records that are duplicates of existing
ones. These duplicate records are merged into the existing Colleague file,
replacing the existing records. ELF also identifies intermediate records that
are possible duplicates. These are records that are similar to existing
Colleague records, but with enough differences that verification is required
before replacing the records. ELF does not import these records into your
database. You must manually verify and, if necessary, correct these records.
Note: Datatel supplies standard duplicate checking criteria that
should accommodate all of your importing needs.
For example, you might use last name, first name, and SSN to determine
whether a record is for a person who already exists on your database.
Colleague compares the first and last name and SSN of the new record against
names and SSNs that already exist in your database when checking for
duplicates.
2-31
Getting Started: Defining Duplicate Criteria
Each criterion can contribute a different amount in determining whether a
record is a duplicate.You can give each of these criterion a different weight or
penalty.
If the values in the fields of the two records are the same, the rating is
increased by the weight.
If the values in the two records are different (or if one is blank and the other
isn’t), the rating is decreased by the penalty.
If either values are blank, the rating is neither increased nor decreased.
The rating is then compared to the Duplicate and Possible Duplicate Rating
numbers that you define. The records are then marked “duplicate” or
“possible duplicate” and are listed on the Duplicate Report after the ITCI
process is run.
Table 2-8 illustrates how the criteria is used to determine the duplication
rating of a particular record in the intermediate file with a similar record in the
Colleague database.
Weight
Penalty
Intermediate
Value
Colleague
Value
Rating
SSN
10
10
923-45-6789
923-45-6789
+10
Last Name
10
10
Jones
Jones
+10
First Name
8
8
Ann
Susan
-8
Field
Total Rating
12
Table 2-8: Example of Duplication Rating Determination
In this example, notice that the SSN numbers and the last names are the same
for both records, but that the first names are different. For the values that are
the same, the rating uses the “weight” number, but for values that are
different, the rating uses the “penalty” number. The sum of these ratings is 12
(10 for SSN, plus 10 for the last name, and minus 8 for the first name
discrepancy). If the Duplicate Rating for this file was 15, the record would not
be considered a duplicate.
Table 2-9 provides another example in which the SSN is not found in
Colleague.
Weight
Penalty
Intermediate
Value
Colleague
Value
Rating
SSN
10
10
923-45-6789
---
-10
Last Name
10
10
Jones
Jones
+10
Field
Table 2-9: Second Example of Duplication Rating Determination
2-32
Field
Weight
Penalty
Intermediate
Value
Colleague
Value
Rating
8
8
Ann
Susan
-8
First Name
Total Rating
-8
Table 2-9: Second Example of Duplication Rating Determination
In this example, notice that again the last names are the same for both records,
but that the first names are different. For the values that are the same, the
rating uses the “weight” number, but for values that are different, the rating
uses the “penalty” number. Because a value for the SSN was not found, the
rating uses the penalty. The sum of these ratings is -8 (minus 10 for SSN, plus
10 for the last name, and minus 8 for the first name discrepancy). If the
Duplicate Rating for this file was 15, the record would not be considered a
duplicate.
2-33
Use the Duplicate Match Criteria (DUPC) form to set up ratings, weights, and
penalties to be used in determining whether two records in different files are
duplicates.
When a record is evaluated to see whether it is a duplicate, the weights are
added together when the values in the associated fields are the same between
two records. The penalties are added together when the values in the
associated fields are different between two records. The sum of the weights,
minus these penalties, is then compared to the duplicate rating number. If the
sum is greater than or equal to the duplicate rating, the record is considered a
duplicate of an existing record; if the sum is less than the duplicate rating but
greater than or equal to the possible duplicate rating, the record is considered
to be a possible duplicate of an existing record.
The duplicate processing is used when importing files. For example, if an
admissions tape is being loaded, its intended destination is the PERSON file,
and duplicate detection criteria has been set on PERSON, then any records
from the admissions tape that show as possible duplicates will not be
imported to the PERSON file. Manual intervention will be required to resolve
the duplicate records.
Only intermediate files and Colleague files are involved in the duplicate
checking because the intent is to prevent duplicate data from getting to the
Colleague database.
Figure 2-9: Duplicate Match Criteria (DUPC) Form
2-34
Noteworthy Fields on the DUPC Form
The fields in this section are particularly important for setting up duplicate
match criteria.
Field/Subroutine
Enter the name of an intermediate file field that will be used in deciding
whether or not one record is a duplicate of another.
If, at runtime, either of the data elements being compared is blank, then the
comparison is not made, and this field pair’s contribution to the total rating
will be zero.If a comparison subroutine is specified, then the subroutine is
invoked, even if the data elements are blank.
If this field is multivalued, the entire set of the intermediate record is
compared to the entire set of the existing record. There will be no attempt
made to compare all the possible permutations to find a match.
Weight
When a record is evaluated to see whether it is a duplicate, these weights are
two records. The sum of the weights, minus the penalties, is then compared to
the duplicate rating number (Dupl Rating field). If the sum is greater than or
equal to the duplicate rating, the record is considered a duplicate of an
existing record; if the sum is less than the duplicate rating but greater than or
equal to the possible duplicate rating (Poss Dupl Rating field), the record is
considered to be a possible duplicate of an existing record.
Penalty
When a record is evaluated to see if it is a duplicate, these penalties are added
together when the values in the associated fields are different between two
records. The sum of the weights, minus these penalties, is then compared to
the duplicate rating number. If the sum is greater than or equal to the duplicate
rating (Dupl Rating field), the record is considered a duplicate of an existing
record; if the sum is less than the duplicate rating but greater than or equal to
the possible duplicate rating (Poss Dupl Rating field), the record is considered
2-35
Compare to Field
This is the name of the field that the imported data will be compared to. These
are fields in the Colleague database against which the intermediate file field
will be compared.
If, at runtime, either of the data elements being compared is blank, then the
comparison is not made, and this field pair's contribution to the total rating
will be zero. Of course, if a comparison subroutine is specified, then the
subroutine is invoked, even if the data elements are blank.
If this field is multivalued and the field in the ELFDUPL.FIELDS file is
single-valued, then if the value in the ELFDUPL.FIELDS filed matches any
occurrence of the values in this ELFDUPL.COMPARE.TO.FIELDS file, that
is considered a duplicate and will be given the associated weight or penalty.
Limiting Field/Subroutine and Compare to Field
This field tells the duplicate checking routine which subsets of records to
select.
For example, suppose this field were INT.LAST.NAME in an intermediate
file. The limiting comparison field could be LAST.NAME in the PERSON
file. This says to limit the records to check for duplicates to the set of records
in the PERSON file where the intermediate file last name matches the
LAST.NAME field. Then the duplicate algorithms process the subset of the
PERSON file that have the same last name as the intermediate file.
Without this type of field, each record in the intermediate file would have to
be compared to each record in the PERSON file every time, which would take
an unacceptably long time.
Dupl Rating
Enter the threshold at which a record should be considered a confirmed
duplicate.
two records. The penalties are subtracted when the values in the associated
fields are different between the two records. The sum of the weights, minus
the penalties, is then compared to this duplicate rating number. If the sum is
greater than or equal to the duplicate rating, the record is considered a
2-36
greater than or equal to the value in the Poss Dupl Rating field, the record is
considered to be a possible duplicate of an existing record. Duplicate records
are merged with the Colleague record.
Dupl Subroutine
Use this field to enter the name of a user-defined subroutine used to do
duplicate checking. If this subroutine exists, all other fields on the duplicate
criteria record are ignored; however, they can be entered for use by this
subroutine.
Poss Dupl Rating
Enter the threshold at which a record should be considered a confirmed
duplicate.
two records. The penalties are subtracted when the values in the associated
fields are different between the two records. The sum of the weights, minus
the penalties, is then compared to the value in the Dupl Rating field. If the
sum is greater than or equal to the duplicate rating, the record is considered a
greater than or equal to this possible duplicate rating, the record is considered
2-37
Procedure for Defining duplicate
Criteria
Complete the following steps to define your duplicate criteria.
Before defining duplicate criteria, you should familiarize yourself with the
process of defining duplicate criteria. For more information, see “In This
Chapter” on page 2-31.
Step 1. Use the Duplicate Match Criteria (DUPC) form to modify or create a new
duplicate criteria record.
Step 2. Make the appropriate modifications on the DUPC form.
For more information, see “Setting Up Duplicate Match Criteria” on
page 2-34 and the DUPC form online help.
Step 3. Save the record.
2-38
Getting Started
2
2
081
,A
9
g
u
ts
In This Chapter
This chapter describes how to define the merge criteria that will be used to
identify which of the possible duplicates are merged with existing Colleague
records.
Topic
Page
Understanding Merge Criteria
2-39
Procedure for Defining Merge Criteria
2-44
When you run the Inter-to-Colleague Import (ITCI) process, ELF compares
incoming records to those already in the Colleague database. If it finds a
confirmed duplicate, the process merges the information in the intermediate
file record with your existing record in Colleague. ELF uses the defined
merge criteria to determine how to handle the information in the two records
and merge them into one record.
Note: For each file, Datatel supplies standard merge criteria that
should accommodate all of your importing needs.
You can customize your merge criteria if the standard merge criteria supplied
by Datatel does not meet your needs. Use the ELF Merge Criteria (MRGC)
form to define custom merge criteria you want ELF to use when merging the
intermediate files with your Colleague files.
Figure 2-10 shows an example of how Datatel used the ELF Merge Criteria
(MRGC) form to define the merge criteria for the APPLICANTS file.
2-39
Getting Started: Defining Merge Criteria
Figure 2-10: Example of the ELF Merge Criteria (MRGC) Form
Noteworthy Fields on the MRGC Form
Merge Actions
When ELF finds two records that are duplicates, it attempts to merge the two
records into one. You must select either P, PN, or RN to be the default for each
field in the file. (See Table 2-11 on page 2-41 for a description of these merge
actions.) You can define separate merge actions for each field, if appropriate.
You can only select either P, PN, or RN as default merge actions because you
do not want to overwrite valid Colleague record information with incorrect or
blank record information. For example, you may import immunization
information from the INTER.PERSON.HEALTH file. This information may
only contain the immunization information for a person, with the remaining
fields (last name, first name, address, and so on) left blank. If you had a merge
action defined (other than P, PN, or RN), you could possibly overwrite a valid
2-40
name field in the person’s record with a blank value. Using either P
(preserve), PN (preserve unless null), or RN (replace unless null) will prevent
overwriting valid information.
Table 2-11 shows the various types of merge actions you can specify for a
single-valued field. These merge actions are stored in the
ELF.MERGE.ACTION validation code table. You can use these codes on the
ELF Merge Criteria (MRGC) form.
Code
Merge Action
Description
P
Preserve
Preserve the existing data in the Colleague record.
PN
Preserve unless null
Preserve the existing data in the Colleague record, unless the
existing data is null. In that case, use the data in the new
record.
R
Replace
Replace the existing data in the Colleague record with the
data in the new record.
RN
Replace unless null
Replace the existing data in the Colleague record with the
data in the new record, unless the data in the new record is
null. In that case, preserve the existing data.
Table 2-11: Merge Actions for Single-Valued Fields
Table 2-12 shows the merge actions you can specify for a multivalued field or
an association.
Code
MP
MR
Association
Merge Actions
Merge/Preserve
Merge/Replace
Are Duplicate
Controllers Allowed?
Description
No
Merge the data in the new record with the
data in the Colleague record. If a controller in
the new record already exists in the
Colleague record, preserve that instance of
the association in the Colleague record.
Yes
Add the new data as a new entry in the list,
because there is no way to know which value
is to be preserved.
No
Merge the data in the new record with the
data on the Colleague record. If a controller in
the new record already exists on the
Colleague record, replace that instance of the
association with the data iin the new record.
Yes
Add the new data as a new entry in the list,
because there is no way to know which value
is to be replaced.
Table 2-12: Merge Actions for an Association
2-41
Note that both Merge/Preserve and Merge/Replace add entries if the
controller is new (that is, it did not previously exist in the Colleague set of
values). To clear out the whole list or association, specify an action of Replace
and put nulls on the new record. You cannot delete just one entry of a list or an
association.
If you have a field that contains a multivalued list but is not an association,
there is no difference between Merge/Preserve and Merge/Replace. Both add
a new value and leave an existing value unchanged.
Table 2-13 shows some additional information about merge actions on the
PERSON and ADDRESS files. You must decide how appropriate the
information is for your particular needs.
PERSON
ADDRESS
Most fields are of action PN
All fields are of action PN
Associations are of action MP
Associations are of action MP
For more details, see the IBIO.PERSON file
using the MRGC form
For more details, see the IBIO.ADDRESS file
using the MRGC form
Table 2-13: Merge Actions on the PERSON and ADDRESS Files
Merge Subroutines
Use this field to enter the name of a user-defined subroutine used to merge
data with an existing record. If this subroutine exists, all other fields on the
merge criteria record are ignored; however, they can be entered for use by this
subroutine.
Arguments:
A.TARGET.ID (Input). The ID of the Colleague record in which data will
be merged
A.ELF.MERGE.CRITERIA (Input). The ID of
ELF.MERGE.CRITERIA record being used to merge data.
A.IMPORT.RECORD (Input). The entire import record. This is the
record that the import routine has built that will be written to the target file.
A.TARGET.RECORD (Input). The entire original Colleague record
being updated.
A.NEW.RECORD (Output). The entire replacement Colleague record.
ABORT.MSG (Input/Output). This is a field-delimited list of error
messages, and may already contain message on input. Messages describing
any errors encountered should be added to this list.
2-42
The following are examples of the types of merge subroutines that are
delivered by Datatel:
Merge Criteria Name: APPLICATIONS
Merge Subroutine: S.MERGE.APPLICATIONS
Merge Criteria Name: IINST.ADDRESS
Field Merge Subroutine: S.MERGE.ADR.LINES
Merge Criteria Name: IBIO.PERSON
Assoc Merge Subroutine: S.MERGE.PEOPLE.EMAIL
Existing subroutines that can be used as examples can also be found with the
following query:
MIOSEL ELF.MERGE.CRITERIA WITH ELFMERG.SUBR OR WITH
ELFMERG.FIELD.SUBRS OR WITH
ELFMERG.ASSOCIATION.SUBRS
LIST ELF.MERGE.CRITERIA ELFMERG.SUBR
ELFMERG.FIELD.SUBRS ELFMERG.ASSOCIATION.SUBRS
2-43
Procedure for Defining Merge Criteria
Complete the following steps to define your merge criteria.
Before defining you merge criteria, familiarize yourself with the file merge
process. For more information, see “In This Chapter” on page 2-39.
Step 1. Access the ELF Merge Criteria (MRGC) form.
Step 2. Determine the merge action you want to default if no specific merge action is
defined for a field. Enter the corresponding code for that merge action into the
Default Action field.
Step 3. Make the appropriate modifications on the MRGC form.
See “You can customize your merge criteria if the standard merge criteria
supplied by Datatel does not meet your needs. Use the ELF Merge Criteria
(MRGC) form to define custom merge criteria you want ELF to use when
merging the intermediate files with your Colleague files.” on page 2-39 and
the online help for the MRGC form.
2-44
Getting Started
2
2
081
,A
9
g
u
ts
In This Chapter
This chapter describes how to define your translation tables.
Topic
Page
Understanding File Translation Tables
2-45
Procedure for Defining File Translation Tables
2-49
Determining Whether Translation Tables Are Completed
2-50
Worksheet for File Translation Tables
2-51
The source data you are importing does not necessarily contain the codes used
by your institution. You can define how you want ELF to translate each code
in the source data. ELF uses the translation tables you define for each code
and converts the original source code into a new code set up in Colleague.
You must define a translation table for each code used by the source data. For
delivered imports, refer to the online help for the particular source-tointermediate import you will use for a list of translation tables you need to
define. Refer to the documentation that you received with the source data to
determine a list of values used by the source for each code.
Use the File Translation Table (FLTT) form to define a translation for every
code referenced in the source data. List the values used by the source on the
FLTT form in the Original Code column. In the New Code column list the
appropriate Colleague code used by your institution.
Note: If you do not define a new code for a particular original code,
ELF leaves the corresponding field in the intermediate file blank.
2-45
Getting Started: Defining Translation Tables
For example, Figure 2-11 shows how Datatel University translated the student
ethnic codes used on the SAT test tape into ethnic codes used by DU.
Figure 2-11: Example of Defining a Translation Table
To define the translation table for the ethnic codes in the example above,
Datatel University used a worksheet like the one shown in Table 2-15. The list
of the original code values and their descriptions came from the source data
documentation. The new code value list is the appropriate translation of each
original value into DU’s ethnic code values. Note that the last three code
values do not have corresponding new values. Therefore, if a source file
contains one of those code values, the corresponding intermediate file will not
have a value for that code.
2-46
Original Code Values
(from Source)
Description
New Code Values
(Colleague)
1
African-American/Black
02
2
American Indian/Alaskan Native
05
3
Caucasian-American/White
01
4
Mexican-American/Chicano
08
5
Asian-American/Pacific Islander
04
6
Puerto Rican/Cuban/other Hispanic origin
03
7
Other
--
8
Multiracial
--
9
Not Specified
--
Table 2-15: Example of a Translation Table Worksheet
The ELF translation tables are only maintained through the FLTT form. You
could build your own utility to populate the table, especially if you have
hundreds of entries and would rather not enter each entry by hand. A
translation table is one record in the ELF.TRANSLATE.TABLES file, and the
values in the table are stored in a multivalued association. Check the
dictionary of the file for the appropriate positions.
If you have a source code that needs to be defined into two or more different
codes, Datatel recommends that you build separate tables for each new code
using the source code, rather than trying to use the special processing fields on
the FLTT form. For example, if you have source codes A1, B2, C3, D4, and so
on, and you want to separate each into two codes, you can build the following:
Source
New
Source
New
A1
A
A1
1
B2
B
B2
2
C3
C
C3
3
D4
D
D4
4
Table 2-16: Example of “Splitting” a Source Code
2-47
Special Processing Fields
The specific delivered Source-to-Intermediate Import procedure you use may
have optional special processing that further defines how the source data is
translated. In these cases, the translation table must also include information
in the Special Processing Fields. See the Comments field for a particular
translation table for more information.
2-48
Procedure for Defining File Translation Tables
Procedure for Defining File Translation
Tables
Complete the following steps to define your file translation tables.
Step 1. Determine which Source-to-Intermediate procedure you need to use for this
import.
For more information, see “Understanding the Source-to-Intermediate Files
Transfer” on page 3-32 for a partial list of available procedures.
Step 2. Determine which translation tables you must define.
Step 3. Refer to the documentation that came with your source data to determine what
values the source uses for each code.
Step 4. Complete a worksheet for each file translation table you must define.
For more information, see “Worksheet for File Translation Tables” on
page 2-51.
Step 5. Access the File Translation Table (FLTT) form.
Step 6. Complete the FLTT form for one of your translation tables.
Step 8. Repeat the procedure for each file translation table you identified in Step 3.
2-49
Determining Whether Translation
Tables Are Completed
Datatel strongly recommends that you use your mapping spreadsheet to
determine whether you’ve specified all the translation tables needed for your
ELF process. However, you can use the following query sentence to
determine the translation tables required for your ELF process. Enter the
following query sentence at the colon prompt.
Where import.name is the name of your ELF import:
LIST ELF.MAPS WITH @ID EQ import.name WITH
ELFMAP.TRANSLATE.TABLE ELFMAP.SRC.FIELD
ELFMAP.TGT.FIELD ELFMAP.TRANSLATE.TABLE
Where ELF_import_file_name is the name of the import file:
LIST RT.FIELDS WITH RTFLDS.FILE.NAME EQ
ELF_import_file_name WITH
RTFLDS.READ.TRANSLATE.TABLE
RTFLDS.READ.TRANSLATE.TABLE
2-50
Description
New Code
Table 2-17: Worksheet for File Translation Tables
Orig
Code
New Code Field
Original Code Field
Description
ELF Table Name
Field 1
Field 2
Special Processing Fields
Field 3
Complete the following worksheet for each file translation table you must define.
Field 4
2-51
2-52
Getting Started
2
Identifying Codes Related to the
ELF Process
2
081
,A
9
g
u
ts
In This Chapter
This chapter provides information about validation code tables that you will
use during the ELF process. The codes in this section are defined by Datatel;
you cannot maintain these codes.
This chapter also provides information about how you can verify whether the
account in which you are working has the validation code tables and code
files that are needed by the intermediate files. This section only provides
information on how you can verify; this section does not provide a list of
those validation code tables or code files because each intermediate file may
require a different set of validation code tables and code files.
Topic
Page
Before You Begin
2-53
Understanding ELF Codes
2-54
Verifying Validation Code Tables and Code Files
2-60
Validation Code Worksheet
2-64
Before You Begin
Before you can identify the codes that are related to the ELF process, you
must map your source-to-intermediate files. During the mapping process, you
identify the validation code tables needed by each intermediate file. Review
your mapping chart for this information. See “Mapping Your Data” on
page 2-15 for more information about mapping.
2-53
Getting Started: Identifying Codes Related to the ELF Process
The codes used by the ELF process are defined by Datatel. Definitions of
some of the main codes are given in the following sections.
Duplicate Categories
The ELF process assigns a duplicate category code (stored in the
DUPL.CATEGORIES validation code table) to imported records.
These categories are set by the ELF duplicate detection process. This
identifies the duplicate category based on the rating as defined on the
Duplicate Match Criteria (DUPC) form.
Duplicate category codes are used on the ELF Target Results/Dupl Res
(TGTR) form.
ELF File Types
The ELF Source-to-Intermediate process needs to know what type of media
the source information is coming from. Table 2-19 shows a list of the
predefined codes and their descriptions.
Code
Description
C
Colleague
FD
Fixed Disk
FT
Fixed Tape
O
Other
VD
Variable Disk
VT
Variable Tape
Table 2-19: ELF File Type Codes
For more information about how the ELF file type codes are used onthe
Electronic Transfer File (ELFT) form, refer to “Understanding Source File
Definition” on page 3-2.
2-54
Use the ELF file types (stored in the ELF.FILE.TYPES validation code table)
in the File Type field on the ELFT form. The ELF file types codes you specify
for a file determines which of the following forms you can access for a file:
For more information about how these codes are used with these forms, see
“Defining Source Files” on page 3-1.
ELF Merge Actions
ELF merge actions codes (stored in the ELF.MERGE.ACTIONS validation
code table) are used by the ELF import process to determine how a field from
a source file is merged with an existing Colleague record. These predefined
codes are used on the ELF Merge Criteria (MRGC) form.
ELF Run Modes
The ELF process uses ELF run modes codes (stored in the ELF.RUN.MODES
validation code table) to determine whether an ELF process is in progress.
There are only two predefined ELF run modes codes:
S – ELF process is Stopped
R – ELF process is Running
These statuses occur in the background (in a field called
ELFBAT.RUN.MODE) during batch processing and are not displayed on any
form.
ELF Target Statuses
The ELF target statuses codes (stored in the ELF.TGT.STATUSES validation
code table) indicate the results of trying to import an intermediate file record
to the Colleague database. These codes are applied during the second phase of
an import.
2-55
There are two sets of possible statuses. The first set of codes is used when
running the second phase of an import in update mode. The second set is used
when in non-update mode, or when errors occur during update mode.
Table 2-20 provides a list of predefined target status codes.
Code
Description
Codes used when running the second phase of an import in update mode
E
Error – an error occurred for this target record
N
New – a new record was successfully added
M
Merged – an existing record was successfully updated with the data
from this import record
A
Ambiguity – duplicate checking encountered an ambiguous situation
where either:
• There is more than one possible duplicate
• Yhere is one possible duplicate, but it is not certain
Codes used when in non-update mode
A
Ambiguity (same as update mode)
AN
Anticipated New
AM
Anticipated Merge
X
The target record was not written
Table 2-20: ELF Target Status Codes
The ELF target status codes appear on such forms as the ELF Target Results/
Dupl Resolution (TGTR) form and the ELF Transaction Tracking (ETRK)
form.
2-56
ELF Transaction Status
The ELF process uses ELF transaction status codes (stored in the
ELF.TRANSACTION.STATUSES validation code table) to indicate the
status of an ELF import. Table 2-21 provides a list of predefined transaction
status codes and their descriptions.
Code
N
NA
Description
Not yet processed (ITCI process has not yet been run).
No ambiguities found. The data in the intermediate file has been checked for duplicates but
has not yet been imported into Colleague.
A
Ambiguity found. The data in the intermediate files has been checked for duplicates, and
duplicate checking found an ambiguity that you must manually resolve before the transaction
can be processed.
E
Errors were detected, which prevented the transaction from being imported.
I
Imported. The data from the intermediate files has been successfully imported into Colleague
Table 2-21: ELF Transaction Status Codes
The ELF transaction status codes are used on such forms as the ELF
Transaction Tracking (ETRK) form, where you can monitor an ELF
transaction.
2-57
ELF Transfer Statuses
The ELF process that performs the import or export assigns transfer statuses
codes (stored in the ELF.TRANSFER.STATUSES validation code table) to
the ELF transfer. These codes specify the stage in which the process is
currently running. If a process can only be run once (for example, a
conversion should only be run once in update mode), the status is used to
prevent it from running again. Table 2-22 provides the list of predefined codes
and their descriptions.
Code
Description
R
Running
C
Completed without errors
E
Completed but generated errors
A
Aborted
Table 2-22: ELF Transfer Status Codes
ELF Translate Actions
The ELF process uses ELF translate action codes (stored in the
ELF.TRANSLATE.ACTIONS validation code table) to specify how a
translate failure should be treated for the purposes of mapping one field to
another. Table 2-23 lists the predefined ELF translate action codes.
Code
Description
K
Keep the original (pretranslation) data
N
Null – keep as blank or null for the translated value
E
Error – consider this an error
Table 2-23: ELF Translate Action Codes
ELF translate action codes are used on the following forms in Colleague
Core:
ELF Field Mapping Detail (ELMD) form
Data Element Edits (RDEE) form
2-58
ELF Update Actions
The ELF process uses ELF update action codes (stored in the
ELF.UPDT.ACTIONS validation code table) to determine what action to take
on a target field that contains data. Table 2-24 shows a list of update action
codes and their descriptions.
Code
Description
A
Append – causes the source data to be added to the end of existing data. This code is
only valid if the target field is multivalued.
O
Overwrite – causes the existing target data to be replaced by the source data.
N
No Update – protects existing data by not allowing anything already in the target field to
be changed. This is useful when loading external tapes where only new information is
desired, not changes to what is already in the database.
Table 2-24: ELF Update Action Codes
ELF Value Error Actions
The ELF process uses the value error action codes (stored in the
ELF.VALUE.ERROR.ACTIONS validation code table) to determine the
proper action if data intended for a target record fails the target field’s
validation specifications. Table 2-25 provides a list and description of the ELF
value error action codes.
Code
AN
R
Description
Accept/No value. The invalid value is dropped and a null value used (unless the
target field has a default value specified, in which case the default value is used).
Reject. The record is rejected and will not be written to the file.
Table 2-25: ELF Value Error Action Codes
ELF value error action codes are used by the underlying processes of the
following Colleague Core forms:
ELF Field Mapping (ELFM) form
ELF Field Mapping Detail (ELMD) form
2-59
Verifying Validation Code Tables and
Code Files
In the previous section, you learned about the validation code tables that are
defined by Datatel for the ELF process. In this next section, you will learn
some simple ways to check whether all the validation code tables and code
files that you must define have been created.
You should ensure that your validation code tables and code files are created.
If some of your code table or files are not created, you could get error
messages during the source-to-intermediate phase of the ELF process.
Checking Your Mapping Spreadsheets
Review your mapping data spreadsheets to determine which code tables and
code files you need to define. This is one way to check the existence of
required validation code tables and code files. Use the Validation Codes
(VAL) form to verify that the validation code tables you specified on the
spreadsheet do exist in Colleague Core. For information about mapping
spreadsheets, see “Mapping Spreadsheets” on page 2-25.
Using a Query Sentence to Verify Validation Code
Tables
Another method of checking is to search the intermediate file for fields
validated against code tables. Enter the following query sentence at the colon
prompt.
Where intermediate.file.name is the name of the intermediate file you want to
search:
:SORT RT.FIELDS WITH RTFLDS.FILE.NAME EQ
intermediate.file.name WITH
RTFLDS.VALIDATION.TABLE RTFLDS.VALIDATION.TABLE
RTFLDS.VAL.TABLE.APPLICATION
Figure 2-12 on page 2-61 shows the results of the query using the
INTER.BIODEMO file as the intermediate file.
2-60
SORT RT.FIELDS WITH RTFLDS.FILE.NAME EQ INTER.BIODEMO WITH
RTFLDS.VALIDATION.TABLE RTFLDS.VALIDATION.TABLE
RTFLDS.VAL.TABLE.APPLICATION 13:34:39 Sep 26 2003 1
Val
RT.FIELDS................... Validation Table................... Appl
IBIO.ADDRESS.TYPES
IBIO.COMMUNICATION.STATUSES
IBIO.EMAIL.TYPES
IBIO.MARITAL.STATUS
IBIO.ORIGIN
IBIO.PHONE.TYPES
IBIO.PREFIX
IBIO.PRIVACY.FLAG
IBIO.STATUS
IBIO.SUFFIX
IBIO.VETERAN.TYPES
12 records listed
ADDRESS.ROUTE.CODES
ADREL.TYPES
CORR.STATUSES
PERSON.EMAIL.TYPES
MARITAL.STATUSES
PERSON.ORIGIN.CODES
PHONE.TYPES
PREFIXES
PRIVACY.CODES
PERSONAL.STATUSES
SUFFIXES
VETERAN.TYPES
CORE
CORE
CORE
CORE
CORE
CORE
CORE
CORE
CORE
CORE
CORE
CORE
Figure 2-12: Example of Query on the INTER.BIODEMO File
The results of the query display the fields within the specified intermediate
file that require validation against a particular code table. However, you may
not have all the fields mapped (depending on your institutional needs). For
example, your institution may not require a mapping to the
IBIO.EMAIL.TYPES field in the INTER.BIODEMO file. Therefore, you
don’t need to populate the PERSON.EMAIL.TYPES validation code table.
The validation code tables displayed as a result of the query were created by
Datatel for the intermediate file. Your institution needs to determine the codes
you want to use to populate those validation code tables. This may require a
team or group from your institution to determine the codes and how those
codes will be used within the system. As a simple example, the codes team
can specify which prefixes to define in the phone types validation code table.
The codes team would determine whether they want to use numeric or
alphabetic codes, what each means, and if any special processing is needed.
You can use the validation code worksheet on page 2-64 to help you
determine the codes you need to define for each validation code table. You
can define most validation code tables using the Validation Codes (VAL)
form. However, some validation code tables use other forms. For example,
use the Prefix and Suffix Definition (PPS) form to define the prefixes and
suffixes validation code tables.
2-61
Using a Query Sentence to Verify Validation Code
Files
Validation code files differ from validation code tables in that the code files
are stored in their own, individual files, whereas all code tables are stored in
either the VALCODES or appl.VALCODES files (where appl is the
mnemonic of the application, such as CORE, CF, ST, and so on.).
To check whether you’ve defined the validation code tables needed for your
import, enter the following query sentence at the colon prompt.
Where intermediate.file.name is the name of the intermediate file you want to
search:
:SORT RT.FIELDS WITH RTFLDS.FILE.NAME EQ
intermediate.file.name WITH RTFLDS.VALIDATION.FILE
RTFLDS.VALIDATION.FILE
Figure 2-13 shows the results of the query using the INTER.BIODEMO file
as the intermediate file.
SORT RT.FIELDS WITH RTFLDS.FILE.NAME EQ INTER.BIODEMO WITH
RTFLDS.VALIDATION.FILE RTFLDS.VALIDATION.FILE 13:39:25 Sep 26 2003 1
RT.FIELDS................... Validation File.................
IBIO.COMMUNICATION.CODES
IBIO.COUNTRY
IBIO.COUNTY
IBIO.DENOMINATION
IBIO.DRIVER.LICENSE.STATE
IBIO.ETHNIC
IBIO.OCCUPATION
IBIO.RESIDENCE.COUNTY
IBIO.RESIDENCE.STATE
IBIO.STATE
10 records listed
CC.CODES
COUNTRIES
COUNTIES
DENOMINATIONS
STATES
ETHNICS
OCCUPATIONS
COUNTIES
STATES
STATES
Figure 2-13: Example of Query on the INTER.BIODEMO File
The results of the query display the fields within the specified intermediate
file that require validation against a particular code file. However, you may
not have all the fields mapped (depending on your institutional needs). For
example, your institution may not require a mapping to the
IBIO.DRIVER.LICENSE.STATE field in the INTER.BIODEMO file.
Therefore, you don’t need to populate the STATES validation code table for
this field. However, by looking at the results, you will need to populate the
STATES validation code table for other fields.
2-62
The validation code files displayed as a result of the query were created by
Datatel for the intermediate file. Your institution needs to determine the codes
you want to use to populate those validation code tables. Just as with
validation code tables, this may require a team or group from your institution
to determine the codes and how those codes will be used within the system.
As a simple example, the codes team can specify how to define ethnic groups
in the ethnics validation code file. The codes team would determine whether
they want to use numeric or alphabetic codes and the description of the codes.
Because the validation code files are stored in their own individual files, each
code file has a specific form that you can use to define them. Most of these
forms are located on the Institution Core Setup (ICS) menu in Colleague
Core. Use Table 2-26 on page 2-63 to determine which form you need to use
to define a specific code file.
Mnemonic
Form Name
Mnemonic
Form Name
DEPT
Department
OACD
Other Academic Levels
DIV
Divisions
CHP
Chapters
ODIV
Other Divisions
RCLS
Reunion Classes
SCHL
Schools
BKCM
Bank Codes Maintenance
LOCN
Locations
DENO
Denominations
OLOC
Other Locations
ETH
Ethnics
CNTY
Counties
DISD
Disabilities
CTRY
Countries
INTR
Interests
ODEG
Other Degrees
VOCD
Vocations
OMAJ
Other Majors
OCC
Occupations
OMIN
Other Minors
ORTY
Organization Types
OCCD
Other CDDs
ITTL
Institution Contact Titles
OSPC
Other Specializations
SUPL
Supplies
OHON
Other Honors
EQPM
Equipment
Table 2-26: Institution Core Setup (ICS) Forms
2-63
2-64
Description (20 characters maximum
upper and lower case)
Table 2-27: Validation Code Worksheet
Code
Form Mnemonic: VAL
Table Name: _______________________________________
Minimum Value
Validation Codes
Validation Code Worksheet
Special
Processing 1
Special
Processing 2
Using ELF
3. Source to Intermediate
Imports
Source to Intermediate Imports
3
2
081
,A
9
g
u
ts
In This Chapter
In this chapter, you will learn how to identify and describe your source files
before beginning the actual import process. You must first define the source
files so that the ELF process knows what to look for and where.
Topic
Page
Understanding Source File Definition
3-2
Procedure for Defining Source Files
3-7
Defining Fields of a Variable Length File
3-8
Defining Fields for a Fixed Length File
3-11
3-1
Source to Intermediate Imports: Defining Source Files
You must define each of the source files that you want to import before you
can move the information into your intermediate files. Refer to the online
process help for the particular source-to-intermediate procedure you are about
to use. See “Understanding the Source-to-Intermediate Files Transfer” on
page 3-32 for a partial list of procedures available.
Use the Electronic Transfer File (ELFT) form, shown in Figure 3-1, to define
the external source of the imported information.
Figure 3-1: Electronic Transfer File (ELFT) Form
Note: You will also use the ELFT form to define your target file for an
ELF export. See “Exporting Data Using ELF” on page 6-1 for
information about the ELF export process.
3-2
Noteworthy Fields on the ELFT Form
The following fields are particularly useful when defining source files.
File Type
You must define which of the following describe the source of your imported
data:
Colleague style
Variable tape
Fixed tape
Variable disk
Fixed disk
Custom
If your source is a fixed file, either tape or disk, you can detail to the Fixed
File Fields (ELFF) form to define the file fields.
Depending upon your source file type, you must specify other types of
information for each source file. Table 3-2 shows the additional information
necessary for each type of source file and where to refer for more information.
File Type
Additional Information Needed
Page
Colleague style
none
n/a
Variable Disk
File location
3-4
Variable length file characteristics
3-5
Records and blocks to skip (optional)
3-6
File location
3-4
Fixed length file characteristics
3-5
3-6
Tape characteristics
3-4
Variable length file characteristics
3-5
3-6
Fixed Disk
Variable Tape
Table 3-2: Additional Information Needed Per File Type
3-3
File Type
Fixed Tape
Other
Additional Information Needed
Page
Tape characteristics
3-4
Fixed length file characteristics
3-5
3-6
Custom
3-6
Table 3-2: Additional Information Needed Per File Type (cont’d)
File Location or Directory
If your source file is either a fixed or variable disk, you must define the source
file location. This includes defining both the operating system directory and
the OS file name for the physical file.
For example, in UNIX, if the path to the source file is /user/datatel/
FILENAME, then you would define the directory as “/user/datatel” and the
OS File Name as “FILENAME.”
Datatel recommends that the file name and the OS file name be the same. For
example, in Figure 3-1 on page 3-2, the file name (as selected using
Electronic Transfer File LookUp from the RT.FILES file) is JAF.TEST and
the name entered in the OS File Name field is also JAF.TEST.
Tape Characteristics
If your source files are on a tape, you must define the following:
The conversion to be performed on the tape data.
The unit string number associated to the tape drive.
A label to be used when creating a tape with this file structure.
The length of the tape label.
Position of file on the tape.
3-4
Variable Length File Characteristics
If the source contains files of variable length, you must define the delimiters
between the various parts of the file, including the following:
record delimiter (ASCII character “10,” a line feed)
field delimiter
value delimiter
subvalue delimiter
You can detail from the File Type field on the ELFT form to access the
Variable File Fields (ELFV) form if the file type you enter in the File Type
field is one of the following:
VD – variable disk
VT – variable tape
C – Colleague
O – other
Use the ELFV form to define fields for variable files. For more detailed
information about defining fields of a variable length file, see “Defining
Fields of a Variable Length File” on page 3-8.
Fixed Length File Characteristics
If the source contains files of fixed length, you must define the following
lengths:
record length
block length
If the block length is not an even multiple of the record length, you will
receive a warning. For example, if the block length is 8000, a record length of
200 is acceptable. A record length of 202 receives a warning that the record
size does not fit evenly within the block.
You can detail from the File Type field on the ELFT form to access the Fixed
File Fields (ELFF) form if the file type you enter in the File Type field is one
of the following:
FT – fixed tape
FD – fixed disk
O – other (custom)
3-5
Use the ELFF form to define fields for fixed length files. See “Defining Fields
for a Fixed Length File” on page 3-11 for more information about defining
fields for fixed length files. Only files with one of the file types listed above
can be accessed on the ELFF form.
Records and Blocks to Skip
If your source files are any type but Colleague, you must define the number of
records and blocks to be skipped before processing the first record. This is to
guarantee that the import starts with the correct record and block of
information.
Custom
If you are using any “other” source files, you must customize the input and
output subroutines. Use the Custom ELF File Access (CELF) form, shown in
Figure 3-2, to specify input and output subroutines for “other” file types.
Figure 3-2: Custom ELF File Access (CELF) Form
3-6
Complete the following steps to define your source files.
Step 1. Familiarize yourself with the source file definition.
For more information, see “Understanding Source File Definition” on
page 3-2.
Step 2. Determine the source files you need to either create or modify.
Refer to the online process help for the source-to-intermediate procedure you
intend to use.
Step 3. Access the Electronic Transfer File (ELFT) form.
Step 4. Enter the necessary information for the type of source files you want to
import.
For more information, see Table 3-2 on page 3-3 for a list of necessary
information based on the source file type.
3-7
Defining Fields of a Variable Length
File
Use the Variable File Fields (ELFV) form to add and define fields to a file.
Figure 3-3 shows an example of the ELFV form.
Figure 3-3: Variable File Fields (ELFV) Form
You can access the ELFV form directly or you can detail to it from the File
Type field on the ELFT form. To access a file from the ELFV form, the file
must be defined with one of the following file types:
VD – variable disk
VT – variable tape
C – Colleague
O – other
3-8
Defining Fields of a Variable Length File
Noteworthy Fields on the ELFV Form
The following fields are particularly useful when defining fields to a file.
File Prefix
Each field in a file is unique to that particular file. For example, LAST.NAME
is unique to the PERSON file and can only be used with the PERSON file.
The File Prefix you define for this file is attached to the beginning of all fields
for this file. The prefix you define for this file should somehow relate to the
file (perhaps an abbreviation of the file) because it will make the fields unique
to this file only. In the example in Figure 3-3, the file name is
D01.IMPORT.FILE, and the file prefix specified is D01IMP.
Because all the fields for this file are unique to this file, all the fields will have
the prefix at the beginning of their names.
Data Field Names
You can specify unique field names for the intermediate file using the Data
Field Names fields on the ELFV form. The ELF process assigns these field
names to the information found in the designated positions in your source file.
When you enter a field name in a Data Field Names field, the prefix you
specified in the File Prefix field will be attached to the beginning of the field
name you enter. For example, if you want to name a field
D01IMP.LAST.NAME in the D01.IMPORT.FILE file, you would enter
LAST.NAME in the Data Field Names field. The ELFV form will attach the
specified file prefix (in the example, D01IMP) plus a period to the beginning
of the field name, making the field name D01IMP.LAST.NAME.
Note: Because the ELFV form automatically attaches the prefix to the
field name, do not enter the prefix in this column. For example, if you
want to name a field D01IMP.LAST.NAME in the D01.IMPORT.NAME
file, do not enter D01IMP.LAST.NAME. The resulting file name will
become D01IMP.D01IMP.LAST.NAME, because the ELFV form
attaches the specified prefix plus a period to the field name you enter.
These data field names will be used later in the import process on the ELF
Field Mapping (ELFM) form when defining the target fields. (For more
information about defining the target fields, see “Identifying the Target
Fields” on page 3-21.
3-9
Number
The number you specify in the Number field corresponds to the order of the
field in the source file. Using the example in Figure 3-3 on page 3-8, the first
field in the source file is SSN. Therefore, the first field in the
D01.IMPORT.FILE file should be D01IMP.SSN, and the number given to it
must be 1.
Length
Even though the file is a variable length file, you must specify a length for
each field. When you specify the length, think of all the possibilities on how
the field could be used.
For example, the D01IMP.SSN field could hold only numbers or numbers and
characters (such as the hyphen [-] between numbers). The field could hold
555555555 (9 characters) or 555-55-5555 (11 characters).
3-10
Use the Fixed File Fields (ELFF) form to add and define fields in files of a
fixed length. Figure 3-4 shows an example of the ELFF form.
You can access the ELFF form directly or you can detail to it from the File
Type field on the Electronic Transfer File (ELFT) form. To access a file from
the ELFF form, the file must be defined with one of the following file types:
FD – fixed disk
FT – fixed tape
O – other
Figure 3-4: Example of the Fixed File Fields (ELFF) Form
3-11
Noteworthy Fields on the ELFF Form
The following fields are particularly useful when defining fields for a fixed
length file.
File Prefix
Each field in a file is unique to that particular file. For example, LAST.NAME
is unique to the PERSON file and can only be used with the PERSON file.
The File Prefix you define for this file is attached to the beginning of all fields
for this file. The prefix you define for this file should some how relate to the
file (perhaps an abbreviation of the file) because it will make the fields unique
to this file only. In the example in Figure 3-4 on page 3-11, the file name is
D01.IMPORT.FILE2, and the file prefix specified is D01IM2.
Because all the fields for this file are unique to this file, all the fields will have
the prefix at the beginning of their names.
Data Field Names
You can specify unique field names for the intermediatefile using the Data
Field Names fields on the ELFF form. The ELF process assigns these field
names to the information found in your source file.
When you enter a field name in a Data Field Names field, the prefix you
specified in the File Prefix field will be attached to the beginning of the field
name you enter. For example, if you want to name a field
D01IM2.LAST.NAME in the D01.IMPORT.FILE2 file, you would enter
LAST.NAME in the Data Field Names field. The ELFF form will attach the
specified file prefix (in the example, D01IM2) plus a period to the beginning
of the field name, making the field name D01IM2.LAST.NAME.
Note: Because the ELFF form automatically attaches the prefix to the
field name, do not enter the prefix in this column. For example, if you
want to name a field D01IM2.LAST.NAME in the D01.IMPORT.FILE2
file, do not enter D01IM2.LAST.NAME. The resulting file name will
become D01IM2.D01IM2.LAST.NAME, because the ELFF form
attaches the specified prefix plus a period to the field name you enter.
3-12
Start/End
Use the Start and End fields to define the beginning and ending position for
each field to be referenced in the source file. You can specify only certain
sections of the source file you want to reference, so leaving gaps between the
ending position of one field and the beginning position of the next field is
acceptable. Notice that in Figure 3-4 that there is a gap between field
D01IM2.SUFFIX and field D01IM2.ADDR.LINE.1. Field D01IM2.SUFFIX
ends at 101 and field D01IM2.ADDR.LINE.1 begins on 110, leaving a gap of
8.
Length
When you specify the start and end positions, the system automatically
calculates and enters the length into the Len field. However, if you know
where the field starts and you know the length of it, you can enter the start
position and length. The system then determines the end position of the field.
(Similarly, if you enter the length of a field, both start and end positions are
determined based on the end position of the preceding field.)
Trimming Spaces
From the Data Field Names field on the ELFF form, you can detail to the
Database Element Presentation (RDEP) form. See page 2-18 for information
on the RDEP form.
From the Input Prompt field on the RDEP form, you can detail to either the
Data Element Edits (RDEE) form or the Data Element Write Edits (RDEW)
form. If you detail to the RDEE form, make sure you enter S in the Trim
Spaces field. Trimming spaces from imported information, such as names,
will ensure that your Colleague fields are correct. For example, let’s say that
the last name field accepts up to 30 characters. If you import “Jones” with 25
spaces at the end, your Colleague information for that field will have the
additional 25 spaces as well. By trimming the spaces, your Colleague
information will only receive “Jones” (with no additional spaces).
3-13
Enter S in the
Trim Spaces
field
Figure 3-5: Example of Trimming Spaces Using the RDEE Form
3-14
3
2
081
,A
9
g
u
ts
In This Chapter
This chapter describes how to identify the target intermediate files needed to
receive the information from the source files. The target or intermediate files
are the temporary storage areas of the data you want to import from the source
files to Colleague.
Copying the source data into an intermediate data file instead of directly into
your Colleague database might seem like an unnecessary step, but the
intermediate files make the import process very versatile. The source-tointermediate procedures can be written and modified easily to fit a variety of
source types and data.
You can also use the intermediate files as a holding place from which you can
run queries, reports, and mailing lists even if you decide not to import the data
into Colleague.
Topic
Page
Before You Begin
3-16
Understanding the Intermediate Files
3-17
3-18
Identifying the Target Fields
3-21
Procedure for Creating an ELF Source-to-Intermediate Import
3-23
Previewing the ELF Specifications
3-24
Specifying Data Transformations
3-26
Populating Intermediate Files
3-28
Cataloging Your ELF Import
3-29
3-15
Source to Intermediate Imports: Identifying the Target Files
Before You Begin
You must define translation tables for all of the codes used in the source data
files so ELF can import the source information correctly into your database.
See “Defining Translation Tables” on page 2-45 for more information on
defining your translation tables.
Make sure you have defined your source files before trying to import the
source data into the target or intermediate files. See “Defining Source Files”
on page 3-1 for more information on defining the source files.
3-16
Importing data from an external source to your Colleague database is a twopart process. Figure 3-6 illustrates the two parts of the process.
1. Copy the information from the source media to a set of intermediate data
files, using an source-to-intermediate procedure.
2. Copy the information from the intermediate data files into your Colleague
database, using the intermediate-to-Colleague procedure.
Target or
Intermediate Files
Source
STII
Source-to-Intermediate
Procedure
Colleague
ITCI
Intermediate-to-Colleague
Procedure
Figure 3-6: Copying Data From an External Source to Colleague
The target or intermediate files receive the data from the source files. The
second part of the ELF process exports the data in the target or intermediate
files into Colleague.
3-17
Use the Source to Target Map (ELFS) form to name the actual import process
and to identify the target files.
Figure 3-7: Example of the Source to Target Map (ELFS) Form
Source and target files must already be defined in the RT.FILES file. Fields
that will be referenced in the Field Maps field must already be defined in the
RT.FIELDS file.
If the target file is an intermediate file, there can be no ambiguity in the
relationships of the intermediate records that are created from one source
record. For example, suppose a source file has the following fields:
Student Name
Parent Name
Student Test Scores
If there is an intermediate file called INTER.PERSON, and another called
INTER.TEST, and INTER.TEST has INTER.PERSON as a related file, then
both the student name and the parent name cannot map to INTER.PERSON
3-18
because the INTER.TEST record doesn’t know if it belongs to the student or
the parent. The parent name should map to some INTER.REL file, which in
turn would map to the RELATIONS file.
Naming the ELF Imports
Datatel recommends that you use the following naming convention when
naming the ELF imports:
[client number]M[three-digit number]
For example, Datatel University (D01) would name an import as D01M001.
(The “M” represents iMport.)
Enter the ELF import process name at the ELF Spec LookUp prompt on the
ELFS form. If this is a new import process name, you’ll receive a message
similar to the following:
Record not found -- Enter (A)dd or RETURN to
Reenter:
Enter A to add the new import process name to the ELF.SPECS file.
3-19
Components of Mapping Source Files to Target Files
Use the ELFS form to define the following aspects or characteristics of
mapping a source file to its corresponding target files.
Component
Description
Application
Indicate whether the import will populate Colleage Core or Colleague Student by
entering Core or ST. If you’re not sure which application to enter, or if your
import will populate both systems, enter Core.
Source File
This is the file you previously identified using the Electronic File Transfer (ELFT)
form.
Target Files
Indicate which intermediate files you want the import to populate. ELF
processes each intermediate file individually.
Process Entry
You can specify a start-up process or initialization code to be run immediately
before the main loop of the import process. Use this hook to initialize custom
variables.
Source Pre Edit
You can specify code to run after the import process reads a record but before
any field edits are performed. Source pre-edit codes can read other source file
records to pre-assign fields in the primary file, and to perform other functions.
Process Exit
You can specify code to run at the end of the process, immediately after the
main loop of the import process.
Table 3-4: Components of Mapping Source Files to Target Files
3-20
As part of identifying the target files (including naming the import), you must
also specify the target fields with the target files.
For example, you want to import personal and demographic information from
your source file (which we will call D01.DEMOG) to the Colleague PERSON
file. The intermediate file is named INTER.BIODEM. Specify the fields
within the INTER.BIODEM file to correspond to the fields of the
D01.DEMOG file.
Use the ELF Field Mapping (ELFM) form to specify the source fields with
their corresponding target fields. You can access the ELFM form directly
from a menu prompt or you can detail to it from the Field Maps field on the
ELFS form.
Figure 3-8: Example of the ELF Field Mapping (ELFM) Form
3-21
About Source Fields
The source field names are the names of the fields you defined for the source
file using the Electronic File Transfer (ELFT) form and either the Variable
File Fields (ELFV) form or the Fixed File Fields (ELFF) form. Refer to
“Defining Source Files” beginning on page 3-1 for information on defining
source files and source fields.
About Target Fields
The target fields on the ELFM form are the fields in the intermediate file that
you want populated by the corresponding source field. For example, if the
specified source field contains Social Security information that you want
imported, then the target field should be the field of the intermediate file that
corresponds to Social Security information.
Source File:
D01.IMPORT
Intermediate File:
INTER.BIODEMO
Source Field:
D01IMP.SSN
Target Field:
IBIO.SSN
Figure 3-9: Example of Source Field to Target Field
3-22
Procedure for Creating an ELF Source-to-Intermediate Import
Procedure for Creating an ELF Sourceto-Intermediate Import
Use these steps to create an ELF source-to-intermediate import. These steps
were written under the assumption that you have completed all the setup
procedures. Refer to all the chapters in the “Getting Started” part of this
manual.
Step 1. Make sure you have defined your source files.
Step 2. Access the Source to Target Map (ELFS) form.
Step 3. At the ELF Spec LookUp prompt, enter the name of the import process you
want to create.
For example, Datatel University (D01) could name one of their imports as
D01M001.
Colleague displays a message prompting you to enter “A” to add. Enter A at
this message prompt.
Step 4. Complete the ELFS form as needed.
Refer to “Components of Mapping Source Files to Target Files” on page 3-20
and online help for specific field information.
Step 5. To associate the source fields with the target fields, access the ELF Field
Mapping (ELFM) form from the Field Maps field on the ELFS form.
Step 6. Save the information from both forms.
Step 7. Catalog the import process you just created.
Refer to “Cataloging Your ELF Import” on page 3-29 for more information.
3-23
You can preview the specifications defined for the source fields and target
fields. This helps you determine the transformations that have been
predefined by Datatel for the intermediate files. Use the ELF Specification
Preview (EPVW) process to preview source and target fields specifications.
Figure 3-10 shows an example of the EPVW form.
Figure 3-10: Example of the ELF Specification Preview (EPVW) Form
The EPVW process produces a report similar to that shown in Figure 3-11 on
page 3-25.
3-24
September 26 2003
Page
1
15:53
ELF Specification Preview
Specification: INTER.BIODEMO
Process Entry Hook
-----------------$INSERT I_DEFAULTS FROM CORE.SOURCE
$INSERT I_PEND.ADR FROM CORE.SOURCE
Source Field Edits
-----------------IBIO.ADDRESS.LINES
IBIO.ADDRESS.TYPES
Convert to Upper..........: Yes
IBIO.ALT.IDS
IBIO.BATCH
IBIO.BIRTH.DATE
IBIO.BOX
IBIO.CITY
Trim Field................: Standard
Convert to Upper-case Word: Yes
IBIO.COMMUNICATION.CODES
IBIO.COMMUNICATION.DATES
IBIO.COMMUNICATION.INSTANCES
Convert to Upper-case Word: Yes
IBIO.COMMUNICATION.STATUSES
IBIO.COUNTRY
IBIO.COUNTY
IBIO.DECEASED.DATE
IBIO.DENOMINATION
IBIO.DRIVER.LICENSE.NO
IBIO.DRIVER.LICENSE.STATE
IBIO.EMAIL.ADDRESSES
IBIO.EMAIL.TYPES
Figure 3-11: Example of the ELF Specification Preview (EPVW) Report
Note: This report is a sample; the actual report produced in this run
was about 14 pages.
3-25
There is another step you should perform before importing the source data
into the intermediate files. You need to specify any data transformations that
are necessary to properly convert the source data into the intermediate files.
Use the Data Element Edits (RDEE) form to define specific data
transformations for any data element or field in the source files. Figure 3-12
shows an example of the RDEE form.
Figure 3-12: Example of the Data Element Edits (RDEE) Form
You can specify particular actions that need to be taken against the field
before it is imported into the target file.
You can also specify minor alterations to the field, such as trimming zeros or
spaces, or you can perform complex transformations using the Read Edit
Hook field. You can detail to a comments form from the Read Edit Hook field
to specify special code for an action you want performed on the field.
Ensure you enter S in the Trim Spaces field. Trimming spaces from imported
information, such as names, will ensure that your Colleague fields are correct.
For example, let’s say that the last name field accepts up to 30 characters. If
3-26
you import “Jones” with 25 spaces at the end, your Colleague information for
that field will have the additional 25 spaces as well. By trimming the spaces,
your Colleague information will only receive “Jones” (with no additional
spaces).
3-27
Populating Intermediate Files
Although you can choose which source data to import into the intermediate
files, there are certain files that Datatel recommends you should populate
depending on the type of import you want to perform. Remember, these are
only recommendations. You can import additional information for each
import, but the files listed in Table 3-5 should be the minimum information
you need to populate.
Type of Import
Demographics
Admissions
Intermediate File
Hint or Purpose
INTER.BIODEMO
INTER.INST.ATTEND
One for each college/high school attended
INTER.OTHER.ADDRESS
For additional addresses
INTER.BIODEMO
Not needed if the people are already in the system
INTER.APPLICANT
Students
INTER.APPLICATION
One per application
INTER.TEST.SCORE
One per test score
INTER.BIODEMO
Not needed if the people are already in the system
INTER.STUDENT
Curriculum
INTER.STU.PROGRAM
For additional program assignments
INTER.CREDENTIAL
For degrees earned here
INTER.COURSE
INTER.COURSE.SECTION
Credit Records
INTER.STU.ACAD.CRED or
INTER.STU.COURSE.SEC
Others
INTER.FA.AWARD
Award history
INTER.AR.RCPT
Cash receipts
INTER.AR.INVOICE
Invoices (can be used as a balance forward)
Table 3-5: Recommended Intermediate Files to Populate For Each Import
Note: If you import data for a person and you do not have the
INTER.BIODEMO file in your mapping, then you must always have a
valid Colleague Person ID for that individual (such as an
INTER.FA.AWARD or INTER.STUDENT file).
3-28
After you have created an ELF import process using the Source to Target Map
(ELFS) form, you must catalog the process in your system to create the proper
VOC pointer. Enter the following at the colon prompt.
Where ELF.SPEC is the ID of the ELF process you created on the ELFS form:
:CATALOG ELFGEN.SOURCE ELF.SPEC DIRECT
Datatel recommends using DIRECT in the query sentence if you want to
locally catalog the process. If you want to globally catalog the process,
replace DIRECT with GLOBAL.
3-29
3-30
3
2
081
,A
9
g
u
ts
In This Chapter
This chapter describes how to import the source data.
Topic
Page
Before You Begin
3-31
Understanding the Source-to-Intermediate Files Transfer
3-32
Components of a Source-to-Intermediate Import
3-33
Choosing the Source-to-Intermediate Procedure
3-35
Procedure for Importing Source Data to Intermediate Files
3-36
Before You Begin
Before you can import your source data to your intermediate files, you must
define the items listed in Table 3-7:
Define
Reference
duplicate criteria
page 2-31
Merge criteria
page 2-39
Translation tables
page 2-45
Source files
page 3-1
Target files
page 3-15
Table 3-7: Setup Needed Before Importing Data to Intermediate Files
3-31
Source to Intermediate Imports: Importing Source Data
Understanding the Source-toIntermediate Files Transfer
The source-to-intermediate file transfer is the first step in a two-step process
to import source information into your Colleague database. Running this
process in update mode populates the intermediate files. You can use the
intermediate files to generate mailings and for query purposes without
importing the data into Colleague.
The source-to-intermediate process can be run in either update or non-update
mode. In either mode, the records are processed to determine errors. If any
errors are found, ELF prints an error report. In non-update mode, the source
data is processed, but the intermediate files are not populated. You can run the
Source-to-Intermediate Import (STII) procedure in non-update mode as many
times as you need to process all of the records without error. After you have
resolved all of the errors, you can run the STII procedure in update mode,
which populates the intermediate files.
If you run the process in update mode, any source records with errors are not
added to the intermediate files and therefore are not available to be imported
into Colleague. If errors occur when running in update mode, you must rerun
the entire import after fixing the errors to import those records.
After successfully running the STII procedure in update mode, you can then
run the Intermediate-to-Colleague (ITCI) procedure to import the data from
the intermediate files to your Colleague database. See “Understanding the
Intermediate-to-Colleague Files Transfer” on page 4-2 for more information
about importing your intermediate files into your Colleague database.
3-32
Components of a Source-to-Intermediate Import
Components of a Source-toIntermediate Import
Figure 3-13 shows an example of the generic Source-to-Intermediate Import
(STII) form. You can alternatively choose one of the more specific types of
import, which are outlined in the next section. From the STII form, you detail
to each of the source-to-intermediate import procedures, which share the
following components:
batch control ID
estimated number of records
update mode
source file override
Figure 3-13: Example of the Source-to-Intermediate Import (STII) Form
3-33
Noteworthy Fields on the STII Form
The following fields are particularly important for the STII process.
Batch Control ID
The batch control ID uniquely identifies each import.
You can not reuse a batch ID if that batch has records that have been
successfully imported into Colleague. You must first purge the existing batch
using the ELF Batch Purge (EPRG) process before you can reuse a batch ID
for a batch whose records have been imported into Colleague.
See “Understanding Intermediate File Purges” on page 5-1 for more
information about purging your intermediate files.
Estimated Number of Records
If your source files are not Colleague-style files, you must estimate the
number of records to be imported. This number is also required if you want a
bar graph to display during processing that estimates completion.
Update Mode
You can run the STII procedure in either update or non-update mode. You can
run the process in non-update mode if you want to know what errors you will
encounter before actually trying to update the intermediate files. When you
are ready to update the intermediate files, you need to run the STII procedure
in update mode. In non-update mode, no records are written to the
intermediate files.
3-34
Choosing the Source-to-Intermediate Procedure
Choosing the Source-to-Intermediate
Procedure
You may want to manually set up your source-to-intermediate import,
depending on the specific type of data being imported. You can use these
source-to-intermediate procedures, which depend upon the type of external
information you are trying to import. For example, if you are importing
admissions information, you can use one of the following procedures in
Colleague Student:
ACT Student Search Tape (ACSI)
ETS Student Search Tape (ETSI)
ACT Test Scores Import (ACTI)
SAT Test Scores Import (SATI)
LSAT Test Scores Import (LSAI)
See the Using Recruitment/Admissions Management manual for more
information about these forms.
You can also use the STII form to perform a generic import.
3-35
Procedure for Importing Source Data to
Intermediate Files
Complete the following steps to import your source data into your
intermediate files.
Step 1. Familiarize yourself with the importing process.
See “Understanding Electronic File Transfers (ELFs)” on page 2-2.
Remember, this is a multiple-step process and that you must import your data
into an intermediate file before importing it into your Colleague database.
Step 2. Determine which source-to-intermediate procedure you need to use for this
import.
Step 3. Access the appropriate source-to-intermediate form (in most cases, this is the
STII form).
Step 4. Define the source file for the selected procedure.
Refer to the online process help for the procedure to identify the necessary
source files.
See “Procedure for Defining Source Files” on page 3-7 for information about
defining your source files.
Step 5. Define the file translation tables for the procedure.
See “Procedure for Defining File Translation Tables” on page 2-49 for
information about defining your translation tables.
Step 6. Access the selected procedure.
Step 7. Complete the necessary fields on the selected form.
3-36
Procedure for Importing Source Data to Intermediate Files
Step 8. Update from the form to initiate the procedure.
If there are any problems during the importing of the data, ELF produces a
report listing all errors. Otherwise, go to Step 11.
Step 9. Review the report and correct errors.
Step 10. Repeat this import procedure starting with Step 6.
Step 11. The source data is now available in your intermediate files to query reports,
generate mailing labels, or to import into your Colleague database.
3-37
3-38
Using ELF
4. Intermediate Files to
Colleague
Intermediate Files to Colleague
4
Importing Information into
Colleague
2
081
,A
9
g
u
ts
In This Chapter
This chapter describes how to import data from the intermediate file into
Colleague.
Topic
Page
Before You Begin
4-1
Understanding the Intermediate-to-Colleague Files Transfer
4-2
Procedure for Importing Information
4-5
Reading the Import Report
4-7
Before You Begin
Before you can import data from your intermediate files to your Colleague
database, you must perform the steps listed in Table 4-2:
Action
Reference
Import the external source files to the
intermediate files
page 3-36
Understand your duplicate criteria
page 2-31
Understand your merge criteria
page 2-39
Understand ELF codes
page 2-54
Table 4-2: Information Needed Before You Can Import Data
4-1
Intermediate Files to Colleague: Importing Information into Colleague
Understanding the Intermediate-toColleague Files Transfer
After you have successfully imported your source data into your intermediate
files and determined that you want to include these records in your Colleague
database, you can use the Intermediate-to Colleague Import (ITCI) procedure
to import them.
You can choose to run the process in non-update mode to manually review
and override the duplicate checking before you import records. In non-update
mode, no records are imported.
Or, you can run this procedure in update mode if you want to directly import
all non-duplicate records into your database. In update mode, any records
without errors are imported to Colleague.
In either mode, the records are processed to determine errors, warnings, and
potential duplicate records that already exist in your Colleague database.
You may want to use both methods of update mode in the following way:
1. Run the ITCI procedure in non-update mode. In this mode the duplicate
checking process reports all potential duplicate records.
2. Review the duplicates report for errors. You can use the ELF Duplicate
Resolution (EFDR) form to resolve duplicate file errors, or you can use the
ELF Target Results/Dupl Res (TGTR) process to correct other types of
errors found.
3. After correcting errors, repeat the ITCI procedure in non-update mode to
verify that all errors were corrected.
4. Once the ITCI procedure runs without errors, you can run the procedure in
update mode, at which time your Colleague files are updated with the data
from the intermediate files.
4-2
Understanding the Intermediate-to-Colleague Files Transfer
Figure 4-1: The Inter-to-Colleague Import (ITCI) Form
Each intermediate file populates one or more Colleague files. The
Intermediate Files table contains one row for each intermediate and Colleague
(target) file combination. Each row also refers to a duplicate criteria record
and a merge criteria record corresponding to the intermediate-Colleague
combination.
For example, the file INTER.BIODEMO can populate the PERSON,
ADDRESS, and MAILING files. When populating the PERSON file, ELF
uses the IBIO.PERSON duplicate criteria record to detect duplicate person
records. If a duplicate is found, ELF uses the IBIO.PERSON merge criteria
record to determine how to merge the data from the INTER.BIODEMO
record to the existing PERSON record.
You can enter a saved list or a list of specific transactions on the ITCI form
that you want to import.
You can run the ITCI procedure as many times as you need to successfully
import all of the records from the intermediate files. Records that have been
successfully imported are not processed on subsequent runs.
4-3
Duplicate Checking
The import process uses the duplicate criteria defined on the Duplicate Match
Criteria (DUPC) form. Datatel supplies standard duplicate criteria records,
but you can modify this criteria to meet your needs.
You can also enter a different duplicate criteria record for an intermediatetarget combination. If you do not want any duplicate checking done for a
particular combination, you can leave the Duplicate Criteria column blank.
See “In This Chapter” on page 2-31 for more information about your
duplicate criteria.
Merging Records into Colleague
If you run the ITCI procedure in update mode, the intermediate records that
are not found to be duplicates are imported into your Colleague database. If a
record is different from any existing records, a new record is created in
Colleague. If the intermediate file contains updates to existing information,
the intermediate record is merged with the existing record using criteria
defined on the ELF Merge Criteria (MRGC) form. Datatel supplies standard
merge criteria records that you can modify to meet your needs.
As with the duplicate criteria, you can also enter a different merge criteria
record for an intermediate-target combination. If you leave the Merge Criteria
field blank, existing records in Colleague will not be merged with the
intermediate file data. The existing Colleague data will be preserved.
See “Defining Merge Criteria” on page 2-39 for more information about
defining your merge criteria.
4-4
Complete the following steps to import information from your intermediate
files to your Colleague database.
Step 1. Familiarize yourself with the importing process.
For more information, see “Understanding the Intermediate-to-Colleague
Files Transfer” on page 4-2.
Remember, this is a multiple-step process and that you import your data into
an intermediate file before importing it into your Colleague database.
Step 2. Access the Inter-to-Colleague Import (ITCI) process.
Step 3. Review the duplicate and merge criteria for each intermediate file and target
file that will be processed.
If you have defined customized criteria, you can override the standard criteria
displayed.
Step 4. If you do not want to run the process in Update mode, enter No in the Update
Mode field, and continue with Step 5.
If you want to skip the manual review and the option to override the duplicate
checking, go to Step 10.
Step 5. Save and Update from the form.
Colleague produces a report indicating errors and warnings about possible
duplicate records. However, no records are actually imported. For information
about analyzing the error report, see “Reading the Import Report” on
page 4-7.
If the report lists no errors, then go to Step 10.
4-5
Step 6. Select the type of report you want by entering one of the following in the
Report Detail field:
D – Detailed Report
U – Unresolved Dupls Only
A – All Duplicates
Step 7. Save from the form.
Step 8. Correct any errors that are found.
For more information, see “Resolving Import Errors” on page 4-9.
Step 9. Repeat the procedure starting with Step 4 until the process runs without
errors.
Step 10. Run the ITCI process in update mode. Enter Yes in the Update Mode field.
The Colleague database is updated with the data from the intermediate files.
4-6
After you run the Intermediate-to-Colleague Import (ITCI) process, the report
process produces a report of possible duplicates or ambiguities for you to
examine. These duplicates or ambiguities result from the duplicate match
criteria you specified on the Duplicate Match Criteria (DUPC) form. For
detailed information about duplicate match criteria and the DUPC form, see
“Defining Duplicate Criteria” on page 2-31.
Components of the Import Report
The ITCI procedure generates a report showing the records that are processed,
any error or warning messages, and the target records in Colleague that are
updated or created. You can determine how detailed you want the report by
entering one of the following in the Report Detail field.
D - Detailed. Enter D for a detailed report that shows all information,
including errors and non-errors
A - All. Enter A for a report that includes all duplicates found during the
import
U - Unresolved. Enter U for a report that includes unresolved duplicates,
that is, only the duplicates that the system could not find a definite match
for in the Colleague database.
If the import process cannot determine whether a record in the intermediate
database is a duplicate of an existing Colleague record, that record is not
imported, and the ambiguity is indicated in the report. Use the ELF Target
Results/Dupl Resolution (TGTR) form to resolve the ambiguity, and then rerun the ITCI procedure. See “Resolving Import Errors” on page 4-11 for more
information about resolving your duplicate errors.
Note: The report that is generated after the ITCI procedure may mark
a record that you expected to be “New” as “Merged.” This occurs
because of the sequence of processing the records. Sometimes a new
record is created and then updated by a subsequent new record. For
example, when an application record is imported, a person record is
created along with the new application record. When the student’s
demographic information is imported, it updates this newly created
person record but, because the person record is getting updated, the
report marks it as “Merged.”
4-7
The import report displays information about a particular batch. The batch
control ID is displayed at the top of the report. The batch control ID on the
report consists of the name of the application, and the date and time when the
import was run.
You can use the batch number with the two-digit record code to access batch
information specific to one of the four available files (main, test, interests, or
institutions attended) on the ELF Duplicate Resolution (EFDR) form.
Figure 4-2 shows examples of the ITCI report. Please note that this is only a
sample showing one record; you may have several listed on your ITCI report.
4-8
4-9
INTERMEDIATE-TO-COLLEAGUE IMPORT
Batch Control: ACT97.98
Report Detail: All Duplicates
Page
Figure 4-2: Example of the Intermediate-To-Colleague Import (ITCI) Report
Transaction Status
ELF Tgt Results
Target File
Dupl Target ID
Rating Cat Actual ID/Actio
----------- -------------------- ----------------- ------------------------- ------------------------- ------ --- -------------1 Error
7954
PERSON
0003785
173 Dup (New)
0003480
173 Dup
0003379
173 Dup
0003279
173 Dup
0003179
173 Dup
0003074
173 Dup
0002904
173 Dup
0002903
173 Dup
0002902
173 Dup
0002901
173 Dup
0002900
173 Dup
0002899
173 Dup
0002898
173 Dup
0002897
173 Dup
0002853
173 Dup
0002753
173 Dup
0002653
173 Dup
0003581
163 Dup
0003681
158 Dup
7955
ADDRESS
PHA0003379
55 Dup (New)
PHA0002653
55 Dup
7956
MAILING
No duplicates detected
(Not Written)
7957
INSTITUTIONS.ATTEND
(New)
7960
STUDENT.NON.COURSES
(New)
7961
STUDENT.NON.COURSES
(New)
7962
STUDENT.NON.COURSES
(New)
7959
SECSCH.TRANSCRIPTS
(New)
7963
APPLICANTS
(New)
7964
PERSON.ST
(New)
7965
APPLICATIONS
(New)
7966
STUDENT.PROGRAMS
(New)
7958
PERSON
(New)
ERROR: File: PERSON: Ambiguity exists for ELF.TGT.RESULTS 7954
ERROR: File: ADDRESS: Ambiguity exists for ELF.TGT.RESULTS 7955
ERROR: Pre-Commit: SIN Number assigned to 0002653 Brigget L. Name001
WARNING: File: STUDENT.PROGRAMS: WARNING: STPR.STATUS contains a null. Null controller removed
October 03 2003
14:02
4-10
Intermediate Files to Colleague
4
2
081
,A
9
g
u
ts
In This Chapter
This chapter describes how to resolve any errors that may occur when you
attempt to import data into Colleague.
Topic
Page
Before You Begin
4-11
Forms Used
4-12
Understanding Duplicates and Ambiguities
4-13
Viewing the List of Potential Duplicates
4-17
About Duplicate File Resolution
4-18
Resolving Discrepancies
4-33
Before You Begin
Before you can correct errors, you must perform the steps in Table 4-4:
Action
Reference
Understand the duplicate criteria used
“In This Chapter” on page 2-31
Import source information to your intermediate
files
“Procedure for Importing Source Data to Intermediate
Files” on page 3-36
Run the ITCI process
“Procedure for Importing Information” on page 4-5
Table 4-4: Actions Necessary Before You Can Correct Duplicate Errors
4-11
Intermediate Files to Colleague: Resolving Import Errors
Forms Used
The procedure in this chapter requires access to the following forms:
Form
Purpose
ELF Duplicate Resolution
(EFDR)
List and resolve potential duplicates found
during a specific batch import process.
Resolve Person Duplicates
(ERPD)
Compare the incoming PERSON data that
may be a possible duplicate with one or more
Colleague records.
Resolve Relation Person Dupls
(ERRP)
Compare the incoming PERSON data that
Colleague records.
Resolve Address Duplicates
(ERAD)
Compare the incoming ADDRESS data that
Colleague records.
Resolve Relation Addr Dupls
(ERRA)
Colleague records.
Resolve Other Address
Duplicates (EROA)
Colleague records.
Resolve Appl Import Duplicates
(RAPD)
Compare the incoming APPLICATION data
that may be a possible duplicate with one or
more Colleague records.
ELF Target Results/Dupl Res
(TGTR)
View a list of records requiring resolution after
running the ELF import process.
ELF Transaction Tracking
(ETRK)
Trace the path of one or more transactions in
an ELF import.
Table 4-5: Forms Used to Resolve Import Errors
4-12
Understanding Duplicates and
Ambiguities
The ELF import process uses the duplicate detection criteria that you
specified on the Duplicate Match Criteria (DUPC) form before running the
import process to identify any possible duplicate records between the
intermediate files and Colleague files. Duplicate records are those records
from the intermediate files that have the same information as a record in the
Colleague file.When the duplicated detection process finds a positive
duplicate or match, the merge process will merge the file into Colleague based
on the merge criteria you specified on the ELF Merge Criteria (MRGC) form.
After you ran the Inter-to-Colleague Import (ITCI) process, you may have
unresolved ambiguities. Unresolved ambiguities are information you
imported from the intermediate files into Colleague that does not exactly
match the information you have in Colleague, but because of the duplicate
criteria you defined, identifies the data as a possible duplicate with Colleague
records.
Ambiguities occur when the Colleague record information does not correctly
match the record information the intermediate files. For example, Jane
Smith's husband’s name is John Smith, but Colleague has five John Smiths in
its database. Using the duplicate resolution forms, you can select the correct
John Smith (if the correct one is listed), or you can add a new John Smith.
The import process categorizes duplicates and possible duplicates of the
incoming records from the intermediate file. The import process analyzes the
records and compares them with the existing Colleague records, looking for
duplicates. The following is how the import process identifies or categorizes
duplicates of the incoming records:
Record x is not a duplicate of any Colleague record. A new Colleague
record is created.
Record x is a definite duplicate of an existing Colleague record. The two
records are merged based on the merge criteria defined on the MRGC form.
Record x is a possible duplicate of an existing Colleague record, but there’s
enough ambiguity between the two records that manual resolution is
needed using the duplicate resolution form.
More than one duplicate record already exists in Colleague. The incoming
record will be rejected and manual resolution is needed.
4-13
Similarly, the import process also detects ambiguities between the records of
the intermediate files and the Colleague records. The import process
categorizes ambiguities as follows:
The incoming data may have already been converted (in conversion
situations). No action is needed.
The data on the source file may be incorrect. You may have to correct the
data in the source file, then rerun the import process from the beginning.
The duplicate selection criteria specified on the DUPC form may be
inadequate, producing false duplicates. You may need to modify the
duplicate selection criteria on the DUPC form and rerun the ITCI process.
The merge criteria specified on the MRGC form may be inadequate,
producing improper merges. You may need to modify the merge criteria on
the MRGC form and rerun the ITCI process.
4-14
Overview of Duplicate/Ambiguity Resolution
The steps below show a high-level overview of how to resolve duplicates and
ambiguities. Each step refers you to another part of this manual for detailed
instructions about completing that process.
Step 1. In Colleague, access the ELF Duplicate Resolution (EFDR) form, which
shows you a list of potential duplicates. See “Viewing the List of Potential
Duplicates” on page 4-17.
Step 2. On the EFDR form, Detail on the ID of the target file that you want to resolve.
Depending on the type of target file associated with the result, you are taken
to one of the following forms:
Resolve Person Duplicates (ERPD). See “Resolving Person Duplicates” on
page 4-19.
Resolve Relation Person Dupls (ERRP). See “Resolving Relation Person
Resolve Address Duplicates (ERAD). See “Resolving Relation Person
Resolve Relation Addr Dupls (ERRA). See “Resolving Relation Address
Resolve Other Address Duplicates (EROA). See “Resolving Other Address
Resolve Appl Import Duplicates (RAPD).“Resolving Application
ELF Target Results/Dupl Res (TGTR). “Resolving Other Duplicate
Ambiguities” on page 4-27.
Step 3. Compare the information on the detail form. You can scroll through the
possible duplicates to select the one you want to combine with the imported
data.
• If you find one you want to combine, enter Yes in the Combine field.
• If you do not want to combine any of the Colleague records with the
imported data, then enter Yes in the Reject All Dupl IDs field.
• If you do not want to combine any of the Colleague records with the
imported data but you know a record ID that you do want to use, enter Yes
in the Reject All Dupl IDs field and enter the record ID in the Override ID
field.
4-15
Step 4. Repeat with each duplicate ambiguity. When done resolving all of the
duplicate ambiguities, save from the EFDR form.
Step 5. Are there other import errors?
Yes. Continue to Step 6
No. Skip to Step 7
Step 6. Detail from the Other Import Errors field to the ETRK form to view
information about other errors. Resolve the errors as necessary. See
“Resolving Discrepancies” on page 4-33.
Step 7. Save your work.
4-16
Use the ELF Duplicate Resolution (EFDR) form to list and resolve potential
duplicates found during a specific batch import process. When you access the
EFDR form, you will see a list of target results IDs that correspond to
duplicates found during the batch run. The EFDR form displays the Source
File and the Target File. The Source File field displays the intermediate file or
“storage file” which is holding the imported record.
Note: Keep in mind that imported application information is imported
to an intermediate file before it is actually imported into the Colleague
database.
You can detail from a target result ID on this form to resolve different types of
duplicate ambiguities from the following forms:
Resolve Person Duplicates (ERPD)
Resolve Relation Person Dupls (ERRP)
Resolve Address Duplicates (ERAD)
Resolve Relation Addr Dupls (ERRA)
Resolve Other Address Duplicates (EROA)
Resolve Appl Duplicates (RAPD)
ELF Target Results/Dupl Res (TGTR)
Figure 4-3: ELF Duplicate Resolution (EFDR) Form
4-17
Once you’ve accessed a duplicate resolution form from a target results ID on
the EFDR form, you can compare the incoming data that may be a possible
duplicate with one or more Colleague records. Most ambiguous information
or duplicates will likely occur for person, address or application information.
Note: From the EFDR form, you can also detail to the ETRK form to
resolve other types of duplicate ambiguities. See “Resolving Other
Duplicate Ambiguities” on page 4-27 for information about the ETRK
form.
The right side of the form contains the possible duplicate information about
the imported (source) data that resides in the intermediate file. This is the
information you need to compare with the possible Colleague duplicate on the
left side of the form.
If you do not want to combine the imported source data with any of the
duplicate records displayed, you can reject all the possible duplicates
displayed by entering Yes in the Reject All Dupl IDs field. If you enter “Yes”
in this field, the imported data is brought into Colleague as its own separate
address record.
If none of the duplicate IDs is the one with which you want to merge the
imported data, but you do know the ID of a record with which you want to
merge, you can enter that record ID in the Override ID field.
4-18
Resolving Person Duplicates
Use the Resolve Person Duplicates (ERPD) form to determine whether the
ELF records that are being imported already exist in the Colleague person
files. You can indicate which application record is the duplicate, or that there
is no duplicate.
When data is imported, it is displayed in the Intermediate Import Data area of
the form. Records in Colleague that may be possible duplicates of the source
record are displayed in the Potential Duplicates Found on the PERSON area.
Figure 4-4: The Resolve Person Duplicates (ERPD) Form
4-19
Resolving Relation Person Duplicates
Use the Resolve Relation Person Dupls (ERRP) form to determine whether
the ELF records that are being imported already exist in the Colleague person
is no duplicate.
record are displayed in the Potential Duplicates Found on the PERSON area.
Figure 4-5: The Resolve Relation Person Dupls (ERRP) Form
4-20
Resolving Relation Address Duplicates
Use the Resolve Relation Addr Duplicates (ERRA) form to determine
whether the ELF records that are being imported already exist in the
Colleague address files. You can indicate which address record is the
duplicate, or that there is no duplicate.
record are displayed in the Potential Dupls found on the PERSON/ADDRESS
area.
Figure 4-6: The Resolve Relation Addr Duplicates (ERRA) Form
4-21
Resolving Address Duplicates
Use the Resolve Address Duplicates (ERAD) form to determine whether the
ELF records that are being imported already exist in the Colleague address
files. You can indicate which address record is the duplicate, or that there is no
duplicate.
record are displayed in the Potential Dupls found on the PERSON/ADDRESS
area.
Figure 4-7: The Resolve Address Duplicates (ERAD) Form
4-22
Resolving Other Address Duplicates
Use the Resolve Other Address Duplicates (EROA) form to determine
whether the ELF records that are being imported already exist in the
Colleague address files. You can indicate which address record is the
duplicate, or that there is no duplicate.
record are displayed in the Potential Duplicates found on the ADDRESS area.
Figure 4-8: The Resolve Other Address Duplicates (EROA) Form
4-23
Resolving Application Duplicates
Use the Resolve Appl Duplicates (RAPD) form to determine whether the ELF
records that are being imported already exist in the Colleague application
is no duplicate.
record are displayed in the Potential Duplicates from the INTER/
APPLICATION area.
Figure 4-9: The Resolve Appl Duplicates (RAPD) Form
4-24
Noteworthy Fields on the Duplicate Resolution
Forms
The fields described in this section are particularly important for resolving
duplicates from the ERPD, ERRP, ERAD, ERRA, EROA and RAPD forms.
Combine
Indicate whether the application in the Potential Duplicates area is the same
application as the ELF import record in the Source Data area. Enter Yes if the
records are the same and you want to merge them. The record that is displayed
when you enter Yes here is the one that will be combined.
It is not necessary to mark all records listed as No if they are not duplicates,
but if you do enter No for a record, then it is added to a list that the system
keeps track of for this ELF import record. The record will no longer be
considered as a potential duplicate.
View (Intermediate File Name)
Details to the View Intermediate Files (VIEF) form, where you can view the
intermediate file record that is created during phase 1 of the ELF import. You
cannot modify any of the intermediate data on the VIEF form, but you can use
this information to diagnose any errors that occurred during the import
process.
Reject All Dupl IDs
Enter Yes if none of the application records in the Potential Duplicates list are
duplicates of the record being imported. This allows you to save time by
rejecting all of the records instead of marking each potential duplicate.
Enter No or leave this field blank to take no action. The records will not be
rejected.
If one of the records in the Potential Duplicates list is the correct record, enter
No or leave this field blank. If you want to mark any of the other records as
non-duplicates, you must resolve them individually by entering No in the
Combine field for each record that you want to reject.
4-25
Override ID
If you know that a duplicate application record exists in Colleague, but it
doesn't appear in the Potential Duplicates list, enter the ID of that Colleague
record in this field.
4-26
Resolving Other Duplicate Ambiguities
The information you imported during the ITCI procedure could contain
records that you already have in your database. Using the defined duplicate
criteria, ELF identifies new records that may be duplicates and does not
import them into your database. You must manually verify and correct these
records.
After running the import process, you can use the ELF Target Results/Dupl
Res (TGTR) form to view a list of the records that require resolution. This
form is particularly helpful when the imported records are not duplicates, but
are other types of duplicate ambiguities.
Figure 4-10: The ELF Target Results/Dupl Res (TGTR) Form
When you access the TGTR form, you provide a system-generated batch
name of the intermediate file record. This is the batch with which this record
is associated. You can use Batch ID LookUp which searches the ELF batch
control file (ELF.BATCH.CONTROL) for the batch name you want to use.
You must also enter the target results ID for the batch you specified. The
target results ID corresponds to each piece of data imported into a target file.
(That is, if 100 records were imported into target files, then the ELF process
4-27
created 100 target result IDs.) Each batch can have one or more target results.
You can use ELF Target Results LookUp to help you search the
ELF.TGT.RESULTS file where the target results IDs are stored.
Noteworthy Fields on the TGTR Form
The following fields are particularly important for resolving other types of
duplicate ambiguities.
Transaction
Refers to the transaction that created this target result record. This transaction
number, along with the batch ID in the ELFTGT.BATCH field of the
ELF.TGT.RESULTS file, associates this target result with the transaction
record in ELF.TRANSACTIONS that created it.
For example, if the target result record is ACSI.JAT and the transaction
number is 2, then the ELF transaction record is ACSI.JAT*2.
Record Status
Displays the current status of the target record. The ELF process maintains
this status code. Codes for this field are stored in the ELF target statuses
(ELF.TGT.STATUSES) validation code table. See “Understanding ELF
Codes” on page 2-54 for more information about these codes.
Dupl Check Date
Displays the date the duplicate match process was last run. If any duplicates
were detected, this is also the date that data in the duplicate association was
created.You can use this date as a comparison between the date the data is
loaded to the target file and the date the duplicate checking was done. Some
time may have elapsed between one and the other. If a long time has passed,
the old duplicate checking results may no longer be accurate.
4-28
Dupl Criteria
The ID of the ELF duplicate criteria file (ELF.DUPL.CRITERIA) record that
was used in duplicate checking. The system keeps this ID for historical
purposes but does not otherwise use it.
Changing this ID with the editor will NOT change the duplicate criteria used
for the purposes of determining a duplicate record.
Merge Criteria
The ID of the ELF merge criteria file (ELF.MERGE.CRITERIA) record that
was used to update an existing record.The system keeps this ID for historical
purposes but does not otherwise use it.
Changing this ID with the editor will NOT change the merge criteria used for
the purposes of determining a duplicate record.
Dupl ID
The ID of the Colleague record (stored in the ELFTGT.DUPL.ID field) which
the duplicate checking routine has determined is a duplicate of the data being
imported. Only the duplicate checking routine maintains this data. It is
entered only when that routine is able to find a match, and only if there is
absolutely no ambiguity which requires manual resolution. You can override
this ID by entering the ID of a record you determined is a duplicate in the
Override ID field.
Override ID
Allows you to enter the ID of a Colleague record that you (and not the system)
determined is a duplicate of the imported data. By entering an ID in this field,
you override the ID that displayed (if any) in the Duplicate ID field. You can
select this ID from the list of duplicate target IDs in the Dupl Target ID field.
Dupl Target ID
Displays the IDs of the Colleague records that were found to be ambiguous or
possible duplicates of the imported record. The records associated with the
IDs in this field are possible duplicates because their probability rating met or
exceeded a minimum threshold during the duplicate checking process.
4-29
Rating
The Rating field associated with the Dupl Target ID field displays the
duplicate probability rating of the corresponding ID. The value of the rating is
determined by the system using the duplicate match criteria.
For example, if the minimum threshold rating defined is 50, then the rating
value associated with the imported ID must be at least 50.
Category
The Category field displays the category assigned to the associated ID by the
duplicate checking routine. The category depends on which threshold the
rating exceeded. There are two possible categories: duplicate or possible
duplicate.
A record that has a Duplicate category received a rating that matched or
exceeded the duplicate rating defined in the Dupl Rating field on the DUPC
screen. A record that has a Possible Duplicate category received a rating that
matched or exceeded the possible duplicate rating value defined in the Poss
Dupl Rating field on the DUPC screen but was less than the duplicate rating.
For example, if a duplicate criteria has the Dupl Rating field on the DUPC
screen set at 90 and the Poss Dupl Rating field set at 55, then only those
records with a rating of 90 or higher will receive a Duplicate category. Only
those records with a rating of 55 to 89 will receive a Possible Duplicate
category.
Non-Dupl IDs
Use the Non-Dupl IDs field to manually identify a Colleague record as
definitely not a duplicate of the imported record. Review the ITCI report
listing possible duplicates, which indicates when one or more records have
ambiguities that require manual resolution.
If you determine that none of the Colleague record IDs listed in the Dupl
Target ID fields are duplicates of this imported record, then enter all of those
Colleague IDs in the Non-Dupl IDs fields. By listing these IDs in this field,
the system prevents those IDs from again being flagged as possible duplicates
the next time duplicate checking is rerun.
4-30
For example, you should have run the ITCI process in non-update mode, then
resolved any duplicates or ambiguities. By entering these IDs in this field
now, those records will not be considered possible duplicates when you re-run
the ITCI process in update mode.
However, if you enter a Colleague ID in the Override ID field, then you do not
need to enter any IDs in the Non-Dupl IDs field because duplicate checking
will not be run again.If there are many IDs in the Dupl Target IDs fields and
none of the IDs are duplicates, you could use the Reject All Dupl IDs field to
indicate that none of those IDs are duplicates. This would save you time by
not requiring you to enter all those IDs in the Non-Dupl IDs fields.
Reject All Dupl IDs
You can use the Reject All Dupl IDs field to reject all the duplicates identified
in the Dupl Target ID fields. If you enter “Yes,” then you are specifying that
none of the duplicates identified in the Dupl Target ID list are really
duplicates. If you enter “No,” than you are indicating that at least one of the
records listed in the Dupl Target ID fields may be a duplicate ID.
Use the Reject All Dupl IDs field as a shortcut to using the Non-Dupl IDs
field. Using the Non-Dupl IDs field could get tedious if you had to enter
several IDs from the Dupl Target ID fields.
4-31
Procedure for Resolving Other Duplicate
Ambiguities
Complete the following steps to resolve ambiguities:
Step 1. Access the ELF Target Results/Dupl Res (TGTR) form.
Step 2. If You know the ID of the Colleague record that matches the imported record,
then enter the ID in the Override ID field. Continue with Step 4.
If you do not know the ID of the Colleague record that matches the cross
reference, continue with the next step.
Step 3. Search through the list of IDs displayed in the Dupl Target ID fields to locate
a possible match.
If you find the ID that is a duplicate of the imported record, then enter the ID
in the Override ID field.
Step 4. If none of the information displayed in the Dupl Target ID fields is the correct
duplicate, you can either:
a. Enter all the IDs from the Dupl Target ID fields into the Non-Dupl IDs
fields.
or
b. Enter Yes in the Reject All Dupl IDs field.
Step 5. Save the information on the TGTR form.
When you have resolved all the cross references, re-run the ELF import
process for the resolved records.
4-32
The ELF Transaction Tracking (ETRK) form is used to trace the path of one
or more transactions in an ELF import. It displays tracking information about
a particular transaction within a batch. You can use this form to research
problems that occurred during an import or if you are attempting to
research errors that occurred during phase 2 of the import process.
From the Target Results field, you can detail to the corresponding duplicate
resolution form, where you can view more information about the target
results.
Figure 4-11: The ELF Transaction Tracking (ETRK) Form
4-33
Noteworthy Fields on the ETRK Form
The fields described in this section are particularly important when tracking
ELF transactions.
Intermediate File
You can use this field to detail to the View Intermediate Files (VIEF) form,
which displays information about ambiguities and other errors for the current
transaction. From the VIEF form, you can additionally detail to the View
Intermediate File Detail (VIED) form, where you can view the multivalued
data that is contained in a specific field of an intermediate file record.
Phase 2 Errors
Detail on this field to view the list of duplicates for this transaction, which do
not display on the ACIE form.
4-34
Using ELF
5. Purging
Purging
5
2
081
,A
9
g
u
ts
Understanding Intermediate File
Purges
After you have successfully imported your source data into your Colleague
database and no longer need the intermediate files, you can purge the files
using a purge process. You can also use the purge process if you have
imported data into the intermediate files in error.
Use the ELF Batch Purge (EPRG) form shown in Figure 5-1 to purge an ELF
batch and the associated records in the intermediate files. The form prompts
you for a batch control ID. When you finish from the form, ELF purges the
batch and the transaction files and records in the intermediate files associated
with the batch.
Figure 5-1: Example of the ELF Batch Purge (EPRG) Form
5-1
Purging: Purging Intermediate Files
Procedure for Purging Intermediate
Files
Complete the following steps to purge your intermediate files of obsolete
records.
Step 1. Familiarize yourself with the ELF purging process.
See “Understanding Intermediate File Purges” on page 5-1
Step 2. Access the ELF Batch Purge (EPRG) form.
The EPRG form displays with the cursor at the Batch ID LookUp prompt.
Step 3. Enter the ID of the batch you want to delete from your intermediate files.
Step 4. Enter Y in the Delete Batch field.
Step 5. Update from the EPRG form.
ELF purges the selected batch, including transaction files and records in the
intermediate files associated with the batch.
5-2
Using ELF
6. ELF Export
ELF Export
6
2
081
,A
9
g
u
ts
Understanding the Export Process
The ELF export process is similar to the ELF import process described in the
previous chapters. However, there are two significant differences:
While the import process involves two stages (source-to-intermediate and
intermediate-to-Colleague), the export process is a one-stage process
(Colleague-to-target).
The ELF import process can involve many source files, intermediate files,
and Colleague files. However, an ELF export involves copying one
Colleague file to a one or multiple target file(s).
Several Source Files
Several Intermediate Files
Several Colleague Files
Figure 6-1: Example of Files Involved in ELF Import Process
One Colleague File
One or Several Target File(s)
Figure 6-2: Example of Files Involved in ELF Export Process
Procedurally, the export process (Colleague-to-target) is the same as the
import’s source-to-intermediate process.
6-1
ELF Export: Exporting Data Using ELF
Before You Begin
When using the ELF process to export a file from Colleague to an external
file, you need to understand the terminology (or differences in terminology)
between the import and export process.
Chapters to Use
All chapters in this manual are valid for an ELF export process with the
exception of the following:
“Importing Information into Colleague” on page 4-1
“Purging Intermediate Files” on page 5-1
How to Use the Correct Chapters
This manual was written describing an import process. When using the
procedures in this manual to perform an export, substitute the following while
using the procedures.
If the ELF Import Process says…
then substitute the following for an ELF Export
Process
Source file
Colleague file
Intermediate files
external file or files
Table 6-1: Substituting Terminology Between Import and Export Processes
Note: Remember, for an export process, your “source” file is your
Colleague file.
6-2
ELF Export Form
ELF Export Form
In addition to the procedures described in this manual, you will also use the
ELF Export (ELFE) form to perform your export from Colleague to a target
file. The ELFE form lets you process an ELF export without building an
Envision procedure or front-end form to run the export.
Note: Do not use the ELFE form to process intermediate-toColleague imports. Also, do not use the ELFE form to run any Datateldelivered export.
The ELFE form is designed to perform simple, “generic” exports. Figure 6-3
shows an example of the ELFE form.
Figure 6-3: Example of the ELF Export (ELFE) Form
In the example shown above, we had defined the ELF specification
(D01M002) using the Source to Target Map (ELFS) form as shown in
Figure 6-4 on page 6-4.
6-3
Figure 6-4: Example of the Source to Target Map (ELFS) Form
(We had previously defined the target file (TDB.FILE) using the Electronic
Transfer File (ELFT) form, and defined the target file’s fields using the Fixed
File Fields (ELFF) form since TDB.FILE is defined as a fixed file.)
This is the same way you define source and target files for an import. This
reconfirms the similarity between the ELF import process and ELF export
process.
6-4
Procedure for Exporting Data Using ELF
Procedure for Exporting Data Using
ELF
Use these steps and the references to which they refer to perform an ELF
export.
Defining Your Parameters
Step 1. Identify the Colleague data you want to export.
Step 2. Define the translation tables needed by to perform the ELF process using the
File Translation Tables (FLTT) form.
For more information, see “Defining Translation Tables” on page 2-45.
Constructing Your Export Process
Step 1. Define your target file using the Electronic File Transfer (ELFT) form.
You can detail to one of the following forms from the ELFT form to define
fields for a variable length file or fixed length file:
Step 2. Construct your Colleague to target file export using the Source to Target Map
(ELFS) form.
You must also catalog your file specification to create a VOC pointer.
For more information, see “Identifying the Target Files” on page 3-15.
6-5
Exporting Colleague to Target
Step 1. Export the Colleague data to the target files.
On the ELF Export (ELFE) form, use the file specification you gave the
import when you created the procedure (such as D01M002).
For more information, see “Importing Source Data” on page 3-31.
6-6
Using ELF
Index
Index
A
D
ACSI procedure 3-35
Data Element Edits (RDEE) screen
mapping process and 2-18
specifying data transformations 3-26
ACT Student Search Tape (ACSI) procedure 3-35
ACT Test Scores Import (ACTI) procedure 3-35
ACTI procedure 3-35
Address duplicates
procedure for resolving 4-27
resolving 4-18
Ambiguities
resolving 4-27
ambiguities
understanding 4-13
B
Batch control ID
naming convention 4-8
Batch ID
naming convention 4-8
data, exporting using ELF 6-5
data, specifying transformations of 3-26
Database Element Presentation (RDEP) screen 2-18
defining fields
fixed length file 3-11
variable length file 3-8
duplicate category codes 2-54
Duplicates
resolving 4-27
duplicates
understanding 4-13
duplication checking 4-4
criteria 2-32
duplication criteria, defining 2-38
blocks, in source file 3-6
duplication rating, determining 2-32
C
E
cataloging import process 3-29
electronic file transfers, overview 2-2
CELF screen 3-6
Electronic Transfer File (ELFT) screen 3-2
Codes
duplicate categories 2-54
ELF file types 2-54
ELF merge actions 2-55
ELF run modes 2-55
ELF target statuses codes 2-55
ELF transaction status 2-57
ELF transfer statuses 2-58
ELF translate action codes 2-58
ELF update actions 2-59
value error actions 2-59
verifying tables and files 2-60
worksheet 2-64
ELF Batch Purge (EPRG) screen 5-1
criteria, duplication checking and 2-32
Custom ELF File Access (CELF) screen 3-6
ELF codes
target statuses 2-55
transaction status 2-57
transfer statuses 2-58
translate actions 2-58
update actions 2-59
value error actions 2-59
ELF duplicate catetgory codes 2-54
ELF Export (ELFE) screen 6-3
ELF Field Mapping (ELFM) screen 3-21
ELF file type codes 2-54
ELF import
creating 3-23
naming 3-19
ELF merge actions codes 2-55
ELF Merge Criteria (MRGC) screen 2-39
Index - 1
Index
ELF module, features of 1-6
ELF run modes codes 2-55
ELF Specification Preview (EPVW) process 3-24
ELF specifications, previewing 3-24
ELF Target Results/Dupl Res (TGTR) form 4-27
intermediate files
importing 4-5
populating 3-28
intermediate-to-Colleague transfer, understanding
4-2
ELF Transaction Tracking (ETRK) form 4-33
L
ELFE screen 6-3
logical prefixes 2-26
ELFF screen 3-11
M
ELFM screen 3-21
ELFS screen
exporting data 6-4
identifying target files 3-18
mapping
procedure 2-28
source files to target files 3-20
spreadsheets 2-25
ELFT screen 3-2
merge actions codes 2-55
ELFV screen 3-8
merge criteria, defining 2-44
EPRG screen 5-1
merging records 4-4
EPVW process 3-24
MRGC screen 2-39
ERAD form 4-18
P
ETS Student Search Tape (ETSI) procedure 3-35
ETSI procedure 3-35
F
File Element Inquiry (RFEI) screen 2-18
File Translation Table (FLTT) screen 2-45
file translation tables
procedure for defining 2-49
special processing fields 2-48
worksheet for defining 2-51
file type codes 2-54
files, populating intermediate 3-28
Fixed File Fields (ELFF) screen 3-11
fixed length files
characteristics 3-5
defining fields 3-11
FLTT screen 2-45
Forms
ELF Target Results/Dupl Res (TGTR) 4-27
ELF Transaction Tracking (ETRK) form 4-33
Resolve Address Duplicates (ERAD) 4-18
I
Person duplicates
procedure for resolving 4-27
Procedure for Resolving Person or Address
Duplicates 4-27
Procedures
ACT Student Search Tape (ACSI) 3-35
ACT Test Scores Import (ACTI) 3-35
creating an ELF import 3-23
defining a field of a variable length file 3-11
defining source files 3-7
ETS Student Search Tape (ETSI) 3-35
exporting data using ELF 6-5
importing data from intermediate files to
Colleague 4-5
mapping data 2-28
resolving duplicates and ambiguities 4-32
SAT Test Scores Import (SATI) 3-35
Q
query sentence
cataloging ELF import process 3-29
finding field information 2-22
verifying code files 2-62
verifying code tables 2-60
imports, naming 3-19
Index - 2
Index
R
RDEE screen
RDEP screen 2-18
records, in source file 3-6
Resolve Address Duplicates (ERAD) form 4-18
Resolving
ambiguities
procedure 4-32
duplicates
procedure 4-32
Resolving Address Duplicates 4-18
Resolving ambiguities 4-27
Resolving duplicates 4-27
RFEI screen 2-18
run modes codes 2-55
S
SAT Test Scores Import (SATI) procedure 3-35
SATI procedure 3-35
Screens
Custom ELF File Access (CELF) 3-6
Data Elements Edits (RDEE)
Database Element Presentation (RDEP) 2-18
Electronic Transfer File (ELFT) 3-2
ELF Batch Purge (EPRG) 5-1
ELF Export (ELFE) 6-3
ELF Field Mapping (ELFM) 3-21
ELF Merge Criteria (MRGC) 2-39
ELF Specifcation Preview (EPVW) 3-24
File Element Inquiry (RFEI) 2-18
File Translation Table (FLTT) 2-45
Fixed File Fields (ELFF) 3-11
Source to Target Map (ELFS)
exporting data 6-4
Source-to-Intermediate (STII) 3-33
Variable File Fields (ELFV) 3-8
source fields 3-22
source files
custom 3-6
defining 3-7
fixed length characteristics 3-5
location or directory 3-4
procedure for defining 3-7
records and blocks 3-6
tape characteristics 3-4
understanding 3-2
variable length characteristics 3-5
Source to Target Map (ELFS) screen
exporting data 6-4
source-to-intermediate (STI) procedure 3-32
Source-to-Intermediate Import (STII) screen 3-33
spreadsheets, mapping 2-25
STI procedure 3-32
STI procedure, types of 3-35
STII screen 3-33
T
target fields
about 3-22
identifying 3-21
target files
identifying 3-18
target statuses codes 2-55
TGTR form 4-27
transaction status codes 2-57
transfer statuses codes 2-58
translate action codes 2-58
U
update action codes 2-59
V
validation code worksheet 2-64
value error action codes 2-59
Variable File Fields (ELFV) screen 3-8
variable length files
characteristics 3-5
defining fields 3-8
procedure for defining fields 3-11
Index - 3
Index
W
worksheets
file translation tables 2-51
validation code tables 2-64
Index - 4