This page features General, CoA, and Technical frequently asked questions related to the Ascend Project.
To search through all Ascend FAQs, please open this PDF.
- Ascend Project General FAQs
About the Project
Why are we replacing our financial systems?
UCLA’s current administrative financial systems were developed in the 1980s on a mainframe platform. These systems have struggled to keep up with the growing needs of the University’s complex business landscape and technical infrastructure. In order to achieve increased efficiencies, streamlined business processes, effective reporting, and to meet regulatory requirements, UCLA has decided to implement the Oracle Cloud suite of enterprise applications. In the decades since adopting its mainframe system, UCLA has experienced remarkable growth and the University will continue to evolve. The flexibility and adaptability of the new system will allow staff to focus on UCLA's core mission, empowered by up-to-the-minute data and robust reporting capabilities. The adoption of the new system will ensure that the culture of innovation, efficiency, and data-driven decisions continues. For more information, please see Mission, Goals, and Guiding Principles.
What is the Oracle Applications Cloud?
Oracle Applications Cloud is a cloud-based Enterprise Resource Planning (ERP) system, which supports finance, financial project management, procurement, budget, and post-award research administration activities, among others. It is a modern, agile suite of integrated applications, which undergo periodic updates automatically to improve functionality. It extends desktop applications to smartphones and tablets.
I heard there are consultants working on Ascend. Who are they and what are they doing?
UCLA has partnered with Huron Consulting Group to assist with the implementation of the Oracle Applications Cloud. They are helping to provide functional and technical expertise for the implementation and integration of the new system, as well as supporting business process mapping and optimization, project management, change management, and training. UCLA is responsible for the overall leadership of the Ascend project and for staffing each work stream with subject-matter experts to advise the configuration of the cloud and to design the future-state business processes.
Timeline & Scope
What is the schedule for the Oracle Applications Cloud implementation?
High-level project dates are included below, and a more detailed timeline can be found here.
April 2018 – July 2018
July 2018 – February 2019
February 2019 – January 2020
January 2020 – January 2021
January 2021 – July 2021
July 2021 – October 2021
Why is go-live scheduled for UCLA’s year-end fiscal close in July 2021?
There are pros and cons to going live at fiscal close. Fiscal year-end is generally a busy time and adding a system cutover can add to the workload. However, there are major benefits from a go-live at fiscal close.
The main benefit of a fiscal year-end go-live is that all of the transactions and reporting for the next fiscal year will be in one system, simplifying FY2021 reporting.
From an accounting and budgeting perspective, it makes sense to close a fiscal year on the current mainframe system and start new year activities in the new Oracle Cloud, as opposed to converting mid-fiscal year and consequently having some activity on the old system and some on the new system.
Cutover at a point mid-year is possible; however, it requires additional planning related to conversion of balances, reconciliations, and financial reporting. Universities have successfully gone live with large Financial ERP Systems at their fiscal close and at mid-year, so both options are feasible.
What is in scope for the Ascend project go-live set for July 2021?
UCLA will go live with a number of Oracle modules, which will broadly impact areas including, but not limited to Procurement, Accounts Payable, Expenses/Employee Reimbursements, Grants, Cash Management, Accounts Receivable, Equipment Assets, General Ledger, Internal Billing/Recharges, Planning & Budgeting, BI & Reporting, Gifts & Endowments, Budgeting, and Capital Projects.
How and when will I know if I am likely to be impacted by this change?
All users will eventually benefit from increased efficiencies and better access to data; the core users who are likely to be most impacted by the implementation are those who work for Corporate Financial Services, Office of Research Administration, Academic Planning & Budgeting, External Affairs, and IT Services. The project team is actively engaged with these areas to ensure that the new system will be designed and configured to best support their business processes. Additionally, the project team is engaging with Business Partner Experts, who are departmental leaders actively participating in the business process re-design efforts and focused on understanding local change impacts. Experts in their respective areas, they help to communicate business needs and identify potential points of concern to the project team, while taking an active role in designing the new system and participating in testing. Go to Business Partner Experts to see the expert for your area.
When will the larger UCLA population get hands-on access to explore the new financial system?
As of November 2018, the project team is at the conclusion of the first round of system testing in CRP1. System design becomes increasingly refined as we continue through the successive test cycles to confirm our configurations. As those refinements occur, we will offer opportunities to the broader UCLA community to get “hands-on-keyboard” experience through a variety of methods. This will include specifically-designed outreach sessions, Ascend open labs to be held throughout campus, and other similar events. While these dates have not been specifically determined, we will distribute this information through our website, newsletter, Change Network and the Business Partner Experts once dates are confirmed.
Future State System & Data
Which existing systems are going away, and when will this happen?
The project team is actively compiling and assessing all systems within the UCLA ecosystem. Some of those systems will no longer be needed to support UCLA’s financial business processes after the implementation of Oracle Cloud. Conversely, some of those systems will still be required for other functions that the Ascend Financial System cannot accommodate. For instance:
BruinBuy will be replaced in its entirety by the P2P functionality within Oracle Cloud.
Non-Student AR activity will be completed in Oracle Cloud, however the present-day BAR system will continue to be used for student financial AR activities.
The complete list of systems which will be made redundant by the Ascend project is still in progress. Currently, the project team is working with departments and system owners to determine which systems will be kept and retrofitted and which will not be retained.
At this point in time, we have compiled the following crosswalk of present-day to future-state systems:
Corporate Financial System
Same thing as General Ledger/ Financial Journal / TOF / Recharge / Encumbrance Voucher / Memo-Lien Voucher (replaced by Oracle GL)
Pre-trip Authorization System
Direct Bill Payment System
Will continue to use BAR for Student Financial AR
Asset Management System (Equipment Management)
QDB – Financials
Oracle data warehouse and application reporting tools
May continue to use QDB for historical data access
APB Hyperion Planning and Budgeting
Permanent Budget / Budget Error Correction – FS Permanent Budget System
W-9 Upload System
Oracle Supplier Portal
Procurement Card Receipt Management
UCLA Vendor Self-Service
Oracle Supplier Portal
EFM Only- Central Users (For RAPID, FRS, and Web F&A)
Will we have all our current data in the new system when we go live?
The data in the new financial system will be determined by our Conversion and Cutover strategy. In summary, all current financial data sources will undergo a thorough review and a data clean-up effort will occur to ensure the new system is populated with relevant data. Following the clean-up process, the Conversion team will process all current activity and balances into the Oracle Cloud Financial System. Historical data will be available when Oracle Cloud goes live, but its location is still to be determined as a part of the data warehouse scope. More information related to the scope of data to be converted will be shared as the strategy and plans are finalized in 2019.
What is the cutover strategy?
Cutover will occur in mid-2020, but the specific dates and details have not yet been determined. System design and retrofitting analyses are still in progress, and will contribute to the detailed cutover plan that the project team will develop. We will share more information on the Cutover strategy once it becomes available in early 2020.
Training & Testing
What are the plans for training?
Training starts by providing you relevant and timely information throughout the lifecycle of the project. We aim to provide UCLA with robust communication and change management activities in order to promote user confidence and adoption well before the new Ascend Financial System goes-live in July 2021.
As we near the go-live date, we will roll out job aids / quick reference guides, online training sessions, and opportunities to drop in for an Open Lab to experience the system first-hand.
For now, stay informed about the project by signing up for the Ascend Newsletter, visiting the website often, and watching for new videos and Town Hall events near you. Another way to get timely and relevant information is by signing up to be a part of the Ascend Change Community. As a member, you will receive topical webinars (coming early 2019). We also invite you to email your questions to us at [email protected].
How is the new system being tested?
There are five rounds of formal, iterative testing scheduled. The first three rounds are Conference Room Pilot (CRP) testing sessions, which validate configuration and begin to validate converted data. The next round of testing, System Integration Testing (SIT), is designed to evaluate end-to-end scenarios and external integrations within the context of UCLA’s future business operations. Finally, User Acceptance Testing (UAT) occurs as the last formal testing cycle. UAT is designed to expand tester population and confirm all system setups in relation to future state business processes. The iterative testing cycles increase in scope and complexity as the project continues. For more information about testing dates, see the Ascend Project Timeline.
Who is participating in testing?
Testing is principally conducted by the core project teams, including the leads and their team members. As we move forward into the next four iterative testing cycles, the testing participation will expand to include relevant stakeholder groups. During User Acceptance Testing, opportunities will be made available to the Change Network to get a better understanding of what the future state system will look and feel like, which includes participation in these future testing cycles.
I am a MEDNET user and I cannot access Ascend content on Box.
- Accounts Receivables
What receivables are moving into the Oracle AR subledger?
Non-student Billing and Accounts Receivables (BAR) will move out of BAR and into the Oracle AR subledger; other types of AR are not planned to be included in the subledger at go-live, though it may be possible to incorporate other AR activity into the subledger at a future date after go-live.
How is Billing and Accounts Receivables (BAR) impacted by the Ascend project?
BAR will remain as UCLA’s student billing system; student receivables will remain in BAR. As part of the Ascend implementation, BAR is retrofitting to process billing transactions using the new Chart of Accounts so that the related accounting entries can interface into Oracle Cloud. Non-student BAR accounts will be transitioned out of BAR and into the Oracle AR subledger.
My department has receivables we would like to have hosted in the Oracle AR subledger. What is the process of doing this?
At this time, a limited volume of receivables will move into the Oracle AR subledger for go-live in July 2021. If you are interested in hosting your department’s receivables in the Oracle AR subledger after go-live, please submit your inquiry to [email protected] for future consideration.
My department has its own receivables system. Will its AR need to be hosted in the Oracle AR subledger?
No, it will not. Only non-student BAR receivables are moving into the Oracle AR subledger for go-live in July 2021. All other receivable systems on campus will remain after go-live but may need to be retrofitted to send and/or receive financial data from Oracle Cloud.
Is new functionality available for recurring payment process of AR activity?
Not at this time, but we are working with CASHNet on future enhancements.
How will asset custodians access information in the future?
All asset custodians will have access to the Data Warehouse, in which all the details about each custodian's assets will be available.
Will the physical inventory process (Annual Equipment Certification) change with the new Oracle Cloud system?
There will still be a physical inventory in the future, and it will involve the asset custodian running a report to review current asset information, then communicating any changes and certifications to the PP&E team. The custodian will not update the data directly in Oracle Cloud. However, the process mechanics are still being determined.
Will all assets in AMS be converted to the new Oracle Cloud system?
All active assets as of June 30th, 2021, will be converted to the new Oracle Cloud system. Disposed assets will not be converted in the new system, but the historical financial information will be available in a separate database.
- Cash Management
How is CASHNet impacted by the Ascend project?
CASHNet will remain as UCLA’s main cashiering system and will be retrofitted to process payments using the new Chart of Accounts instead of the present-day FAU.
Is the “Daily Deposit Report” changing in the future?
Yes. We are in the process of designing and testing the report. More information will be available in upcoming Business Process Analysis (BPA) sessions.
- Capital Projects
When will a department need to create a capital project in the Project Portfolio Management subledger of Oracle Cloud?
A Capital Project (CP) is defined by UCOP as any body of work that
1. is a collection of costs,
2. exceeds a total cost of $35,000, and
3. adds to the useful life of an existing asset by a specified number of years, or creates a new asset.
Additional details, including more information about the years criterion in item 3, are available in this Capital Projects Checklist. Any body of work meeting these three criteria should be recorded in the Project Portfolio Management (PPM) subledger in Oracle Cloud.
Will departments be expected to handle their own capitalizations for projects?
No. Capitalization will happen centrally, as is largely the case today. Creating projects in advance of spending and holding expenses in a project will assist the Property Plant and Equipment team in their capitalization efforts once the project is complete.
How can I track all expenses related to a project? Are there any tools available to compare expenses to my budget?
All expenses will natively flow to the Project Costs area in Oracle Cloud. In this area, users can view all costs associated with a given project. Additionally, we are working on reports to assist users in tracking budgets versus actuals and other key components related to their projects.
Are capital projects in Oracle Cloud tied to the fiscal year calendar in any way?
Not directly, although projects can certainly cross fiscal years. That said, there will be an effort at year-end to clean up any projects that should be capitalized at that time.
How will creating and charging expenses to projects change my local financial statements?
Expenditures that are deemed capitalizable at the time they are incurred will route to a Construction-in-Progress account, which is classified as an asset account, not an expense account. This is a change to today's model in which expenditures are classified as an expense up-front and moved to an asset account at the time of capitalization. When the project is capitalized, the balance will shift from a Construction-in-Progress asset account to another asset account, like Buildings.
Will we be able to proxy for other users in Concur?
Yes. Depending on access granted, users can be added as a "delegate" for others. Being a delegate for another person will allow you to create expense reports on that person's behalf.
- General Accounting
Will I have access to create my own Chart of Accounts (CoA) values?
The process for managing new Chart of Accounts (CoA) value requests is actively being designed. It will not be possible for users to create new CoA values on their own, but there will be a request process routing to General Accounting. General Accounting will be responsible for establishing new CoA values. Additional details on the request process will be shared as the process design matures.
What happens if a cross-school journal is submitted and only one school's lines are approved? Does this journal get submitted?
All schools affected by the transaction must approve their respective lines in order for the journal to post.
- Internal Billing
How are the Interdepartmental Recharge and Recharge Order Request (ROR) systems changing?
Ascend is implementing a full procure-to-pay module for internal recharges. The Recharge Order Request (ROR) system will be replaced by Oracle Procurement, and Interdepartmental Recharges will be replaced by Payables zero-dollar invoices.
What benefits does the new system provide for the recharging process?
Using the Procurement module to replace ROR means UCLA will have a catalog shopping experience where Receiver (customer) Units can select from a variety of goods/services with pre-defined rates and an associated Service Unit. This increases compliance with F&A (Facilities and Administrative) rate calculations and provides the campus more transparency over goods/services available for purchase.
Using the Payables module to replace the Interdepartmental Recharges System will enable recharge processors to create a direct link between the purchase and the invoice; Purchase Order numbers from the Procurement module will be added to the zero-dollar invoice, which increases communication and transparency between the Service Unit and Receiver Unit.
How are Service Unit and Receiver (Customer) Unit responsibilities changing?
The majority of recharge responsibilities will be unchanged; Receiver Units will still be responsible for requesting goods/services, and Service Units will still be responsible for creating recharge (zero-dollar invoice) transactions.
Approval workflow will be the largest change in responsibility. Please see the 'Workflow' Q&As for more information.
What is changing in terms of intercampus transactions?
Intercampus recharges will be created in Oracle Cloud as zero-dollar invoices. Service Units providing services to other campuses will still be responsible for creating the recharge (now in Oracle), and all remaining steps to reflect that charge on the receiving university's ledger will happen as it does today.
Receiving Units ordering services from another campus will be required to send their CoA/POETAF for the expense to the campus they're ordering from. Those requests will be processed, sent to UCLA General Accounting, then, UCLA General Accounting will create the zero-dollar invoice for the UCLA Receiving (customer) Unit to approve.
Will I be able to load recharge transactions in bulk?
Yes. Ascend is developing a platform similar to today's bulk upload tool that allows you to validate recharges before they're submitted.
When will Central Purchasing become involved in a requisition?
The intent is to ensure that Campus Purchasing is able to identify strategic sourcing opportunities and confirm that proper purchasing controls are in place. This means Campus Purchasing will be involved in a subset of purchasing activity.
All departmental purchases will begin with a requisition. Requisitions that come from the catalog and are below a dollar threshold will automatically become a Purchase Order without Campus Purchasing's involvement. Note that the dollar threshold is still being determined and will apply universally across the University. Additionally, requisitions that are related to a blanket agreement will also automatically become a Purchase Order without Campus Purchasing's involvement.
We submit invoices to AP multiple times when an invoice hasn't been paid. In the future, will we know when AP has seen our invoices?
A goal of the new system is to increase speed and efficiency of invoice processing and to avoid credit holds. AP will have easy access to information about aging, overdue, and unpaid invoices.
In the future state, whenever possible, invoices should be electronically submitted directly from the supplier to AP. The electronic submission will make the process far more transparent for all parties. The electronic invoice will then match against a purchase order within Oracle Cloud, at which point the individual who created the original requisition will be able to see the system invoice and, where applicable, a PDF of the invoice submitted by the supplier. In situations where electronic submission by the supplier to AP is infeasible, it will be possible for campus users to scan an invoice into Oracle Cloud. Once the invoice is scanned, it will match against the PO just as described above.
Via invoice approval, the original requester will have an opportunity to review the invoice before it is paid.
In terms of invoices, can we see the original invoice?
Yes. If the invoice was submitted as a PDF, you can see the PDF in the system. If the original invoice was sent electronically, the data will be available in the system.
Is BruinBuy going away? What about Classes of Order?
Yes, BruinBuy will be replaced by Oracle Cloud in July, 2021. Once Oracle is live, there will no longer be classes of orders. An equivalent process in Oracle Cloud will be used to handle these in the future, such as using contract purchase agreements and blanket purchase agreements.
What is changing in UCPath with Ascend?
There are several impacts to UCPath, all related to the new Chart of Accounts (CoA) structure and the use of Project Portfolio Management (PPM). Pages in UCPath and all reports that currently display or use Full Accounting Units (FAUs) will be updated to reflect the new Chart of Accounts (CoA) and project costing (POETAF) fields. Various system processes will also be updated to accommodate the new chart structure. Additionally, the UCPath department structure will be updated to match the Ascend financial unit hierarchy. The Ascend team is working closely with UCPath to design and test the updates to UCPath that will allow it to work seamlessly with Ascend at go-live.
Will users have to relearn UCPath business processes?
No. All UCPath business processes will remain the same; no changes will be made to the Employee Life Cycle in UCPath. However, there will be some changes to the UCPath pages and data entry flow due to the new Chart of Accounts (CoA). See the question above for more details.
Who will approve transactions in Concur?
The approver will be determined based on both the type of transaction and the accounting information on the transaction. For all Pre-Trip Authorizations, users will be able to manually select the appropriate approver when submitting the request. For expense reports charged to a project, the Project Manager or Department Grant Administrator will approve. For expense reports charged to a non-project source, users must select the appropriate approver from a pre-defined list of Financial Unit Managers.
How many Project Managers or Departmental Grant Administrators are permitted per project?
One Departmental Grant Administrator is permitted per sponsored research project. One Project Manager will exist per capital and other projects. He or she will approve all purchases and expense reports charged to that project.
Can the Financial Unit Manager be in the Entity Approval Group?
Yes. A Financial Unit Manager may act as another type of approver, such as an Entity Approver. In small areas, this overlap may be necessary.
Can I add non-mandatory reviewers, i.e., just send an "FYI" to my colleagues?
Not necessarily. When a transaction is submitted for approval, the approver may request that their colleagues be added to the approval process for that sole transaction. This will require these colleagues to approve the transaction before it can be finalized. The Ascend team is looking into additional functionality to understand what other options may exist for communicating about transactions within the application.
How will we appoint and update approvers?
Departmental approvers will be identified by Schools and will be provisioned and maintained via Grouper. Grouper will replace the current DACCS provisioning system. Project Managers and Departmental Grant Administrators will be identified directly in Oracle Cloud's Project Portfolio Management (PPM) module.
Can we mark purchases as "urgent" to notify approvers to prioritize accordingly?
Yes. When submitting a purchase requisition, you may mark it as "urgent". This will notify the approver (via email and their approval worklist) that the requisition is urgent. However, we always recommend that if a purchase is truly urgent, you should reach out to your approver via email or phone to ensure that the approval process occurs efficiently.
What happens if an approver rejects a transaction? Does the initiator need to start from scratch?
No. In most cases, the initiator does not lose their existing work; they can simply make a quick edit and re-submit for approval. In some cases, such as journal approval, we recommend that approvers use the "request more information" function as opposed to "reject" to make the process of editing and re-submitting more efficient. Approvers will receive training to understand the distinctions between these options.
Is there a dollar-threshold for obtaining approvals on purchases?
Yes, there will be a low-dollar threshold set for all requisitions that are not grant- or capital project-related. Any purchase requisition under this dollar threshold would auto-approve. Additionally, a high-dollar threshold will be set, above which a second layer of approval (the Entity Approval Group) will be required to review the transaction in addition to the Financial Unit Manager. The specific "global" thresholds for all schools and departments are still being determined and will be communicated once a decision is made.
Will we be able to set our own dollar thresholds?
Dollar thresholds will be set at a "global" level, meaning they will apply across the entire University. The Ascend team is actively working with academic and administrative leadership across campus to determine the appropriate thresholds, leveraging historical purchasing data to inform the decision.\
Chart of Accounts FAQs
- What is the Chart of Accounts?
The Chart of Accounts, or CoA, is the basic structure used to record the financial effects of transactions in Oracle Cloud (Ascend). The future state Chart of Accounts will:
- Replace the current FAU structure for recording financial transactions.
- Organize UCLA’s finances by segregating expenses, revenues, assets, liabilities, and equity to provide a clear understanding of the university’s financial status.
- Organize and report data out of the financial system.
- Support financial and management reporting by serving as the basis for the fiscal administration of UCLA’s funds, programs, projects, organizations, and activities.
- Serve as the common language for financial transactions whether they are created directly in the financial system, generated in another major university system, or created through a local third-party application. However, it may not support the detailed fiscal tracking of all institutional activities. Some detailed information currently stored in the current FAU structure will instead be captured within other modules of the Oracle Cloud application.
- Why do we need a new Chart of Accounts?
A new Chart of Accounts is needed for the following reasons:
- The current mainframe system no longer supports UCLA’s financial needs and requires modernization. The current FAU is not supported by Oracle Cloud and requires a redesign.
- FAU segments are used inconsistently across campus. Defined fields (e.g., Cost Center) are often interpreted differently in each unit and used in a variety of ways; free-form fields (e.g., Project, Source), if utilized, are used for a large variety of unique purposes. This inconsistent use of fields makes meaningful reporting at the broader institutional level difficult. The fields within the new CoA will be strictly defined and controlled to maintain institutional integrity.
- Comingling of data within a single FAU field has led to duplication of values and inflexibility in reporting. These “nested” values prevent consistent departmental and institutional level reporting.
- A limited number of remaining values and narrow ranges in some fields (e.g., Fund) has led to the recycling of values, which compromises reporting.
- Certain internal reporting capabilities are becoming more important (e.g., activity by interdisciplinary program), but UCLA lacks the ability to determine this information with the current FAU structure.
- How did we arrive at the CoA structure?
- The CoA structure is based on the UC Common Chart of Accounts, prior assessments of UCLA’s CoA, industry best practice, and feedback from key financial administrators representing academic and non-academic areas. To arrive at the final CoA structure, the Ascend CoA Redesign Team is in the process of deploying a four-phased approach that involves collecting requirements, testing the CoA structure with real-life business scenarios, developing values, and translating the current-state FAU into future-state Chart combinations.
- What are the key objectives of the CoA structure?
The key objectives of the CoA structure are to:
- Improve capacity for tracking fiscal activity of cross-disciplinary programs.
- Balance the University’s external reporting needs with the schools' local reporting needs.
- Create a common financial language for the institution.
- Increase flexibility for fiscal management and reporting.
- Scale as UCLA’s business expands and becomes more complex.
- Require less maintenance than the current-state FAU structure.
- How will the new UCLA Chart of Accounts compare to the current FAU?
The new UCLA Chart of Accounts differs from the current FAU in the following ways:
- Unlike the FAU structure, the CoA has a multi-dimensional, or matrix-style, structure with multiple segments where each segment captures a specific defined attribute of the transaction.
- Each core segment (Entity, Fund, Account, Financial Unit, Transaction Class, Program and Portfolio) has a single use with a clear and consistent definition. Today, information is comingled in FAU segments – for example, the Account segment contains functional expense classifications and, in some cases, organizational information. The Chart of Accounts will only have defined value sets, unlike the current FAU structure, which has two free-form fields: Project and Source.
- The Oracle Cloud financial system requires that each segment has a value when entering a transaction. For certain transactions, where not all segments are required, the system will auto-populate a default value. In the current mainframe system, the FAU recordings allow some fields to be left blank on certain transactions.
- How will this change the way I enter financial transactions in the Oracle Cloud Financial system?
There are several meaningful changes associated with the way financial transactions (such as purchase requisitions) are entered:
- There will be a drop-down list for each segment that contains all valid values.
- Users will be able to search for and select any value.
- Users will be able to see a title for each value.
- Cross-Validation Rules will systematically prevent users from entering an invalid CoA string.
- Where can users find all the latest information regarding the Chart of Accounts?
- Information, including presentations and future training materials, can be found on the Chart of Accounts webpage. As the project progresses, the Ascend team will continue to post additional materials to this page.
- Who is affected by this change?
- All financial systems users will be affected by the new CoA in some capacity. Training materials are being developed to aid campus’ adoption of the new CoA.
- Reporting & Data Warehouse
Reporting: Will I be able to save my reports and drill-downs so I can reuse them?
Absolutely. You will have the ability to take pre-built reports and save your own view (filters, prompts, etc.). Additionally, you can build your own reports and save them locally.
[Reporting] For user access, will i only have access to the general ledger or are subledgers included, as well?
You will have access to both.
Reporting: Regarding drill-down functionality, is it possible to dictate when i want to see details and when i want a summary?
Yes. The tools are very flexible and can provide a drag-and-drop user interface for developing reports.
Data Warehouse: What is the financial integration hub (FIH)?
FIH is the main solution for other applications at UCLA to get self-service access to financial data. It will consist of a series of flattened tables based on financial subject areas; for example, General Ledger, Accounts Receivables, Accounts Payables and Expenses. The primary objective of the FIH is to maintain business continuity and minimize departmental retrofit efforts from QDB to the new financial system. Authorized downstream application owners will be able to write queries to access approved subject areas to pull data into their systems.
Data Warehouse: What is the financial integration hub (FIH) replacing?
At go-live, FIH will only include Ascend solution data:
-Oracle Financials Cloud
Downstream applications will continue to have to connect to QDB to get additional sources such as BAR, FAM, etc.
Data Warehouse: Will I have access to another unit for shared projects?
Yes, the intent is to provide this access.
Data Warehouse: From a travel expense on the ledger, can I drill-down into the subledgers to see who incurred the expense? And can I see the description of that travel?
Our goal is to allow you to drill into the lowest transactional level of data; the details of an expense report are an example of this capability.
Data Warehouse: Regarding the new planning, budgeting & forecasting system (EPBCS), will this only grab data from the GL or will it pull subledgers data too?
EPBCS data will be included in the Data Warehouse. EPBCS itself will only be able to view the financial data in the GL, but can pull more summary-level detail compared to budget through the Data Warehouse.
Data Warehouse: Can I leverage the QDB tables to map to the future state data warehouse tables?
There is no translation between the tables because Oracle Cloud is fundamentally a different table structure. We will provide training and resources to understand how to navigate the future Data Warehouse tables closer to go-live.
Data Warehouse: Will accounts receivables include bar?
Accounts Receivable in Oracle Cloud will incorporate non-student billing from BAR, and all data that resides in Cloud will be available in the data warehouse. Student billing will still be housed in BAR and not passed to Oracle Cloud. If requirements exist to include student billing in the data warehouse the Ascend Team will conduct an evaluation and determine the feasibility of including that data.
Data Warehouse: What does MGR stand for?
Manager. This is a way to signify that an account that has access to QDB is not assigned to an individual. These credentials can be used by other applications to access the data in QDB.
Will my access to Financial Systems change at go-live?
School/VC leadership will define access provisioning in the future based on user roles.
What is an Actor? What does an Actor drive?
Actor is a term used to describe individuals who perform similar business processes. An Actor is distinct from a user’s title or position. When delegating access in Grouper, Delegators will be able to identify employees as particular Actors.
Can one person serve as multiple actors?
Yes. For example, someone may be a Procurement Requester and also a Financial Unit Manager.
Can I set up dollar limits in Grouper to restrict a user from entering high-dollar transactions?
No. All transaction initiators will have the ability to enter any dollar amount. However, these transactions will route through an approval workflow. Certain high-dollar transactions will route to numerous stages of approval before they are finalized and accounted. The specific high-dollar thresholds are being evaluated by UCLA leadership. Details will be available in future updates.
- System Access
What Is Grouper?
Grouper is an application for managing access provisioning and will replace DACSS for Ascend-impacted applications. There will be a user-friendly front-end interface to allow delegators to easily provision access across applications.Granting access in Grouper will be more intuitive than DACSS; instead of function codes, the access will have application-specific descriptive names and additional information about the roles available.
What Is IDM?
IdM stands for “Identity Management”. The Ascend IdM team deals with authenticating (Single Sign-On, e.g. UCLA Logon ID), authorizing (access provisioning via Grouper), and managing user identities.
Will Departmental Security Administrators (DSAs) still provision access?
School/VC area leadership will be given Delegator access and will ultimately decide who should provision access within their organization. This delegation model allows each department or organization to define their own set of Delegators to create the best model of access provisioning for their business processes.
Will the option to define access based on dollar amounts of transactions still be available?
Grouper is an access provisioning tool and will accommodate the security model provided by each application to which it grants access. For Oracle Financials Cloud, delegators will not have the option to define initiator access based on dollar amount. Instead, approval workflow rules will determine the number of approval stages required for financial system transactions. For example, any procurement requester can submit a high-dollar requisition and it will need to route through multiple approval stages before it is finalized.
Will I be able to report on user access from Grouper?
Yes. Grouper provides the ability to look up access and generate reports based on a user’s privileges
Will templates still be available as they are in DACSS?
Yes. Grouper will support a similar feature; Delegators will be able to clone current access of one user to another user. However, please note that a Delegator can only clone access based on the privileges and permissions delegated to them.
Who will have access to Grouper?
All employees will have access to Grouper. The actions that can be performed in Grouper, however, depend on the permissions and user roles granted to an employee.
- System Integrations & Retrofits
System Integrations: Why do we need new integrations?
The existing integrations to the financial system are based on the legacy system's requirements. These cannot be translated to the new Oracle Financials Cloud system and, therefore, are being evaluated on a case-by-case basis to determine the required future integrations.
System Integrations: What are different ways I can integrate our systems to the new Oracle Financials Cloud?
Integrations are available using batch and real-time processes. Batch file-based integrations will use FTP, and real-time integrations will use RESTful APIs.
System Integrations: Are APIs available for integrating to our systems to the new Oracle Financials Cloud?
Yes. We are building a suite of RESTful APIs to integrate to the financial system.
System Integrations: Where can I find all the latest information regarding the new integration requirements?
Currently, the integration requirements are being shared directly with the systems that will integrate with the new financial system. In the future, certain APIs will be published on a campus portal.
System Integrations: What is FBDI-based integration?
FBDI is an acronym for File-Based Data Import. This is the specification Oracle uses for importing batch data.
System Integrations: What is the API-based integration?
The real-time integration to the financial system uses RESTful APIs. The APIs are web services that adhere to REST architectural constraints.
Retrofits: What is retrofitting
Retrofitting describes the effort required to ensure that UCLA’s systems can continue to function with Oracle Financials Cloud. Specifically, this retrofitting effort includes modifying systems that currently hold Full Accounting Unit (FAU) values or segments, as well as the Department hierarchy. Today’s FAU values and segments will need to be replaced with future-state Oracle Cloud Chart of Accounts (CoA) values and segments, and the Department hierarchy will need to be replaced with the future-state Financial Unit hierarchy.
Retrofits: How do I know if I am impacted?
In 2018, the Ascend project team conducted an analysis of systems across UCLA that will be impacted by Ascend. For reference, if your system(s) today hold FAU values, department hierarchy values, then you will be impacted. The Ascend team will work with each department in the planning and execution of your retrofit efforts. If you believe your system is impacted and have yet to begin discussions with the Ascend team, please email [email protected].
Retrofits: What is the approval process for integration?
The Ascend project team has determined the list of in scope inbound integrations through numerous outreach efforts and direct validation with department leadership and Ascend Business Partner Experts. Analysis is ongoing to determine the scope of outbound integrations, which includes Oracle Cloud and the new Data Warehouse that will replace FS QDB. If you have any questions regarding what is in scope for your department’s retrofit efforts, please do not hesitate to reach out to the Retrofits team by emailing [email protected].
Retrofits: What is the difference between directly and indirectly impacted systems?
Directly impacted systems will interface directly with Oracle Cloud and other financial systems being implemented by the Ascend project. Examples include:
- Housing & Hospitality – Opera
- Facilities – Maximo
Indirectly impacted systems interact with the directly impacted systems noted above, but will not integrate directly with Oracle Financials Cloud in the future state. These indirectly impacted systems may also need to be modified to accommodate the new Chart of Accounts (CoA) values (previously FAU), as well as an expanded Department hierarchy structure (now called Financial Unit hierarchy). Examples include:
- Specialized departmental systems
- Local SQL servers or Access Databases
- Web applications
- Microsoft Excel spreadsheet
Retrofits: When is the deadline for retrofitting my system or building an integration?
The Ascend go-live date is July 2021. However, there are several critical milestones along the way that must be met to ensure a successful retrofitting effort. The sequence of key testing milestones for directly and indirectly impacted systems is listed below for reference. Alignment of your retrofitting efforts with the testing cycles will be planned at length during working sessions with the Retrofits team.
- Conference Room Pilot 4 / Connectivity Testing
- System Integration Testing, Rounds 1 and 2
- User Acceptance Testing
- Pre Go-Live Training
- Go-Live: July, 2021
*Please note that if interface development is not part of your retrofit efforts, then the testing milestones above may not apply. You will have until go-live to retrofit your system to hold the new CoA/POETAF (Project Number, Organization, Expenditure Type, Task, Award, Funding Source) values and/or Financial Unit hierarchy.
Retrofits: Where can I go if I have technical or business process (functional) questions?
Please reach out to us via [email protected]. A member of our team will route your inquiry for review and input by the appropriate expert.