« June 2008 | Main | August 2008 »
July 29, 2008
Table trigger summary
Admissions/Tuition Promise
st_saradap_update_row
st_saradap_insert_row
These set the rate code for incoming students
sarappd_insert_row
This sets the cohort code on students when the admit decision is positive. The endterm field gets populated from a cron job... szpecht.
Capp
insert_sgrsatt_from saradap
insert_sgrsatt_from sgbstdn
insert_sgrsatt_from_shrtram
insert_sgrsatt_from_sordegr
These deal with transfer students and populates the student attribute table with the appropriate attribute for Capp (AAOT,ASOT,ASOC)
Direct Deposit/AP
st_spraddr_insert_row
This syncs the 4 tables necessary for ap direct deposit to work on a person who updates an address. It syncs the atyp and seqno if it is a ap direct deposit vendor.
ID creation
st_spriden_update_row
st_spriden_insert_row
The big daddy. The insert one is a recursive trigger. It populates the ssn field on spbpers if the insert is coming from a student form. It checks against swbpidm to tell if it is an insert or an update. If it's a new record, a swbpidm entry gets inserted A new V number is generated from a sequence and gets inserted into spriden on the second half of the recursion.
Posted by wendlerb at 2:45 PM | Comments (0)
July 28, 2008
AP Direct Deposit
The address type and sequence has to match on 4 tables: ftvvend,goremal,gtvemal, and gxrdird in order for direct deposit to work correctly. The problem is it gets out of sequence when the address is updated via a form or the web between the four tables. I modified st_spraddr_insert_row to put the 4 tables back in sync if the address being inserted is the type on the gxrdird record with ap_ind set to 'Y'. The code shouldn't fire if it's any other address type being inserted. Worked ok so far when changing from ftvvend. Testing for via the web still
Posted by wendlerb at 10:37 AM | Comments (0)
July 10, 2008
Ftmvend
Added trigger CALL_FOAIDEN and changed guaoptm from form to trigger calling form
Posted by wendlerb at 11:46 AM | Comments (0)
July 9, 2008
Fwpchkp (cont)
and fatckin_vend_inv > rpad(:prev_rpt_vend_inv,25,' ')
This is the kicker. The prev_rpt_vend starts with a C and fatckin_vend_inv is MULTIPLE on multiples. The memo_detail procedure gets called multiple times from memo_body_psu. Not sure why. Anyway the line above prevents the detail from getting selected more than the first time through except it doesn't work on multiples. They get selected every time the program enters the memo_detail procedure in the loop in memo_body_psu.
I changed the line in memo_body_psu to:
strcpy(prev_rpt_vend_inv,"MULTIPLE");
Hope this works
Posted by wendlerb at 10:36 AM | Comments (0)
July 3, 2008
FWPCHKP
Once in awhile checks with multiples print the detail several times. It also doesn't page correctly which is wierd. There's a counter that formats a new page in the while loop that never kicks off. This is driving select statement
EXEC SQL DECLARE cursor_030 CURSOR FOR
select distinct fatckin_vend_inv,
TO_CHAR(fatckin_invh_date, 'DD-MON-YYYY'),
fatckin_net_amt,
FARINVC_VEND_INV_CODE,
TO_CHAR(farvinv_vend_inv_date, 'DD-MON-YYYY'),
farinvc_invh_code,
sum(farinvc_appr_qty * (farinvc_appr_unit_price) + farinvc_addl_chrg_amt - farinvc_disc_amt)
from fatckin,
farvinv,
farinvc x
where fatckin_check_num = :rpt_chk_no_an
and fatckin_invh_code = farinvc_invh_code
and farinvc_invh_code = farvinv_invh_code(+)
and farinvc_vend_inv_code = farvinv_vend_inv_code(+)
and fatckin_vend_inv > rpad(:prev_rpt_vend_inv,25,' ')
and fatckin_vend_inv is NOT NULL
group by fatckin_vend_inv,
fatckin_invh_date,
fatckin_net_amt,
farinvc_vend_inv_code,
farvinv_vend_inv_date ,
farinvc_invh_code
order by farinvc_vend_inv_code;
I just added a nvl to the first value because the loop depends on it having a value.
We'll see if it makes a difference
Posted by wendlerb at 9:40 AM | Comments (0)
July 1, 2008
Year End Cash Close
We hadn't tried running swbuglf while in restricted mode to I had the dbas put woutst in that mode and ran it. We found ban_wouprd needs to be in the restricted list ot fwrckno errors out. I also changed fwrckno to not use its logic of setting July 1 checks to June 30 since it runs now at night instead of the next morning like it used to.
The feed turned up 4 transaction errors last night that we had to fix before we copied the tables to fiscal01. These were because a fund was inactive so we had to reactivate the fund, fix the fdoc in finance, and then do posting and approvals to get it out of suspences. Tgrrcon and swrages numbers agreed so we ended up good.
Posted by wendlerb at 3:42 PM | Comments (0)