Frequently Asked Questions (FAQ) from technical staff to help understand how to migrate applications to Kuali and related items

1) How should recharges work within Kuali? What is the KFS equivalent of "sub 09" transaction on specific account/fund today?

You will be feeding recharge transactions, we provided the Origin Code (source system code), Doc Type (equivalent to type entry) for each feeder system in the orientation meeting. The account fund will be crosswalked using our crosswalk table. Sub 09 object codes will be crosswalked on the object code crosswalk. If the users prefer to post on-line, you can use IB and SB documents.

2) How do we determine whether the KFS equivalent of "fund" is rechargeable?

If the user is using the IB document on-line, this is enforced by FUND_GROUPS (grouping of sub-funds) or SUB_FUND_GROUPS (grouping of funds) parameter and we will set up the values. However, this business rule is enforced only on the document. Feeder system will have to enforce the same business rule -- validate against SUB_FUND_GROUP or FUND_GROUP.

3) How do we determine the "overhead" rate and whether there are any restrictions on how money's can be spent on a KFS account or "fund" equivalent?

Subs will be equivalent to the Object Code Consolidation Code so you will be able to identify object codes for Sub 09. The Internal Billing document (equivalent of our type entry 53) has several parameters to
restrict the use of accounts and object codes. You can restrict them by Fund Group, Sub-Fund, Object Type, Object Level, and Object Sub-Type. We have not met with Financial Transactions team to determine which parameter(s) we are going to use to restrict the use of accounting lines.

KFS will determine and calculate any necessary overhead rate. Overhead rates are set up in using the Overhead Rate document and then assigned to Object Codes and Accounts.

4) Some of our recharge programs distinguish between the state fund 19900 and the UCIMC state fund. How should we distinguish UCI from UCIMC state funds going forward?

The Medical Center will have its own charts and their funds are easily identified based on the chart code.

5) How do we detect contract and grants funds? How do we determine whether the KFS equivalent of "fund" is valid if we don't use the entire FAU DWH API call? Is there an equivalent of fund end dates?

KFS distinguishes C&G accounts by Fund Group or Sub-Fund Group (campus choice). We will be able to know fund/sub-fund based on the account number passed from the external system. We have an account expiration date and continuation account feature in KFS for C&G.

6) The Reference field is parsed by many applications for more information. For example, it stores part of the Purchase Order number or could store a student id. How is the Reference field in Kuali going to translate the legacy Reference?

Org Document number field and Org Ref ID fields are for departments to use. KFS Purchase Order number is automatically stored in FDOC_REF_NBR field across REQS (Requisition), PO (PO), CM (Vendor Credit Memo), and PREQ (payment request) transactions.

7) How is the Partial/Full flag on an encumbrance handled in Kuali?

We do not have Partial or Full flag in the encumbrance transactions themselves. You will just pass the amount you are encumbering or disencumbering and the Open Encumbrance Table will track the open and closed amount. In the PURAP Invoice Document, however, you can designate the FINAL payment, that will disencumber the remaining encumbrance.

8) How is KFS different in its handling fiscal year end closing? How are carry forwards handled? How do you run the trial balances of the accounting processes?

We don't anticipate any significant difference from the way we currently handle fiscal year end closing, but more testing is needed. Handling of carry forwards is yet to be determined.

9) Who will be the system of record on the UCOP funds for PBS/FMW reporting?

UCOP Funds will be managed within KFS and copied to FMW. The auditors look to KFS for this information.

10) What are the data synchronization interfaces between FMW and Kuali FS supposed to look like?

We don't know anything about FMW but I'd imagine that it will be just like any other feeder system, where FMW will be feeding base or revised budget. You will probably compare the balance table balances for BB (Base Budget) or CB (Current Balance) balance type on a regular basis.

11) Since the gl would have all transactions would the customer be able to get their invoices directly from kuali? That way we can eliminate our
whole invoice generation processes and possibly the Financial Report. We have invoice generation processes for charges coming from FACSERV, utilities and Fleet Billing. If kuali has a centralized piece to generate/view invoices that would be a big help.

We need to discuss this further. Are you wanting to just retrieve GL entries generated off invoices (not the invoice information itself)? If so, the answer is yes. However, any detailed invoice information will not be present, unless you generate your own invoice within KFS.

When you say "Invoice," that is invoices for recharges, right? (In KFS accounts receivables, invoices are usually generated for external customers, not for recharge purposes). Lets talk some more about your needs. I feel that UCI definition of invoice is rather different from the norma invoices. If invoices are something you are just explaining the recharge details, then you can just pass that information through the <detail> element of XML.

We are working on a new screen which will show this detail for our users. Systems could feed the detail to KFS and KFS will allow users to view the details in the system. This could eliminate feeder systems "invoice" report generation.

12. Would our feed be putting all the entries in the Kuali GL Pending entries area (GLPE)? Could we potentially post all our transactions
every night into the General Ledger Pending Entries table?

The feed will not hit Pending Entries. After the entries are scrubbed by Scrubber, they are posted to the Entries Table directly. Pending entries are only for transactions entered on-line.

13. Would Kuali have its own account validation program to check the validity of the accounts? Could we rely on that and hence get rid of our
own account validation java program? Could we make a call to that central program to mark our records with an exception if the account is
not valid?

KFS has its web services to perform account validation. Making web services to perform accounting line validation is probably a good idea. We'll need to survey the feeder folks to determine which webservice protocols they're able to use and the expected volumne of transactions. Given the complexity of accounting-line validation, this is probably something we'll want to release during our roll-out.

14) It appears from the documentation that the scrubber posts the valid transactions from the pending area to the GL and the pending area is
cleared. The error transactions are moved into a separate file ("demerge"). Need more information on this step. Do any notifications go
out informing us of failed transactions? Am I correct in understanding that we would then fix the offending transactions in the external system
and then send them again via the feeder system to this GLPE area? Since transactions will be every day in the GL customers should not need our
Financial Report and could get that information from Kuali.

Again, a direct feed does not use the Pending Table (pending is only for on-line transactions). The scrubber posts output of Collector or Enterprise job.
Any error transactions are moved to an error file where the accounting staff will make corrections and push them through – we have a UI for it (GLCP document).The access to this screen is limited to the super user in the accounting area. They will work the people in the functional areas when correcting the errors the same as they do now. The error file is one single file which will contain feeds from various feeder systems.

15) Would we have the ability to define fields like a job number and/or work order in the document and then be able to search by them in the GL?
Since business rules are based on Document Type, how easy is it to make a custom Document Type? What does it take to create/modify a business
rule? Can we set up validation for any field sent in a transaction?

Yes, you can use Org Doc Number or Org Ref ID for your use and they are searchable. To create a new Doc Type, we will first need to define the Doc Type in our Doc Type table and then we will have to modify our scrubber code, which is not trivial. Modifying scrubber will be our last resort and we do not normally touch that code. Scrubber already has various validations so we should sit down and discuss what else you are wanting to see. Typically, we expect that the feeder files to be already validated within the source system. Business rules are normally enforced in the KFS on-line document.

16) The handout indicates that there is an organizational hierarchy defined within Kuali. Is there a link between an account and a
department? So if we send to the GL just the account information would Kuali be able to generate a report to search by an organization code for
all accounts and transactions for that organization?

Yes, department (organization code) is an attribute of an account. Yes, Organization Code is not a searchable field on the transaction but
I would think that it can be added easily.

17) Billing corrections could potentially be performed by the user in Kuali itself if Kuali can report by custom fields like job number. That
would make Kuali the most accurate repository of financial costs pertaining to a job apart from its ability to report by account
information.

KFS has GEC (General Error Correction Document) or error correction feature (if you have transacted on KFS, you can click a button to generate reversing entries). However for a better audit trail it is best to correct errors in the feeder system.

18) At a future date what do you think is the possibility of using web services to do real time upload of charges from feeder systems?

We could allow them to upload collector files via a SOAP web service at any time the system is up. However, they should not expect the ledger to be updated in real time, as I believe we're still planning on having a nightly accounting cycle.

19) We would like to know what is the plan for data and reporting at the cut-off date? Does it mean all charges up till June 30th, 2013 on jobs still open as of the cut-off date would have to bill with the old account-fund in the old system and then the fau on all such jobs would have to be updated in the feeder systems so that the new charges would bill with the new fau in the kuali system? Am I correct in assuming then that our data will be split in two systems or is there any plan to migrate the old data into Kuali? What are the recommendations of the Kuali team relating to the two different sets of the financial data? It is critical for us to get a better understanding of this as it will determine many decisions we will have to make.

Just a little bit of history..In 2007 we closed as many jobs as we could and created an Invoice Report for the customers to look at data on jobs closed before the migration. Then we migrated the open jobs into the new system. At 2013 new fiscal year we will again try to close as many jobs as possible but there will be still many jobs which will remain open through the transition.

We have no plans to bring forward transactions from the period prior to the year-end close. We will only bring forward account balances. The old transactions will stay behind on the data warehouse. You are correct in saying that you will post transactions in FS in the old FAU up until the cutoff date and the after the cutoff date, you will be posting transactions using KFS accounting line.

Two sets of data must be accessible from data warehouse -- Valerie is looking into how this should be accomplished. I have seen it in two different ways; some institutions walked the data back from KFS to the old accounting system Chart of Accounts for multi-year comparative reports; the other have done it reversed. Since KFS is a relational system, the challenge for us to walk the old account to the new will be the necessity to create old accounts in KFS, which we do not plan to do (too much overhead). I would like to have exact scenarios so we can brainstorm the best way for UCI.

20) How do Fund codes 19900,19933[,,] series map to KFS? Would like to know how the FS Account, FS Fund, FS Accountfund and FS hierarchy tables map to KFS. Also, need to map relevant portions of the FS0Range file to KFS attributes or help us understand how to do the processing.

21) Can one KFS account belong to more than one school? Within the same school, can one KFS account belong to different level of organization hierarchy? What is the relationship between KFS organization hierarchy and account?

One kfs account is only associated with one organization code hence to one level only. You can bring up reports in cognos for all the accounts associated under one organization hierarchy. The general relationship is many accounts to one org.

22) Object type does not need to be entered for online journal because object code itself can tell the system what the object type should be. Please confirm if your understanding is the same.

Correct!

23)Please help me understand how we differentiate fee revenue for OP from local fee revenue without fund #? My guess is we will have different account and different object code in KFS world for it.

Each KFS account contains Sub-Fund group code as its attribute, sub-fund group code maps to UCOP's Fund group code, which specifies the source of funding. In KFS you will have different accounts that are in turn map to its corresponding sub-fund group code, see http://www.ucop.edu/irc/campus_specs/caf/appendixefunds.pdf page 3

24. Do you know the difference between award end date and the project end date? The current UCI PI report collects both dates. I guess they are different. Do you know if KFS will have different end dates for awards and projects?

The award end date, specifies when the Award will be ending, in KFS it will be Stop Date . Project end date stops all the transaction from going thru, acts like the Account Expiration date.

Browser not supported