Subaward Encumbrances & Subaward Invoice …...subaward document in KC, a Purchase Requisition and Purchase Order is created in KFS using a nightly batch process (not immediate) which

© Kuali Foundation 2008

Kuali Coeus

System Requirements Specification

Subaward Encumbrances & Subaward Invoice Payments Module: Subaward

Gap: KC lacks the ability to encumber subaward balances - KC-AWD18 Subaward & KC-AWD19 Subaward Invoicing

Abstract: This document will provide details on encumbering subawards in KFS by creating a

Requisition (REQ) which auto approves to generate an Automatic Purchase Order (APO) and

processing Payment Request (PREQ) against the PO to reduce the encumbrances.

Author(s): Chris Kropelnyckyj

Contributor(s):

Current Owner: Chris Kropelnyckyj

Revision: Version

1.0

Create Date: February 16, 2015

Last Save Date: March 5, 2015

<Document Name – Revision> Last Save: 1/12/14 7:18 AM

Page 2 of 26

Contents

CONTENTS ......................................................................................................................................................... 2

TABLES ............................................................................................................................................................... 3

FIGURES ............................................................................................................................................................ 3

1. INTRODUCTION ........................................................................................................................................... 4

1.1. Purpose ................................................................................................................................................... 4

1.2. Review ..................................................................................................................................................... 4

1.3. Document Revision History ........................................................................................................ 4

1.4. References ............................................................................................................................................ 4

2. BUSINESS REQUIREMENTS AND OBJECTIVES ..................................................................................... 5

3. BUSINESS RULES ........................................................................................................................................ 5

4. USER REQUIREMENTS ............................................................................................................................... 5

4.1. Narrative – User Story ................................................................................................................... 5

4.2. Important Concepts and Background ................................................................................... 5

4.3. User Classes and Roles .................................................................................................................. 5

4.4. User Requirements .......................................................................................................................... 6

4.5. Index to Use Cases .......................................................................................................................... 6

4.6. Use Cases .............................................................................................................................................. 6

5. FUNCTIONAL REQUIREMENTS ............................................................................................................... 12

6. DATA DICTIONARY................................................................................................................................... 14

6.1. Data Dictionary Items .................................................................................................................. 14

6.2. Grouping and Sort Order ............................................................................................................ 14

7. USER INTERFACE DESIGN ...................................................................................................................... 15

7.1. User Interface Workflow ............................................................................................................ 15

7.1.1. Tab Order of Fields ..................................................................................................................... 15

7.2. Design Requirements ................................................................................................................... 15

7.3. User Interface Mock-up .............................................................................................................. 16

8. USER DOCUMENTATION NOTES ............................................................................................................ 18

9. DESIGN AND IMPLEMENTATION NOTES ............................................................................................. 18

9.1. Constraints and Issues ................................................................................................................ 18

9.2. Other Technical ................................................................................................................................ 19

10. APPENDIX .............................................................................................................................................. 19

10.1. Document Change Log ................................................................................................................. 19

10.1.1. [Date] ............................................................................................................................................ 19

10.2. Issues List ........................................................................................................................................... 19

10.2.1. Open/In Progress ...................................................................................................................... 19


Page 3 of 26

10.2.2. Resolved ....................................................................................................................................... 19

Tables

Table 1 Document Reviewers ..................................................................................................................... 4

Table 2 Document Revision History .......................................................................................................... 4

Table 3 Relevant Documents...................................................................................................................... 4

Table 5 User Roles and Classes ................................................................................................................. 5

Table 6 Use Case Sample........................................................................................................................... 6

Table 7 Functional Requirements ............................................................................................................ 12

Figures No table of figures entries found.


Page 4 of 26

1. Introduction 1.1. Purpose

The purpose of this system requirements specification is to identify how to encumber subaward funds in KFS by

creating a requisition which auto approves to generate an Automatic Purchase Order (APO) and processing

Payment Requests (PREQ) against the PO to reduce the encumbrances.

1.2. Review

The following people have read and agreed to the contents of this document:

Table 1 Document Reviewers

Name, Title (or Role) Organization Signoff, Date

Renee Dolan KC Award Workgroup

Chitra Chandran KC Technical

Workgroup

Dan Evon CGA

Steve Ueberroth, Shyam Gedela KFS – Functional,

Technical

Greg Deppong, Lee Hunter, Kim Kokenakes Controller’s Office,

University Services

1.3. Document Revision History

The following table lists major revisions of this document following table. Please see the Document Change Log

on page 19 for a detailed list of changes.

Table 2 Document Revision History

Document Version Revision Name - Description Revision Date Author(s)

1.0 First Draft 2/16/2015 Chris Kropelnyckyj

1.4. References

Documents that have information relating to the information discussed in this document.

Table 3 Relevant Documents

Document Title Description Location FBAS FDS FIN-1686 KC Requisition interface to

KFS for Subaward

https://jira.itservices.msu.edu/browse/FIN-1686


Page 5 of 26

2. Business Requirements and Objectives

The system shall provide the ability to encumber subaward funds in KFS. The system shall also provide for subaward

invoice information to be entered into KC by the Department or College, certified and approved by the PI and finally,

routed to CGA for approval in KC. Encumbering subaward funds in KFS will be a significant improvement because

Departments and Colleges are unable to get a true account balance when subaward funds are not encumbered.

Because of this, shadow systems are being maintained.

3. Business Rules

None

4. User Requirements 4.1. Narrative – User Story

Once CGA has a fully executed subaward, the Subaward document is finalized in KC. Final Subaward documents

will be sent to KFS via a nightly batch process, which then triggers the creation of a requisition (REQ). The REQ is

automatically approved which generates an Automated Purchase Order (APO) in KFS.

The subaward invoice information will be entered into KC by department administrators and routed to the PI for

certification and approval. The Subaward Invoice is then routed to CGA for approval. Upon CGA approval, an email

with a link to the KC document will be system generated to [email protected], which includes: the PO number, vendor

name, invoice number, object code(s) and amounts. An Accounts Payable auditor will download/review the invoice

and enter the payment into KFS on a Payment Request (PREQ). Once the payment is issued via the PREQ, the PO

encumbrance will be reduced by the amount of the payment.

If a Subaward is versioned requiring a Purchase Order Amendment, CGA will enter a note detailing the PO number

and the changes needed and send it to Purchasing to amend the Purchase Order in KFS.

Since the APO will be automatically approved in KFS, there won’t be Subaccount and Subobject information in KFS.

These could potentially be added (at Purchasing’s discretion) by amending the PO prior to the first payment being

applied in KFS.

4.2. Important Concepts and Background

None

4.3. User Classes and Roles

The following table lists the groups of people that are expected to interact with the system. Each user class role is

considered when documenting the procedures that users will follow when interacting with the system. In the use cases,

these are called “Actors.”

Table 4 User Roles and Classes

User Class Role Description: the group and how they are expected to use the system.

CGA Admin CGA Administrator CGA will need to encumber subaward, and approve subaward invoices.

mailto:[email protected]


Page 6 of 26

PI Researcher PI will need to view subawards, enter subaward invoices, and approve

payments for subawards that they are associated with.

Dept./College Admin Unit Administrator Dept. /College Admin will need to enter payments for subawards within

their Dept. /College and view subawards and subaward invoice document

for their Dept. /College.

Purchasing Staff/Accounts

Payable Staff

View Subaward The purchasing/accounts payable staff will need the view subaward

permission to be able to view the current subaward and subaward invoice

document to modify the PO as needed or to enter the Payment Request

within KFS.

The KFS roles needed are Purchasing Processors, Contract Manager, AP

Processor, and AP Manager.

4.4. User Requirements

# ID(s) User Requirement

1 The user shall be able to enter the financial information on a subaward, and upon approval of the

subaward document in KC, a Purchase Requisition and Purchase Order is created in KFS using a

nightly batch process (not immediate) which encumbers the funds.

2 The user shall be able to enter subaward invoice information in KC and upon final approval by

CGA, an email is generated so that a payment (PREQ) against the PO may be entered by Accounts

Payable which will automatically route to the Fiscal Officer in KFS. CGA needs to be excluded

from the route path of the PREQ based on the object code.

3 The user shall be able to begin the PO amendment process with an automated notification generated

from KC.

4.5. Index to Use Cases

The following table lists the use cases

Use Case ID Use Case Name Use Case Description

1 Create Encumbrance User shall be able to enter subaward financial information in KC and ultimately

create a Purchase Requisition/Purchase Order in KFS to encumber funds via a

nightly batch process.

2 Create subaward invoice in KC User shall be able to enter subaward invoice information in KC so that a

payment can be processed in KFS.

3 Modifying a PO (POA) User shall be able to request a POA and begin the PO amendment process.

4.6. Use Cases

Table 5

1 Use Case ID: 1

2 Use Case Name Create Encumbrance

3 Priority:

4 Actor(s): CGA Administrator


Page 7 of 26

5 Description: Users with modify subaward permissions will have the ability to enter subaward financial

information in KC and generate a Purchase Order to encumber funds via a nightly batch

process.

6 Precondition(s): The user needs the modify subaward permissions.

7

Normal Course: CGA

Entering

N1 Subaward entry

User logs on to the KC system.

From the Central Admin tab the User selects the Subawards data entry (green plus sign).

1) The System displays the KC Subaward tab.

2) The User enters information to create a Subaward in the required fields of

Description, Subaward Type, Requisitioner User Name, Subrecipient, Status, Award

Number and adds the award, Person or organization, project role and selects the

“add” button to add the contact.

3) Purchase Order ID is an optional field and will need to be populated based on KFS

data.

4) The user saves the document or navigates to the Financial Tab.

5) The System displays the History of Changes panel.

6) The user enters information in the Effective date, Obligated Change, Anticipated

Change, Object Code, and chooses a file if needed and selects the “Add” to add the

data.

7) User navigates to Subaward Actions tab.

8) The system displays “Submit, Save, Reload, and Close” buttons.

9) User selects the “Submit” button.

10) The Subaward document is finalized.

11) A Req./APO is created/generated in KFS via a nightly batch process.

12) The Purchase Order is posted in KFS.

8

Alternative Course(s):

Correct errors

A1 User logs on to the KC system.

From the Central Admin tab the User selects the Subawards search (green plus sign).

1) The System displays the KC Subaward tab.

2) The User edits the Subaward and creates a new version of the Subaward as needed.

3) The user enters any changes needed to correct the errors. Specifically the required

fields in the Subaward: Description, Subaward Type, Requisitioner User Name,

Subrecipient, Status, Award Number and adds the award, Person or organization,

project role and selects the “add” button to add the contact.

4) The user saves the document or navigates to the Financial Tab.

5) The System displays the History of Changes panel.

6) The user enters information in the Effective date, Obligated Change, Anticipated

Change, Object Code, and chooses a file if needed and selects the “Add” to add the

data.

7) User navigates to Subaward Actions tab.


9) User selects the “Submit” button.

10) The Subaward document is finalized.

11) The user manually creates in note in KC with the requested PO amendment details,

including PO # and change in every notification.

12) The user sends the note to the Purchasing staff member.

9 Exceptions: E1 None

10 Post-conditions: PO1 REQ/APO generated via a nightly batch process.

11 PO2 Funds for subaward are encumbered in KFS, on the following business day.

12 Special Requirements: SR1

13 Assumptions:

14 Notes and Issues:

15 Use Case ID: 2


Page 8 of 26

16 Use Case Name Create Subaward invoice in KC and payment in KFS

17 Priority:

18 Actor(s): Dept./College Admin., PI, CGA Administrator, Fiscal Officer, Accounts Payable

19

Description: Dept. /College or PI will be able to create a subaward invoice in KC. In KC, the PI

certifies the invoice. CGA, will approve the subaward invoice. KC will email payment

information for the PO payment to Accounts Payable including the PO # and vendor

name in the subject line, and how to apply the vendor invoice to the PO line items,

accounting string, and the link to the KC document for the invoice. The Fiscal Officer

will approve the payment in KFS. Accounts Payable issues the check/wire payment.

20

Precondition(s): 1) A Subaward needs to be in final status before an invoice is paid.

2) A Subaward will need to be linked to an award. (We need this for the account

information).

3) The user will need create subaward invoice permission for subaward invoice data

entry.

4) The user will need subaward requisitioner review approver role for KC approvals.

21

Normal Course:

Department Entering

N2 Create Subaward invoice in KC and payment in KFS

1) Dept./College Administrator searches for the Subaward using the subrecipient

that needs payment.

2) System displays existing subawards.

3) User selects the “Open” action for the subaward that needs payment.

4) The system displays the selected subaward.

5) User navigates to the Financial tab.

6) The system displays “Add invoice, Save, Reload, and Close” buttons.

7) User selects the “Add invoice” button.

8) The system displays the subaward invoice panel.

9) The User enters information in the Description, Invoice ID, Start Date, End

Date, Object Code 1, Amount Released 1, Object Code 2, Amount Released 2,

Effective Date, and attaches the invoice. We are modifying the object code 1

and 2 and Amount released 1 and 2 fields.

10) The system displays buttons of “Submit, Save, Close, and Cancel”.

11) The User selects the “Submit” button.

12) The invoice is submitted into routing in KC to the PI for certification approval.

13) The PI opens the subaward invoice in KC.

14) The system displays buttons of “Send ad hoc request, Approve, Disapprove,

and Close”.

15) The PI checks the PI certification box.

16) The PI selects the “Approve” button for the invoice in KC.

17) The invoice is routed to CGA for approval.


and Close”.

19) The CGA Administrator selects the “Approve” button.

20) KC automatically notifies Accounts Payable that the invoice is available in KC

for payment processing against the PO via email (real time notification).

21) Accounts Payable creates the PREQ in KFS.

22) Invoice routes to Fiscal Officer for approval.

23) Fiscal Officer adds sub-account and sub-object information as needed.

24) Fiscal Officer approves payment in KFS.

25) Accounts Payable issues check/wire payment.


Page 9 of 26

22

Alternative Course(s):

PI Disapprove

A1 1) The invoice is submitted into routing in KC to the PI for certification and

approval.



and Close”.

4) The PI selects the “Disapprove” button the invoice in KC.

5) The system asks “Are you sure you want to disapprove this document?” and

displays “Yes or No” buttons.

6) The system requires the user enter a reason in the box provided.

7) The User enters the reason in the box provided.

8) The User selects the “Yes” button and the system returns the user to the Central

Admin tab.

9) The User selects the “No” button and the system returns the user to the

Subaward Invoice panel.

23

CGA Disapprove A2 1) Dept./College Administrator searches for the subaward using the subrecipient

that needs payment.










Effective Date, and attaches the invoice.

10) The system displays buttons of “Submit, Save, Reload, Close, and Cancel”.


12) The invoice is submitted into routing in KC to the PI for certification and

approval.



and Close”.

15) The PI checks the certification box.

16) The PI selects the “Approve” button the invoice in KC.

17) The invoice is routed to the CGA Administrator for approval.


and Close”.

19) The CGA Administrator will “Disapprove” the invoice if it is not attached in

KC.

20) The CGA Administrator selects the “Disapprove” button.


displays a “Yes or No” button.




Admin tab.




Page 10 of 26

24

PI Enter & Approve A3 1) PI searches for the subrecipient that needs payment.





6) The system displays “Add invoice, Save, Reload, and Close” buttons.





Effective Date, and attaches the invoice.

10) The PI checks the certification box.

11) The system displays buttons of “Submit, Save, Close, and Cancel”.


13) Selecting Submit by the PI both approves and submits the invoice into routing.

14) The invoice is routed to the CGA for approval.

15) CGA opens the subaward invoice in KC.


and Close”.

17) The CGA Administrator selects the “Approve” button.

18) KC automatically notifies Accounts Payable that the invoice is available in KC

for payment processing against the PO via email.

19) Accounts Payable creates the PO invoice payment in KFS.


21) Fiscal Officer adds sub-account and sub-object information as needed.



25

PI Enter, CGA Disapprove A4 1) The invoice is routed to CGA for approval.

2) CGA opens the subaward invoice in KC.


and Close”.

4) The CGA Administrator selects the “Disapprove” button.


displays a “Yes or No” button.




Admin tab.



26

FO / AP Disapproves

Payment in KFS

A6 1) If CGA approves invoice in KC and notifies Accounts Payable, the payment is

correct in KC. If CGA disapproves in KC, no payment notification is sent to

AP. Accounts Payable re-creates the PO invoice payment in KFS.


3) Fiscal Officer adds sub-account and sub-object information.



27 Exceptions: E1 None

28 Post-conditions: PO1 CGA approves invoice

29 PO2 Payment is processed in KFS by Accounts Payable.

30 Special Requirements: SR1

31 Assumptions:

32 Notes and Issues:


Page 11 of 26

`

33 Use Case ID: 3

34 Use Case Name Modifying a Purchase Order

35 Priority:

36 Actor(s): CGA Administrator

37 Description: CGA will need to request Purchasing Processors to amend a PO that has been created for

a subaward, either to change the dates or object codes/amounts of a subaward.

38 Precondition(s): 1) A PO has been created for a subaward.

2) The user needs to modify the subaward, either by changing a date, object code(s), or

modifying funds.

39

Normal Course: N3 1) User navigates to an existing subaward.

2) User chooses the “edit” button and versions a subaward.

3) User edits any needed information on the Subaward tab.


5) User adds/subtracts any funds, changes dates or object codes in the history of

changes panel as needed.

6) User sends a workflow note is sent to a person in Purchasing that identifies the

change(s) needed and the PO number. The changes in KFS need to be detailed in

the note text.


Page 12 of 26

5. Functional Requirements

Table 6 Functional Requirements

# ID Requirement

1 When a subaward document is final, and Purchase Requisition/Purchase Order is created via a nightly batch process

which will encumber funds in KFS.

2 The user shall be able to enter object code information into KC for subaward invoices.

3 Will need a code table or a parameter to populate the two object codes on the subaward invoice. As this functionality is

tentatively being contributed back to the KC community, we need to confirm what is best as different schools use

different object codes.

4 Need a new create subaward invoice permission for the ability to create a subaward invoice and not modifying any other

subaward data. (This is already complete with KIM configuration work)

5 CGA will need the ability to change the object code amounts in a subaward invoice, while not changing the total

submitted.

6 KC should provide a total field for the amounts released on the subaward invoice.

7 Purchase Order number field in KC changed from required to optional as the PO # won’t be known until APO created in

KFS.

8 When the invoice payment is approved by CGA, an email will be automatically issued to [email protected] with the

subject line including PO number and vendor name. The body of the email should include payment instructions, on how

to appropriately apply vendor invoice to PO line items and accounting string (account, object codes and amounts) with a

link to the KC document number for the invoice. This is a real time notification/email.

9 Subaward Invoice Maintenance document: need to be able to enter notes and attachments via the Notes and Attachments

panel during routing.

10 KC will need to validate account numbers with KFS.

11 KC will need to sync/validate Vendors/Vendor Codes with KFS.

12 Add valiation rule that Organization records in KC must have a Vendor Code, which is KFS Vendor #.

13 Batch feed errors and handling will be listed in the KFS specification.

14 Will need a way to populate the Purchase Order number back into KC once the Purchase Order number is known in KFS.

Since the PO numbers are listed in the success emails, KC would prefer a file from KFS with this information.

15 KFS Document Description field: populated with, “KC Subaward ID, Sponsor Acronym and PI Last Name”; truncate

after 40 characters.

16 KFS: Needs to add a parameter or validation rules to lock KFS account, object code and amount in routing of the

payment request.

17 mapping See the following table that maps KC fields to KFS.

APO Field KC Field Required? Comments

Header Info

Record Type PH Y

Prefix and Number KC Subaward Code Y String up to 20 characters

mailto:[email protected]


Page 13 of 26

Ship to Building 0067 Y

Ship to Room # 2 Y

Due Date MM/DD/YYYY format N Leaving empty, not req’d

Buyer ID 99 Y

Buyer Name N Defaults in with Buyer ID

Vendor ID Vendor Code Y From KC Organization

BPO Indicator Y Y

Header Description KC Subaward ID, Sponsor Acronym, PI Last Name

Y KFS Document Description; 40 character limit

Org Doc Number KC Subaward Document Number Y

Terms Net Y

FOB N/A Y

Shipping Title N/A Y

Type of PO GRAN Y

PO Start/End Dates KC Subaward Period of Performance Start/End Dates

Y

Line Info

Record Type PL Y

Prefix and Number KC Subaward Code Y Has to match above

Line Number Item Line # (1,2, etc) Y

Item Type Code SRVC Y

Item Description Subaward Title Y

Quantity N/A N

Quantity/UOM N/A N

Unit Price KC Obligated Amount Y

PO Item Number N Leaving empty, not req’d

Trade in Indicator N Y

Account Info

Record Type AD Y

Prefix and Number KC Subaward Code Y Has to match above

Line Number Item Line # (1,2, etc) Y

Account MS, Account, Object Code, Amount Y

Percent 100% Y

Capital Asset Info

Not applicable

Notes Leaving empty for the time being


Page 14 of 26

6. Data Dictionary 6.1. Data Dictionary Items

Terms not already defined in the KC Data Dictionary should be added to the table below during the specification

process. Once finalized, the terms should be added to the MSU Kuali Coeus Data Dictionary.

Data Item Name Description

Object Code 1 Code table populates two object codes here of 6593, and 6594 for MSU. *

Object Code 2 Code table populates two object codes here of 6593, and 6594 for MSU. *

Amount Released 1 Numeric amount field where a portion of payment for object code 1 is listed. *

Amount Released 2 Numeric amount field where a portion of payment for object code 2 is listed. *

Total Amount Released Numeric amount field which provides a sum of Amount Released 1 and Amount

Released 2, and is not editable.

*Note

We may only need one object code or amount released depending on how this is

implemented. Awaiting decision from Technical team on how best to do this.

6.2. Grouping and Sort Order

Group in following order:

Group Name Sort Order

None


Page 15 of 26

7. User Interface Design 7.1. User Interface Workflow

None

7.1.1. Tab Order of Fields

None

7.2. Design Requirements

# ID Requirement

1 1) The user shall be able to enter object code information into KC for a subaward.

2 2) The user shall be able to enter object code information into KC for a subaward invoice.


Page 16 of 26

7.3. User Interface Mock-up

Note for Technical Team – How is it best to implement this technically? I would prefer an amount box with a drop

down to select an object code next to it. Usually there is only one invoice to cross over (2) object codes.

The Dept. /College enters the invoice. The invoice routes to

the PI who certifies & approves the invoice. The document

then routes to CGA for approval. After CGA approves the

invoice, a KFS document can be processed for payment.

Insert box for KC “Object Code 1”

here. Code table should map Object

Code to two options 6593

Subcontracts <= $25,000 and 6594

Subcontracts > $25,000. Change

Amount Released to “Amount

Released 1”. Insert box for KC “Object

Code 2” here. Code table

should map Object Code to

two options 6593

Subcontracts <= $25,000 and

6594 Subcontracts > $25,000.

Insert numeric field of

Amount Released 2 below

Object Code 2. Need to add a Total Amount Released

field that is a sum of both of the Amount

Released 1 and Amount Released 2. This

should be under the Amount Released 2

field and should be not editable.

This should be similar to the Obligated

Amounts 1 and 2 on the previous page.

And is it easier to select the Object Codes

from a drop down, in terms of

contributing it to the Foundation code.


Page 17 of 26

Screenshots above for the workflow note needed to modify a Purchase Order.

This is an example of a Requisition inbound file.


Page 18 of 26

8. User Documentation Notes

None

9. Design and Implementation Notes 9.1. Constraints and Issues


Page 19 of 26

9.2. Other Technical

None

10. Appendix 10.1. Document Change Log

Important changes and additions since the last published version are noted in the list below and in the document

by an orange star.

10.1.1. [Date]

Description of Change

10.2. Issues List

10.2.1. Open/In Progress

Issue ID: 9 Reporter: Jira #:

Status: Open Create Date:

Subject/Title: There is a fiscal year end process in KFS that allows AP to backpost payments to the old FY. Is

this needed in KC?

Description:

Owner(s): Next Step(s): Due:

Date:

Close Date:

Resolution:


Status: Open Create Date:

Subject/Title: Need to know if interface feed is a fixed length feed or variable length feed.

Description:


Date:

Close Date:

Resolution:


Status: Open Create Date: 2/18/2015

Subject/Title: The subaward document in KC requires a PO# that won’t be available until the nightly batch

process runs. Need a way to populate that field in KC when complete & bypass requiring that

field during Subaward data entry.


Page 20 of 26

Description:


Date:

Close Date:

2/18/2015

Resolution:

10.2.2. Resolved


Status: Closed Create Date: 2/16/2015

Subject/Title: Can we delete Buyer ID and Buyer name from mapping table and fields needed to create APO?

Description: The Buyer ID field is required by KFS.


Date:

Close Date:

KFS is going to have to determine how to best populate these fields; it depends on 2/18/2015

which interface/process is used. The interface will be a combination of the

Cyclotron and FAMIS

Resolution: Cyclotron & FAMIS feeds and will need to determine, if required, how to

information back to KC to populate the PO# field. See Issue #1 above.



Subject/Title: To process a payment via PREQ, an attachment is required.

Description: Why should we store the same attachments in both KC and KFS? How can we get past this requirement?


Date:

Close Date:

KC would need an attachment for the system of record since the PI/CGA approvals 2/18/2015

are happening in KC.

Resolution: KC will automatically generate an email notification with a link to the subaward invoice document so Accounts

Payable can pull the attachment out of KC.



Subject/Title: Need to determine how to modify purchase orders.

Description: How do we extend PO dates and add or delete funds? If the document doesn’t route can we still include FYI’s?


Date:

Close Date:

2/18/2015

Resolution: A notification detailing the changes needed will be sent from CGA via the Subaward document in KC. Fields needed

are the PO number, Period of Performance Start Date, Period of Performance End Date, Obligated Amount.



Subject/Title: Requested info from CGA for purchasing based on 6/23/2014 KFS meeting.

Description: 1. Approximate number of unique vendors (subawardees)? 800 unique subcontract recipients in Account Explorer


Page 21 of 26

2. Number of payment requests currently processes by DVs for subawards (monthly, quarterly, etc)? They want whatever is quickest easiest to get. In Fiscal Year 2014, we have approved more than 2500 subcontract payments (all as Disbursement Vouchers).

3. How are we paying international vendors (subawardees) now…wires? Checks? International subcontractors are paid via wire.


Date:

Close Date:

7/1/14 6/24/14

14

Resolution: Information Received 6/25/2014



Subject/Title: Need to convert DV vendors to PO vendors in KFS.

Description: KC will need to convert DV vendors from KFS into KC.


Date:

Close Date:

3/4/2015

Resolution: Yes this will be possible.



Subject/Title: Additional charges on subaward invoices.

Description: KC has confirmed that there will be no additional charges for freight, shipping and handling, miscellaneous, trade in, and full order discount on subaward invoices.


Date:

Close Date:

3/4/2015

Resolution: This information has been confirmed.



Subject/Title: Do we need to add a requirement for sensitive data?

Description: KC has confirmed that KC award data will be public information and no additional requirements need to be added.


Date:

Close Date:

3/4/2015

Resolution: This information has been confirmed.

10.3. Assumptions

1. KFS Development Work


Page 22 of 26

1. Cloning existing interface for Requisition Inbound files with differences below:

i. KC will only contain account number and object code information and will not offer the full KFS

accounting string (Account, Object Code, Sub account, Sub object, Project Code, and Org Ref ID).

KFS fully accepts the entire KFS accounting string, if it becomes essential to expand KC to capture

the full KFS accounting string, no code changes will be required by KFS. See appendix A for KFS

data related to sub accounting on DV subaward payments.

ii. Currently a daily email (~ 6 AM) is delivered to a specific “interface group” stating “Requisition

Source - [REQ Source Code] - Batch process successful records” which includes the number of

REQS/PO created/processed and various other data requirements.

iii. Currently a daily night batch process error and validation messages email (~ 8:30 PM) is delivered to

a specific “interface group” stating “Requisition Source - [REQ Source Code] - Batch process Error

or Validation Messages” which includes specific error and validations by specific Subaward Number

to explain why these transactions were not created in KFS.

iv. Future enhancement to all Requisition Inbound Interface files to include adding the PO Start and PO

End Dates.

2. KC requests the chart, account and object code cannot be changed in KFS. To accommodate this request,

KFS will add business rule validation on a POA to error upon submission if the account and object code

has changed from the most recent PO/POA version based upon percentages.


KFS will add business rule validation on a PREQ to error upon submission if the account and object code

has changed from the most recent PO/POA version based upon amounts.

Expired account numbers for both PREQ/VCM (Vendor Credit Memo) cannot automatically use the

continuation account number.

Closed account numbers for both PREQ/VCM cannot process on the closed account number.

4. Additional charges usage on REQ/PO are not applicable for KC REQS and will not be coded into the file.

If these become necessary, KFS may require an enhancement to the interface. Additional charges are:

Freight/Trade In/Full Order Discount/Miscellaneous

2. Requisition (REQ)/Purchase Order (PO)

1. KC desires their subaward document to create Automatic Purchase Orders (APOs) in KFS as appropriate.

2. A Requisition interface will be sourced from KC. Information collected in the KC subaward document

will be populated to the interface to KFS.

3. KC requisitions will bypass standard REQ KFS routing path below:

i. Organization (content reviewer) – optional driven by department

ii. Subaccount – optional driven by department

iii. Account (FO) – Required

iv. AccountingOrganizationHierarchy – optional driven by department

v. SeparationofDuties – optional driven by department

4. REQ will pass all APO business rules and a PO will be created with a system generated PO number.

5. Typical KC REQs file could include two non-quantity line items with one accounting line at 100% for

each line if the subaward is for more than $25,000. KFS REQ will be generated based solely only the

information contained in the KC file.

6. APO will bypass standard PO KFS routing path below:

i. Commodity – conditional if a specific commodity code on any line items is included. The

Commodity Reviewer role takes action at this route node.

ii. Award – conditional if any grant accounts used in items with two levels of review configured based

upon dollar amount of transactions.

iii. Budget – conditional – MSU not currently utilizing

iv. Tax – conditional based on vendor SSN match to KFS employee or foreign vendors

7. PO generates encumbrances when it reaches a workflow status of 'FINAL'. Encumbrances are created on

the accounting string entered in the item sections and the appropriate offset object code(s).

https://finalt.qual.ebsp.msu.edu/kfs-qa/static/help/WordDocuments/gloss_workflow.htm

https://finalt.qual.ebsp.msu.edu/kfs-qa/static/help/WordDocuments/gloss_status.htm

https://finalt.qual.ebsp.msu.edu/kfs-qa/static/help/WordDocuments/gloss_offset.htm

https://finalt.qual.ebsp.msu.edu/kfs-qa/static/help/WordDocuments/gloss_objectcode.htm


Page 23 of 26

8. KFS will not be sending KC the PO number. KC requests file from KFS when the batch processes to

populate into KC.

9. KC Object Codes 6493 SUBCONTRACT PAYMENTS <=$25,000 and 6494 SUBCONTRACT

PAYMENTS >$25,000.

3. Amendments (POA)

1. If a subaward is versioned in KC which results in a POA, an automatic notification will be sent to

Purchasing to amend the Purchase Order via an action list to Purchasing.

2. POA would be handled by the Purchasing buying staff.

POA will follow all standard routing nodes as appropriate.

Account – FO of the source accounting line – required for item tab changes

Contract Management – conditional review based on purchasing processor PO dollar limits

Commodity – conditional if a specific commodity code on any line items included with

Commodity Reviewer role

Award – conditional if any grant accounts used in Items with 2 levels of review configured

based upon dollar amount of transactions.

Budget – conditional – MSU not currently utilizing

Tax – conditional based on vendor SSN match to KFS employee or foreign vendors


KFS will add business rule validation on a POA to error upon submission if the account and object code

has changed from the most recent PO/POA version based upon percentages.

4. Each subaward should be its own PO for the duration of the award rather creating new individual PO’s

each year. POAs would be required by the purchasing processors each year to add an additional year one

at a time to an existing PO.

5. Pending payments may affect required POAs, however payment terms are “Net upon Receipt” so

overlapping should not be a significant factor. Vendors advised not to invoice more frequently than

monthly or less so overlapping POA issues from purchasing should be minimal.

6. CGA would give access permission for purchasing processors and/or contract managers to view KC

subaward documents which contain a note with the requirements for a POA in KFS.

4. Accounts Payable: Payment Types – PREQ/VCM

1. Payments/Vendor Credit Memo Processing Requirements

1. CGA to send approval email to AP email address:

2. Subject line must include the PO number and the vendor name

3. Body should include payment instructions on how to appropriately apply vendor invoice to PO line

items and accounting string

4. Subaward invoices need to include: PO #, amount, vendor and vendor invoice number

Email will include a hyperlink to KC document to obtain the associated invoice(s).

o An Accounts Payable auditor (Accounts Payable Processor) will manually enter invoices into KFS as a

PREQ along with the approval email from CGA and will download/review the invoice to attach to follow

standard KFS workflow.

o PREQ will auto-approve within 5 calendar days by pay date base on payment terms if not department

approved.

o Vendor credit memo situations are rare, however the following added for clarification.

Manual entry only by AP staff would be resource driven and drive more paper oriented options.

No approval required, however FO will receive an FYI upon submission

o KC requests the chart, account and object code cannot be changed in KFS. To accommodate this request,

KFS will add business rule validation on a PREQ to error upon submission if the account and object code

has changed from the most recent PO/POA version based upon amounts.

o Any cancellation of payments will require manual business process as PREQ can be cancelled at several

different steps. Manual notification required from AP to CGA. Any of the below cancellations:

AP may cancel a PREQ

FO may request cancel on a PREQ


Page 24 of 26

AP may cancel prior to formatting

AP may cancel within the PDP

AP may cancel a check after issued

o Standard payment term is “Net upon Receipt”.

o CGA performs the audit of subaward payments and obtains approval within KC.

o Vendors invoice no more than monthly or less so overlapping issues from purchasing/account payable

should be minimal.

o Payments – Checks/ACH/Wires/BOA – Concerns?

o CGA would give access permission for account payable processors and account payable managers to

view KC subaward documents to determine the requirements for a PREQ in KFS.

5. Vendors

o CGA to notify vendor reviewer group to create a new PO vendor request

o Approximately 800 total utilized vendors for DV subaward payments

o Current DV vendors to be used by KC will need to be migrated to PO vendor type. Manual process

to be determined.

o Vendor data to be populated and various decisions may require but not limited to:

1. Payment Terms / Shipping Payment Terms / Shipping Titles

2. Vendor PO / Remit Addresses

3. Addition of default commodity code

4. COI

5. BOA

o This is work required by KFS to make sure the interface REQs to satisfy APO business rules.

6. KFS Assumptions

All account numbers must be current and not expired/closed in KFS in order for the REQ to be created

from the nightly interface.

All accounting lines will default to 100%.

No vendor contracts are required for KC REQS.

REQ/POs would have a requisition source code specific to KC and a standard document description and

“Organization Document Number” to inform users of their origination.

Additional charges usage on REQ/PO are not applicable for KC REQS and will not be coded into the file.

If these become necessary, KFS may require an enhancement to the interface. Additional charges are:

Freight/Trade In/Full Order Discount/Miscellaneous.

Any capital asset REQS are available as a direct requisition source code (manual).

Manual requisitions would not be considered integrated within KC for reporting.

Currently a daily email (~ 6 AM) is delivered to a specific “interface group” stating “Requisition Source -

[REQ Source Code] - Batch process successful records” which includes the number of REQS/PO

created/processed and various other data requirements.

Currently a daily night batch process error and validation messages email (~ 8:30 PM) is delivered to a

specific “interface group” stating “Requisition Source - [REQ Source Code] - Batch process Error or

Validation Messages” which includes specific error and validations by specific Subaward Number to

explain why these transactions were not created in KFS. Sample error validations messages:

The following errors occurred during data acquire process :

1. Validation error while acquiring batch record for 1-C5057010: Vendor is required for a BPO.

2. Validation error while acquiring batch record for 136-C1060270: Invalid Batch - Batch is not

complete.

3. Validation error while acquiring batch record for 55-C1047890: Invalid Line Item.

4. Validation error while acquiring batch record for 8-C1039710: Two Headers with same document

number.

5. Document creation error while creating document for 197-Requisition C1039900: Vendor is

inactive.

6. Validation error while acquiring batch record for: Batch is empty.


Page 25 of 26

The following errors occurred while processing documents :

1. The following validations occurred while processing document for C1040000.

Account Number (Account) is a required field.

2. The following validations occurred while processing document for F114347.

Account MS-AT023465 is closed and cannot be used. Please select a different account.


The specified Vendor Payment Term does not exist.

The specified Vendor Shipping Payment Term does not exist.


Object Code (Object) is a required field.

5. The following errors occurred during document construction process :

Document creation error while creating document for 1-Requisition C1052800: Requisition

Document already exists.

Document creation error while creating document for 77-Requisition B6141239: Invalid user

- Not able to find the requestor in system.

Document creation error while creating document for 34-Requisition C1052280: Invalid

Vendor / Vendor Not available in system.

Daily reconciliation is required by source system (KC) for the files.

Items contained in the error email from KFS no REQ has been created. Items will need to be resolved

within KC and can be resubmitted in nightly batches.

PO, Purchase Order Amendment (POA) FINAL/Open, Purchase Order Void (POV) FINAL/Void, and

Purchase Order Close (POC) FINAL/Closed automatically send FYI to REQ initiator and FO of the

source account line (not delegates) unless configured to be ignored in KFS using an existing parameter.

No development required by KFS.

7. KFS Ledger Entries

o The financial system generates pending general ledger entries after the PO becomes FINAL/Open status.

These entries include the encumbrances for the transactions and the appropriate offsetting entries. After

the nightly batch jobs run to post the G/L entries, these pending entries no longer display on the PO.

o The financial system generates pending general ledger entries after a POV (Purchase Order Void)

becomes FINAL/Void status. These entries include the disencumbrances for the transactions and the

appropriate offsetting entries. After the nightly batch jobs run to post the G/L entries, these pending

entries no longer display on the POV. The POV reverses the encumbrance that were created by the PO.

o The financial system generates pending general ledger entries after a POC (Purchase Order Close)

becomes FINAL/Closed status. These entries disencumber any remaining encumbrances on a PO. After

the nightly batch jobs run to post the G/L entries, these pending entries no longer display on the POC.

The POC removes any remaining encumbrances on a PO.

o Unlike other KFS documents, pending G/L entries for Payment Request (PREQ) are created prior to final

approval. Upon document submission to workflow, disencumbrance entries and actual charges are

generated, written to the G/L pending entry table, and posted in the nightly G/L batch cycle. If fiscal

officers change accounting strings or redistribute the charges within their accounts, G/L entries are

generated to reverse the original actual entries and recreate them (encumbrances are not altered) and these

entries are written to the GL Pending table for posting in the next batch cycle.

8. KFS Roles

Role Role

Type

Name

Namespace Role Name Description

26 Campus KFS-PURAP -

Purchasing/Accounts

Payable

Purchasing

Processor

This role represents central or campus Purchasing

staff. They have additional permissions for and


Page 26 of 26

receive action requests for most Purchasing

document types.

25 Contract

Manager

KFS-PURAP -

Purchasing/Accounts

Payable

Contract

Manager

Contract Managers review and approve Purchase

Order documents. A Purchase Order is assigned to a

given Contract Manager for their review and

approval.

22 Default KFS-PURAP -

Purchasing/Accounts

Payable

Accounts

Payable

Processor

Accounts Payable users who can initiate Payment

Requests, Credit Memo, EIRT and IREQ documents.

They also have several permissions related to

processing these document types and receive

workflow action requests for them. The

REQ_SOURCE_CODES_EXEMPT_AP_ROUTING

system parameter exists and may change how this

routing occurs.

29 Default KFS-SYS -

Financial System

Accounts

Payable

Manager

Users with manager-level access to Accounts

Payable documents. This includes the ability to hold

or cancel (or remove those states) from Payment

Request and Credit Memo documents.

9. Account Number Corrections:

If an account number is wrong and there are no payments made, the PO will be voided in KFS and

Subaward inactivated in KC. A new subaward will then be created in KC and picked up by the

nightly batch process into KFS.

If payments have been processed with the wrong account, will need to request the PO be closed in

KFS and Subaward inactivated in KC. A new subaward will be created in KC and picked up by the

nightly batch process into KFS. GEC will need to be processed to move the payments to the correct

account in KFS.

During the Award closeout process in KC, CGA will need to close the PO if it not spent out.