The basic function of the Stanford University organization (org) code hierarchy is to define parent-child organizational relationships and group information such as employees and financial data. The org code hierarchy affects many aspects of Stanford’s financial reporting and management. Therefore, any change to the org code hierarchy must be carefully planned and executed and only authorized budget officers may submit them. As an alternative to org hierarchy changes, departments can consider utilizing PTA hierarchical structure and attributes (e.g., free-form fields) to accomplish reporting and management needs.
There are many reasons why changes might be made to the org hierarchy, such as to improve management or reporting of business activities, to create a new organization, to reflect a restructuring of an organization, to inactivate an org that is no longer needed, or to change the name or description of an existing organization. Refer to the planning section below for submission deadlines and considerations for these requests.
Category Type | Description and Considerations |
---|---|
New Org Code |
Request for a new org code to support organization expansion or reorganization. If it is a leaf-level code (i.e, an org code that has no children), it may be used to assign staff or accounts (also known as PTAs). As a best practice, identify the owners of activities in the new org structure prior to the org changes to ensure seamless transition (e.g., who will manage POs, vendor relationships, financial approval, etc). When creating a new org, a unique four digit alphabetic code needs to be specified. Each budget unit has a unique naming convention for their set of codes (e.g., many School of Engineering codes begin with an “R”), so it is important to consult the designated budget officer for an appropriate and available code. |
Org Code Move |
Request for change of the parent org.
If an org is moving, identify an inbound owner and an outbound owner of the org move to ensure coordination and effective hand off of the organization. Also, if the org will be moving across budget units, coordination between the designated budget officers of both units is required (org code moves across budget units take effect only once a year, on Sept. 1; see Change Request Deadlines and Planning Timeline below). |
Modify Org Attributes | Request to change one of the following fields: Official Name, Display Name, 30 Char Name, or to update one of three custom fields. |
Inactivate an Org Code | Request to inactivate an org code for future use. Before inactivating an org code, all assigned staff and assigned PTAs must be moved to another leaf-level org code. The same applies to positions under the org. Note that deactivating an org does not delete it; the org will still exist in the hierarchy, but will have a status of “inactive.” |
Plan for org code hierarchy changes at least three months before the implementation date and start preparing early to ensure a smooth transition. Refer below to the first table for deadlines and to the second table for a planning timeline and considerations for submitting change requests. For additional support with planning or implementing organizational changes, submit an org code hierarchy support request.
Org Code Hierarchy Change Request Deadlines
In addition to the quarterly update cycle below, please note that individual budget units may have their own internal processes and deadlines which departments must follow to submit requests.
UBO Starts Accepting Change Requests | Change Requests Due to UBO | New Org Code Hierarchy Released (Approved Changes Implemented in Most Systems)* | Approved Changes Implemented in Oracle Financials |
---|---|---|---|
Sept. 1, 2023 | November 1, 2023 | Dec. 1, 2023 | Three to five business days after November fiscal close |
Dec. 1, 2023 | February 1, 2024 | March 1, 2024 | Three to five business days after February fiscal close |
March 1, 2024 | June 1, 20234 | July 1, 2024 | Three to five business days after June fiscal close |
Sept. 1, 2024 | August 1, 2024 | Sept. 1, 2024** | Three to five business days after August fiscal close |
*Systems include, but are not limited to, Cardinal Planning & Budgeting (CPB) system and PeopleSoft. The CPB system employs the currently effective hierarchy.
**Org code moves across budget units take effect only once a year on Sept. 1 (start of fiscal year).
Planning Considerations and Timeline
The following questions will support thoughtful creation of new org structure:
- Reporting
- How do you want your revenue, expenses, and other transactions to roll up in the new org structure?
- Do you need to view historical data for the org/PTAs being changed?
- Control:
- Who should see what data (including salary data)?
- Do different people need access to different accounts? Do you want to control data by org, PTA, award, or project?
- Are there timing considerations for authority (e.g., if an org moves to a new budget unit, do you need to retain authority permanently or temporarily?)
Timeframe | Activity and Considerations |
---|---|
At least four months prior to org change |
|
Three months prior to org change |
|
One month prior to org change | Review related systems and impacts to take appropriate action as necessary. |
Below are the systems or areas that may be impacted by an org code hierarchy change request.
System/Area | Description and Impact | Consideration |
---|---|---|
Authority Manager |
Authority manager allows users to view and grant authority across the many administrative applications at the university, including financial approval authority. Authority Manager needs to be modified to ensure the right level of control (separation of duties). Process:
|
Plan to change Authority Manager one month before change. Note: In many cases, changes to Authority Manager cannot be made until the new org(s) are created or the org(s) are moved. |
PeopleSoft | Request creation/changes to position management for the updated leaf org to feed over to the employee job record. Ensure the employee job record reflects the correct leaf org. Employees on parent orgs will fail to load into Oracle Financials, affecting access and possibly cause inaccurate payroll charges. In HRMS PeopleSoft, Position Management timing and coordination within the department is critical since you cannot sequence in Position Management (e.g., process two transactions on the same effective date). | Timing of creation/ changes defined by Payroll Schedules and Deadlines |
Labor Schedules | Can be adjusted at any time, but labor schedules for new/changed orgs should be created in line with the activation of the org code hierarchy in Oracle Financials. If the PTA(s) that employees are charged to are not changing (i.,e., if the org is moving intact), then changes to labor schedules may not be needed; view Learn About System: Labor Schedules. If the PTA(s) that employees are charged to are not changing (i.,e., if the org is moving intact), then changes to labor schedules may not be needed. |
Once the org code hierarchy is activated in Oracle Financials. |
Organization Suspense Accounts (OSAs) | An Organization Suspense Account (OSA) is a holding account, set up for every department to account for payroll transaction errors. The OSA and org mapping is maintained in Oracle Financials by the Systems and Reporting Operations (SRO) team. To learn or change the OSA for an org, use the Oracle Inquiry Tools: Suspense Account Query. | |
Accounts Payable (AP) Default PTA | An Organization AP Default PTA is a holding account, set up for every department to account for non-payroll transaction errors. The AP Default PTA and org mapping is maintained in Oracle Financials by the Systems and Reporting Operations (SRO) team. To learn or change the AP Default PTA for an org, see Learn About: Suspense Account Query Tool. | |
Revenue/Fund Balance | Submit a support request to the Office of the Treasurer if revenue is impacted. If revenue is being automatically posted, then Oracle Financials will need to be updated to correct PFOO (object code or 4****). If revenue/fund balances are impacted in the org, determine updates needed to manage/report revenue as desired. | Two week lead time to request change. |
Global | Determine if the org change impacts a global entity; consult with the Global Business Services team as needed. | |
POs/Blanket POs | Review active POs (not finally closed and no payment activity in 18-24 months) and determine if PTA needs to be updated (e.g., if PTA is no longer active, invoices will not be paid). | |
Contracts (SmartMart Contracts) | Look up purchase requisitions that have a contract; or long term obligation (e.g., a lease, term obligation, contract to a third part supplier). Review active contracts by running Purchase Requisition Report in OBI, and include the “Purchase Req Line Contract Required Indicator” field. | |
Vendors | Determine if there is going to be a change in the existing vendor relationship (e.g., if contacts change, or an org is moved to another BU and a different vendor is used for the same service). | |
PCards/TCards | Review existing cards and PCards to determine if a change to the guarantee PTA associated is needed, if a change to the verifier or custodian is needed. Determine if a new card needs to be issued. Run the OBI Credit Card Transaction - Aging Report to determine what transactions are in process, and clear them prior to org change. Also review credit card transactions to determine if subscriptions or other automatic payments will be impacted. | Two weeks - one month prior to change |
Expense Request Transactions/ Non-PO Payments (ERs, PRs, VRs) | Review active transactions to determine if PTA changes are needed. Run the OBI Expense Requests - Aging Report to determine what transactions are in process and submit or delete them prior to org change. Review transactions to determine if subscriptions, memberships, etc. need to be moved to a new PTA. | Two weeks - one month prior to change |
Contingent Workforce (CardinalTemps and Independent Contractor) | Ensure contingent workers (temp labor and independent contractors) are moved to the updated org, if needed. For independent contractors (not through CardinalTemps), please follow the Contracts process above. | One month prior org change |
Reporting (Verification) | Verify org changes and run OBI reports for expenses, revenue and budgets, to determine if the org structure is capturing financials as desired. If discrepancies are found in OBI, submit a support request. | One day after org changes are made in Oracle |
Reporting Historical Data (OBI) | Historical attributes in OBI Ad Hoc Reporting can be used to see data in original org or PTA. Note: Authority for current org/PTA is needed. | After org changes are made in Oracle Financials |
Academic (ACAD) Org | If an org that is being moved, changed or deactivated is related to an academic (ACAD) org, ensure the impact is managed. Note: AcadOrgs are managed by the Registrar and questions can be directed to @email. |
Only authorized budget officers may request new org codes or request changes to existing org codes using the Organization Code Hierarchy Tool. For step-by-step instructions on how to make change requests, refer to How to: Request Changes to the Organization Code Hierarchy. For guidance on best practices in making these changes, refer to the previous sections in this topic overview.
The Org Code Hierarchy Tool has historical org code changes dating back to July 1, 2023; you can view details when you click on each org code or download the Change Request Details or Summary of Changes export files; see Reporting: Organization Code Hierarchy Tool for more information.
For historical org code changes prior to June 30, 2023, please refer to these UBO-maintained logs:
- Org Code Change Request Log (March 2008-June 2023)
- Legacy Org Code Change Request Log (May 2003-December 2007)