SDBOR 009 Functional Specification v6mytraining.sdbor.edu/resources/banner/Multiple... · optimal...

South Dakota Board of Regents Customization Id: SDBOR 009 Banner® Finance and Banner® H/R State Payroll Export Process Functional Specification

Prepared by: Jason Norem

Version: 6 Last Revision Date: 02/04/2010

Create Date: 10/09/2006

Project Manager: Jason Norem Functional Consultant Lead: Jason Norem

Functional Specification

SunGard Higher Education - Confidential & Proprietary

SDBOR 009 Functional Specification v6.doc of 40 Payroll

FSI/RCNTRANS

File

4-Feb-10

Confidential Business Information

------------------------------------------------------------------------------------------------------------------------------------------------------------------ This documentation is proprietary information of SunGard Higher Education and is not to be copied, reproduced, lent or disposed of, nor used for any purpose other than that for which it is specifically provided without the written permission of SunGard Higher Education. Prepared By: SunGard Higher Education

4 Country View Road Malvern, Pennsylvania 19355 United States of America

© SunGard 2009. All rights reserved. The unauthorized possession, use, reproduction, distribution, display or disclosure of this material or the information contained herein is prohibited. In preparing and providing this publication, SunGard Higher Education is not rendering legal, accounting, or other similar professional services. SunGard Higher Education makes no claims that an institution's use of this publication or the software for which it is provided will insure compliance with applicable federal or state laws, rules, or regulations. Each organization should seek legal, accounting and other similar professional services from competent providers of the organization’s own choosing.

Without limitation, SunGard, the SunGard logo, Banner, Campus Pipeline, Luminis, PowerCAMPUS, Matrix, and Plus are

trademarks or registered trademarks of SunGard Data Systems Inc. or its subsidiaries in the U.S. and other countries.

Third-party names and marks referenced herein are trademarks or registered trademarks of their respective owners.




FSI/RCNTRANS

File

4-Feb-10

TABLE OF CONTENTS

1 FUNCTIONAL REQUIREMENT ..........................................................................5

1.1 INTRODUCTION ..........................................................................................5 1.2 OVERVIEW.................................................................................................5 1.3 SCOPE ......................................................................................................5

1.3.1 Product Release.........................................................................................5 1.3.2 Assumptions...............................................................................................6 1.3.3 Exclusions..................................................................................................7 1.3.4 Concerns....................................................................................................7 1.3.5 Terminology ..............................................................................................7 1.3.6 Security......................................................................................................7 1.3.7 Site Policy Impact......................................................................................7

1.4 FUNCTIONALITY .........................................................................................7 1.4.1 Functional Process Flow ..........................................................................7 1.4.2 New Human Computer Interactions (HCI)/Forms....................................8 1.4.3 Modified Human Computer Interactions (HCI)/Forms ..........................13 1.4.4 New Web Applications ............................................................................13 1.4.5 Modified Web Applications .....................................................................13 1.4.6 New Processes.........................................................................................13 1.4.7 Modified Processes .................................................................................28 1.4.8 New Reports ............................................................................................28 1.4.9 Modified Reports .....................................................................................28 1.4.10 New Reporting Structures .......................................................................28 1.4.11 Modified Reporting Structures ................................................................28

1.5 DATABASE...............................................................................................28 1.5.1 New Tables ..............................................................................................28 1.5.2 Modified Tables.......................................................................................35 1.5.3 New Views ...............................................................................................35 1.5.4 Modified Views........................................................................................35 1.5.5 New Functions.........................................................................................35 1.5.6 Modified Functions .................................................................................35 1.5.7 New Procedures ......................................................................................35 1.5.8 Modified Procedures ...............................................................................35 1.5.9 New Packages .........................................................................................35 1.5.10 Modified Packages ..................................................................................36 1.5.11 New Other ...............................................................................................36 1.5.12 Modified Other ........................................................................................36

2 CROSS ENTERPRISE CONSIDERATIONS .....................................................36

2.1.1 Campus Pipeline/Luminis .......................................................................36 2.1.2 SunGard Higher Education’s Workflow Examples.................................36 2.1.3 WebCT Interface Processes.....................................................................36 2.1.4 Learning Systems.....................................................................................36 2.1.5 Other Interfaced Systems ........................................................................36

3 PERFORMANCE REQUIREMENTS .................................................................36

3.1 ANTICIPATED SYSTEM USAGE...................................................................36 3.2 RESPONSE/EXECUTION TIME....................................................................36




FSI/RCNTRANS

File

4-Feb-10

3.3 ERROR HANDLING/RECOVERY ..................................................................36

4 CONTRACT INFORMATION ............................................................................37

5 APPROVAL TO PROCEED ..............................................................................38

6 DOCUMENT HISTORY .....................................................................................39

7 ACRONYMS......................................................................................................40

8 DEFINITIONS....................................................................................................40




FSI/RCNTRANS

File

4-Feb-10

1 Functional Requirement

1.1 Introduction

South Dakota Board of Regents (SDBOR) is requesting a new process be created that

extracts information from the Banner® HR and Banner® Finance systems and reports it

in the required State file formats. The two files are referred to as the FSI file and the

RCNTRANS file. The RCNTRANS file only reports checks and the FSI file contains the

accounting information behind the payroll transactions.

This functional specification document represents the outcome of an iterative review

process. It is considered a product-planning document and does not represent a

commitment to develop the described software changes in the manner presented.

SunGard Higher Education reserves the exclusive right to determine, in its sole

discretion, the enhancements to be developed by SunGard Higher Education and the

manner in which they are developed.

1.2 Overview

SDBOR is currently creating FSI/RCNTRANS files for A/P transactions using the

custom process FZPCHKR. SDBOR is required by the State to report the same type of

information for payroll transactions. This functional specification outlines the steps

needed to accomplish this task.

1.3 Scope

SunGard Higher Education will create a new Pro*C process that creates the two desired

files. The current process FZRCHKR has the appropriate file format for both the FSI and

RCNTRANS files. The new process will be a stand-alone process using the Finance

Attributes, Bank Code and rules that were created for the existing process. The new

process will run independently from the other.

1.3.1 Product Release

Module Release Number

Banner® Finance 7.1

Banner® Human Resources 7.1.1




FSI/RCNTRANS

File

4-Feb-10

1.3.2 Assumptions

1.3.2.1 Contractual Assumptions

1. All customizations will be developed and delivered in Banner® Finance 7.1 and

Banner® Human Resources 7.1.1.

2. Objects not mentioned in the Statement of Work are outside the scope of the

proposed solution. Any change in scope will be handled with a Change Request and a

re-evaluation of effort.

3. SunGard Higher Education will deliver efficient, well-formed code, analyzed for

optimal performance according to Oracle and SunGard Higher Education standards.

4. A single point of contact from the Client will be identified for communication during

the project. This single point of contact will be responsible for all communication

with SunGard Higher Education, including the review and approval of project

deliverables and formal acceptance of the final product.

Client approval will be required on the following documents:

a. Statement of Work

b. Milestone Document

c. Functional Specification

d. Sign Off/Acceptance

5. Failure to meet milestone dates as agreed upon in the milestones document could

present a jeopardy to the project.

6. The Client will provide SunGard Higher Education with an Acceptance Test Plan

that will determine whether or not the customization meets the requirements outlined

in the functional specification.

7. SunGard Higher Education will test the customization prior to delivery; however, it is

the responsibility of the Client to thoroughly test the customization within the testing

period allowance (30 days from the date of delivery of the customization).

8. The project will be considered accepted and complete 30 days from initial delivery, if

there are no outstanding defects and a signed acceptance agreement has not been

obtainable. However, a signed acceptance agreement is required before any

modification is eligible for maintenance through Customization Services.

9. The Client is responsible for the installation of the software delivered by SunGard

Higher Education.

10. The Client is responsible for data set up required by the customization.

11. End user training, beyond the delivered documentation, is not part of this estimate.

12. Maintenance is not included in this Statement of Work. After original project sign off

is submitted, a separate maintenance agreement is required if the Client wishes to put

the customization under a maintenance contract.

13. SunGard Higher Education will perform all work off campus. On-site, campus visits

are outside the scope of this estimate.

14. Travel and expenses are not included in the estimate of effort associated with this

document

1.3.2.2 Process Assumptions

1. Process will be run from job-submission

2. It will be the responsibility of the client to run the process




FSI/RCNTRANS

File

4-Feb-10

3. All required data elements exists in the Banner® Finance System and Banner® HR

System

4. The journal entry that reallocates the monies in the Banner® Finance System will be

created from the baseline Payroll Interface JV’s. A change request to SDBOR 002 will

be needed to exclude the JV from being picked up on the A/P FSI file created by the

FZRCHKR process but allowed to be part of the GURFEED document created.

5. No Banner® Finance Journal Entries will be created by the new process.

6. FSI and RCNTRANS File formats will be exactly the same as the existing files created

by the current FZRCHKR process but will have different logic built in for the deduction

descriptions.

7. The files will use the same attributes that were created for the FZRCHKR process. In

addition to these rules the new process will use a new table to identify deduction

descriptions that will be included in the FSI file.

8. The new process will be run independently from the existing FZRCHKR process.

9. The new process will have its own State numbering sequence for the FSI file. The FSI

file Document ID2 field will begin with a ‘CUX7nnnnnnn’.

10. All transactions that have not yet been reported will be picked up by the process. A new

table will be created that can identify what has been already reported.

11. The RCNTRANS interface file will only contain Check Transactions.

12. The Create NHRDIST Records on the NTRINST form must be checked.

13. The baseline Payroll processing must be completed before initiating the NZPSRPT job

(minimum disposition 62).

14. Transactions that include the rule class for Net Payroll on NTRFINI will be ignored by

the new NHRDIST table trigger. The current NTRFINI record will be used by the

process to determine the rule class to exclude. The baseline delivered rule class is

HNET.

1.3.3 Exclusions

None at this time

1.3.4 Concerns

None at this time

1.3.5 Terminology

1.3.6 Security

All objects for this modification will invoke the standard Banner® object level security.

1.3.7 Site Policy Impact

None at this time

1.4 Functionality

1.4.1 Functional Process Flow

Users will initiate the new process called NZPSRPT from job submission after the Baseline

Payroll Process is complete. The NZPSRPT process must be run in audit mode first. In Update




FSI/RCNTRANS

File

4-Feb-10

mode the process will create two state interface files in the appropriate state format (FSI and

RCNTRANS).

Set up steps

1. The NTRINST record must be set to create NHRDIST records.

1.4.2 New Human Computer Interactions (HCI)/Forms

GZAXWLK – Data Crosswalk

This form will be used to crosswalk Higher Education Banner® values to State values. This new

form will be used to enter the descriptions that the NZPSRPT process will use to report the state

and local deductions in the FSI file.

The fields will be stored in the GZRXWLK table.




FSI/RCNTRANS

File

4-Feb-10

The User ID and Activity Date are system maintained. The Data Origin is stored on the

GZRXWLK table, but not displayed on the form.

In the key block of the GZAXWLK form the user can select, from a list of values of all Higher

Education Banner® tables with Oracle security grants to BANINST1, a Source Table. Based on

the source table selected the user can select, from a list of values of all Banner® columns owned

by the source table selected, a Source Column. The user will also be able to choose the Process

ID, from a list of values for all the Process ID values on the GZRXWLK table.

If the Process ID is left blank the user is asked if they want to pre-populate the Banner® Values

with what exist on the database. If there is any data found for the key block search criteria,

GZAXWLK will display all the existing data.

This form allows for unlimited Process ID values to be cross-walked to and Banner® Value and a

State Value. The Process ID must be a valid Banner® job in the Process Maintenance, GJAJOBS

form.

Sorting of records in the form:

Records will be displayed sorted by Process ID, Banner® Value, and State Value.

Characteristic Values

Source Table In the key block, a List Of Values to all the Banner® tables

owned by the schema owner BANINST1. Banner® table to be

cross-walked.

Display only? No

Updateable? Yes

Queryable? Yes

Required? Yes

Enterable? Yes




FSI/RCNTRANS

File

4-Feb-10


Data Type Character(30)

Maximum Data

Length

30

Double click

functionality

Not applicable

Help Line text ‘Banner Source Table; All tables with Oracle security grants to

BANINST1 are displayed.’

Error Message ’*ERROR* Source Table not found with Oracle grants to

BANINST1.’

Edit-check Messages Not applicable

Special processing If source table is not found, the user will get the error message.


Source Column In the key block, a List Of Values to all the Banner® columns in

the Source Table. Banner® column on the crosswalk source

table to be cross-walked.

Display only? No

Updateable? Yes

Queryable? Yes

Required? Yes

Enterable? Yes


Maximum Data

Length

30

Double click

functionality

Not applicable

Help Line text ‘Banner Source Column; All columns in the Source Table are

displayed.’

Error Message ’*ERROR* Source Column not found in the source table.’


Special processing If source column is not found, the user will get the error message.


Process ID In the key block, a List Of Values to all the unique Process IDs

on the GZRXWLK table. The Banner job name, from Banner

job submission, of the process that uses the cross-walked value.

Display only? No

Updateable? Yes

Queryable? Yes

Required? No




FSI/RCNTRANS

File

4-Feb-10


Enterable? Yes


Maximum Data

Length

30

Double click

functionality

Not applicable

Help Line text ‘Banner Process ID; The Banner job name, from Banner job

submission, of the process that uses the cross-walked value.’

Error Message Not applicable

Edit-check Messages ’*ERROR* Process ID not found on GJAJOBS.’

Special processing Must exist in report/process definition table (GJBJOBS_NAME).

If the value is not found in GJBJOBS_NAME, the user will get

the error message.


Process ID In the detail block. The Banner job name, from Banner job

submission, of the process that uses the cross-walked value.

Having the Process ID in the body block allows for the creation

of crosswalk values to new Process IDs.

Display only? No

Updateable? Yes

Queryable? Yes

Required? No

Enterable? Yes


Maximum Data

Length

30

Double click

functionality

Not applicable

Help Line text ‘Banner Process ID; The Banner job name, from Banner job

submission, of the process that uses the cross-walked value.’


Edit-check Messages ’*ERROR* Process ID not found on GJAJOBS.”

Special processing Must exist in report/process definition table (GJBJOBS_NAME).

If the value is not found in GJBJOBS_NAME, the user will get

the error message.


Banner Value In the detail block, Banner® source column value.

Display only? No

Updateable? Yes




FSI/RCNTRANS

File

4-Feb-10


Queryable? Yes

Required? Yes

Enterable? Yes


Maximum Data

Length

30

Double click

functionality

Not applicable

Help Line text ‘Banner Value; Banner source column value.’



Special processing Not applicable


State Value In the detail block, State value of the cross-walked Banner source

column and value.

Display only? No

Updateable? Yes

Queryable? Yes

Required? Yes

Enterable? Yes


Maximum Data

Length

30

Double click

functionality

Not applicable

Help Line text ‘State Value; value of the code that the state is expecting.’





User ID In the detail block, the Oracle User ID of the user who changed

the record

Display only? Yes

Updateable? No

Queryable? No

Required? Yes




FSI/RCNTRANS

File

4-Feb-10


Enterable? No


Maximum Data

Length

30

Double click

functionality

Not applicable

Help Line text Not applicable





Activity Date In the detail block, the date of last activity (insert of update) on

the record.

Display only? Yes

Updateable? No

Queryable? No

Required? Yes

Enterable? No

Data Type Date

Maximum Data

Length

11

Double click

functionality

Not applicable

Help Line text No applicable




1.4.3 Modified Human Computer Interactions (HCI)/Forms

1.4.4 New Web Applications

1.4.5 Modified Web Applications

1.4.6 New Processes




FSI/RCNTRANS

File

4-Feb-10

1.4.6.1 State Payroll Export Process (NZPSRPT)

The new State Payroll Export Process (NZPSRPT) will use existing information in the baseline

HR and Finance tables. The two main HR tables that will be used to create the required

information for the state reporting include NHRDIST and PHRDOCM.

The accounting information resides it the NHRDIST table and the check number/information

resides in the PHRDOCM table.

A new table NZRSRPT will be created that includes information from both. A post-insert trigger

will be added to NHRDIST table that will initially load the new NZRSRPT table.

The new process NZPSPRT Payroll FSI/RCNTRANS File Create Process will edit/update the

remaining information needed from the PHRDOCM table and the Banner Finance attribute

tables. The process will have the same edits on the State Fund/Account/Company attributes. The

process can be able to run in audit or update modes. When the effective date parameter is

entered, this date will be used on the update to the NZPSRPT table and will not use the check

date from PHRDOCM.

The payroll process must be at a disposition 62 (or higher). The NHPFIN2 process will load the

transactions into the NHRDIST table and a post-insert trigger will fire that will load the records

into the new State reporting table, NZRSRPT.

The trigger will exclude transactions that have the net payroll rule class identified on the baseline

NTRFINI form. The trigger will use the current NTRFINI record for the fiscal year to identify

the rule class to exclude. The current record will be identified by the date range of the fiscal year

in regards to the NHRDIST transaction date. The baseline rule class delivered is ‘HNET’. If the

Process is run before a disposition 62, there will be no new records in the NZRSPRT table and

the process will give an error.




FSI/RCNTRANS

File

4-Feb-10

If the payroll is at a Disposition 62 or higher the trigger will successfully insert records into

NZRSRPT table. The sum of the decoded transactions in NZRSRPT should now equal the net

pay for an individual.

The NZPSPRT process will first update the NZRSPRT table with the check information from the

PHPDOCM table. The information inserted into the table will include the check number,

document type to identify if it is a direct deposit or check and the net amount of the check. This

check number and amount will repeat for every transaction in the NZRSPRT table for a particular

individual.

The sum(decode(NSRSRPT_DR_CR_IND, ‘C’, -NSRSRPT_AMT, NSRSRPT_AMT)) should

equal the net amount of the check. The process will also load the attribute information for each

transaction in the table and error if any information is missing. The process will create two State

Interface Files.

FSI/RCNTRANS file extract and report Descriptions:

BAP code will be a break in the FSI report and extract. The BAP code will be identified by the

starting number of the Check. The translation rules of the BAP code will be determined by this

table.

Description

Check #

Char 1-2 BAP Company Account Center

Check

Transaction

– BRP 10 BRP 9000 22094011 330040

Check 20 HXU 9000 2209402 330040




FSI/RCNTRANS

File

4-Feb-10

Transaction

– USD

Check

Transaction

– SDSU 30 HXX 9000 2209403 330040

Check

Transaction

- SDSMT 40 HXM 9000 2209404 330040

Check

Transaction

– NSU 50 HXN 9000 2209405 330040

Check

Transaction

– BHSU 60 HXB 9000 2209406 330040

Check

Transaction

– DSU 80 HXD 9000 2209408 330040

All other types of Check transactions will be for BAP code BRP and will follow the original logic

that was outlined in the functional specification.

• Effective Date Parameter

o The field will be defined as a date field an will be optional

o When the field is left blank the process will use existing logic. – this should be

left blank when processing Original (monthly) pay periods

When the parameter is populated, the process will update the Document Date

(NZRSRPT_DOC_DATE) of the Selected Records to this new Effective Date value. The process

will then use the existing reporting logic to generate the reports and extracts for this one day.

This parameter should only be used during correction runs.

All Check and Check Cancellation Transactions need to have an offsetting entry made to the FSI

file in summary for the day.

The Warrant Imprest fund needs to be debit/credited for all check/check cancellation transaction

amounts. The transactions should be subtotaled by BAP code. The Company, Account and

Center codes will be hard-coded based on the BAP code of the transaction for this part of the FSI

file. The transactions will have the opposite sign of the sum of the transactions creating the entry.

All check transactions creating the entry will have a credit or ‘60’ and all check cancellations will

have a debit entry or ‘10’. The document id will be the same as the document id number of the

records creating the transaction.

The State Document ID (CU….) will be unique for each day, check transactions or cancellations,

and now BAP code. Descriptions will be based on the BAP code as noted in the above table..

The State Imprest Entry will be unique for each State Document and the State Company, Center

and Accounts will be determined by the same logic as SDBOR 002.

• Fiscal Year Override Parameter




FSI/RCNTRANS

File

4-Feb-10

o The field length will be 4 digits and provide an LOV and validation against

NBAFISC (Fiscal Year form)

o The field will be optional; if the field is left blank the process will use the

existing logic.

o When the field is populated, the process will update the Doc Number field in the

FSI file (Source Document ID2 in Positions 54 – 63) with the next document

available for the entered fiscal year rather than the existing logic.

RCNTRANS file output change:

The AP_BAP_CODE reported in the RCNTRANS file will include the BAP code logic reported

in the table above.

1.4.6.1.1.1.1 Parameter Definition

Add the following new parameter to the Parameter Definitions Form (GJAPDEF) for

Process NZPSRPT:

Field Data

Parameter Number: 1

Parameter Description: Run Mode

Data Type: Character

Length: 1

Optional/Required: Required

Single/Multiple: Single

Validation: N/A

Help Text: Enter A for Audit and U for Update Mode

Default: A

Field Data

Parameter Number: 2

Parameter Description: Fiscal Year Override

Data Type: Character

Length: 4

Optional/Required: Optional


Validation: LOV and validation on NBAFISC

Help Text: Enter fiscal year to use on all FSI created

documents. Use for year end-adjustments

only.




FSI/RCNTRANS

File

4-Feb-10

Default: N/A

Field Data

Parameter Number: 3

Parameter Description: Effective Date

Data Type: Date

Length: 11

Optional/Required: Optional


Validation: N/A

Help Text: Enter the effective date to use on all

transactions processed. Use for correction

payroll runs only.

Default: N/A

Add the following rows to the Parameter Value Validation Form (GJAPVAL) for

NZPSRPT:

Field Data

Number: 1

Parameter: Run Mode

Value: A

Field Data

Number: 1

Parameter: Run Mode

Value: U

Add the following row to the Default Parameter Value Validation Form (GJAPDFT) for

NZPSRPT:

Field Data

Number: 1

Parameter: Run Mode

System Default: A

1.4.6.1.1.1.2 File Naming Convention




FSI/RCNTRANS

File

4-Feb-10

When records are found, the data files naming convention will include date/timestamp

concatenated to the name of the job’s output file. This will insure correct reporting to the State

and will insure that no file will be overwritten. This new naming convention is only for the files

created in ‘update mode’. The files created in ‘audit mode’ will just have AUDIT and the job

name. The file will be overwritten when the job is run in audit mode a second time.

The FSI file example would be AUDIT_FSI.DAT when run in audit mode.

The FSI file example would be FSI200607181415.DAT -- for 18-Jul-2006 at 14:15 when run in

update mode.

1.4.6.1.2 Interface Files

The NZPSRPT process will have an edit up front to check to see if there are records to process.

If no records are found, the job will error and report the error of “No records to process.” This

way the data files will not be created with zero output. It will also check to see if the state

reporting attributes and bank codes exist on the fund and account records.

1.4.6.1.2.1 FSI interface file

1.4.6.1.2.1.1 Document Description Logic

The FSI export default descriptions will be:

CHECK TRANSACTIONS – BRP

ACH TRANSACTIONS

CANCELLED CHECKS - BRP

CANCELLED ACH

The process will use a different value if the deduction code on the NZPSRPT record exists in the

new GZRXWLK table. The process will use the fsi export description based on the

NZRSRPT_BDCA_CODE matching a GZRXWLK_SOURCE_COLUMN.

1.4.6.1.2.1.2 The Document ID logic

The one digit fiscal year will be retrieved from the FTVFSYR table using the system date to

identify the current fiscal year. The one-up-numbering (nnnnnn) will have six digits available.

The one digit fiscal year of the file will be the derived from the day the file was run in update

mode. If the run date is June 30, 2006 the fiscal year will be ‘6’. If the run date is July 1, 2006

the fiscal year will be ‘7’ even if there were transactions in the file from a previous day.

If the fiscal year parameter is populated when running the process, the logic will use this fiscal

year and not calculate it.




FSI/RCNTRANS

File

4-Feb-10

The Check, ACH, and Deductions transactions should all be on the same State Document ID2 for

the day. The Cancelled Checks, Cancelled ACH and the corresponding cancelled deduction

transactions should be on another document ID2 for that day. The corresponding State Warrant

Imprest Summary Credit/Debit Entry will also have the same document ID2 number as the

corresponding check/check cancellation expenditure entries.

Transactions included in the FSI file:

1. Transactions from the NZRSRPT table for the expense reporting side to the State of

South Dakota.

FSI record layout includes fields called Company, Account, Center, and Project Code.

These fields will be defined as attributes in Banner® Finance to create the interface file.

SDBOR will be using attributes on the Fund and Account Codes to satisfy this

requirement. In addition to these fields the Company, Center and Account need to be

grouped and reported by the Description of the transaction.

2. State Warrant Imprest Credit/Debit Entry

All Check and Check Cancellation Transactions need to have an offsetting entry made to

the FSI file in summary for the day.

The Warrant Imprest fund needs to be debit/credited for all check/check cancellation

transaction amounts. The transactions should be subtotaled by the description. The

Company, Account and Center codes will be hard-coded to 9000 22094011 330040. The

transactions will have the opposite sign of the sum of the transactions creating the entry.

All check transactions creating the entry will have a credit or ‘60’ and all check

cancellations will have a debit entry or ‘10’. The document id will be the same as the

document id number of the records creating the transaction.

The Process will read all the transactions that have not been previously reported to the

State and report them in the appropriate State files. The output fields for the state will

follow the same format as the current FZPCHKR process.

NOTE: The NZPSRPT process will not report zero amount transactions in the FSIPAY file.

The FSI record layout is listed below:

Name of Field Length From Thru Remarks Source System

2 1 2 “HE”

Destination

2 3 4 “GL”

Document Type

3 5 7 Not Used




FSI/RCNTRANS

File

4-Feb-10

Name of Field Length From Thru Remarks Activity

12 8 19 Not used

Source Document ID1 (ID1 and ID2 are really one field but listed in this table separately.)

44 20 53 Blank

Source Document ID2

10 54 63 Format should be CUX7nnnnnn

The 4th digit (7) indicates fiscal year for

the system date of the run (or

parameter if entered) and the last six

digits should be the updated to a “1-up”

number each time the process is run

(start with 000001, then 000002, etc.)

(left justified)

Created from NZRSRPT_

FSI_SOURCE_DOC_SEQ and

NZRSRPT_FSI_SOURCE_DOC_YEAR Source Document Line # 4 64 67 Not used Application Work Area 2 68 69 Not used Filler

22 70 91 Filler (Spaces) Accounting Rule 2 92 93 “01” Summarize Indicator

1 94 94

Blank

Funding Company

4 95 98 Not used Filler 35 99 133 Filler (Spaces) Company 4 134 137 Not used Application Area

2 138 139 “HE” Batch Number 2 140 141 Not used Data Type

1 142 142 “2” Batch Total 10 143 152 Not used Batch Total # Decimals

2 153 154 Not used Closed Period Adjust

1 155 155 “0”




FSI/RCNTRANS

File

4-Feb-10

Name of Field Length From Thru Remarks Effective Date 4 156 159

packed hexadecimal Julian value as

described below. This appears from

the info faxed in element 20 Effective

Date, 23 Reversing Effective Date, 27

Recurring Purge Date, 36 Effective

Date. For example, the file created has

a 171 (June 20th) in Effective Date and

should be 2006171F. If no date, then

all zero packed value (i.e. 000F) Source Generate Code 1 160 160 “0” Project Company

4 161 164 Blank Reversing Effective Dt

4 165 168









all zero packed value (i.e. 000F) Suspense Account

18 169 186 Not used Suspense Center

12 187 198 Not used Recurring Code

1 199 199 Blank Recurring Purge Date

4 200 203









all zero packed value (i.e. 000F) Date Format Code

1 204 204 Not used Item Number

4 205 208 One up numbering for the document Transaction ID

1 209 209 “1” Debit/Credit Code

2 210 211 10 – Debit 60 – Credit (decoded from NZRSRPT_DR_CR_IND)




FSI/RCNTRANS

File

4-Feb-10

Name of Field Length From Thru Remarks Company

4 212 215 Calculated based on a fund attribute

NZRSRPT_STATECO Account

18 216 233 Calculated based on an acct attribute

NZRSRPT_STATESA

Note: Needs the STATESS Overlay

procedure Center

12 234 245 Calculated based on a fund attribute

NZRSRPT_STATECE Source Code

10 246 255 Same as Source Doc ID2 above (left

justified) Effective Date

4 256 259

Run Date packed hexadecimal Julian

value as described below. This

appears from the info faxed in element

20 Effective Date, 23 Reversing

Effective Date, 27 Recurring Purge

Date, 36 Effective Date. For example,

the file created has a 171 (June

20th) in Effective Date and should be

2006171F. If no date, then all zero

packed value (i.e. 000F) Amount

10 260 269 Sum(NZRSRPT_AMT) (amount must be >

0) Amount # Decimals

2 270 271 “02” Description 1a

29 272 300

See Description 1a section.

CHECK TRANSACTIONS – BRP

ACH TRANSACTIONS


CANCELLED ACH

DEDUCTIONS

Description 1b

1 301 301 “C” Description 2

12 302 313 Blank Description 3

10 314 323 Blank




FSI/RCNTRANS

File

4-Feb-10

Name of Field Length From Thru Remarks Project Code

12 324 335 Blank Statistical Amt

10 336 345 Not used Stat Amt # Decimals

2 346 347 Not Used Currency Code

4 348 351 Not Used Foreign Amount

10 352 361 Not Used Foreign Amt # Decimals

2 362 363 Not Used Exchange Rate

10 364 373 Not Used Exchange Rt # Decimals

2 374 375 Not Used Filler

33 376 408 Filler (Spaces)

For additional information see (FSI record layout.pdf)

FSI File - All packed fields noted by the column titled "Class" with a P in it need to be

initialized to an all zero packed value for the length of that field when not used and

should not consist of blanks. Those in the layout appear to be Packed 10 so would be

000000000F.

Fields with a Z under the "Class" column needs to have an "02" in them at all times even

if there is no amount populated in the field prior to it. Those would be fields elements:

18: Batch Total # Decimals, 38: Amount # Decimals, 44: Stat Amt # Decimals, 47:

Foreign Amt # Decimals, 49: Exchange RT # Decimals.

1.4.6.1.2.2 2. RCNTRANS Interface File

The RCNTRANS file is for check reporting to the State of South Dakota. Cancellations

and ACH Payments do not appear on this file. Check transactions should be summarized

into one line per check. The NZRSRPT_HIST_TYPE = ‘R’ should not be picked up in the

file to the State.

File example:

Name of Field Length From Thru Remarks

AP_RECORD_TYPE 2 1 2 “02”




FSI/RCNTRANS

File

4-Feb-10

Name of Field Length From Thru Remarks

AP_BANK_ACCOUNT 14 3 16 ”000153031360”

AP_FILLER_1 23 17 39 Filler

AP_WARRANT_NUMBER_FROM 10 40 49 Check Number

NZRSRPT_DOC_NO

(lpad with zeros)

AP_WARRANT_NUMBER_TO

10 50 59 Filler

AP_DATE 8 60 67 Date format (MMDDYYYY)

date of check

NZRSRPT_DOC_DATE

(or Effective Date Override

Parameter if entered)

AP_DATE_FORMAT 1 68 68 “2”

AP_AMOUNT 15 69 83 Amount of the check

NZRSRPT_NET

AP_BAP_CODE 3 84 86 BRP

AP_PAY_ENTITY 4 87 90 Filler

AP_VENDOR_NUMBER 10 91 100 Filler

AP_VENDOR_GROUP 2 101 102 Filler

AP_PAYEE_NAME 30 103 132 Payee Name decoded

from NZRSRPT_PIDM

2 AP_FILLER_2 22 133 152 Filler

This NZRSPRT process can be run in audit or update mode. The process will need to be run in

audit mode first where the NZRSPRT_ACCT_FEED_IND will be initially set to an ‘I’ and the

state attribute values will be updated on each of the NZRSPRT records.

Any missing attributes will cause error and must be corrected before the job can continue. An

error report will be produced by the process displaying the errors. The errors will be listed

separately based on the fund or account that has the missing State Attribute.




FSI/RCNTRANS

File

4-Feb-10

1.4.6.2 Job Output:

Here is an example of the output for a missing account attribute.

If no records are found by the process the process will not create any files and give this output:

After correcting any missing attributes the process should be run in audit mode again to mark the

records as ‘I’ (in process). Only records that are at a status of an ‘I’ will be picked up by the

process in update mode.




FSI/RCNTRANS

File

4-Feb-10




FSI/RCNTRANS

File

4-Feb-10

Update Mode

The process will also create two .slk files for the client to review and reconcile the data using

Microsoft® Excel or another tool.

1.4.7 Modified Processes

1.4.8 New Reports

1.4.9 Modified Reports

1.4.10 New Reporting Structures

1.4.11 Modified Reporting Structures

1.5 Database

1.5.1 New Tables

1.5.1.1 NZRSPRT – State Payroll Export Reporting Table

In addition to the transaction information, the table will contain additional fields for

tracking/reporting purposes. These additional fields will be loaded by the NZPSRPT process.

The feed indicator and feed date will be used to determine whether the transactions have been

previously reported. The table will be initially populated with values using a table trigger on the

baseline table NHRDIST.

The table structure will be as follows:




FSI/RCNTRANS

File

4-Feb-10

Field Name Type Null? Comments

NZRSRPT_YEAR VARCHAR2(4) Y

From NHRDIST_YEAR populated by trigger. Pay Period Year for Expenditure Interface transactions. This will be NULL for all transactions other than Expenditure type transactions.

NZRSRPT_PICT_CODE VARCHAR2(2) Y

From NHRDIST_PICT_CODE populated by trigger Pay Period Year for Expenditure Interface transactions. This will be NULL for all transactions other than Expenditures.

NZRSRPT_PAYNO NUMBER(3) Y

From NHRDIST_PAYNO populated by trigger Pay Period Pay Number from Expenditure Interface transactions. This will be NULL for all transactions other than Expenditures.

NZRSRPT_PIDM NUMBER(8) Y

From NHRDIST_PIDM populated by trigger PIDM : Internal System Identification Number.

NZRSRPT_SEQ_NO NUMBER(2) Y

From NHRDIST_SEQ_NO populated by trigger Pay Event Identifying Sequence Number. This will be NULL for all transactions other than Expenditures.

NZRSRPT_HIST_TYPE_IND VARCHAR2(1) Y

From NHRDIST_HIST_TYPE_IND populated by trigger Pay Event Type Indicator pulled from PHRHIST_TYPE_IND. This indicates the type of Pay Event (Manual, Void, Redistribution etc).

NZRSRPT_CATEGORY_CODE VARCHAR2(1) Y

From NHRDIST_CATEGORY_CODE populated by trigger An internal code which identifies the type of Finance Interface transaction. (Earnings, Employee deductions, Net Pay, Budget Adjustment, Encumbrance etc.

NZRSRPT_SOURCE VARCHAR2(10) Y

From NHRDIST_SOURCE populated by trigger This column will help tie the transaction back to its source.




FSI/RCNTRANS

File

4-Feb-10


Different values are stored here depending on the transaction ... (For Earnings: Earn Code,

NZRSRPT_FISC_CODE VARCHAR2(4) Y

From NHRDIST_FISC_CODE populated by trigger The Fiscal Year to which this interface transaction will be posted.

NZRSRPT_RUCL_CODE VARCHAR2(4) Y

From NHRDIST_RULC_CODE populated by trigger The Finance System Rule Class code to be applied to this interface transaction.

NZRSRPT_COAS_CODE VARCHAR2(1) Y

From NHRDIST_COAS_CODE populated by trigger Chart of Accounts Code. Only filled if Finance System present.

NZRSRPT_FUND_CODE VARCHAR2(6) Y

From NHRDIST_FUND_CODE populated by trigger Fund. Filled if Banner Finance is present.

NZRSRPT_ORGN_CODE VARCHAR2(6) Y

From NHRDIST_ORGN_CODE populated by trigger Organization. Filled if Banner Finance is present.

NZRSRPT_ACCT_CODE VARCHAR2(6) Y

From NHRDIST_ACCT_CODE populated by trigger Account. Filled if Banner Finance is present.

NZRSRPT_PROG_CODE VARCHAR2(6) Y

From NHRDIST_PROG_CODE populated by trigger Program. Can only contain a value if Banner Finance is present.

NZRSRPT_ACTV_CODE VARCHAR2(6) Y

From NHRDIST_ACTV_CODE populated by trigger Activity. Will only contain a value if Banner Finance is present.

NZRSRPT_LOCN_CODE VARCHAR2(6) Y

From NHRDIST_LOCN_CODE populated by trigger Location. Can only contain a value if Banner Finance is present.

NZRSRPT_DR_CR_IND VARCHAR2(1) Y

From NHRDIST_DR_CR_IND populated by trigger Interface Debit/Credit indicator. This column can have a value of D, C, + or - depending on the particular transaction and whether that transaction repress

NZRSRPT_AMT NUMBER(11,2) Y From NHRDIST_AMT populated by trigger




FSI/RCNTRANS

File

4-Feb-10


The absolute amount of the transaction (always a positive number). The NHRDIST_DR_CR_IND is used when representing negative transactions.

NZRSRPT_TRANS_DATE DATE

From NHRDIST_TRANS_DATE populated by trigger The transaction date used to post this entry through into the Finance system.

NZRSPRT_BDCA_CODE VARCHAR2(3) Y From NHRDIST_BDCA_CODE populated by trigger

NZRSRPT_DOC_TYPE VARCHAR2(1) Y

From PHPDOCM_DOC_TYPE DOCUMENT TYPE; Indicates whether the document is a check or a direct deposit

NZRSRPT_PRIORITY NUMBER(2) Y

From PHPDOCM_PRIORITY PRIORITY: The sequence that the documents are generated in.

NZRSRPT_DOC_NO VARCHAR2(9) Y

From PHPDOCM_DOC_NO DOCUMENT NUMBER: The check or direct deposit notice number.

NZRSRPT_DOC_DATE DATE Y

From PHPDOCM_DOC_DATE DOCUMENT DATE: Date of the check or direct deposit notification.

NZRSRPT_NET NUMBER(11,2) Y

From PHPDOCM_NET NET AMOUNT: The amount of the check or direct deposit.

NZRSRPT_ACCT_FEED_IND VARCHAR2(1) Y

Records whether the reallocation has taken place on this transaction. Works together with Feed Date. Initially loaded with a ‘Y’ and NZPSPRT will update it to an ‘I’ when run in audit mode and ‘F’ when run in update mode.

NZRSRPT_FEED_DATE DATE Y

Date the record was reported to the State. When the acct_feed_ind is turned to ‘F’

NZRSRPT_FSI_SOURCE_DOC_SEQ NUMBER(3) Y

FSI SOURCE DOC SEQ:Source doc sequence number for FSI export file. Used in the new numbering of the DOCID2 for the FSI file. The new coding will start with a CUx7nnnnnn. This will keep track of the 1 up numbering of the documents reported.

NZRSRPT_FSI_SOURCE_DOC_YEAR VARCHAR2(4) Y FSI SOURCE DOC YEAR:Source doc year for FSI




FSI/RCNTRANS

File

4-Feb-10


export file. Used in the new numbering of the DOCID2 for the FSI file. The new coding will start with a CUx7nnnnnn. This will keep track of the fiscal year the document was reported in. Used in the third position of the doc id2.

NZRSRPT_STATECO VARCHAR2(8) Y

From Attribute for Fund. STATE COMPANY:Code and description of the Company Codes.

NZRSRPT_STATESA VARCHAR2(8) Y

From Attribute for Acct. STATE ACCOUNT:Code and description of the State Account.

NZRSRPT_STATECE VARCHAR2(8) Y

From Attribute from Fund. STATE CENTER:Code and description of the Center Codes.

NZRSRPT_STATESS VARCHAR2(8) Y

Special code from Fund Attribute that will overlay account code with new code if populated. STATE SS: Fund Based attribute to modify State Account. (only overlay the State Account if populated. If STATESS attribute is entered then a STATESU has to be entered)

NZRSRPT_STATESU VARCHAR2(8) Y

Special code from Fund Attribute that will overlay account code with new code if populated. STATE SU:Fund Based attribute to modify State Account. (only overlay if populated)

NZRSRPT_REDIS_BANK VARCHAR2(2) Y From FTVFUND_BANK_CODE

NZRSRPT_EXPORT_DESC VARCHAR2(29) Y

EXPORT DESC FOR FSI FILE-

CHECK TRANSACTIONS -

BRP

ACH TRANSACTIONS


CANCELLED ACH

And the export description

(GZRXWLK_STATE_VALUE)

for the benefit/deduction code

that matches the

NZRSRPT_BDCA_CODE

identified in the new table,

GZRXWLK.




FSI/RCNTRANS

File

4-Feb-10

1.5.1.2 GZRXWLK – Data Crosswalk Table

A new table will be created to store the benefit/deduction export descriptions. The table will have

one description per benefit/deduction code. The new process NZPSRPT will use this description

value for the benefit/deduction codes defined.

Column Name Null? Type Comments

GZRXWLK_SOURCE_TABLE No VARCHAR2(30) CROSSWALK SOURCE TABLE:

Banner table to be cross-walked.

GZRXWLK_SOURCE_COLUMN No VARCHAR2(30) CROSSWALK SOURCE COLUMN:

Banner column on the crosswalk source

table to be cross-walked.

GZRXWLK_SOURCE_VALUE No VARCHAR2(30) CROSSWALK SOURCE VALUE:

Banner source column value.

GZRXWLK_ACTIVITY_DATE No DATE ACTIVITY DATE: Date of last

activity (insert of update) on the record.

GZRXWLK_USER_ID No VARCHAR2(30) USER ID: The Oracle ID of the user

who changed the record.

GZRXWLK_DATA_ORIGIN Yes VARCHAR2(30) DATA ORIGIN: Source system that

created or updated the row.

GZRXWLK_PROCESS_ID No VARCHAR2(10) CROSSWALK PROCESS ID: The

Banner job name, from Banner job

submission, of the process that uses the

cross-walked value.

GZRXWLK_STATE_VALUE No VARCHAR2(30) CROSSWALK STATE VALUE: The

state value of the cross-walked Banner

source column and value.




FSI/RCNTRANS

File

4-Feb-10

1. The NZPSRPT process will only change descriptions of the deductions for Employee

Liabilities and Employer Liabilities (baseline rule class codes HEEL and HERL). The process will

Rule class codes will also need to be used to determine which records should the description

should be changed on.

The rule classes included will be determined by the current fiscal year NTRFINI record and will

not be hard-coded. This will allow the school to use a site created rule class code for employee

and employer liabilities. Currently the school uses the delivered rule class HEEL and HERL.

2. The state attributes codes for COMPANY, CENTER, and ACCOUNT do not follow the same

rules based on the Banner fund and account attribute records for deductions. The three State

Codes are specific to the individual deduction code. SDBOR needs to be ability to identify these

three fields for each benefit/deduction code. The State Codes reported in the FSI file and the

third report of NZPSRPT will include these codes where appropriate. The update will follow the

logic of the description change in the FSI file. (HEEL or HERL rule class code and the deduction

code matches)

A new entry will be made for the State Codes for each deduction code in the GZAXWLK table. This new entry will be identified by the table NZRSRPT and the column NZRSRPT_BDCA_CODE. The State code will be listed in this table as COMPANY-CENTER-ACCOUNT with hyphens between the three. The identified state values for each deduction will be used in the FSI interface file. The state codes will only be used for a transaction in NZRSRPT when the deduction code matches and the transaction has the Employee liability (HEEL) or Employer Liability (HERL) rule class codes.




FSI/RCNTRANS

File

4-Feb-10

1.5.2 Modified Tables

1.5.3 New Views

1.5.4 Modified Views

1.5.5 New Functions

1.5.6 Modified Functions

1.5.7 New Procedures

1.5.8 Modified Procedures

1.5.9 New Packages

1.5.9.1 NHRDIST Trigger

A new trigger will be created to the NHRDIST table to load the required information in the

NZRSRPT table.




FSI/RCNTRANS

File

4-Feb-10

A post-insert trigger will be created to the NHRDIST capture and store all Financial Information

that needs to be reported to the State from the Banner® HR system.

Trigger will not load transactions that start with an ‘A’. These transactions are adjustments and it

is assumed that they net to zero. No transactions will be reported to the state and the transactions

will not be in the custom table.

Net Pay will be excluded from the Trigger as well based on the rule class value for net pay in

NTRFINI.

1.5.10 Modified Packages

1.5.11 New Other

1.5.12 Modified Other

2 Cross Enterprise Considerations

2.1.1 Campus Pipeline/Luminis

2.1.2 SunGard Higher Education’s Workflow Examples

2.1.3 WebCT Interface Processes

2.1.4 Learning Systems

2.1.5 Other Interfaced Systems

3 Performance Requirements

3.1 Anticipated System Usage

3.2 Response/Execution Time

3.3 Error Handling/Recovery




FSI/RCNTRANS

File

4-Feb-10

4 Contract Information

Modification Data

Initial Proposal Date:

Product(s) Targeted for

Modification:

Intended Release:

Institutional Data

Product(s) Currently in Use:

Client Contact(s)

1. Last Name:

First Name:

Telephone Number:

Email Address:

2. Last Name:

First Name:

Telephone Number:

Email Address:




FSI/RCNTRANS

File

4-Feb-10

5 Approval to Proceed

The signatures below indicate that SDBOR 009 Functional Specification v5.02 meets the

approval of the undersigned and thereby grants SunGard Higher Education the approval

to proceed.

Please fax this approval page to Jason Norem at 610-578-3395.

________________________________________ ______________

Signature Date Print Name:

Print Title:

________________________________________ ______________

Signature Date Print Name:

Print Title:




FSI/RCNTRANS

File

4-Feb-10

6 Document History

Revision Record

Number Date and Sections Author Notes

1.00 10/09/2006 All Jason Norem First Draft

2.00 10/20/2006 Jason Norem Adjusted after discussion with Client/State

3.00 11/01/2006 Jason Norem Adjusted after discussion with Client/State

4.00 11/06/2006 Jason Norem Revised after client review

5.00 11/6/2006 Jason Norem Change crosswalk table to a generic

crosswalk table that can be used with both

SDBOR 007 and SDBOR 009.

6.00 2/4/2010 Jason Norem Updated to include all change requests.




FSI/RCNTRANS

File

4-Feb-10

7 Acronyms

Acronym Description

AMC Account Management Council

AMM Account Management Methodology

CAM Client Account Management

CDM Common Development Methodology

CMS Common Star

CSM Common Services Methodology

PEG Process Engineering Group

PMC Project Management Council

PMM Project Management Methodology

ProNet SunGard Higher Education’s Process Network

PTDB Project Tracking Database

RPE Request for Product Enhancement

SPG Software Process Group

SQ&P Services Quality and Processes

8 Definitions

Term Definition

SDBOR 009 Functional Specification v6mytraining.sdbor.edu/resources/banner/Multiple... · optimal...

Documents

Transcript of SDBOR 009 Functional Specification v6mytraining.sdbor.edu/resources/banner/Multiple... · optimal...