Oracle Business Intelligence (OBI) Expense Requests and SU Card Activity (ERR) dashboard provides information about the Expense Request system in Oracle, including purchasing card (PCard), travel card (TCard), expense reports, visitor reimbursements, digital payments, advances, petty cash, non-PO payments and legacy iOU transactions.

Launch OBI Expense Requests and SU Card Activity Dashboard

Click this link... ...for reports about
Expense Requests Transaction details of all advances [ADV], expense reports [ER], visitor reimbursements [VR], digital payments [DP], non-PO payments, including honoraria and human subjects [PR], petty cash [PC] and legacy iOU transactions [A]/[R].
Expense Requests - Aging Transaction details of expense requests not yet posted to a PTA, grouped by age (in days) or outstanding status.
Credit Card Transactions Transaction details of credit card charges, in separate sections for university purchasing card (PCard) and travel card (TCard) transactions.
 
Credit card information for all cards used in the transactions.
Credit Card Transactions - Aging  Transaction details of credit card charges not yet posted to a PTA (may or may not be on an expense request in process), grouped by age (in days) or outstanding status.
Advances Transaction details of advances, similar to Expense Requests tab, but includes the expense requests to which advances have been applied.
Advances - Aging Transaction details of advances not yet expensed, i.e., not on an expense request that has been posted to a PTA. Transactions are grouped by age (in days) or outstanding status.  
 Advances - Force Cleared Transaction details of advances that have been force cleared and all transactions associated with the original advance and the force cleared advance, including the force clear fee.
Petty Cash Replenishment Transaction Detail Petty cash fund replenishment transaction details.
Expense Request Efficacy Dashboard Expense request approval/rejection rates, approval aging and status, for assessing process flow efficiency.
Force Clear Metrics Dashboard Summary of force cleared travel card transactions (TCard), purchasing cards (PCard), and advances by organization and person.
SU Credit Card Custodian Non-customizable, BI Publisher listing of SU credit cards and details on the card holders, verifiers and approvers, transaction limit amounts, last four digits of card number and guarantee PTA number.

Transaction details of all advances, expense reports, visitor reimbursements, digital payments, non-PO payments, including honoraria and human subjects, petty cash and legacy iOU transactions.

Launch OBI Expense Requests

  • What is the status of an expense request for a particular traveler?
  • Which expense requests were submitted for a particular event, and to what PTAs were they charged?
  • Which advance was used against a particular expense request, and how much of the advance was applied?
  • Which non-PO payments are charging my PTA?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  Refer to Using Selection Criteria for OBI Reports for more guidance.

  • No dates are required if searching based on Expense Request Transaction Number or SU Credit Card Transaction ID Number. For Expense Request Transaction Number, use the proper alpha character prefix. 
  • Guarantee PTA number is the PTA where travel card charges accumulate until they post to a PTA as part of an expense reimbursement. The guarantee PTA is specified during the credit card application process.
  • Supplier Name is the individual who is getting the reimbursement, advance or non-PO payment.

If Expenditure Item Dates is used as selection criteria, all the transaction lines of specific expense requests may not be captured.

The Expense Request Transactions section displays details and status information of expense requests. It receives data from the Expense Request module in Oracle Financials for all transactions, except those that have been saved but never submitted.

To reconcile Expense Requests with the Consolidated Expenditure Reporting Expenditure Detail report, choose GL Period Name as selection criterion and use the Expenditure Reconciliation view.

The Expense Request Transactions Summary section displays the number of expense request transactions and the total dollar amount of all the expense requests listed in the Expense Request Transactions section. 

The OBI ERR Expense Request Category field maps to Oracle Expense Request System (ERS) Type, see table below. The initial alpha characters of an ERR Expense Request Transaction Number uniquely identify ERR Expense Request Category.

ERR transactions are further defined by Expense Request Transaction Type Description which maps to Oracle Expense Request System (ERS) Category. For guidance on determining ERS types and categories, refer to Expense Request System Help.
 

OBI ERR Expense Request Category Initial characters of transaction # Oracle ERS Type
Expense Report ER Expense Report/SU Payee
Visitor Reimbursement Request VR Expense Report/Non-SU Payee
Digital Payment DP Digital Payments/Non-SU Payee
Advance Request ADV Advance/Request
Non-PO Payment Request PR Non-PO Payment (all types)
Petty Cash Replenishment Request PC Petty Cash/Replenishment
Other A or R Legacy iOU system

The Expense Request-Aging report displays expense requests that have been submitted for approval but not yet posted to a PTA as an expenditure.  

  • Submitted expense reports are displayed within the appropriate aging bucket .
  • Expense requests that have moved beyond local approval, are displayed as outstanding.
  • After the expense request has moved past audit review, posted and paid it is no longer visible on the aging report but is still available on the Expense Request report.

For more information on the expense request workflow and how it relates to this report refer to Topic Overview: Managing Aging and Outstanding Expense Transactions-Expense Requests Aging.

Launch OBI Expense Requests - Aging

  • Which transactions are aging and need action?
  • Which transactions are outstanding (approved locally but pending other actions)?
  • Are any expense requests stalled in their workflow progression and need resolution?
  • Who is the approver or preparer to follow-up with, based on the transaction status?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  Refer to Using Selection Criteria for OBI Reports for more guidance.

  • The Expense Requests - Aging tab has no date prompts, thus providing visibility on all transactions that have not posted to a PTA as an expenditure. 
  • For Expense Request Transaction Number, use the proper alpha character prefix. 
  • Supplier Name is the individual who is getting the reimbursement, advance or non-PO payment.

Expense Requests - Aging & Outstanding displays details and status information. It receives data from the Expense Request module in Oracle Financials for all transactions, except those that have been saved but never submitted.

Transaction details of credit card charges in separate sections for university purchasing card (PCard) and travel card (TCard) transactions as well as credit card information for all cards used in the transactions.

Refer to Topic Overview: Stanford's Purchasing Card (PCard) Program and Topic Overview: Stanford Travel Card (TCard) Program,  for more information about the university's credit card programs.

 

Launch OBI Credit Card Transactions

  • What charges are on my organization’s travel card?
  • What are the transaction details, counts and amounts for the cardholders in my organization for a specific time period?
  • Which transactions were force approved (force cleared) in a particular range of GL periods and may need to be journaled to their proper PTAE?

 

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  Refer to Using Selection Criteria for OBI Reports for more guidance.

 

Description Selection Criteria:
  • You can narrow the the type of credit card transactions returned (Tcard or Pcard), by specifying the Credit Card Program Description.
  • To search by status for a TCard transaction, specify "SU Travel Card" for Credit Card Program Description.
    • For Tcard transactions not not yet linked to an expense request that has been submitted for approval, use "Unknown" for the Expense Request Status Description.
    • For  Tcard transactions already linked to an expense request that has been submitted for approval, use the Expense Request Status Description  for the desired status:  Paid, Pending Approval, Rejected
  • To search by status for a Pcard transaction, specify "SU Pcard" for Credit Card Program Description and use SU Credit Card Transaction Status Description.
  • To retrieve any Tcard or Pcard transactions that have been force cleared, specify "Forced Approved" for SU Credit Card Transaction Status Description.
Transaction Number Selection Criteria:
  • If searching by SU Credit Card Transaction ID Number, no dates are required. This transaction ID number can be for the PCard Mastercard, TCard Mastercard or TCard American Express.
  • If searching by Expense Request Transaction Number, no dates are required. Only TCard charges related to the specified expense request will be returned.

Name Selection Criteria:

  • SU Credit Card Holder Name is the name printed on the credit card; for department cards, it is the name of the department.
  • SU Credit Card Custodian Full Name is the person who has possession of the card. This is most relevant for department cards because they do not have a person’s name on them. For individual cards, the credit card custodian is also the credit card holder.
  • Preparer Full Name applies only to TCard transactions and is an attribute of an associated expense request. 
  • Verifier Full Name applies to both TCard and PCard transactions. 

PTA Selection Criteria:

  • Guarantee PTA Number is an attribute of the PCard and/or TCard used for a transaction and can be different from the transaction PTA Number.
    • For TCards, it is the PTA where charges are accumulated until they are posted as an expenditure on an expense request.
    • For PCards, it is the PTA to which charges will be force-cleared if they are not verified and expensed to a PTA within an appropriate time frame.

Use the Expanded with PTAE view to determine which credit card transactions have been force cleared (aka force approved) and to display the administrative fee charged. Refer to Topic Overview: Managing Aging and Outstanding Expense Transactions-How to Find Force Cleared TCard and PCard Transactions.

TCard Transactions

The TCard Transactions section displays travel card transactions (Mastercard and American Express) throughout their entire workflows. This includes TCard transactions that have or have not been applied to an expense request.

PCard Transactions

The PCard Transactions section displays all purchase card transactions (Mastercard).  This includes PCard transactions that have not been verified.

 

Credit Card Information

The Credit Card Information section displays information about the TCards and PCards used, including the card custodian, holder and verifier, along with the guarantee PTA and credit limit amounts.  

Only cards that were used in the transactions listed in the TCard and PCard Transaction Reports will be displayed. Deactivated cards could be displayed if they were used in one of the transactions listed. This may differ from what is shown on the SU Credit Card Custodian Report.

To understand which date selection criteria to use, refer to the following table. 
 

Field Description
Expense Incurred Date  
The date the credit card transaction occurred.
SU Credit Card Posted Date The date the transaction posts from the bank to the Expense Requests module (TCards) or the PCard module (PCards) within Oracle Financials.
SU Credit Card Expense End Date The date entered by the preparer for TCard transactions in the Expense Requests module to specify the last expense date for all transactions related to the event/trip.  This supersedes the default of Expense Incurred Date to become the new date used for calculating aging. 
Expense Request End Date The latest expenditure item date of all the transactions included in the expense request. This field is not displayed by default in the aging report but can be revealed by using the include command.
Submitted Date For PCards, it is the date the transaction completed verification and was submitted for approval. For TCards, it is the date the associated expense request was submitted for approval.

For a list of fields available to include in report customizations, refer to Data Fields Available in ERR Dashboard.  

The Credit Card Transactions - Aging report displays transaction details of credit card (TCard and PCard) charges not yet posted to a PTA as an expenditure, grouped by age (in days) or outstanding status.

  • Credit card transactions appear on the aging reports not long after a purchase has been made and will stay on until they are:
    • (Tcard) either applied to an expense request that has been approved, posted and paid.
    • (Pcard) verified and approved.
  • After the credit card transaction has been fully cleared it is no longer visible on the aging report but is still available on the Credit Card Transactions report.

For more information on the travel card transaction workflow and how it relates to the TCard Transactions Aging & Outstanding report refer to Topic Overview: Managing Aging and Outstanding Expense Transactions-Travel Card (Tcard) Transactions Aging.

For more information on the purchasing card transaction workflow and how it relates to the PCard Transactions Aging report refer to Topic Overview: Managing Aging and Outstanding Expense Transactions-Purchasing Card (Pcard) Transactions Aging.

Refer to Topic Overview: Stanford's Purchasing Card (PCard) Program and Topic Overview: Stanford Travel Card (TCard) Program,  for more information about the university's credit card programs.

Launch OBI Credit Card Transactions - Aging 

  • What charges on my organization’s travel card are not yet posted to a PTA, i.e. are aging, and how old are they?
  • Which aging transactions are pending verification or local approval and who are the employees whose actions are pending?
  • Which aging transactions are outstanding (approved locally but pending other actions)?
  • Which aging transactions are disputed?
  • Which aging transactions do not have Expense End Dates assigned?
  • Which aging transactions have a verifier or a card custodian that is no longer in their role at Stanford?

 

 

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  Refer to Using Selection Criteria for OBI Reports for more guidance.

The Aging tab has no date prompts, thus providing visibility on all credit card transactions that have not posted to a PTA as an expenditure.

Description Selection Criteria:
  • You can narrow the the type of credit card transactions returned (Tcard or Pcard), by specifying the Credit Card Program Description.
  • To search by status for a TCard transaction, specify "SU Travel Card" for Credit Card Program Description.
    • For Tcard transactions not not yet linked to an expense request that has been submitted for approval, use "Unknown" for the Expense Request Status Description.
    • For  Tcard transactions already linked to an expense request that has been submitted for approval, use the Expense Request Status Description  for the desired status:  Paid, Pending Approval, Rejected
  • To search by status for a Pcard transaction, specify "SU Pcard" for Credit Card Program Description and use SU Credit Card Transaction Status Description.
Transaction Number Selection Criteria:
  • If searching by SU Credit Card Transaction ID Number, no dates are required. This transaction ID number can be for the PCard Mastercard, TCard Mastercard or TCard American Express.
  • If searching by Expense Request Transaction Number, no dates are required. Only TCard charges related to the specified expense request will be returned.

Name Selection Criteria:

  • SU Credit Card Holder Name is the name printed on the credit card; for department cards, it is the name of the department.
  • SU Credit Card Custodian Full Name is the person who has possession of the card. This is most relevant for department cards because they do not have a person’s name on them. For individual cards, the credit card custodian is also the credit card holder.
  • Preparer Full Name applies only to TCard transactions and is an attribute of an associated expense request. 
  • Verifier Full Name applies to both TCard and PCard transactions. 

PTA Selection Criteria:

  • Guarantee PTA Number is an attribute of the PCard and/or TCard used for a transaction and can be different from the transaction PTA Number.
    • For TCards, it is the PTA where charges are accumulated until they are posted as an expenditure on an expense request.
    • For PCards, it is the PTA to which charges will be force-cleared if they are not verified and expensed to a PTA within an appropriate time frame.

The Credit Card Transactions - Aging report has two sections based on the type of credit card.  It shows credit card transactions that have not been posted to a PTA as an expenditure.  Refer to the following screenshots. 

TCard Transactions - Aging & Outstanding

The TCard Aging & Outstanding section displays travel card transactions that have either not been applied yet to an expense reimbursement or have been applied to an expense reimbursement that has not been posted to a PTA. This report displays the transaction dollar amounts in buckets, based on their age prior to local approval or the status of their associated expense request while being processed centrally.

Use the Expanded-Action Needed view to identify transactions that have stalled because a verifier or card custodian is no longer active, identified by the relevant Employment Status Indicator column.

Credit Card Transactions Reports – PCard - Aging

The PCard Transactions Aging section displays all outstanding purchase card transactions, per the selection criteria, throughout their approval workflow utilizing age buckets. This includes PCard transactions that have not been verified.

Use the Expanded-Action Needed view to identify transactions that have stalled because a verifier or card custodian is no longer active, identified by the relevant Employment Status Indicator column.  

Travel Card Transaction Aging

Aging days are calculated as today’s date minus the end date. The end date is pulled from one of three different fields in the following order based on where it is in the expense request process:

  • SU Credit Card Posted Date after the initial purchase
  • SU Credit Card Expense End Date if it has been entered in the Expense Requests system
  • Expense Request End Date when the transaction is on a submitted expense request

For more information on the travel card transaction workflow and how it relates to the TCard Transactions Aging & Outstanding report refer to Topic Overview: Managing Aging and Outstanding Expense Transactions-Travel Card (Tcard) Transactions Aging.

 

Purchasing Card Transaction Aging

PCard transaction aging starts from the SU Credit Card Posted Date until it completes local approval. 

For more information on the purchasing card transaction workflow and how it relates to the PCard Transactions Aging report refer to Topic Overview: Managing Aging and Outstanding Expense Transactions-Purchasing Card (Pcard) Transactions Aging.

Employment Status Indicator

This value exists for both Verifier and SU Credit Card Custodian and can be either Y or N. While Y means that the person is a current employee, an N will appear for a temp worker or student worker, even if they are the valid current person in the role. Records with N values must be individually assessed to determine whether there is a valid person currently in the role.

For a list of fields available to include in report customizations, refer to Data Fields Available in ERR Dashboard. 

Displays transaction details of advances and lists any expense requests to which advances have been applied.

Launch OBI Advances

  • For a particular advance, which expense requests has it been applied to, and is there an outstanding unapplied balance to be used before another advance for that employee is created?
  • Do any of the employees in my organization have a balance on one of their advances that should be refunded?
  • Have any of the advances been force cleared and need to be journaled to their proper PTAE?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  Refer to Using Selection Criteria for OBI Reports for more guidance.

  • The Expense Request Transaction Number applies only to advances (ADV). No date is required with this selection criteria. To view expense request details, use the Expense Requests tab.
  • Expense Request Transaction Status Description is the status of the advance itself and not of any related expense requests.
  • Supplier Name is the name of the person receiving the advance.

The Advances tab displays details on all advance transactions except those that have been saved but never submitted.

  • Displays detailed visibility on advances and where they are in their approval workflows. It includes uncleared, partially cleared and cleared advances.
  • Displays expense requests to which the advance has been applied and for what amount. 
  • Shows the outstanding balance still available on the advance. 
  • Displays any advance amounts returned by the employee.
  • The outstanding advance balance will not reflect associated expense requests that have not been fully approved.

 

Advance Dates
Expense Incurred Date/Expenditure Item Date The date entered in the Expense Request system in Oracle when creating the advance.
Advance Expected Clearing Date The expected date that the travel is to be completed; it is specified when creating the advance.
Submitted Date During the creation of the advance, the date it was submitted for approval.

The Advance-Aging report displays details of advances that are not completely cleared.

  • Each amount applied from an advance to an expense report is listed on a separate line.  
  • Any unapplied amount from the advance is displayed within the appropriate aging bucket.  
  • After the advance has been fully cleared by one or more expense requests it is no longer visible on the aging report but is still available on the Advances report.

For more information on the advance and expense request workflow and how it relates to this report refer to Topic Overview: Managing Aging and Outstanding Expense Transactions-Advances Aging.

Launch OBI Advances - Aging

  • Which advances are uncleared?
  • Which advance balances are in jeopardy of exceeding 60 days?
  • Which advances have exceeded 60 days, to whom and for how much?
  • Which advances have a preparer or a supplier (person who received the advance) that is no longer in their role at Stanford?

 

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  Refer to Using Selection Criteria for OBI Reports for more guidance.

  • The Aging tab has no date prompts, thus providing visibility on all uncleared advances.
  • The Expense Request Transaction Number applies only to advances (ADV).  Expense Request Transaction Status Description is the status of the advance itself and not of any related expense requests.
  • Supplier Name is the name of the person receiving the advance.

 

Displays transaction details of advances not yet fully expensed, i.e., ones that have a remaining balance not on an expense request that has been posted to a PTA. Transactions and unapplied amounts are displayed by aging buckets.   

The advance balance is not adjusted until the expense request to which it is applied has been posted to a PTA

Use the Expanded-Action Needed view to identify advances that have stalled because a preparer or supplier (person who received the advance) is no longer active by the relevant Primary Job Status column. 

Primary Job Status

This value exists for both Preparer and Supplier and can be either Active or Inactive. While Active means that the person is a current employee, Inactive will appear for a temp worker or student worker, even if they are the valid current person in the role. Records with Inactive preparers must be individually assessed to determine whether there is a valid person currently in the role. Records with Inactive Supplier mean the person who received the advance is no longer an employee and you should submit a support request to Get Assistance with Expense Reimbursement System.

Displays advances that have been force cleared by Financial Management Services (FMS) as a result of not being fully applied to an expense request or the funds returned within 60 days of their expected clearing dates. Includes transaction details of advances that have been force cleared and all transactions associated with the original advance and the force cleared advance, including the force clear fee.

LAUNCH OBI ADVANCES - FORCE CLEARED

  • What are the advances that have been force cleared and may need to be journaled to their proper PTAE?
  • How much was charged to force clear advances?
  • How many advances were force cleared?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  Refer to Using Selection Criteria for OBI Reports for more guidance.

The Advances -  Force Cleared report has two sections.

Displays the number of advances that have been force cleared, as well as the total of the force clear fees that were charged.

Displays the advances that have been force cleared.  The report displays the following details:

  • the original advance number (e.g. ADV123456) and associated details
  • expense requests, if any, that have had that advance applied
  • the forced cleared transaction (designated with the original advance number with FC appended (e.g. ADV123456FC)
  • the forced clear transaction fee of $35
Viewing Force Cleared Transactions in other OBI ERR Dashboard Reports
  • Force cleared transactions are not visible in the Expense Requests report or Advances report.
  • The force cleared amount will be included in the Employee Advance Returned Amount column in the Advances report, along with any other employee returned amounts. 
Viewing Force Cleared Transactions in OBI Procure to Pay (P2P) AP Invoices Report
  • Force cleared transactions will have associated invoices in the Procure to Pay Reporting  - AP Invoices report.  These invoice numbers will have the advance number with FC appended (e.g. ADV123456FC).

When unused advance money is returned by the employee, the AP Invoice for that transaction is designated as the advance number with RUM appended (e.g. ADV123456RUM).

 

Listing of petty cash holders and detail of replenishment transactions.

Launch OBI Petty Cash Replenishment Transaction Detail

  • Who is the custodian for the petty cash account for my organization?
  • What reimbursements are being processed using petty cash?

To retrieve results, follow the Selection Criteria instructions near the top of the screen.  Refer to Using Selection Criteria for OBI Reports for more guidance.

The Petty Cash Replenishment Transactions report has two sections.

Displays information about the petty cash account including the petty cash fund name, custodian and funded amount for the given selection criteria.

Displays the number of petty cash replenishment transactions and the total reimbursement amount for the selection criteria entered.

The Expense Request Efficacy (ERE) Dashboard provides reporting and analysis of expense requests approval and rejection rates, rejections reasons, and expense request processing lead times and throughput to assist in effectively managing and improving expense request processing. Data is provided in tabular and graphical formats.

Refer to the  ERE dashboard  reporting page for details.

The OBI Force Clear Metrics (FCM) Dashboard provides budget units and organizations summary level reporting of university credit card transactions (PCard and TCard) and advances that have been force cleared.  This provides visibility where training or reinforcement of policy may be needed to prevent future force clear transactions. 

Refer to the Force Clear Metrics  Dashboard reporting page for details.

Non-customizable, BI Publisher listing of active, inactive and suspended (PCard & Tcard) credit cards, details about the card custodians, card holders, verifiers and approvers, transaction limit amount, last four digits of credit card number and guarantee PTA.

Refer to Topic Overview: Stanford's Purchasing Card (PCard) Program and Topic Overview: Stanford Travel Card (TCard) Program,  for more information about the university's credit card programs.

Launch OBI SU Credit Card Custodian

  • Who has credit cards for my organization, and who are the verifiers for the cards?
  • What are the guarantee PTAs for the cards within my organization?
  • Do any former Stanford employees still have active credit cards linked to my organization?
  • Which credit cards have been suspended or closed?
  • Which cards do not have a verifier with active status?

To retrieve results, follow the  instructions on the first tab. Organization Code is four characters only and can be a child org or a parent org which pulls all children orgs.

Specifying an Inactive On date will return all credit cards that were deactivated after that date, and includes credit cards that are still active. For additional information for selection criteria, see BI Publisher Reports.

The Credit Card Custodian report requires that you select one of two tabs to view the results.

Based on selection criteria, displays a list of active, inactive and suspended credit cards by the last four digits of the card numbers, and includes information about the custodian, cardholder, verifier, approver, transaction limits and guarantee PTA.

Data Download - This tab provides a downloadable data version of the Custodians - Distributed Report.  The output does not have row suppression. 

 

Name Selection Criteria:

  • SU Credit Card Holder Name is the name printed on the credit card; for department cards, it is the name of the department.
  • SU Credit Card Custodian Full Name is the person who has possession of the card. This is most relevant for department cards because they do not have a person’s name on them. For individual cards, the credit card custodian is also the credit card holder.
  • Verifier Full Name is the person who is responsible for properly documenting and recording PCard and TCard/Expense Request transactions in Oracle Financials.

PTA Selection Criteria:

  • Guarantee PTA Number is an attribute of the PCard and/or TCard used for a transaction and can be different from the transaction PTA Number.
    • For TCards, it is the PTA where charges are accumulated until they are posted as an expenditure on an expense request.
    • For PCards, it is the PTA to which charges will be force-cleared if they are not verified and expensed to a PTA within an appropriate time frame.

Job Status

This value exists for both Verifier and SU Credit Card Custodian and can be either Active or Inactive. While Active means that the person is a current employee, Inactive will appear for a temp worker or student worker, even if they are the valid current person in the role. Records with Inactive values must be individually assessed to determine whether there is a valid person currently in the role.

For a list of fields available to include in report customizations, refer to Data Fields Available in ERR Dashboard. 

Last Updated: Sep 30, 2022
Submit feedback about this page

Questions?

arrow_upward
Back to Top