Mod5 SLP: The changing interaction of finance, information, and technology - Coursework Example

Mod5 SLP: The changing interaction of finance, information, and technology Introduction: Over a period of time especially in the last few decades technology has seen an exponential leap, managing complexity, diversity and volume of information from varied sources. The global industry runs on technology, and finance as a separate domain is now automated using various software and tools. In today’s world information is of prime importance, and managing the same becomes crucial for the success of an organisation.

With the world moving ahead at such a spectacular speed, characterised with dynamism and constant change there is always a need to be able to manage this change and the information associated with it. The field of technology enables the efficient storage and utilisation of information. The domain of finance and financial services have immensely benefited from the introduction of softwares, tools and new methods and techniques of storing, accessing and utilising financial data. This inter-dependency and interaction of finance, information and technology is constantly changing with evolution of industry needs and with the need to be more efficient and user friendly.

Evaluation of the system: While creating e-Docs by entering information, certain fields have a restricted data set and thus have look up icons (magnifying glass). These look up icons take the user to another search page, the look up screen from where valid value of the field can be searched and entered. Main Menu: The Main Menu gives us a large variety of choices for the different applications in the Kuali Financial System (KFS). They are grouped under: Transactions, Administrative Transactions, Custom Doc Searches, Lookup and Maintenance, Reports and Year End Transactions.

Input Field with restrictions on input values: In cases where input fields can accept only certain value (i.e. numbers/codes within a particular range, or certain selected values) a look up icon (magnifying glass) is accompanied with the input box. This look up icon helps choose valid value for the field by redirecting to a lookup page and helping use pick a valid row from the results in the result table. Mandatory Fields: Fields with an asterisk indicate required fields. If you do happen to enter a duplicate value for the new Project Code, or if you enter an incorrect value in another field, the application will display an appropriate error message in the space above the top tab.

Tool tip: Every text label and its accompanying text box have a tool-tip associated with it. On the top right hand corner of every page the eDoc name is mentioned. Feature of Return Value: The ‘return-value’ link against records displayed under the search filter for a look up page of a particular field is used to enter information against the selected row into the main page where data is being entered. Asynchronous Data Validation System on GUI through input fields: Kuali financial System had a dynamic way of validating data entered in input fields for e.g.: Automatic routing of eDocs: Kuali automatically manages the routing of its eDocs for online approval.

Routing, with the built-in Kuali Enterprise Workflow (KEW), sends documents to prescribed users for specific actions, all in a sequence determined by the organization. Sequence of Steps: Scenario 3: Route for approval: Scenario 2 a preceding step to Scenario 3 has already been completed, wherein a transfer of funds has been initiated and has been submitted for routing. However the transaction is not complete until the document gets an approval from all approvers under the ‘Requested of’ Column of the ‘Pending Action Requests’ tab. a. Getting the approver id: We click on the approver’s name under the Requested of column, which opens up a pop-up browser page with the information on the approver (principal name: rorenfro) b.

Backdoor login as approver: We login as user with principal name: rorenfro. In the next step we click on the ‘Action List’ button, once logged in as rorenfro. On opening the Action List we are able to access all requests for approval. We click on the appropriate request by selecting the particular row. We are redirected to another pop up browser page where the requisition details can be viewed. Here we approve the request by clicking on the ‘request’ button. c. Searching our ‘Transfer of Funds’ document after approval: The same sets of steps need to be repeated for the second approver.

Once the request is approved by the second approver we go to the main menu, select transfer of funds and click on the button ‘doc search’. We type in user name: khuntley and search the transfer of funds document that we created in Scenario 2. Subsequent to approval of the document we search for our ‘transfer of funds’ document using the doc search button. We find our transfer of funds document with route Status: Final. This means that the document was completed by khuntley and approved by rorenfro and fjacobs.

Scenario 4: General Ledger Balance Inquiry a. Start in the main menu tab: We click on general ledger balance menu item under the Balance Inquiries Section of the Main Menu. We are redirected to the ‘General Ledger Balance Lookup’ page; b. View the details of a General Ledger entry Next we enter BL in the Chart Code field, "0142900" in the Account Number field and click the "All" radio button next to ‘Include Pending Ledger Entry’. Now we click "search" and the resulting General Ledger balances displays. c. Drill down to a monthly detail For example, click the amount shown for the June field in the third line.

A pop up browser page opens with the details of the transaction. In the next screen, you see the General Ledger Entry for June, Fiscal year "2011". We can open the eDoc that produced this General Ledger Entry by clicking on the Document Number "3823" in this case, takes us to a display of the full eDoc contents. It appears in the same format as it would in our Action List, but without the "approve" or "disapprove" buttons. If it has been fully approved, it will have an Error Correction button, which creates a non-editable eDoc in reverse and a Copy button which lets us create an eDoc using this one as a template. d. Conclusion: Once we have seen all you want, close this browser window with the Windows Close button at top right.

We have searched for a General Ledger Balance entry by Account, Chart, and Object, and then drilled down to view the contents of the eDoc that produced it. Scenario 5: Disbursement Voucher We now proceed to the Disbursement voucher eDoc scenario of the test drive. This document has numerous tabs for entering data and could be a seemingly complex document to work with. a. Start in the main menu tab We click on the "Disbursement Voucher" in the "Transactions" frame. b. Create a new Disbursement Voucher EDoc To start creating a DV we must first enter information regarding the payee.

First we enter an arbitrary description in the mandatory description field and click on the look-up icon next to the Payee Id field. We will be redirected to the Payee Lookup page. In the Payee Look up page we have to select a payment reason. In our case we can select: Moving Reimbursement (M) from the drop down menu as the payment reason. We enter Smith in the ‘last name’ field and click on search. Complete at least one of the other fields, wild cards are permitted in the name fields, but the complete number must be entered in the Tax number, Employee ID or Vendor Number field.

The payment reason code controls the type of entity that can be paid (vendor or employee) and various other business rules. We enter Smith in the last name field and click Search. The available payees are returned. Next we click "return value". Next we click Smith, Iggy and we will be returned to the Disbursement Voucher. Next, c. Complete the Payment Information tab Enter the payee address (normally this would come over from the person record, but this data is incomplete in the Test Drive) Enter a Check Amount.

Select P-Check/ACH as the Payment Method Complete the Check Stub Text field. d. Complete the Accounting Lines tab to split fund this transaction between two different accounts. We can enter the details for the accounting lines either manually or using the look up buttons for valid values. In our case we select chart as BL account number 1023200, object: 5070 and amount as 5000. We add another account line with account number as: 1023287 object as: 5070 and amount as 5000. e. Next we enter contact number under the contact information tab.

Finally we click on submit button. After clicking, if the document is successfully registered in the system we get a confirmation message on page refresh as ‘Document was successfully submitted. At the top of the DV document we can find a new link that allows the DV Doc to be printed. Now we expand the route Log tab by clicking on it. We click on the show button next to Pending Action Requests and Future Action Requests. Under the pending action requests, approval is required by RENFROW, ROBERTA G  (rorenfro). f. Now, the Route Log now indicates two pending Action Requests.

In the annotation, we see that they refer to the Accounts for the two Accounting Lines. For each of these two Fiscal Officers (IDS: rorenfro and rorenfro): We use the Backdoor Login to "impersonate" the Fiscal Officer. We go to the Action List Open the Disbursement Voucher eDoc and Approve. g. Back door approval: We impersonate as rorenfro and provide approval to the request by clicking on approve. Once the document is approved we search our DV eDoc again through main menu-disbursement voucher-doc search navigation path and with initiator name as khuntley.

On checking the route log we find an approval is required from LARGE, MYRA P  under the ‘Pending Approvals’ section. There are 3 Actions Taken: one for initiating the eDoc and two for approvals by each of the Fiscal Officers for the Accounts involved. Additionally, one of the Future action requests has moved to Pending Action Requests, waiting for one of the people who have the KFS-SYS Tax Manager role to approve. Several people have this role, but only one of them has to approve. Once one of them does, it will move to Actions Taken and the final approval will be pending.

Log in as mylarge (LARGE, MYRA P ) one of the Tax Managers and approve. After approval we search our DV doc and check the Route Log tab’s Pending Actions Section. We can see there are no Pending Actions or Future Action Requests. The Action Taken Section has three entries one for the initiation of the BV doc by our login (khuntley), one for the approval by rorenfro(RENFROW, ROBERTA G  ) and the third one for the final approval given by mylarge (LARGE, MYRA P ). We do one final search for the DV doc and notice that the status of the document is FINAL and Route Log showing that all requests have been completed.

Scenario 6: Purchase Requisition a. Start a new Purchase Requisition – Complete the Delivery tab We select ‘Requisition’ under the ‘Purchasing/Accounts Payable’ section under the ‘Transactions’ frame. Some descriptive text regarding the document is entered in the Description field on the Document Overview tab. We fill out the Final Delivery Section under the Delivery tab. Use the Look icon to complete the Building field and enter a value in the Room field, free form or use the Lookup to find a valid value. b. Add some Items to the Requisition: Here we need to enter ‘Item Type’ as Quantity, Quantity, (UOM) Unit of Measure, Commodity Code, Description and Unit Cost. c. Complete, Calculate and Submit the Requisition: We add the requestor's phone number and email (if this information was completed in the Person data it would auto-fill.) Additional Details are already pre-populated, except for the contact number which should be in format (###-###-####) Next, we click ‘Calculate’.

Click ‘Submit’. d. On submitting we get a message: Document was successfully submitted. Review the Route Log e. Back door approval: Open the Route Log tab and click "show" next to Future Action Requests. We see under Pending Request Section, under Requested of column khuntley. For the first approval we don’t need back door entry as we are currently logged in as default user khuntley. We simply click on Action List button and open the relevant item and click on approve button. Scenario 7: Contracts & Grants Proposal a.

From the "Main Menu" tab, select "Proposal" in the "Look up and Maintenance" section. b. As this is a maintenance transaction, the next screen is a Proposal Lookup screen. We want to create a new Proposal. Click the "create new" button at screen top right. We enter a description and explanation in the Proposal Document. c. Proposal number is pre-populated. Agency number: 52590 Agency Name: Administration for Children and Families. Project Title: Demo Project. Start Date 06/05/2011, End Date 06/06/2011. d. Click on add button, click on submit button.

Document was successfully submitted. Is displayed. e. The Status of this eDoc is PROCESSED. This is similar to FINAL in that this Proposal is in the database and ready for use. However, because there are two Pending Action Requests for Acknowledgement, this eDoc will not go to FINAL until all Acknowledgements are made. f. Back door approval: You can acknowledge a document the same that you approve, by using the Back Door to log in as the Requested Of users and opening the Proposal from their Action List.

We click on ‘Acknowledge’ instead of ‘Approve’. Additionally, these acknowledgements were set using Organization Review as indicated in the Annotation section. Any Proposal that contains an Organization that rolls up to Chart BL – Organization BL will trigger this routing rule. Backdoor approval is done by jnbybee (BYBEE, JARED N). Conclusion: The Kuali Financial System has a robust graphical user interface and data storing/ retrieving mechanism. Compared to other financial systems the only draw-back is the time it takes for the pages and various in built components to load in the browser.

The driver’s manual is an additional resource that helps user and beginners to get accustomed to the usage and process of KFS. Questions regarding financial systems such as KFS: Usages of such financial systems do come with certain questions like: Migration of data into other 3rd party systems if there is a business need or an overhaul of business infrastructure. How efficient will KFS be and whether there are systems in place to allow smooth migration of data? How efficient is the database in storing large amount of data and whether it is accompanied with content managing software to store backups of the same?

These are certain basic questions that need to be considered on a long term basis in adopting KFS as the solution for an organisation’s financial management processes. References: 1. Kuali Financial System, Driver’s Manual 4.1 (22nd May, 2011). Retrieved from: https://wiki.kuali.org/display/KULDOC/Drivers+Manual+4.1