Functional Description

The University of Connecticut’s (UConn’s) Facilities Operations and Building Services (FOBS) organization selected AiM, an Integrated Workplace Management Solution (IWMS) provided by AssetWorks, as the software to manage Operations and Maintenance (O&M). In addition to utilizing the AiM software, UConn also decided to execute the hosted solution offered out of their Wayne, PA data center. In order to accurately track costs, perform maintenance, route work, etc.

All purchase requisitions will initiate in AiM Work Orders and be reviewed and approved by supervisors.  Once approved in AiM the Purchase request will be sent to KFS where it will become a purchase requisition.  Currently, the System of Record (SOR) for UConn’s Purchase Requisitions is Kuali Financial System.

Impact

This function will allow purchase requests to be created and stored in AiM where they are associated to specific work orders for functional tracking and supervisor approval tracking. The data will be moved in near real-time to KFS. This makes sure the financial control process is followed properly, and all financial approval auditing is kept in KFS and can be traced back to the work done.

User Story

Pasted from other SOP so information is not lost

KFS Requisition Doc Statuses can be used to drive the interactions between the two systems:

When a Requisition is created in HuskyBuy, the transaction is moved to KFS once the Purchase button is clicked.
 This transitions the user into KFS where they fill in the description, account number and object code.
 Clicking the Calculate button followed by the Submit button puts the Requisition Doc Status into "IN PROCESS" status.

This requisition will show on the Content Reviewer (Supervisor)'s Action List.
 If the Requisition completes the approval workflow in KFS and gets to the Requisition Doc Statuses = "CLOSED", the Purchase Request information should now be pushed to AiM

As-Is.  If this is cancelled or disapproved, the individual who placed the order will get an FYI through KFS as notification.

 

(THIS IS ONLY THE PHASE 1 DESIGN.  IN FUTURE STATE SCIQUEST/JAGGER WILL PUSH THE REQUEST TO AiM WHICH WILL CREATE THE REQUISITION IN KFS AFTER SUPERVISOR APPROVAL IN AIM)

 

*****END OF PASTE FROM OTHER SOP******

System of Record (SoR)

There are many ways an AiM Purchase request can be generated but regardless of initiation method, once a supervisor approves the request a corresponding Purchase Requisition needs to be created in KFS. An example of an AiM Purchase Request that has been Approved and needs the integration to send it to KFS is shown here:

A requisition that has successfully been sent to KFS should be ENROUTE

Integration Point(s) for SoR Data

When the Purchase Request in AiM reaches the APPROVED status, it is then sent to KFS to create a requisition

If at any point in the Kuali workflow the Requisition is cancelled then KFS notifies AiM and the status gets changed to DISAPROVED

If in the Kuali workflow teh Requisition is approved and a corresponding PO is created, then KFS notifies Aim and the status gets changed to CLOSED and the PO Integration is invoked

KFS Representation of Data

Assumptions

Roles

Role Name	Description	Example from current team(s)
KFS Functional Lead	Individual(s) responsible for data correctness of  KFS Purchase Requisitions	Brett Paulson
KFS Business Analyst	Individual(s) responsible for data correctness of  KFS Purchase Requisitions	Bruce Lindeman
KFS Technical Lead	Individual(s) responsible for technical execution of KFS	Rich Ritchie
Assistant Director of Finance and Budget Facilities Operations & Building Services	Individual(s) responsible for overseeing the financial responsibilities of FOBS	Tammie C
Application Administrator	Individual(s) responsible for overseeing the proper operation of AiM	Cheli D
Integration Developer	Individual(s) responsible for implementing and maintaining the integration	Ying Hu

Data Mapping

Account Level Mapping (update/insert)

KFS Table	KFS Field	UCONN API Method	XML	AiM Web Service	AiM Web Service Tag	AiM Table	AiM Field
						ae_i_pre_e
						ae_i_pre_e
						ae_i_pre_e
						ae_i_pre_e
						ae_i_pre_d	pr_item

Object Code Level Value Mappings

AiM Account Status Values
Status	Description	Status Flag

 

AiM Subcode Types
Type	Description

Documents (Transactional, Maintenance, Search/Inquiry Screens)

AiM Web Service to find a subcode	Sample result

To update an account call

AiM Web Service to Update a Subcode	Sample result

Requirements

Frequency

The Object Code Integration will run once daily. ??? am is the desired time

Soft Errors/Warnings/Notifications and reporting

Certain conditions will be defined that will allow for the insertion, update or inactivation of properties and/or their attributes in AiM, but they will generate notification reports

Condition	Action to be performed

Hard Errors and reporting

Condition	Action to be performed

Pre-defined Types and Values

Design Options

Java Broker