A modern procurement platform, powered by JAGGAER, configured to reflect UCLA business processes. 

BruinBuy Plus provides user a modern purchasing interface, similar to the “Amazon” experience. It also provides enhanced communication tools and increased visibility into the workflow approval process. 

Purchase Order Migration FAQs document

No. Pcard will be integrated with Concur.

BruinBuy will remain active, but only for transactions that cannot be completed in BruinBuy Plus.

BruinBuy Plus will support multiple attachments.

In the future state (Oracle), most transactions will begin in subledgers which will contain subledger-specific information. All sponsored contract and grant costs will begin in the Project Portfolio Management (PPM) subledger. In PPM, detailed individual transactions will be recorded using POETAF. All costs in subledgers will be recorded to the General Ledger based on Subledger Accounting Rules (SLA). In the General Ledger, summary-level information will be recorded using the Chart of Accounts (CoA) chart string; in this sense, the General Ledger will remain “general.”

POETAF is an abbreviation for the six fields within the PPM subledger: Project Number, Organization, Expenditure Type, Task, Award, and Funding Source.

1. Project Number: A unique number assigned to identify each project. Contains budget by expense category.
2. Organization: Unit that owns a given project expenditure. Department must be designated as an expenditure-owning organization.
3. Expenditure Type: Identifies the specific type of transaction. Corresponds with Natural Account segment in the Chart of Accounts (CoA).
4. Task: Identifies the project activity. 
5. Award: Umbrella record that contains overall financial and demographic information with projects associated underneath. 
6. Funding Source: The funding source supporting a specific expenditure. Options generally include sponsor and an internal source, such as a cost share fund. 

• Project Number: For the converted data, a unique combination of Account, Cost Center, and Fund values in FAU (Full Accounting Unit) will have one unique project. Project Number (8 digits) will be assigned in a sequential order by system.  
• Organization: Organization value is derived from Financial Unit values that have been confirmed through CoA mapping. The lowest level of the value in the financial unit will be used.  
• Expenditure Type: Expenditure Type value is derived from Object Code value in FAU. 
• Task: Task has one to one relationship with Project. Task value is derived from Project Number value. No connection to any segment in FAU. 
• Award: Award is set up in PPM for each unique sponsored award. Award value is derived from Fund Number in FAU and award information in PATS. For a single fund number, one fund in FAU will be one award in PPM. For the cases where multiple fund numbers are assigned to one award, one award will be set up in PPM with multiple projects.  
• Funding Source: Funding Source values indicate if it is from sponsor, UCLA (cost sharing), Program income, or other source (e.g., STIP). The Funding Source values will be the sponsor name for sponsored funding, or Financial Unit in the case of cost sharing. 

We aim to convert all detailed costs from inception to date on the open funds that will convert to Oracle and will continue to test and evaluate a feasibility of this plan through rounds of testing.

Oracle was selected as the best modern financial system to meet UCLA’s complex requirements. Most modern financial systems do not contain “free form” fields like today’s Project and Source fields. Free form fields are not accommodated in new systems because they hinder data accuracy and related reporting. To prepare for this upcoming change, the Program Team is working with over 300 campus mapping experts across every organization to understand how these fields are used today. The Grants team has reviewed use cases submitted by campus, grouped similar use cases, identified the source system(s) involved in each scenario, and are in the process of finding solutions to address these use cases. Based on the information gathered from campus, the following options exist for elements held in Project and Source today:  

1. Some data elements will not be held in the Chart of Accounts but will instead be held in subledgers or other sub systems. For example, one current use of the Source field is to identify how receipts come in (e.g., ACH, Wire, etc.). In the future, this same information will be identified in the Cash Management module of Oracle.  
2. Other data will admittedly be required to be tracked in separate systems if it is not appropriate for a financial system. For example, identifying information for staff members attending a conference will not be held in the central finance systems. 

A Procure To Pay (P2P) software solution that provides a modern shopping experience with easy-to-use functionality.   

JAGGAER continues to be recognized as a procurement technology leader by Gartner. JAGGAER provides the ability for end users to use one platform for all of their P2P needs. 

The first release of BruinBuy Plus is scheduled for January 2, 2024. 

Everyone on campus will be impacted, but all users with the appropriate DACSS roles will have access to JAGGAER for shopping cart creation via Single Sign-On (SSO). 

Yes! The Training Team will deliver training in phases to meet the needs of end users. Details around end user training for Procurement Release 1 will be announced as it is made available.

Bruin Finance is UCLA's name for the Oracle Financials Cloud system. This implementation will achieve crucial, modern efficiencies; streamline reporting needs; and meet regulatory requirements. It also modernizes campus financial systems and transforms business processes.

UCLA has experienced remarkable growth since the development of the current financial systems. Adopting modern, scalable, cloud-based systems will empower UCLA’s continued growth and enable the transformation of financial operations. This transformation will allow staff to focus on the core mission, empowered by up-to-the-minute data and robust reporting capabilities.

Yes, as part of a comprehensive training plan, there will be several training opportunities to see the new system and practice.

Through the Ascend 2.0 Program, UCLA will: 

1. Streamline the Procure to Pay processes by replacing the legacy system with BruinBuy Plus, supported by JAGGAER technology  
2. Modernize and streamline financial management by replacing the mainframe financial system with Oracle Financials Cloud (Bruin Finance)
3. Increase efficiency by retiring dated and redundant financial applications
4. Support consistent campus-wide reporting and create a new common language for UCLA’s financial transactions by replacing the Full Accounting Unit (FAU) with a new Chart of Accounts (CoA) 
5. Enable a more robust planning and budgeting process by migrating from Hyperion to Oracle Enterprise Performance Management Cloud (Bruin Finance)

Once relaunched, the Ascend 2.0 website will have additional information regarding this initiative, including timelines. The Ascend 2.0 team also invites you to contact them at ascend2@ucla.edu.

We are excited to announce the relaunch of UCLA’s efforts to transform our financial systems. The Ascend 2.0 Program, previously known as Ascend, is an ambitious, multi-year initiative to transform the landscape of UCLA’s financial systems. The scope increased and now involves two system implementations (BruinBuy Plus and Bruin Finance) and the transition to 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 2.0).

The future state Chart of Accounts will: 

• Replace the current Full Accounting Unit (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 
• Support financial and management reporting, alongside the Oracle sub-ledger data, 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

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. 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.

The Chart of Accounts (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. The CoA Redesign Team is in the process of deploying a four-phased approach that involves CoA Planning, CoA Structure Enhancement, CoA Value Development, and CoA Mapping Development.

The key objectives of the CoA structure are to: 

• 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 
• Improve capacity for tracking fiscal activity of cross-disciplinary programs
• Scale as UCLA’s business expands and becomes more complex

The new UCLA Chart of Accounts differs from the current FAU in the following ways:

• Each core segment (Entity, Fund, Account, Financial Unit, Transaction Class, Program and Portfolio) has a single use with a clear and consistent definition.  
• 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.  
• 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.

Information can be found on the Chart of Accounts webpage. As the project progresses, the Ascend 2.0 team will continue to post additional materials to this page.    

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.