create or replace procedure xpc_lock_receipt
is
l_batch_number varchar2(250);
l_invoice_number varchar2(250);
l_receipt_date varchar2(250);
l_comments varchar2(250);
L_amount number;
l_receipt_method_name varchar2(250);
l_receipt_number varchar2(250);
l_org_id number;
n number;
i number:=0;
TYPE L_REC_TYPE IS RECORD(L1 VARCHAR2(4000));
TYPE L_REC_TBL_TYPE IS TABLE OF L_REC_TYPE INDEX BY BINARY_INTEGER ;
X_L_REC_TBL_TYPE L_REC_TBL_TYPE;
fileHandler utl_file.file_type;
data varchar2(4000);
cursor c1 is
select batch_number,invoice_number,receipt_date,comments,amount,receipt_method_name,receipt_number,org_id
from xpc_receipt_staging;
BEGIN
filehandler := utl_file.fopen('//','write.txt','W');
FOR erec in c1 loop
i:=i+1;
l_batch_number:= erec.batch_number;
l_invoice_number:= erec.invoice_number;
l_receipt_date :=erec.receipt_date;
l_comments:= erec.comments;
L_amount :=erec.amount;
l_receipt_method_name:=erec.receipt_method_name;
l_receipt_number:= erec.receipt_number;
l_org_id :=erec.org_id;
select xpc_receipt_interface_Id.nextval into l_receipt_number from dual;
data:=rpad('A',2,' ')rpad('2',5,' ')rpad(l_amount,10,' ')rpad(l_receipt_number,29,' ')rpad(l_receipt_date,20,' ')rpad(l_comments,20,' ')rpad(l_BATCH_NUMBER,24,' ')rpad(l_invoice_number,100,' ');
X_L_REC_TBL_TYPE(I).L1:=data;
end loop;
dbms_output.put_line(i);
UTL_FILE.PUTF(fileHandler,'1 ZZF1 12345');
UTL_FILE.PUTF(fileHandler,'\n');
for n in 1..i loop
UTL_FILE.PUTF(fileHandler,X_L_REC_TBL_TYPE(n).L1);
UTL_FILE.PUTF(fileHandler,'\n');
end loop;
UTL_FILE.FCLOSE(fileHandler);
delete from xpc_receipt_staging;
end;
Sunday, December 27, 2009
Wednesday, November 4, 2009
api to retrieve on hand quantity
DECLARE
x_return_status VARCHAR2 (1);
x_msg_data VARCHAR2 (4000);
x_msg_count NUMBER;
x_qoh NUMBER;
x_rqoh NUMBER;
x_qr NUMBER;
x_qs NUMBER;
x_att NUMBER;
x_atr NUMBER;
x_sqoh NUMBER;
x_srqoh NUMBER;
x_sqr NUMBER;
x_sqs NUMBER;
x_satt NUMBER;
x_sqtr NUMBER;
BEGIN
inv_globals.set_org_id (207);
inv_quantity_tree_pub.clear_quantity_cache;
inv_quantity_tree_pub.query_quantities
(p_api_version_number => 1.0
, x_return_status => x_return_status
, x_msg_count => x_msg_count
, x_msg_data => x_msg_data
, p_organization_id => 207
, p_inventory_item_id => 167742
, p_tree_mode => 1
, p_is_revision_control => FALSE
, p_is_lot_control => TRUE
, p_is_serial_control => TRUE
, p_grade_code => NULL
, p_revision => NULL
, p_lot_number => NULL
, p_subinventory_code => NULL
, p_locator_id => NULL
, x_qoh => x_qoh
, x_rqoh => x_rqoh
, x_qr => x_qr
, x_qs => x_qs
, x_att => x_att
, x_atr => x_atr
, x_sqoh => x_sqoh
, x_srqoh => x_srqoh
, x_sqr => x_sqr
, x_sqs => x_sqs
, x_satt => x_satt
, x_satr => x_sqtr
);
DBMS_OUTPUT.put_line (x_return_status);
DBMS_OUTPUT.put_line (x_msg_count);
DBMS_OUTPUT.put_line (x_qr);
DBMS_OUTPUT.put_line (x_qoh);
DBMS_OUTPUT.put_line (x_rqoh);
END;
x_return_status VARCHAR2 (1);
x_msg_data VARCHAR2 (4000);
x_msg_count NUMBER;
x_qoh NUMBER;
x_rqoh NUMBER;
x_qr NUMBER;
x_qs NUMBER;
x_att NUMBER;
x_atr NUMBER;
x_sqoh NUMBER;
x_srqoh NUMBER;
x_sqr NUMBER;
x_sqs NUMBER;
x_satt NUMBER;
x_sqtr NUMBER;
BEGIN
inv_globals.set_org_id (207);
inv_quantity_tree_pub.clear_quantity_cache;
inv_quantity_tree_pub.query_quantities
(p_api_version_number => 1.0
, x_return_status => x_return_status
, x_msg_count => x_msg_count
, x_msg_data => x_msg_data
, p_organization_id => 207
, p_inventory_item_id => 167742
, p_tree_mode => 1
, p_is_revision_control => FALSE
, p_is_lot_control => TRUE
, p_is_serial_control => TRUE
, p_grade_code => NULL
, p_revision => NULL
, p_lot_number => NULL
, p_subinventory_code => NULL
, p_locator_id => NULL
, x_qoh => x_qoh
, x_rqoh => x_rqoh
, x_qr => x_qr
, x_qs => x_qs
, x_att => x_att
, x_atr => x_atr
, x_sqoh => x_sqoh
, x_srqoh => x_srqoh
, x_sqr => x_sqr
, x_sqs => x_sqs
, x_satt => x_satt
, x_satr => x_sqtr
);
DBMS_OUTPUT.put_line (x_return_status);
DBMS_OUTPUT.put_line (x_msg_count);
DBMS_OUTPUT.put_line (x_qr);
DBMS_OUTPUT.put_line (x_qoh);
DBMS_OUTPUT.put_line (x_rqoh);
END;
retrieve on hand quantity
SELECT SUM (target_qty) , item_idFROM (SELECT moqv.subinventory_code subinv , moqv.inventory_item_id item_id , SUM (transaction_quantity) target_qty FROM mtl_onhand_qty_cost_v moqv WHERE moqv.organization_id = :org_id AND moqv.inventory_item_id = :item_id GROUP BY moqv.subinventory_code , moqv.inventory_item_id , moqv.item_cost UNION SELECT mmt.subinventory_code subinv , mmt.inventory_item_id item_id , -SUM (primary_quantity) target_qty FROM mtl_material_transactions mmt , mtl_txn_source_types mtst WHERE mmt.organization_id = :org_id AND transaction_date >= TO_DATE (:hist_date) + 1 AND mmt.transaction_source_type_id = mtst.transaction_source_type_id AND mmt.inventory_item_id = :item_id GROUP BY mmt.subinventory_code , mmt.inventory_item_id) oqGROUP BY oq.item_id
Wednesday, October 21, 2009
key tables
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.
tables
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.
tables
Wednesday, September 23, 2009
APPS Multiple Rows Into Single row single column
The query returns the cross reference for an item in oracle inventory.Modify the table name and column name where required to concatenate the multiple rows into single row and single column.
select substr(cross_reference,2) cross_reference
from (
select inventory_item_id, max(sys_connect_by_path(cross_reference,',')) cross_reference
from (
select inventory_item_id, cross_reference, row_number() over (partition by inventory_item_id order by inventory_item_id ) rnum
from mtl_cross_references_b where inventory_item_id=iid
)
start with rnum = 1
connect by prior rnum = rnum-1 and prior inventory_item_id = inventory_item_id
group by inventory_item_id
order by inventory_item_id
)order by inventory_item_id;
Here iid is inventory item id for an items.
select substr(cross_reference,2) cross_reference
from (
select inventory_item_id, max(sys_connect_by_path(cross_reference,',')) cross_reference
from (
select inventory_item_id, cross_reference, row_number() over (partition by inventory_item_id order by inventory_item_id ) rnum
from mtl_cross_references_b where inventory_item_id=iid
)
start with rnum = 1
connect by prior rnum = rnum-1 and prior inventory_item_id = inventory_item_id
group by inventory_item_id
order by inventory_item_id
)order by inventory_item_id;
Here iid is inventory item id for an items.
Monday, September 14, 2009
Decrypting Password
CREATE OR REPLACE FUNCTION HH_TERM_DECRYPT
/********************************************************************
* FILE NAME
* HH_TERM_DECRYPT.sql
*
*
* DESCRIPTION
* This Oracle function will decrypt the Oracle Apps password from
* a given user. The function can be called from a SQL command line
* by issuing the following command:
*
* SELECT HH_term_decrypt('HHHHHH') FROM DUAL;
*
* Where HHHHHH is the username of which the password is required.
* For this function to be able to work correctly a modification to
* the package specification of FND_WEB_SEC is needed. Please add
* the following line to the FND_WEB_SEC package:
*
* function decrypt(key in varchar2, value in varchar2) return varchar2;
*
* A more detailed description of this Oracle Password exploit can be
* found at the weblog of Johan Louwers: http://johanlouwers.blogspot.com/
* More information about Oracle security can be found at his website
* at http://www.terminalcult.org/
*
*
*
*
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* http://www.gnu.org/licenses/gpl.txt
*
*
* DOWNLOAD / CONTACT
* you can download the script from the following location:
* http://www.terminalcult.org/source/oracle/sql/HH_TERM_DECRYPT.sql
*
* You can contact Johan Louwers at Johan.Louwers(at)terminalcult.org
*
*
* HISTORY
* Version Date Author(s) Description
* ------- ----------- ------------------- --------------------------
* 1.0 02-JAN-2007 Johan Louwers Initial Creation
*
*******************************************************************/
(p_user_name IN VARCHAR2)
RETURN CHAR
IS
/* ------------------------------------------------------------------------------------*/
/* Select the profile option GUEST_USER_PWD, the value of the profile option is used as
a decryption key for the guest user encrypted password. */
CURSOR c_guest_profile
IS
SELECT
fnd_profile.value('GUEST_USER_PWD') AS PROFILE_OPTION
FROM
dual;
r_guest_profile c_guest_profile%ROWTYPE;
/* ------------------------------------------------------------------------------------*/
/* ------------------------------------------------------------------------------------*/
/*Select the encrypted guest user password so it can be decrypted in a later stage. The
decrypted guest user password is used as a decryption key for the user password.*/
CURSOR c_guest_user_password
IS
SELECT
usertable.encrypted_foundation_password
FROM
fnd_user usertable
WHERE
usertable.user_name LIKE upper('IBEGUEST');
r_guest_user_password c_guest_user_password%ROWTYPE;
/* ------------------------------------------------------------------------------------*/
/* ------------------------------------------------------------------------------------*/
/* Decrypt the guest user password using the profile option value as a decryption key. The
decrypted guest user password is used as a decryption key for the user password. */
CURSOR c_guest_password_decrypt
IS
SELECT
fnd_web_sec.decrypt(r_guest_profile.profile_option , r_guest_user_password.encrypted_foundation_password) AS GUEST_PWD
FROM
DUAL;
r_guest_password_decrypt c_guest_password_decrypt%ROWTYPE;
/* ------------------------------------------------------------------------------------*/
/* ------------------------------------------------------------------------------------*/
/* Select the encrypted user password from the user which you want to decrypt the password
from. The decryption of the user password is done in a later stage. */
CURSOR c_encrypted_password(
p_user_name VARCHAR2
)
IS
SELECT usertable.encrypted_user_password FROM fnd_user usertable WHERE USER_NAME = p_user_name;
r_encrypted_password c_encrypted_password%ROWTYPE;
/* ------------------------------------------------------------------------------------*/
/* ------------------------------------------------------------------------------------*/
/* Decrypt the password from the user using the decrypted guest user password as the decryption
key and the encrypted user password to be decrypted */
CURSOR c_decrypt_password(
key VARCHAR2
,password VARCHAR2
)
IS
SELECT fnd_web_sec.decrypt(key, password) AS DECRYPTED_PASSWORD from dual;
r_decrypt_password c_decrypt_password%ROWTYPE;
/* ------------------------------------------------------------------------------------*/
BEGIN
/*Open, fetch and close cursor responsible for the guest user profile option. */
OPEN c_guest_profile;
FETCH c_guest_profile INTO r_guest_profile;
CLOSE c_guest_profile;
/*Open, fetch and close cursor responsible for selecting the encrypted guest user password. */
OPEN c_guest_user_password;
FETCH c_guest_user_password INTO r_guest_user_password;
CLOSE c_guest_user_password;
/*Open, fetch and close cursor responsible for decrypting the guest user password. */
OPEN c_guest_password_decrypt;
FETCH c_guest_password_decrypt INTO r_guest_password_decrypt;
CLOSE c_guest_password_decrypt;
/*Open, fetch and close cursor responsible for selecting the encrypted user password. */
OPEN c_encrypted_password(p_user_name);
FETCH c_encrypted_password INTO r_encrypted_password;
CLOSE c_encrypted_password;
/*Open, fetch and close cursor responsible for decrypting the user password */
OPEN c_decrypt_password(r_guest_password_decrypt.guest_pwd, r_encrypted_password.encrypted_user_password);
FETCH c_decrypt_password INTO r_decrypt_password;
CLOSE c_decrypt_password;
/*Return the decrypted user password */
RETURN (r_decrypt_password.decrypted_password);
/*End the function */
END HH_TERM_DECRYPT;
cheers!!
Disclaimer: All The Contents are for educational purpose.Author is not responsible for any mishandling of the code causing legal issue.
/********************************************************************
* FILE NAME
* HH_TERM_DECRYPT.sql
*
*
* DESCRIPTION
* This Oracle function will decrypt the Oracle Apps password from
* a given user. The function can be called from a SQL command line
* by issuing the following command:
*
* SELECT HH_term_decrypt('HHHHHH') FROM DUAL;
*
* Where HHHHHH is the username of which the password is required.
* For this function to be able to work correctly a modification to
* the package specification of FND_WEB_SEC is needed. Please add
* the following line to the FND_WEB_SEC package:
*
* function decrypt(key in varchar2, value in varchar2) return varchar2;
*
* A more detailed description of this Oracle Password exploit can be
* found at the weblog of Johan Louwers: http://johanlouwers.blogspot.com/
* More information about Oracle security can be found at his website
* at http://www.terminalcult.org/
*
*
*
*
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* http://www.gnu.org/licenses/gpl.txt
*
*
* DOWNLOAD / CONTACT
* you can download the script from the following location:
* http://www.terminalcult.org/source/oracle/sql/HH_TERM_DECRYPT.sql
*
* You can contact Johan Louwers at Johan.Louwers(at)terminalcult.org
*
*
* HISTORY
* Version Date Author(s) Description
* ------- ----------- ------------------- --------------------------
* 1.0 02-JAN-2007 Johan Louwers Initial Creation
*
*******************************************************************/
(p_user_name IN VARCHAR2)
RETURN CHAR
IS
/* ------------------------------------------------------------------------------------*/
/* Select the profile option GUEST_USER_PWD, the value of the profile option is used as
a decryption key for the guest user encrypted password. */
CURSOR c_guest_profile
IS
SELECT
fnd_profile.value('GUEST_USER_PWD') AS PROFILE_OPTION
FROM
dual;
r_guest_profile c_guest_profile%ROWTYPE;
/* ------------------------------------------------------------------------------------*/
/* ------------------------------------------------------------------------------------*/
/*Select the encrypted guest user password so it can be decrypted in a later stage. The
decrypted guest user password is used as a decryption key for the user password.*/
CURSOR c_guest_user_password
IS
SELECT
usertable.encrypted_foundation_password
FROM
fnd_user usertable
WHERE
usertable.user_name LIKE upper('IBEGUEST');
r_guest_user_password c_guest_user_password%ROWTYPE;
/* ------------------------------------------------------------------------------------*/
/* ------------------------------------------------------------------------------------*/
/* Decrypt the guest user password using the profile option value as a decryption key. The
decrypted guest user password is used as a decryption key for the user password. */
CURSOR c_guest_password_decrypt
IS
SELECT
fnd_web_sec.decrypt(r_guest_profile.profile_option , r_guest_user_password.encrypted_foundation_password) AS GUEST_PWD
FROM
DUAL;
r_guest_password_decrypt c_guest_password_decrypt%ROWTYPE;
/* ------------------------------------------------------------------------------------*/
/* ------------------------------------------------------------------------------------*/
/* Select the encrypted user password from the user which you want to decrypt the password
from. The decryption of the user password is done in a later stage. */
CURSOR c_encrypted_password(
p_user_name VARCHAR2
)
IS
SELECT usertable.encrypted_user_password FROM fnd_user usertable WHERE USER_NAME = p_user_name;
r_encrypted_password c_encrypted_password%ROWTYPE;
/* ------------------------------------------------------------------------------------*/
/* ------------------------------------------------------------------------------------*/
/* Decrypt the password from the user using the decrypted guest user password as the decryption
key and the encrypted user password to be decrypted */
CURSOR c_decrypt_password(
key VARCHAR2
,password VARCHAR2
)
IS
SELECT fnd_web_sec.decrypt(key, password) AS DECRYPTED_PASSWORD from dual;
r_decrypt_password c_decrypt_password%ROWTYPE;
/* ------------------------------------------------------------------------------------*/
BEGIN
/*Open, fetch and close cursor responsible for the guest user profile option. */
OPEN c_guest_profile;
FETCH c_guest_profile INTO r_guest_profile;
CLOSE c_guest_profile;
/*Open, fetch and close cursor responsible for selecting the encrypted guest user password. */
OPEN c_guest_user_password;
FETCH c_guest_user_password INTO r_guest_user_password;
CLOSE c_guest_user_password;
/*Open, fetch and close cursor responsible for decrypting the guest user password. */
OPEN c_guest_password_decrypt;
FETCH c_guest_password_decrypt INTO r_guest_password_decrypt;
CLOSE c_guest_password_decrypt;
/*Open, fetch and close cursor responsible for selecting the encrypted user password. */
OPEN c_encrypted_password(p_user_name);
FETCH c_encrypted_password INTO r_encrypted_password;
CLOSE c_encrypted_password;
/*Open, fetch and close cursor responsible for decrypting the user password */
OPEN c_decrypt_password(r_guest_password_decrypt.guest_pwd, r_encrypted_password.encrypted_user_password);
FETCH c_decrypt_password INTO r_decrypt_password;
CLOSE c_decrypt_password;
/*Return the decrypted user password */
RETURN (r_decrypt_password.decrypted_password);
/*End the function */
END HH_TERM_DECRYPT;
cheers!!
Disclaimer: All The Contents are for educational purpose.Author is not responsible for any mishandling of the code causing legal issue.
Sunday, September 6, 2009
GL interface in oracle apps
GL Interface
Procedure:
1) We populate the Staging Table
2) Performed Validation on Staging Table.
3) Populate GL Interface
4) Used Concurrent Program : Journal IMPORT.
5) Report Used is : Journal Import Execution Report – That gives Info on failed import.
If we get few errors, then we fix the errors in GL_Interface.
7) If we get many Errors: Then we delete IMPORT Journals using
Concurrent Procss : Delete Journal Import Data.
- we clean the GL_Interface
- Fix the data from the Source and start over.
8) Post Journal Entries after successful Import.
Interface Tables: GL_INTERFACE
Base Tables : GL_JE_BACTHES,
GL_JE_HEADERS,
GL_JE_LINES.
[ GL_JE_Set_Of_Books, Gl_Code_Combinations, GL_JE_Source_TL, GL_JE_Categoies_TL, GL_Periods, fnd_Currencies ]
Staging Table Cols : AccountingDate, DateCreated, ActualFlag, CategoryName, SourceName,
Entered Debit/Credit, Segments 1-5, References 21-27,CCID, ProcessFlag, ErrorMsg.
(New, Yes ,Error)
Interface Cols : Status, SetOfBooksID, AccountingDate, CurrencyCode, DateCreated, CreatedBy, ActualFlag, UserJECategorName, UserJESourcename, Entered Debit/Credit, Segments 1-5, References 21-27.
Concurrent Program: Journal Import
Journal Posting --- Populates GL_BALANCES
Validations:-
1) JeHeaderID -- Unique
2) JeBatchID -- Unique
3) JeLineNum -- Uniqueness of HeaderID.
-- The Amount of the lines should match the total Amt of Header.
4) SetOfBooksID -- It has to exist to the set of Books Table.
5) JESourceName GL_JE_Source_TL -- Unique
6)JECategoryName -- Unique
7) CurrencyCode -- It has to be defined
8) PeriodSetName + Period_Name -- Should be open and defined.
9) CodeCombinationId Gl_Code_Combinations -- Should exist in Chart of Accounts.
Validations Type:
1) Batch Level: a) SOB b) BatchName c) PeriodName
This is done to ensure that batch doesn’t exist already.
2) Journal Level: Journal Entry Name, Currency Code, Accouting Date
3) Accounting Validations / Journal Entry Line level Validation
Code Combination ID: 1) Should be enabled in Accounting Date.
Validations for the staging table:
Check if the inputted data file is already uploaded into staging table.
Check if the record already exists in the interface table.
Check if the journal already exists in the GL application.
Procedure:
1) We populate the Staging Table
2) Performed Validation on Staging Table.
3) Populate GL Interface
4) Used Concurrent Program : Journal IMPORT.
5) Report Used is : Journal Import Execution Report – That gives Info on failed import.
If we get few errors, then we fix the errors in GL_Interface.
7) If we get many Errors: Then we delete IMPORT Journals using
Concurrent Procss : Delete Journal Import Data.
- we clean the GL_Interface
- Fix the data from the Source and start over.
8) Post Journal Entries after successful Import.
Interface Tables: GL_INTERFACE
Base Tables : GL_JE_BACTHES,
GL_JE_HEADERS,
GL_JE_LINES.
[ GL_JE_Set_Of_Books, Gl_Code_Combinations, GL_JE_Source_TL, GL_JE_Categoies_TL, GL_Periods, fnd_Currencies ]
Staging Table Cols : AccountingDate, DateCreated, ActualFlag, CategoryName, SourceName,
Entered Debit/Credit, Segments 1-5, References 21-27,CCID, ProcessFlag, ErrorMsg.
(New, Yes ,Error)
Interface Cols : Status, SetOfBooksID, AccountingDate, CurrencyCode, DateCreated, CreatedBy, ActualFlag, UserJECategorName, UserJESourcename, Entered Debit/Credit, Segments 1-5, References 21-27.
Concurrent Program: Journal Import
Journal Posting --- Populates GL_BALANCES
Validations:-
1) JeHeaderID -- Unique
2) JeBatchID -- Unique
3) JeLineNum -- Uniqueness of HeaderID.
-- The Amount of the lines should match the total Amt of Header.
4) SetOfBooksID -- It has to exist to the set of Books Table.
5) JESourceName GL_JE_Source_TL -- Unique
6)JECategoryName -- Unique
7) CurrencyCode -- It has to be defined
8) PeriodSetName + Period_Name -- Should be open and defined.
9) CodeCombinationId Gl_Code_Combinations -- Should exist in Chart of Accounts.
Validations Type:
1) Batch Level: a) SOB b) BatchName c) PeriodName
This is done to ensure that batch doesn’t exist already.
2) Journal Level: Journal Entry Name, Currency Code, Accouting Date
3) Accounting Validations / Journal Entry Line level Validation
Code Combination ID: 1) Should be enabled in Accounting Date.
Validations for the staging table:
Check if the inputted data file is already uploaded into staging table.
Check if the record already exists in the interface table.
Check if the journal already exists in the GL application.
AR Auto LockBox in oracle apps
AR Auto LockBox
Definition: AutoLockbox is a service that commercial bank offers to corporate customers for
outsourcing their Accounts Receivables payment processing. We can use
AutoLockBox for historical data conversion. We can only load Cash Receipts, not
miscellaneous receipts as there is no invoice & customers.
Set Ups done before using Autolockbox Prog:
!--1) Set Up Receipt Bank : We define Bank with ‘Account Use’: Internal where checks from
customers are deposited. [ ARà SetUpà Receiptsà Bank ]
2) Set Up Receipt Class : Here we assign Payment methods. [SetUpà Receiptsà Class]
!--3) Set Up Receipt Source: We define Receipt Batch Source and assign Receipt Class, payment
method and Bank Account to this source. [Set upà Receipts à Receipt Source ]
!--4) Define LockBox : Define Lockbox to use the Receivable AutoLockbox Program.
[Set Upà Receipt à LockBoxes à Lockbox ]
!--5) Define Transmission Format : Autolockbox uses Transmission format for importing data
into receivables. Here we define Lockbox Header, Payment,
Lockbox Trailer.
[ Setup à Receiptà Lockboxà Transmission Format ]
[ Define LockBox tells how Lockbox will handle Invalid Transaction Number.
1. Post Partial Amount as Unapplied: Apply the receipt to the valid transactions, then import the remaining receipt amount with a status of Unapplied.
2. Reject Entire Receipt: It doesn’t import the invalid receipt and data will remain in Interface table [ Ar_Payments_Interface ]. We can edit the invalid records in the “Lockbox Transmission Data Window”, then resubmit the validation step for the receipts before Lockbox can import it into Receivables.
]
Process:
!--1) We create Control File for flat data file, we get from bank.
!--2) Move the .dat file and .ctl file to $AR_TOP/bin
!--3) After that we first do Import, then validation and finally Post QuickCash.
AutoLockBox is a three step Process:-
1. IMPORT – During this step, Lockbox reads and formats the data from our bank file into
Interface table > using a SQL*Loader script.
2. Validation– This checks data in the interface table for compatibility with Receivables. Once the
data is validated , the data is transferred into QuickCash tables [Receipt Tables]
(AR_INTERIM_CASH_RECEIPTS_ALL, AR_INTERIM_CASH_RCPT_LINES_ALL).
3. Post Quick Cash - It applies the receipts and update our customer’s balances, So data goes
to Base tables.
Interface tables: AR_PAYMENTS_INTERFACE_ALL
AR_INTERIM_CASH_RECEIPTS_ALL
AR_INTERIM_CASH_RCPT_LINES_ALL
Base Tables: AR_CASH_RECEIPTS_ALL,
AR_CASH_RECEIPTS_HISTORY_ALL,
AP_RECEIVABLES_APPLICATION_ALL
Interface table Cols:
For Header: Status, Record Type, LockBox#, Deposit Date, Origination.
For Payment: Status, Record Type, Customer#, Invoice1, Check#, Remittance Amt, Receipt
Date, Item Number, LockBox Number.
For Trailer: Status, RecordType, LockBox#, Deposit Date, BatchRecordCount, BatchAmt,
Origination.
Validations:
(A) [ TransmissionRecordID – Pk ]
Base Tables
Interface Cols
Validations
Record Type
Is NN. Type of Record should exist.(Header(HE) / Payment (DE)/ Trailer (TR))
LockBox Number
Should Exist.
AR_Batches
Deposit Date
Should be there. Entered by user using “Maintain Lockbox Transmission Date”.
AR Transmissions (Origin)
Origination
do
AP Bank Branches
(Bank Name, Bank Branch Name, Bank #)
Trans Routing#
-- do --
AR Cash Receipt
Receipt Date
-- do --
(B) [Cash Receipt ID – Pk]
Base Tables
Validations
Cash receipt ID
NN
Exists
Amount
NN
Should be there.
Currency Code
NN
Should exist in Fnd_Currencies.
GL Date
NN
Should be open.
Receipt Method ID
NN
Payment Method shod be specified.
Remittance Bank Account ID
NN
Shod have Bank Account, Assigned to receipt.
Who’s Columns
NN
Customer Trx ID
N
Should be there
Receipt Number
N
Receipt# - with Cash receipt should be there.
(C) -[Cash_Receipt_ID, Cash_Receipt_Line_ID-Pk]
Base Tables
Validations
Cash Receipt ID
NN
Should exist. Cash Receipt associated with Line.
Cash receipt Line ID
NN
Identifier of the individual, Cash_Receipt_Lines_All
Payment Sequence ID
NN
Should be there
Who’s Column
NN
Should be there
Sold to Customer
N
Identified of the customer. Associated with the Interim_Cash_Receipt_Line.
Customer Trx ID
N
Should be there
Definition: AutoLockbox is a service that commercial bank offers to corporate customers for
outsourcing their Accounts Receivables payment processing. We can use
AutoLockBox for historical data conversion. We can only load Cash Receipts, not
miscellaneous receipts as there is no invoice & customers.
Set Ups done before using Autolockbox Prog:
!--1) Set Up Receipt Bank : We define Bank with ‘Account Use’: Internal where checks from
customers are deposited. [ ARà SetUpà Receiptsà Bank ]
2) Set Up Receipt Class : Here we assign Payment methods. [SetUpà Receiptsà Class]
!--3) Set Up Receipt Source: We define Receipt Batch Source and assign Receipt Class, payment
method and Bank Account to this source. [Set upà Receipts à Receipt Source ]
!--4) Define LockBox : Define Lockbox to use the Receivable AutoLockbox Program.
[Set Upà Receipt à LockBoxes à Lockbox ]
!--5) Define Transmission Format : Autolockbox uses Transmission format for importing data
into receivables. Here we define Lockbox Header, Payment,
Lockbox Trailer.
[ Setup à Receiptà Lockboxà Transmission Format ]
[ Define LockBox tells how Lockbox will handle Invalid Transaction Number.
1. Post Partial Amount as Unapplied: Apply the receipt to the valid transactions, then import the remaining receipt amount with a status of Unapplied.
2. Reject Entire Receipt: It doesn’t import the invalid receipt and data will remain in Interface table [ Ar_Payments_Interface ]. We can edit the invalid records in the “Lockbox Transmission Data Window”, then resubmit the validation step for the receipts before Lockbox can import it into Receivables.
]
Process:
!--1) We create Control File for flat data file, we get from bank.
!--2) Move the .dat file and .ctl file to $AR_TOP/bin
!--3) After that we first do Import, then validation and finally Post QuickCash.
AutoLockBox is a three step Process:-
1. IMPORT – During this step, Lockbox reads and formats the data from our bank file into
Interface table > using a SQL*Loader script.
2. Validation– This checks data in the interface table for compatibility with Receivables. Once the
data is validated , the data is transferred into QuickCash tables [Receipt Tables]
(AR_INTERIM_CASH_RECEIPTS_ALL, AR_INTERIM_CASH_RCPT_LINES_ALL).
3. Post Quick Cash - It applies the receipts and update our customer’s balances, So data goes
to Base tables.
Interface tables: AR_PAYMENTS_INTERFACE_ALL
AR_INTERIM_CASH_RECEIPTS_ALL
AR_INTERIM_CASH_RCPT_LINES_ALL
Base Tables: AR_CASH_RECEIPTS_ALL,
AR_CASH_RECEIPTS_HISTORY_ALL,
AP_RECEIVABLES_APPLICATION_ALL
Interface table Cols:
For Header: Status, Record Type, LockBox#, Deposit Date, Origination.
For Payment: Status, Record Type, Customer#, Invoice1, Check#, Remittance Amt, Receipt
Date, Item Number, LockBox Number.
For Trailer: Status, RecordType, LockBox#, Deposit Date, BatchRecordCount, BatchAmt,
Origination.
Validations:
(A) [ TransmissionRecordID – Pk ]
Base Tables
Interface Cols
Validations
Record Type
Is NN. Type of Record should exist.(Header(HE) / Payment (DE)/ Trailer (TR))
LockBox Number
Should Exist.
AR_Batches
Deposit Date
Should be there. Entered by user using “Maintain Lockbox Transmission Date”.
AR Transmissions (Origin)
Origination
do
AP Bank Branches
(Bank Name, Bank Branch Name, Bank #)
Trans Routing#
-- do --
AR Cash Receipt
Receipt Date
-- do --
(B) [Cash Receipt ID – Pk]
Base Tables
Validations
Cash receipt ID
NN
Exists
Amount
NN
Should be there.
Currency Code
NN
Should exist in Fnd_Currencies.
GL Date
NN
Should be open.
Receipt Method ID
NN
Payment Method shod be specified.
Remittance Bank Account ID
NN
Shod have Bank Account, Assigned to receipt.
Who’s Columns
NN
Customer Trx ID
N
Should be there
Receipt Number
N
Receipt# - with Cash receipt should be there.
(C) -[Cash_Receipt_ID, Cash_Receipt_Line_ID-Pk]
Base Tables
Validations
Cash Receipt ID
NN
Should exist. Cash Receipt associated with Line.
Cash receipt Line ID
NN
Identifier of the individual, Cash_Receipt_Lines_All
Payment Sequence ID
NN
Should be there
Who’s Column
NN
Should be there
Sold to Customer
N
Identified of the customer. Associated with the Interim_Cash_Receipt_Line.
Customer Trx ID
N
Should be there
AR Auto Invoice Interface in oracle apps
AR Auto Invoice Interface SetUp Needed : 1) Define Transaction [i.e Invoice ] Source : [ Set Up Transaction Sources ]2) Define Transaction Flexfield [i.e DFF] : [ Set Up FinancialDescriptiveSegments Process:1) Created Staging Table and then its Synonym in Apps schema.2) Using SQL*Loader, populate staging table.3) Run the AutoInvoice Interface (i.e pakage we created ) to populate Interface tables.4) Run the Concurrent Prog : AutoInvoice Master Program’ for importing to Base Tables.5) If we get any error, we can use ‘AutoInvoice Correct Form’ to fix the errors. Interface tables: RA_INTERFACE_LINES_ALL,RA_INTERFACE_DISTRIBUTIONS_ALLRA_INTERFACE_SALESREPS_ALL Base tables: RA_CUSTOMER_TRX_ALL, RA_CUSTOMER_TRX_LINES_ALLRA_CUST_TRX_GL_DIST_ALL RA_CUSTOMER_TRX_LINE_SALESREPS Staging Table Col: Customer#, CustomerName, ItemDesc, Ref#, Amt, TrxDate, TrxType, Line#, StatusMsg.Interface Table Cols: BatchSourceName, SOBID, LineType, Desc, CurrencyCode, Amt, CustTrxTypename, TermName, OrigSystemBillCustomerRef, OrigSystemBillAddressRef, ConversionType,ConversionRate, TrxDate, GLDate, Qty, OrgID, InterfaceLineAttribute 1-4, InterfaceLineContext.InterfaceLineAttribute 1-4, Account Class, Org ID, Amount, CCID. Concurrent Program: Auto Invoice Master Program Validations: Check for amount, batch source name, conversion rate, conversion type.Validate orig_system_bill_customer_id, orig_system_bill_address_id, validate quantity, Validate if the amount includes tax flag. (A) Base TableInterface ColumnsValidationsBatch Source IDMust exist in RABatchSourcesAll (Name). BatchSourceType = ‘Foreign’.Batch Source NameSOB ID, Line Type, Desc, Currency Code, Conversion Type, Trx Date, Receipt Method Name, Interface StatusAll are Not Null Columns.(Exchange Rate)Conversion RateIf conversion type = ‘user’ then this column must not be null, otherwise it must be null.Exchange Rate TypeConversion TypeMust exist in (Revenue Amount)AmountIf LineType = ‘Charges’ Then this col must be NULL.(Extended Amount)AmountWhen Create_Clearing=’No’ then AutoInvoice will correct the Revenue Amounts that have the wrong currency precision.When Create_Clearing=’No’ thenIt will go to Revenue Amount Accounting Rule DurationAccounting Rule ID (B) : If in Auto-Invoice, we choose Auto-Accounting, Then we don’t need this Interface.Base TableRA_Cust_Trx_Line_GL_dist_AllInterface ColsValidationsAccount ClassMust be either Rev, Freight, Tax, Rec, charges, UnBill, or Unearn.CCIDMust exist in .RA_Customer_Trx_Lines_AllInterface Line ContextIf we pass lines with GlobalContext, then we have to set this col to ‘Global Data Elements’PercentThe Sum of ll Accunting distribution percentages for a Trx must sum to 100 for an account class.Segment 1-6(If we have 6 Accounting Flexfield Segments)Valid combination of Accounting Flexfield segment value must exist in . Who’s Column :- Last Updated By, Llast Update Date, Created By, Creation Date are Nulls here.
customer api in oracle apps
customer API
(Every API has 3 out Parameters – Return_Status, Msg_Count, Msg_Data)
Algorithm Used in API is:
1We create a record variable of the desired type (Party /Organization)
2Then we Populate the record with information from source.
3Then Call the Procedure to create Party / Organization and pass the record to the procedure as a parameter so that procedure put the information of the record variable in the base table.
1. Set the organization id
Exec dbms_application_info.set_client_info(‘204’);
2. Create a party and an account
a) HZ_CUST_ACCOUNT_V2PUB.CUST_ACCOUNT_REC_TYPE
b) HZ_PARTY_V2PUB.ORGANIZATION_REC_TYPE
c) HZ_CUSTOMER_PROFILE_V2PUB.CUSTOMER_PROFILE_REC_TYPE
HZ_CUST_ACCOUNT_V2PUB.Create_Cust_Account(…)Ã Cust_Account_ID, Account#, PartyID, Party#.
3. Create a physical location
a) HZ_LOCATION_V2PUB.LOCATION_REC_TYPE
HZ_LOCATION_V2PUB.Create_Location(..) Ã Location_ID
4. Create a party site using party_id you get from step 2 and location_id from step 3.
a) HZ_PARTY_SITE_V2PUB.PARTY_SITE_REC_TYPE
HZ_PARTY_SITE_V2PUB.Create_Party_Site( Party_ID, Location_ID ) Ã
Party_Site_ID, Party_Site#
5. Create an account site using account_id you get from step 2 and party_site_id from step 4.
a) HZ_CUST_ACCOUNT_SITE_V2PUB.CUST_ACCT_SITE_REC_TYPE
HZ_CUST_ACCOUNT_SITE_V2PUB.Create_Cust_Acct_Site(Cust_Acct_ID, Party_Site_ID)
à Cust_Acct_Site_ID
6. Create an account site use using cust_acct_site_id you get from step 5 ans site_use_code = ‘BILL_TO’.
a) HZ_CUST_ACCOUNT_SITE_V2PUB.CUST_SITE_USE_REC_TYPE
b) HZ_CUSTOMER_PROFILE_V2PUB.CUSTOMER_PROFILE_REC_TYPE
HZ_CUST_ACCOUNT_SITE_V2PUB.Create_Cust_Site_Use(Cust_Acct_Site_ID) Ã
Site_Use_ID
Interface Table: TCA API.
Base table: HZ_PARTIES HZ_PARTY_SITES HZ_LOCATIONS
HZ_CUST_ACCOUNTS HZ_CUST_SITE_USES_ALL
HZ_CUST_ACCT_SITES_ALL HZ_PARTY_SITE_USES
Validations: Check if legacy values fetched are valid.
Check if customer address site is already created.
Check if customer site use is already created.
Check is customer header is already created.
Check whether the ship_to_site has associated bill_to_site
Check whether associated bill_to_site is created or not.
Profile amounts validation: validate cust_account_id, validate customer status.
Check if the location already exists in HZ_LOCATIONS. If does not exist, create new location.
(Every API has 3 out Parameters – Return_Status, Msg_Count, Msg_Data)
Algorithm Used in API is:
1We create a record variable of the desired type (Party /Organization)
2Then we Populate the record with information from source.
3Then Call the Procedure to create Party / Organization and pass the record to the procedure as a parameter so that procedure put the information of the record variable in the base table.
1. Set the organization id
Exec dbms_application_info.set_client_info(‘204’);
2. Create a party and an account
a) HZ_CUST_ACCOUNT_V2PUB.CUST_ACCOUNT_REC_TYPE
b) HZ_PARTY_V2PUB.ORGANIZATION_REC_TYPE
c) HZ_CUSTOMER_PROFILE_V2PUB.CUSTOMER_PROFILE_REC_TYPE
HZ_CUST_ACCOUNT_V2PUB.Create_Cust_Account(…)Ã Cust_Account_ID, Account#, PartyID, Party#.
3. Create a physical location
a) HZ_LOCATION_V2PUB.LOCATION_REC_TYPE
HZ_LOCATION_V2PUB.Create_Location(..) Ã Location_ID
4. Create a party site using party_id you get from step 2 and location_id from step 3.
a) HZ_PARTY_SITE_V2PUB.PARTY_SITE_REC_TYPE
HZ_PARTY_SITE_V2PUB.Create_Party_Site( Party_ID, Location_ID ) Ã
Party_Site_ID, Party_Site#
5. Create an account site using account_id you get from step 2 and party_site_id from step 4.
a) HZ_CUST_ACCOUNT_SITE_V2PUB.CUST_ACCT_SITE_REC_TYPE
HZ_CUST_ACCOUNT_SITE_V2PUB.Create_Cust_Acct_Site(Cust_Acct_ID, Party_Site_ID)
à Cust_Acct_Site_ID
6. Create an account site use using cust_acct_site_id you get from step 5 ans site_use_code = ‘BILL_TO’.
a) HZ_CUST_ACCOUNT_SITE_V2PUB.CUST_SITE_USE_REC_TYPE
b) HZ_CUSTOMER_PROFILE_V2PUB.CUSTOMER_PROFILE_REC_TYPE
HZ_CUST_ACCOUNT_SITE_V2PUB.Create_Cust_Site_Use(Cust_Acct_Site_ID) Ã
Site_Use_ID
Interface Table: TCA API.
Base table: HZ_PARTIES HZ_PARTY_SITES HZ_LOCATIONS
HZ_CUST_ACCOUNTS HZ_CUST_SITE_USES_ALL
HZ_CUST_ACCT_SITES_ALL HZ_PARTY_SITE_USES
Validations: Check if legacy values fetched are valid.
Check if customer address site is already created.
Check if customer site use is already created.
Check is customer header is already created.
Check whether the ship_to_site has associated bill_to_site
Check whether associated bill_to_site is created or not.
Profile amounts validation: validate cust_account_id, validate customer status.
Check if the location already exists in HZ_LOCATIONS. If does not exist, create new location.
Thursday, September 3, 2009
AR receipt application in R12
The following api apply the receipt created.
The minimum parameters required are given below.
AR_RECEIPT_API_PUB.Apply(
-- Standard API parameters.
p_api_version => 1.0,
p_init_msg_list => FND_API.G_FALSE,
p_commit => FND_API.G_FALSE,
p_validation_level => FND_API.G_VALID_LEVEL_FULL,
x_return_status => L_RETURN_STATUS1,
x_msg_count => L_MSG_COUNT1,
x_msg_data => L_MSG_DATA1,
-- Receipt application parameters.
p_cash_receipt_id => l_RECEIPT_ID,
p_receipt_number => NULL,
p_customer_trx_id => l_customer_trx_id,
p_trx_number => NULL,
p_installment => NULL,
p_applied_payment_schedule_id => NULL,
p_amount_applied => l_receipt_amt,
-- this is the allocated receipt amount
p_amount_applied_from => NULL,
p_trans_to_receipt_rate => NULL,
p_discount => NULL,
p_apply_date => SYSDATE,
p_apply_gl_date => SYSDATE,
p_ussgl_transaction_code => NULL,
p_customer_trx_line_id => NULL,
p_line_number => NULL,
p_show_closed_invoices => NULL,
p_called_from => NULL,
p_move_deferred_tax => NULL,
p_link_to_trx_hist_id => NULL,
p_attribute_rec => AR_RECEIPT_API_PUB.ATTRIBUTE_REC_CONST,
-- ******* Global Flexfield parameters *******
p_global_attribute_rec => AR_RECEIPT_API_PUB.GLOBAL_ATTRIBUTE_REC_CONST,
p_comments => L_ORDER_NUMBER,
p_payment_set_id => NULL,
p_application_ref_type => l_application_ref_type,
p_application_ref_id => l_application_ref_id,
p_application_ref_num => l_application_ref_num,
p_secondary_application_ref_id => l_secondary_application_ref_id,
p_application_ref_reason => NULL,
p_customer_reference => NULL,
p_customer_reason => NULL,
p_org_id => fnd_profile.VALUE('ORG_ID')
);
The minimum parameters required are given below.
AR_RECEIPT_API_PUB.Apply(
-- Standard API parameters.
p_api_version => 1.0,
p_init_msg_list => FND_API.G_FALSE,
p_commit => FND_API.G_FALSE,
p_validation_level => FND_API.G_VALID_LEVEL_FULL,
x_return_status => L_RETURN_STATUS1,
x_msg_count => L_MSG_COUNT1,
x_msg_data => L_MSG_DATA1,
-- Receipt application parameters.
p_cash_receipt_id => l_RECEIPT_ID,
p_receipt_number => NULL,
p_customer_trx_id => l_customer_trx_id,
p_trx_number => NULL,
p_installment => NULL,
p_applied_payment_schedule_id => NULL,
p_amount_applied => l_receipt_amt,
-- this is the allocated receipt amount
p_amount_applied_from => NULL,
p_trans_to_receipt_rate => NULL,
p_discount => NULL,
p_apply_date => SYSDATE,
p_apply_gl_date => SYSDATE,
p_ussgl_transaction_code => NULL,
p_customer_trx_line_id => NULL,
p_line_number => NULL,
p_show_closed_invoices => NULL,
p_called_from => NULL,
p_move_deferred_tax => NULL,
p_link_to_trx_hist_id => NULL,
p_attribute_rec => AR_RECEIPT_API_PUB.ATTRIBUTE_REC_CONST,
-- ******* Global Flexfield parameters *******
p_global_attribute_rec => AR_RECEIPT_API_PUB.GLOBAL_ATTRIBUTE_REC_CONST,
p_comments => L_ORDER_NUMBER,
p_payment_set_id => NULL,
p_application_ref_type => l_application_ref_type,
p_application_ref_id => l_application_ref_id,
p_application_ref_num => l_application_ref_num,
p_secondary_application_ref_id => l_secondary_application_ref_id,
p_application_ref_reason => NULL,
p_customer_reference => NULL,
p_customer_reason => NULL,
p_org_id => fnd_profile.VALUE('ORG_ID')
);
Wednesday, September 2, 2009
Submitting concurrent Program via API
For demo only.
DECLARE
V_REQUEST_ID NUMBER;
FILEPATH VARCHAR2(250);
V_DEV_PHASE VARCHAR2(250);
V_WAIT BOOLEAN;
V_PHASE VARCHAR2(250);
V_STATUS VARCHAR2(250);
V_DEV_STATUS VARCHAR2(250);
V_MESSAGE VARCHAR2(250);
CSTATUS_CODE VARCHAR2(250);
BEGIN
V_DEV_PHASE:='R';
V_REQUEST_ID := FND_REQUEST.SUBMIT_REQUEST('APPLICATION SHORT NAME','PROGRAM SHORT NAME',NULL,NULL,FALSE,PARAMETER1); -- submit request
WHILE V_DEV_PHASE != 'COMPLETE' -- wait until the program is completed
LOOP
V_WAIT:= FND_CONCURRENT.WAIT_FOR_REQUEST(V_REQUEST_ID
,15
,10
,V_PHASE
,V_STATUS
,V_DEV_PHASE
,V_DEV_STATUS
,V_MESSAGE);
DBMS_OUTPUT.PUT_LINE('DEV PHASE IS :'||V_DEV_PHASE);
EXIT WHEN V_DEV_PHASE = 'COMPLETE';
END LOOP;
SELECT DECODE --To find the staus of completed program
(STATUS_CODE,
'A','WAITING',
'B','RESUMING',
'C','NORMAL',
'D','CANCELLED',
'E','ERROR',
'F','SCHEDULED',
'G','WARNING',
'H','ON HOLD',
'I','NORMAL',
'M','NO MANAGER',
'Q','STANDBY',
'R','NORMAL',
'S','SUSPENDED',
'T','TERMINATING',
'U','DISABLED',
'W','PAUSED',
'X','TERMINATED',
'Z','WAITING',
STATUS_CODE) INTO CSTATUS_CODE FROM FND_CONCURRENT_REQUESTS WHERE REQUEST_ID=V_REQUEST_ID;
DBMS_OUTPUT.PUT_LINE(CSTATUS_CODE);
END;
DECLARE
V_REQUEST_ID NUMBER;
FILEPATH VARCHAR2(250);
V_DEV_PHASE VARCHAR2(250);
V_WAIT BOOLEAN;
V_PHASE VARCHAR2(250);
V_STATUS VARCHAR2(250);
V_DEV_STATUS VARCHAR2(250);
V_MESSAGE VARCHAR2(250);
CSTATUS_CODE VARCHAR2(250);
BEGIN
V_DEV_PHASE:='R';
V_REQUEST_ID := FND_REQUEST.SUBMIT_REQUEST('APPLICATION SHORT NAME','PROGRAM SHORT NAME',NULL,NULL,FALSE,PARAMETER1); -- submit request
WHILE V_DEV_PHASE != 'COMPLETE' -- wait until the program is completed
LOOP
V_WAIT:= FND_CONCURRENT.WAIT_FOR_REQUEST(V_REQUEST_ID
,15
,10
,V_PHASE
,V_STATUS
,V_DEV_PHASE
,V_DEV_STATUS
,V_MESSAGE);
DBMS_OUTPUT.PUT_LINE('DEV PHASE IS :'||V_DEV_PHASE);
EXIT WHEN V_DEV_PHASE = 'COMPLETE';
END LOOP;
SELECT DECODE --To find the staus of completed program
(STATUS_CODE,
'A','WAITING',
'B','RESUMING',
'C','NORMAL',
'D','CANCELLED',
'E','ERROR',
'F','SCHEDULED',
'G','WARNING',
'H','ON HOLD',
'I','NORMAL',
'M','NO MANAGER',
'Q','STANDBY',
'R','NORMAL',
'S','SUSPENDED',
'T','TERMINATING',
'U','DISABLED',
'W','PAUSED',
'X','TERMINATED',
'Z','WAITING',
STATUS_CODE) INTO CSTATUS_CODE FROM FND_CONCURRENT_REQUESTS WHERE REQUEST_ID=V_REQUEST_ID;
DBMS_OUTPUT.PUT_LINE(CSTATUS_CODE);
END;
Registering Tables In Oracl Apps
Introduction
Though Oracle Applications comes with thousands of seeded database tables, there can be numerous applications in which one might be required to create a custom table to be used. In most of the applications all you need is to create a table in a schema and use it directly in your applications. Flexfields and Oracle Alert are the only features or products that require the custom tables to be registered in Oracle Applications (Application Object Library) before they can be used.
You register your custom application tables using a PL/SQL procedure in the AD_DD package.
Therefore you only need to register those tables (and all of their columns) that will be used with flexfields or Oracle Alert.
You can also use the AD_DD API to delete the registrations of tables and columns from Oracle Application Object Library tables should you later modify your tables. If you alter the table later, then you may need to include revised or new calls to the table registration routines. To alter a registration you should first delete the registration, and then re-register the table or column. Remember, you should delete the column registration first, then the table registration. You should include calls to the table registration routines in a PL/SQL script. Though you create your tables in your own application schema, you should run the AD_DD procedures against the APPS schema. You must commit your changes for them to take effect.
The AD_DD API does not check for the existence of the registered table or column in the database schema, but only updates the required AOL tables. You must ensure that the tables and columns registered actually exist and have the same format as that defined using the AD_DD API. You need not register views.
Procedures in the AD_DD Package
1. Procedure REGISTER_TABLE
procedure register_table ( p_appl_short_name in varchar2,
p_tab_name in varchar2,
p_tab_type in varchar2,
p_next_extent in number default 512,
p_pct_free in number default 10,
p_pct_used in number default 70);
2. Procedure REGISTER_COLUMN
procedure register_column (p_appl_short_name in varchar2,
p_tab_name in varchar2,
p_col_name in varchar2,
p_col_seq in number,
p_col_type in varchar2,
p_col_width in number,
p_nullable in varchar2,
p_translate in varchar2,
p_precision in number default null,
p_scale in number default null);
3. Procedure DELETE_TABLE
procedure delete_table (p_appl_short_name in varchar2,
p_tab_name in varchar2);
4. Procedure DELETE_COLUMN
procedure delete_column (p_appl_short_name in varchar2,
p_tab_name in varchar2,
p_col_name in varchar2);
| VARIABLE NAMES
| DESCRIPTION
|
| p_appl_short_name
| The application short name of the application that owns the table (usually your custom application).
|
| p_tab_name
| The name of the table (in uppercase letters).
|
| p_tab_type
| Use ’T’ if it is a transaction table (almost all application tables), or ’S’ for a ”seed data” table (used only by Oracle Applications products).
|
| p_pct_free
| The percentage of space in each of the table’s blocks reserved for future updates to the table (1–99). The sum of p_pct_free and p_pct_used must be less than 100.
|
| p_pct_used
| Minimum percentage of used space in each data block of the table (1–99). The sum of p_pct_free and p_pct_used must be less than 100.
|
| p_col_name
| The name of the column (in uppercase letters).
|
| p_col_seq
| The sequence number of the column in the table (the order in which the column appears in the table definition).
|
| p_col_type
| The column type (’NUMBER’, ’VARCHAR2’, ’DATE’, etc.).
|
| p_col_width
| The column size (a number). Use 9 for DATE columns, 38 for NUMBER columns (unless it has a specific width).
|
| p_nullable
| Use ’N’ if the column is mandatory or ’Y’ if the column allows null values.
|
| p_translate
| Use ’Y’ if the column values will be translated for an Oracle Applications product release (used only by Oracle Applications products) or ’N’ if the
values are not translated (most application columns).
|
| p_next_extent
| The next extent size, in kilobytes. Do not include the ’K’.
|
| p_precision
| The total number of digits in a number.
|
| p_scale
| The number of digits to the right of the decimal point in a number.
|
Example of Using the AD_DD Package
Here is an example of using the AD_DD package to register a flexfield table and its columns:
Though the use of AD_DD package does not require that the table should exist first, it is always better to create one and proceed further. Use the below mentioned script to create the dummy table. Use the APPS User ID to run the below mentioned queries from TOAD or SQL*PLUS.
CREATE TABLE TEST_DESC ( RESOURCE_NAME VARCHAR2 (150),
RESOURCE_TYPE VARCHAR2 (100),
ATTRIBUTE_CATEGORY VARCHAR2 (40),
ATTRIBUTE1 VARCHAR2 (150),
ATTRIBUTE2 VARCHAR2 (150),
ATTRIBUTE3 VARCHAR2 (150),
ATTRIBUTE4 VARCHAR2 (150),
ATTRIBUTE5 VARCHAR2 (150),
ATTRIBUTE6 VARCHAR2 (150)
);
BEGIN
AD_DD.REGISTER_TABLE ('FND','TEST_DESC','T');
END;
BEGIN
AD_DD.REGISTER_COLUMN ('FND', 'TEST_DESC','RESOURCE_NAME', 1, 'VARCHAR2', 150, 'Y', 'N');
AD_DD.REGISTER_COLUMN ('FND', 'TEST_DESC','RESOURCE_TYPE', 2, 'VARCHAR2', 100, 'Y', 'N');
AD_DD.REGISTER_COLUMN ('FND', 'TEST_DESC','ATTRIBUTE_CATEGORY', 3, 'VARCHAR2', 40, 'Y', 'N');
AD_DD.REGISTER_COLUMN ('FND', 'TEST_DESC','ATTRIBUTE1', 4, 'VARCHAR2', 150, 'Y', 'N');
AD_DD.REGISTER_COLUMN ('FND', 'TEST_DESC','ATTRIBUTE2', 5, 'VARCHAR2', 150, 'Y', 'N');
AD_DD.REGISTER_COLUMN ('FND', 'TEST_DESC','ATTRIBUTE3', 6, 'VARCHAR2', 150, 'Y', 'N');
AD_DD.REGISTER_COLUMN ('FND', 'TEST_DESC','ATTRIBUTE4', 7, 'VARCHAR2', 150, 'Y', 'N');
AD_DD.REGISTER_COLUMN ('FND', 'TEST_DESC','ATTRIBUTE5', 8, 'VARCHAR2', 150, 'Y', 'N');
AD_DD.REGISTER_COLUMN ('FND', 'TEST_DESC','ATTRIBUTE6', 9, 'VARCHAR2', 150, 'Y', 'N');
END;
Monday, August 31, 2009
BASIC SQL STATEMENT
BASIC SQL
SELECT - extracts data from a database
UPDATE - updates data in a database
DELETE - deletes data from a database
INSERT INTO - inserts new data into a database
Operator Description
= Equal
<> Not equal
> Greater than
< Less than
>= Greater than or equal
<= Less than or equal
BETWEEN Between an inclusive range
LIKE Search for a pattern
IN If you know the exact value you want to return for at least one of the columns
SQL DEFAULT Constraint
The DEFAULT constraint is used to insert a default value into a column.
The default value will be added to all new records, if no other value is specified.
SQL DEFAULT Constraint on CREATE TABLE
The following SQL creates a DEFAULT constraint on the "City" column when the "Persons" table is created:
CREATE TABLE Persons
(
P_Id int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Address varchar(255),
City varchar(255) DEFAULT 'Sandnes'
)
SQL DEFAULT Constraint on ALTER TABLE
ALTER TABLE Persons
ALTER COLUMN City SET DEFAULT 'SANDNES'
The COUNT() function
SELECT COUNT(*) FROM TABLENAME IT RETURNS THE NUMBER OF ROWS OF THE TABLE
SELECT DISTINCT COUNT(*) FROM TABLENAME RETURNS THE NUMBER OF DISTINCT ROWS IN THE TABLE
THE MAX FUNCTION
IT RETURNS THE MAX VALUE OF THE GIVEN COLUMN.
EG
SELECT MAX(SALARY) FROM EMP;
RETURNS THE MAXIMUM VALUE OF THE SALARY COLUMN
THE MIN FUNCTION
IT RETURNS THE MIN VALUE OF THE GIVEN COLUMN
EG
SELECT MIN(SALARY) FROM EMP;
RETURNS THE MINIMUM VALUE OF THE SALARY COLUMN
THE SUM FUNCTION
IT RETURNS THE SUM OF THE TOTAL DATA PRESENT IN THE GIVEN COLUMN IN A TABLE
EG
SELECT SUM(SALARY) FROM EMP;
IT SUMS UP THE TOTAL SALARY AND RETURNS THE SUMMATION OF SALARY.
The GROUP BY Statement
The GROUP BY statement is used in conjunction with the aggregate functions to group the result-set by one or more columns.
SQL GROUP BY Syntax
SELECT column_name, aggregate_function(column_name)
FROM table_name
WHERE column_name operator value
GROUP BY column_name
SELECT - extracts data from a database
UPDATE - updates data in a database
DELETE - deletes data from a database
INSERT INTO - inserts new data into a database
Operator Description
= Equal
<> Not equal
> Greater than
< Less than
>= Greater than or equal
<= Less than or equal
BETWEEN Between an inclusive range
LIKE Search for a pattern
IN If you know the exact value you want to return for at least one of the columns
SQL DEFAULT Constraint
The DEFAULT constraint is used to insert a default value into a column.
The default value will be added to all new records, if no other value is specified.
SQL DEFAULT Constraint on CREATE TABLE
The following SQL creates a DEFAULT constraint on the "City" column when the "Persons" table is created:
CREATE TABLE Persons
(
P_Id int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Address varchar(255),
City varchar(255) DEFAULT 'Sandnes'
)
SQL DEFAULT Constraint on ALTER TABLE
ALTER TABLE Persons
ALTER COLUMN City SET DEFAULT 'SANDNES'
The COUNT() function
SELECT COUNT(*) FROM TABLENAME IT RETURNS THE NUMBER OF ROWS OF THE TABLE
SELECT DISTINCT COUNT(*) FROM TABLENAME RETURNS THE NUMBER OF DISTINCT ROWS IN THE TABLE
THE MAX FUNCTION
IT RETURNS THE MAX VALUE OF THE GIVEN COLUMN.
EG
SELECT MAX(SALARY) FROM EMP;
RETURNS THE MAXIMUM VALUE OF THE SALARY COLUMN
THE MIN FUNCTION
IT RETURNS THE MIN VALUE OF THE GIVEN COLUMN
EG
SELECT MIN(SALARY) FROM EMP;
RETURNS THE MINIMUM VALUE OF THE SALARY COLUMN
THE SUM FUNCTION
IT RETURNS THE SUM OF THE TOTAL DATA PRESENT IN THE GIVEN COLUMN IN A TABLE
EG
SELECT SUM(SALARY) FROM EMP;
IT SUMS UP THE TOTAL SALARY AND RETURNS THE SUMMATION OF SALARY.
The GROUP BY Statement
The GROUP BY statement is used in conjunction with the aggregate functions to group the result-set by one or more columns.
SQL GROUP BY Syntax
SELECT column_name, aggregate_function(column_name)
FROM table_name
WHERE column_name operator value
GROUP BY column_name
Subscribe to:
Posts (Atom)