Recently in Banner Category

Last week seemed to be taken up with a lot of error fixes with CPR. First, the archives pages does not take into account if a change requester leaves/retires from WOU and is no longer in the directory. When it would attempt to list that request, it would crash the page. I believe this was also causing the Job that runs the ucs.email program every night to fail as well. I've decided to list the request and requester, without attempting to go out and find the department and division associated with the requester. This will still keep the information on the request, without crashing the program.

I then received an email from Ross yesterday that the email job is crashing again for a different reason. I couldn't duplicate the error in testing, so I changed a couple lines of code and am hoping for the best. I've asked Ross to keep an eye on the job and see if that fixed it.

I've also started on the Scholarship application. The application part is fairly straight forward, but verifying that the student has already applied before filling out the application can be tricky if they did not apply for admissions on line, or their paper application has not been loaded into Banner yet.

I was also wondering how we would reconcile the admin/review part for the app with online _and_ paper applications to review together.

Next week I'll be finishing the new archive page for CPR, as well as getting the scholarship app ready for first round of testing.

Back to work in the new year. Though it's been a chilly couple weeks, I have to admit, I like this better than rain, but that's soon to be back.

After time off, there's always a list of issues or problems that have occurred that need to be addressed. So far, here's my list:

- Classroom services request form was throwing errors on submit. Come to find out, it was still using cougar as the mail server. I changed that to outgoing, and then the utl_smtp.helo server to ora.wou.edu. That fixed it, so I did a search on all the code for cougar and changed any place it was used for the mail server, I changed it to outgoing and recompiled.

- The International admissions application is now complete and live. I've changed all the links from the old online application to the new one and also went through and changed the links for the pdf version to the newest one wherever I could find it.

- The graduate admin application to view admissions apps was the same as the one for the undergraduate admin, so I made some modifications to it to more reflect the different process the grad office uses for applications.

- I've gotten two reports that graduate applicants are having a problem inputting their address information. One was second hand email, and I couldn't duplicate it, but the second called and I logged in as her and put in the exact information she was trying and it worked fine. She was using the same browser (Firefox) as well, so I'm not sure what's going on there. I'll just have to keep an eye on it.

- I received an email about a new process for CPR (Course and Program Request) for adding a Writing Intensive Committee. I'm not quite sure how that's going to work, so I'll need to meet with Ellis before I proceed.

- The scholarship application meeting will be next week, which I'm actually looking forward to. I need a new project.

- For the rest of this week, I'm going to attempt to figure out what is going on with the application to banner process. That has just been a nightmare from the beginning, but I hope to have it fixed soon. I know those at the admissions office would be happy to have that fixed.

- Richard told me that some students were still going into the wireless app to "sign up" for wireless service, even though they no longer need to do this, and it's throwing an error. I'm going to do a usertype check and just not let students get that far anymore.

So I got an email from Mike Huber stating:

Mike Ross was able to kill the job running on ora (the test instance) and we'll be able to test again tomorrow when the job runs again (on production) to make sure everything is working correctly.

We finally were able to have our first meeting to get the online international app started. We were able to go over the current online application as well as the updated paper application. I'll be creating a new online application that will work very similar to the undergraduate and graduate online applications, giving the student a non-ldap account which will allow them to log in, start an application, and come back later to finish, rather than just giving them one shot to submit everything. This will also reduce the load on the international admissions office going through multiple applications from the same student.

We will reduce the number of pages that they are currently required to print out and mail in. They will still need to print the Financial page and of course mail in official transcripts, etc. Eventually, I will make the application load to Banner and possibly to Hobsons (which I have no idea what this is).

Getting most of the kinks worked out of the admissions application load into banner. There's still the issue of the charge for the application fee being put on the student record, and when it's needed. Most students should already have it on there as they will be paying online, which puts all the correct records in tbraccd. But when the student does not pay online, and admissions wants to put their data into banner, that can cause issues. It's easy enough to create a new user with pidm and vnumber, but the money part is very picky.

I've also got all the current api for loading data into the banner tables working pretty good. The high school information will not load unless there is an exact match on the school name, so I'm going to see if I can change the application to have a drop down box based on school city and state, with an "other" box. With how many schools are listed in banner now, that other box will not ever be used, but you never know.

My pre-programming meeting with admissions, it was decided to always insert into students as non-residents until it can be manually verified they are a resident and then changed at that time. It was also decided curriculum data would not be auto loaded either. But now it seems both of those decisions may be reversed, so I'll have to make those changes at that time. Hopefully it will be fairly straight forward, but I'll need to research what the correct api would be for those forms.

There have been cases where spaces are being allowed in names of students who are applying on line for admissions. When these students pay, their record is then created in spaiden, using the information they put into the application. Since it appears that students are adding spaces to the end of their name(s), it's creating havoc in banner, making it difficult to find students and search not working.

Doing a search on first name within the admissions table for trailing spaces, I actually got 720 records! I changed those records to remove the trailing spaces and fixed the code when students apply to trim all trailing spaces from names.

It looks like the admissions application is back in the picture - did it ever really leave? Now they would like the admissions application to link with Banner so they no longer have to manually type in the information from the applications (since they are on different DBs). It would have been nice if they'd let me do this from beginning, but alas, politics. At least we're now working with a better credit card piece as well as starting on ACH. Hopefully that will be up and running soon!

I received an email from Nathan that he was unable to send transcripts and was getting the error "Current Status ZZ: error reported". EDI.Smart has never been extremely help with error handling, so I had to do quit a bit of digging through the transaction log to figure out what was going on. I noticed that it appeared to be the same data set that was the hold up, but it had one too many numbers in the identifier. I traced it back to the original transcript that had an error in the data file when it was created and then it appears that on resending the transcript, it added a 1 to the end of the ID, thus making it invalid from that point on. I modified the original data set and scheduled it to resend and it came back just fine. I'm still not sure why it was originally messed up, but at least I know everything is still working. We've been able to receive transcripts the entire time, and I didn't see any other outgoing issues from our end, ie acknowledgments. Hopefully it was just a weird glitch that won't recur, but I'll keep my eyes on it to make sure.

On the topic of EDI...

My week was kind of all over the place. I've been working with Brian trying desparately to figure out why we're having duplicate credit card charges and duplicate pidm creation for the admissions application. We were able to figure out the pidm issue early on, but were still getting double charges and double entry into tbraccd table.

At first changes managed to have only one entry in Banner, but still charging the card twice. Half way there, but definitely not good. We decided to move the table lock up to before the credit card charge process and added a couple more logical checks before processing, and this morning we received the credit card report. "4 $50 transactions - no repeats" (wendlerb)!

I had added insert into a test table throughout the code where it was and when. There are still entries in the table that don't make a lick of sense, and it goes through exactly as expected when I run it, so I can't duplicate what's going on. But if it appears to be working, I guess I won't worry too much.

Well, we had the Banner upgrade this weekend. I had a compiler issue on spruce, but once that was cleared up and the mods in place, the testing went perfect this morning. All test cases reflected the appropriate changes, and I don't see any problems. I was a little worried, so I'm pleased that everything appears fine.

I've started working on a new application for admissions to contact students about important upcoming events or deadlines. They wish to send out emails and/or text messages based on certain criteria that should be met. Bill and I had a meeting today with Rob and Dorothy to fine tune the minimal information I had received on this project and to hunt down where all the information they may wish to filter on is located. I am still not positive if they will wish to be dealing with both admitted or pending students or both. I'm going with both just to be safe, and whoever ends up using the application can choose from among the filters. I have all the tables where the information is stored no matter the admission status, so it shouldn't be a problem.

We actually went live today, and EDI is in production for Western. Our consultant, Cheryl, said this was done in record time! Go us! Everyone did a great job. Thanks go out to Brian and Nathan Walters and Joe. Thank you so much for the support.

Phew!

I made the final (hopefully) modification to shrediy.pc. It stated that a student was not currently enrolled regardless unless we included current course work on the transcript. Since we do not currently do that, we had to remove that status indicator all together. We certainly can't have it state that a student is not currently enrolled if they may be. Put that in place and tested a student without a SSN and the modification, which worked fine. I had Brian move the file to production as well.

Nathan has started his week of testing. Everything is going well and all the timers are in place. I'm doing the file transfers from/to Banner, since we didn't want to set up those cron jobs for test, but they are in for prod. We're hoping to set up Chemeketa as our first trading partner and do the test Monday or Tuesday. Once that goes through fine, we'll change to production and be live! In two weeks time, we should be good to go.

Then on to OFAX...

Things are finally looking very good for EDI completion. I found out that the setup in woutst is not correct, so it's not looking at the mods for wou_sis_mods.exe, but rather osshe_mods.exe. Once we moved the shrediy and shredir files to that location, they worked like a dream. I knew there had to be something like this, especially when even the straight across conversions were not taking place. That was extremely frustrating, and I'm so glad we've got that part fixed!

Yesterday, our contractor, Cheryl, was here. We managed to complete quite a bit and I believe we're ready for our final test week which will be done by Nathan Walters. Cheryl is planning on returning Monday. The permanant location for EDI.Smart software and where file transfers will live have all been decided on and put in place. We'll have the jobs on a schedule and the file movement to be done automatically every day. Shrediy and shredir work perfectly with all modification in place. In our final testing, we'll want to be sure to have test cases for a student with a minor, no SSN, and one that is currently enrolled (should NOT show classes in progress). After the final testing, we'll make a copy of EDI.Smart for production, finish the documentation book we're putting together, inform Texas we're production, do a quick test out of wouprd, and go live! Very exciting.

Well, of course I'm still working on EDI. It's really enough to make me want to pull all my hair out. It seems that every mod I've made to shrediy.pc has never taken effect, ever. I've made all the modifications that have been done at the other banner schools and it's still not working, plus some WOU specific mods that are not working. It appears that the correct version of shrediy is loaded into woutst, so I'm not sure what's going on. I've asked Brian to assist me in ferreting out the culprit after lunch.

Wish me luck.

Last week was almost entirely devoted to EDI work. It's an extremely time consuming and frustrating project. I've been attempting to modify the shrediy.pc banner job to produce the output we desire to transfer transcripts, and it's just not cooperating. I've made all the changes that should have worked and it still insisting on pulling the vnumber rather than the ssn. For transcripts going to schools outside our system, a vnumber won't mean anything. Also, I added a mod that should add the second and third lines of the address field when submitting a transcript for edi to be used as a way to let partner schools know if this is a test transcript once we go live by putting in ***Test*** or some such text. Well, it seems to be pulling the address from somewhere else based on the school code you put in to tell it where the transcript is being sent and over-writing the address fields. I'm still plugging away at it. It's very time consuming to test since I do not have access to the banner job submission areas to move files to and from, so I have to wait for someone else to do the moving. Then the process to go round trip from us to the SPEEDE server and back and to load everything back in can take at least 1.5+ hours, for one test case. Cheryl has planned to come back tomorrow, but I'm not sure I'll be ready. I'm hoping to make some headway today.

The initial EDI install and setup are nearly done. We're able to request transcripts, run shrediy and manually move the files to where EDI.Smart looks for them, and send them off to the EDI SPEEDE server in Austin, Texas. The last piece that needs to be done is for the server to ftp back to us using their required public key. They were able to connect with a username and password we created for them, but they require the public key. Joe thinks it may be issues with our ftp software, so he's looking into that. We should have that up and going soon.

Yesterday, our EDI contractor, Cheryl Kolbe, was here to install and set up our newly purchased EDI.Smart software. The install and setup went very smoothly and it is now installed on ts5. We decided to put it there so, with the purchase of a connection, we can have anyone else in Admissions or the Registrars to be able to access the software, which will need to happen on occasion. Where we ran into issues is when we were attempting to run the shrediy process on woutst. Once a transcript request was submitted through banner (on woutst), shrediy was run and produced the one line of header and the final line, no data. We came to the conclusion that woutst was not running something we needed (job submission) to be able to run this since we couldn't get a paper transcript out of it either. Today, Soukup and Brian helped me out and we now have woutst working correctly with output! Very exciting. Cherly is to come back on Thursday, and it would have been a wasted trip without getting this output. I'm very happy we're back on track.

I've also modified our shrediy.pc file and will have it uploaded back to woutst. This just changes layout only. I'll also need some assistance from the Banner team to help with a grade issue unique to Western. Pre-1994, we only gave grades A-F without plus or minus. Now, we also give plus and minus grades. This will change the grade qualifier when we send the transcript out.

I had my first meeting with Cheryl Kolbe, the consultant for our EDI setup last week. Since we did not have EDI.Smart bought and installed, it was mostly just an informational meeting. We went over what will need to be done and all the requirements. We should have EDI.Smart by the end of the week and Cheryl is scheduled to be back next week. When we're set up, we'll be starting with university trading partners:

• Oregon State University
• Portland State University
• Southern Oregon University
• University of Oregon
• Oregon Institute of Technology

• Clackamas Community College
• Chemeketa Community College
• Lane Community College
• Linn-Benton Community College
• Portland Community College

Hope everyone is having a green day!

I had a meeting yesterday on my EDI project for dual enrollment. Because of the big push for the online application for admissions and the IRB application being completed, I've really only been looking at code and reading the mailing lists concerning EDI, I haven't been able to get to the coding part.

I've been working on a new Alumni tracking program for the past couple days. It's actually a fairly easy job and I've already got the first step done. You can view it here and log in using your wou email username and password. It pulls information from ldap and the Banner tables to display what we currently have on file, and then gives the option to edit. There's also a place to fill in information on a contact person who will know where you will be, and other data fields. Feel free to play, it's currently only going to a local table. I'll need to make it update the Banner email field and then have other programs that will pull the data and insert it where it needs to go within the Alumni and COE databases. This form will be required to fill out before the student will be able to apply for degree/graduation or view or receive final transcripts.

I guess there was an issue brought up that if a student attempts to log in more than three times, the account gets disable. If they then retrieve their pin through my new program, it still will not allow them to log in. Since my package was on aero, I was using a database link to get the pin out of the gobtpac table on wouprd. This link only allowed queries, not updates, so I asked Brian to help me figure out a way to update that table and make sure the account is enabled once they retrieve their pin. He was able to modify the gobtpac view to use the wouprd_upd database link and then I was able to write a procedure as wou_util to update that field based on a pidm. Then my program calls this procedure once the pin has been sent.

I've finished up the Banner pin retrieval Nancy was wanting. This takes the student's wou username and emails their pin to their wou email. Then all they need to do is log into email and retrieve it. If they have forgotten either their wou username or password, they can go to the account lookup page. This way, everything if fully automated and will not require any intervention from the Registrar's office.

I've now been assigned the IT side of the streamlined dual enrollment partnership, starting with Chemeketa. I'm just starting by collecting information, since I know almost nothing about this project.

I've contacted Donna Fossum in FA and have set up a meeting for tomorrow morning. I've also received some contact information from Jeremy Hickerson (now OSU) and have been pointed in the direction of some online documentation for EDI within Banner. I'll need help from Faye or Michele to find out exactly what I need to do to gain access to this documentation.

For IT side of dual enrollment, the list includes:

• Support for OFAX
• Support for EDI
• Create new Banner screen for Financial Aid
• Host School excludes credits from Clearinghouse reporting
• Home School adds credits from Host School for Clearinghouse reporting

The staff permit application seems to be working. It's worked for the few that have purchase permits so far, but the real test will be when the masses go for it. Keeping my fingers crossesed, esp since Brian will be on vacation all next week.

I've modified the account lookup application to work with both kitty (old server) and sundown (for those migrated). As soon as everyone is migrated, kitty will be going away, so I'll need to modify it again then. For now, it will ask you to agree to the tech agreement everytime, but that should be fixed next week. It does change you're password, which is what counts. Just make sure to check if you've been migrated or not, as this is what points to a particular server. Obviously, if you don't know if you've been migrated or not, the most likely answer would be no, which is the default.

Travis and I are also looking into connecting to Active Directory from Oracle, since we are able to sync from AD to ldap, not the other way. This will make passwords uniform across domain login and email! (Also saving us a big chunk of change for having to buy certificates to be able to sync from ldap to Active Directory.)

Well, the staff parking permit page is going okay. Of course, I can't really test it, as part is development and part is production and at this point there is no way to completely separate the two. I'm looking forward to discussing options with Brian and Darin. Hopefully we'll be able to come up with a solution soon.

My first Banner project, student parking permit, is now in production. Brian has helped me move wou_park from woudev to wouprd, along with a supplementary function I created. Keep your fingers crossed.

Now, students have the option to have their parking permits mailed or to pick them up at the cashier (previously the only option). It also tells them what we have as their current mailing address so they know exactly where it will be headed. Hopefully this will also keep the records updated when students find out what's on file. Two birds with one stone.

I think I've got the student parking permit on-line application updated. Working on Banner is extremely nerve-racking, since there really is no way to test your applications and everything on wilbur is live. This is especially dangerous for me, considering I'm the queen of breaking things. I really like having a test environment. Fortunately, I've only needed to make minor changes and I've kept backups of the previous version (learned the hard way), so it should be all good. I'll probably be able to move this form onto production tomorrow. Then it's on to bigger and messier things.

I've begun my work on Banner, and it's off to a shaky start. As far as I can see, the names are made up completely by random and there are about five to ten procedure calls to produce one line of output. Extremely frustrating to say the least. Fortunately, I'm working only on woudev, so (most) any mistakes won't be live. I'll try not to buy anyone else a parking permit :)