The Attic

EOU called and told me they had a PO that wasn’t showing up in any approval queues.  I checked to make sure posting was running and it was.  I found it in fobuapp but still with a status of new.  I ran forappl manually so I could see the lis file and found an error for it which said it couldn’t find a limit for the queue.  Looking for the queue id, I couldn’t find it anywhere.  The system could not route the PO to an appropriate crew.  EOU told me the user uses key strokes so fast, the various forms don’t always get a chance to complete their tasks.

Solution: I had the original user go into the form FOADOCU and deny the PO.  It has to be the original user.

Well, after we figured out how to do checks we found EOU wants to feed the ERFD detail code tbraccd records through the feed and process as ACH in the AP direct deposit run.  This has proved to be a challenge.  I’ll try to summarize what we’ve tried and where we’re headed.

At first we wanted to change the prefix on these records from SD to SE.  This was because EOU currently in production processes these SDs in a different way.  We found that the feed didn’t bring these records across correctly and quickly abandoned the idea.  So we went back to SD.

Fzbchks and fzbchkp had to be modified to leave the SD records open and fabchks records to be generated correctly for these SDs so they could get picked up by an AP run.

AR documentation states that if you leave the address type and seqno fields null on the gxrdird record, the direct deposit steps will process the records from the feed with whatever address type and seqno comes across on the fabinvh records generated during the feed.  We found this not to be the case with the farinvs report because of an osshe mod for AP which requires an address type/seqno.  I wrote a program,fzrinvs, to pick up these SD records anyway.  We at first tried to update the gurapay record that gets fed with a addr type/seqno of ##/0 because that’s what the osshe mod defaulted for a null record on gxrdird.  This however caused other problems.  We really wanted to get it to work with the null typ/seq on the gxrdird record and any addr/seqno combo on the gurapay record.

Fabchks had an osshe mod on it to exclude SD docs.  We needed to include them again so I made a new mod to it for EOU.  We also discoved the web tool students used to put in their bank info was creating a gxrdird record with a pre-note status and setting it to payroll.  Still working on how to fix that.

I finally got a student through fabchks and fwpdird, created a direct deposit file, but then got an abort on fabchka.  Investigating this determined that fwpdird was not populating the fatckin_check_num field like it should because….yes, we had null values for gxrdird atyp/seq fields.

So, now Jeremy and I are trying to update the gxrdird record with the addr/seq combo from the gurapay record.  Before we were modifying the gurapay addr/seqno record but that caused problems later in the feed.  On the positive side, I think I can get rid of fzrinvs if we can achieve this.

EOU now has 3 checks that they produce: A/P checks, student checks, student refund checks.  The feed has to deal with 2 of them without screwing up the A/P check process.  In order to accommodate this,  on demand student checks now use a SC prefix instead of SQ.  This is to prevent the feed from printing them.  Student refund checks are set up as SQ so they can be printed during the feed and are loaded via an ar process.

In order to achieve this I had to modify some programs called during the fis portion of EOU’s ar/fis feed.  At first we had the accounting posting for SC checks fed but not the check.  I had to add the SC type to fwriapp.sql which updates the fabinvh_appr_ind to Y to fool the system into approving the checks.  This is a local mod.

Fzbchks.pc was changed to populate fatckin_paymt_type_ind. Fzbchkp.pc was changed to not set fabchks_ach_ind to Y for SC checks. Fwpchkp.pc was changed to not print the SC checks.

Ellucian Live had 2 motivational speakers this year at the opening and closing sessions who were pretty good I thought.  I know some prefer a celebrity but they did a nice job.  The conference for the first time combined sessions of Banner and Colleague (formerly datatel) which caused some confusion at first.  The first FIS session I went to was a Colleague one and I couldn’t figure out what the heck they were talking about till I realized it was a different product all together.

Several talks pointed out that their product map is out there for all to see so this is obviously an emphasis for the new company.  There was also some emphasis on the code sharing repository with several talks on it.

Banner 9/horizon has become Banner XE.  It is still using the groovy/grails code but Ellucian has backed off using Spring as a frame.  They’ve come up with using git as the means for distributing their source and there is some set up involved in using it along with ssh keys.  They kept pointing people to Banner Commons for setup and information but I found very little in the way of definition for setting up the architecture as far as step by step instructions go.  They’ve got a ways to go.

Banner general has some nice new features and Banner finance has mostly rpe fixes.