« May 2005 | Main | July 2005 »

June 30, 2005

Employee leave

The employee leave system here at WOU is a legacy system that’s been around since before Banner. It’s essentially a set of spreadsheets used by HR and payroll. When HRIS/FIS went live, this shadow leave system was supposed to be discontinued. In the meantime, I was asked to create a feed into Banner. This resulted in several meetings with ETS to ensure we correctly populated Banner. Here it is 6 years later and it’s still here.

Essentially, the spreadsheets are used to create a comma delineated file which is sql loaded into a WOU Banner table. From there a job submission program,PZPLEAV, is run to feed it into the Banner tables. The difficulty comes from the use of spreadsheets. Classified and unclassified employees have different categories of leave so different control files are needed when doing the sqlload. You have different control files for different spreadsheets. The departments are constantly adding new columns to the spreadsheets which means you have to do a lot of work to it before it is ready to be sqlloaded. In addition, there is no error checking of names and IDs on a spreadsheet so you get incorrect data or sometimes differently formatted data in the same column. All this makes it next to impossible for any backup for me to be able to go in and feed leave if I’m unavailable.

Posted by wendlerb at 11:46 AM | Comments (0)

June 24, 2005

Fac Web

Several web for faculty packages weren't working in Banner 7.1 All I get is dreaded page not found error which means nothing. After looking through code, saw a function call to another package. Sure enough,found a bug in package SECTALL with statement twgkwbis.P_CloseDoc('1.1'); causing error in compile. Changed it to twbkwbis.P_CloseDoc('1.1'); and it seems to be working.

Posted by wendlerb at 11:46 AM | Comments (0)

June 23, 2005

FZRUINV

I’ve been fixing an old Open/Unapproved invoice report originally written way back in ’95 long before I got here. It was not set up to handle multiple invoices and the amount calculation was incorrect. I’m surprised that neither Dale or Susan ever mentioned that the amounts were sometimes off. Anyway, Fzruinv now lists out the vendor invoice on multiples and calculates amounts consistent with Banner.

Posted by wendlerb at 3:02 PM | Comments (0)

June 22, 2005

To AR or not

The business office enetered an incorrect parameter in a job sybmission program and stuck approximately 4500 AR holds on student records. Luckily, I could remove them once I got back from class so he could run it again this time with the correct parameters. For a while there, the front office came unglued,lol.

Posted by wendlerb at 11:11 AM | Comments (0)

June 21, 2005

Payroll checks

Check printing in payroll has undergone significant changes since we went to Banner INB forms. It’s worth noting, however, that the old client-server setup still exists and has saved our butts on a few occasions. We will lose this when we upgrade to banner 7.1 unfortunately. Payroll uses a pair of Troy 524 Micr printers. Unlike the Troys we use for SIS and AP checks, there is no special dimm in this printer. Although the check printing process is now run from job submission, the client it runs on still has to have the printer set up on the machine as a shared printer with the software font dimms added to the driver as well as the fonts to the windows folder. The name of the printer has to match the Banner queue. The driver for this Troy has the same HP name as the driver for the corresponding HP printer but it is a different driver. Payroll has manuals for how to print a check. The only thing that might foul you up is if popups from OUS aren’t enabled or the domain of the client changes. Also note that the payroll check process will allow you to reprint a check. A lot of times if something goes south, you can just do a reprint on the check.

Posted by wendlerb at 1:40 PM | Comments (0)

June 20, 2005

Disbursement goes live

Only 9 records created over the weekend. All released aid correctly but check process didn't cut check for two grad students. Found bug in swpbchk grad check routine looking for a Y instead of a T. Fixed now so grad students will get check cut. Only 2 new ones since this early morning. Not a lot of aid out there for summer.

Posted by wendlerb at 11:16 AM | Comments (0)

June 17, 2005

Disbursement

This goes live over the weekend. Powerfaids turns off disbursement page on the menu when loading aid into memo and then turns it on when finished. This is causing headaches because sometimes you want to leave it off and the process turns it on every morning that it runs.

Posted by wendlerb at 1:46 PM | Comments (0)

June 14, 2005

Disbursement on web for student

The front end of the financial aid disbursement page on web for student is actually fairly simple. The student selects the term and then gets to see the aid he has loaded into Banner. He can either release it, decline it, or leave it undecided for now. The system will remember what has been declined, what has been accepted, and what is still undecided. Currently, we are only allowing one term to be available at a time. In the past when a student declined aid, he filled out a form and the aid was zeroed out in tbrmemo later by staff. Now, the aid gets zeroed out immediately so it can’t get reinstated without a trip to financial aid. If the student is owed money, a record is created in a collector table. The job submission program, szpbchk, is run which populates these records into the normal student check printing process.

The real work of the form is on the back end making sure aid is not released to the student when it shouldn’t be according to WOU business policies. There’s error checking against credit hours taken. This takes into account part time students on the financial aid list as well as part of term 3 credit hour scenarios. There’s a check to make sure the student is set up with a revolving charge account. There’s a check against several holds which stop release of financial aid. One hold prevents money being paid out to the student which is earmarked for being returned to their parents. The actual amount which can be cut on a check to the student has to have this amount removed. The program must also determine if a third of tuition was paid and if money is owed from previous terms. Recent additions check if Visa payments were paid tying up funds. A record of the released aid goes on tbraccd just like it would if you released it from Banner.

Posted by wendlerb at 9:27 AM | Comments (0)

June 8, 2005

Financial Aid/Banner Feeds

Powerfaids and part time student lists are done every morning in a cron job. The part time student list is done one term only (instead of all terms) and transferred from financial aid’s server to a directory on spruce every morning at 4:15 am. This info is used in the financial aid disbursement package on Banner Web for Student. The FAIDS file transfer runs shortly after. The files controlling these two transfer process are on the shared drive on maverick. The Banner process on spruce which takes those files and feeds Banner,SWBRPFD, runs at 5:30 am. There is logic in SWBRPFD.COM that only runs it if the date of the faids.dat file is the same as the system date. This was set up to help prevent it from double loading data into Banner when no new faids file was transferred into spruce. Note that this only checks against day so you will double load Banner if you run from job submission manually after the load ran that morning via the cron job. The latest part time student file is always loaded regardless. Financial aid uses POE instead of term code. The table to crosswalk this is faids_term.

The direct loan feed is also a cron job on spruce which runs nightly on spruce at 8 pm. It is called SWBRDLL and is different than powerfaids in that it can be run more than once without hurting anything. The file transfer from financial aid (anticipated.txt and loan.txt) to a directory on spruce takes place at 7 pm. This process is on wolfman. There is also another cron job on spruce which runs at 8:20 pm that emails the financial aid accountant telling her if the direct loan feed was successful or not.

Both direct loans and powerfaids load financial aid into Banner's memo table and must be released manually before getting applied to student's account. The new financial aid disbursement process on web for student will let the student do this himself.

Posted by wendlerb at 11:22 AM | Comments (0)

SIS report file

I'm up to about 180 active Banner jobs and processes used at WOU. I'm guessing that's about half.

Posted by wendlerb at 9:19 AM | Comments (0)

June 7, 2005

AP Checks

The AP check printer is also a Troy MICR 4100 Secure Ex. It also has dimms containing files for the logo, seal, signature, and page format. These are files 16,17,18,19 on the dimm. The code in the program for these files looks something like CHR(27)||'&f16y3X'. The files themselves are in a directory under the business office folder. Use the bi-directional parallel cable, go to that directory in a dos prompt, and copy the files to the printer using the command copy filename.all lpt1. The tricky part is that these files are set for directory 0 on the printer. This is ok for moneymachine and cha-ching but sischeck has all its stuff in directory 1. The Banner queue for the AP check printer is w_moneymachine. The Banner job submission to print checks is FWPCHKP, another WOU mod of baseline. Most other OUS schools don’t use this but run a program similar to our payroll check printing for their AP and SIS checks. In our case, it actually saved us a lot of headaches when we went to INB because Oracle Reports didn’t work correctly. FWPCHKP prints checks off several tables such as fatckin. The next step in the process is running a job submission to post the accounting. This is noteworthy because once the records are posted to accounting, the records in the tables used by the check printing(FWPCHKP) process are purged. When trying to debug an issue that came up during the check print, you can’t regenerate it once its accounting is posted.

Posted by wendlerb at 11:54 AM | Comments (0)

June 6, 2005

SPAIDEN

Bug Description.

For records generated with no SSN, user goes back into form, types in V number,pages down into form, enters SSN into id field, and hits save. Spriden SSN record is created but the spbpers_ssn field is not populated. It works fine on a normal record creation. Only see problem with records already having a V number. Noticed form does not do the normal field updates after post insert. Tried a number of tricks in post-insert trigger to populate field but none worked. Found that if user tabs over to biographic screen and enters manually, everything works ok. Since screen is right there, Banner team decided to have user do this to solve problem.

Posted by wendlerb at 10:12 AM | Comments (0)

Check Printing SIS

The SIS check printers are Troy MICR 4100 Secure Ex. These are essentially an HP 4100 with a Troy dimm added to handle the micr font. The Banner queues for the two printers are w_sischeck and w_cha-ching. The signature, seal, page format, and logo on the checks are all pcl/macro files on a flash dimm(G7 Productivity Systems) in each printer. You can get a listing of files from the printer menu. The files were created using TransForm, a software package by Mips dataline America,Inc. The files are passed to the printer via a bi-directional parallel cable (ie. copy page.all lpt1) from command line. You can look at test1.all as an example of sending commands to the printer to see if a file is printing correctly (copy test1.all lpt1).

When you cut a check in Banner SIS using the WOUCHEK form, you are populating a collector table. The job submission program, SWBRCHK, is set up to run in sleep/wake mode every 20 – 30 sec. This sleep/wake job passes 5 parameters to the job TGRZTCH. This job checks the collector table and prints out a check for the records in the table. TGRZTCH is a mod of baseline and contains the Troy micr font PCL setting as well as the calls to the 4 files on the printer dimm. If you change the name of a file on the printer, you have to change it in the program too.

Posted by wendlerb at 9:51 AM | Comments (0)

June 3, 2005

The SIS - FIS/HR link

At WOU, SIS and FIS/HR are on two separate databases. The production databases are wouprd and wops. We have tied the two systems together through the individual’s spriden id records and a Saturn link. We want an employee or student to have the same id in both systems. In order to do this we had to choose one database spriden table to hold the records for both systems and in our case, it’s the FIS/HR spriden table. The spriden records you see in SIS come from a view of this FIS/HR spriden table. There is actually no spriden table in SIS.

Baseline Banner uses a sequence to generate a new V number id and a table to generate new pidms. Our mods have not changed pidm generation and thus an individual’s pidm on FIS/HR is different from the same person’s pidm in SIS. The baseline spriden table in FIS/HR was modified to include a column (spriden_wouprd_pidm) to cross reference the two pidms. V number id generation is another story. One sequence has to be used for both systems. In order to do this a table trigger on the FIS/HR spriden table is used to generate a new V number spriden record when a new ssn record is inserted into the table. In the case when “GENERATED� is used to create a spriden record, the spriden record with the id “GENERATED� is actually inserted into the table causing the trigger to fire and creating another V number record. The record with the id of “GENERATED� is later deleted in a post-insert trigger form mod.

Posted by wendlerb at 8:41 AM | Comments (0)

June 2, 2005

Taming Chaos

I have begun to try and get a handle on all the sis programs we have out there by starting out focusing on job submission c programs. There are also sql scripts, stored procedures, pearl scripts, and God knows what else. It's obvious we are going to have to create some type of user request form similar to FIS/HR to keep track of these. I'm finding that I've written student reports myself that I can't remember who they were for.

Posted by wendlerb at 8:52 AM | Comments (0)