, , , ,

System Administrator – Configuration

A system administrator is involved in setting up an Oracle Applications installation, controlling access, and ensuring smooth ongoing operation. The tasks involved in these functions are described in the Oracle Applications System Administrator’s Documentation Set, in these three volumes.

  1. Configuration
  2. Security
  3. Maintenance

This Oracle Applications System Administrator’s Guide – Configuration volume describes the tasks involved in setting up and configuring Oracle Applications. These tasks may be done once upon installation, or may also be done as needed, such as setting up a printer or customizing online help files.
Oracle Applications Tablespace Model and the Tablespace Migration Utility
The new Oracle Applications Tablespace Model (OATM) has fewer, consolidated tablespaces (twelve, including three system tablespaces: temporary, system and undo segments). Locally managed tablespaces are also supported.
The Tablespace Migration Utility is a menu-based Perl program that enables you to estimate future space requirements for the tablespaces and to migrate the Applications  database to OATM.

/by
, , , , ,

Oracle Applications Architecture(Sys Admin)

The Oracle Applications Architecture is a framework for multi-tiered, distributed computing that supports Oracle Applications products. In this model, various servers or services are distributed among three levels, or tiers.
A tier is a logical grouping of services, potentially spread across more than one physical machine. The three-tier architecture that comprises an Oracle E-Business Suite installation is made up of the database tier, which supports and manages the Oracle database; the application tier, which supports and manages the various Applications components, and is sometimes known as the middle tier; and the desktop tier, which provides the user interface via an add-on component to a standard web browser.

Centralizing the Oracle Applications software on the application tier eliminates the need to install and maintain application software on each desktop client PC, and also enables Oracle Applications to scale well with an increasing load. Extending this concept further, one of the key benefits of using the Shared Application Tier File System model (originally Shared APPL_TOP) is the need to maintain only a single copy of the relevant Applications code, instead of a copy for every application tier machine.
The Desktop Tier
The client interface is provided through HTML for HTML-based applications, and via a Java applet in a Web browser for the traditional Forms-based applications.

In Oracle Applications Release 12, each user logs in to Oracle Applications through the E-Business Suite Home Page on a desktop client web browser. The E-Business Suite Home Page provides a single point of access to HTML-based applications, Forms-based applications, and Business Intelligence applications.
Once logged in via the E-Business Suite Home Page, you need not sign on again to access other parts of the system. Oracle Applications does not prompt again for user name and password, even when you navigate to other tools and products. Oracle Applications also retains preferences as you navigate through the system. For example, if you registered in the E-Business Suite Home Page that German is your preferred language, this preference carries over whether you access Forms-based or HTML-based applications.
The Forms client applet is a general-purpose presentation applet that supports all Oracle Applications Forms-based products, including those with customizations and extensions. The Forms client applet is packaged as a collection of Java Archive (JAR)
files. The JAR files contain all Java classes required to run the presentation layer of Oracle Applications forms.
The Application Tier
The application tier has a dual role: hosting the various servers and service groups that process the business logic, and managing communication between the desktop tier and the database tier. This tier is sometimes referred to as the middle tier.
Four servers or service groups comprise the basic application tier for Oracle Applications:

  • Web services
  • Forms services
  • Concurrent Processing server
  • Admin server

Note: In Release 12, the Web and Forms services are provided by  Oracle Application Server (OracleAS) 10g. They are no longer servers in the sense of being a single process, as was the case in previous Applications releases.  It is advisable to avoid using a mixture of different platforms on your application tier. This makes maintenance easier, since only one set of patches needs to be downloaded.

The Database Tier
The database tier contains the Oracle database server, which stores all the data maintained by Oracle Applications. The database also stores the Oracle Applications online help information.
More specifically, the database tier contains the Oracle data server files and Oracle Applications database executables that physically store the tables, indexes, and other database objects for your system. The database server does not communicate directly with the desktop clients, but rather with the servers on the application tier, which mediate the communications between the database server and the clients.

/by
, , ,

Oracle Receivables Operations

Maintaining Invoice and Credit Memo Transactions
In oracle Receivables transaction can be reviewed an updated after creation regardless of whether the transaction was created manually or imported using ‘Auto Invoice’.There are exceptions to this and some system options and profile options have to be set.

If the Allow change to printed transactions system option is ‘Yes’ you can update most of the transaction information, even if the transaction has been printed. However if there is activity against the transaction, you will not be able to make changes to many of the transaction attributes. Activity includes actions such as payments, credit memos, adjustments and including transactions on a consolidated billing invoice.

After your transactions have posted to your General Ledger, you can still update most of information. Receivables maintains a complete audit trail of all the posted changes you make to your accounting entries.

Receivable does not maintain an audit trail when you change a transaction that has not been posted.

Also what can be changed depends on various attribute settings on the transaction.
In addition to updating transactions, you may find the need to delete or void a transaction. Again, there are circumstances under which deleting or voiding a transaction can be accomplished.

Transaction Field Reference
When reviewing the tables, you will notice the tables indicate the field reference in down the left side of the table with the conditions going across the rows. Within the rows is the indication as to whether this field reference can be updated or not any exceptions that must be considered. By using these tables you will resolve many of your own issues as to why a user cannot update particular field on an invoice or credit memo.

When reviewing the update table you will note there are two sections, header and line levels.

Once you save the transaction, you cannot update the transaction number.

Additionally here are some profile options and system options that effect maintaining transactions.

System options can be set as follows

Setup/System/System Options/Trans and Customers Tab

Set allow change to printed transactions to Yes

Profile Options can be set as follows

Using the system administrator responsibility

Profile/System
Site level
Query in the field for the profile of choice. Some profile options that affect maintaining transactions are

AR: Update Due
AR: Change Customer on Transaction
Allow update existing sales credits
Sequential Numbering – Make the options is not null at all levels, has to contain a value at least one level.

Delete or Void Transactions
Deleting or voiding transactions can be accomplished depending on how your administrator has setup function security on you Oracle Receivables.
If the allow change to Printed Transactions system options is set to Yes and transactions have no activity against them, then the transaction have no activity against them, then the transactions can be removed by one of the following methods:
By delete record from the edit menu. This will delete invoice and any lines.
Invoice with rules cannot be deleted but you can create a credit memo and apply it to the invoice. The credit memo will create a credit entry offsetting the invoice debit entry.
Void the invoice by changing the invoice type in the Transaction window to a type with the Open Receivables and Post to GL options set to No. This will delete the payment schedule and cancel the distributions by removing the GL Date.
Delete the payment schedule by choosing incomplete button in Transaction window. This makes the invoice inaccessible for payment or crediting.

Maintaining Transactions Navigation
Navigate to the Transactions or the Transactions summary window:

Transactions/Transactions
Query the Transaction.
Change the transaction type to ‘void’ transaction type
Save

Transaction Table Information
Invoice : When an invoice is created the Header information is written to the RA_CUSTOMER_TRX_ALL table. Changes to any of the header information such as the customer invoice line information is written to RA_CUSTOMER_TRX_LINES_ALL, RA_CUST_TRX_LINE_GL_DIST_ALL, AR_PAYMENT SCHEDULES_ALL and RA_CUST_TRX_LINE_SALEREPS_ALL.

RA_CUST_TRX_LINES_ALL holds line details, what and how much is being invoices a nd what tax is applicable.
RA_CUST_TRX_LINES_GL_DIST_ALL stores information that need to be posted across General Ledger.
AR_PAYMENT_SCHEDULES_ALL keeps running totals of the Invoice amounts for line,tax and freight. Record both the original amounts and the amounts remaining.
RA_CUST_TRX_LINE_SALEREPS_ALL stores who get credited for the sale represented by the invoice.

Credit MemoCredit memos are stored in the same tables as the invoices. RA_CUSTOMER_TRX_ALL hold the credit memo header information similar to that of the invoice credit memo line information is t stored in RA_CUST_TRX_LINES_ALL, RA_CUST_TRX_LINE_GL_DIST_ALL, AR_PAYMENT SCHEDULES_ALL, AR_RECEIVABLE_APPLICATIONS_ALL
RA_CUSTOMER_TRX_LINES ALL holds credit memo line detail information.

AR_Receivable_Applicaitons_all- stores how much of the credit memo is applied

/by
, , ,

Multiple Currencies

Revaluing Foreign Currency Balances
Asset and Liability accounts that are entered in foreign currencies must be revalued every period in accordance with FAS52 (Financial Accounting Standards). The Revaluation program adjusts the value of the balance sheet accounts based on current period exchange rates. It then generates revaluation journals with adjustments to the defined unrealized gain/loss account. The Revaluation program generates adjustments in the Functional Currency. If you have a Reporting Set of Books you must run revaluation once for each Primary and Reporting Set of Books. The Revaluation generates a revaluation batch containing a separate journal for each foreign currency. The revaluation batch automatically has its reversal period set to the next accounting period. When you run revaluation for the next accounting period, you must reverse and post the last accounting periods revaluation batch first.

You get to the Revalue balances form by following navigation path

Currency->Revaluation

Translating Foreign Currency BalancesThe Translation process translates actual and budget account balances to another currency in accordance FAS52. The translation program uses three different exchange rates: period-average, period end, and historical. The translation program translates asset and liability accounts using the period end exchange rate, ownership/stockholder equity accounts using the historical exchange rate, and revenue and expenses accounts using period average exchange rate. The period average exchange rate is the average rate of all daily rates across the entire accounting period.

The profile option GL: Owners equity transaction rule effects how ownership stockholders equity account balances are translated. If the profile option is set to PTD, the net activity accounts of the accounting period are translated, then added to the corresponding prior period balances. If the profile set to YTD the balances, not the activities are translated and the translated amounts are the YTD Balances. There is no need to add the balances to previous balances.

Navigation Currency-> Translation

Multiple Reporting Currencies
Multiple Reporting Currencies allows you to maintain accounting transactions in more than one functional currency. MRC is set up by creating one or more Reporting Set of Books.

MRC need if
Your company is located a member state of EMU and would like to report financial data, including transaction level data, in both your functional currency and the Euro.

You must regularly report financial data including transaction level data in more than one currency because your company is multinational.

MRC Works for following modules
Assets, CashManagment, Cost Management , General Ledger, Payables, Projects, Purchasing, Receivables.

MRC works differently depdning on whether you enter the transaction inn Oracle Subledger or Oracle GL. When you enter transaction in subledgers the accounting transactions are translated into the Reporting set of books as you enter the transaction. When you transfer to Oracle GL, you must transfer to both the primary set of books and the reporting set of books you should post the transferred subledgers accounting transactions to the primary set of books as well as to all reporting set of books.

When you enter transactions in GL, the journal entries entered in the Primary Set of Books are not translated immediately into any reporting Set of Books, when the Journal entries are posted
In the Primary Set of Books it will transferred to reporting Set of Books. In the reporting Set of Books you can post, revalue , translate and consolidate.

/by
, ,

Oracle Form Components

Forms Builder provides various components, such as Data Block, Items, Property Palette, Canvases and Windows, Triggers, and Program Units that enable you to create a form.

Data Block
A data block is a virtual data set that represents the database table. You need to create the associated block in the Object Navigator for every table used in the form. A data block is bound to a table or a view in a database or a set of procedures. The association of a data block and a database allows a form to manipulate the data in a database. You can create a data block manually or using the Data Block wizard.
Items
An item is an interface object that helps display information in a GUI application. It enables you to store, insert, modify, and delete information in a database. Each item belongs to a block. The items in a block are bound to columns in a base table. They display the data stored in these columns. You may also enter the data in these items for later processing. An item may need not necessarily be bound to columns of base table, such as sum of fields. These items are known as non-database items. These items are used to display information from the tables associated with base tables.
Canvases and Windows
A canvas is a physical container or a layout on which you can place items. End users interact with the items on the canvas when a form is executed. You can create a canvas manually using the Layout Editor or the Layout wizard. A canvas can be displayed in different windows.
A Window is the basic Document Interface in the Forms Builder. For each window, you must create at least one canvas. The Windows are assigned appropriate properties to determine whether the application is a Multiple Document Interface (MDI) or Single Document Interface (SDI).
You need to place the canvas in a specific window to view the canvas and the items in it, when you execute a form. By default, a canvas is assigned the window called WINDOW1. You can assign a different window using the Window property in the property palette of the canvas.
Forms Builder enables you to create the following types of canvases:

  • Content
  • Stacked
  • Tab
  • Toolbars
/by