Known Issues for Oracle Fusion Analytics Warehouse

Learn about the issues you may encounter when using Oracle Fusion Analytics Warehouse and how to work around them.

Topics:

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Oracle Fusion Analytics Warehouse General Issues and Workarounds

Learn about the general issues you may encounter when using Oracle Fusion Analytics Warehouse and how to work around them.

Topics:

Issue with Failed Status for Renamed Custom Dimensions

When you edit an Add Dimension step, the current and subsequent steps enter into a failed status.

To work around this issue, delete the step and create it again.

Known Issues for Oracle Fusion ERP Analytics

Oracle Fusion ERP Analytics has a number of known issues.

Topics:

Aggregation of YTD Metrics Is Incorrect in Certain Scenarios

If you're aggregating YTD metrics across ledgers for a quarter and in one ledger, the last period of the quarter isn't open, then the aggregation won't include the metrics from that ledger.

In this example, Period 1, Period 2, and Period 3 exist in Quarter 1. Ledger A and Ledger B have balances for all three periods. Period 3 in Ledger C isn't open and shows no balance.

In this example, YTD Revenue for Quarter 1 across three ledgers shows as 16500 instead of 22500. If you aggregate by Ledger or Period, you obtain the correct balance.

Quarter Period Revenue YTD Ledger Name
Quarter1 Period1 3000 Ledger A
Quarter1 Period2 7000 Ledger A
Quarter1 Period3 10000 Ledger A
Quarter1 Period1 2500 Ledger B
Quarter1 Period2 5000 Ledger B
Quarter1 Period3 6500 Ledger B
Quarter1 Period1 4000 Ledger C
Quarter1 Period2 6000 Ledger C

Issue with Latest Payables Invoice Validation Status

The Incremental run in Fusion Analytics Warehouse depends on LAST_UPDATE_DATE. For certain scenarios when the APPROVAL_STATUS column in the AP_INVOICES_ALL table is updated, Fusion Analytics Warehouse doesn't update the LAST_UPDATE_DATE. APPROVAL_STATUS is mapped to Validation status. Because the LAST_UPDATE_DATE isn't changed, the incremental run doesn't fetch those changes and transfer them to the warehouse tables.

This issue doesn't currently have a workaround.

Receivables Invoice with In Arrears Invoicing Rule and Receivables Accounting in a Future Period Displays the Incorrect Transaction and Line Amount

Until Release 22.R3, the AR Revenue subject area had distribution accounting entries for Receivables transactions that are accounted.

For transactions with the In Arrears invoicing rule, receivables accounting is generated at the end of the revenue recognition schedule. Transaction Amount and Line Amount for such transactions display the amounts based on the revenue that's recognized and the unrecognized revenue isn't included.

The AR Unaccounted Transactions functional area has been introduced in Release 22.R4. When this is activated, the AR Revenue subject areas show both accounted and unaccounted transactions as long as the transactions are Complete and the Revenue schedules are generated. Transaction Amount and Line Amount may still show incorrectly for partially accounted transactions in some scenarios when attributes such as Fiscal Period, Transaction Accounting Fiscal period (both anchored to Distribution Accounting Date), Accounted Indicator, Account Override Indicator, are used in the analysis. Partially accounted transactions are transactions having both accounted and unaccounted distributions in different periods.

This issue doesn't currently have a workaround.

Receipt Accounting Date Isn't Populated for Some of the Miscellaneous Receipt Accounting Distributions

The Receipt Accounting date for some of the Miscellaneous Receipt accounting distributions shows NULL, but the distribution for the CASH accounting class shows the date.

The workaround is to use the Receipt Distribution Accounting Date. This will have the date populated for all accounting distributions.

Accounted Raw Cost, Accounted Burden Cost, and Accounted Burdened Cost Metrics Show a Value of Zero

Accounted Raw Cost, Accounted Burden Cost, and Accounted Burdened Cost metrics in the PPM - Projects Costs subject area are used with the GL Account Combination attribute.

If the GL Account Combination attribute isn't included in the Accounted Raw Cost, Accounted Burden Cost, and Accounted Burdened Cost metrics, the Debit and Credit entries negate each other and the metric value shows as zero.

Currency Conversion Rate Type Attributes Show Rate Type ID Data Instead of the User Rate Type Value

In the Projects Costs subject area, the Currency Conversion Rate Type attributes show the Rate Type ID data instead of the User Rate Type value.

This is the expected behavior.

Aggregation of Certain YTD Metrics Is Incorrect in the GL Profitability Subject Area When the Adjustment Period Flag Is Included in the Analysis

If you're analyzing YTD metrics at a quarter or year level, and if you include the adjustment period flag as a filter or attribute, the YTD amounts gets aggregated incorrectly for the Depreciation Expenses YTD, Income Tax Expense YTD, Interest Expense YTD, Other Income YTD, Other Operating Expense YTD, R&D Expense YTD, Sales & Marketing Expense YTD, and Total Operating Expenses YTD metrics in the GL Profitability subject area.

For example, Period 1, Period 2, Period 3, and Adj Period exist in Quarter 1, and the amounts for R&D Expense YTD are as shown below. When you remove the Period attribute and view the Quarter level balance for Quarter 1, you expect to see 10,000. However, it will aggregate the amounts and show 20,000 for Quarter 1 with the Adjustment Period flag set to N, and 10,000 for Quarter 1 with the Adjustment Period flag set to Y.

Quarter Period R&D Expense YTD Adjustment Period Flag
Quarter1 Period1 3000 N
Quarter1 Period2 7000 N
Quarter1 Period3 10000 N
Quarter1 Adj Period 10000 Y

To work around this issue, don't use the Adjustment Filter flag when you're analyzing Quarter- or Year-level balances for YTD metrics.

GL Segment Value of GL Account Shows ~No Value~ If That Segment Value Is Based on a Table-Validated Value Set

If the segment value of Chart of Account is based on a table validated value set, then the Value, Name, and description attributes of that GL Segment show ~No Value~ instead of the actual values.

To work around this issue, examine the segment value using the GL Account Combination attribute.

Intracompany Records Generated for AP Invoice Payments Has Invoice-Related Attributes Populated Randomly

When an AP payment is made against multiple invoices for which SLA generates the Intracompany or Balance records to balance the accounting entries, Fusion Analytics Warehouse associates these accounting entries with attributes related to invoice numbers randomly.

In these cases, Intracompany and Balance records aren't generated specific to the invoice in Fusion Applications. Fusion Analytics Warehouse populates these entries with invoice-related attributes which is incorrect. This issue exists in the GL Account Analysis subject area, and doesn't have a workaround.

Opening Amount Doesn't Match the Closing Amount of the Prior Period in AR Aging and AP Aging Subject Areas

In the AR Aging and AP Aging subject areas, the Opening Amount doesn't match the prior period Closing amount due to unaccounted applied transactions.

This issue happens because the Closing amount is derived from the Remaining balance of the transaction in Oracle Fusion Cloud Enterprise Resource Planning, which is the amount remaining after considering all application activities. However the Activity amount is calculated in the warehouse using only the accounted transactions. Therefore, if there are application transactions that aren't accounted, these aren't included when calculating the activity amount, which impacts the Opening Amount since Opening Amount is calculated as Closing Amount - Activity Amount. To work around this issue, account all the transactions in Fusion Applications Suite and check the amounts after an incremental run.

Invoice Validation Status Filter Attribute Causes Data Validation Error

When you validate the data of the Total Transaction Amount metric in the AP Invoices subject area, and use the Invoice Validation Status filter attribute, a SOAP SERVER ERROR occurs.

This issue occurs in the Fusion Applications Suite versions 22A and 22B.

To work around this issue, don't select the Invoice Validation Status filter in the Data Validation of Total Transaction Amount metric of the AP Invoices Subject area. However you can choose this as a pivot attribute.

Incorrect Values for Header Released Amount and Line Released Amount Metrics in the Agreement Subject Area

The Header Released Amount and Line Released Amount metrics in the Agreement Subject Area shows incorrect values due to an error in identifying when the agreement was last updated.

To work around this issue, reset the data pipeline for the Purchase Agreement functional area every weekend. See Reset a Data Pipeline for a Functional Area.

Detail Line Number in the AR Revenue Subject Area is Incorrect

The detail line number in the AR Revenue subject area shows the same value as the parent line number.

This issue doesn't have a workaround.

Data Validation in Procurement Isn't Working

As part of the Procurement activation plan for Oracle Fusion ERP Analytics and Oracle Fusion SCM Analytics in 22.R3, some granular functional areas are deprecated and a new Purchasing functional area is added. Data validation in the procurement area only work with the new Purchasing functional area.

To work around this issue, first activate the new Purchasing functional area. See Activate a Data Pipeline for a Functional Area.

The following granular functional areas are supported in 22.R3 and will be deprecated in a future release:

  • Purchase Agreement
  • Purchase Order
  • Purchase Receipt Requisition

Revenue Metrics with Bill Plan Attributes are Incorrect

Revenue metrics show an incorrect value when bill plan attributes are added.

There's a missing join with the Bill Plan ID in the Revenue fact which causes is a Cartesian join. To workaround this issue, avoid using Bill Plan attributes when analyzing Revenue metrics.

Project Attribute Columns Show Null in Sales Order Fulfillment Lines

Project attribute columns show a null value in Sales Order fulfillment lines.

Duplicate records are created when updating project attribute. To avoid incorrect data, project attribute columns are now populated with null values. There is no workaround for this issue.

GL Account Combination Not Populated for Some Accounting Distributions in AR Revenue and AR Transactions

The AR Unaccounted Transactions functional area has been introduced in Release 22.R4.

When this is activated, the AR Transactions and AR Revenue subject areas show both accounted and unaccounted transactions as long as the transactions are Complete and the Revenue schedules are generated. For the unaccounted transactions and distributions, GL Account Combination isn't populated with the account string and shows a default value as "~NOVALUE~". There is no work around for this issue.

Data Augmentation Doesn't Work for the AR Aging Subject Area

Data augmentation isn't supported for the AR Aging subject area currently.

To work around this issue, if you need any additional attributes, then try to add the attributes to the AR Transactions subject area and use it through cross-subject area analysis.

Known Issues for Oracle Fusion SCM Analytics

Oracle Fusion SCM Analytics has this known issue.

Topics:

Incorrect Values for Header Released Amount and Line Released Amount Metrics in the Agreement Subject Area

The Header Released Amount and Line Released Amount metrics in the Agreement Subject Area shows incorrect values due to an error in identifying when the agreement was last updated.

To work around this issue, reset the data pipeline for the Purchase Agreement functional area every weekend. See Reset a Data Pipeline for a Functional Area.

Data Validation in Procurement Isn't Working

As part of the Procurement activation plan for Oracle Fusion ERP Analytics and Oracle Fusion SCM Analytics in 22.R3, some granular functional areas are deprecated and a new Purchasing functional area is added. Data validation in the procurement area only work with the new Purchasing functional area.

To work around this issue, first activate the new Purchasing functional area. See Activate a Data Pipeline for a Functional Area.

The following granular functional areas are supported in 22.R3 and will be deprecated in a future release:

  • Purchase Agreement
  • Purchase Order
  • Purchase Receipt Requisition

Project Attribute Columns Show Null in Sales Order Fulfillment Lines

Project attribute columns show a null value in Sales Order fulfillment lines.

Duplicate records are created when updating project attribute. To avoid incorrect data, project attribute columns are now populated with null values. There is no workaround for this issue.

Sales Credits Data Deleted in Fusion Applications Continues to Show in Fusion Analytics Warehouse

Sales Order Sales Credits records deleted from the Fusion Applications source continue to appear in Fusion Analytics Warehouse.

This scenario shows data mismatch between the Fusion Applications and Fusion Analytics Warehouse. This would be reintroduced once the issue is fixed in the Fusion source application.

To work around the issue, reset the warehouse (see Reset the Data Warehouse) and reload the data pipeline (see Reload a Data Pipeline for a Functional Area).

Supplier and Supplier Site Columns Show Null Value in Back-to-back Sales Order Fulfillment Lines

Supplier and Supplier site columns show null value in the Back-to-back Sales Order fulfillment and Supply lines.

Duplicate records were being created in the Back-to-back Sales Order scenarios that have multiple POs with multiple Supplier and Supplier Sites for the same Supply Tracking Line. To avoid incorrect data, the Supplier and Supplier Sites columns are being populated with null values.

There is no work around for this.

Known Issues for Oracle Fusion CX Analytics

Learn about the issues you may encounter when using Oracle Fusion CX Analytics and how to work around them.

Topics:

Data Deleted in Fusion Application Shows in Fusion Analytics Warehouse

When records such as Opportunity, Revenue Line. etc., are deleted in the source Fusion Applications. the deleted objects aren't deleted from Fusion Analytics Warehouse.

This scenario shows a data mismatch between Fusion Applications and Fusion Analytics Warehouse.

To work around the issue, the reset the warehouse (see Reset the Data Warehouse) and reload the data pipeline (see Reload a Data Pipeline for a Functional Area).

Activity Count Shows an Incorrect Value When Any Recurring Appointment Changes

When a recurring meeting is updated, for example increasing or decreasing the number of recurrences or other changes, then the Last Update Date column isn't updated in the Activity and the Activity Resource tables.

The Incremental run in Fusion Analytics Warehouse depends on Last Update Date. Because the date isn't changed, the incremental run doesn't fetch those changes and transfer them to the warehouse tables.

To work around the issue, the reset the warehouse (see Reset the Data Warehouse) and reload the data pipeline (see Reload a Data Pipeline for a Functional Area).

Revenue Line Amount Shows an Incorrect Value When Quantity, UnitPrice, and Revenue Amount Updates with the Addition of a Split Line

When a Revenue Line is Split, and Quantity, Unit Price, and Revenue Amount are also updated at the same time and saved, the Last Updated Date doesn't update, so the updated Revenue Line related details aren't read by the warehouse.

The Incremental run in Fusion Analytics Warehouse depends on Last Update Date. Because the date isn't changed, the incremental run doesn't fetch those changes and transfer them to the warehouse tables.

To work around the issue, the reset the warehouse (see Reset the Data Warehouse) and reload the data pipeline (see Reload a Data Pipeline for a Functional Area).

Incorrect Subscription MRR When the Field is Manually Edited in Fusion Applications

Subscription Product line details page may have the MRR field exposed from the Fusion Applications Composer.

The MRR field should be a read-only field, however it's editable, which is the issue. If the values of these fields change, then the CX - Subscription Historical Trend subject area shows an incorrect value.

For example, if a Customer has two subscriptions with MRR of $300 each, the trend would show as: 
||Period||MRR|| 
|Jan-2022|$600| 
|Feb-2022|$600| 
|Mar-2022|$600|
In the month of March 2022, if the user updates the MRR value to $400 for one of the subscriptions (which shouldn't be possible since it's a derived value), here's what one would expect to see and would actually see:
 ||Period||MRR (Expected to see)||MRR (would show up)|| 
|Jan-2022|$600|$700| 
|Feb-2022|$600|$700| 
|Mar-2022|$700|$700|

There isn't currently a workaround.

Issue with Custom Fixed Choice List, Custom Dynamic Choice List, and CLOB Extension Attributes

The custom attributes created for an object are added to the warehouse using the Data Augmentation feature.

For the custom fields of type Fixed Choice List (FCL), Dynamic Choice List (DCL), CLOB, the field labels don't show up.

To work around this issue:
  1. Add the column to the dimension using data augmentation.
  2. Create a new logical column based on step 1 using a semantic model extension.
  3. Hide the column created in step 1 using the semantic model extension security framework.

Note:

Use the Oracle Fusion Cloud Sales Automation Application Composer Confiuration Report for information about customer fields, their physcial column names, and their labels. See How to View Application Composer Changes in Cloud Customizing Sales.

INDUSTRY_CLASS_CATEGORY Field Shows Old Value

The INDUSTRY_CLASS_CATEGORY field populates when a new Lead is created and the value is set in the profile option: MOT_INDUSTRY_CLASS_CATEGORY.

When this profile option changes, and an existing Lead with an old Industry Classification value updates, the database still saves an incorrect older code against the INDUSTRY_CLASS_CATEGORY.

This issue doesn't currently have a workaround..

Subscription Invoice Amount Shows Incorrect Value After Changes

A subscription invoice amount may show an incorrect value when changes are made to the invoice after it's first generated.

When the billing lines are updated in existing subscriptions invoices, however the last updated date doesn't change in the system. Therefore, the changes aren't updated in the warehouse.

To work around the issue, the reset the warehouse (see Reset the Data Warehouse) and reload the data pipeline (see Reload a Data Pipeline for a Functional Area).

Corporate/CRM Currency May Show Old Corporate Currency Code

If the corporate or CRM currency is changed in Fusion Applications, then the data created with the older corporate currency continues to show values with the original corporate currency code in Oracle Fusion CX Analytics.

For example, you create opportunities in Oracle Fusion Cloud Sales Automation with the corporate currency of US dollars. If the corporate currency changes to euros, and the Oracle Fusion CX Analytics report uses facts from the CX Currency folder, then Oracle Fusion CX Analytics shows older opportunities in US dollars and newer opportunities in euros.

To work around this issue, set the analytics currency in Fusion Analytics Warehouse to the same currency as the corporate currency in Fusion Applications, and you can use the facts from the analytics currency folder. This ensures the currency is consistent between applications. See Set Up the Pipleine Parameters.

Renewed Subscriptions Many Not Show Renewed Date

When a subscription is renewed, thereby creating a new subscription, the last updated date for the subscription doesn't change.

Because the updated date isn't captured, the warehouse doesn't show the Renewed Date accurately even though the subscription was created by the renewal process.

To work around the issue, the reset the warehouse (see Reset the Data Warehouse) and reload the data pipeline (see Reload a Data Pipeline for a Functional Area).

Subscription Historical Trend Subject Area Aggregate Date May Show Incorrect Values

In the Subscription Historical Trend subject area, the Aggregate Date dimension may show incorrect month-week-date column values when pulled in to the same report.

The Aggregate Date dimension specifies the date/week/month/year time interval over which the Subscription data has been aggregated. You can see the Active MRR (as an example) over the past 30 days or 52 weeks or 12 months etc.

When the month and date are added in the same report (not an intended use case), the date values may show incorrect data.

For example, the Subscription Aggregate Date has a value of 31/01/2021 12:00:00 AM, but the Subscription Aggregate Month has a value of 2021/02.

This is caused by the week rolling over to the month based on the join criteria: Week_End_Date = Month_Start_date.

For example: 
Week_code = '2021 Week14' 
period_start_date = 28-MAR-21 
period_end_date = 03-APR-21 
month_code = '2021 / 04' 
quarter_code = '2021 Q 2'

This issue occurs when the week spans two months and the week isn't a starting or end week of the corresponding year.

To work around this, don't use multiple time levels in the same report for the Aggregate Date dimension, because this date dimension analyzes the aggregated Subscription trends data for a specific time level, and isn't recommended for other time dimensions when aggregating data at multiple time levels.

Subscription Historical Trend Subject Area Inaccurately Shows Subscriptions as Active

If the ESS job to update the subscription status is run after the Oracle Fusion Analytics Warehouse incremental job, an expired subscription may show as Active in the Subscription Historical Trend subject area.

To avoid this issue, schedule the ESS job prior to the Oracle Fusion Analytics Warehouse incremental run.

If the data shows incorrectly, reset the warehouse (see Reset the Data Warehouse) and reset the data pipeline (see Reset a Data Pipeline for a Functional Area).

Customers with Existing Subscriptions Show as New Customers in Subscription Reports

The initial extract date (IED) defined in Oracle Fusion Analytics Warehouse determines the data extract date from the Oracle Fusion Cloud Applications Suite. If transactions occurred before the initial extract date and are still active, they might not be captured.

For example, if a customer ordered a 3 year subscription for 1 Jan 2020 to 31 Dec 2022, and the initial extract date is set as 1st Jan 2021, then the subscription won't be captured in Oracle Fusion Analytics Warehouse unless you update the data. If the same customer orders another subscription on 1 Aug 2021, it becomes the first subscription in Oracle Fusion Analytics Warehouse for this customer and the application erroneously marks the transaction as a new Customer. You need to be sure to select the correct initial extract date before extracting data into the warehouse.

To work around this issue, run an ESS job before initiating the Oracle Fusion Analytics Warehouse incremental run. If the data still shows up incorrectly, reset the data warehouse (see Reset the Data Warehouse) and refresh the data pipeline (see Refresh a Data Pipeline for a Functional Areawould need to be [reloaded|https://docs.oracle.com/en/cloud/saas/analytics/fawag/reload-data-pipeline-functional-area.html]).

Reset the Warehouse and Reload the Data if Existing Security Conditions in an Access Group are Modified

Whenever any new security condition is setup, Oracle Fusion Analytics Warehouse reads the data from Oracle Fusion Cloud Applications and applies the same security condition to the data.

If the existing security conditions are modified, the previous security conditions data may persist and provide an incorrect outcome. For example, if there is a security condition to grant a user access to all the Opportunities in EU region, then Oracle Fusion Analytics Warehouse copies over all the Opportunity Ids for EU region against that security condition. If the same condition is updated in Fusion CX Sales, to restrict the data to Opportunities only in Germany, then the new Opportunity IDs belonging to Germany (for this security condition) gets copied over. But the previous Opportunity IDs also exist in the system thereby giving an incorrect data security result.

To work around this issue, reset the data warehouse (see Reset the Data Warehouse) and refresh the data pipeline (see Refresh a Data Pipeline for a Functional Area.