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?
Med 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 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. How we handle carry forwards are 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.