§ About

This web log documents the daily experiences and learnings of Oracle Applications Consultants and Implementor's. OracleAppsBlog was founded by Richard Byrom, an Independent Oracle Applications Consultant and Solutions Architect. Richard Byrom Consulting can provide you with services in the following areas:

Bids and Proposals

Business Consulting and Analysis

Information Technology (IT) Strategy

Solutions Architecting

Enterprise Resource Plannning (ERP) Implementations

Writing and Presenting

This Blog has been categorised according to the different industries and modules that apply to Oracle Applications.

Finance

Wednesday, February 09, 2005

Utilising the Customer Alternate Name Field

I had a problem at a client the other day where they weren’t able to capture data in to the Customers Alternate Name Field, here’s the quick and simple solution.

In order to allow data entry in to the Alternate Name field of the Customer as indicated in the diagram below, the profile option AR: Customers - Enter Alternate Fields should be set to Yes. An alternate name would most likely be used where the customer is trading using a different name to the one shown on your records. Apparently certain reports within AR will display this alternate name if you are using it.

The validation that ADI uses for client side validation cannot dynamically create a new flexfield, only the server-side validation has been designed to dynamically create valid flex code-combinations - Bug:1924015.

The simple solution to the problem is to set the Profile Option profile Flexfields: Validate on Server to Yes. It’s also important to note that Cross-validation checking is only performed if you have this option set to Yes.

Another Metalink Note 251463.1 provides the same solution for the system allowing the upload of Disabled Accounting Flexfield segments to General Ledger via ADI.

Friday, January 21, 2005

FSG Transfer Program

The other day I came across this feature in Financial Statement Generator which I never knew existed and found to be quite useful.

FSG Transfer is a programme that you can run in General Ledger which gives you the ability to copy Financial Statement Generator (FSG) components from one environment to another. For example, you might want to transfer your FSG’s from a TEST environment to your PRODUCTION environment.

According to the Oracle General Ledger User Guide, before this report can be run, the following prerequisites should have been implemented: -

You or your System Administrator must define database links.

The Chart of Accounts in your source database must be identical to the Chart of Accounts in your target database.

Any currencies and sets of books referred to by the row sets and column sets being copied must exist in the target database.

Report details, such as budgets and encumbrance types, referred to by copied reports must exist in the target database.

You must be logged in to General Ledger and connected to the target database.

Programme Parameters

To run the report, from the file menu in General Ledger Responsibility select View > Requests and choose to run a single request entitled Program - FSG Transfer. Examples of how the parameters for this programme can be filled are as follows: -

Component Type

The following elements of an FSG can be copied between environments: -

Column Sets

Content Sets

Display Groups

Display Sets

Reports

Report Sets

Row Orders

Row Sets

All of the above

Component Name

The name of the component selected above should be entered if you are copying a single component mentioned above. If you are copying all components you do not need to specify a name.

Source DB Chart of Accounts

The exact name of the Chart of Accounts from which you want to copy report objects.

Target DB Chart of Accounts

The exact name of the Chart of Accounts to which you want to copy report objects.

Source

The name of the source database from which you are copying. This field will not have a List of Values (LOV) unless you have defined database links. To define database links within the General Ledger Responsibility go to Setup > System > Database Links and create a New Database Link (if you have any uncertainty about what parameters to enter here contact your DBA, typically you should be able to extract the connect string from the TNSNAMES.ORA file).

UAB’s vision for a new administrative computing system at UAB has reached a major milestone with the implementation of Oracle Human Resources (HR) applications on January 20, 2004. The Finance implementation has been delayed to October 2004. By exploring these pages, you will gain knowledge about the STEPS Project and the new Oracle system.

A suite of Oracle HR modules are being implemented for the management of all UAB personnel. The advantage of the new system is the creation of an integrated information environment, and improvement in the quality of human resources data, thereby providing better HR services to individuals.

Data currently viewed in the Human Resource System (HURS) will be found using the ACT form (screen) in Oracle. Several paper processes will be replaced with new electronic processes, such as new hire appointments, salary reclassifications, and effort reporting.

Specific features of the new system include a web-based self-service environment for all employees and an electronic administrative processing environment for staff to conduct day-to-day business. Also, seven-digit employee numbers will replace social security numbers as a means of identifying UAB employees.

HR modules to be implemented as part of the STEPS project are:

Core Human Resources Management

Advanced Benefits

Payroll and Time and Labor

Labor Distribution and Effort Reporting

This area of the site also discusses self service and you can download a copy of the new HR Organizational Hierarchy codes.

UAB is preparing to replace its existing financial accounting system (EFS) with the Oracle Financials suite of applications to create an integrated information environment that is web based and flexible to handle future growth. With the implementation of the Oracle system, UAB will have a new Oracle General Ledger accounting structure and a new Oracle Grants accounting structure.

Data currently viewed in FAS will be found in Oracle and transactions currently processed using EFS will be processed using Oracle. What are currently called “account numbers” in FAS will be referred to as “account strings” in Oracle and the format of these account strings differs from the current account numbers. Prior to implementation, a “cross-walk table” will be provided matching FAS account numbers to Oracle account strings where possible. Also, the object codes will change from a four-digit to a seven-digit number. The new Oracle object codes can be viewed from this site.

Finance modules to implemented as part of the STEPS project are:

General Ledger

Purchasing

Accounts Payable

Grants/Plant Accounting

Accounts Receivable (for Sponsored Projects only)

This section of the site has a variety of documents and presentations you can download that relate to the new Oracle General Ledger accounting structure and Oracle Grants accounting structure. Briefly stated, the new chart of accounts will contain six segments as follows: -

Account - Identifies primary activity for which money is being spent (7 digits)

SubAccount - An account can be broken down to track one or more activities, tasks, time periods, or allocations (3 digits)

Balancing - Indicates the level at which UAB chooses to carry a balance sheet, whether for internal or external purposes (9 digits)

Organization - Identifies the organizational unit with which has primary fiscal responsibility for the Account String (9 digits)

Future - Reserved to meet future requirements (4 digits)

Object Code - Categorizes the nature of the dollars as a specific type of revenue, expense, asset, etc. (7 digits)

Under this section of the site you will find course descriptions, online course manuals and online simulation courses (training videos). Online course manuals are available for the following modules: -

Finance

Navigation

ACT (Appoint, Change and Terminate)

TEL(Time, Entry and Labour)

Self Service

The online simulations are quite good for those who are just starting to earn Oracle Applications. The following simulations are available: -

Here you will find the specifications for a Desktop PC which needs to run Oracle Applications. There is also a Go-Live Checklist which is designed to ensure that users are prepared for utilising Oracle Applications.

Here you will find a listing of End User responsibilities for Oracle HRMS at the University. For each responsibility a summary of access areas is documented. If a user does not have access to the system the appropriate forms are made available to apply for access.

Thursday, July 15, 2004

Business need for Chart of Accounts - An Overview

The Chart of Accounts (COA) is the account structure the organization uses to record transactions and maintain financial account balances. Oracle General Ledger defines the COA structure in the Accounting Flexfield. The structure enables the organization to categorize accounting information during the recording process. The structure is comprised of multiple uniquely defined segments. Each segment contains a list of values, such as the list of Cost Centers or Natural Accounts. The various combinations of the segment values represent the unique account combination to which accounting transactions are posted and account balances are maintained.

When defining the Accounting Flexfield (COA) segments, Oracle requires one segment be designated as the balancing segment and one segment be designated the account segment. The balancing segment identifies an entity requiring a self-balancing trial balance, such as Company. The Account segment identifies the segment used to produce the Financial Statements such as Cash, Accounts Payable, or Revenue. Additionally, Oracle allows the designation of a cost center segment. The cost center segment identifies functional areas of the business such as Finance and Marketing. The cost center segment value is primarily used for reporting in Oracle Assets or Projects.

There are several constraints that should be adhered to when defining the organization’s COA in Oracle

COA structure must contain at least 2 segments (Balancing and Natural Account) and no more than 30 segments

Total length of segment combinations cannot exceed 240 characters

Each Natural Account value must have only one Account Type (e.g. Expense, Asset, etc…)

Benefits of Common Chart of Account Structure

Some of the benefits of using a Common Chart of Accounts are the following: -

Drives consistency of reported information across business units and ensures compatibility

Reduces the effort to consolidate information to satisfy management requests

Reduces reconciliation procedures

Provides easier benchmarking between different business units/territories

Allows ability to leverage staff between different business units

Reduces learning curve due to commonality

Provides a framework to introduce financial shared services

Chart of Accounts Impact on Reporting

The primary purpose of the General Ledger is financial reporting and financial analysis. The Chart of Account structure defines the nature, ranges, and groupings of information available for reporting and inquiry. Reporting is generated by ranges and groupings of values for one or more segments. Management must define the dimensions by which financial data will be analyzed and reported and ensure those dimensions are reflected in the segments contained within the COA structure.

Chart of Accounts Best Practices and Development Guidelines

Structure

Determine the scope that the chart of accounts must support. The scope should begin with GAAP reporting requirements followed by management reporting requirements. Common examples of Management reporting requirements are Geographic Regions, Product Line reporting, Activities, and Cost Centers.

Team members in the chart of accounts design process should be functionally aligned as opposed to geographically aligned. This facilitates the aim of developing a standard COA across global boundaries.

Design a flexible chart of accounts that will reflect current business processes and accommodate organizational changes in the future. Consider future segments if involved in a high-growth, dynamic industry or environment.

Each measured dimension of the business should be a separate segment. Segments used for more than one dimension limit the use of standard default values and complicates reporting by making data difficult to isolate. In addition, it precludes the user from using more than one dimension in an individual transaction. This also complicates the processing of consolidations and allocations, validation/security rules, and reporting.

The resulting COA structure should be more horizontal in design with reporting across segments instead of using individual values for multiple dimensions.

Values

Limit detail in values and report on information in the appropriate source (subledger) system unless the data is scattered among multiple systems. (e.g. create the minimum number of accounts for GAAP reporting of PP&E. Create Asset Categories in Oracle Assets that “roll-up” to the respective natural accounts and report detail out of the Assets subledger)

Product segments should be carefully considered for inclusion in the Accounting Flexfield Structure if there are extensive product lines. Try to identify major product lines for meaningful reporting in the General Ledger and look to the relevant subledger for detail reporting.

Project segments may be considered if not using Project Accounting. Project Segments are not recommended if Project Accounting is to be used. All project reporting should be generated from the Projects subsystem.

Carefully consider usage of summary accounts to capture information. Balances are stored at both the detail and summary levels and can negatively impact some concurrent processes. Summary Accounts may significantly improve FSG reporting.

Avoid intelligent numbering (Assigning a meaning to every digit of a segment value). This complicates allocations and reporting.

Avoid using dependent segments. Allocations work off independent segments and may not function properly with dependent segments.