Monday, March 30, 2009

Move controlfiles from the Filesystem to ASM

1. Identify the location of the current controlfile:

SQL> select name from v$controfile;
NAME
——————————————————————————–
/opt/app/oracle/product/11/db_1/dbs/standby_control.ctl’

2. Shutdown the database and start the instance:
SQL> shutdown normal
SQL> startup nomount

3. Use RMAN to move the controlfile to ASM :

rman target /

RMAN> restore controlfile to ‘+DATA’ from ‘/opt/app/oracle/product/11/db_1/dbs/standby_control.ctl’;

Starting restore at 30-MAR-09
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=539 device type=DISK
channel ORA_DISK_1: copied control file copy
Finished restore at 30-MAR-09

RMAN> exit

We are only specifying the name of the diskgroup, so Oracle will create an OMF (Oracle Managed File).
Use ASMCMD or sqlplus to identify the name assigned to the controlfile

4. On the ASM instance, identify the name of the controlfile:

Using ASMCMD:
$ asmcmd
ASMCMD> pwd
+data/standby/controlfile
ASMCMD> ls
current.1384.681888623
current.1385.681888685

This is just the name assigned for the identical copy of the current controlfile.

5. On the database side:

* Modify init.ora or spfile, replacing the new path to the init parameter control_files.
* if using init.ora, just modify the control_files parameter and restart the database.

6. start the instance.

Verify that new control file has been recognized. If the new controlfile was not used, the complete procedure needs to be repeated.

7. SQL> show parameter control_file

NAME TYPE VALUE
———————————— ———– ——————————
control_file_record_keep_time integer 7
control_files string +DATA/standby/controlfile/curr
ent.1384.681888623, +DATA/standby/controlfile/current.1385.681888685

NOTE : Steps 3 to 5 Could be repeated to multiplex the contolfiles to more than one on each diskgroup .

Sunday, March 29, 2009

Copy ASM Files with DBMS_FILE_TRANSFER

You can copy ASM Files using DBMS_FILE_TRANSFER pl/sql package. Lets see how to copy an archive log file from ASM storage to local disk.

RMAN> sql 'alter system switch logfile';
sql statement: alter system switch logfile

RMAN> crosscheck archivelog all;
released channel: ORA_DISK_1allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=129 instance=rdba1 devtype=DISKvalidation succeeded for archived logarchive log filename=+FRA/rdba/archivelog/2009_03_29/thread_1_seq_2197.485.682769833 recid=490 stamp=682769833Crosschecked 1 objects

RMAN> exit
Recovery Manager complete.

C:\>sqlplus / as sysdba

SQL> create directory XXARCsrc as '+FRA/rdba/archivelog/2009_03_29';
Directory created.

SQL> create directory XXARCdest as 'C:\';
Directory created.

SQL> grant read, write on directory XXARCsrc to public;
Grant succeeded.

SQL> grant read,write on directory XXARCdest to public;
Grant succeeded.

SQL> execute dbms_file_transfer.copy_file('XXARCsrc','thread_1_seq_2197.485.682769833','XXARCdest','arc2197');

Now look for the archive file arc2197 in local disk in c-drive.

Note: This way you can copy any file from ASM to the disk.

To view the files on ASM use the ASMCMD tool,

SET oracle_home=C:\oracle\product\10.2.0\asm_1
SET oracle_sid=+ASM1

C:\>asmcmd
ASMCMD> ls
/BKP
/DATA
/FRA

ASMCMD> cd data
ASMCMD> ls
RDBA/

ASMCMD> cd rdba

C:\>set oracle_home=C:\oracle\product\10.2.0\db_1

C:\>set oracle_sid=+ASM1

C:\>asmcmd
ASMCMD> ls
BKP/
DATA/
FRA/

ASMCMD> cd data

ASMCMD> ls
DB_UNKNOWN/
RDBA/

ASMCMD> cd db_unknown
ASMCMD> ls
PARAMETERFILE/

ASMCMD> cd parameterfile

ASMCMD> ls
SPFILE.268.665669211

ASMCMD> cd ..
ASMCMD> cd ..
ASMCMD> cd rdba

ASMCMD> ls
CONTROLFILE/
DATAFILE/
ONLINELOG/
TEMPFILE/
spfilemol.ora

ASMCMD> cd datafile

ASMCMD> ls
ARCHDATA.279.667315727
AUTOSCAN.278.667315457
COMPANY.275.667315065
COMPANY_IDX.273.667314429
EMPLOYEE.271.667314047
EMP_IDX.284.667316721
EXAMPLE.264.663930173
INDX.290.667317683
INDX_MOL1.269.667313539
INDX_MOL2.281.667316185
MAIN_MOL.277.667315275
MAIN_MOL.282.667316309
MOL_DNRD.289.667317613
MOL_DNRD_INDEX.288.667317545
OTHERS.280.667315911
OTHER_IDX.276.667315173
SYSAUX.257.663930059
SYSTEM.256.663930057
TEMPORARAY.287.667317499
TNT.272.667314321
TNT_IDX.274.667314579
TNT_IDX1.291.667317753
TOOLS.285.667317351
TUNE_INDEX.270.667313981
UNDOTBS1.258.663930059
UNDOTBS2.265.663930307
USERS.259.663930059
USR.286.667317429
VISA_CANCEL_CHNG.283.667316489

Monday, March 16, 2009

Apps 11i Technical Interview Question/Answers

How to know if a specific patch is installed or not?
SELECT * FROM AD_BUGS WHERE BUG_NUMBER=x;
Here substitute x with patch number, and if the query returns a value means the patch is already applied.

What is US directory in $AD_TOP or under various product TOP’s . US directory is defauly language directory in Oracle Applications. If you have multiple languages Installed in your Applications then you will see other languages directories besides US, that directory will contain reports, fmx and other code in that respective directory like FR for France, AR for arabic, simplifies chinese or spanish.

What are main concurrent Manager types.
ICM - Internal Concurrent Manager which manages concurrent Managers
Standard Managers - Which Manage processesing of requests.
CRM - Conflict Resolution Managers , resolve conflicts in case of incompatibility.

What is difference between ICM, Standard Managers & CRM in Concurrent Manager?
ICM stand for Internal Concurrent Manager, which controls other managers. If it finds other managers down , it checks & try to restart them. You can say it as administrator to other concurrent managers. It has other tasks as well.
Standard Manager These are normal managers which control/action on the requests & does batch or single request processing.
CRM acronym for Conflict Resolution Manager is used to resolve conflicts between managers & request. If a request is submitted whose execution is clashing or it is defined not to run while a particular type of request is running then such requests are actioned/assigned to CRM for Incompatibilities & Conflict resolution.

Where is Concurrent Manager log file location.
By default standard location is $APPLCSF/$APPLLOG, in some cases it can go to $FND_TOP/log as well

What is multi node system?
Multi Node System in Oracle Applications 11i means you have Applications 11i Component on more than one system. Typical example is Database; Concurrent Manager on one machine and forms, Web Server on second machine is example of Two Node System.
ICM stand for Internal Concurrent Manager, which controls other managers. If it finds other managers down , it checks & try to restart them. You can say it as administrator to other concurrent managers. It has other tasks as well.
Standard Manager These are normal managers which control/action on the requests & does batch or single request processing.
CRM acronym for Conflict Resolution Manager is used to resolve conflicts between managers & request. If a request is submitted whose execution is clashing or it is defined not to run while a particular type of request is running then such requests are actioned/assigned to CRM for Incompatibilities & Conflict resolution.

Where is Concurrent Manager log file location.
By default standard location is $APPLCSF/$APPLLOG, in some cases it can go to $FND_TOP/log as well

What is multi node system?
Multi Node System in Oracle Applications 11i means you have Applications 11i Component on more than one system. Typical example is Database; Concurrent Manager on one machine and forms, Web Server on second machine is example of Two Node System.

What is .dbc file, where its stored, what use of .dbc file?
dbc as name says is database connect descriptor file which stores database connection information used by application tier to connect to database. This file is in directory $FND_TOP/secure also called as FND_SECURE

How to determine Oracle Apps 11i Version?
Select RELEASE_NAME from fnd_product_groups;
You should see output like
RELEASE_NAME
———————–
11.5.9 or 11.5.10.2

Whats is TWO_TASK in Oracle Database?
TWO_TASK mocks your tns alias which you are going to use to connect to database. Lets assume you have database client with tns alias defined as PROD to connect to Database PROD on machine teachmeoracle.com listening on port 1521. Then usual way to connect is sqlplus username/passwd@PROD ; now if you don’t want to use @PROD then you set TWO_TASK=PROD and then can simply use sqlplus username/passwd then sql will check that it has to connect to tnsalias define by value PROD i.e. TWO_TASK

What is GWYUID ?
GWYUID , stands for Gateway User ID and password. Usually like APPLSYSPUB/PUB
Where GWYUID defined & what is its used in Oracle Applications?
GWYUID is defined in dbc i.e. Database Connect Descriptor file. It is used to connect to database by think clients

How to check number of forms users at any time?
Forms Connections initiate f60webmx connections so you can use
ps -ef grep f60webmx wc -l

What is 0 & Y in FNDCPASS, FNDLOAD or WFLOAD?
0 & Y are flags for FND Executable like FNDCPASS & FNDLOAD where
0 is request id (request ID 0 is assigned to request ID’s which are not submitted via Submit Concurrent Request Form.
‘Y’ indicates the method of invocation. i.e. it is directly invoked from the command-line not from the Submit Request Form.

If your system has more than one Jinitiator, how will the system know, which one to pick. ?
When client makes a forms connection in Oracle Applications, forms client session uses configuration file defined by environment variable FORMS60_WEB_CONFIG_FILE also called as appsweb config file. These days this file is of format appsweb_$CONTEXT.cfg The initiator version number defined by parameter jinit_ver_name in this file will be used.

What are .ldt & .lct files which you see in apps patch or with FNDLOAD?
ldt & .lct stands for Loader datafile & Loader configuration files, used frequently in migrating customization, profile options, configuration data, etc.. across Instances.

What is dev60cgi & ifcgi60?
cgi stands for Common Gateway Interface and these are Script Alias in Oracle Apps used to access forms server . Usually Form Server access directly via http://hostname:port/dev60cgi/ifcgi60

What is difference between COMPILE_ALL=SPECIAL and COMPILE=ALL while compiling Forms?
Both the options will compile all the PL/SQL in the resultant .FMX, .PLX, or .MMX file but COMPILE_ALL=YES also changes the cached version in the source .FMB, .PLL, or .MMB file. This confuses version control and build tools (CVS, Subversion, make, scons); they believe you’ve made significant changes to the source. COMPILE_ALL=SPECIAL does not do this.

What is ps -ef or ps command in Unix ?
ps is unix/linux utility or executable to find status of process. Used mainly to find if services/process is running or not.

Monday, March 9, 2009

Oracle Clusterware - Voting Disk

What is a voting disk?
A voting disk is a file that manages information about node membership.

What are the administrative tasks involved with voting disk?
Following administrative tasks are performed with the voting disk :
1) Backing up voting disks
2) Recovering Voting disks
3) Adding voting disks
4) Deleting voting disks
5) Moving voting disks

How do we backup voting disks?
1) Oracle recommends that you back up your voting disk after the initial cluster creation and after we complete any node addition or deletion procedures.
2) First, as root user, stop Oracle Clusterware (with the crsctl stop crs command) on all nodes. Then, determine the current voting disk by issuing the following command:
crsctl query votedisk css
3) Then, issue the dd or ocopy command to back up a voting disk, as appropriate.

Give the syntax of backing up voting disks:-
On Linux or UNIX systems:
dd if=voting_disk_name of=backup_file_name
where,
voting_disk_name is the name of the active voting disk
backup_file_name is the name of the file to which we want to back up the voting disk contents
On Windows systems, use the ocopy command:
ocopy voting_disk_name backup_file_name

What is the Oracle Recommendation for backing up voting disk?
Oracle recommends us to use the dd command to backup the voting disk with aminimum block size of 4KB.

How do you restore a voting disk?
To restore the backup of your voting disk, issue the dd or ocopy command for Linux and UNIX systems or ocopy for Windows systems respectively.
On Linux or UNIX systems:
dd if=backup_file_name of=voting_disk_name
On Windows systems, use the ocopy command:
ocopy backup_file_name voting_disk_name
where,
backup_file_name is the name of the voting disk backup file
voting_disk_name is the name of the active voting disk

How can we add and remove multiple voting disks?
If we have multiple voting disks, then we can remove the voting disks and add them back into our environment using the following commands, where path is the complete path of the location where the voting disk resides:
crsctl delete css votedisk path
crsctl add css votedisk path

How do we stop Oracle Clusterware?When do we stop it?
Before making any modification to the voting disk, as root user, stop Oracle Clusterware using the crsctl stop crs command on all nodes.

How do we add voting disk?
To add a voting disk, issue the following command as the root user, replacing the path variable with the fully qualified path name for the voting disk we want to add:
crsctl add css votedisk path -force

How do we move voting disks?
To move a voting disk, issue the following commands as the root user, replacing the path variable with the fully qualified path name for the voting disk we want to move:
crsctl delete css votedisk path -force
crsctl add css votedisk path -force

How do we remove voting disks?
To remove a voting disk, issue the following command as the root user, replacing the path variable with the fully qualified path name for the voting disk we want to remove:
crsctl delete css votedisk path -force

What should we do after modifying voting disks?
After modifying the voting disk, restart Oracle Clusterware using the crsctl start crs command on all nodes, and verify the voting disk location using the following command:
crsctl query css votedisk

When can we use -force option?
If our cluster is down, then we can include the -force option to modify the voting disk configuration, without interacting with active Oracle Clusterware daemons. However, using the -force option while any cluster node is active may corrupt our configuration.

Oracle Accounts Recievables - Tables

Useful AR Tables Informations

Following are commonly used AR ( receivables )tables and their usage. There are many other tables also in AR but here i am putting only few commonly used tables.

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.

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.

Oracle General Ledger - Tables

Oracle General Ledger - Tables

Following are commonly used GL tables and their usage. There are many other tables also in GL but here i am putting only few commonly used tables.

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