1 / 62

Colleague Financial Aid Rule Writing & Troubleshooting

Colleague Financial Aid Rule Writing & Troubleshooting. Presented by: Colleen Olsen Financial Aid Coordinator Elmhurst College May 21, 2013. Introduction to FA Rule Writing. Where rules are used in FA module How rules are evaluated Elements required to write rules

radha
Download Presentation

Colleague Financial Aid Rule Writing & Troubleshooting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Colleague Financial Aid Rule Writing & Troubleshooting Presented by: Colleen Olsen Financial Aid Coordinator Elmhurst College May 21, 2013

  2. Introduction to FA Rule Writing • Where rules are used in FA module • How rules are evaluated • Elements required to write rules • Rules versus Rule Tables • Define the steps used to write rules • Decide on the rule that needs to be written • Conduct research to find the data needed • Map out the rules needed and code them in the system • Test the rules with test data

  3. What are Rules? They allow institutions to customize a method of action in the FA Module within Colleague. Rules can often be used instead of custom programming, keeping IT out of the process They can be a means of interpreting an institution’s policy so that Colleague can understand and react to that policy. Depending on how complex the rules are, they fall anywhere between reporting and custom programming. They are used where is flexibility is needed due to the variety of institutional policies that are present.

  4. Where are rules used in FA? General Set-UpCommunication Management: LCRL- Location Rule Table CRA- Correspondence Request Assignment FRCP- FA Registration Credit Rules CRRD- Correspondence Request Definition PATR- Attendance Pattern Rule Table DOC- Document Paragraph Rules FPRL- Full/Part Time Rules GEC- Global Eligibility Rules Packaging: AEC- Award Eligibility Rules PDRL- Packaging Definition Rule Table BDRL- Budget Definition Rules PCRL- Packaging CB/Inst. Rules (sub-screen) SBRD- Student Budget Rules PERL- Packaging Eligibility Rules (sub-screen) AAXL- Award AR Transmit Limits PARL- Packaging Amount Rules (sub-screen) AAD- Award Amount Definition PCTR- Packaging Percent Rules (sub-screen) PGRL- Packaging Group Rules (sub-screen) Electronic Loan Processing: PYRL- Packaging Years (sub-screen) HRRL- Loan/Hold Release LTRL- Loan Processing Rule Table Web Advisor/Awards: ADRL- Award Letter Satisfactory Academic Progress: ALRT- Award Letter Rule Table SPTD- SAP Type Definition (Multiple Rules)

  5. How are rules evaluated? The result initially from the evaluation of a rule is either Pass or Fail, no matter how complicated the rule. In FA, there are processes that require multiple rules to be evaluated. (Example: Budget Rules, Eligibility Rules, Correspondence Request Rules) Three ways that Colleague deals with multiple rules: The first rule is passed and the attached result is assigned; therefore the order of your rules is extremely important. All of the rules are evaluated and then the results of all passed rules are assigned. All of the rules are evaluated and must pass in order for any results to be assigned.

  6. FIRST TRUE RULE…ex. PATR/SPTD/BDRL We have 12 SAP Status Rules which assign an associated status Once the student passes a SAP Rule, they are assigned this Status and will not be evaluated against any rules further down into the table

  7. Our SAP rules: These are all of the possible 12 rules that a student could be evaluated against at our institution until they passed one rule, and then they would be assigned the appropriate SAP Status.

  8. ALL TRUE RULES…ex SBRD/CRRD/DOC All of the rules are evaluated and then the results of all passed rules are assigned.

  9. All Rules must PASS…ex AEC/FRCP/GEC Award “GSL” contains 3 Rules

  10. Elements required to write rules Primary File View: determines the data elements available to us in writing the rule – using co-files, pointers and computed columns allow access to data from other files Rule Connectives: determine how the rule is processed – WITH, AND, EVERY, OR, WE (WITHEVERY), ORWITH, OREVERY, OWE (ORWITHEVERY) Left Hand Expression: must be a Field in the Run-Time Central Data Dictionary (CDD) – available fields determined by Primary File View Relation: how to associate the Left Hand Expression to the Right Hand Expression Right Hand Expression: may be a literal value in quotation marks or a field from the Run-Time CDD (no quotation marks)

  11. How do you determine the Primary File View? Write rules from within the FA process where the rules will be evaluated. If you do a “Look Up” (…) on the field for the Primary File View on your rule, your view will be limited to the files from which you SHOULD choose! For example, rules on the Award Eligibility Criteria (AEC) form are limited to the TA.ACYR or TL.ACYR files for the Primary File View. The typical files used in the FA module as the Primary File View are the *.ACYR file suite files, FIN.AID SA.ACYR or CS.ACYR --Budgets (SBRD), Attendance Pattern (PATR), Packager (PERL, PARL) CS.ACYR-- (Correspondence Request rules (CRRD), MAILING (Paragraph rules for DOC) TA.ACYR --(Transmittal rules (GEC/AEC)

  12. Co-Files in Colleague Primary File Views used in FA: Sample Co-Files CS.ACYR: PERSON, FIN.AID, SA.ACYR, MAILING, etc. (any file keyed by the Colleague ID number) TA.ACYR: No Co-files SAP.RESULTS: No Co-files MAILING: PERSON, FIN.AID, CS.ACYR, SA.ACYR, etc. (any file keyed by the Colleague ID number) You may use any data element from any co-file in your rule.

  13. Co-file rule example: Primary file view is CS.ACYR, but field is in a co-file

  14. Co-file rule example: AGE can be used in this rule, as could any other data element in PERSON, or any other co-file Age is in the PERSON file, a co-file of CS.ACYR

  15. Pointers in Colleague If you can’t use a co-file, use a pointer! Pointers get us from the “Primary file view” to another file which contains data we need, and whose “key” is different from our primary file. Can be single-valued (X), or multivalued (Q) You may need to build pointers in RDEL on occasion, or simply “reset” a pointer by pulling it up on RDEL and saving out.

  16. Pointers in Colleague Frequently needed in the “USING” field on the RLDT form (detail from RLDE) • If you are taken to this detail form when writing a rule, you MUST enter some pointer value in the “USING” field or your rule will not return a value (the system does not know how to find the necessary value) • Do a “lookup” to find the available pointers from which you should choose

  17. Pointers in Colleague, example • CS.ACYR ISIR.FAFSA • CS.ACYR contains CS.FED.ISIR.ID, type X • The SINGLE key to the current Federally Flagged ISIR on NASU • The CS.FED.ISIR.ID is a pointer to ALL ISIR files (they all use the same key) • CS.ACYR contains CS.ISIR.TRANS.IDS, type Q • The keys to ALL imported ISIRs for this student for ALL ISIR files

  18. SNIP

  19. Data Element, delivered X pointer Note that this pointer points to multiple files

  20. Data Element, delivered Q pointer

  21. Virtual Field, custom pointer FA.ACAD.LEVELS Computed Column Codestring[] xlResult1; key xKeyStudents for file Students;xKeyStudents = vFaStudentId; xlResult1 = vlStuAcadLevels;return xlResult1;

  22. Rules vs Rule Tables Rules Stored in the RULES file Not inherently year specific Rules file is shared by all modules One or more pass/fail statements Rule Tables Stored in the RULE.TABLE.ACYR File Year- specific Used by the Financial Aid module only One or more rules OR a default value

  23. Developing Rules Five Necessary Steps to proper rule Development • Articulate the rule • Research your data elements using provided tools • Write the rule in English statements • Code the rule in the system • Test, test, test!

  24. Step 1: Articulate the rule • What is the purpose of the rule? • Write down exactly what you want from the rule • Computers do not make assumptions, you must clearly define your expectations • Define your rule in English statements

  25. Step 2: Research your data elements • How do you identify fields in FA? • FIELD HELP while on the field you need • Colleague File & File Suites • Information on file suites is in the learning guide • Know the commonly used FA files used in rules • CS.ACYR (person ID key) • TA.ACYR • SA.ACYR • And all co-files

  26. Step 2: Research—field help

  27. Step 2: Research—field NAME

  28. Step 2: Research—RFEI • RFEI is the data structure of the file • File key (you can determine any co-files) • Data elements • virtual fields/computed columns Recognize all associated fields, single and multi-value pointers, etc.

  29. Step 2: Research—RFEI

  30. Step 3: Write the rule in English Writing out the rule in plain English is the most efficient way to begin It provides back-up documentation if the rule needs to be reconstructed

  31. Step 4: Code the rules--RLDE • Accessing the RLDE form from the mnemonic that drives the rule ensures that the rule will be created from the correct view • Recommend entering the “English statement” rule in the comments area for completeness, or at the very least, the “purpose” for the rule • Allows those coming behind you to see the intent of the rule if someone modifies your rule.

  32. RLDE—FAAECRED sample rule

  33. RLDE—Context for primary file! From AEC, we have 2 files when we “lookup” our primary file view. Note that if we go straight in from RLDE how that changes

  34. RLDE--Rule example--FABRON Not in my file, this is an APPLICATION field—need a pointer!

  35. Rule detail form, RLDT Enter your “using” pointer value here

  36. Rule example from AEC example, above **This First Rule in “GSL” is checking the RULE ID FAAECRED to see if the student is registered at least half-time

  37. Example from AEC, rule 2 **This Second Rule within “GSL” is checking Rule Id FAAEENTI to see if a student has completed “Entrance Counseling”

  38. Example from AEC, rule 3 Rule ID FAAEMPN **This last rule within “GSL” is for checking to see if a student has an MPN.

  39. Step 5: Test, Test, Test! RLTD and RTVF VES for transmittals (detail on failed rule) SBGT or SBRV PKCR in ERV mode

  40. RLTD—Rule Test and Debug • Must have a key to the primary file • If the rule is written from an ACYR file, you must enter the year • Pay attention to the primary file • Errors out if you enter a year for a non-acyr file • Valid field if ‘passes’ • Invalid field if it does not

  41. RLTD—Rule test and debug

  42. RLTD—Primary file and Record ID

  43. RLTD—passing example

  44. RLTD—failure

  45. RTVF—Virtual Field Test & Debug • Am I getting the proper result from my virtual field? • Enter Data Element • If an ACYR Primary file, enter year • Enter Record ID from Primary file • Remember if a co-file of PERSON, you must enter the 7 digit ID including leading zeros

  46. RTVF—Virtual field test and debug

  47. RTVF—Data returned

  48. RTVF—No data returned

  49. VES—Test Transmittal Rules • Transmittal rules entered on AEC & GEC • Failed transmittal rules on FATR • FATR doesn’t tell you WHY, only the rule that failed • You can use RLTD on individual rules OR • VES for the Award Period • Pass/Fail status for all awards (AEC) • Indicates whether the student passed global (GEC)

More Related