| Oracle® Retail Merchandising Implementation Guide Release 14.1 E56350-01 |
|
 Previous |
 Next |
This chapter is an overview of Oracle Retail Sales Audit (ReSA).
The following information is maintained in the ReSA application.
Oracle Retail Sales Audit (ReSA) contains a set of system options that is different from the RMS system options set. These system options control functionality in ReSA. One of the important system option parameters is the balancing level. The balancing parameter could be Cashier or Register. If the balancing parameter is Cashier, the totals are balanced for each cashier. If the balancing parameter is Register, the totals are balanced for each register. Another important option is the unit of work. This determines whether transactions are exported prior to the elimination of all errors for the store/day. Other parameters include defining the escheatment party and the details of the clearinghouse. Certain business rules like duplicate and missing transaction number checks are also controlled through the system options setting.
ReSA requires a certain amount of foundation data to start working. ReSA shares some of its foundation data with RMS, while the rest of the foundation data needs to be maintained in ReSA.
Foundation data in ReSA includes company/location close dates, location traits, bank setup, tender types, reference maintenance, error codes and store-specific foundation data.
ReSA allows the retailer to define the Totals needed for their business. Totals in ReSA can be a ReSA-calculated value from raw transaction data or a total that comes from the POS/OMS through the RTLog. ReSA calculates a total based on raw transaction data or on existing totals. Totals are used for performing store balancing over/short analysis within ReSA. Totals are also used to create data for external systems such as General Ledger. By assigning an audit rule to the total, business validation is built in ReSA. For example, the retailer defines a ReSA-calculated total of total cash tendered at a register for a store/day. He defines another total, a POS/OMS-declared total, for the total cash declared at the register for a store/day. He defines an audit rule to compare both the totals for over/short analysis. Totals are used to export consolidated data to an external system. So, while defining a total, the retailer defines the systems to which the total is exported.
Rules are used in ReSA to perform custom data validation against transactions and totals. Audit rules run on POS/OMS transaction data and totals during the automated and interactive audit process. When the rule is broken, an exception error is thrown that must be edited or overwritten by the auditor. ReSA comes with some standard pre-configured rules and also provides flexibility to the retailers to define rules needed for their business.
Error codes provide information to the auditor about the type of error and the remedial action needed to solve the error, thus increasing the effectiveness of the audit process. When setting up audit rules for automated audit process, an error code is associated to the rule. The error code contains an explanation of why the rule failed, as well as a recommended solution. The error code also contains security settings to determine if the error can be overridden at the store or headquarters. When a rule fails, the error code is available to the auditor in the error list. Additionally the specific location where the error has occurred is available in the transaction details, thus helping the auditor to quickly understand and correct the error.
Automatic auditing is done in ReSA using batch programs. The goal of the automatic audit process is to accept transaction data from point-of-sale (POS/OMS) applications and move the data through a series of processes that culminate in clean data. ReSA uses several batch-processing modules to perform the following activities:
Import POS/OMS transaction data from the RTLog.
Perform initial validation of data during upload of data from the RTLog to ReSA database.
Produce totals using user-defined totaling calculation rules that are user reviewable during the interactive audit.
Validate transaction and total data with user-defined audit rules and generate errors whenever data does not meet the criteria. The user reviews these errors during the interactive audit.
Create and export files of clean data in formats suitable for transfer to other applications.
Update the ReSA database with adjustments received from external systems on previously exported data.
Auditors use the interactive audit process to view and correct errors. This process is done after the automated audit is completed. This process allows the auditors to view errors at summary or detail level, fix or override errors, update the totals and close the store/day. In addition, it is also possible to review and edit data of missing transactions or transactions that have passed automated audit, add transactions and delete invalid or missing transactions.
ReSA provides summary views for the auditor to identify and fix the problem areas quickly. A Store/Day Summary View screen contains the following information about a store/day: The audit status, the data status, the number of transactions, the number of errors and the over/short amount. The auditor has access to other options in the Store/Day Summary screen such as: The error list, the balancing level summary, over/short, miscellaneous totals, missing transactions and the import/export log.
ReSA provides two other summary views: Tender Summary and Item Summary.
Automated Clearing House (ACH) is a U.S.-based banking network used to electronically transfer funds. Retailers use ACH to enable them to have access to funds before the funds have been physically deposited in the bank. This is done by estimating the following day's bank deposit and sending this amount to the consolidating bank through the ACH network. In this way, the cash to be received from the stores is hedged.
Escheatment is the process of forwarding monies of outstanding, non-expiring vouchers to the proper government authorities (state or country) after a defined period of time from the date of issuance. Some government authorities require that unredeemed vouchers be escheated after a specific period of time has passed. When a voucher is escheated, an invoice is generated that initiates payment of the escheated voucher amount to the government authority. The government authorities then attempt to locate the consumers owed the monies.
To accommodate Escheatment, a new total should be added to Sales Audit to create escheatment totals. ReSA automatically totals sales transactions based on calculation definitions set up for the total.
The audit trail functionality provides the store and headquarters employees with the capability of tracking all changes to transactions and totals. ReSA maintains versions of all modified transactions thus enabling easy tracking of changes.
Totals for General Ledger that are impacted by a revised transaction are reversed and both the reversal and the new total are extracted for the General Ledger.
Oracle Retail Sales Audit interfaces with the following Oracle products:
Oracle Retail Merchandise System
Store Inventory Management
Oracle Retail Invoice Matching System
Retail Analytics
This figure displays the ReSA interfacing products:
Oracle Retail Sales Audit also interfaces with the following third-party applications:
Automated Clearing House.
Universal Account Reconciliation System.
ReSA and RMS share the same database. ReSA shares some of its master data with RMS. Foundation data such as items, stores, company/location close dates, location traits, bank setup, and tender types are maintained in RMS and used in ReSA.
Current reference data is retrieved from RMS into ReSA by the batch program SAGETREF. The data is extracted into multiple data files. The data in the files are used by the batch program SAIMPTLOG as reference data for doing validation checks on the POS/OMS transaction data during the data upload from POS/OMS to ReSA. Having the reference in data file formats increases the performance of the SAIMPTLOG process. SAGETREF generates the following reference files: Items, Wastage, Sub-transaction level items, Primary variant relationships, Promotions File, Currency File, Warehouse File, Inventory Status File, Variable weight PLU, Store business day, Code types, Error codes, Store POS, Tender type, Merchant code types, Partner vendors, Supplier vendors, Employee IDs, Banner IDs.
All clean and audited sales and returns data is extracted from ReSA into a POSU file by the batch program SAEXPRMS. All corrected sale and return transactions that do not have RMS errors are extracted into the file. The sales audit system options parameter work unit controls the export of data into file in case of presence of RMS errors in the POS/OMS transaction data. The shell scripts UPLOADSALES.KSH and SALESPROCESS.KSH load data from the POSU file into the RMS tables.
Sales, returns and other transaction data are loaded into ReSA from the Point-of-Service and Order Management System application. These applications should provide a standard RTLog file. The RTLog data is loaded into ReSA either in trickle mode or once a day. If the data is uploaded in the trickle mode, then corporate inventory reflects a more accurate intra-day stock position. The data from the RTLog is loaded into ReSA using the batch program SAIMPTLOG for end-of-day. If trickle processing is used the final RTLog for the day must include a count of all RTLog files for the store/day.
In the normal course of business, payments are made to vendors at the store level. Payments for merchandise purchases done at store level are booked against a corresponding merchandise invoice. Payments of non-merchandise purchases or miscellaneous services availed at the store are booked against a corresponding non-merchandise invoice. These transactions are passed from the POS/OMS to ReSA as specially designated PAID OUT transactions (sub-transaction type of EV - Expense Vendor or MV - Merchandise Vendor). All these invoices are assumed paid. The batch program SAEXPIM transfers the PAID OUT type of transactions to the Invoice Matching staging tables.
The batch program SAEXPIM is also used for escheatment processing. Unclaimed monies of outstanding, non-expiring vouchers are totaled after a defined period of time from the date of issuance of the voucher and posted to the Invoice Matching staging tables as a non-merchandise invoice by SAEXPIM. The unclaimed amount is paid out as income to the issuing Retailer. In some U.S. states, it is paid out to the state (based on configuration). ReSA determines who receives this income and accordingly posts a non-merchandise invoice for the partner. These invoices are assumed not paid.
The batch job EDIDLINV is used to extract the invoices from the Oracle Retail Invoice Matching (ReIM) staging tables and load as EDI invoices to ReIM.
The batch program SAEXPGL transfers the sales data from ReSA into the financial staging tables in RMS. This batch program executes only if the external financial system is set to O (for other), E-Business Suite, or some other external financial application based on system options configuration.
SAEXPGL directly inserts the data into financial stage tables of RMS.
ReSA determines the estimated bank deposit for each store/day. The batch program SAEXPACH posts the store/day deposits into a database table and creates the standard ACH format file. The output file is sent to a Clearing House. The output file conforms to the requirements imposed by the National Automated Clearing House Association (NACHA). The nature of the ACH process is such that as much money as possible must be sent as soon as possible to the consolidating bank. Any adjustments to the amount sent can be made front-end. This batch assumes that there is only one total to be exported for ACH per store/day.
The batch program SAEXPUAR extracts specified TOTALS to a flat file that is interfaced to an account reconciliation application. For each store day, all specified totals are posted to their appropriate output files. All the stores and totals with usage type starting with UAR are exported.
ReSA sends audited data to SIM which helps SIM to be synchronized with RMS with respect to inventory levels. The batch program SAEXPSIM extracts information from transactions with changed item quantities, item deletions, item addition, change in item status to VOID, and change in transaction status to PVOID. This information in the form of a file (SIMT) is uploaded and processed by SIM.
Access to ReSA and access to stores an auditor can take action against, is controlled by privileges available to the user's application role and RMS data level security.
To access ReSA, the user must be mapped to one of the available ReSA roles. There are four default application roles:
Sales Auditor
Sales Auditor Manager
Finance Manager
Administrator
Each of these roles have multiple privileges attached to them. The privileges are defined at granular level and restrict access to a particular screen, or access to take specific audit action, or access to view specific fields. The privileges get directly assigned to the user once a user is mapped to the ReSA roles. A user can be assigned multiple roles.
ReSA shares the database instance with RMS. RMS location level data security is also applied to ReSA users. The location level security is assigned to every ReSA user. This controls the Organization Hierarchy locations the user has access to.
|
Note: RMS also supports Item and Merchandise Hierarchy level data security to restrict user access to specific products. Item level security is not applicable for ReSA. |
Oracle Retail Sales Audit (ReSA) Operational Insights dashboards and reports provide pervasive Business Intelligence. To provide a seamless user experience, they are designed to be embedded in a single sign on environment within the ReSA ADF application.
ReSA Operational Insights dashboards and reports have integrated data sources, including Oracle Retail Merchandising System (RMS) for foundation data and ReSA for sales audit transactional data. The standard reporting tool for ReSA Operational Insights dashboards and reports is Oracle Business Intelligence Enterprise Edition (OBI EE).
Using OBIEE 11g, rich metadata layer is created hiding the complexities of the base transactional systems
The reports and dashboards are created using OBIEE Answers and embedded into ReSA ADF screens. The ReSA Operational Insights dashboards and reports provide the ability to drill to lower level of detail and launch ReSA screens to execute tasks thus enabling actionable, and close loop BI.
The contextual BI reports in ReSA screens provides additional contextual insights related to the primary information displayed in the main dashboard report or in the contextual pane of a ReSA screen. The pervasive contextual BI reports give an auditor additional insight into the data that they see in a dashboard or ReSA UI screen to make better decisions and drive efficiencies in the sales audit process.
The contextual BI reports for ReSA screens other than the main dashboard screen appear in an expandable pane to the right of the main ReSA screen.
This section covers the following topics:
This section provides a list of factors that should be taken into account when making sizing plans.
There are two major hardware components that make up the ReSA Operational Insights dashboards and reports physical environment:
Middle Tier Application Server - The middle tier application server hosts software components such as Oracle WebLogic Server and Oracle Business Intelligence Enterprise Edition (EE) or Oracle Business Intelligence Standard Edition One (SE One).
Database - The Oracle Database stores large amounts of data that are queried in generating Oracle BI reports. The report query processing is heavily dependent on the hardware sizing decision. Operational Reports are a light reporting solution which leverages the RMS/ReSA database schema and directly reports off it.
Sizing is customer-specific. The sizing of the ReSA Operational Insights dashboards and reports application is sensitive to a wide variety of factors. Therefore, sizing must be determined on an individual installation basis.Tthe DB sizing will be driven mostly by ReSA requirements for they are related to DB hardware.
Testing is essential as with any large application. Extensive testing is essential for determining the best configuration of hardware.
The following factors must be considered for sizing:
Application Server
Report Complexity - Reports processed through Oracle BI can range from very simple one-table reports to very complex reports with multiple-table joins and in-line nested queries. The application server receives data from the database and converts it into report screens. The mix of reports that will be run will heavily influence the sizing decision.
Number of Concurrent Users - The Oracle Retail Sales Audit (ReSA) Operational Insights dashboards and reports embedded in ReSA are designed for multiple concurrent use. When more users are running reports simultaneously, more resources are necessary to handle the reporting workload. For more details on Clustering and Load Balancing, see the Oracle Business Intelligence Enterprise Edition Deployment Guide.
Hardware Architecture
Number and Speed of Processors - More and faster processors speed report query processing in the database. The application server needs fewer resources than the database.
Memory - More memory enables a larger SGA in the database and will reduce the processing time for report queries.
Network - Since the data from the report queries needs to go from the back-end database to the application server, a faster network is better than a slower network, but this is a relatively low priority.
The Operational reports for ReSA can be divided into following 2 categories when accessed through the ReSA screens.
The Dashboard Reports - The dashboard surfaces information in a manner that will help users, sales auditors, finance managers, etc, prioritize their day-to-day activities as well as quickly identify areas of concern. The dashboard allows a user to look at a consolidated view of their to-dos and then directly and contextually launch into the corresponding ReSA screens to take an action thus enabling actionable and closed loop BI.
Contextual BI Reports - Contextual BI Reports are displayed in the contextual pane of the ReSA screens. Contextual BI reports provide additional in context insights to the data being viewed in the ReSA screen. This kind of pervasive BI reports enable users to take quicker and more informed actions thus driving workforce efficiencies.
See the Oracle Retail Sales Audit (ReSA) Operational Insights Reports User Guide.
|
Note: The ReSA Operational Insights dashboard can be accessed in a standalone OBIEE environment. Use of the Operational Insights contextual reports in standalone OBIEE is not supported due to dependencies on ReSA input parameters. |
ReSA Operational Insights dashboards and reports provide pervasive Business Intelligence when implemented in a Single Sign-On environment. To provide a seamless user experience, they are designed to be embedded within the ReSA ADF application.
|
Note: The Single Sign-On (SSO) implementation for Oracle Retail Sales Audit (ReSA) Operational Insights dashboards and reports is mandatory in production environments because it has contextual BI reports and in context launches into ReSA screens apart from dashboard reports. Because accessing the Operational Insights reports from the ReSA UI in the absence of SSO poses a security risk, the use of integrated Operational Insights reports in RESA UI without SSO is not supported in this release. In the absence of SSO, the ReSA Operational Insights dashboard can be accessed in a standalone Oracle Business Intelligence Enterprise Edition (OBIEE) environment. The use of the Operational Insights contextual reports in a standalone OBIEE environment is not supported due to dependencies on ReSA input parameters. |
For details about security configuration and implementation, the Oracle Retail Merchandising Operations Management Security Guide.
Internationalization is the process of creating software that can be translated more easily. Changes to the code are not specific to any particular market. ReSA Operational Insights dashboards and reports has been internationalized to support multiple languages.
|
Note: ReSA Operational Insights dashboards and reports uses ISO codes for all the supported languages. ReSA Operational Insights dashboards and reports will look up RMS language codes. If, in the case a language supported by ReSA Operational Insights dashboards and reports is not available in the source system, then the Primary language of RMS will be used. |
This section describes configuration settings and features of the software that ensure that the base application can handle multiple languages.
Translation is the process of interpreting and adapting text from one language into another. Although the code itself is not translated, components of the application that are translated may include the following:
Graphical user interface (GUI)
Data translations for Item description, Store name, Tender Type Group
Report titles
The user interface for Oracle Retail Sales Audit (ReSA) Operational Insights dashboards and reports has been translated into:
Chinese (simplified)
Chinese (traditional)
Croatian
Dutch
French
German
Greek
Hungarian
Italian
Japanese
Korean
Polish
Portuguese (Brazilian)
Russian
Spanish
Swedish
Turkish
Operational Insights Dashboards and reports displays the reports in the same language as ReSA by accepting the Lang parameter from the ReSA system. However the locale setting are independent of the locale setting in ReSA. The language and Locale can be set for a user using the My Account OBIEE preferences as shown below. The language setting in OBIEE My Account preferences is however overwritten by the Lang parameter passed from ReSA once the reports are accessed from within ReSA (embedded in ReSA).
ReSA Operational Insights dashboards and reports is supported in 18 languages. This section provides details of various scenarios that may come across during implementation.
Since multi-language data support in ReSA Operational Insights is dependent on the availability of the multi-language data in the source system, it is important to understand various scenarios the user may encounter. Before proceeding review the following facts about multi-language support:
ReSA Operational Insights dashboards and reports programs extracts multi-language data from source systems.
Depending on the implementation, the source system may or may not have data for particular supported language(s). For example, RMS supports Item Descriptions in multiple languages but the item's description may not be available in the translated languages.
For source system released languages, see the Oracle Retail Merchandising System Operations Guides.
Scenario 1
All the supported languages are implemented in ReSA Operational Insights dashboards and reports and are the same set of languages that are supported in the source system as well.
Multi-lingual data sets are enabled in both ReSA Operational Insights and the source system.
Data Scenario 1a
Translated data exists for all records in Source System: This is an ideal scenario where the source system supports data for the same set of languages as ReSA Operational Insights and data for the required column exists in all the languages in the source system.
In this scenario the attributes that are supported for multi-languages get all the multi-language data in ReSA Operational Insights.
Data Scenario 1b
Translated data does not exist for some of the records in the source system.
For the attributes for which data is not available in the source system, ReSA Operational Insights dashboards and reports will display the attribute in source system primary language. For example, Operational Insights dashboards and reports requests data in German and English languages. In RMS, the Item Attribute description is not available in the German language but is available in English language.
ReSA Operational Insights dashboards and reports will display Item description in English to a user who is logged into Oracle BI EE (assuming English is the primary language of RMS for that implementation).
ReSA Operational Insights supports both primary currency and local currency.
The Operational insights reports support this in the following way.
For the following reports where amounts are aggregated across stores, if the auditor has stores assigned that have varied local currencies, the amounts are displayed in primary currency only. If all auditor stores have the same common local currency, the amounts are displayed in local currency.
Over/Short Summary Report on Dashboard
Over/Short History Report on Store Day Search Screen
For the following reports where amounts are displayed for a single store selected in the ReSA screen, the values are displayed in the currency selected in the currency toggle of the corresponding ReSA screen (Primary or Local). On screen launch, Local Currency is the default.
Cashier/Register Over Short Report on Store Day Summary Screen
Tender Summary Report on Tender Summary Screen
ReSA Operational Insights dashboards and reports is a light weight reporting solution and provides efficient access to operational data through the delivered pre-defined reports and dashboards which are embedded in ReSA application ADF User Interface. For any transactional reporting solution, including ReSA Operational Insights, smart decisions on how to implement and run your operational reporting system will ensure that you are getting the most out of it. This section contains information that will help you get the best performance out of ReSA Operational Insights and identifies common contributors that can weaken performance, as well as best practices that will ensure ReSA Operational Insights is running in the most optimal manner. All implementations are unique and the factors that are beneficial for one implementation may not have the same effect for all the implementations. It is a good practice to test several settings/approaches for the factors and recommendations listed below and use the ones that work best for your environment. The factors listed in this chapter are the key factors that impact performance but no absolute values or settings can be provided for implementation purposes due to the uniqueness of each environment. ReSA Operational Insights includes Oracle Business Intelligence (OBI EE) for analytic reporting purposes. The recommendations in this section will focus on front end (OBIEE) components of ReSA Operational Insights dashboards and reports.
Based on the complexity of the report, OBIEE sometimes generates complex SQL, causing the Oracle Database to pick a less than optimized execution plan. In order to avoid this scenario, it is recommended that the SQL Plan Baseline functionality of the Oracle 11gR2 be enabled (it is disabled by default). For more details see the Oracle 11gR2 Performance Tuning Guide.
Operational reporting queries sometimes require retrieval of large amounts of data. Since ReSA Operational Insights dashboards and reports are embedded within ReSA screen, thus all caching is disabled at installation time. This enables any change to data in ReSA to be immediately reflected in the reports. For example when the user updates the item quantity for a particular store, the status of the store changes from partially loaded to fully loaded. Hence, to reflect this change immediately it is essential that the OBIEE cache is disabled. However if the implementation does not require real time data updates for effective usage of ReSA Operational Insights then caching can be powerful performance enhancement technique.
The Oracle BI server can save the results of a query in cache files and then reuse those results later when a similar query is requested. Using the middle-tier cache permits a query to be run one time for multiple requests of a report and not necessarily every time the query is run. The query cache allows the Oracle BI Server to satisfy many subsequent query requests without having to access back-end data sources (such as Oracle database). This reduction in communication costs can dramatically decrease query response time.
To summarize, query caching has the following advantages only when the same report is run repeatedly:
Improvement of query performance
Less network traffic
Reduction in database processing and charge back
Reduction in Oracle BI server processing overhead
For more details on caching see the Oracle BI EE System Administrator's Guide.
Data Base Configuration/Partitioning strategy/ Purging and Archiving Strategy
ReSA Operational Insights dashboards and reports is built on ReSA/RMS database which is based on Oracle Database 12c Enterprise Edition Release 12.1.0.1.4 and must be optimized and configured for a retailers' needs. See the Oracle Retail Merchandising Implementation Guide for further information.
Adequate Hardware Resources
For more information, see Setup and Configuration.
ReSA Operational Insights dashboards and reports provide pervasive Business Intelligence. To provide a seamless user experience, they are designed to be embedded within the ReSA ADF application. Ad-hoc creation of reports and dashboards in a standalone OBIEE environment is not supported. Changes to existing ReSA Operational Insights dashboards and reports are subject to standard customization support policies. Any customizations made should follow an extensive analysis to ensure no performance impacts to transactional systems users.
Listed below are recommendations that will help you in maintaining ReSA Operational Insights dashboards and reports code:
Naming convention: It is recommended that you use a good and consistent naming convention when customizing ReSA Operational Insights dashboards and reports code or building new code in the ReSA Operational Insights dashboards and reports environment.
As a best practice, keep all the documentation up-to-date for capturing any changes or new code that has been developed at a site.
While creating custom reports, refer to the following guidelines:
Report developers should be trained in Oracle BI to learn how to design reports in the most optimal manner.
Design reports at the highest level possible and allow drill down to more detailed levels when required.
Design reports in a manner that allows multiple users to utilize a single report output rather than multiple users running the same report. A best practice is to run one report and distribute that report to multiple users. For more information on how to distribute reports, see the Oracle Business Intelligence Enterprise Edition User Guide and the Oracle Business Intelligence System Administrator's Guide.
Do not design reports to request data at a level lower than the minimum level that a metric can be reported. In addition, drilling must not be performed at these levels. This ensures that reports do not produce misleading or invalid results.
Evaluate and purge reports periodically to eliminate any outdated or duplicate reports.
Design reports to use the least amount of fact areas necessary. This reduces the number of fact table joins and in turn reduces the risk of poor report performance. Try creating separate reports with one or two fact areas on the report at a time and combining the results after these reports have run successfully.
Design reports with the least number of metrics necessary.
Schedule reports according to priority. This ensures that critical reports are available when needed. For more information on how to schedule reports, see the Oracle Business Intelligence System Administrator's Guide.
ReSA Operational Insights dashboards and reports is built on Oracle Database 12c Enterprise Edition Release 12.1.0.1.4 and must be optimized and configured for a retailers' needs.
Create aliases for the objects created in the physical layer for usability purposes.
Any level key on ident's must be set to non-drillable.
Do not design the business layer model as a snow-flake model.
In the presentation layer, fact folders (presentation tables) must contain only metrics and dimension folders (presentation tables) must contain only attributes.
For a development environment, it is recommended to use a multi-user environment. For more information on setting up a multi-user environment, see the Oracle Business Intelligence Server Administration Guide.
The following issues may be encountered while implementing ReSA Operational Insights dashboards and reports. The accompanying solutions will help you work through the issues.
Issue:
Why am I getting the Login Denied error with the following message when I try to run a report using Oracle BI Presentation Services?
ORACLE ERROR CODE: 1017, MESSAGE: ORA-01017: INVALID USERNAME/PASSWORD; LOGON DENIED
Solution:
Ensure that the repository connection pool has the right login credentials in the Oracle BI Administration Tool and check the tnsnames.ora file.
Issue:
I am getting the following error when I performed the Update all Row Counts task from the Oracle BI Administration tool.
UNABLE TO CONNECT DATABASE USING CONNECTION POOL
Solution:
Ensure the repository connection pool has the right login credentials in Oracle BI Administration tool or check the tnsnames.ora entry.
Issue:
Why can't I see query activity at the individual user level in the NQQUERY.LOG file?
Solution:
Check the logging level field in the user dialog box in the User tab. If the logging level is set to zero, the administrator may have disabled query logging. Contact the Oracle BI administrator to enable query logging.
Issue:
When a user logins to the portal, the reports do not show data?
Solution:
Check if the user has stores assigned to him.
Accessibility involves making your application usable for persons with disabilities such as low vision or blindness, deafness, or other physical limitations. This means creating applications that can be used without a mouse (keyboard only), used with a screen reader for blind or low-vision users, and used without reliance on sound, color, or animation and timing. Application Development Framework (ADF) Faces user interface components have built-in accessibility support for visually and physically impaired users. User agents such as a web browser rendering to nonvisual media such as a screen reader can read component text descriptions to provide useful information to impaired users.
ADF Faces provides two levels of application accessibility support:
Default: By default, ADF Faces generates components that have rich user interface interaction, and are also accessible through the keyboard. Note that in the default mode, screen readers cannot access all ADF Faces components. If a visually impaired user is using a screen reader, it is recommended to use the Screen Reader mode.
Screen Reader: ADF Faces generates components that are optimized for use with screen readers. The Screen Reader mode facilitates the display for visually impaired users, but will degrade the display for sighted users (without visual impairment).
Additional fine grained accessibility levels as described below are also supported:
High-contrast: ADF Faces can generate high-contrast–friendly visual content. High-contrast mode is intended to make ADF Faces applications compatible with operating systems or browsers that have high-contrast features enabled. For example, ADF Faces changes its use of background images and background colors in high-contrast mode to prevent the loss of visual information. Note that the ADF Faces high-contrast mode is more beneficial if used in conjunction with your browser's or operating system's high-contrast mode. Also, some users might find it beneficial to use large-font mode along with high-contrast mode.
Large-fonts: ADF Faces can generate browser-zoom–friendly content. In default mode, most text and many containers have a fixed font size to provide a consistent and defined look. In large-font mode, text and containers have a scalable font size. This allows ADF Faces both to be compatible with browsers that are set to larger font sizes and to work with browser-zoom capabilities. Note that if you are not using large-font mode or browser-zoom capabilities, you should disable large-font mode. Also, some users might find it beneficial to use high-contrast mode along with the large-font mode.
ReSA provide the ability to switch between the above accessibility support levels in the application, so that users can choose their desired type of accessibility support, if required. ReSA exposes a user preferences screen in which the user can specify the accessibility preferences/mode which will allow the user to operate in that mode.
Users can configure their session to the accessibility mode by setting user preferences on the home page of the ReSA application as shown below.
Perform the following procedure to configure a user preference for screen reader mode.
Log into the ReSA Portal.
From the ReSA application home page, select Preferences from the logged in user menu.
From the Tasks pane, click Accessibility to open the Accessibility tab.
Select Screen Reader to enable accessibility mode and click Save.
Click on Back to Home to return to the ReSA home page.
Now the application is enabled in the screen reader mode to assist a visibly challenged user. Some of the graphical content of Operational Insights is also displayed in a tabular mode.
Perform the following procedure to set Accessibility mode to Default mode.
From the ReSA application home page, select Preferences from the logged in user menu.
From the Tasks pane, click Accessibility to open the Accessibility tab.
Select Default mode.
Click Save to save the settings.
Click Back to Home to return to the ReSA home page.
ReSA is returned to default mode and you can view graphical reports.
