Finance

Oracle Finance

Part of the Oracle E-Business Suite, Oracle Financials fully integrates several dozen modules that are independently licensed within the E-Business Suite. It simplifies and automates the financial business procedures for a company in order to increase business intelligence, further develop business operations, and lower expenditures.


What is Oracle Financials?

Oracle Financials products provide organizations with solutions to a wide range of long- and short-term accounting system issues. Regardless of the size of the business, Oracle Financials can meet accounting management demands with:

Oracle Assets: Ensures that an organization's property and equipment investment is accurate and that the correct asset tax accounting strategies are chosen.

Oracle General Ledger: Offers a complete solution to journal entry, budgeting, allocations, consolidation, and financial reporting needs.

Oracle Inventory: Helps an organization make better inventory decisions by minimizing stock and maximizing cash flow.

Oracle Order Entry: Provides organizations with a sophisticated order entry system for managing customer commitments.

Oracle Payables: Lets an organization process more invoices with fewer staff members and tighter controls. Helps save money through maximum discounts, bank float, and prevention of duplicate payments.

Oracle Cash Management: Lets you perform bank reconciliation and cash forecasting.
Oracle Personnel: Improves the management of employee- related issues by retaining and making available every form of personnel data.

Oracle Purchasing: Improves buying power, helps negotiate bigger discounts, eliminates paper flow, increases financial controls, and increases productivity.

Oracle Receivables:Improves cash flow by letting an organization process more payments faster, without off-line research. Helps correctly account for cash, reduce outstanding receivables, and improve collection effectiveness.

Oracle Revenue Accounting Gives an organization timely and accurate revenue and flexible commissions reporting.

Oracle Sales Analysis: Allows for better forecasting, planning. and reporting of sales information. 





Key Tables: Financials

General Ledger

1- GL_SETS_OF_BOOKS
2- GL_IMPORT_REFERENCES
3- GL_DAILY_RATES
4- GL_JE_LINES
5- GL_PERIODS
6- GL_JE_HEADERS
7- GL_JE_BATCHES
8- GL_BALANCES
9- GL_CODE_COMBINATIONS


GL_SETS_OF_BOOKS
Stores information about the sets of books you define in your Oracle General Ledger application. Each row includes the set of books name, description, functional currency, and other information. This table corresponds to the Set of Books form.

GL_IMPORT_REFERENCES
Stores individual transactions from subledgers that have been summarized into Oracle General Ledger journal entry lines through the Journal Import process. You can specify the journal entry sources for which you want to maintain your transaction’s origin by entering ’Yes’ in the Import Journal References field of the Journal Sources form.
For each source that has Import Journal References set to ’Yes’, Oracle General Ledger will populate GL_IMPORT_REFERENCES with one record for each transaction in your feeder system.

GL_DAILY_RATES
Stores the daily conversion rates for foreign currency transactions. It replaces the GL_DAILY_CONVERSION_RATES table. It stores the rate to use when converting between two currencies for a given conversion date and conversion type. Each row in this table has a corresponding inverse row in which the from and to currencies are switched.
For example, if this table contains a row with a from_currency of YEN, a to_currency of CND, a conversion_type of Spot, and a conversion_date of January 1, 1997, it will also contain a row with a from_currency of CND, a to_currency of YEN, a conversion_type of Spot, and a conversion_date of January 1, 1997.
In general, this row will contain a rate that is the inverse of the matching row. One should never insert directly into this table. They should instead insert into the DAILY_RATES_INTERFACE table. Data inserted into the GL_DAILY_RATES_INTERFACE table will be automatically copied into this table.

GL_JE_LINES
Stores the journal entry lines that you enter in the Enter Journals form. There is a one–to–many relationship between journal entries and journal entry lines. Each row in this table stores the associated journal entry header ID, the line number, the associated code combination ID, and the debits or credits associated with the journal line. STATUS is ’U’ for unposted or ’P’ for posted.

GL_PERIODS
Stores information about the accounting periods you define using the Accounting Calendar form. Each row includes the start date and end date of the period, the period type, the fiscal year, the period number, and other information. There is a one–to–many relationship between a row in the GL_PERIOD_SETS table and rows inthis table.

GL_JE_HEADERS
Stores journal entries. There is a one–to–many relationship between journal entry batches and journal entries. Each row in this table includes the associated batch ID, the journal entry name and description, and other information about the journal entry. This table corresponds to the Journals window of the Enter Journals form. STATUS is ’U’ for unposted, ’P’ for posted. Other statuses indicate that an error condition was found. CONVERSION_FLAG equal to ’N’ indicates that you manually changed a converted amount in the Journal Entry Lines zone of a foreign currency journal entry. In this case, the posting program does not re–convert your foreign amounts. This can happen only if your user profile option MULTIPLE_RATES_PER_JE is ’Yes’. BALANCING_SEGMENT_VALUE is null if there is only one balancing segment value in your journal entry. If there is more than one, BALANCING_SEGMENT_VALUE is the greatest balancing segment value in your journal entry.

GL_JE_BATCHES
Stores journal entry batches. Each row includes the batch name, description, status, running total debits and credits, and other information. This table corresponds to the Batch window of the Enter Journals form. STATUS is ’U’ for unposted, ’P’ for posted, ’S’ for selected, ’I’ for in the process of being posted. Other values of status indicate an error condition. STATUS_VERIFIED is ’N’ when you create or modify an unposted journal entry batch.
The posting program changes STATUS_VERIFIED to ’I’ when posting is in process and ’Y’ after posting is complete.

GL_BALANCES
Stores actual, budget, and encumbrance balances for detail and summary accounts. This table stores functional currency, foreign currency, and statistical balances for each accounting period that has ever been opened.
ACTUAL_FLAG is either ’A’, ’B’, or ’E’ for actual, budget, or encumbrance balances, respectively. If ACTUAL_FLAG is ’B’, then BUDGET_VERSION_ID is required. If ACTUAL_FLAG is ’E’, then ENCUMBRANCE_TYPE_ID is required.
GL_BALANCES stores period activity for an account in the PERIOD_NET_DR and PERIOD_NET_CR columns. The table stores the period beginning balances in BEGIN_BALANCE_DR and BEGIN_BALANCE_CR.
An account’s year–to–date balance is calculated as BEGIN_BALANCE_DR – BEGIN_BALANCE_CR + PERIOD_NET_DR – PERIOD_NET_CR. Detail and summary foreign currency balances that are the result of posted foreign currency journal entries have TRANSLATED_FLAG set to ’R’, to indicate that the row is a candidate for revaluation.
For foreign currency rows, the begin balance and period net columns contain the foreign currency balance, while the begin balance and period net BEQ columns contain the converted functional currency balance. Detail foreign currency balances that are the result of foreign currency translation have TRANSLATED_FLAG set to ’Y’ or ’N’. ’N’ indicates that the translation is out of date (i.e., the account needs to be re–translated). ’Y’ indicates that the translation is current.
Summary foreign currency balances that are the result of foreign currency translation have TRANSLATED_FLAG set to NULL. All summary account balances have TEMPLATE_ID not NULL. The columns that end in ADB are not used. Also, the REVALUATION_STATUS column is notused.

GL_CODE_COMBINATIONS
Stores valid account combinations foreach Accounting Flexfield structure within your Oracle General Ledger application. Associated with each account are certain codes and flags, including whether the account is enabled, whether detail posting ordetail budgeting is allowed, and others. Segment values are stored in the SEGMENT columns. Note that each Accounting Flexfield structure may use different SEGMENT columns within the table to store the flexfield value combination. Moreover, the SEGMENT columns that are used are not guaranteed to be in any order. The Oracle Application Object Library table FND_ID_FLEX_SEGMENTS stores information about which column in this table is used for each segment of each Accounting Flexfield structure. Summary accounts have SUMMARY_FLAG = ’Y’ and TEMPLATE_ID not NULL. Detail accounts have SUMMARY_FLAG = ’N’ and TEMPLATE_ID NULL.


Receivables


1- RA_CUSTOMER_TRX_ALL
2- RA_CUSTOMER_TRX_LINES_ALL
3- RA_CUST_TRX_LINE_GL_DIST_ALL
4- AR_PAYMENT_SCHEDULES_ALL
5- AR_RECEIVABLES_TRX_ALL
6- AR_RECEIVABLE_APPLICATIONS_ALL

RA_CUSTOMER_TRX_ALL
This table stores invoice, debit memo, commitment, and credit memo header information. Each row includes general invoice information such as customer, transaction type, and printing instructions. You need one row for each invoice, debit memo, commitment, and credit memo you create in Oracle Receivables.
Invoices, debit memos, credit memos, and commitments are all distinguished by their transaction types stored in RA_CUST_TRX_TYPES_ALL. If you entered a credit memo, PREVIOUS_CUSTOMER_TRX_ID stores the customer transaction identifier of the invoice you credited. In the case of on account credits, which are not related to any invoice at creation, PREVIOUS_CUSTOMER_TRX_ID is null. If you created an invoice against a commitment, Oracle Receivables stores the customer transaction identifier of the commitment in INITIAL_CUSTOMER_TRX_ID, otherwise it is null. COMPLETE_FLAG stores ’Y’ for Yes and ’N’ for No to indicate if your invoice is complete.
When you complete an invoice, Oracle Receivables creates your payment schedules and updates any commitments against this invoice. Before an invoice can be completed, it must have at least one invoice line, revenue records must exist for each line and add up to the line amount, and a sales tax record must exist for each line.
Required Columns:
SOLD_TO_CUSTOMER_ID,
SOLD_TO_SITE_USE_ID,
BILL_TO_CUSTOMER_ID,
BILL_TO_SITE_USE_ID,
SHIP_TO_SITE_USE_ID,
PRINTING_OPTION,
PRINTING_PENDING,
TERM_ID,
REMIT_TO_ADDRESS_ID,
PRIMARY_SALES_REP_ID, and
INVOICE_CURRENCY_CODE
are required even though they are null allowed. The primary key for this table is CUSTOMER_TRX_ID.

RA_CUSTOMER_TRX_LINES_ALL
This table stores information about invoice, debit memo, credit memo, and commitment lines. For example, an invoice can have one line for Product A and another line for Product B. You need one row for each line. Invoice, debit memo, credit memo, and commitment lines are distinguished by the transaction type of the corresponding RA_CUSTOMER_TRX_ALL record.
Also, credit memos are required to have a value in PREVIOUS_CUSTOMER_TRX_LINE_ID, except on account credits which are not related to specific invoices/invoice lines at creation time, will not have values in this column. QUANTITY_ORDERED stores the amount of product ordered. QUANTITY_INVOICED stores the amount of product invoiced. For invoices entered through the window, QUANTITY_ORDERED and QUANTITY_INVOICED must be the same.
For invoices imported through AutoInvoice, QUANTITY_ORDERED and QUANTITY_INVOICED can be different. If you enter a credit memo, QUANTITY_CREDITED stores the amount of product credited. UOM_CODE stores the unit of measure code as defined in MTL_UNITS_OF_MEASURE. UNIT_STANDARD_PRICE stores the list price per unit for this transaction line. UNIT_SELLING_PRICE stores the selling price per unit for this transaction line. For transactions imported through AutoInvoice, UNIT_STANDARD_PRICE and UNIT_SELLING_PRICE can be different. DESCRIPTION, TAXING_RULE, QUANTITY_ORDERED, UNIT_STANDARD_PRICE,UOM_CODE, and UNIT_SELLING_PRICE are required even though they are null allowed.
LINE_TYPE differentiates between the different types of lines that are stored in this table. LINE points to regular invoice lines that normally refer to an item. TAX signifies that this is a tax line. The column LINK_TO_CUST_TRX_LINE_ID references another row in this table that is the invoice line associated with the row of type TAX. FREIGHT works the same way as TAX but there you can have at most one FREIGHT type l ine per invoice line of type LINE. You can also have one line of type FREIGHT that has a null LINK_TO_CUST_TRX_LINE_ID (and this is referred to as header level freight). CHARGES works just like the LINE type. A line_type of ’CB’ is created for a Chargeback line. For every row in this table that belongs to a complete transaction (where RA_CUSTOMER_TRX.COMPLETE_FLAG = Y), there must be at least one row in the table RA_CUST_TRX_LINE_GL_DIST (which stores accounting information), even for non–postable transactions. The primary key for this table is CUSTOMER_TRX_LINE_ID.


RA_CUST_TRX_LINE_GL_DIST_ALL
This table stores the accounting records for revenue, unearned revenue and unbilled receivables for each invoice or credit memo line. Each row includes the GL account and the amount of the accounting entry. The AMOUNT column in this table is required even though it is null allowed.
You need one row for each accounting distribution. You must have at least one (but you can have multiple) accounting distributions for each invoice or credit memo line. Oracle Receivables uses this information to post the proper amounts to your general ledger. If your invoice or credit memo has a transaction type where Post to GL is set to No, Oracle Receivables assigns Null to GL_DATE.
If your AutoAccounting is unable to complete your general ledger default accounts using the AutoAccounting rules you define, incomplete general ledger accounts are stored in CONCATENATED_SEGMENTS. If you are importing a transaction through AutoInvoice and the general ledger date of your transaction is in a closed accounting period, AutoInvoice uses the general ledger date of the first open accounting period and stores the original general ledger date in ORIGINAL_GL_DATE. ACCOUNT_CLASS defines which type of distribution row you are on.
The ACCOUNT_CLASS REC represents the receivable account and is for the total amount of the invoice. There can be at most two REC rows. One that has a ACCOUNT_SET_FLAG set to Y and the other has ACCOUNT_SET_FLAG set to N. Use LATEST_REC_FLAG to join to the later of the two rows. ACCOUNT_SET_FLAG is Y if this row is part of an account set. An account set is a set of rows that represent a model distribution. Account sets are used for invoices with rules. The rows represent how the actual distribution rows should be created and what percentage of the actual distribution should be allocated to each account.
For invoices with rules, the distributions are not created when the invoice is initially created. Instead, the invoices are created when the Revenue Recognition program is run. The primary key for this table is CUST_TRX_LINE_GL_DIST_ID.

AR_PAYMENT_SCHEDULES_ALL
This table stores all transactions except adjustments and miscellaneous cash receipts. Oracle Receivables updates this table when activity occurs against an invoice, debit memo, chargeback, credit memo, on account credit, or receipt. Oracle Receivables groups different transactions bythe column CLASS. These classes include invoice (INV), debit memos(DM), guarantees (GUAR), credit memos (CM), deposits (DEP),chargebacks (CB), and receipts (PMT).
Transaction classes determine which columns in this table Oracle Receivables updates when a transaction occurs, and whether a transaction relates to either the RA_CUSTOMER_TRX_ALL table or the AR_CASH_RECEIPTS_ALLtable. AR_PAYMENT_SCHEDULES_ALL joins to the RA_CUSTOMER_TRX_ALL table for non–payment transaction entries such as the creation of credit memos, debit memos, invoices, chargebacks, or deposits.
AR_PAYMENT_SCHEDULES_ALL uses the foreign key CUSTOMER_TRX_ID to join to the RA_CUSTOMER_TRX_ALL table for these transactions. AR_PAYMENT_SCHEDULES_ALL joins to the AR_CASH_RECEIPTS_ALL table for invoice–related payment transactions using the foreign key CASH_RECEIPT_ID. When a receiptis applied, Oracle Receivables updates AMOUNT_APPLIED, STATUS and AMOUNT_DUE_REMAINING. STATUS changes from ’OP’ to ’CL’for any transaction that has an AMOUNT_DUE_REMAINING value of 0(Zero).
ACTUAL_DATE_CLOSED and GL_DATE_CLOSED are populated with the date of the latest transaction. For a receipt, the amount due remaining includes on account and unapplied amounts. Oracle Receivables stores debit items such as invoices, debit memos, chargebacks, deposits, and guarantees as positive numbers in the AMOUNT_DUE_REMAINING and AMOUNT_DUE_ORIGINAL columns. Credit items such as credit memos and receipts are stored as negative numbers. In Release 10, receipts can be confirmed or not confirmed as designated by the CONFIRMED_FLAG column. The sum of the AMOUNT_DUE_REMAINING column for a customer for all confirmed payment schedules reflects the current customer balance. If this amount is negative, then this column indicates the credit balance amount currently available for this customer. For invoices with split terms, one record is created in RA_CUSTOMER_TRX_ALL and one record is stored in AR_PAYMENT_SCHEDULES_ALL for each installment. In AR_PAYMENT_SCHEDULES_ALL, DUE_DATE and AMOUNT_DUE_REMAINING can differ for each installment of a split term invoice. Each installment is differentiated by the TERMS_SEQUENCE_NUMBER column.
If you create a debit memo reversal when you reverse a receipt, Oracle Receivables creates a new payment schedule record for the debit memo and fills in REVERSED_CASH_RECEIPT_ID with the CASH_RECEIPT_ID of the receipt that was reversed. Oracle Receivables creates a new payment schedule record when you create a chargeback in the Receipts window. ASSOCIATED_CASH_RECEIPT_ID is the cash receipt of the payment you entered when you created the chargeback in this window. GL_DATE_CLOSED indicates the general ledger date on which your transaction was closed.
This column identifies which transactions Oracle Receivables selects when it displays current and overdue debit items in the aging reports. The aging reports also utilize the current balances in AMOUNT_DUE_REMAINING to display outstanding amounts for current and overdue debit items. ACTUAL_DATE_CLOSED gives the date on which you applied a payment or credit to an open transaction that set AMOUNT_DUE_REMAINING to 0 for that transaction. Oracle Receivables uses ACTUAL_DATE_CLOSED to determine which transactions to include when you print statements. The primary key for this table is PAYMENT_SCHEDULE_ID, which identifies the transaction that created the row.


AR_RECEIVABLES_TRX_ALL
This table links accounting information with your Receivables Activities. Possible types of activities include Adjustment, Miscellaneous Cash, and Finance Charges. If your type is Miscellaneous Cash, you can associate either a distribution set or a standard accounting flexfield to your Receivables Activity. Oracle Receivables uses one row for each activity. You use your receivables activities to speed receipt entry and generate finance charges. The other types of activities that were valid in release 9 and no longer valid in Release 10 were converted (as part of the upgrade) such that the actual accounting flexfield CODE_COMBINATION_ID is stored in the table instead of the RECEIVABLES_TRX_ID. In Release 9, all of these references were in AR_BATCH_SOURCES; they are now in AR_RECEIPT_METHOD_ACCOUNTS_ALL. The primary key for this table is RECEIVABLES_TRX_ID.
AR_RECEIVABLE_APPLICATIONS_ALL
This table stores all accounting entries for your cash and credit memo applications. Each row includes the amount applied, status, and accounting flexfield information. Possible statuses of your applications include APP, UNAPP, ACC, and UNID. You use this information to determine the applications of your payments or credit memos. CONFIRMED_FLAG is a denormalization from AR_CASH_RECEIPTS_ALL.
If the cash receipt is not confirmed, the applications of that receipt are not reflected in the payment schedule of the transaction it is applied against. There are two kinds of applications: CASH and CM (for credit memo applications). This is stored in the column APPLICATION_TYPE.
CASH applications represent applications of a cash receipt. When a cash receipt is initially created, a row is created in this table that has a status of UNAPP for the amount of the cash receipt. Each subsequent application creates two rows – one with a status of APP for the amount being applied to the invoice and one with status UNAPP for the negative of the amount being applied. Ifyou reverse a cash application, a row with status APP with the inverse amount of the original application (i.e. the negative of the original application amount) is created. The corresponding UNAPP rows is alsocreated which will have a positive amount (the same amount as the application being reversed). For example: UNAPP 100 creation of a$100 cash receipt APP 60 application of $60 of this cash receipt UNAPP –60 this row takes away (debits) unapplied APP –60 reversal of the $60 application UNAPP 60 this rows puts back(credits) unapplied The sum of the AMOUNT_APPLIED column for CASH applications should always equal the amount of the cash receipt. CM applications, on the other hand, do not have rows of status UNAPP. They only use rows with a status of APP. CASH_RECEIPT_ID stores the cash receipt identifier of the receipt you entered. Oracle Receivables concurrently creates a record of this receipt in the AR_CASH_RECEIPTS_ALL table.
This column is null for a credit memo application. CODE_COMBINATION_ID stores valid Accounting Flexfield segment value combinations that will be credited in the General Ledger when this application is posted. A negative value in AMOUNT_APPLIED becomes a debit. The STATUS of a receivable application determines which flexfield account Oracle Receivables uses. For example, if you enter a cash receipt of $500 as Unidentified, Oracle Receivables creates a record in theAR_RECEIVABLE_APPLICATIONS_ALL table with AMOUNT_APPLIED = 500 and STATUS = ’UNID’. Oracle Receivables uses the foreign key CODE_COMBINATION_ID to associate this payment with the Unidentified flexfield account. CUSTOMER_TRX_ID, CASH_RECEIPT_ID, and PAYMENT_SCHEDULE_ID identify the transaction that you are actually applying. APPLIED_CUSTOMER_TRX_ID and APPLIED_PAYMENT_SCHEDULE_ID identify the invoice or credit memo that receives the application. For example, if you apply a receipt against an invoice, Oracle Receivables creates a record in the AR_RECEIVABLE_APPLICATIONS_ALL table. The CASH_RECEIPT_ID and the PAYMENT_SCHEDULE_ID of this record identify the receipt you are applying. APPLIED_PAYMENT_SCHEDULE_ID and APPLIED_CUSTOMER_TRX_ID for this record belong to the invoice that is receiving the application. If you apply a credit memo against the invoice, Oracle Receivables creates a record in the AR_RECEIVABLE_APPLICATIONS_ALL table that has theCUSTOMER_TRX_ID and the PAYMENT_SCHEDULE_ID of the credit memo you are applying. The APPLIED_PAYMENT_SCHEDULE_ID and the APPLIED_CUSTOMER_TRX_ID of this record belong to the invoice that is receiving the application. If you combine an on account credit and a receipt, Oracle Receivables creates a record in the AR_RECEIVABLE_APPLICATIONS_ALL table.
The PAYMENT_SCHEDULE_ID and the CASH_RECEIPT_ID of this record identify the receipt. The APPLIED_PAYMENT_SCHEDULE_ID and the APPLIED_CUSTOMER_TRX_ID of this record identify the on account credit that you are combining with the receipt. The primary key for this table is RECEIVABLE_APPLICATION_ID, which uniquely identifies the transaction that created the row.



Payables


1- AP_INVOICES_ALL
2- AP_INVOICE_DISTRIBUTIONS_ALL
3- AP_PAYMENT_SCHEDULES_ALL
4- AP_HOLDS_ALL
5- AP_AE_LINES_ALL
6- AP_AE_HEADERS_ALL

AP_INVOICES_ALL
AP_INVOICES_ALL contains records for invoices you enter. There is one row for each invoice you enter. An invoice can have one or more invoice distribution lines. An invoice can also have one or more scheduled payments. An invoice of type EXPENSE REPORT must relate to a row in AP_EXPENSE_REPORT_HEADERS_ALL unless the record has been purged from AP_EXPENSE_REPORT_HEADERS_ALL. Your Oracle Payables application uses the INTEREST type invoice for interest that itcalculates on invoices that are overdue. Your Oracle Payables application links the interest invoice to the original invoice by inserting the INVOICE_ID in the AP_INVOICE_RELATIONSHIPS table.

AP_INVOICE_DISTRIBUTIONS_ALL
AP_INVOICE_DISTRIBUTIONS_ALL holds the distribution line information that you enter for invoices. There is a row for each invoice distribution. A distribution line must be associated with an invoice. An invoice can have multiple distribution lines. Your Oracle Payables application automatically creates rows in this table when:
1) you choose a distribution set at the invoice level
2) you import expense reports
3) you match an invoice to a purchase order or receipt; ituses information from the matched purchase order or receipt
4) you import invoices via the Open Interface Import process
5) you select to automatically calculate tax
6) you select to automatically do withholding.

Each invoice distribution line has its own accounting date. When you account for an invoice, your OraclePayables application creates accounting events, accounting entry headers and accounting entry lines for those distribution lines that have accounting dates included in the selected accounting date range for the Payables Accounting Process.The accounting entries can then be transferred over to General Ledger by running the Transfer to General Ledger process which creates journal entries. Values for POSTED_FLAG may be Y for accounted distributions or N for distributions that have not been accounted. Values for ACCRUAL_POSTED_FLAG may be Y if distribution has been accounted and system is set up for accrual basis accounting or N if either distribution has not been accounted or accrual basis accounting is not used. Values for CASH_POSTED_FLAG may be Y if distribution has been accounted and system is set up for cash basis accounting, N if either distribution has not been accounted or system is not set up for cash basis accounting or P if distribution has been partially accounted in the cash set of books. The MATCH_STATUS_FLAG indicates the approval status for the distribution. Values for the MATCH_STATUS_FLAG can be null or N for invoice distributions that Approval has not tested or T for distributions that have been tested or A for distributions that have been tested and approved. Invoice distributions may be interfaced over/from Oracle Assets or Oracle Projects. Your Oracle Payables application sets the ASSETS_ADDITION_FLAG to U for distributions not tested by Oracle Assets; Oracle Assets then adjusts this flag after it tests a distribution for assignment as an asset.
To avoid the same invoice distribution being interfaced to both Oracle Projects and Oracle Assets, you must interface any project–related invoice distribution to Oracle Projects before you can interface it to Oracle Assets. If the project–related invoice distribution is charged to a capital project in Oracle Projects, Oracle Projects sets the ASSET_ADDITION_FLAG to P when the PA_ADDITION_FLAG is set to Y, Z or T. Oracle Assets only picks up invoice distributions with the ASSET_ADDITION_FLAG set to U and if project–related, with the PA_ADDITION_FLAG set to Y, Z, or T. PA_ADDITION_FLAG tracks the status of project–related supplier invoice distribution lines and expense report distribution lines.
For supplier invoice distributions entered via Oracle Payables, the PA_ADDITION_FLAG is set to N if the distribution is project–related, otherwise it is set to E and it is updated by Oracle Projects when the distribution is processed by the Oracle Projects Interface Supplier Invoice process. Oracle Projects sets the PA_ADDITION_FLAG to Y or Z after the item is successfully processed, or may be set to a rejection code if the line is rejected during transfer to Oracle Projects; see QuickCodes listing for all the errors. You must correct the rejection reason an try to retransfer the line. For supplier invoice adjustment lines interfaced from Oracle Projects to Oracle Payables (which must net to zero with another line), the value for the PA_ADDITION_FLAG is set to T. For expense report distributions interfaced from Oracle Projects to Oracle Payables via Invoice Import, this value is set to N. This row is never picked up by the Interface Supplier Invoices process based on the AP_INVOICES.INVOICE_TYPE_LOOKUP_CODE = EXPENSEREPORT. For expense report adjustment lines interfaced from Oracle Projects to Oracle Payables which net to zero with another line, thisvalue is set to T. Both lines are associated with the original invoice by the Oracle Projects Interface Expense Reports to AP process. Values for the ENCUMBERED_FLAG are as follows:

- Y indicates aregular distribution that has been successfully encumbered by Payables;
- W indicates a regular distribution that has been encumbered in advisory mode even though insufficient funds existed;
- H indicates a regular distribution that has not been encumbered because it was put on hold;
- Nor null indicates a regular line that has not been encumbered because it has not been looked at yet;
- D is the same as Y for a reversal distribution line;
- X is the same as W for a reversal distribution line;
- P is the same as H for a reversal distribution line;
- R indicates a line to be ignored by encumbrance and approval code because neither the original nor the reversal distributions were looked at and they offset each other so, they can be ignored.

AP_PAYMENT_SCHEDULES_ALL
AP_PAYMENT_SCHEDULES_ALL contains information about scheduled payments for an invoice. You need one row for each time you intend to make a payment on an invoice. Your Oracle Payables application uses this information to determine when to make payments on an invoice and how much to pay in an automatic payment batch. Values for HOLD_FLAG may be ’Y’ to place a hold on the scheduled payment, or ’N’ not to do so. Values for PAYMENT_STATUS_FLAG may be ’Y’ for fully paid payment schedules, ’N’ for unpaid scheduled payments, or ’P’ for partially paid scheduled payments. For converted records, enter a value for AMOUNT_REMAINING.

AP_HOLDS_ALL
AP_HOLDS_ALL contains information about holds that you or your Oracle Payables application place on an invoice. For non–matching holds, there is one row for each hold placed on an invoice. For matching holds, there is one row for each hold placed on an invoice–shipment match. An invoice may have one or more corresponding rows in this table. Your Oracle Payables application does not pay invoices that have one or more unreleased holds recorded in this table. This table holds information referenced by the Invoice Holds window. In the strictest sense, AP_HOLDS_ALL has no primary key. It is possible for your Oracle Payables application to place a certain type of hold on an invoice, then release it, then place another hold of the same type (if data changes before each submission of Approval), which would result in a duplicate primary key. But for practical purposes, the primary key is a concatenation of INVOICE_ID, LINE_LOCATION_ID,and HOLD_LOOKUP_CODE.

AP_AE_LINES_ALL
An accounting entry line is an entity containing a proper accounting entry with debits or credits both in transaction currency as well as functional currency along with an account and other reference information pointing to the transaction data that originated the accounting entry line. An accounting entry line is grouped with other accounting entry lines for a specific accounting entry header. Any such group of accounting entry lines should result in balanced entries in the functional currency.

AP_AE_HEADERS_ALL
An accounting entry header is an entity grouping all accounting entry lines created for a given accounting event and a particular set of books. An accounting entry header can either be transferred over to GL or not at all. That is, either all its accounting entry lines are transferred or none at all. The transferred to GL status is marked in the GL_TRANSFER_FLAG. Possible values for GL_TRANSFER_FLAG are Y, N, or E. Y indicates that the accounting entry header has been transferred to GL. N indicates that the accounting entry header has not been transferred to GL due to 2 possible reasons: either the transfer process has not run or it has run but the accounting entry had an accounting error on it. E indicates that an error was encountered during the transfer to GL process.


Assets

1- FA_DEPRN_PERIODS
2- FA_DEPRN_SUMMARY
3- FA_ADDITIONS_B
4- FA_BOOKS
5- FA_CATEGORIES_B
6- FA_DEPRN_DETAIL
FA_DEPRN_PERIODS contains information about your depreciation periods. Oracle Assets uses this table to determine when each period in FA_CALENDARS was open for a depreciation book. PERIOD_OPEN_DATE and PERIOD_CLOSE_DATE are the dates when you opened and closed each book’s depreciation period. Each time you run the depreciation program, it closes the current period by setting PERIOD_CLOSE_DATE to the system date. It also opens the next period by inserting a new row into this table in which PERIOD_CLOSE_DATE is NULL and PERIOD_OPEN_DATE equals the PERIOD_CLOSE_DATE of the old row. CALENDAR_PERIOD_OPEN_DATE and CALENDAR_PERIOD_CLOSE_DATE correspond to your calendar as defined by the START_DATE and END_DATE columns in FA_CALENDAR_PERIODS.

FA_DEPRN_SUMMARY contains depreciation information for your assets. Each time you run the depreciation program, it inserts one row into thistable for each asset. PERIOD_COUNTER is the period for which you ran the depreciation program. DEPRN_AMOUNT is the depreciation expense for an asset in a depreciation period. It is the sum of DEPRN_AMOUNT in all the rows of FA_DEPRN_DETAIL for the asset and period. YTD_DEPRN is the accumulated depreciation of an asset for the current fiscal year as of the end of this period. DEPRN_RESERVE is the total accumulated depreciation for this asset. DEPRN_SOURCE_CODE tells you what program created the row BOOKS Created by the Depreciation Books form, Quick Additions form, or the post mass additions program when you enter a new asset. DEPRN Created by the depreciation program when you run depreciation. ADJUSTED_COST is the depreciable basis the depreciation program uses to calculate depreciation for an asset in a depreciation period. This value is the same as the asset’s recoverable cost, except for assets that use a diminishing value depreciation method, assets to which you have made an amortized adjustment, and assets you have revalued.
For assets that use a diminishing value method, the ADJUSTED_COST is the beginning of year net book value, which the depreciation program updates at the start of each fiscal year. When you perform an amortized adjustment on an asset or revalue it, the ADJUSTED_COST becomes the asset’s net book value at the time of the adjustment or revaluation. BONUS_RATE is the bonus rate that Oracle Assets adds to the adjusted rate to give you the flat rate for the fiscal year. The depreciation program uses this rate to calculate depreciation for an asset. This only applies to assets that use both a flat–rate depreciation method and bonus depreciation.
FA_ADDITIONS_B contains descriptive information to help you identify your assets. Oracle Assets does not use this table to calculate depreciation.When you add an asset, Oracle Assets inserts a row into this table and into FA_ASSET_HISTORY. When you change the asset information stored in this table, Oracle Assets updates it in this table. It also creates a new row in FA_ASSET_HISTORY. When you perform a unit retirement, Oracle Assets reduces the CURRENT_UNITS by the units retired. UNIT_ADJUSTMENT_FLAG is set to YES by the Additions form if you change the number of units for an asset. The Transfers form resets it to NO after you reassign the remaining units. FA_ADJUSTMENTS stores information that Oracle Assets needs to create journal entries for transactions. The posting program creates journal entries for regular depreciation expense from information in FA_DEPRN_DETAIL. Oracle Assets inserts a row in this table for the debit and credit sides of a financial transaction. All the rows for the same transaction have the same value in the TRANSACTION_HEADER_ID column. The SOURCE_TYPE_CODE column tells you which program created the adjustment:
- ADDITION Depreciation program
- ADJUSTMENT Expensed or Amortized Adjustment User Exit
- CIP ADDITION Depreciation program
- CIP ADJUSTMENT Expensed or Amortized Adjustment User Exit
- CIP RETIREMENT Gain/loss program
- DEPRECIATION Depreciation program (Retroactive transactions andexpensed depreciation adjustments)
- RETIREMENT Gain/loss program
- RECLASS Reclassification user exit
- TRANSFER Transfers form
- TAX Reserve Adjustments form
- REVALUATION Mass revaluation program
The ADJUSTMENT_TYPE column tells you which type of account Oracle Assets adjusts. DEBIT_CREDIT_FLAG is DR if the amount is a debit and CR if the amount is a credit. ADJUSTMENT_AMOUNT is the amount debited or credited to the account. ANNUALIZED_ADJUSTMENT is the adjustment amount for a period times the number of periods in a fiscal year. The depreciation program uses it to calculate the depreciation adjustment for an asset when you perform multiple retroactive transactions on the asset. Oracle Assets calculates ADJUSTMENT_PER_PERIOD by dividing the ADJUSTMENT_AMOUNT for a retroactive transaction by the numberof periods between the period you entered the transaction and the period that it was effective. For current period transactions, this columnis zero. PERIOD_COUNTER_CREATED IS the period that you entered the adjustment into Oracle Assets. PERIOD_COUNTER_ADJUSTED is the period to which the adjustment applies. It is the same as PERIOD_COUNTER_CREATED, unless you enter a reserve adjustment, in which case PERIOD_COUNTER_ADJUSTED is the last period of the fiscal year to which the adjustment applies. CODE_COMBINATION_ID indicates the Accounting Flexfield combination Oracle Assets debits or credits for all transactions except reclassifications and intercompany transfers. This CODE_COMBINATION_ID is generated using the Account Generator, and the posting program does not perform any further processing.


FA_BOOKS contains the information that Oracle Assets needs to calculate depreciation. When you initially add an asset, Oracle Assets inserts one row into the table. This becomes the ”active” row for the asset. Whenever you use the Depreciation Books form to change the asset’s depreciation information, or if you retire or reinstate it, Oracle Assets inserts another row into the table, which then becomes the new ”active” row, and marks the previous row as obsolete.
At any point in time, there is only one ”active” row in the table for an asset in any given depreciation book. Generally, Oracle Assets uses the active row, but if you run a report for a prior accounting period, Oracle Assets selects the row that was active during that period. You can identify the active row for anasset in a book because it is the only one whose DATE_INEFFECTIVE and TRANSACTION_HEADER_ID_OUT are NULL. When Oracle Assets terminates a row, the DATE_INEFFECTIVE and TRANSACTION_HEADER_OUT are set to the DATE_EFFECTIVE and TRANSACTION_HEADER_IN of the new row, respectively. This means that you can easily identify rows affected by the same transaction because they have the same DATE_EFFECTIVE / DATE_INEFFECTIVE and TRANSACTION_HEADER_ID_IN / TRANSACTION_HEADER_ID_OUT pairs.
When Oracle Assets creates the new row, the value used for the TRANSACTION_HEADER_ID_IN column is the same as the TRANSACTION_HEADER_ID in the row inserted into FA_TRANSACTION_HEADERS, and the DATE_EFFECTIVE is the system date. When you retire an asset, Oracle Assets inserts a new row to reduce the COST by the amount retired. When you reinstate an asset, Oracle Assets inserts a new row to increase the COST by the COST_RETIRED in the corresponding row in FA_RETIREMENTS.RATE_ADJUSTMENT_FACTOR is originally 1. It is used to spread depreciation over the remaining life of an asset after an amortization or revaluation. If you perform a revaluation or an amortized adjustment, Oracle Assets resets the Rate Adjustment Factor to prorate the remaining recoverable net book value over the remaining life.
This fraction is calculated as [Recoverable Cost – what Depreciation Reserve would be]/Recoverable Cost. The depreciation program uses this value to adjust the depreciation rate for an asset.
FA_CATEGORIES_B stores information about your asset categories. This table provides default information when you add an asset. The depreciation program does not use this information to calculate depreciation.The Asset Categories form inserts one row in this table for each asset category you define. The Application Object Library table FND_ID_FLEX_SEGMENTS stores information about which column in this table is used for each segment.
FA_DEPRN_DETAIL contains the depreciation amounts that the depreciation program charges to the depreciation expense account in each distribution line.
Oracle Assets uses this information to create depreciation expense journal entries for your general ledger.The depreciation program inserts one row per distribution line for an asset each time you run depreciation.
For example, if you assign an asset to two different cost centers, the depreciation program inserts two rows in this table for the asset.
DEPRN_AMOUNT is the amount of depreciation expense calculated forthis distribution line.
YTD_DEPRN is the year–to–date depreciation allocated to thisdistribution line.When you add an asset, Oracle Assets inserts a row into this table for the period before the current period. This row has the asset cost in the ADDITION_COST_TO_CLEAR column and a DEPRN_SOURCE_CODE of ’B’. This column is used for reporting on new assets. When you run depreciation, Oracle Assets transfers the cost to the COST column in the current period row, this row has a DEPRN_SOURCE_CODE of ’D’.


FND
1- FND_ID_FLEXS
2- FND_ID_FLEX_SEGMENTS
3- FND_ID_FLEX_STRUCTURES
4- FND_FLEX_VALUES
5- FND_FLEX_VALUE_HIERARCHIES

FND_ID_FLEXS stores registration information about key flexfields. Each row includes the four–character code that identifies the key flexfield, the title of the flexfield (by which a user identifies theflexfield), the name of the combinations table that contains the key flexfield columns, and the name of the structure defining (MultiFlex) column for the flexfield (SET_DEFINING_COLUMN_NAME). Each row also contains values that identify the application that owns the combination table and the application that owns the key flexfield, a table–type flag that specifies whether the combinations table is specificor generic (S or G), whether dynamic inserts are feasible for the flexfield(Y or N), whether the key flexfield can use ID type value sets, and the name of the unique ID column in the combinations table. You need one row for each key flexfield in each application. Oracle Application ObjectLibrary uses this information to generate a compiled key flexfield definition
FND_ID_FLEX_SEGMENTS
FND_ID_FLEX_SEGMENTS stores setup information about keyflexfield segments, as well as the correspondences between application table columns and the key flexfield segments the columns are used for. Each row includes a flexfield application identifier, the flexfield code,which identifies the key flexfield, the structure number(ID_FLEX_NUM), the value set application identifier, the segment number (the segment’s sequence in the flexfield window), the name of the column the segment corresponds to (usually SEGMENTn, where n is an integer). Each row also includes the segment name, whether security is enabled for the segment, whether the segment is required, whether the segment is one of a high, low segment pair, whether the segment is displayed, whether the segment is enabled (Y or N), type of default value, display information about the segment such as prompts and display size, and the value set the segment uses. Each row also includes a flag for whether the table column is indexed; this value is normally Y. You need one row for each segment of each structure for each flexfield. Oracle Application Object Library uses this information to generate a compiled key flexfield definition to store in the FND_COMPILED_ID_FLEXS table

FND_ID_FLEX_STRUCTURES
FND_ID_FLEX_STRUCTURES stores structure information about keyflexfields. Each row includes the flexfield code and the structurenumber (ID_FLEX_NUM), which together identify the structure, and the name and description of the structure. Each row also includes values that indicate whether the flexfield structure is currently frozen, whether rollup groups are frozen (FREEZE_STRUCTURED_HIER_FLAG), whether users can dynamically insert new combinations of segment values through the flexfield pop–up window, and whether the flexfield should use segment cross–validation rules. Each row also contains information about shorthand flexfield entry for this structure, including whether shorthand entry is enabled, the prompt for the shorthand window, and the length of the shorthand alias field in the shorthandwindow. You need one row for each structure of each key flexfield. Oracle Application Object Library uses this information to generate acompiled key flexfield definition to store in the FND_COMPILED_ID_FLEXS table


FND_FLEX_VALUES stores valid values for key and descriptive flexfield segments. Oracle Application Object Library uses this table when users define values for independent or dependent type value sets. Oracle Application Object Library also uses this table when users define parent values for ranges of child values that exist in a validation table(Oracle Application Object Library stores the parent values in this table). Each row includes the value (FLEX_VALUE) and its hierarchy level if applicable as well as the identifier of the value set the value belongs to. If the value is a dependent value, PARENT_FLEX_VALUE_LOW contains the independent value this value depends upon. Oracle Application Object Library does not use the PARENT_FLEX_VALUE_HIGH column. If ENABLED_FLAG contains N, this value is currently invalid, regardless of the start and end dates.
If ENABLED_FLAG contains Y, the start and end dates indicate if this value is currently valid.
SUMMARY_FLAG indicates if this value is a parent value that has child values, and STRUCTURED_HIERARCHY_LEVEL contains the rollup group the parent value belongs to, if any (1 through 9). COMPILED_VALUE_ATTRIBUTES contains the compiled values of anysegment qualifiers assigned to this value. These values are in a special Oracle Application Object Library format, and you should never modify them.
VALUE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE50 are descriptive flexfield columns, where VALUE_CATEGORY is the context (structure defining) column.
These descriptive flexfield columns do not contain values unless you have defined the descriptive flexfield at your site. You need one row for each independent, dependent or parent value belonging to a value set.
Oracle Application Object Library uses this information to ensure that users enter valid values in flexfield segments


FND_FLEX_VALUE_HIERARCHIES stores information about child value ranges for key flexfield segment values. Each row includes an identification of the parent value the range belongs to, as well as the low and high values that make up the range of child values. FLEX_VALUE_SET_ID identifies the value set to which the parent value belongs. You need one row for each range of child values (you can have more than one row for each parent value). Oracle Application Object Library provides this information for applications reporting purposes.
 
 

Financial Analyzer -I

Definition: Financial Analyzer
Financial Analyzer is a distributed software application that you can use to:
1) Report and analyze corporate financial data and create financial budgets, forecasts, and plans
2) Create and run financial models
3) Configure an efficient and convenient financial system for your business

Financial Analyzer runs on a combination of networked personal computers and servers. A variety of software modules, known as workstations, are installed on the personal computers and servers and are set up to access common databases, called shared databases. These shared databases contain data and structures that are used throughout the Financial Analyzer system.
If Web listener software has been installed and configured on the server, Financial Analyzer reports, graphs, and data entry forms can also be accessed through a Web browser.



Types of workstations
The Financial Analyzer environment includes two basic types of workstations, administrator workstations and user workstations.
The following types of administrator workstations are supported:
- Super administrator workstation
- Administrator workstations
- Task Processor workstations

The following types of user workstations are supported:
- Budget workstations
- Analyst workstations



Types of databases
Financial Analyzer workstations access 2 type of databases:
1) Personal: Personal databases are used to store objects, and on some types of workstations, financial data. Objects include dimensions, financial data items, attributes, and hierarchies, as well as documents such as reports, worksheets and graphs.

2) Shared: The shared database contains financial data and objects that are shared by all users. Shared databases are maintained by administrators.



Tiered system design
Using the Super administrator workstation as the starting point, you can build a tiered architecture by creating subordinate administrator workstations, which can in turn be used to create other subordinate administrator workstations. This tiered approach to system design reduces the size and complexity of the top-level structures and permits greater autonomy and control at lower-level and remote sites.


Super Administrator Workstations

Super administrator workstation enables the administrator at the highest level to perform the following functions:
- Define database structures and documents for system-wide use
- Control subordinate administrators' and users' access to financial data
- Process tasks submitted by users to update the Super administrator's shared database

Location in a tiered architecture:The Super administrator workstation is located at the top level of any Financial Analyzer environment. Only one Super administrator workstation can exist in a given system.
Associated databases: Super administrator workstations are associated with a Super shared database, a personal database, and a Task Processor.


Administrator Workstations
The Administrator workstation is a system management and data access tool that enables you to perform the following tasks:
1) Define and maintain users of Budget, Analyst, and subordinate Administrator workstations.
2) Specify the default configuration for Budget, Analyst, and subordinate Administrator workstations when you create them.
3) Restrict changes to shared data by controlling user access to the financial data in the shared database.
4) Define database structures and distribute them to the shared database, subordinate Administrator workstations, Budget workstations, and Analyst workstations.
5) Distribute slices of financial data to users and the shared database.
6) Refresh the shared database that you maintain with data distributed from your superior administrator.
7) Submit financial data from the shared database that you maintain to your superior administrator's shared database. (Super administrators cannot perform this task because by definition they are at the highest level in the reporting structure.)


Location in a tiered architecture: Multiple Administrator workstations can exist at various levels of an environment that is set up in a tiered configuration. Each Administrator workstation is associated with its own shared database.

Associated databases: Administrator workstations are associated with a shared database and a Task Processor.


Task Processor Workstation

A Task Processor workstation is a queue management tool that has the following characteristics: - It is associated with each Administrator workstation in an Financial Analyzer system
- It enables administrators to monitor and control the transfer of data between user workstations and their associated shared databases
- It enables administrators to manage distribution of structures to subordinate workstations

Methods of running a Task Processor
Although all tasks are actually processed on the server, a Task Processor can be set up:
- As a separate software component on the computer where an Administrator workstation runs
On a separate computer that is dedicated to task processing
- To run directly on a server as a background task

When the Task Processor workstation is installed as a stand-alone workstation on a dedicated PC or server, tasks can be processed without interruption.

Budget Workstations
A Budget workstation is a data access tool that enables you to perform the following tasks:
- Define and maintain personal database objects such as dimensions, attributes, hierarchies, models, solve definitions, and group solve definitions
- Create and maintain personal reports, graphs, worksheets, and folders
- Use administrator defined database objects and documents
- Submit financial data from the personal database to the Administrator workstation's shared database
- Refresh the personal database with data from the Administrator workstation's shared database

Location in a tiered architecture: In a tiered structure, a Budget workstation is located beneath the Administrator workstation that created it and is associated with a personal database that contains database structures, settings, and financial data.
Multiple Budget workstations can exist beneath the same Administrator workstation. In a tiered configuration, multiple Budget workstations can also exist at multiple levels of the configuration.

Analyst Workstations
An Analyst workstation is a data access tool that enables you to perform the following tasks:
- Refresh structures distributed by the Administrator workstation
- Define and use personal reports, graphs, worksheets, and folders or use administrator defined documents
- Access and manipulate data associated with dimensions, dimension values, time, attributes, hierarchies, and models in the shared database

Location in a tiered architecture: In a tiered structure, an Analyst workstation is located beneath the Administrator workstation that created it and is associated with a personal database that contains database structures and settings but no personal copy of financial data

Example: Workstations in a Typical Corporate Environment
In a typical corporation, there are many different ways that Financial Analyzer can be configured and utilized.

Consulting division: In the consulting division, regional Consulting Managers use Budget workstations that report into the Sub Administrator workstation of the Consulting VP. Consulting Managers can:
- Edit the expense and revenue line items of their region.
- View the expense and revenue line items of other regional Consulting Managers. This facilitates Consulting Managers inputting their budget and forecast numbers based on trends in their particular regions.
- Perform what-if analysis to evaluate the potential performance based on the probability of the variable environment factors occurring.
- Augment their personal database by adding financial and personnel data which is not present in the data set distributed to them from the Administrator (which is sourced primarily from Oracle General Ledger).

When budgets or forecasts are completed, Consulting Managers submit their final numbers to the Consulting VP who reviews them and requests revisions if necessary. The Consulting VP may also make edits to the shared data which become the final budget. The lower level Budget workstations Consulting Managers then refresh their personal databases to get the finalized figures. The Consulting VP submits final summary consulting P&L budgets and forecasts to a Senior Financial Analyst in Corporate Finance who runs the Super administrator workstation.


Manufacturing: In the manufacturing environment, Product Managers:
- Follow an organization similar to the Consulting Managers, except that what they can view and edit is determined by their product responsibilities rather than by their geographic region.
- Utilize Financial Analyzer Budget workstations to budget and forecast and perform in-depth analyses such as product profitability, customer profitability, trend analysis, what-if analysis, and production forecasting.
- Submit forecasts and budgets to the Production VP or directly to a Financial Analyst in Corporate Finance.

Some product managers are provided with Analyst workstations to keep current on company performance and to support production line decisions. These Analyst workstation users view the historic, budget, and current forecast data to properly plan and execute to the budget/forecast. Their view of the data is also very product-focused. They do not need to perform analysis or provide budget or forecast data. They use the finalized corporate data for ongoing decision making and planning; therefore, the functionality of the Analyst workstation suits their needs.


Corporate finance: In general, all Manufacturing and Consulting related workstations report directly to the Super administrator workstation in Corporate Finance. Other Financial Analyzer users in the Corporate Finance Department are either Budget or Analyst workstations, all of which report to the Super administrator workstation.
A Senior Financial Analyst or a number of Senior Financial Analysts are responsible for the collection of budget and forecast data throughout the organization. If there are a number of these positions, they act as Administrator workstations which then report to a Super administrator workstation within the Corporate Finance Department. The Senior and Junior Financial Analysts all require analysis and modeling capabilities to review and possibly modify the information coming in from other areas of the organization.
Other specialists in the Corporate Finance Department can require either the Budget or Analyst workstation functionality:
- The CFO normally requires only Analyst workstation functionality
- Budget or Forecast Analysts who concentrate primarily on forward trends and potential changes in the projected performance path require Budget workstations

The Super administrator resides in the Corporate Finance Department and the number of Sub administrator workstations it supports depends on whether data from other areas of the organization is submitted to one or many workstations within the Corporate Finance department.


Typical Financial Analyzer Configurations

Simple configuration: The simplest system configuration is made up of the following:
- A single Super administrator workstation that includes a super shared database and Task Processor
- One or more user workstations


Complex configuration: A more complex system configuration can be set up with multiple tiered structures. In a structure with multiple tiers, each level, or tier, includes the following:
- A single Super administrator workstation, that includes a super shared database and Task Processor
- One or more Administrator workstations that each include a shared database and Task Processor
- One or more user workstations that communicate with the Administrator workstation in the tier immediately above them


External Users
In addition to supporting access through workstations, Financial Analyzer supports external users. External users have access to their administrator's shared database. No client software needs to be installed on the local PC.
There are two types of external users:
- External Web users
- External Express Spreadsheet Add-In users

External Web users: External Web users access Financial Analyzer reports and graphs through a Web browser. An external Web user can also use data entry forms to enter data into the shared database. An external Web user cannot create or maintain personal documents, create or distribute data structures, or distribute data.

External Express Spreadsheet Add-In users: Express Spreadsheet Add-In users fetch data from one or more Financial Analyzer databases and work with the data in a spreadsheet environment. An Express Spreadsheet Add-In user who is an external user is limited to data manipulation; no personal database is available.


Financial Analyzer documents
You can work with four types of documents in Financial Analyzer:
1- Reports
2- Graphs
3- Worksheets
4- Data entry forms

1) Reports: You use reports to view your financial data from different perspectives and prepare presentations based on your analyses.


2) Graphs:You use graphs to create visual representations of your financial data.


3) Worksheets:You use worksheets to enter and manipulate financial data.


4) Data Entry Forms:You use data entry forms to enter data using the Financial Analyzer Web interface.


Compatibility with other products: You can use Financial Analyzer in conjunction with the following products:
1- Oracle General Ledger - You can integrate it with Financial Analyzer during installation and setup.

2-Microsoft® Excel - You can choose to install the Oracle Express Spreadsheet Add-In when installing a Financial Analyzer workstation. This enables you to fetch data from one or more Financial Analyzer databases and work with Financial Analyzer data in a spreadsheet environment.

3- Oracle Express Objects and Oracle Express Analyzer - You can then use Oracle Express Objects and Oracle Express Analyzer to develop custom applications.





Oracle General Ledger Interface
If you have installed Oracle General Ledger, Manage menu opens a cascading menu, which contains the following items:
1- Submit Load from GL -- Opens the Submit Load from GL dialog box, which enables you to log into your GL Account and load data into General Ledger either manually or automatically.
2- Refresh GL -- Opens the Refresh GL Structure dialog box, which enables you to see which database objects from General Ledger are to be added, deleted, or overwritten when you refresh your database.
3- Write Budget to GL -- Opens the Write Budget to GL dialog box, which enables you to specify the data to write back to General Ledger.

4- Add GL Dimension Values -- Opens the Add GL Dimension Values dialog box, which enables you to create dimension values for General Ledger segment values that were imported into Financial Analyzer but which had no associated balances at the time they were loaded.

5- GL Access Settings -- Opens the GL Access Settings dialog box, which enables you to specify the financial data set to be downloaded and the name of the account on the host computer where the Oracle General Ledger data reside.

(GL Interface available in Super administrator workstations.)


Working in a Stand-Alone Session
Thick client : A client is considered thick if the personal database and Personal Express are installed on the PC and a majority of processing takes place on the PC.
Thin client: A client is considered thin if the personal database and express server are installed on the server and a majority of processing occurs on the server.

About working stand-alone
You can work without being attached to the shared database if your PC is set up as a thick client. When you start the software while working on a stand-alone workstation, the software warns you that you are not able to connect to the shared database and asks if you want to work unattached. If you choose Yes, you will be running in a stand-alone session, where you are unable to receive distributions or submit your work. During a subsequent work session when you are attached to the shared database, you can submit the data that you worked on during your unattached session.
You can specify a setting in the Options dialog box that tells the system to automatically ask if you want to work unattached to the shared database. Setting this option enables users who are working away from the office to bypass a set of message boxes requesting passwords and providing warning messages.

Conditions required: You can work in a stand-alone session unattached to the shared database if the following conditions are met:
- You are working on a Super administrator, Administrator, or Budget workstation.
- You installed a personal copy of Financial Analyzer code.
- You are working on a PC that is set up as a thick client.

When you can work stand-alone: Using this feature, you can continue to work productively even if:
- You have to be away from your office and do not have the ability to communicate with the shared database.
- You are unable to connect to the shared database because of communications problems within your normal working environment.

When you cannot work stand-alone: You cannot work stand-alone if:
- You are using an Analyst workstation. This is because Analyst workstations must always attach directly to the shared database.
- You are on a workstation that does not have a copy of personal code installed.
- You are working on a PC that is set up as a thin client.


Dimensions and Dimension Values
Data is organized in Financial Analyzer using three kinds of data structures:
1) Dimensions
2) Dimension values
3) Financial data items

Financial data items are made up of dimensions, which in turn are made up of dimension values.
Dimensions: Dimensions are database objects that perform the following functions:
- They organize the data contained in financial data items
- They answer the following questions about data: what, when, and where
- They enable you to select and work with specific subsets of data


Who can work with dimensions and dimension values?

1) Administrators: As an administrator, it is your responsibility to maintain the dimensions and dimension values that your users access in the shared database that you administer. When you create or modify a dimension or dimension value and want other users to be able to access it, you must distribute the dimension or dimension value to the shared database and to other users.
2) Budget workstation users: As a Budget workstation user, you can create and modify dimensions and dimension values for personal use. You can modify dimensions and dimension values that your administrator has created for you, but you cannot save the modifications unless you assign a new name to the modified dimension or dimension value, so that you retain the original. Also note that you cannot submit data to the shared database if is associated with a dimension or dimension value that you have created in your personal database.


Ways to Set Up Dimensions


- Using dimensions in models: When the data associated with a financial data item needs to be calculated, a model is defined using one or more of the dimensions that make up the financial data item. For example, models might be based on dimensions such as Line Item and Account. Dimensions that are used in models typically aggregate over time and do not require hierarchies because Financial Analyzer provides a Time hierarchy.

- Using dimensions in hierarchies: When the data associated with a financial data item needs to be aggregated into higher and lower levels of detail, a hierarchy is defined using one or more of the dimensions that make up the financial data item. For example, hierarchies might be based on dimensions such as Organization and Product. Dimensions that are used in hierarchies typically do not aggregate over time and are not used in models.

-Using dimensions as attributes: When you need to establish a relationship between two dimensions for the purpose of selecting values of one dimension by their association with another dimension, an attribute can be defined to link them. Typically, the grouping dimension of an attribute is not used to dimension any financial data item, does not aggregate over time, is not used in a model, and does not require hierarchies.


Financial Data Items
Financial data items are database objects that are used to store or calculate financial data values. There are two types of financial data items:
1) Stored financial data items, which are used to store values
2) Formula financial data items, which are used to calculate values

1) Stored financial data items: A stored financial data item can accept data in the following ways:
- You can enter the data manually using a worksheet or a data entry form
- You can enter the data using a data loading program
- You can copy the data into one financial data item from another financial data item

2) Formula financial data items: A formula financial data item contains a formula that calculates values based on the values of one or more stored financial data items. For example, you might create a formula financial data item called Budget Variance whose values reflect the difference between two stored financial data items, Actuals and Budget.
The values of a formula financial data item are calculated and displayed in a report or graph that includes the financial data item. Because the values are based on another financial data item, whose values may change, the values of a formula financial data item are not permanently stored in the system. They are calculated based on their associated stored financial data items.
Types of formula financial data items

There are two types of formula financial data items:1- Formula Manual -- The value of the financial data item is dynamically calculated using a formula in which the data's dimensionality is specified by the user
2- Formula Automatic -- The financial data item's value is dynamically calculated using a formula in which the data's dimensionality is automatically determined from a stored financial data item

Who can work with financial data items?


1- Administrators: As an administrator, it is your responsibility to maintain the financial data items that your users access in the shared database that you administer. When you create or modify a financial data item and want other users to be able to access it, you must distribute the financial data item to the shared database and to other users.
2-Budget workstation users: As a Budget workstation user, you can create and modify financial data items for personal use. You can modify financial data items that your administrator has created for you, but you cannot save the modifications unless you assign a new name to the modified financial data item and retain the original. Also note that you cannot submit data to the shared database if it is associated with a financial data item that you have created in your personal database.


Sparse data: Sparse data occurs when many data cells in a financial data item contain NA values. For example, if a financial data item contains information that is dimensioned by Product and Market, it is likely that the data will be sparse because not all products are sold in all markets.


Importance of dimension order for financial data items:
When you create a stored financial data item, you must pay attention to the order in which you select the dimensions that comprise the financial data item. The dimension order determines how data is stored in Financial Analyzer, which in turn affects performance and storage in the Financial Analyzer database.

The order that you specify for the dimensions in your financial data items should depend on whether the data in the financial data item is dense or sparse.

1) When data is dense, the Time dimension should be the last dimension in the financial data item definition.

2) When data is sparse,

- You must have at least one dense dimension.
- Place dense dimensions first in the financial data item's definition.
- The Time dimension should always be a dense dimension.
- If you have more than one dense dimension (one of them being Time), the Time dimension can either be the last of the dense dimensions or the last of all dimensions:
a) If you will be consistently processing one period's data at a time for a financial data item, placing the Time dimension last may improve load and solve performance.
b) If you will be consistently processing a time series, placing the Time dimension last of the dense dimensions may improve load and solve performance.

- Dimensions identified as sparse should be ordered according to their number of dimension values, with dimensions with more values coming before those with less. For example, if a fi nancial data item has four dimensions: Account Organization, Product, and Time, and the relationship between Account, Organization, and Product is sparse, then the order of the dimensions should be:


Hierarchies
Hierarchies are tree-like organizational structures that you can use to relate the values of dimensions in your database. Hierarchies enable the data associated with dimension values to be aggregated at various levels along the structure. Dimensions that are associated with hierarchies in this way are called embedded total dimensions because the levels of aggregation are embedded in the dimension's values. Typically, these dimensions include Time, Product, and Organization, but you can define hierarchies for any dimension in your system.


Parent and child values: The relationships between the various values are referred to as though they were part of a family tree. Each dimension value in a hierarchy (except the top-most value) has a parent value, which is the value directly above it in the structure. The dimension values directly below a parent are called its children.


Sibling values: Each parent value can have any number of children. Dimension values that have the same parent are called siblings.


Descendant and ancestor values: Each child value can also have children of its own, and so on. Multiple levels of dimension values that roll up to a common value are called descendants of that value, and the value itself is known as the ancestor of the descendent values.


Leaf values: In a hierarchy, any dimension value that has no children is called a leaf dimension value. Leaf dimension values are the only dimension values for which you can input data for a hierarchy. The data for each non-leaf dimension value is consolidated from its children.


Attributes
Attributes establish relationships between the values of two dimensions in such a way that the values of one dimension (a grouping dimension) can be used to group multiple values of the other dimension (a base dimension). Each value of the grouping dimension serves as a characteristic, or attribute, that applies to multiple values of the base dimension.

Attributes facilitate the process of selecting data for documents. When selecting data by attribute, you can choose any number of values of the base dimension by specifying a single value of the grouping dimension. This eliminates the need to specify each value of the base dimension in a separate operation.

Grouping options: You can create attributes that group related data in many different ways, such as by product type, by time period, or even by user. For example, an administrator could create an attribute called BudgetWest that includes all Budget workstation users in the West division. The administrator could then distribute data specific to Budget Workstation users in the West division, without having to select them all individually.


Attribute Types
Financial Analyzer supports two types of attributes:
1) One-to-many -- A relationship where multiple values of a base dimension are related to a single value of a grouping dimension.
2) Many-to-many -- A relationship where multiple values of a base dimension are related to multiple values of a grouping dimension.

1) One-to-many attributes: Establish a relationship between the values of two dimensions where each value of a grouping dimension is related to multiple values of a base dimension.
Simplify the process of selecting data by enabling you to specify a single value of the grouping dimension to select many values of the base dimension.

2) Many-to-many attributes: Establish a relationship between the values of two dimensions where multiple values of a grouping dimension are related to multiple values of a base dimension.
- Simplify the process of selecting data by enabling you to specify a single value of the grouping dimension to select many values of the base dimension.
- Provide an additional feature for refining your data selection; because the base dimension values can be linked to multiple values of the grouping dimension, the grouping dimension values provide a context for selecting data.


Selector: The ability to select the precise information that you want to work with is a key feature of Financial Analyzer. A data selection tool, referred to as the Selector, supports the data selection function. The Selector:
- Gives you flexible access to your data and to database objects that you use in Financial Analyzer.
- Provides a set of tools that enable you to easily select groups of related data.


Models
Models are sets of up to 8,000 interrelated equations that can be used to calculate new data values. They can also be used in worksheets for performing what-if analyses. Models are:
- Database objects that you create and maintain
- Separate from the financial data items whose data they calculate

To use a model to calculate new data for a financial data item, you include the model in a solve definition, and associate the solve definition with a financial data item. You then run the solve definition to calculate the data. The same model can be used to calculate data for multiple financial data items, as long as they have the same dimensions.

Financial Analyzer models can be used to manage a wide range of financial data issues including:
- Simple relationships between dimension values
- Complex reference calls involving data stored in separate data cubes
- Simultaneous equations where the sequence of multiple calculations is essential to deriving the desired results

Who can work with models?
1-Administrators: As an administrator, it is your responsibility to maintain the models that your users access in the shared database that you administer. When you create or modify a model and want other users to be able to access it, you must distribute the model to the shared database and to other users. Typically, administrators create and distribute the basic line item models for their groups.
2- Budget workstation users: As a Budget workstation user, you can create and modify models for your own personal use. You can modify models that your administrator has created for you, but you cannot save the modifications unless you assign a new name to the modified model, retaining the original.


Specifying how simultaneous equations are solved?
A simultaneous equation occurs when an equation in a model indirectly depends on itself as the result of the dependencies among other equations in the model. A dependency occurs when the expression on the right-hand side of the equal sign in one equation refers to the assignment target of another equation.
You control how simultaneous equations are solved by selecting options in the Model Options dialog box. The model options enable you to specify the following:
- The solution method to use
- The factors to use in testing for convergence and divergence
- The maximum number of iterations to perform
- The action to take if an equation diverges or fails to converge


Model Equation Syntax: Model equations can include operators, numeric constants, and condition statements. You can also include functions.

Operators: Operators include the unary minus symbol (-) and the standard binary operators for addition (+), subtraction (-), multiplication (*), and division (/). Conventional rules for evaluating algebraic expressions apply.
If a formula contains multiple subexpressions (distinguished from the main expression by parentheses), the subexpressions are evaluated first; then the main expression is evaluated.
Operators are evaluated from left-to-right using the conventional order of precedence: unary operators (negative symbols) are evaluated first, followed by multiplicative operators (*,/), followed by additive operators (+,-).

Numeric Constants: Numeric constants are real numbers (decimal numbers) or integers (non-decimal numbers).
Real numbers-
- Have a decimal point with digits on both sides
- Can begin with the unary minus symbol (to indicate a negative value)
- Can include exponential notation (d, D, e, or E)

Integers-
- Are whole numbers
- Can include the unary minus symbol to indicate a negative value
- Do not include a decimal point or exponential notation


Condition statements: You can use models to derive data based on certain conditions. You must use the condition statements IF, THEN, and ELSE. All three statements are required.


When typing a command or equation into a model, you can continue it onto another line by ending the partial command with a hyphen and then continuing on the next line.
(Financial Analyzer models are limited to one command per If statement)


Referring to another financial data item: When referring to another financial data item, you must create an alias financial data item. In models, you cannot reference financial data items directly; you must always refer to them using their alias. Although the model will compile if a financial data item is referenced directly, a solve that is based on the model will not run.


Modeling Functions: Financial Analyzer has many functions that you can use to make calculations and analyze data. You can use functions to perform the following tasks:
- Calculate totals and moving totals, averages, and moving averages
- Reference values from different time periods or derive data based on other line item values
- Compute logs, square roots, absolute values, and random numbers
- Calculate statistical and financial functions

To use a function, you type its name and, in parentheses, some additional information. Each piece of information needed by a function is called an argument.


Advanced mathematical functions: Advanced mathematical functions operate on each dimension in the expression. The dimensions of the result are the union of the dimensions of the inputs.

ABS - Calculates an absolute value
INTPART - Calculates the integer part of a value
LOG - Calculates the natural logarithm
LOG10 - Calculates the logarithm base 10
MAX - Calculates the maximum between 2 expressions
MIN - Calculates the minimum between 2 expressions
RANDOM - Calculates a random number
REM - Calculates the remainder after a division
SQRT - Calculates the square root


Most advanced mathematical functions operate on a single numeric variable, but the MAX and MIN functions make comparisons between the values of two variables. For dimensioned variables, the MAX and MIN functions compare each value of one variable with the corresponding value of the other variable.


Time-series functions: The time-series functions retrieve and perform calculations on values from a previous or future time period.

CUMSUM - Calculates cumulative sums over time
LAG - Calculates the value for a previous time period
LAGABSPCT - Calculates the percent difference between current and previous values and indicates the direction of change
LAGDIF - Calculates the difference between current and previous values
LAGPCT - Calculates the percent difference between current and previous values
LEAD - Calculates the value for a subsequent time period
MOVINGAVERAGE - Calculates a series of averages over time
MOVINGMAX - Returns a series of maximum values over time
MOVINGMIN - Returns a series of minimum values over time
MOVINGTOTAL - Calculates a series of totals over time

The data you retrieve with a time-series function is usually dimensioned by a time dimension, such as MONTH, PERIOD, or YEAR. LAG and LEAD actually can retrieve data of any type, but the other time-series functions handle numeric data only.
The LAG, LAGDIF, LAGPCT, LAGABSPCT, and LEAD functions let you compare data for the time dimension values in the current status with data from a previous or future time period. You specify the data expression you want to analyze, the number of time periods the function should go back or forward for the comparison, and the time dimension. LAG and LEAD simply return the past or future value.
The LAGDIF and LAGPCT functions make the most commonly used types of comparisons, that is, the difference and the percent difference, between the current data and the comparison value.
The moving functions (such as MOVINGTOTAL or MOVINGMAX) return a value for each time period in the status of a time dimension. The value is based on the data for a range of time periods that precede, include, or follow the period for which the value is being calculated. The range is always relative to the current period, so the range is always moving forward as you process each time value in the current status.

Financial functions: The financial functions provide standard calculations needed for financial analysis.

DEPRDECL - Calculates declining-balance depreciation
DEPRSL - Calculates straight-line depreciation
DEPRSOYD - Calculates sum-of-year's-digits depreciation
FINTSCHED - Calculates the interest on a series of fixed-rate installment loans
FPMTSCHED - Calculates payments for a series of fixed-rate installment loans
IRR - Calculates the internal rate of return for a stream of cash flows
NPV - Calculates the net present value of a stream of cash flows

Aggregation functions: Functions that return an aggregate value ordinarily return one value for many values of the input expression.

ANY - Tests if any values match a criterion (returns Boolean result)
AVERAGE - Calculates an average value
COUNT - Counts values that match a criterion
EVERY - Tests if every value matches a criterion (returns Boolean result)
LARGEST - Calculates the largest value
NONE - Tests if no value matches a criterion (returns Boolean result)
SMALLEST - Calculates the smallest value
STDDEV - Calculates the standard deviation using N-1
TALLY - Counts the number of dimension values corresponding to related dimension values
TCONVERT - Aggregates or allocates data based on time periods
TOTAL - Calculates a total value


Solving data
When changes are made to Financial Analyzer data, the data must be solved to ensure that it is current. Solving data can accomplish the following:
Calculate new data values for financial data items
Aggregate values along any hierarchies that have been defined for the dimensions that make up the financial data item

Solve definition: A solve definition is an information set for calculating new data for a financial data item. The elements that can make up a solve definition are models, hierarchies, and financial data items.
You can use a solve definition to:
- Associate stored financial data items with sets of interrelated equations called models, for the purpose of calculating data
- Associate stored financial data items with dimensional hierarchies for the purpose of aggregating data
- Use both models and hierarchies in combination with the same financial data item so that you can calculate new data for that item and aggregate it along a hierarchy or hierarchies

Group solve definition: A group solve definition is a mechanism for solving large quantities of data in multiple financial data items by running a single process. A group solve definition can combine solve definitions and copy data profiles, and run them in a specific order to calculate and aggregate data for any number of financial data items.
You can use group solve definitions to perform complex sets of calculations that need to be completed on a periodic basis. For example, you can set up group solve definitions to solve all of the financial data items that are affected by a particular occurrence in your business cycle.

Reasons to solve data: You solve the data in a financial data item after you have performed any of the following actions:
1- Changing or adding an equation in a model for a line item associated with the financial data item
2- Changing the aggregation type of a line item dimension associated with the financial data item 3- Changing or adding a hierarchy for a dimension associated with the financial data item
4- Adding new time periods to your database
5- Adding new dimensions to your database
6- Adding new financial data items to your database
7- Changing the current time period for your database
8- Refreshing the financial data item after adding new data
9- Entering or changing data for the financial data item through a worksheet, a data entry form, or a copy data event

[Because solve definitions and group solve definitions perform calculations or aggregations on actual stored data values, you can run them only on stored financial data items. You cannot run solve definitions or group solve definitions on formula financial data items because formula financial data items contain no actual data values. ]


Solving versus recalculating data: Solving data differs from recalculating data in that solves are performed on models, which are defined using specific financial data items. When you run a solve, it is performed for all financial data items in the model.
When you recalculate data, the recalculation is performed only on the dimensions currently in status in the worksheet.

Who can create solve definitions?
1- Administrators: As an administrator, it is your responsibility to maintain the solve definitions that your users access in the shared database that you administer. When you create or modify a solve definition and want other users to be able to access it, you must distribute the solve definition to the shared database and to other users.
2- Budget workstation users: As a Budget workstation user, you can create and modify solve definitions and group solve definitions for personal use. You can modify definitions that your administrator has created for you, but you cannot save the modifications unless you assign a new name to the modified solve definition, retaining the original.


What happens when data is submitted?
Each time a Budget workstation user submits data (or the case of an Analyst workstation user, saves data) for the financial data item, the software automatically initiates the appropriate solve definition or group solve definition to recalculate the data.
The dimension values in status when the solve or group solve takes place is determined by the intersection of the submit status and the solve definition status.

1) IF the solve profile is a solve definition THEN . . .the status set before the solve is the intersection of the status of the submit with the status set in the solve definition.

2) IF the solve profile is a group solve definition THEN . .then the status set before each solve definition in the group is:
a) The intersection of the status of the submit with the status set in the solve definition, if the financial data item in the solve definition is one that was used in the submit.
b) The status set by the solve definition if the financial data item in the solve definition was not used in the submit. 
 
 

Financial Analyzer - II

Transferring Structures and Data




How Information Flows through Financial Analyzer?


1) Data flow: Financial Analyzer has a multi-layered, or tiered, structure that follows the reporting structure of the organization or group of organizations that it supports. Data flows both upward and downward through this system in a specific controlled manner. Administrators can ensure the integrity of the data at each level and enable the users that they support to have access to the appropriate data.
When you make data available to users, you must also give the users access to the objects in the shared database that structure the data. When you distribute objects, you provide read and write access to the data referenced by those objects.



2) Structure flow: Database structures usually flow downward through the levels of the tiered structure. The super administrator, who occupies the top-most level of the structure, creates database objects based on the needs of the organization or organizations that the system supports and makes them available to users in the next level of the structure. Lower level administrators do the same for their organizations.






Data and structure flow is monitored and controlled by the administrator at each level, who maintains the shared database for the users at the level below. The administrator at each level of the reporting structure acts as a sort of "gatekeeper," allowing the appropriate information to flow upward and downward through the system.






Methods for transferring information-
Financial Analyzer supports the following methods for transferring information.

1- Distribute Structures- Enables administrators (including the system's super administrator) to transfer database objects to their users.
2- Distribute Data- Enables administrators (including the system's super administrator) to transfer data to their users.
3- Refresh Structures- Enables users to incorporate database objects distributed to them by their administrators.
4- Refresh Data- Enables users to update the data that they view or use with the most current version of that data from the shared database.
5- Submit Data- Enables administrators and Budget workstation users to contribute data to the shared database.



Distribution: In order to give users access to the shared database that you administer, you must provide access to both the data and to the database objects that reference that data. The process that you follow to provide access to objects in your shared database is called distribution.



To whom do you distribute?



You can distribute objects and data as follows:
- To Analyst and Budget workstations in the tier immediately below you in a multiple-tier environment
- To administrator workstations in the tier immediately below you in a multiple-tier environment
- To the shared database

Importance of distribution : It is important to ensure that users have immediate access to the most current versions of objects. If there is a discrepancy between the version of an object that users are working with and the version that is in your shared database, the users will be unable to contribute data based on that object to the shared database.



[Everything that you distribute comes from your personal database. Always ensure that an object is current before distributing it to other users. ]



Distributing Structures from Administrator Workstations



1-When to distribute:The following list outlines some of the conditions under which you would need to distribute structures to the shared database and to the users that you support:
- You have created a new database object for one or more of your users.
- You have modified an existing database object, to which one or more of your users currently has access.
- You need to delete an object from the shared database and remove access to it from one or more users.
- One or more new users needs access to objects in the shared database.
- You need to provide one or more users with access to additional objects, to which they previously did not have access.





Selecting distribution items: Select the structure items that you want to distribute. You can choose one or more of the following:
- Dimension values
- Financial data items
- Hierarchies
- Documents (reports, graphs, worksheets, and data entry forms)
- Models
- Attributes
- Folders
- Solves and group solves
- Profiles for submit, refresh, and copy data
- Custom (Add-In) Menu
- Saved selections





Limits on document distribution : Do not distribute more than 3000 documents. Also, bear in mind that distributing an extremely large number of documents, such as 1000, might degrade system performance.



Distribution profiles : A distribution profile captures the information in the selection grid and saves it for reuse. You can apply the profile at a later time -- either exactly as is, or as a template for defining similar distributions. You can save the information that you enter in the Distribute Structure dialog box as a distribution profile.


Distributing structures for new dimension values: If you distribute new dimension values to your users, you must also redistribute the dimensions with which the values are associated. If you do not redistribute the dimensions along with the new dimension values, users may have trouble contributing data associated with those values back to the shared database.
When structures have the same name : If you distribute a structure to a user who has already created a structure with the same name in their personal database, the new structure will appear in the "DBA Items to Overwrite Personal" column when the user performs a Refresh Preview. When the refresh is performed, the current structure in the user's personal database will be overwritten by the newly distributed structure.
Submitting structure distributions to the Task Processor: After you specify structures for distribution, you must submit the distribution. Submitting a distribution sends it to the Task Processor.
If your system is not set up to continually run the Task Processor as a separate workstation or in the background, you must manually start the Task Processor so that the task will run.



Distributing Data from Administrator Workstations


When to distribute data: As an administrator, you can distribute slices of data that you entered into your personal database to the shared database that you maintain and to subordinate workstations. This feature enables you to control when your users receive specific types of data, such as currency translation rates, because users receive notification that they need to refresh their data, and they cannot contribute new data to the shared database until they have refreshed their personal databases.


It is important to be careful when distributing data, because the data that you distributes overwrites data in the shared database. You can only distribute data for financial data items that you specifically marked for this purpose when you created them by selecting the Distribute Data option in the Maintain Financial Data Item dialog box.



Selecting data for distribution: You choose Distribution, Distribute Data from the Manage menu to distribute slices of financial data to users and to the shared database. This opens the Distribute Data dialog box, where you can select a financial data item and define an associated data slice.


Submitting Data from Administrator Workstations

As an administrator, you are responsible for submitting data that your users submit to your shared database up to your administrator's shared database. This responsibility applies to all administrators below the super administrator level. Because the Super administrator workstation is positioned at the top-most level of the tiered structure, the shared database that the super administrator maintains contains the highest level of consolidated data.




Data submission profiles: If you periodically submit the same data, you can save the information in the Submit Data dialog box as a data submission profile. A data submission profile captures the selection information and saves it for reuse. You can apply the profile at a later time -- either exactly as is, or as a template for defining similar submissions.




Submitting Data From Budget Workstations: As a Budget workstation user, you can manipulate the data in your personal database using a worksheet and save your work without affecting the shared database. However, if you want other users to have access to your work, you must submit the data from your personal database to the shared database. For example, after you use a worksheet to prepare a budget or forecast, you can submit your work to the shared database where it can be accessed by other users.




Synchronizing your database: Before you submit data, you must refresh your personal database to synchronize it with the shared database -- that is, your personal database must contain the most current set of structures defined for you by your administrator.




Saving Data from Analyst Workstations: If you are using an Analyst workstation, you do not maintain a personal copy of data from the shared database. Rather, you access the shared database directly when you open a worksheet. Therefore, you need only save the data in the worksheet in order to submit your work to the shared database.


Reverting to saved data: If you attempt to save a worksheet from an Analyst workstation and you receive a message that states that the submission failed, you must exit from Financial Analyzer if you want to revert to the data in the shared database. For example, a submission can fail if you attempt to change the value of a dimension to which you do not have write access.




Shareable documents feature: As an administrator, you can authorize users who are below you in the reporting tier to submit documents to the shared database that you maintain. This extends the task of creating and maintaining documents to subordinate administrators and to Budget and Analyst workstation users.
A shareable document should be based on structures that reside in the shared database. Users who receive a shareable document cannot see any personal structures.




Refreshing Structures:
Super administrators and administrators define structures that are appropriate for their users and distribute those structures to the shared database and to their users. Users must then refresh structures in their personal databases so that their view of the data is consistent with their related shared database.


When automatic refresh occurs
- Budget workstation users can set the Automatic Refresh option in the Options dialog box so that a refresh process is automatically initiated if new structures are available to be refreshed when they log onto their systems. They can also choose not to set this option, which enables them to refresh structures manually.
- Analyst and Administrator workstation users must always refresh newly available structures when they log in. For these users, the Automatic Refresh option is always on.




What happens during a refresh:
Depending on the type of workstation that you are using, one of the following types of refresh processes will take place:



Super administrator workstation -- The Super administrator creates all new structures that exist at the top level of the tiered reporting structure; therefore all structures that can be refreshed come from one or more external sources. Structures from an external source are loaded directly into the Super administrator's personal database.



Administrator workstations -- Administrators can receive structures both from external sources and from the administrator at the next highest level in the tiered reporting structure. If structures have been loaded from an external source into the administrator's shared database, the refresh process brings those structures into the administrator's personal database. If structures have been distributed to the administrator, the refresh process brings those structures into the administrator's shared database.



Budget workstations -- Budget workstations refresh structures from their administrators shared database. The structures are refreshed from the administrator's shared database into the Budget Workstation user's personal database.




Data refresh data profiles: If you periodically refresh the same or similar data, you can save the information in the Refresh Data dialog box as a data refresh profile. A data refresh profile captures the selection information and saves it for reuse. You can apply the saved profile at a later time -- either exactly as is, or as a template for defining similar data refreshes.






Task Processing:




Task Processor maintains the shared database-
The Task Processor enables an administrator to maintain the shared database. All administrator distributions, solve definition processes, and data submissions to the shared database are routed to the Task Processor, where they wait in a queue until they are processed. This procedure:
- Enables multiple users to submit tasks simultaneously
- Gives the administrator the opportunity to monitor the processing events




Task processor configurations: The Task Processor can be set up in the following ways:
1) A Task Processor workstation can be defined as part of the administrator's workstation, which gives the responsibility of updating to the administrator.
2) A Task Processor can be defined as a separate workstation, which allows the administrator to continue working without being responsible for processing data submitted by users.
3) A Task Processor can be defined directly on a server.




When to run the task processor: The frequency at which data is distributed by administrators and shared among users will depend on:
1) The size of the company
2) The number of users within the administrator's database network

[To increase the efficiency of distributing and sharing data, Financial Analyzer processes all tasks using the Task Processor and tracks them using the Task queue.]




How tasks are processed: All tasks in the Task Processor are processed chronologically, which means that like tasks can overwrite each other, depending on the order in which each task is submitted for processing. As the administrator, you can reschedule tasks so that the more critical information is not inadvertently overwritten.




Function of Task queue: When tasks are submitted and processed by the Task Processor, they appear in the Task queue.
- Information you can obtain from the Task queue
- For each task, the Task queue displays the following information:
- The user who initiated the task
- The task type (such as "Distribution")
- Whether the task is pending or has been processed
- When the task was submitted for processing
- If pending, when the task is scheduled to be processed
- If pending, the task's position (priority) in the queue
- If processed, the elapsed time.
- If processed, when processing was completed




Managing User Access




- As an administrator, you can create users for the shared database that you maintain.


- Before you can create a new Windows client user, you must install the user's environment. This environment, called a component, contains shell databases and configuration files.


- Determine web sign-on method; if the system has been installed so that users will access Financial Analyzer through Oracle Self Service Applications, setting up users will involve importing user names from Oracle Applications. You will need an Oracle Applications user ID, password, and connection alias to perform this task.




User type: You can create the following type of users:
1) DBA -- An administrator who has access to a personal and shared database and to the set of features that are available in the Administrator workstation. On the web, DBA users access data from the shared database
2) Budget -- A user who has access to a personal database and to the set of features that are available in the Budget workstation. For a budget user who will access Financial Analyzer through the Windows client, you can create a budget user as thin- or thick client. On the web, budget users access data from the shared database.
3) Analyst -- A user who has access to a temporary personal database and to the set of features that are available in the Analyst workstation. For a Windows client, an analyst user's personal database must be connected to the same instance of Express Server that is connected to the shared database.
4) External -- A user who has access to the shared database of his or her administrator and to a set of features that are available through the Financial Analyzer Web interface, through the Express Spreadsheet Add-In, or through a custom application that accesses the Financial Analyzer shared database.

User names:

You can import user names from one of two sources:
- Operating system -- Choose this option to select users who will access Financial Analyzer through the Windows client. You can also use this option to select web users who will not use Oracle Applications to access Financial Analyzer.
- Oracle Applications -- Choose this option to select web users who will use Oracle Applications to access Financial Analyzer through a single sign-on.

For Windows client users and web users who will not use Oracle Applications to access Financial Analyzer, you also have the option to manually type in a user name.



Controlling Access to Shared Data
Data access restrictions: As an administrator, you are responsible for controlling read and write access to the shared database on your level in the tiered structure. By default, users have both read and write access to data in the shared database. When appropriate, you can prevent one or more users from writing to a particular slice of data to which they would otherwise have access.


Write access profile: A write access profile enables you to select a slice of data and prevent specific users or all users who have access to that data from contributing data to the shared database for values of the slice.
When you restrict users' write access to data, you prevent them from writing new data values to the dimensions in the shared database; you do not restrict the users' ability to view that data or to work with it in reports, graphs, worksheets, or data entry forms.

Following are some of the ways in which you might want to restrict access to data for a financial data item.
1) Preventing all users from accessing values of one dimension; you can deny access to one or more values of a single dimension. For example, if you want to prevent all users from changing Actuals data in the shared database for the month of June, you can deny write access to the June value of the Time dimension for the financial data item. This action denies all users write access to the June Time dimension value and to any Actuals data dimensioned by June.

2) Preventing all users from accessing a combination of values of two or more dimensions; you can deny write access to one or more values of two or more dimensions. For example, if you want to prevent all users from changing Actuals data for the organizations London, Chicago, and New York for the month of November, you can deny write access to the London, Chicago, and New York values of the Organization dimension and to the November value of the Time dimension. This action denies all users write access to those dimension values and to any Actuals data dimensioned by those values.
3) Preventing specific users from accessing dimensions
You can deny write access to one or more users. For example, you might deny write access to Actuals to users who are entering data into data entry forms over the web. This will prevent the users from overwriting data cells for Actuals.

Reports

A report is an interactive tool that enables you to view financial data from different perspectives and prepare effective presentations based on your analyses.


Report Tupes:
Financial Analyzer allows you to design your own reports. In addition, you can create two special types of reports:
1) Asymmetric report -- Combines the values of two dimensions, or the values of a dimension and a financial data item
2) Ranking/Exception report -- Identifies values meeting specific exception criteria, ranking criteria, or both exception and ranking criteria


Report objects: Reports enable you to view and format financial data based on the financial data items, dimensions, and dimension values that are defined in your personal database. Before you can create a report, your personal database must contain the required database objects. Administrators typically define database objects and distribute them to users.


Ranking and Exception reports: Ranking and Exception reports apply ranking criteria, exception criteria, or both ranking and exception criteria to a dimension. The criteria is applied to each page of data.

There are four types of ranking and exception reports:
1) Ranking report -- Displays data in an order that meets a set of criteria that you specify. For example, you might rank products by volume within a market area and time period.
2) Exception report -- Displays data associated with dimension values that meet cutoff values within parameters that you specify. For example, you might display expense items for which variance is greater than 10% within a cost center and time period.
3) Ranking-then-exception report -- Displays data in an order that meets a set of criteria that you specify, then displays a subset of the ranked data that meet cutoff values within parameters that you specify. For example, you might rank the top 100 products by volume for a year in the U.S. and then display a ranked subset of those products for which sales exceeded $1.5 million in the U.S. for the year.
4) Exception-then-ranking report -- Displays data associated with dimension values that meet cutoff values within parameters that you specify in an order that meets criteria that you specify. For example, you might display products for which sales exceeded $1.5 million in the U.S. for the second quarter and rank the top five of these products by volume change from year ago in the U.S. for the second quarter.


Exporting report data to a file: You can export data from a report to a file that can be used in other applications. You can select from three export formats (.csv, .xls, and .txt), and choose the pages or values to export. If you choose to export to the .xls file format, you can specify whether the data will be displayed in a single worksheet or in multiple worksheets.

[The .xls export uses the most recently installed version of Excel. See the Release Notes for a list of supported versions.]



Graphs

Graphs enable you to create visual representations of your financial data. You can use graphs to view your financial data from different perspectives, and you can format and print graphs for use in presentations.


Types of graphs: Financial Analyzer provides a variety of graph types that enable you to represent data in many different ways. For example, some graphs let you emphasize trends over time while other graphs let you show part-to-whole relationships.

1- Line Graph

2- Vertical Bar Graph

3- Horizontal Bar Graph

4- Bar-Line Graph

5- Area Graph

6- Pie Graph

7- Scatter Graph


Exporting graph data to a file: You can export data from your active graph to bitmap (.bmp) file.


Worksheets

A worksheet is a tool you can use to:
- Enter new financial data into your database
- Make changes to existing data
- Drill through levels of data
- Perform calculations such as growing, spreading, and increasing data


Worksheets allow you to view multiple slices of financial data from different perspectives. In addition, they allow you to change the values in data cells. You can enter data manually or have the software populate worksheet cells based on instructions that you provide.
Since worksheets enable you to enter, drill down, and perform calculations on data, they are essential for developing budgets, forecasts, and what-if analyses.

Worksheet objects: Worksheets let you view and manipulate financial data based on the financial data items, dimensions, and dimension values that are currently defined in your personal database. Administrators typically define these and other database objects and distribute them to users.


Exporting worksheet data to a file: You can export data from a worksheet to a file that can be used in Microsoft Excel and other applications. You can select from three export formats (.csv, .xls, and .txt), and choose the pages or values to export. If you choose to export to the .xls file format, you can specify whether the data will be displayed in a single worksheet or in multiple worksheets.

[The .xls export uses the most recently installed version of Excel. See the Release Notes for a list of supported versions. ]


Data Entry Forms


Data entry forms support Web-based data collection. An authorized user who has a browser can use a data entry form to accomplish the following tasks:
- Enter new data into the shared database
- Make changes to existing data in the shared database
- Calculate summary data based on data that is newly entered

Data entry forms are designed for controlled data collection. Although users can enter data and run predefined calculations, they cannot use the forms to develop budgets, forecasts, and what-if analyses.


Data entry form workflow: An administrator creates a data entry form on an Administrator workstation in the Windows client and distributes the forms to the appropriate users. The administrator can distribute data entry forms to any type of user: administrator, budget, analyst, and external.
A user accesses the data entry form through the Web interface. He or she opens the form and enters or modifies data.
When data entry is complete, the user submits the data to the shared database. If a solve definition has been associated with one or more financial data items in the form, the data is recalculated.


Prevent users from overwriting data: Data that is entered into a data entry form and submitted to the shared database might overwrite existing data. You can prevent users from overwriting data to which they should not have access by locking data at the financial data item level. For example, you might want to lock cells that are associated with data from a previous time period.
When a user views the data entry form through the Web interface, locked cells will be displayed in gray.


Folders

You can use folders to organize the documents that you create and save in your database. Folders:
- Are objects that you create and name expressly for the purpose of grouping your documents so that you can work with them more efficiently
- Enable you to organize documents logically, which means that you have complete control over the way in which your documents are arranged in each folder

For example, you might always want to print a certain group of documents together at the end of the month. You can group these documents together in a folder, so that you can print them together whenever you need to. You can also choose the order in which the documents in a folder are printed.

Storing folders: Documents are stored independently from folders in the database. This means that if you delete a folder with documents in it, only the folder is deleted, not the documents that it contains. Note, however, that if you are an administrator and you distribute a folder, its contents are distributed along with the folder. You can also add documents to more than one folder, so that you have maximum flexibility in organizing your documents in the way that makes the most sense for you.


The Financial Analyzer Web Interface


The Financial Analyzer Web interface provides access to reports, graphs, and data entry forms through a browser.

System requirements: In addition to the standard Financial Analyzer server components, the following server components must be installed:
1- Express Server, including Oracle Express Web Agent. The following configuration options must be selected in Express Configuration Manager:
- The WebAuthenticationType property on the Web Agent tab must be set to FORM.
- The RequirePasswordEncryption property on the Security tab must be set to NO and the RequiredSecurityLevel property must be set to HOST or NONE.
2- A supported Web server such as Apache.

Browser requirements: Users must have an appropriate browser installed on the PC. For information about browser requirements, refer to the release notes for Oracle Express Web Agent.


User requirements: To access Financial Analyzer through the Web interface, you must have a valid user ID. You must also be set up as a user in Financial Analyzer.



Web reports: Web reports display multi-dimensional data in tabular format. You can open and work with reports that have been distributed to you by your administrator. If you are an analyst user, you can also create and save personal reports.



Data Loaders


The data loader feature uses Oracle Express Administrator to create programs that load information and data into your personal and shared databases.
You can define programs that perform the following tasks:
1- Load values into dimensions and related dimension metadata objects
2- Load information to structure hierarchies and attributes
3- Load data into financial data items 
 
 
 

No comments:

Post a Comment

Subscribe to: Posts (Atom)

ORA-00059: Maximum Number Of DB_FILES Exceeded in 19C database

When I am adding datafile to my 19C database facing the below error. SQL> alter tablespace DATA  add datafile '/u01/data/data15.dbf...