1 / 40

Security Management System for Department Sponsors

Security Management System for Department Sponsors. Session #20244 March 15, 2006 Alliance 2006 Conference Nashville, Tennessee. Your Presenters. Jeralyn Snow. Your Presenters (Continued). Terri Pinkston Controller for OU HRMS and Financials Functional Lead

dinos
Download Presentation

Security Management System for Department Sponsors

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security Management System for Department Sponsors Session #20244 March 15, 2006 Alliance 2006 Conference Nashville, Tennessee

  2. Your Presenters • Jeralyn Snow

  3. Your Presenters (Continued) • Terri Pinkston • Controller for OU • HRMS and Financials Functional Lead • 16+ years of Higher Ed experience • 20+ years of accounting experience

  4. Your Presenters (Continued) • Karen Sturtz • HRMS and Financials Implementation Technical Lead • 10+ years of PeopleSoft experience • 20+ years of IT experience

  5. Overview • Department sponsors use an on-line system called Financial Account Management System (FAMS) to maintain what data Campus Users have access to in HRMS and Financials and what functions they can perform. Information from FAMS is fed to HRMS and Financials to update various tables within the systems.

  6. Agenda/Contents • Overview of OU • The Birth of Financial Account Management System (FAMS) • FAMS side • PeopleSoft side with focus on Financials

  7. The University of Oklahoma

  8. The University of Oklahoma • Located in Norman, a city of ~ 100,000 residents, located 20 miles south of OKC. • Enrollment on Norman Campus: 24,569 • Faculty & Staff FTE: 3,935

  9. The University of Oklahoma • Total Norman Campus Budget: $511,240,169 • Total Norman Campus Sponsored Programs: $122,890,974

  10. University of Oklahoma and Oracle • HRMS 8.0 - November 2002 • HRMS 8.8 – Upgrade 2004 • Financials 8.8 – July 2005 - General Ledger - Purchasing - Accounts Payable - Asset Management • Budgeting 8.9 (go live April 2006)

  11. The Birth of FAMS • HRMS was the first ERP module implemented • Moved from a legacy system with on-line capabilities • HRMS department vs Financials department (funding source) • Decentralized functions • Approximately 500 department sponsors • Many “non-sponsors” using legacy system

  12. The Birth of FAMS • In-house system created in Oracle • Departments and sponsors fed from Financials • “Roles” were developed for HRMS • Sponsors given access to their departments to add “proxies” for their departments. • Allowed us to have row level security in PS based on roles assigned to proxy in FAMS. • Leveraged existing system when Financials was implemented • Developed roles for Financials • Enhanced the process for updating security in PS

  13. FAMS

  14. FAMS

  15. FAMS

  16. FAMS • Must have an EmplID in HRMS to access FAMS. • Must have an EmplID in HRMS to be designated a proxy. • Create Proxy – gives individual same abilities as sponsor. • FAMS is used for the security of an in house Personnel Action Form (PAF) system as well as HRMS and Financials.

  17. FAMS

  18. FAMS • Sponsored Program departments = xx5xxxxxx • Teams of Sponsored Program specialists are responsible for groups of Sponsored Program departments • “Grants and Contracts Teams” captures the members of the teams • “Grants and Contracts Departments to Teams” captures the departments that belong to each team

  19. FAMS • FAMS does not govern the security of all employees. • Financial Support Services • Internal Auditing • Purchasing

  20. FAMS – The PeopleSoft Side • Create Record / Page Definitions for the Deptid / Project Authorization tables. • Create Search / Add views to select / retrieve Deptids / Projects that a Campus User has access to, based upon the Authorization Tables. • Modify Prompt tables in Record Definitions to use Custom Security Views. • Modify identified Component Definitions to use Custom Security Views.

  21. FAMS – The PeopleSoft Side • PeopleTools Customizations • Interface / Data Requirements • Detail Design • Custom Field Definitions and Translate Values • Custom Record Definitions • Customized Record Definitions • Custom View Definitions • Customized Components • Custom Page Definitions • Custom Interface Batch Process – SQR • Modified Delivered SQR Reports • Row Level Security • Maintenance

  22. FAMS – PeopleTools Customizations • Custom Field Definition - OU_GL_AUTHCODE. • Auth Code Translate values: • 001 Financials Inquiry Only • 002 Requisition Add / Update / Cancel • 003 Requisition Approve • 004 PO Receiving

  23. FAMS – PeopleTools Customizations • Custom Record Definitions • OU_GL_DEPTAUTH • Captures Deptid(s) and corresponding Fund Codes per User ID. • Data retrieved from FAMS, updated by batch process. • OU_GL_PROJAUTH • Captures Project(s) and corresponding Fund Codes per User ID. • Data retrieved from FAMS, updated by batch process.

  24. FAMS – PeopleTools Customizations • Customized Record Definitions: • Prompt Tables pointed to custom views. • Enforces row level security by retrieving Deptids / Projects for specific Auth Codes

  25. FAMS – PeopleTools Customizations • Custom View Definitions: • Various Custom views cloned from original views • Retrieves Deptids / Projects for specific Auth Codes.

  26. FAMS – PeopleTools Customizations • Customized Components: • Changed Search records to Custom Views • Retrieves Deptids / Projects for specific Auth Codes.

  27. FAMS – PeopleTools Customizations • Custom Department Auth Page:

  28. FAMS – PeopleTools Customizations • Custom Project Auth Page:

  29. FAMS – Custom Interface Batch Process • SQR Process that: • Updates PS Financials Security tables with User Roles: • PSROLEUSER • ReportSuperUser • EOPP_USER • OU_GL_INQ_CAMPUS - Financials Inquiry Only • OU_PO_REQADD_CAMPUS - Requisition Add / Update / Cancel • OU_PO_REQAPPR_CAMPUS - Requisition Approve • OU_PO_RECV_CAMPUS - PO Receiving • PS_ROLEXLATOPR

  30. FAMS – Custom Interface Batch Process • Updates Department and Project Authorization tables • OU_GL_DEPTAUTH • OU_GL_PROJAUTH • with authorized Deptid / Project values and Auth Code information from FAMS.

  31. FAMS – Custom Interface Batch Process • Retrieves Fund Code for the Deptid / Project ID from the PeopleSoft SPEEDTYP_TBL. Inserts the appropriate FUND_CODE into the Authorization tables. • Updates the PS_REQUESTOR_TBL and the Requisition Setup section of the User Preferences (PS_OPR_DEF_TBLs). • NOTE: In order to retrieve data efficiently, FAMS must have a LAST UPDATE DTTM stamp on every row that it stores. This enables the PS Financials system to retrieve data based on a date or a date range.

  32. FAMS – Modified Delivered SQR Reports • GLS7002 - General Ledger Activity • FIN2001 - Journal Entry Detail • GLS7011 - Journal Error Report • GLS8005 - Budget Transaction Detail • GLS8010 - Budgets / Actuals • GLS8020 - Budget Status Report • GLS8510 - Ledger Details report

  33. FAMS – Row Level Security • Permission Lists and Roles were developed to control Campus user access to the Maintain Requisitions pages. • Row level security then ensures that the Campus user only adds, approves or changes requisitions for Deptids / Projects for which he or she is authorized. • On specific pages, when a SpeedChart is selected, the DEPTID /PROJECT_ID is validated against the PS_OU_GL_DEPTAUTH / PS_OU_GL_PROJAUTH custom Authorization tables to ensure the Campus user has the appropriate Add authority for the Deptid / Project selected.

  34. FAMS – Row Level Security • When a Campus users clicks on Speedchart, the values are limited to what is stored in the Authorization Tables.

  35. FAMS – Maintenance • Interface Monitoring: • Should be monitored daily. • Can be re-run many times in batch mode or on an ad-hoc basis. • Can be run for a date range, or default to current date • Application Message Monitoring: • Partial Sync application message sync’s the User Profile (only) data between HR and Financials. • Monitor message on a daily basis. If errors or remains in a NEW status, OPRIDs may not be created in Financials.

  36. FAMS – Maintenance • Changes to FAMS: • Changes to table structures in FAMS must be addressed in the FAMS to PS interface. • The rest of the row level security code in PS will not be affected. • The PS Financials row level security hinges on the Authorization tables PS_OU_GL_DEPTAUTH and PS_OU_GL_PROJAUTH tables. Changes to these custom tables will affect Row Level Security.

  37. FAMS – Maintenance • Impact of Patches and Fixes: • Care must be taken not to overwrite custom Search views for components and prompt table edits for Record Definitions. • Document all modifications, including SQR’s. • Run compare reports prior to applying patches to show comments and customizations.

  38. Questions?

  39. Contacts • Terri Pinkston • Controller • University of Oklahoma • E-mail: terri@ou.edu • Karen Sturtz • PeopleSoft Team Lead • Information Technology • University of Oklahoma • E-mail: karen-sturtz@ou.edu

  40. This presentation and all Alliance 2006 presentations are available for download from the Conference Site Presentations from previous meetings are also available

More Related