CrossRoad - New pages [en]

For Financial Aid

2016-03-07T16:36:56Z

WikiSysop:

= EAS Financial Aid Setup =

== Financial Aid items ==

EAS Applications, Web Aid editing is how these are modified.

The type and typesequen fields are used to order the presentation of the items.

The title and descript fields are usually abbreviated versions of what appears in the Calendar.

Criteria are derived from the Calendar entry.

Requires is intended to indicate the additional materials or statements needed for the item.

Finaidid is the link to the CrossRoad item. This means that all the items must exist in CrossRoad prior to being added in Web Aid.

FORMFIELD is a name for the html field. These must be unique.

SUBFIELDOF and PARENTOF is allows the specification of parent and child awards; currently King's has none of these.

Requirefld specifies fields that must be present when this award is selected. Most common are statements (OTHER:nameofstatement), financial information (FININFO:NONEED!~FININFO:SAVINGS). Note that these are preceded by the section of the application, are in a tilde delimited list, and a ! means that it absent.

== Need Workbook ==

These are kept in u:\crossroad\needform and have the year inserted in the name.

The last two tabs are data exchange tabs. Data should have all but the extra row numbers blanked out.

The following tabs need to have updated values added each year:

Tuition, Fees, Books
Moderate Standard of Living
Minimum Student Contributions
Childcare
Return Transportation
Allowable Monthly Costs

Assessment form contains all the formulas. Should there be a calculation required the change should be made in the first data column and copied across.

== Clearing Old Applications ==

This is best done in a database tool (Data Architect) and requires zapping two tables. FAPPLICS.DBF (FAPPLICS.NTX) holds the application data except for selected aid items and statements. FAPPITEM.DBF (FAPPITEM.NTX) holds the selected items.

FAPPNOTE.DBF (FAPPNOTE.NTX) holds the various statements submitted by applicants. This could be zapped as well, but if it is left intact, students can reuse prior year statements.

== Enabling Applications ==

EAS Applications, Release Editing, change the following to the appropriate values:

FINAID.REL -- two CrossRoad standard date in a tilde delimited list as the start and end of the application period. 01/02/2016~31/03/2016~
FINAPPNM.REL - The name for the financial aid application.
FINSTMT.REL - a pipe (|) and tilde delimited lists of possible statements. The left of the pipe is the field name; the right is the html description.
FINTAB.REL - a list of the Tabs and icons associated with the tabs of the financial aid application.

CHECKLST.REL - FIN2016/17~
StuMenu.rel - FIN2016/17~

EAS Applications, HTML Editing, update the following to the appropriate values:
FinApp.htm - Financial aid application head note.
FinDecl.htm - Declaration for the financial aid application.
FinExp.htm - note explaining our use of PoA values in our calculations.

= EAS Financial Aid Receiving =

== Match ==

Match File# fills in the Entcode field. The match process assists with this, but the number can manually be filled in if necessary.

== Print/File and Move ==

The applications are next to be printed and moved. The printing is to a PDF; the move is taking the data from the application and moving it into CrossRoad. In that process the financial need file is exported.

The resulting PDFs should be a) copied to a temporary folder for consolidation and b) filed in CrossRoad.

== Import to Need Workbook ==

Financial Need data should be copied from the resulting needfile.csv. This goes onto the final tab of the workbook at the bottom of the list. Duplicates are highlighted in RED (usually these are due to a student revising his/her application); because of the large number of linked formulas, it is best to copy and paste all the data up over the first of the duplicates rather than deleting that row.

The CSV file should be date stamped after import.

= EAS Financial Aid Need Importing =

The Financial Need Workbook calculates the need values for each student. This needs to be audited for errors (such as incorrect province codes, or non-numeric in numeric fields).

Once these are fixed, then the data on the NeedToCr tab needs to be sent to a CSV file. That file is imported into the need2cr.dbf (need2cr.ntx) table. That table then needs to have its values overwrite those in scholars.dbf.

= Consolidated PDFs =

The copies of the applications for consolidation can be merged into a single pdf (using a PDF merge tool). The arrangement of these should be in a useable order.

Alternatively, it would also be possible to place these documents into a SharePoint folder for use during meetings. I suggest a separate library so that searching can be isolated to that library.

Scan for Term Entries

2016-02-01T15:39:35Z

WikiSysop: New page: This process should not be needed if the current students process is run regularly after each add/drop deadline. However, if a record is archived with excess term records, which appear as ...

This process should not be needed if the current students process is run regularly after each add/drop deadline. However, if a record is archived with excess term records, which appear as empty terms on the transcript, this process should be used. Similarly, missing term records will omit terms on the transcript. Retrospective data entry will sometimes create that situation.

To run this, from the main menu choose Utilities > Archive Maintenance > Scan for Term Entries. The next dialog is a prompt about whether you are ready to proceed. Once you click yes, it will remove these empty term records. Records with a comment code generate a query; usually these records should be retained as they contain comments about degree conferral in a term when the student was not present.

Term Records And Transcript Comments

2016-02-01T15:32:46Z

WikiSysop:

A term record is created on the first registration in a given term by a student. It captures their degree information at that moment -- note that this may not be correct if they are applying to a subsequent program and registering early.

Term records are where transcript comments are stored. These are viewable through the term records tab in either current students or alumni.

These records are usually deleted when a student is deregistered entirely from the term. However, web registration, and batch unenrolling from Course Offerings will sometimes leave excess records that need to be removed. There are processes in both Current Students and Archived Students for managing this; the current student version should be run after each add/drop deadline.

Scanning For Missing Or Redundant Records

2016-02-01T15:31:18Z

10.111.15.12: New page: = Scan Term Records = After each registration period (i.e. after the add/drop deadline for the term) it is necessary to run the Scan Term Records process. This removes any term entries f...

= Scan Term Records =

After each registration period (i.e. after the add/drop deadline for the term) it is necessary to run the Scan Term Records process. This removes any term entries for a student who registered at some point but did not remain in classes after the add/drop deadline.

To run this, in the Current Students Window from the menu choose Students > Global Processes > Student Related > Scan Term Records. The next dialog is a prompt about whether you are ready to proceed. Once you click yes, it will remove these empty term records. Records with a comment code generate a query; usually these records should be retained as they contain comments about degree conferral in a term when the student was not present.

There is a parallel process under the main menu Utilities > Archive Maintenance for those records for archived students. If the current students process is being carefully followed, it should not be necessary to run the archives version regularly. However, if a student was archived prior to the current students process being run, this will tidy up those records too.

Clear Account Detail

2016-01-18T15:30:13Z

10.111.15.12: New page: Prior to each term, Accounts Receivable data should be cleared. This should also be done prior to generating T2202A and T4A data. The process is invoked from the Current Students window, ...

Prior to each term, Accounts Receivable data should be cleared. This should also be done prior to generating T2202A and T4A data.

The process is invoked from the Current Students window, using the menu items Students | Global Processes | Accounts Receivable | Clear Accounts Receivable Records.

A dialog asking for an academic year and term will appear; only records with that year and term entry will be removed. Records are moved to the historical AR files. If a history file for that year and term does not yet exist, one is created. If it does exist, the records are added to it.

These are viewable using the history button on the AR tab of Current Students.

Miscellaneous Sales

2015-09-08T18:31:16Z

WikiSysop: New page: Miscellaneous Sales is a program that allows the sale of various items to various categories of purchaser. The categories of purchaser are * employees * residence students * current stu...

Miscellaneous Sales is a program that allows the sale of various items to various categories of purchaser.

The categories of purchaser are

* employees
* residence students
* current students
* alumni

These are not wholly exclusive but are driven by the varying requirements of specific purchases.

The available purchases are controlled by miscsale.dbf (miscsale.ntx).

<table>
<tr><th>Field</th><th>Description</th></tr>
<tr><td>APPLIES</td><td>This determines for which purchaser group the transaction is available. R is residence, C is current students, A is alumni, E is Employee</td></tr>
<tr><td>TRANNAME</td><td>This is the name of the transaction as it appears in the program.</td></tr>
<tr><td>ITEMCODE</td><td>This is the itemcode as it exports to Sage. This should also match the support table QIFEES.DBF</td></tr>
<tr><td>OPTIONS</td><td>This defines options for this purchase. Items are separated by a tilde, with elements within the item delimited by a piping character. The sub element items are the name as it appears in the program, the specific item code for the sub item, an optional condition for the sub item, and an amount associated with that item code. The conditions are largely associated with residence items and may be a specific occupancy (DOUBLESING:[occupancy code] or MEALPLAN:[mealplan code]). The amount can be replaces with the QIFEES.DBF entry to allow for synchronization, but note that updates to QIFEES are immediately reflected.</td></tr>
<tr><td>MULTIOPTIO</td><td>This logical flag defines whether multiple options can be selected for this item. If set to false only one option may be selected.</td></tr>
<tr><td>ALLOPTIONS</td><td>This forces all the options to be selected. So if an individual transaction has multiple components (rent and a deposit, for instance) both are required.</td></tr>

<tr><td>INVOICE</td><td>This creates an invoice transaction rather than a DN.</td></tr>
<tr><td>OCCCHANGE</td><td>This flags the item as an occupancy change in residence, which triggers updating CrossRoad occupancy.</td></tr>
<tr><td>MPCHANGE</td><td>This flags the item as an mealplan change in residence, which triggers updating CrossRoad mealplan and exports to the cafeteria systems.</</td></tr>
<tr><td>MPSALE</td><td>This flags the item a mealplan sale, which triggers updating the export amounts to go to the cafeteria system. This is not necessary for Mealplan change items.</</td></tr>
<tr><td>PARKING</td><td>Flags this items as a parking pass sales, triggering the vehicle data collection window.</td></tr>
<tr><td>PCOUNTER</td><td>Flags the items as a balance addition for PCounter, triggering the command line addition to the PCounter balance.</td></tr>

<tr><td>EMAIL</td><td>Flags this transaction as requiring an email.</td></tr>
<tr><td>EMAILADDR</td><td>This is the email address to which the item should be sent.</td></tr>
<tr><td>EMAILSUBJ</td><td>This is the email subject line</td></tr>
<tr><td>EMAILBODY</td><td>This is the email body. Macro substitution can happen in the body: enclosed in double square brackets, you may substitute SURNAME, FNAME, STUDID, ENTCODE, ADDRESS, VISITORNAME, AMOUNT. Specifying Visitor Name will trigger a dialog to collect it; this is used where an employee is sponsoring a visitor for facilities use such as the WORKOut Centre.</td></tr>
</table>

Lockers

2014-09-17T17:45:11Z

68.150.166.67: /* Further Processes to be developed */

Locker Registration has been added to CrossRoad Online Services for Students. The first registered locker for each student is also displayed on the address tab of the Current Students window.

= Process =

There are two modes in which students may register a locker:

1. QR Code Scanning. A QR code sticker has been placed on each locker that directs the scanning device to the web process for locker registration. If the locker is available, the student is asked for his/her student ID and PIN.

2. Online Services. In online services, students may choose the locker registration item, and then select the locker from the drop down list.

In both modes registering a locker releases any other locker registration. In the second a student can simply release his/her locker.

= Viewer =

For a number of staff, a viewer application has been created. This url should not generally be advertised or linked, although it is protected by active directory userids and passwords.

= Support Tables =

There are three support tables that are used in the Locker Registration Process.

Lockers.dbf (index lockers.ntx) - this is the list of lockers. The in_service field could be used to remove a locker from the active inventory. For example, if a locker is out of service for repairs, this field would remove it from being able to be registered.

LockReg.dbf (indexes lockr1.ntx, lockr2.ntx, lockr3.ntx, lockr4.ntx) - this is the list of locker registrations. The entcode links this to a student, or in some cases employee. The locker id matches that from Lockers.dbf. Reg_on and Reg_at record the date and time the student registered the locker. Rel_on and Rel_at record the date and time the locker was released.

LockVUsr.dbf (index lockvusr.ntx) - this records the active directory userids of those permitted to access the viewer. This should all be uppercase. Note that password testing is done against AD.

= Troubleshooting =

The support tables can be directly viewed and edited, although that should be done with caution. Some examples of issues that have arisen so far are:

* duplicate registrations. Due to a couple of bugs from out of scope use-cases, duplicate registrations were possible. This was due to a) inadvertant lowercasing of locker codes and b) a fix for a that made lockreg entries appear to be out of order for individual students, giving access to lockers that were actually registered. In both cases, the cgi was fixed to repair.

* allocating lockers to departments. Lockers are allocated to the cafeteria and to the library. The registrations for those were done by adding records to lockreg using the departmental file number.

* deallocating lockers from departments. When a locker is to be deallocated from a department, simply fill in the REL_ON and REL_AT fields for that departments locker entry in lockreg.dbf

= Further Processes to be developed =

A process in CrossRoad, Students > Global Processes > Address Related, exists to clear all locker registrations.

[[Main Page]]

Confirmation Appointments

2014-08-11T18:34:17Z

10.111.0.117: /* Notifying Students and Other Tasks: 30 days prior to confirmation */

Current to 11 August 2014, 2014/15 Fall Academic Term

Starting 15 days prior to the start of the fall or winter term, students are able to sign up for a confirmation appointment. The implications are as follows:

1. Current Students, good academic standing: an confirmation appointment is created.

2. Current Students, not in good standing: an confirmation appointment is created, and an advisor appointment is created 30 minutes prior.

3. All New Students: an confirmation appointment is created, an advisor appointment is created 30 minutes prior, a res move in appointment is created 30 minutes after.

== Setup: 45 days prior to the start of term==

1. Delete previous appointments

a. EAS, File, Webappt editing

b. File, purge old appointments

2. Create a new appointment series

a. File, create appointment series

b. Select start and end dates

c. Select start and end times

d. Enter the number of appointments

'''Note: You can do multiple days at once, but they all must have the same number of appointments.'''
'''To increase the number of appointments in a time slot, this must be manually done.''''

3. Auto Exclude advisors

a. File, Auto Exclude advisors

b. Enter in year and term

c. Enter in start and end days

Note: This needs to be updated just prior to students starting to sign up for appointments.

4. Email advisors to log in and book off the time they are not available during official confirmation days.

== Notifying Students and Other Tasks: 30 days prior to confirmation==

Prep

1. Adjust the release file entries:

APPTACAD.REL (academic standings that require advisor appointments)

APPTVALI.REL (which controls new and returning access to particular days see below, the second #2)

APPTYT.REL (which controls which year and term appointments are for – particularly, students need to be registered for this year and term before they can make an appointment)

2. Edit the HTML File entry: (in EAS HTM editing)

WEBAPPT.HTM which is the body of the email that goes to students for their appointment. The key thing for this is to edit the orientation date.

1. Email all students to sign-up for appointments

2. In EAS Release File, Apptvali.rel: change the dates to restrict who can book appointments when (ie. this limits new students only on certain days)

NEW:20140827~ (only new on aug 27)

RET:20140828~ (only returning on aug 28)

NEW:20140829~ (Both on aug 29)

RET:20140829~ (Both on aug 29)

3. Monitor Advisors to see who has booked themselves off for long periods of time, especially for the confirmation days.

a. U:\crossroad\dbf.mm\WEBAPEX2 KEELER~ > l:\advisorappointments.htm, then open junk.htm in firefox.

b. For those who are gone, contact them and their dean to provide you with substitute advisors then enter them: U:\CROSSR~1\DBF.MM>u:\fox\dbu SUBADVIS, hit esc, then select f5 database, then F6 Zap will remove all entries in the table, F5 adds

== Turning on Appointments: 15 days prior to Registration Confirmation ==

In EAS Release File:

1. CHECKLST.REL - add ADDR014~ and INFORELEASE014~ (the 14 refers to the number of days that, once passed, it will show up in the checklist). By default, the info release and address update must be done 30 days prior to making an appointment and 30 days prior to confirmation. This can be left in place all the time, although it might be wise to increase the number of days during the terms.

2. CHECKLST.REL - add WEBAPPTyyyy/yyt~ This makes a checklist entry for Registration Confirmation Appointment in a term. This should be added only when turning on appointments. This will add an appointment entry to the checklist that either displays an existing appointment or invites them to make an appointment.

3. STUMENU.REL - add WEBAPPT2014/151~ This actually makes the appointments appear on student menus.

4. APPTYT.REL - Add appropriate year and term (2014/151~)

Admissions Reports

2014-07-11T23:01:12Z

10.111.2.77: /* 4. Profile Reports - Christian Affirmation, Denominational Origin, Geographic Region, High School Origin, Initially Heard */

== Running Weekly Admission Reports ==

=== General Comments ===

1. Stats are run every Friday, except over Christmas

2. If King's is closed on the Friday, then run the reports on Thursday, but change your King's System Date to the Friday

'''Fall Stats'''

1. Are run every week starting the first Friday in December to the Add/Drop Deadline in September

2. Run an Official Fall Stats a second time, the follow week, once Fall Appeals are complete. Check with the Associate Registrar, change your system date to the add/drop deadline

'''Winter Stats'''

1. Are run every week starting the second Friday after the add/drop deadline in September, around September 20, to the add/drop deadline in January. This means from December and January, you are running both the Fall and Winter stats each week.

2. Run an Official Winter Stats a second time, the follow week, once Winter Appeals are complete. Check with the Associate Registrar, change your system date to the add/drop deadline.

=== Preparation ===

In the Admission Reports folder

1. Create a new folder with last weeks date, YYYYMMDD

2. Copy last weeks reports into the new folder

3. Open current students

=== 1. Progress Of Application ===

-File, Print, Application, Progress of Application

a. "Enter Year and Term" Pop-up: Enter in year and term, deselect the start date, click ok

b. "Select programs to exclude" Pop-up: Select {CMTY CHRS}, click ok

-this excludes all students registered in Community Chorus

c. "Restrict by Courses" Pop-up: type in term stats filter, arrow down key, click use

-this removes students on academic leave

d. "Enter Date" Pop-up: This should automatically default to the date before the first day of classes, click ok

e. "Enter date from which to start the report" Pop-up: For the fall, this is the first Friday in December, for the winter, this is the second Friday after the add/drop deadline in September, around September 20.

f. Print the the document to PDF and save it over last week's report in the Admission Reports Folder

g. "Save Data" Pop-up: Yes
-Clicking yes creates a new date entry and should only click by the person official running the weekly reports on the Friday the report is officially run

h. "Print Group Lists" Pop-up: only if you want detail listing from the report

Special Notes about this report

i. Everything left of and including Admitted should equal Total Applications

ii. Everything left of and including New Reg'd Paid should equal Admitted

iii. After June 15, Returning Reg'd and Students Paid should be the same

iv. New Reg'd and Returning Paid should equal Total Reg Paid

=== 2. Applications Received ===

-File, Print, Application, Application Received

a. "Enter Year and Term" Pop-up: Enter the year and term, change start date to the start date for the term, as described in Progress of Application, bullet e.

b. Print the the document to PDF and save it over last week's report in the Admission Reports Folder

Special Notes about this report: none

=== 3. Profile Reports - Program Interest ===

- File, print, profile report

a. "Profile Section" Pop-up: Select Applicant records for a given term, enter in the year and term, click ok

b. select Program Interest, click ok

c. Print the the document to PDF and save it over last week's report in the Admission Reports Folder

Special Notes about this report
i. This profile MUST be run independently, if not, it will double the number of students

ii. If there is an entry *Unknown Program*, there is an applicant who has a blank program. Rerun the report, click the Print Detail button to get the student's name. Identify the program they applied for and enter it, then rerun the report.

=== 4. Profile Reports - Christian Affirmation, Denominational Origin, Geographic Region, High School Origin, Initially Heard ===

These are the same as running the profile report. All of them can be run at the same time (hold the Ctrl button and click each one)

Special Notes about these reports

Christian Affirmation - None

Denominational Origin - *Unknown Denomination*: Once a month, print this report in detail and send the Unknowns to Karen to fix.

Geographic Region - Any Unknowns: Once a month, print this report in detail and send the Unknowns to Henry to fix.

High School Origin - To be added: Once a month, print this report in detail and send to Karen to fix

'''NOTE: All these must be fixed when you run Official Stats for any term.'''

=== 5. Profile Reports - Residence Accommodation ===

- Run this report for the Fall only, starting when Student life starts accepting applications for the upcoming fall (sometime in Feb/March)

- File, print, profile report

a. "Profile Section" Pop-up: Select All applicant and student records, enter in the year and term, click ok

b. Select Residence Accommodation, click ok

c. Print the the document to PDF and save it over last week's report in the Admission Reports Folder

Withdrawing Applications

2014-06-11T22:58:17Z

Rtoews:

A student may withdraw their application at different stages of the application process. Following proper procedure ensures the student appears in the progress of applications in the appropriate column.

== '''For a student to withdraw their application:''' ==

Sample Auto Text

I’m sorry to hear that you won’t be attending King’s next year, I understand that it’s a very difficult decision to make.

In order for us to withdraw your application we require official notification from you. This can be done in 1 of 2 ways:

1. You can log into your Apply Alberta Account [https://www.applyalberta.ca/pub/app_process.asp?ApplyInstitution=48011000] and put a Stop Application on your King’s application.

2. You can send over a signed note requesting your application to be withdrawn. This can be mailed, scanned and emailed to myself, or faxed to 780-465-8321.

== '''Withdrawn before ready for decision:''' ==

Mark the file ready for decision,

File Status= Withdrawn;

Admission Status= Withdrawn;

Admission Decision= left blank;

Admission Date= Left blank;

Advisor= left blank

== '''Withdrawn after an admission decision is made:''' ==

File Status= Withdrawn;

Admission Status= Withdrawn;

Admission Decision= Blank out;

Admission Date= update to date of withdraw;

Advisor= Blank out;

If the student has a scholarship, delete the scholarship.

== '''Student Never Officially Withdraws''' ==

A process runs after the add/drop deadline that marks all apps withdrawn

Admission Scholarship Policy for applicants attending non-accredited Post-Secondary Institutions

2014-06-03T20:18:56Z

Rtoews:

Greetings all. This email is to advise you about a change in our requirement for The King’s University College Admission Scholarships.

To date these have been awarded only to those who are truly entering King’s without intervening study after high school. This meant that any post-secondary study (9 credits or more attempted) disqualified the student for this award.

The effect, however, on students who went to non-accredited programs was that they are not eligible for either the admission scholarship or the transfer scholarship. To address this gap, Hank Bestman has approved a change in our practice.

That is, an applicant is academically eligible for this award if he or she is has attempted 30 or fewer credits in a non-accredited program and has results that indicate success equivalent to their high school admission average. Non-accredited in this context means not provincially, regionally (in the US), government accredited (internationally), ABHE (for bible colleges) or ATS (for seminaries) accredited.

This change should mean that applicants who have done a single YWAM DTS (which earns 24 University of the Nation’s credits), and several other unaccredited Bible colleges, although only for a single year of study are eligible for this scholarship. Examples of other affected programs are: Capernwray, Peace River Bible Institute, Mt Carmel Bible College, and Alberta Bible College.

We will need to adapt this statement for our Calendar, but please be aware of the change in the interim. We will retroactively review all applicants for 2013/14 for eligibility under this new understanding.

--
Glenn J Keeler
Registrar
April 16, 2013

Additional Resources for International Admissions

2014-06-03T20:11:05Z

Rtoews:

IQAS has created a number of guides for various countries that explains the educational system of the country.
[http://work.alberta.ca/Immigration/international-education-guides.html IQAS Country Guides ]

AutoDeposits

2014-06-02T16:19:33Z

WikiSysop: New page: =Daily process= The daily routine for locking and unlocking accounts (busilock.exe) based on imports from Sage and from Library systesms also notes and inserts deposit payments. =Config...

=Daily process=

The daily routine for locking and unlocking accounts (busilock.exe) based on imports from Sage and from Library systesms also notes and inserts deposit payments.

=Configuration Files=

BUSILOCK.DBF is the table that defines the configuration values for this part of that process. It has the following fields:

<table border="1">
<tr><th>Field</th><th>Function</th></tr>
<tr><td>THRESHOLD</td><td>This is the dollar threshold for placing an account on hold -- this should be a positive number as positive numbers in Sage exports are balances owing.</td></tr>
<tr><td>DEPOSIT</td><td>This should be the tuition deposit for all programs except for newly admitted BEd students. This number should be a negative number as it is a credit on account (which Sage expresses as negative values) that is being sought here.</td></tr>
<tr><td>REZDEPOSIT</td><td>This should be the residence deposit and should be a negative value.</td></tr>
<tr><td>BEDDEPOSIT</td><td>This should be the residence deposit and should be a negative value. Note that this only applies to newly admitted BEd students.</td></tr>
<tr><td>INTLDEPOSI</td><td>This should be the international student deposit and should be a negative value. Note that it only applies to newly admitted international students.</td></tr>
</table>

=Process=

In general terms, this process examines each student to first determine the amount of the deposit required. Note that the flow of this is:

<ul>
<li>Is the student registered?
<ul>
<li>If yes, is this a newly admitted BEd Student?
<ul>
<li>If yes, then add BEDDEPOSIT to the amount required</li>
<li>If no, then add DEPOSIT to the amount required</li>
</ul>
</li>
<li>If no, then add zero to the amount required.</li>
</ul>
</li>
<li>Is the student an applicant for residence, not on the waitlist and sent notice of the deposit?
<ul>
<li>If yes, then add REZDEPOSIT to the amount required.</li>
<li>If no, then add zero to the amount required.</li>
</ul>
</li>
<li>Is the student a newly admitted international student?
<ul>
<li>If yes, then add INTLDEPOSI to the amount required.</li>
<li>If no, then add zero to the amount required.</li>
</ul>
</li>
</ul>

Once the amount is required it is simply tested against the exported account balance. Should their be a sufficient credit for the required deposits, a PAID entry is entered in the Account Restrictions tab, along with the amount and date. If that is already filled in, but there is an insufficient balance, then an exception note is added to the report.

The Report is emailed as specified by the batch job.

For Alumni

2014-06-02T14:17:23Z

WikiSysop:

=Setup=
Setup for Alumni Services is very similar to that for Current Student Services. In EAS Admission, under Release Editing, the entry alummenu.rel contains a tilde delimited list of the options enabled for Alumni Services. The options are outlined at [[CGI_Setup#Alumni_Services]]

=Accounts=

==Self-Serve==
Normal account creation asks alumni for their student id number and matching information such as SIN, birthdate and home postal code. Matching 2 of 3 will allow the account to be created. Similarly, if an alumnus/ae has forgotten his/her password, a reset and email password request is available.

==Manual==

Alumni who cannot remember their id number can also email a request with similar information. To set this us, in EAS Admission, use the Alumni Verification window to find (Alt F3) and match the data. Once found and matched, File | Create Alumni Account, will create the account and copy the data to the Windows clipboard. Emails should then be sent to the alumnus/ae, one with the ID and one with the temporary password. If done as a reply to the original email, care should be taken to remove personal data in the replies.

If the account already exists, the same process will reset the password and copy data to the Windows clipboard.

In the same window in EAS Admission, it is also possible to add the alumni's email to their record through the File | Add Account Email. This will help facilitate subsequent email requests.

BEdTRS

2014-04-29T17:20:02Z

WikiSysop:

To generate the BEd TRS file, there are two steps:

<ol>
<li>Edit c:\CrossRoad\BEdTRS.ini. 

[DATAPATHS] 
DBFPATH=c:\keelersv\tkuc\registra\dbf.mm 
REPORTFILE=c:\keelersv\tkuc\registra\BEdTRS.rpt 
[PARAMS] 
YEAR=14 
DEGREES=BED~ 
DEGREECODES=BEDAD~ 

The year entry is the one that will change every year.

</li>
<li>Run c:\CrossRoad\BEdTRS.exe 
This will successively ask about including each student (respond with Y or N) with a grad year as specified in the degree specified. In the situation where multiple submissions happen, this will mean excluding those previously submitted.
</li>
</ol>

Return to [[Main_Page]]

Program Support Table

2013-06-16T23:24:15Z

WikiSysop:

[[Image:Programs.jpg]]

== Degree Identifiers ==
* Degree: This is the up to 4 character code for the degree. Typically this identifies the level of the degree, and the length.
* Conc: This is the major code for this degree (which should match a subject in the conc.dbf support table.
* Longname: This is the human readable name for this program. Note that standard academic nomenclature should be used. So the degree may contain the word "of," as in Bachelor of Arts, whereas the major should be separated with "in."

== Enabling fields ==
* Active_app: this allows this program to appear in the application tabs and to be used with on-line applications.
* Active_reg: this allows this program to appear in progress of applications.

== GPA fields: ==

* Graduating GPA Overall: This is the field Passgpa.
* Graduating Major GPA: This is the field Passmgpa.
* Graduation with distinction. Up to three levels of graduation with distinction are permitted. cum laude is in the Distinctn field, , magna cum laude is in the Distinctn2 field, while summa cum laude is in the Distinctn3 field. If a level is left at 0.00, it indicates that you do not have that level of distinction.

== Faculty: ==
This is the faculty home for this program.

== Program Length and Loads ==

=== Credits or Courses ===
Although course based programs are becoming extremely rare, both can be used in CrossRoad. Check the field Crs_v_cred for programs that are credit based.

=== Length ===
Prog_len should have the number of credits required in the program.

=== Minimum number of senior level credits ===
Minsenior should contain the number of credits after the introductory level that are required for this degree.

=== Maximum transfer ===
The field Maxxfr should have the maximum number of transfer credits available. Note that if this is left at 0 then no transfer will be counted towards the program.

=== Full time threshold ===
Ftthresh holds the minimum number of credits per term that a student must take to be considered full-time. This is normally 60% of the normal full-load.

=== Year of Study determination ===
Thresholds for students to be classified as being in a particular year of study should be entered. For any year that is not part of the program, 999 should be entered.
* Yr1thresh: this is the number of credits earned to be considered year 1. This is normally 0.00
* Yr2thresh: this is the number of credits earned to be considered year 2.
* Yr3thresh: this is the number of credits earned to be considered year 3.
* Yr4thresh: this is the number of credits earned to be considered year 4.

=== Loads ===
This is entered in credits. Any year that is not part of the program should be left at 0.00.

* Yr1load: This is the normal number of credits taken by students in the first year of the program
* Yr2load: This is the normal number of credits taken by students in the second year of the program
* Yr3load: This is the normal number of credits taken by students in the third year of the program
* Yr4load: This is the normal number of credits taken by students in the fourth year of the program

== External Program Codes ==
* CIP: Classification of Instructional Programs as used by provincial and federal reporting agencies.
* PESC Award Code: This is required if XML transcripts are being produced.
* CISCode: This is the degree code for reporting in the Province of Alberta.
* QuaCode: This and the following fields all relate to former Stats Can reporting.
* Qualif:
* Prgcat:
* Approv:

== Other fields ==
* Notes: This is a free form note field.
* Admitted: This is an inactive field relating to quota controls.
* Maximum: This is an inactive field relating to quota controls.

Support Table Maintenance

2013-06-16T22:50:52Z

WikiSysop:

Support Tables

= Programs =

[[Program Support Table]]

= Country =

http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html

Confirmation of Registration

2012-12-11T17:08:27Z

199.185.111.241:

To enable on-line confirmation of registration, the following releases need to be in place:

* StuMenu.rel Needs to have CONFYYYY/YYT~ for the appropriate term added.

* KConfirm.rel Needs to have YYYY/YYT~ for the appropriate term in it.

The following HTML need to be in place:

* CUCTASKA.HTM

* CUCTASKB.HTM

* CUCTASKC.HTM

* CUCTASKD.HTM

Monthly Installments

2012-09-20T15:46:25Z

WikiSysop: /* CrossRoad Process */

Monthly installments are integrated into both web services and the desktop client. There are several stages to this process. This is designed around exporting data to Rotessa.

= Overview =

This process is depicted in this swim lane chart. [[Image:Installments.png|thumb]] Note that a number of the processes include substeps detailed below.

= Enrolment =

Enrolment happens through Registry OnLine Services for Students.

== Bank and Branch Information ==

The data for the two validation tables, banks.dbf and branch.dbf, comes from http://www.cdnpay.ca.

There are several PDFs that should be downloaded and converted to text with one branch on each line. The utility program brnchcmp.exe can then be used to add/update branches. This will also note any banks that are missing.

== Web Services ==

=== STUMENU.REL ===

ROTESSA will enable this menu item for students.

=== STMNTRAN.REL ===

The entry ROTESSA should be assigned text for the display of the link. Monthly Installment Enrollment is the value currently specified.

=== ROTESSA.REL ===

Rotessa.rel contains the year and term for current enrolment. This should be set to the Fall term after 15 June. This should be set to Winter after 1 December. The effect is that if the student enrolled for a prior year and term, they have the option of re-enrolling for the current term.

=== ROTESSA.HTM ===

Rotessa.htm contains the terms and conditions to which students are agreeing when they enrol.

== Student Enrolment ==

Students then enter their bank, branch and account information. These are validated dynamically. When the student also checks the agreement checkbox, the submission button is enabled. An email is sent to the student and the defined online services address with this agreement.

Students can subsequently enter the site and withdraw their enrolment if they have not confirmed for that term, or update their banking information.

Email to the defined registry address is generated on withdraw or updates to the defined online services address.

= Exporting Enrolment to Rotessa =

== Exporting to CSV ==

Note that this documents both current and former process as we are in transition between the two.

=== CrossRoad Global process ===

In the Current Students Window, use the the menu item Students > Global Processes > Accounts Receivable > Installments > Export Installment Enrolments to launch this process.

The process will then ask for the relevant Year and term. Dates should be de-selected.

The next step will ask for a location in which to save the file.

The process will then proceed to export each student whose installment data is not marked as "disabled", who is deemed eligible to export, and who has a King's email address. Eligibility to export is determined by

- having a valid bank and branch (account codes cannot be checked)
- having a SSF invoice entry (hence has confirmed)
- having currently registered credits
- having tuition owing after loans and financial aid are calculated above 0.00

=== Former DOS process ===

Rotessac.exe is the utility to create a csv file for importing into Rotessa. This file generates output that needs to be piped into a file to save the data.

The parameters for this program are:

Group - for King's this is Undergraduate
Year - e.g. 2012/13
Term - e.g. 1
TestFee - e.g. SSF
Owing Threshold - $40 (given that the fee is $37.50).

So an example would be

rotessac Undergraduate 2012/13 1 SSF 40.00 > rot20120920.csv

The output will be CSV lines and some error messages. The lines with error messages should be removed from the file prior to upload to Rotessa. The types of errors that may come up are:

25643 has recent transaction activity -- skipping which means that the student has had financial activity (potentially affecting whether he/she needs the installment plan) either on the current date or the prior business day. These could be payments or a/r entries.

Insufficient credit 20120222 9.50 12.00 which means that the student, whose id is listed, is having financial aid excluded because they are in too few credits (the number after the student id) than the aid item requires (the final number).

No balance owing record for 99999 which means that there is no exported record for this student from AccPac

Invalid bank/branch for 99999 which means that the bank/branch information is incorrect. This should not happen except in teh case of a branch that closed.

Error retrieving credits for 2012/131ENGL204 which would mean that a course offering was deleted when students were still registered.

== Importing to Rotessa ==

In Rotessa, under the Admin section, find the Customer Import tab. Use the browse button to find the export file. Click the Import button. You should be able to review, perhaps on several pages, the entries for validity. If they are all valid, then click the Process button. Otherwise, click Cancel and fix the problems.

= Creating Payments =

== Creation of Payments in CrossRoad ==

In Current Students on the Installments tab, the Create button will calculate the amount owing from the current balance less any unreceived student loans and unapplied financial aid. Once the amount is calculated a query asks whether the create payments. If yes then a dialog to get the dates of the payments is presented -- this prepopulates with the first of the next three months from the current date. The payments are then created or updated if there is an existing payment for that date.

(Note that updates should be immediately manually updated in Rotessa.)

Students should be emailed with the results of this. InstlEml.exe creates a file for merge emailing payments to students. The parameters are year and term.

== Emailing Students with their payment schedule ==

To produce these, use the utility InstlEml.exe. Year and term are the parameters and the output should be redirected. E.g.

InstlEml 2012/13 1 > instleml.tsv

Open instleml.tsv (or wherever you redirected the output) in Excel. It is tab delimited. Save that as a workbook such as U:\CrossRoad\DBF.MM\instleml.xlsx.

Then use and edit the merge print template, Installment Initial Email.docx

Merge this to Email messages.

= Exporting Payments to Rotessa =

== Exporting from CrossRoad ==

Note that this documents both current and former process as we are in transition between the two.

=== Current process in CrossRoad ===

In the Current Students Window, use the the menu item Students > Global Processes > Accounts Receivable > Installments > Export Installment Payments to launch this process.

This process will tehn ask for the location of the file to save.

The next steps of the process are to create the export file which will include any installments created above that is future dated and not previously exported.

=== Former DOS process ===

The utility rotessap.exe is used for this. This will export any future dated payments for clients who have been exported. There are no parameters, but output needs to be redirected.

rotessap > rotp20120925.csv

== Importing into Rotessa ==

In Rotessa, in the Admin Section, find the Transacation Import. Use the browse button to locate the file you created. Click the Import button. You can review the entries for validity; there may be several pages. If they are all valid, click Process. If not, click Cancel and fix the errors.

= Detecting Payment Excess/Insufficiency =

This is done by running the utility instlprb, with year and term as the parameters. Output may be redirected.

instlprb 2012/13 1

This will show each person with an installment entry whose installment payments are too high or too low to address their balance owing.

= Upcoming Payment Alert Email =

A utility INSTLEM2.EXE will produce a batch file (by redirecting the output) and html files for the content of each email. The template for the content file is INSTLEM2.HTM and it may have the following replaceable parameters:

<pre>
[[FNAME]] - the preferred name for the student
[[SURNAME]] - the surname for the student
[[FILE#]] - the file# for the student
[[PAYDATE]] - the payment date
[[PAYAMOUNT]] - the payment amount
</pre>

So an example might be

instlem2 2012/13 1 20121001 > instlem2.bat

Instlem2.bat would then contain commands calling cmdemail using the settings file instlem2.eml for each student email address, and a delete command to tidy up the html.

This should be triggered to run 5 business days prior to the payment date.

= Adjusting Payments =

Adjusting payments could occur for three reasons:

1. A new charge or a failed loan occurs which needs to be added to the monthly instalments.
2. A new payment is made on behalf of the student.
3. Payment NSF and Plan Status changes.

The first two are the same situation, but the last is different.

== New Charges, Failed Loans, Balloon payments ==

The effect of the change is to adjust all the remaining payments, rather than to change any single payment. So a payment of $600 on behalf of a student prior to the first instalment in the Fall should reduce the three instalments by $200 each. The same payment made in October should reduce the remaining 2 instalments by $300 each.

=== In CrossRoad ===

In CrossRoad the instalment amounts should be edited by highlighting the instalment, clicking the Edit button and changing the amount. If the payment is to be deleted, the delete button should be used.

=== In Rotessa ===

In Rotessa, under customers, find the student by file #, click the pencil icon to the right of the instalment and edit the amount. If the payment is to be cancelled altogether, then

== Payment NSF and Plan Status Changes ==

If a student's banking information is incorrect -- which is noted by Rotessa as "Edit Reject" -- we can update the banking information through the Customer Edit in Rotessa after the student has submitted new information. We need then to request that the payment be resubmitted by Rotessa. At the moment this is by an email to Greg Lepp, but we may be able to use the on-line system to do this ourselves.

If a student's payment is dishonoured, an NSF charge should be entered through the Accounts Receivable tab. No other change should be required. Rotessa will automatically schedule a second attempt 15 days from the original payment date.

If a student's payment id dishonoured twice, two NSF charges should be entered through the Accounts Receivable tab. In CrossRoad the instalment payments should be deleted, and the disabled box should be checked. In Rotessa, the future instalment payments should be deleted. This student should then be workflowed to Financial Services as interest charges will need to be assessed.

= Receiving Payment Data from Rotessa =

Rotessa's transaction reports are where we get payment data. These can be exported to Excel for subsequent processing.

== Payment Reports ==

=== Pending ===

Payment attempts are pending for up to 4 days from the date of the payment. Rotessa updates the status of the payments daily in that period. After the fourth day, they will change to a final payment status.

=== Rejected Payments ===

There are several possibilities for failure. The two most common are:

==== Edit Declined ====

Edit declines are students for whom the bank information is incorrect -- whether the mismatch is on bank, branch or account. No NSF fee applies, and we can get updated information and setup a new payment attempt.

==== Other Declines ====

These are generally NSF. Rotessa will schedule a second attempt for 15 days from the first payment date. After a second NSF, they are ours to deal with.

=== Approved Payments ===

For importing approved payments there are several steps.

==== Export Report ====

On the Rotessa site, in Transaction reports, choose Approved items within the desired date range. Export that to an Excel workbook.

==== Import into Excel ====

Copy the exported workbook to the last page of the Rotessa import workbook. Check that the data all transfers to the Data Entry tab. Check the date on that tab. Check that sufficient rows of the formulas are copied down on the first page of that workbook. Save this and close it.

==== Import into Sage ====

Create a new Receipt batch. Choose File | Import. Make the file type Excel 2000 and then use the Browse button to open the Rotessa Import workbook. Click OK.

Note that at the moment this gives a Bank Code mismatch error that has not been resolved. Depending on the error you may need to use Cancel to exit this window.

The number of records and dollar value should be matched against the Rotessa report. Then each student's payment should be applied.

The batch should be posted according to normal Financial Services practices.

==== Import into CrossRoad ====

The morning of the day on which the Accpac exported balances will include the Rotessa payments, the import should be run.

===== CrossRoad Process =====

In the Current Student window, choose the following menu sequence Students > Global Processes > Accounts Receivable > Installments > Import Installments Received. This will ask the operator to specify the file to import, and the year and term.

The process will then attempt to record each line of the CSV. Records that cannot be applied are recorded in a file in the same location as the original with "-Errors.txt" appended. This file, if created, is automatically opened at the end of the process. The records in this file should be assessed and manually updated.

===== DOS Process =====

Using the saved CSV file exported above, use the rotimp.exe utility.

rotimp 2012/13 1 export.csv

The output will display each record. If a matching CrossRoad record cannot be found, or the payment has already been applied, this will be noted.

Payments that were resubmitted due to incorrect bank information or NSF will not apply through this system and need to be done manually.

KINGS - Convention Refugees

2012-05-25T22:48:29Z

199.185.111.241: New page: == Definitions == [This is from Canada Citizenship and Immigration.] === Convention Refugee === Convention refugees are people who are outside their home country or the country where t...

== Definitions ==

[This is from Canada Citizenship and Immigration.]

=== Convention Refugee ===

Convention refugees are people who are outside their home country or the country where they normally live, and who are unwilling to return because of a well-founded fear of persecution based on:
<ul>
<li>race
<li>religion
<li>political opinion
<li>nationality or
<li>membership in a particular social group, such as women or people of a particular sexual orientation.
</ul>

=== Person in need of protection ===

A person in need of protection is a person in Canada whose removal to their home country or country where they normally live would subject them personally to:
<ul>
<li>a danger of torture;
<li>a risk to their life; or
<li>a risk of cruel and unusual treatment or punishment.
</ul>

== Safe Third Country ==

Canada's "safe third country" rule means that if someone has refugee status in a safe country Canada will not recognize them as a refugee here. So we need to be clear with international inquirers that our policy is based on obtaining Canadian designation as a refugee.

== Documentation ==

Refugees will all have a letter from an Immigration Officer confirming their status. They are also advised to apply to CIC for a Protected Person Status document, which has a photo on it. We would prefer the latter for identification and confirmation of status, but the letter will suffice.

== Admissibility ==

Protected persons are generally admissible to King's just as any other student. They will likely have difficulty documenting academic credentials; King's will use its English Language Skills Assessment Test and Math Skills Assessment Test to assist in determining the applicant's eligibility for admission, and will waive the fees for those tests.

We will accept their self-report of institutions attended and, after admission, will work with them to use prior learning assessment (in our case Course Challenge) to grant credit for prior study. The number of credits to be awarded is still limited to 12 by King's regulations.

== Application ==

Applicants who are Convention Refugees can specify that while applying through ApplyAlberta. The application fee is dependent on the address applied from rather than citizenship status, so it remains $70 for US/Canadian addresses and $140 elsewhere. Appeals of the fee will be considered.

== Fees ==

Convention Refugees do '''not''' pay international student fees.

== Links ==

http://www.cic.gc.ca/english/refugees/index.asp

Return to [[King's Admission Information]]

KINGS - Computing Science

2012-03-01T21:47:43Z

WikiSysop:

5 of the following one credit modules may be submitted as a single standard science course.

<ul>
<li> CSE3010: Computer Science 3
<li> CSE3020: Computer Science 4
<li> CSE3110: Iterative Algorithms 1
<li> CSE3310: Recursive Algorithms 1
<li> CSE3120: Object-oriented Programming 1
<li> CSE3320: Dynamic Data Structures 1
<li> CSE3130: Object-oriented Programming 2
<li> CSE3330: Dynamic Data Structures 2
<li> CSE3140: Second Language Programming 2
<li> CSE3340: Dynamic Data Structures 3
<li> CSE3210: Server Side Scripting 1
<li> CSE3240: Robotics Programming 3
<li> CSE3910: CSE Project D
<li> CSE3920: CSE Project E
</ul>

For students who took similar modules under a previous curriculum we will also accept 5 of the following INF modules as a single 30-level science course for admission.

<ul>
<li> INF3210 Computer Science 3
<li> INF3010 Hardware/Software Analysis
<li> INF3150 Programming Application 1
<li> INF3160 Programming Application 2
<li> INF3170 Programming Application 3
<li> INF3020 Local Area Networks
<li> INF3200 Internet Services
<li> INF3220 Object-oriented Programming 2
<li> INF3230 Dynamic Data Structures 1
<li> INF3240 Dynamic Data Structures 2
</ul>

[[King's Admission Information]]

KINGS - Enterprise and Innovation

2012-03-01T21:46:49Z

WikiSysop:

5 of the following may be substituted for 1 5-credit non-standard course.

ENT3010 Managing the Venture

ENT3020 Expanding the Venture

ENT3910 ENT Project D

ENT3920 ENT Project E

ENT3950 ENT Advanced Practicum

[[King's Admission Information]]

KINGS - Environmental Stewardship

2012-03-01T21:46:24Z

WikiSysop:

5 of the following may be substituted for 1 5-credit non-standard course.

ENS3030 The Green Economy

ENS3040 Energy & the Environment

ENS3050 Environmental Politics

ENS3110 Integrated Resource Management

ENS3120 Water Management 2

ENS3130 Sustainable Energy

ENS3210 Sustainable Community Planning & Design

ENS3220 Energy Conservation Applications

ENS3910 ENS Project D

ENS3920 ENS Project E

ENS3950 ENS Advanced Practicum

[[King's Admission Information]]

KINGS - Financial Management

2012-03-01T21:45:52Z

WikiSysop:

5 of the following may be substituted for 1 5-credit non-standard course.

FIN3010 Advanced Accounting

FIN3020 Management Accounting

FIN3030 Capital Accounting

FIN3040 Financial Statements

FIN3050 Small Business Taxation

FIN3060 Financial Analysis

FIN3070 Financial Planning

FIN3080 Personal Investment Planning 1

FIN3090 Personal Investment Planning 2

FIN3910 FIN Project D

FIN3920 FIN Project E

FIN3950 FIN Advanced Practicum

[[King's Admission Information]]

KINGS - Health Care Services

2012-03-01T21:45:14Z

WikiSysop:

5 of the following may be substituted for 1 5-credit non-standard course.

HCS3000 Workplace Safety Systems

HCS3010 Workplace Safety Practices

HCS3020 First Responder 1

HCS3030 First Responder 2

HCS3040 Child Care First Aid

HCS3050 Reproduction & Readiness for Parenting

HCS3060 Pregnancy, Birth & Infant Care

HCS3150 Advances in Medical Technology

HCS3910 HCS Project D

HCS3920 HCS Project E

HCS3950 HCS Advanced Practicum

[[King's Admission Information]]

KINGS - Networking

2012-03-01T21:44:28Z

WikiSysop:

5 of the following may be substituted for 1 5-credit non-standard course.

NET3010 Digital Technology 3

NET3020 Digital Applications

NET3030 Microprocessors

NET3040 Microprocessor Interface

NET3050 Network Operating Systems

NET3060 Wide Area Networks

NET3070 Routing Fundamentals

NET3080 Internet Processes

NET3090 Network Management

NET3100 Network Media & Devices, Security

NET3110 Telecommunications 2

NET3910 NET Project D

NET3920 NET Project E

NET3950 NET Advanced Practicum

[[King's Admission Information]]

KINGS - Wildlife

2012-02-29T19:09:42Z

WikiSysop:

5 of the following may be substituted for 1 5-credit non-standard course.

WLD3020 Wildlife Protection & Stewardship

WLD3040 Wildlife Management Research Study

WLD3050 Wildlife Management Principles

WLD3060 Wildlife Management Applications

WLD3090 Analyzing Issues in Wildlife

WLD3130 Outdoor Leadership

WLD3140 Introduction to Guiding

WLD3910 WLD Project D

WLD3920 WLD Project E

WLD3950 WLD Advanced Practicum

[[King's Admission Information]]

KINGS - Management & Marketing

2012-02-29T19:09:04Z

WikiSysop:

5 of the following may be substituted for 1 5-credit non-standard course.

MAM3010 The Business Organization

MAM3020 Business in the Canadian Economy

MAM3030 Business in the Global Marketplace

MAM3040 Promotion – Sales Techniques

MAM3050 Distributing Goods & Services

MAM3060 Setting Up a Retail Store

MAM3070 Office Systems 2

MAM3080 Communication Strategies 3

MAM3090 Records Management 2

MAM3100 Promotion – Broadcast Advertising

MAM3120 E-commerce 3

MAM3130 Agriculture Marketing

MAM3140 Energy & Resources Market Basics & Trends

MAM3150 The Forest Marketplace

MAM3910 MAM Project D

MAM3920 MAM Project E

MAM3950 MAM Advanced Practicum

[[King's Admission Information]]

KINGS - Legal Studies

2012-02-29T19:08:19Z

WikiSysop:

5 of the following may be substituted for 1 5-credit non-standard course.

LGS3010 Property Law

LGS3020 Dispute Resolution

LGS3040 Negligence

LGS3050 Small Business Law

LGS3060 Controversy & Change

LGS3070 Landmark Decisions

LGS3080 Criminal Law

LGS3910 LGS Project D

LGS3920 LGS Project E

LGS3950 LGS Advanced Practicum

[[King's Admission Information]]

KINGS - Forestry

2012-02-29T19:07:47Z

WikiSysop:

5 of the following may be substituted for 1 5-credit non-standard course.

FOR3010 Issues & Trends in Forestry

FOR3060 Forest Mensuration 2

FOR3080 Forest Research & Development

FOR3090 Forest Ecology – Silvics & Succession

FOR3110 Silviculture

FOR3910 FOR Project D

FOR3920 FOR Project E

FOR3950 FOR Advanced Practicum

[[King's Admission Information]]

KINGS - Design Studies

2012-02-29T19:05:20Z

WikiSysop:

5 of the following may be substituted for 1 5 credit non-standard course.

DES3035 2-D Design 3

DES3045 3-D Design 3

DES3055 CAD 3

DES3065 Technical Design 3

DES3075 Technical Drafting 3

DES3095 Architectural Design

DES3105 Engineering Design

DES3115 Industrial Design

DES3125 Interior Design

DES3135 Landscape Design

DES3145 Modelling – Real

DES3155 Modelling – Virtual

DES3165 Presentation

DES3170 Future of Design

DES3910 DES Project D

DES3920 DES Project E

DES3950 DES Advanced Practicum

[[King's Admission Information]]

KINGS - Community Care Services

2012-02-29T19:03:13Z

WikiSysop:

5 of the following may be substituted for a 5 credit non-standard course.

CCS3080 Community Enhancement

CCS3110 Early Learning & Child Care 1

CCS3120 Early Learning & Child Care 2

CCS3130 Early Learning & Child Care 3

CCS3140 Early Learning & Child Care 4

CCS3150 Early Learning & Child Care 5

CCS3910 CCS Project D

CCS3920 CCS Project E

CCS3950 CCS Advanced Practicum

[[King's Admission Information]]

KINGS - Agriculture

2012-02-29T18:52:44Z

WikiSysop:

5 credits of the following may be substituted for a 5 credit non-standard course.

AGR3000 Agriculture Safety

AGR3030 Field Crops 2

AGR3040 Livestock/Poultry 2

AGR3050 Agrifoods 2

AGR3060 Landscaping 3

AGR3070 Equine 2

AGR3085 Floral Design 3

AGR3095 Display Design

AGR3100 Biotechnology

AGR3120 Soils Management 2

AGR3150 Greenhouse/Nursery Crops 3

AGR3160 Turf Management

AGR3910 AGR Project D

AGR3920 AGR Project E

AGR3950 AGR Advanced Practicum

[[King's Admission Information]]

KINGS - Communication Technology

2012-02-29T18:00:32Z

WikiSysop:

5 of any of the following may be used as 1 non-standard course.

COM3005 Creative Writing

COM3025 Electronic Layout & Publishing 2

COM3035 Raster Graphics 2

COM3045 Vector Graphics 2

COM3055 Rich Media – Basics

COM3065 Rich Media – Programming

COM3075 Cascading Style Sheets

COM3085 Content Management Systems

COM3105 AV Preproduction 2

COM3115 AV Production 2

COM3125 AV Postproduction 2

COM3135 Audio Techniques

COM3145 Animation 3

COM3155 Design – Advertising Campaigns

COM3165 AV Broadcasting

COM3205 Photography – Lighting

COM3215 Photography – Photojournalism

COM3225 Photography – Colour

COM3235 Photography – B/W Digital Techniques

COM3245 Photography – Outdoor

COM3275 Photography – Digital Processing 2

COM3285 Com Tech Client Services 2

COM3910 COM Project D

COM3920 COM Project E

COM3950 COM Advanced Practicum

[[King's Admission Information]]

Graduation

2012-02-03T04:58:24Z

WikiSysop: New page: Graduation is tracked on the application progress tab of Current Students. When a student applies to graduate, the two digit year is entered into the grad year field. When the student actu...

Graduation is tracked on the application progress tab of Current Students. When a student applies to graduate, the two digit year is entered into the grad year field. When the student actually graduates, the checkbox is checked. In addition to this notation, a term comment should be entered, and the exact date of degree conferral can be entered.

Individual Grade Entry

2012-02-03T04:38:54Z

WikiSysop:

Grades can also be entered on the course registration tab of the current students window. In editing mode, select the course for which you are entering a grade, and click the mark button.

[[Image:Current_Students_Course_Registrations_Mark.jpg]]

After entering the grade, click OK. Then click the Save button.

While any valid grade can be entered, normally this is used for course withdrawals only.

Return to [[Main Page]].

For Students

2011-12-13T17:57:32Z

WikiSysop:

= Logging in =

Students log in using the CGI program login.exe. They use their student ID and the PIN on the Account Restrictions tab of the CrossRoad current students window. The default value for this is the month and day of birth. There is a PIN reset process on the login page which, after matching some data in CrossRoad, returns the PIN to its default value. This can also be done directly in CrossRoad.

= Student Menu =

The student menu is run by the mainmenu.exe CGI program. The entries are constructed from two sets of Release files which in turn use the values in the webini table to direct the student.

STMNTRAN.REL provides translation between the various options in the student menu and what appears on the menu. This allows customization of the wording for each entry. The list has the option word, followed by a vertical bar, followed by the text to display. Each of these is separated by a tilde.

STUMENU.REL activates entries by having the appear in a tilde delimited list. There are two types of entries: static and dynamic. Static entries simply toggle on or off a link to a service. For example, REGISTER allows access to a listing of current registrations for the student. ADVISOR allows access to the advisor reports. Dynamic entries have year and term (or possibly just year) components to the key word which sets parameters for the subsequent action. For example, DEC should be followed by a year entry (e.g. DEC2011/12) and it will link to the student contractual obligations for that year. WEBAPPT and CONF should be followed by a year and term entry (e.g. WEBAPPT2011/122) linking to a specific year and term for these services. Some dynamic services disappear from the list when the student has completed the task, while others are simply modified so that the student can review what has been done.

= Reminders =

The reminders section at the top of the menu is controlled by the Release entry CHECKLST.REL. It is very similar to the student menu and most entries in it are dynamic, requiring a year and term component. In the case of the checklist, entries always disappear when the task has been completed.

= Further Information =

Further details on the options can be seen at

http://registry.kingsu.ca/mediawiki/index.php/CGI_Setup#Student_Services

Prerequisite and Requirement Exceptions

2011-04-04T23:01:10Z

199.185.111.241:

This screen is accessed through Current Students from the toolbar icon or the menu items Students | Update Exceptions Table.

Six different types of exceptions are available:
<ul>
<li>Consent 
-if a student needs consent to register for a course. Year, term, course code (with section)must be entered. 
<li>Credit Requirement 
-if a student needs X amount of credits to register in a course. Year, term, course code and credit number must be entered. In Course Code a discipline can be entered (ZZZZ for no discipline) and A (any level), J (Junior) or S (Senior). ZZZZA would add the number of credits in any course, BIOLS would add the number of senior level BIOL credits 
<li>Overload 
-student needs to register in more credits than allowed. Year, term, and credit number must be entered. 
<li>Pre-requisite 
-student needs to register in a course they do not have the prerequisite for. Year, term, course code (with section number) must be entered.
<li>Program Requirement 
-This is used when a student has unclear transfer credit or a program requirement met in some other manner in relation to pre-requisites and courses completed in the program advisor report. Course code must be entered. 
<li>Schedule Conflict 
-allows a student to register in a conflict. Year, term and course must be entered for each course. 
</ul>

KINGS - New English Proficiency Measures

2011-03-25T16:45:02Z

10.111.0.9: /* SAT and English Proficiency */

= New English Proficiency Measures =

This section lists means for meeting English proficiency at King's that are not included in the Academic Calendar because they are new or rare.

== Pearson Test of English (Academic) ==

PTE (Academic): An overall score of at least 59. http://pearsonpte.com/PTEAcademic/Pages/home.aspx

== CLBA ==

Canadian Language Benchmarks Assessment (CLBA) a minimum of 9.0

= English Proficiency Exemption based on Standardized Tests =

== SAT and English Proficiency ==

A SAT Critical Reading and Verbal score of 550 can be used in place of a standardized English proficiency test.

== GCE/IGCSE Equivalents ==

A grade of B or better in an O-level, GCSE, or IGCSE English Language or Literature subjects.

A level or higher with a grade of B or better in the HKDSE English Language or Literature subjects.

Academic Standing

2011-03-21T00:44:52Z

10.111.15.12: /* Report */

= Academic Standing =

Academic Standing is the process by which, at the end of each term, a student is assigned an academic standing of honours, probation, ok, and so on.

To be successful, this process has two prerequisites:
<ul>
<li>the population of an academic standing table with the rules for academic standing</li>
<li>entry of a grade for all courses registered in a term (even if that grade is an incomplete)</li>
</ul>

== Academic Standing Support Table ==

This is edited through [[Support Table Maintenance]], and the table to be edited is AcadStat.

In this table there needs to be a row for every academic standing status that matches every year of study in every program in which students are registered.

=== Program Year of Study Matching ===

The program and year of study matching occurs as follows. If there is a match based on degree (or degree is blank), major/first concentration (or that is blank), minor/second concentration (or it is blank) and the gpas being tested are within the correct range, that record will be used. So rules that apply globally to any program and any year of study should be entered with blank degree, conc1, conc2, and yrstdy fields. Rules that apply to any major or minor or year of study within a degree should have the degree filled in, but conc1, conc2, and yrstdy blank. Other combinations can be determined based on this scheme.

=== Academic Standing Status ===

The next field to be completed is ACADSTAT. This is the 2 character code and must appear in the [[Code Table Maintenance]] for the entry ACDSTAT.

=== Term GPA and failure limit ===

The next two fields to be completed are the term GPA fields. These are UPPERGPA and LOWERGPA, which are the boundaries. Care must be taken when entering the values for these fields as they are 3 decimals. It may be that, through other program settings, you are using 2 or even 1 decimal GPAs. If so, you must enter the three decimal values so that they will round correctly for your calculations. If these are not used for calculating a particular academic standing, enter -1.000 for each.

The next field is NUMFAILS, which defines the number of courses that may be failed in a term in that status. If you have a rule that says that any failure places a student on probation, then this should be 0. If it requires 2 failures to land on probation, then the value should be 2. If you have no such rule, then the value should be entered as 99.

=== List and Weight ===

LIST is a deprecated field, but defines which group this standing falls in. Generally these are P (for probation), W (for withdrawal), H (for honours) and X (of ok).

WEIGHT is a way of sorting the "badness" of the standing. Honours is 10. Required to withdraw is 1. OK is 5. Other statuses should be assigned using ranges between those. This weighting is used to disambiguate standings when the term GPAs and the Cumulative GPA statuses are different, with the worst being assigned.

=== Long Name ===

LONGNAME is used on some reports, such as the statement of results, to print a statement concerning the academic standing that has been calculated if no standing notation has been entered in the term record for this student.

=== Cumulative GPAs ===

MAXCGPA and MINCGPA are entered as the term GPA entries above, but it is the student's cumulative GPA that is checked against these. If these are not used for calculating a particular academic standing, enter -1.000 for each.

== Running Academic Standing Reports ==

These reports are run from the [[Course Results]] window. There you choose the menu item Reports | Honors/Probation Lists. On selecting that you will be offered the option of simply printing the existing calculations, or doing a new set of calculations. The next window permits you to set the parameters for this calculation.

=== Options ===

First you may select the year and term for which calculations are to be done. Normally this is the current term, but there may be come term overlap situations in which it is necessary to change these values. The minumum credits and minimum courses fields allow you to exclude non-credit and part-time students. Both are used in the exclusion, so if you have a program with single large credit courses, you must use the smallest number of courses (likely 1) while using the threshold of the credit load you want included (likely 6 or 9 credits).

It is possible to restrict this process by a course criteria created in the Course Offerings section of CrossRoad. This is very rare, and so should only be used after consultation with Keeler Services.

=== Update/New ===

You will next be presented with a dialog that asks whether you would like to update an existing file or create a new one. The first time academic standing is run for a term, you want to create a new file. However, if there are updates to grades and you wish to run this process again it is substantially faster to update the file.

=== Progress ===

The program will then pull each matching student into a table, and calculate the term GPA and then the CGPA for each student. This can take some time. Once these are calculated, the matching academic standing is located. An errorbox will appear if no matching standing record is found. This should be corrected and the process rerun.

=== Report ===

A report is then produced listing each student with relevant data and a recommended status. Note that this is a report only, and actual changes need to be made by direct entry in each student record. The assumption behind this report is that the person running the report is not the person who finally decides the student's academic status.

=== Academic Standing Decision Review and Processing ===

In the course results window, there is a menu entry to Edit Academic standing. This provides an interface to edit the recommended decisions into final decisions.

The basic interface is a grid where the first column is a drop list of possible academic standing entries. On the right are several options.

==== Commute ====

This changes recommended WD to L3 and is usually used at the end of the Fall term.

==== Reweight ====

This recalculates the weighting, which controls the sort order, of the list. This helps if a number of standing changes have happened and you want to see them in order.

==== Flash ====

This moves the decisions to the Academic Progress tab of the Current Students window.

==== Comments ====

This adds the appropriate comment code to the term record for each student.

==== Audit Report ====

This provides a list of students with academic standing audit codes in their term records; this is useful for cross-checking against the academic standing list and for controlling issues such as part time and grads who received academic standing comments.

There are utilities that automate some of this data entry; you can refer to [[Academic Standing Related Processes and Reports]].

Term End

2011-03-20T23:20:09Z

WikiSysop: New page: = Term End = Term End is a process that is run to close off one term and move to the next. It is actually a series of activities that can be run separately; they are grouped here only for...

= Term End =

Term End is a process that is run to close off one term and move to the next. It is actually a series of activities that can be run separately; they are grouped here only for convenience. Also note that it may not be possible to define a clean term end point depending on the degree of overlap in your terms.

Term End is started at Utilities | Archive Maintenance | Term End. The initial dialog will then appear.

[[image:Term_End_Win.jpg]]

This asks you to specify the next term, to indicate whether to change student academic standing, the add/drop processing date (and if so what that date is), and/or the id series (and if so what the new series is. On clicking Proceed, the following processes, in the term end sequence, are completed, although most have the option to cancel if the operator wishes to skip them.

<ol>

<li>Updating Current Student Term Records (which is the same as [[Scanning For Missing Or Redundant Records]])</li>
<li>Change the ID series and current term information (which can be done in the [[System Parameters]] window)</li>
<li>Resets the academic and student standing (which can be done as part of the [[Academic Standing]] process as well as through the [[Global Processes]] in Current Students, particularly Student Related | Global Update Student Status)</li>
<li>Change the Processing date, (which can also be done in the [[System Parameters]] window)</li>
<li>Recount the earned and advance credits for each student and update the year of study (which can be done through the [[Global Processes]] in Current Students, particularly Student Related | Recalculate Year of Study)</li>
<li>Purge Old Applications (which can be done through [[Global Processes]] in Current Students, particularly Application Related (both items))</li>
</ol>

Advisors-Instructors ERD

2011-03-20T22:26:28Z

WikiSysop: New page: Advisors/Instructors

[[image:Advisors-idef1x.png|Advisors/Instructors]]

Course Offerings ERD

2011-03-20T22:25:30Z

WikiSysop: New page: Course Offerings

[[image:CourseOfferings-idef1x.png|Course Offerings]]

Course Templates ERD

2011-03-20T22:24:52Z

WikiSysop: New page: Course Templates

[[image:CourseTemplates-idef1x.png|Course Templates]]

Prospective Students ERD

2011-03-20T22:24:04Z

WikiSysop: New page: Prospective Students

[[image:Prospective-idef1x.png|Prospective Students]]

Current Students ERD

2011-03-20T22:23:17Z

WikiSysop: New page: Current Students

[[image:Current-idef1x.png|Current Students]]

Deadfiles

2011-03-18T03:06:31Z

WikiSysop:

== Deadfiles ==

Deadfiles are where the records of applicants who never received a student ID are stored. This could arise because they did not complete the submission of their application, or they did not pay a deposit. It is intended that Deadfiles will be purged periodically based on their age -- a suggested interval is two years.

=== Deadfiling ===

Deadfiling is the process of moving applicant records into the deadfiles. This is initiated from the Current Students menu Students | Global Processes... | Application Related | Move Old Applications to Deadfiles.

This brings up a warning, after which a dialog appears asking for the "first protected year and term." Setting this means that applications prior to the protected year and term for students who have not received a student ID will be moved. Once this dialog is complete, the process will run, counting the number of records to be moved and provide you with one more point to stop the process. Once that is accepted the process will move the records from current files to Deadfiles.

=== Editing ===

Deadfiles may be viewed by clicking the main toolbar icon [[Image:DeadF_MTB_icon.jpg]] or by choosing File | Deadfiles from the main menu. This should display the following listing of records.

[[image:DeadF_Win.jpg]]

This is a tabular list of deadfiled students.

==== Seek ====

The seek button assists you in finding the entries you wish to deal with.

==== Revive ====

Once you have found the record you wish to deal with, clicking the Revive button will restore the information to the Current Students part of the program.

==== Delete ====

Delete will simply discard the record you are currently highlighting.

==== Purge ====

Purge will bring up a year term dialog. This is asking you to select the year and term prior to which deadfile entries will be permanently eliminated. Generally the date fields should be unchecked as they are not relevant to this process.

==== Close ====

Close simply closes this window.

Return to [[Main Page]].

Typical Annual Cycle

2011-03-18T02:33:13Z

68.148.176.254: New page: The typical annual cycle of activities includes the following items: <ul> <li>Creating/Editing Course Templates </li> <li>Updating Course Availability to make Courses Available or...

The typical annual cycle of activities includes the following items:

<ul>
<li>Creating/Editing [[Course Template]]s </li>
<li>[[Updating Course Availability]] to make Courses Available or Unavailable for a given year</li>
<li>[[Flash Courses]] from Templates to Course Offerings and Approve Schedule</li>
<li>Student [[Course Registration]]</li>
<li>[[Confirmation of Registration]]/Add/Drop period</li>
<li>Withdraw Period</li>
<li>Entering Results and doing [[Academic Standing]] calculations</li>
<li>Update [[Term Records And Transcript Comments]]</li>
<li>Run [[Term End]] Processes</li>
</ul>

These activities occur in an overlapping fashion between terms and academic years. For example, probably near mid-term of the January-April term, work will need to be completed for the first four items on the list above for the next academic year's fall and winter terms, while the last four items on the list are still incomplete for that term. This is all supported by CrossRoad, but means that it is important that the manager and operators are conscious of this overlap.

These processes will be reviewed.

Return to [[Main Page]]

ApplyAlberta

2011-02-07T18:55:01Z

WikiSysop: /* ASN Reconciliation Issues */

= Application Procedures =

In general, applications are received as follows.

<ol>
<li>Applicant completes ApplyAlberta Profile</li>
<li>Applicant applies to King's portion (email is sent to applicant on completion)</li>
<li>Applicant pays application fee</li>
<li>Payment is matched to application</li>
<li>Statistical Record is sent to ApplyAlberta</li>
<li>Application is Sent to CrossRoad</li>
<li>Application is Received by CrossRoad (File #is assigned)</li>
<li>Application is Printed to electronic file</li>
<li>Transcript requests are entered into Toolkit</li>
</ol>

Items 4 through 8 are described below.

== Payment is Received ==

Online payments are noted in an email to registrar@kingsu.ca. They may also be received in person, by Enrollment Services waivers, by mailed in cheque, wire transfer, bank payment...

== Application Statistical Record is Sent ==

This requires logging into the Application Maintenance system for King's. Production version of this is

https://apply.kingsu.ca/Admin/

In the application list the button beside the now paid application labeled "Send to APAS" should be clicked. This sends a record to ApplyAlberta noting that we have accepted this application for processing.

== Application is Sent to CrossRoad ==

In the same place as the screen above, click the checkbox next to the matched application and click the button in the lower right labeled "Send to CrossRoad."

Multiple entries may be sent in a single pass.

== Application is Received by CrossRoad ==

In CrossRoad, in Current Students, choose Edit | Add from ApplyAlberta. There specify the ASN and application number from the previous step. These can by copy and pasted between windows. Once the import is complete (that is data validated against our standards; new highschool and post-secondary institutions flagged) and data has been reloaded in the Phase II program, the file number assigned in CrossRoad should also appear there.

== Application is Printed to electronic file ==

Return to the apply.kingsu.ca/Admin browser window. Select and View the application. Print it to a PDF and then use the Send To application to file that in the electronic student file using the File# generated in the previous step.

== Transcript requests are entered into Toolkit ==

Using the ApplyAlberta Toolkit (http://apply.kingsu.ca:8080/apasiit/), generate transcript requests for each institution cited. Note that the hold type should be correct in the following pattern:

<ul>
<li>For an institution where the student is currently enrolled, we would request an immediate ("now") transcript and a transcript when grades are released.</li>
<li>For an institution where the student is no longer enrolled, we would request an immediate transcript.</li>
<li>When a student is applying to an after-degree, or second-degree program, we would also request a transcript when the graduation notation is affixed.</li>
</ul>

=== Entering Requests Manually ===
To enter these one at a time, choose Admissions | Request Transcript to start each applicant's group of requests.

The following are mandatory fields for making this request.
<ul>
<li>Last Name</li>
<li>First Name</li>
<li>Gender</li>
<li>Date of Birth (yyyy-mm-dd)</li>
<li>ASN</li>
</ul>

To assist with this, a "Copy ApplyAlberta" button appears on the Secondary and Post-Secondary pages. This places the data in the sequence noted on the clipboard. Another button will copy a student number from a post-secondary record for inclusion in the specific request.

Note the correct release type and submit the requests for this student. See the next section for more detail on managing the requests.

=== Entering Requests By Import of CSV ===
Requests may be exported from CrossRoad through the ApplyAlberta button on the Application for Admission tab. The first export should have the headers added, subsequent exports should not. The process will then loop through each institution starting with Alberta Education (AE) to allow for an immediate request and a second request after final grades or degree notation. To finish with an institution, click Cancel on the dialog box.

In the Toolkit, choose Admissions | Unsent Transcript Requests. Use the Import button at the bottom to find and import the file exported from CrossRoad. Check to ensure that all the requests have imported correctly, including hold types.

= Transcript Procedures =

== Transcript Request Receipt ==

1) Transcript Request arrives at King’s. 
2) Responses include a copy of the information sent in the original request. 
3) If information in the request cannot be extracted, return a Cancelled Response indicating the record has a problem with the data it contains. 
4) Determine if applicant is in the King’s SIS database (when the request arrives). 

If the student cannot be uniquely identified on the initial search, return response of type “OfflineRecordSearch” and start a manual search process.

If the student record is not found, return “NoRecord” (using original request id).

If the student record is found, in paper/microfiche records, determine Holdtype.

If the student record is found in electronic records but under different identifiers than in request, consider updating electronic records for that student prior to sending transcript (e.g. Update ASN, or name information. It is ok to send transcripts with existing information without doing any updates). Combine multiple records into a single record if necessary. Determine holdtype.

If student can be uniquely identified, determine if transcript should be generated.

If not, (e.g. transcript is being held for financial or other reasons): Send response of type “hold” (with the original request id). NOTE: it is the responsibility of the requesting institution to communicate to the student the need to clear the hold. If hold is not cleared in 60 days then send a Cancelled response.

If the holdtype allows for the transcript to be generated at this time, send record electronically or as paper if part of the record is in paper/microfiche (with original request id).

If the holdtype does not allow for the transcript to be generated at this time, keep transcript in queue until such time as the transcript can be generated.

== Transcript Production ==

== Transcript Request Issuance ==

1) Application arrives at King’s with transcripts being requested. 
2) For each Institution or school listed for transcripts on the application: 
If applicant is currently enrolled we determine number of requests to be sent based on different holdtypes. We determine the terms or dates for each individual request based on when the information is needed for evaluation
If applicant is not currently enrolled, we flag to only send a single request with Holdtype=Now. 
3) Consolidating our requests. 
Ideally one request per Holdtype should be sent to a fulfilling institution. (e.g. student attended 3 AB high schools only send 1 request to AE) 
4) Send our requests. 
Ensure all PESC required and recommended fields, where we have access to the information, are included in the request
Generate a request to each institution for each Holdtype. NOTE: each request must have a different RequestID

== Transcript Request Tracking ==

King’s will let applicants know which transcripts we can obtain on their behalf and whether there are any transcripts they are responsible for ordering. 
Applicants can check the status of their transcript being transferred through Apply Alberta by logging on(Apply Alberta - My Activities – Transcripts). Any transcripts that applicants are responsible for ordering will not show up on this status page.

== ASN Reconciliation Issues ==

=== ASI ===
The ASI submission process for submitting and validating ASN’s will continue. Institutions will receive any updated ASN’s through that process. APAS will now need to be notified by Alberta Education of any changes to ASN’s made through this process. APAS will be notified by fax.

When multiple ASN situations are detected by Alberta Education the procedure will be to fax APAS and the institutions any changes to the ASN. APAS and the institutions will update their database information on the student. The institutions will initiate a new request for the transcript on behalf of the student.

When a student initiates a request to investigate a problem with partial transcripts that results in an ASN change, that change will also be faxed to APAS and the institution(s) they applied to. Institutions should then re-request any transcripts after updating their databases. Note: the student may request AE transmit their transcripts immediately in which case institutions may receive an unsolicited transcript. This transcript could arrive prior to their generating a new request.

Note that recently this process seems to be assigning a new ASN to all individuals who have a new surname. We have therefore stopped changing ASNs based on this report if that is the case.

=== Deleted/Retired ASN Process ===

Periodically, EAE will issue a Deleted/Retired ASN report in the form of an Excel workbook. This is imported into our file ASNDEL.DBF which is used to match against XTRA.DBF and ARCXTRA.DBF.

= Technical Support Procedures =

== Bug Reporting Procedure ==

All bug reports are to be made to either Henry Stad or Glenn Keeler who will in turn report these to ApplyAlberta.

=== Known Bugs in Internal Application as of 07 February 2011 ===

None

== Disaster Recovery Strategy ==

To be completed by IT.

== Institutional Maintenance Page ==

Glenn Keeler or Henry Stad will enter any maintenance dates affecting Apply Alberta. The source for such dates is King's IT. Similarly, Open House and King's View Friday dates will be reported to Apply Alberta by Glenn Keeler or Henry Stad.

= Contact List =
<div>
Production
Application Contacts
 
<table border=1 cellspacing=0 cellpadding=0>
<tr>
<td valign=top>
 
</td>
<td valign=top>
 
</td>
<td valign=top>
Name
</td>
<td valign=top>
Title
</td>
<td valign=top>
Work
Phone
</td>
<td valign=top>
Alternate
Phone
</td>
<td valign=top>
Email
</td>
<td valign=top>
Hours
(M-F)
</td>
</tr>
<tr>
<td rowspan=3 valign=top>
Business Contacts
</td>
<td valign=top>
Primary 
</td>
<td valign=top>
Henry Stad
</td>
<td valign=top>
Registry Information Coordinator
</td>
<td valign=top>
(780) 465-3500 x 8214
</td>
<td valign=top>

</td>
<td valign=top>
Henry.Stad@kingsu.ca
</td>
<td valign=top>
Tues-Thur 08:00-18:00, Fri 08:00-17:30
</td>
</tr>
<tr>
<td valign=top>
Backup

</td>
<td valign=top>
Rick Toews
</td>
<td valign=top>
Assistant Registrar
</td>
<td valign=top>
(780) 465-3500 x 8123
</td>
<td valign=top>

</td>
<td valign=top>
Rick.Toews@kingsu.ca
</td>
<td valign=top>
09:00-17:00
</td>
</tr>
<tr>
<td valign=top>
Escalation

</td>
<td valign=top>
Glenn Keeler
</td>
<td valign=top>
Registrar
</td>
<td valign=top>
(780) 465-3500 x 8035
</td>
<td valign=top>

</td>
<td valign=top>
Glenn.Keeler@kingsu.ca
</td>
<td valign=top>
08:00-17:00
</td>
</tr>
<tr>
<td colspan=8 valign=top>
 
</td>
</tr>
<tr>
<td rowspan=3 valign=top>
Technical
Contacts
</td>
<td valign=top>
Primary

</td>
<td valign=top>
Tony Lambregts
</td>
<td valign=top>
Network Administrator
</td>
<td valign=top>
(780) 465-3500 x 8015
</td>
<td valign=top>

</td>
<td valign=top>
Tony.Lambregts@kingsu.ca
</td>
<td valign=top>
08:00 – 16:00
</td>
</tr>
<tr>
<td valign=top>
Backup

</td>
<td valign=top>
Will Ryks
</td>
<td valign=top>
Director ITS
</td>
<td valign=top>
(780) 465-3500 x 8080
</td>
<td valign=top>

</td>
<td valign=top>
Will.Ryks@kingsu.ca
</td>
<td valign=top>
08:00 – 16:00
</td>
</tr>
<tr>
<td valign=top>
Escalation

</td>
<td valign=top>
Will Ryks
</td>
<td valign=top>
Director ITS
</td>
<td valign=top>
(780) 465-3500 x 8080
</td>
<td valign=top>

</td>
<td valign=top>
Will.Ryks@kingsu.ca
</td>
<td valign=top>
08:00 – 16:00
</td>
</tr>
</table>
 
 
Production
Transcript Contacts
 
<table border=1 cellspacing=0 cellpadding=0>
<tr>
<td valign=top>
 
</td>
<td valign=top>
 
</td>
<td valign=top>
Name
</td>
<td valign=top>
Title
</td>
<td valign=top>
Work
Phone
</td>
<td valign=top>
Alternate
Phone
</td>
<td valign=top>
Email
</td>
<td valign=top>
Hours
(M-F)
</td>
</tr>
<tr>
<td rowspan=3 valign=top>
Business Contacts
-Incoming & Outgoing
</td>
<td valign=top>
Primary 
</td>
<td valign=top>
Erika Elves
</td>
<td valign=top>
Registry Clerical Assistant
</td>
<td valign=top>
(780) 465-3500 x 8030
</td>
<td valign=top>

</td>
<td valign=top>
Erika.Elves@kingsu.ca
</td>
<td valign=top>
Mon-Fri, 08:30-04:30
</td>
</tr>
<tr>
<td valign=top>
Backup

</td>
<td valign=top>
Henry Stad
</td>
<td valign=top>
Registry Information Coordinator
</td>
<td valign=top>
(780) 465-3500 x 8214
</td>
<td valign=top>

</td>
<td valign=top>
Henry.Stad@kingsu.ca
</td>
<td valign=top>
Tues-Thur 08:00-18:00, Fri 08:00-17:30
</td>
</tr>
<tr>
<td valign=top>
Escalation

</td>
<td valign=top>
Glenn Keeler
</td>
<td valign=top>
Registrar
</td>
<td valign=top>
(780) 465-3500 x 8035
</td>
<td valign=top>

</td>
<td valign=top>
Glenn.Keeler@kingsu.ca
</td>
<td valign=top>
Mon-Fri 08:00-17:00
</td>
</tr>
<tr>
<td>
ASN queries
</td>
<td valign=top>

</td>
<td valign=top>
Erika Elves
</td>
<td valign=top>
Registry Clerical Assistant
</td>
<td valign=top>
(780) 465-3500 x 8030
</td>
<td valign=top>
 
</td>
<td valign=top>
Erika.Elves@kingsu.ca
</td>
<td valign=top>
Mon-Fri, 08:30-04:30
</td>
</tr>
<tr>
<td colspan=8 valign=top>
 
</td>
</tr>
<tr>
<td rowspan=3 valign=top>
Technical
Contacts
</td>
<td valign=top>
Primary

</td>
<td valign=top>
Tony Lambreghts
</td>
<td valign=top>
Network Administrator
</td>
<td valign=top>
(780) 465-3500 x 8015
</td>
<td valign=top>

</td>
<td valign=top>
Tony.Lambregts@kingsu.ca
</td>
<td valign=top>
08:00 – 16:00
</td>
</tr>
<tr>
<td valign=top>
Backup

</td>
<td valign=top>
Will Ryks
</td>
<td valign=top>
Director ITS
</td>
<td valign=top>
(780) 465-3500 x 8080
</td>
<td valign=top>

</td>
<td valign=top>
Will.Ryks@kingsu.ca
</td>
<td valign=top>
08:00 – 16:00
</td>
</tr>
<tr>
<td valign=top>
Escalation

</td>
<td valign=top>
Will Ryks
</td>
<td valign=top>
Director ITS
</td>
<td valign=top>
(780) 465-3500 x 8080
</td>
<td valign=top>

</td>
<td valign=top>
Will.Ryks@kingsu.ca
</td>
<td valign=top>
08:00 – 16:00
</td>
</tr>
</table>
 
Outage
Contacts
 
<table border=1 cellspacing=0 cellpadding=0
>
<tr>
<td valign=top>
Name
</td>
<td valign=top>
Title
</td>
<td valign=top>
Work
Phone
</td>
<td valign=top>
Alternate
Phone
</td>
<td valign=top>
Email
</td>
<td valign=top>
Hours
(M-F)
</td>
</tr>
<tr>
<td valign=top>
Henry Stad
</td>
<td valign=top>
Registry Information Coordinator
</td>
<td valign=top>
(780) 465-3500 x 8214
</td>
<td valign=top>

</td>
<td valign=top>
Henry.Stad@kingsu.ca
</td>
<td valign=top>
Tues-Thur 08:00-18:00, Fri 08:00-17:30
</td>
</tr>
<tr>
<td valign=top>
Glenn Keeler
</td>
<td valign=top>
Registrar
</td>
<td valign=top>
(780) 465-3500 x 8035
</td>
<td valign=top>

</td>
<td valign=top>
Glenn.Keeler@kingsu.ca
</td>
<td valign=top>
Mon-Fri 08:00-17:00
</td>
</tr>
<tr>
<td valign=top>
Will Ryks
</td>
<td valign=top>
Director, ITS
</td>
<td valign=top>
(780) 465-3500 x 8080
</td>
<td valign=top>

</td>
<td valign=top>
Will.Ryks@kingsu.ca
</td>
<td valign=top>

</td>
</tr>
</table>
 
 
 
Testing
Contacts
 
<table border=1 cellspacing=0 cellpadding=0
>
<tr>
<td valign=top>
 
</td>
<td valign=top>
Name
</td>
<td valign=top>
Title
</td>
<td valign=top>
Work
Phone
</td>
<td valign=top>
Alternate
Phone
</td>
<td valign=top>
Email
</td>
<td valign=top>
Hours
(M-F)
</td>
</tr>
<tr>
<td rowspan=3 valign=top>
Application
</td>
<td valign=top>
Glenn Keeler
</td>
<td valign=top>
Registrar
</td>
<td valign=top>
(780) 465-3500 x 8035
</td>
<td valign=top>
 
</td>
<td valign=top>
Glenn.Keeler@kingsu.ca
</td>
<td valign=top>
Mon-Fri 08:00-17:00
</td>
</tr>
<tr>
<td valign=top>
Henry Stad
</td>
<td valign=top>
Registry Information Coordinator
</td>
<td valign=top>
(780) 465-3500 x 8214
</td>
<td valign=top>

</td>
<td valign=top>
Henry.Stad@kingsu.ca
</td>
<td valign=top>
Tues-Thur 08:00-18:00, Fri 08:00-17:30
</td>
</tr>
<tr>
<td valign=top>
Rick Toews
</td>
<td valign=top>
Assistant Registrar
</td>
<td valign=top>
(780) 465-3500 x 8123
</td>
<td valign=top>

</td>
<td valign=top>
Rick.Toews@kingsu.ca
</td>
<td valign=top>
Mon-Fri 09:00-17:00
</td>
</tr>
<tr>
<td rowspan=3 valign=top>
Transcript
</td>
<td valign=top>
Glenn Keeler
</td>
<td valign=top>
Registrar
</td>
<td valign=top>
(780) 465-3500 x 8035
</td>
<td valign=top>

</td>
<td valign=top>
Glenn.Keeler@kingsu.ca
</td>
<td valign=top>
Mon-Fri 08:00-17:00
</td>
</tr>
<tr>
<td valign=top>
Henry Stad
</td>
<td valign=top>
Registry Information Coordinator
</td>
<td valign=top>
(780) 465-3500 x 8214
</td>
<td valign=top>

</td>
<td valign=top>
Henry.Stad@kingsu.ca
</td>
<td valign=top>
Tues-Thur 08:00-18:00, Fri 08:00-17:30
</td>
</tr>
<tr>
<td valign=top>
Rick Toews
</td>
<td valign=top>
Assistant Registrar
</td>
<td valign=top>
(780) 465-3500 x 8123
</td>
<td valign=top>

</td>
<td valign=top>
Rick.Toews@kingsu.ca
</td>
<td valign=top>
Mon-Fri 09:00-17:00
</td>
</tr>
</table>

Other
Information
 
<table class=MsoNormalTable border=1 cellspacing=0 cellpadding=0
>
<tr>
<td valign=top>
Fax

</td>
<td valign=top>
(780) 465-8321
</td>
</tr>
<tr>
<td valign=top>
Address
</td>
<td valign=top>
9125 - 50 Street, Edmonton, AB T6B
2H3
</td>
</tr>
<tr>
<td valign=top>
Notes 
</td>
<td valign=top>
 
</td>
</tr>
</table>
 
</div>

Marks Entry

2011-02-04T21:56:16Z

WikiSysop: New page: = Marks Entry = On the main toolbar click the image:Result_MTB_icon.jpg button, or choose, from the main menu, File | Course Results, or the keyboard shortcut Ctrl R. This will open t...

= Marks Entry =

On the main toolbar click the [[image:Result_MTB_icon.jpg]] button, or choose, from the main menu, File | Course Results, or the keyboard shortcut Ctrl R. This will open the Course Results window. Select a year, term and course from the boxes at the top to display the members of a class.

[[image:Course_Results_Win.jpg]]

Grades may be entered by either highlighting certain students and clicking the Edit Selected button, or by simply clicking the Edit All button. For each student a grade entry window will appear.

[[image:Current_Students_Course_Registrations_Mark.jpg]]

When a grade is entered here it is tested for validity against the grading system. Once grades are entered, the Save and Cancel buttons are enabled. The entries can be discarded through the cancel button, while all the entries are saved through the save button.

Results

2010-09-23T03:46:03Z

WikiSysop: New page: Results covers the entry of grades. Normally this would be done one class at a time for an entire set of course offerings in a given year and term; for this see Marks Entry. However, i...

Results covers the entry of grades. Normally this would be done one class at a time for an entire set of course offerings in a given year and term; for this see [[Marks Entry]]. However, it is also possible to enter grades for one student in the Course Registration window; see [[Individual Grade Entry]] for details on this.

Return to [[Main Page]].