CMPPAY-L Archives

UC Payroll Release Distribution Notes

CMPPAY-L@LISTSERV.UCOP.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Barbara Vanden Borre <[log in to unmask]>
Reply To:
UC Payroll Release Distribution Notes <[log in to unmask]>
Date:
Tue, 12 Jul 2005 18:32:28 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (77 lines)
This release issues revisions to the PPOT1646 SX lump sum bonus program,
and can be considered a follow-up to r1646.

The intention is that the cost of the lump sum payment will be split
equally between the department (pro-rated among active distributions for
eligible employees) and an IAP funding source,  using a DOS code of LSP for
the department-side transactions and a DOS code of LSI for the IAP
side.  The DOS codes are essentially the same except that LSI payments
are  to be counted as covered compensation and LSP payments are not.

As originally written in the r1646 version of the program, the IAP fau was
intended to be identified in the spec card and used in FT
transactions.  Several difficulties with this approach were discovered, and
have resulted in the changes coded in the r1655 version of PPOT1646:

- A site might wish to assign the standard IAP fau (the one in copymember
   CPWSXIC5) but not be able to because the traditional balance sheet
   fau format, without fund number or sub, would be rejected by transaction
   fau edits.
- Departments viewing the PPP5302 report would see only half of the
   SX lump sum activity because the other part would have been assigned
   a different fau and they wouldn't receive those pages.
- The PPP5332 IAP report consolidates IAP payment dollars by title unit
   within fund group.  The only means it has to determine the fund group
   number is to look up the fau among IAPBALNC entries in the FND table,
   and it can't do that for for balance sheet fau's with no fund number, thus
   half the charges won't be properly broken out in the report.

The solution issued in r1655 is to remove the previous IAP funding fau
logic and the spec card entirely, and instead rely on the regular IAP
processing to handle the reimbursement process.  Recall that a follow-up to
r1646 issued a change to copymember CPWSDOSC such that DOS code LSI will
now be treated just like IAP for this purpose.

What does this mean for you?

1 - Originally if an employee had 1, 2, or 5 eligible distributions, then
     1, 2, or 5 FT transactions with DOS code LSP and departmental
     fau's to proportionally share $125 of the cost, plus a single $125
     FT transaction with DOS code LSI and the alternate funding
     source were generated.  Now two transactions will be created for
     each eligible distribution, both charging the departmental fau,
     and identical except that one will be LSP and one will be LSI.
     In other words, the IAP fau will not appear anywhere in the
     transactions, and only the DOS code will distinguish the two
     parts.

2 - Because all of the transactions will be assigned departmental
     distribution fau's, the entire $250 payment will be viewable by the
     department in PPP5302 reports.

3 - Initially that makes it look as if the department will bear the
     entire $250 cost, however, at every site that has system parameter
     148 (IAP-RELIEF) turned on (that's all of our campuses, but not
     ASUCLA), the expense distribution process will kick in to reimburse
     ('offer relief', in a manner similar to financial leave accounting) the
     payments made under DOS code LSI, that is, 50% of the cost
     just as intended.

4 - PPP533 will find real fau's with fund numbers for the LSI payments
     in the EDW and thus will be able to ascertain the IAPBALNC group
     number for reporting purposes.

NEXT STEPS:

   Despite what seems to be a replacement (actually tagged as changes) of
program PPOT1646 in this release, we do still need to install a portion of
r1646, specifically modified copymember CPWSDOSC and various recompiles to
pick up the changes, therefore if you have not already given us an ok on
r1646, please do so.  Then we'll need your ok for r1655, so we can install
the latest and greatest version of PPOT1646 and make changes to the job
code.  Some sites have already indicated when they'd like the one-time
program run and/or in what compute they'd like to make the SX lump sum
payments.  If you haven't already done so, we look forward to hearing from you.

   bvb

ATOM RSS1 RSS2