Oracle Receivables : Useful AR Tables Informations

Hello Friends , here is some of quite commonly used AR ( receivables )tables and their usage. There are many other tables also in AR but here i am putting only few commonly used tables. for other table if needed we can dig furthur. Let go through below article and let me know if it useful.

1- RA_CUSTOMER_TRX_ALL

2- RA_CUSTOMER_TRX_LINES_ALL

3- RA_CUST_TRX_LINE_GL_DIST_ALL

4- AR_PAYMENT_SCHEDULES_ALL

5- AR_RECEIVABLES_TRX_ALL

6- AR_RECEIVABLE_APPLICATIONS_ALL

RA_CUSTOMER_TRX_ALL

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

Required Columns:

SOLD_TO_CUSTOMER_ID,

SOLD_TO_SITE_USE_ID,

BILL_TO_CUSTOMER_ID,

BILL_TO_SITE_USE_ID,

SHIP_TO_SITE_USE_ID,

PRINTING_OPTION,

PRINTING_PENDING,

TERM_ID,

REMIT_TO_ADDRESS_ID,

PRIMARY_SALES_REP_ID, and

INVOICE_CURRENCY_CODE

are required even though they are null allowed. The primary key for this table is CUSTOMER_TRX_ID.

RA_CUSTOMER_TRX_LINES_ALL

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

RA_CUST_TRX_LINE_GL_DIST_ALL

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

AR_PAYMENT_SCHEDULES_ALL

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

If you create a debit memo reversal when you reverse a receipt, Oracle Receivables creates a new payment schedule record for the debit memo and fills in REVERSED_CASH_RECEIPT_ID with the CASH_RECEIPT_ID of the receipt that was reversed. Oracle Receivables creates a new payment schedule record when you create a chargeback in the Receipts window. ASSOCIATED_CASH_RECEIPT_ID is the cash receipt of the payment you entered when you created the chargeback in this window. GL_DATE_CLOSED indicates the general ledger date on which your transaction was closed.

This column identifies which transactions Oracle Receivables selects when it displays current and overdue debit items in the aging reports. The aging reports also utilize the current balances in AMOUNT_DUE_REMAINING to display outstanding amounts for current and overdue debit items. ACTUAL_DATE_CLOSED gives the date on which you applied a payment or credit to an open transaction that set AMOUNT_DUE_REMAINING to 0 for that transaction. Oracle Receivables uses ACTUAL_DATE_CLOSED to determine which transactions to include when you print statements. The primary key for this table is PAYMENT_SCHEDULE_ID, which identifies the transaction that created the row.

 

RA_CUSTOMER_TRX_ALL

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

Required Columns:

SOLD_TO_CUSTOMER_ID,

SOLD_TO_SITE_USE_ID,

BILL_TO_CUSTOMER_ID,

BILL_TO_SITE_USE_ID,

SHIP_TO_SITE_USE_ID,

PRINTING_OPTION,

PRINTING_PENDING,

TERM_ID,

REMIT_TO_ADDRESS_ID,

PRIMARY_SALES_REP_ID, and

INVOICE_CURRENCY_CODE

are required even though they are null allowed. The primary key for this table is CUSTOMER_TRX_ID.

RA_CUSTOMER_TRX_LINES_ALL

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

RA_CUST_TRX_LINE_GL_DIST_ALL

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

AR_PAYMENT_SCHEDULES_ALL

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

If you create a debit memo reversal when you reverse a receipt, Oracle Receivables creates a new payment schedule record for the debit memo and fills in REVERSED_CASH_RECEIPT_ID with the CASH_RECEIPT_ID of the receipt that was reversed. Oracle Receivables creates a new payment schedule record when you create a chargeback in the Receipts window. ASSOCIATED_CASH_RECEIPT_ID is the cash receipt of the payment you entered when you created the chargeback in this window. GL_DATE_CLOSED indicates the general ledger date on which your transaction was closed.

This column identifies which transactions Oracle Receivables selects when it displays current and overdue debit items in the aging reports. The aging reports also utilize the current balances in AMOUNT_DUE_REMAINING to display outstanding amounts for current and overdue debit items. ACTUAL_DATE_CLOSED gives the date on which you applied a payment or credit to an open transaction that set AMOUNT_DUE_REMAINING to 0 for that transaction. Oracle Receivables uses ACTUAL_DATE_CLOSED to determine which transactions to include when you print statements. The primary key for this table is PAYMENT_SCHEDULE_ID, which identifies the transaction that created the row.

 

 

AR_RECEIVABLES_TRX_ALL

This table links accounting information with your Receivables Activities. Possible types of activities include Adjustment, Miscellaneous Cash, and Finance Charges. If your type is Miscellaneous Cash, you can associate either a distribution set or a standard accounting flexfield to your Receivables Activity. Oracle Receivables uses one row for each activity. You use your receivables activities to speed receipt entry and generate finance charges. The other types of activities that were valid in release 9 and no longer valid in Release 10 were converted (as part of the upgrade) such that the actual accounting flexfield CODE_COMBINATION_ID is stored in the table instead of the RECEIVABLES_TRX_ID. In Release 9, all of these references were in AR_BATCH_SOURCES; they are now in AR_RECEIPT_METHOD_ACCOUNTS_ALL. The primary key for this table is RECEIVABLES_TRX_ID.

AR_RECEIVABLE_APPLICATIONS_ALL

This table stores all accounting entries for your cash and credit memo applications. Each row includes the amount applied, status, and accounting flexfield information. Possible statuses of your applications include APP, UNAPP, ACC, and UNID. You use this information to determine the applications of your payments or credit memos. CONFIRMED_FLAG is a denormalization from AR_CASH_RECEIPTS_ALL.If the cash receipt is not confirmed, the applications of that receipt are not reflected in the payment schedule of the transaction it is applied against. There are two kinds of applications: CASH and CM (for credit memo applications). This is stored in the column APPLICATION_TYPE.

CASH applications represent applications of a cash receipt. When a cash receipt is initially created, a row is created in this table that has a status of UNAPP for the amount of the cash receipt. Each subsequent application creates two rows – one with a status of APP for the amount being applied to the invoice and one with status UNAPP for the negative of the amount being applied. Ifyou reverse a cash application, a row with status APP with the inverse amount of the original application (i.e. the negative of the original application amount) is created. The corresponding UNAPP rows is alsocreated which will have a positive amount (the same amount as the application being reversed). For example: UNAPP 100 creation of a$100 cash receipt APP 60 application of $60 of this cash receipt UNAPP –60 this row takes away (debits) unapplied APP –60 reversal of the $60 application UNAPP 60 this rows puts back(credits) unapplied The sum of the AMOUNT_APPLIED column for CASH applications should always equal the amount of the cash receipt. CM applications, on the other hand, do not have rows of status UNAPP. They only use rows with a status of APP. CASH_RECEIPT_ID stores the cash receipt identifier of the receipt you entered. Oracle Receivables concurrently creates a record of this receipt in the AR_CASH_RECEIPTS_ALL table.

This column is null for a credit memo application. CODE_COMBINATION_ID stores valid Accounting Flexfield segment value combinations that will be credited in the General Ledger when this application is posted. A negative value in AMOUNT_APPLIED becomes a debit. The STATUS of a receivable application determines which flexfield account Oracle Receivables uses. For example, if you enter a cash receipt of $500 as Unidentified, Oracle Receivables creates a record in theAR_RECEIVABLE_APPLICATIONS_ALL table with AMOUNT_APPLIED = 500 and STATUS = ’UNID’. Oracle Receivables uses the foreign key CODE_COMBINATION_ID to associate this payment with the Unidentified flexfield account. CUSTOMER_TRX_ID, CASH_RECEIPT_ID, and PAYMENT_SCHEDULE_ID identify the transaction that you are actually applying. APPLIED_CUSTOMER_TRX_ID and APPLIED_PAYMENT_SCHEDULE_ID identify the invoice or credit memo that receives the application. For example, if you apply a receipt against an invoice, Oracle Receivables creates a record in the AR_RECEIVABLE_APPLICATIONS_ALL table. The CASH_RECEIPT_ID and the PAYMENT_SCHEDULE_ID of this record identify the receipt you are applying. APPLIED_PAYMENT_SCHEDULE_ID and APPLIED_CUSTOMER_TRX_ID for this record belong to the invoice that is receiving the application. If you apply a credit memo against the invoice, Oracle Receivables creates a record in the AR_RECEIVABLE_APPLICATIONS_ALL table that has theCUSTOMER_TRX_ID and the PAYMENT_SCHEDULE_ID of the credit memo you are applying. The APPLIED_PAYMENT_SCHEDULE_ID and the APPLIED_CUSTOMER_TRX_ID of this record belong to the invoice that is receiving the application. If you combine an on account credit and a receipt, Oracle Receivables creates a record in the AR_RECEIVABLE_APPLICATIONS_ALL table.

The PAYMENT_SCHEDULE_ID and the CASH_RECEIPT_ID of this record identify the receipt. The APPLIED_PAYMENT_SCHEDULE_ID and the APPLIED_CUSTOMER_TRX_ID of this record identify the on account credit that you are combining with the receipt. The primary key for this table is RECEIVABLE_APPLICATION_ID, which uniquely identifies the transaction that created the row.

 

Thanks – Shivmohan Purohit

 

 

Oracle A.I.M. Methodology – template list

Oracle A.I.M. Methodology encompasses a project management methodology with documentation templates that support the life cycle of an implementation. The life cycle methodology and documentation templates allows A.I.M. to be a very useful tool for managing implementation projects successfully. This is a depiction of the A.I.M. methodology life cycle:

Application Implementation Method is a proven approach for all the activities required to implement oracle applications. there are eleven processes of implementation.

1. Business Process Architecture [BP] – This phase outlines:

• Existing Business Practices
• Catalog change practices
• Leading practices
• Future practices

BP.010 Define Business and Process StrategyBP.020 Catalog and Analyze Potential Changes

BP.030 Determine Data Gathering Requirements

BP.040 Develop Current Process Model

BP.050 Review Leading Practices

BP.060 Develop High-Level Process Vision

BP.070 Develop High-Level Process Design

BP.080 Develop Future Process Model

BP.090 Document Business Procedure

2. Business Requirement Definition [RD] – This phase explains about the initial baseline questionnaire and gathering of requirements.

RD.010 Identify Current Financial and Operating Structure RD.020 Conduct Current Business Baseline RD.030 Establish Process and Mapping Summary RD.040 Gather Business Volumes and Metrics RD.050 Gather Business Requirements RD.060 Determine Audit and Control Requirements RD.070 Identify Business Availability Requirements RD.080 Identify Reporting and Information Access Requirements

3. Business Requirement Mapping [BR] – In this phase the requirements of business are matched with the standard functionality of the oracle applications.

BR.010 Analyze High-Level GapsBR.020 Prepare mapping environment

BR.030 Map Business requirements

BR.040 Map Business Data

BR.050 Conduct Integration Fit Analysis

BR.060 Create Information Model

BR.070 Create Reporting Fit Analysis

BR.080 Test Business Solutions

BR.090 Confirm Integrated Business Solutions

BR.100 Define Applications Setup

BR.110 Define security Profiles

4. Application and Technical Architecture [TA] – This outlines the infrastructure requirements to implement oracle applications.

TA.010 Define Architecture Requirements and StrategyTA.020 Identify Current Technical Architecture

TA.030 Develop Preliminary Conceptual Architecture

TA.040 Define Application Architecture

TA.050 Define System Availability Strategy

TA.060 Define Reporting and Information Access Strategy

TA.070 Revise Conceptual Architecture

TA.080 Define Application Security Architecture

TA.090 Define Application and Database Server Architecture

TA.100 Define and Propose Architecture Subsystems

TA.110 Define System Capacity Plan

TA.120 Define Platform and Network Architecture

TA.130 Define Application Deployment Plan

TA.140 Assess Performance Risks

TA.150 Define System Management Procedures

5. Build and Module Design [MD] – This phase emphasizes the development of new functionality (customization) required by the client. It mainly details how to design the required forms, database and reports.

MD.010 Define Application Extension StrategyMD.020 Define and estimate application extensions

MD.030 Define design standards

MD.040 Define Build Standards

MD.050 Create Application extensions functional design

MD.060 Design Database extensions

MD.070 Create Application extensions technical design

MD.080 Review functional and Technical designs

MD.090 Prepare Development environment

MD.100 Create Database extensions

MD.110 Create Application extension modules

MD.120 Create Installation routines

6. Data Conversion [CV] – Data Conversion is the process of converting or transferring the data from legacy system to oracle applications. Ex. Transferring customer records from the legacy to the Customer Master.

CV.010 Define data conversion requirements and strategyCV.020 Define Conversion standards

CV.030 Prepare conversion environment

CV.040 Perform conversion data mapping

CV.050 Define manual conversion procedures

CV.060 Design conversion programs

CV.070 Prepare conversion test plans

CV.080 Develop conversion programs

CV.090 Perform conversion unit tests

CV.100 Perform conversion business objects

CV.110 Perform conversion validation tests

CV.120 Install conversion programs

CV.130 Convert and verify data

7. Documentation [DO] – Documentation prepared per module that includes user guides and implementation manuals.

DO.010 Define documentation requirements and strategyDO.020 Define Documentation standards and procedures

DO.030 Prepare glossary

DO.040 Prepare documentation environment

DO.050 Produce documentation prototypes and templates

DO.060 Publish user reference manual

DO.070 Publish user guide

DO.080 Publish technical reference manual

DO.090 Publish system management guide

8. Business System Testing [TE] – A process of validating the setup’s and functionality by QA(functional consultant) to certify status.

TE.010 Define testing requirements and strategyTE.020 Develop unit test script

TE.030 Develop link test script

TE.040 Develop system test script

TE.050 Develop systems integration test script

TE.060 Prepare testing environments

TE.070 Perform unit test

TE.080 Perform link test

TE.090 perform installation test

TE.100 Prepare key users for testing

TE.110 Perform system test

TE.120 Perform systems integration test

TE.130 Perform Acceptance test

9. Performance Testing [PT] – Performance testing is the evaluation of transactions saving time, transaction retrieval times, workflow background process, database performance, etc

PT.010 – Define Performance Testing StrategyPT.020 – Identify Performance Test Scenarios

PT.030 – Identify Performance Test Transaction

PT.040 – Create Performance Test Scripts

PT.050 – Design Performance Test Transaction Programs

PT.060 – Design Performance Test Data

PT.070 – Design Test Database Load Programs

PT.080 – Create Performance Test TransactionPrograms

PT.090 – Create Test Database Load Programs

PT.100 – Construct Performance Test Database

PT.110 – Prepare Performance Test Environment

PT.120 – Execute Performance Test

10. Adoption and Learning [AP] – This phase explains the removal of the legacy system and oracle application roll out enterprise wide.

AP.010 – Define Executive Project StrategyAP.020 – Conduct Initial Project Team Orientation

AP.030 – Develop Project Team Learning Plan

AP.040 – Prepare Project Team Learning Environment

AP.050 – Conduct Project Team Learning Events

AP.060 – Develop Business Unit Managers’Readiness Plan

AP.070 – Develop Project Readiness Roadmap

AP.080 – Develop and Execute CommunicationCampaign

AP.090 – Develop Managers’ Readiness Plan

AP.100 – Identify Business Process Impact onOrganization

AP.110 – Align Human Performance SupportSystems

AP.120 – Align Information Technology Groups

AP.130 – Conduct User Learning Needs Analysis

AP.140 – Develop User Learning Plan

AP.150 – Develop User Learningware

AP.160 – Prepare User Learning Environment

AP.170 – Conduct User Learning Events

AP.180 – Conduct Effectiveness Assessment

11. Production Migration [PM] – The process of “decommissioning” of legacy system and the usage(adoption) of oracle application system.

PM.010 – Define Transition Strategy

PM.020 – Design Production Support Infrastructure

PM.030 – Develop Transition and Contingency Plan

PM.040 – Prepare Production Environment

PM.050 – Set Up Applications

PM.060 – Implement Production Support Infrastructure

PM.070 – Verify Production Readiness

PM.080 – Begin Production

PM.090 – Measure System Performance

PM.100 – Maintain System

PM.110 – Refine Production System

PM.120 – Decommission Former Systems

PM.130 – Propose Future Business Direction

PM.140 – Propose Future Technical Direction

thanks – Shivmohan Purohit

Account Recievables – Conversion – Invoices

Whenever we are going in for implementation of Receivables module, we have to consider the necessity of bringing in customer open balances from the old system to Oracle Receivables.

Some of the key questions that needs to be addressed before we take up a conversion activity. This is just a sample list and not an exhaustive one:

1. What are the different types of invoices in existing system Provide invoice samples? (invoices, credit/ debit memos, commitments, chargebacks)

2. Do we need to migrate only open invoices?

3. Do we migrate closed invoices also, if yes, then for what time period?

4. Please explain the invoice numbering mechanism? Is it automatic?

5. What are the interfaces from/to your existing receivables system?

6. Will the old system still be in place for querying and reporting purpose?

One can adopt one of the following three strategies for conversion:

1. Consolidate all the open balances customer-wise and create a single open invoice for each customer in the new Oracle system. The advantage of this system is that it is quite easy and not data intensive and makes good business sense in case of small businesses with very few customers. The major demerit of this approach is that later on one cannot track the individual invoices which the customer had sent and can become an audit issue also. In case of dispute over payment, this invoice will remain open till the dispute is resolved. Also, aging of invoices and dunning history will be lost.

2. Bring in all the open and partially paid invoices, credit/debit memos into the new system. Migrate all the unapplied and partially applied receipts to the new system. The advantage of this process of conversion is that you can track all open invoices individually and apply the correct receipt to correct invoice. Also, the conversion effort will be moderately low compared to case if you migrate all open and closed invoices. The disadvantage of this approach is that you cannot have a track of closed invoices in the new system. Also, it would be tough to handle scenarios where there is a dispute regarding incorrect receipt application, etc. This is the most common approach taken for receivables invoice, credit/debit memo and receipt migration.

3. Migrate all open and closed invoices to the new system. Reapply the migrated receipts to invoices in the new system. This approach makes sense if your receivables data is quite small else the effort involved in migrating all closed invoices and credit memos to the new system does not make much business sense.

The next question that arises is how we should migrate the invoices, credit/debit memos and receipts to the new system. Oracle provides standard interfaces to load the same. We can also use tools like Dataloader or manually key in the data into Oracle.

In this article i will talk of invoice, credit/debit memo conversion only. Prior to invoice migration, customer migration should be over apart from other pre-requisites. Following is the list of pre-requisites that should be completed prior to invoice, credit/debit memo conversion:

•Set-up of Customer Payment Terms should be complete

•Set-up of Currencies should be complete (this is necessary in case you have foreign currency invoices also)

•Set-up of Transaction Types should be complete

•Set-up of Accounting Rules should be complete

•Set-up of Tax rates and Tax codes should be complete

•Set up for sales representative should be complete

•Set up for debtor area should be complete

•Set up for income category should be complete

•Automatic customer invoice numbering should be set to ‘No’

•Customer and Customer address should be migrated in the system

•Disable the Invoice interface purge program so that the data successfully imported should not get purged in the interface table.

•Set up for invoice batch source name should be complete

In the next step extract Invoice data from the legacy files and using SQL loader populate the interface tables RA_INTERFACE_LINES_ALL and RA_INTERFACE_DISTRIBUTIONS_ALL. Submit the Auto Invoice open interface program. Data from the two interface tables will be uploaded to the following base tables using the Invoice open interface program:

•RA_CUSTOMER_TRX_ALL

•RA_CUSTOMER_TRX_LINES_ALL

•RA_CUST_TRX_LINE_GL_DIST_ALL

•RA_BATCHES_ALL

•RA_CUST_TRX_LINE_SALESREPS_ALL

•AR_RECEIVABLE_APPLICATIONS_ALL

•AR_PAYMENT_SCHEDULES_ALL

•RA_INTERFACE_ERRORS_ALL

Ensure that the Purge Interface check box is not checked when you submit the Autoinvoice program. In the Autoinvoice errors form you can see the error corresponding to failed records. Correct the errors in the interface table and rerun the Autoinvoice program. Submit the Autoinvoice Purge Program separately. Only records that have been successfully processed by Autoinvoice are purged.

Using autoinvoice you can migrate invoices, credit/debit memos and on-account credits into Oracle. However, you have to set grouping rules (Navigation > Setup > Transactions > Autoinvoice > Grouping Rule) to group lines to create one transaction and ordering rules (Navigation > Setup > Transactions > Autoinvoice > Line Ordering Rules) to determine the order of the transaction lines on a particular invoice.

Oracle Interview Questions – Oracle Forms – Custom Development – FAQ

What is the ICX: Forms Launcher system profile option for?

This profile option is used by the Self Service Web Applications Personal Home Page (also known as ICX) to determine the base URL needed to launch an application, which in this case is a Forms application.

What should ICX: Forms Launcher be set to?

ICX: Forms Launcher –is set to ?http://machine_name:port/dev60cgi/f60cgi?. In Apps release 11i you can add some parameters to this URL to enable some Forms features like tracing.

What is FORMS60_TIMEOUT?
FORMS60_TIMEOUT is an environment setting that determines the maximum idle time (in minutes) before f60webmx shuts down.  Note that it will only terminate an idle middle tier process, i.e. one which is waiting for the "next message" from the client. If the middle tier process is running a transaction or waiting for a query to complete it will not have take effect.

How do you enable Forms Runtime Diagnostics (FRD) in Apps?
To enable Forms Runtime Diagnostics (FRD):

– login to Apps as sysadmin
– click on Profile/System
– query ICX%FORMS%LAUNCHER
– add the following to the end of its value at user level:
?record=collect&log=/tmp/forms_frd.log

Note that like any Apps profiles you can do this on various levels e.g. site, user, etc. so that you target your FRD accordingly. Also be aware that FRD incurs significant overhead to Apps processing so disable it when not in use

How do you generate Apps Forms modules or FMB files?
Oftentimes as part of upgrading Forms or modifying a Form module or applying a patch modifying a Form module, you would encounter an issue that would necessitate manually regenerating the Forms module executable or FMX file. To do this you issue the following command:

f60gen module=form_name.fmb userid=apps/apps output_file=form_name.fmx module_type=form batch=yes compile_all=special

How do you generate Apps Forms library modules or PLL files?
To do this you issue the following command:

f60gen module=library_name.pll userid=apps/apps module_type=library batch=yes compile_all=special

How do you generate Apps Forms menu modules or MMB files?
Note that there is only one menu for Apps so it is rare that you need to regenerate the menu. To do this you issue the following command:

f60gen module=FNDMENU.mmb userid=apps/apps output_file=FNDMENU.mmx module_type=menu batch=yes compile_all=special

What is the sequence in which Forms resolves program unit calls?
Forms will attempt to resolve a program unit call in the following sequence:

Program Units node
Forms Library
Database

Where can you find the source Forms modules for Apps?
Apps places all its source (FMB) files in the $AU_TOP/forms/<language> directory whereas the FMX files reside in their respective $PRODUCT_TOP/forms/<language> directory. On the other hand, all menu (MMB, MMX) and library (PLL and PLX) files are copied to the $AU_TOP/resource directory.

How can you find the version of Forms in Apps?
Once you are in an Apps form …

click on Help
click on About Oracle Applications

information is under the Current Form section. The Form Name corresponds to the FMB and FMX file for that form.  The Form Version corresponds to the release level of that form.

How can I open an Apps form in Forms Builder

If you want to open a product specific form, make sure you have all its associated forms and libraries copied over.  Since it is quite difficult to pinpoint exactly what this is, its best to just copy over the entire contents of $AU_TOP/forms/<language> and $AU_TOP/resource.

How can you confirm the version of the FMX or FMB file?
Oftentimes, once you determine the version and name of the current form you want to peek into the internal workings of the actual form itself. To ensure that you are peeking at the right release of the FMB file you can do the following:

$adident Header FNDSCSGN.fmb

If you simply copy the form over to a a machine that does not have Apps installed, you will run into is a lot of FRM-18108: "Failed to load the following objects" errors.  This is because an Apps form is usually dependent on a host of other forms, libaries and menus.

If you want to open the TEMPLATE.fmb form, make sure you have the following forms, libraries, copied over as well from the $AU_TOP/forms/<language> and $AU_TOP/resource directories:

APPSTAND.fmb
APPCORE.pll
APPCORE2.pll
APPDAYPK.pll
CUSTOM.pll
FNDSQF.pll
GHR.pll
GLOBE.pll
GSM.pll
JA.pll
JE.pll
JL.pll
VERT.pll
OPM.pll
PQH_GEN.pll
PSA.pll
PSAC.pll
PSB.pll
IGILUTIL.pll
IGILUTIL2.pll

What is a Forms Builder node?

A Forms Builder node refers to the leaves and branches of its Object Navigator. The Object Navigator provides a hierarchical display of the objects in a Form modules.

+Forms
   +Module
   +Trigger
   +Alerts
   +Attached Libraries
   +Data Blocks
   +Canvases
   +Editors
   +LOVs
   +Object Groups
   +Parameters
   +Pop Up Menus
   +Program Units
   +Property Classes
   +Record Groups
   +Reports
   +Visual Attributes
   +Windows
+Menu
+PL/SQL Libraries
+Object Libraries
+Built-In Packages
+Database Objects

Objects are grouped under their respective nodes. For example, all of the windows defined in a form module appear under the Windows node; all the LOVs defined in the form module appearunder the LOVs node and all the program units appear under the Program Units node.  It is important to familiarize yourself with this in case you need to navigate within an Apps form during the course of debugging a problem.

 



 

How To Customize Standard Oracle Application Using Custom Library – custom.pll

There are numerous scenarios for each customer to customize the standard Application. The following sample code demonstrate how to pop up an error message when customer business validation fails.
This note provides a detail steps for customizing the standard application using custom library.

The code attached here will validate number of digits entered in Customer PO Number field from the sales order form. If the number of digits exceeds 3 digits an error message needs to be populated.

1. Take a back up of custom.pll and custom.plx from $AU_TOP/resource
2. Have custom.pll, appcore.pll and appcore2.pll copied over to your local folder. The best method is to just copy the entire contents of $AU_TOP/resource
3. Open CUSTOM.pll in Oracle Forms Developer
4. Attach appcore2.pll to the custom library
5. Modify the text of the CUSTOM package body in the appropriate section as below
6. Save your changes and use the Oracle Forms Compiler program to generate a custom.plx file for the CUSTOM library
7. Exit from Oracle Forms Developer.
8. Verify that your file generated successfully. If path name is left blank the file will be generated in c:\orawin\bin (or platform equivalent). Move it to AU_TOP/resource.
9. Retry it out from the Oracle Applications Navigator.

Sample

Modify the code CUSTOM package body as follows in the appropriate sections

procedure event(event_name varchar2) is
form_name varchar2(30) := name_in(‘system.current_form’);
block_name varchar2(30) := name_in(‘system.cursor_block’);
item_name varchar2(30) := name_in(‘system.cursor_item’); 
Begin
if (form_name = ‘OEXOEORD’and block_name = ‘ORDER’) then
   if LENGTH(name_in(‘ORDER.CUST_PO_NUMBER’)) > 3 then
     fnd_message.set_name(‘FND’,’Cust PO Number should be less than 4 digits’);
     fnd_message.Error;
     RAISE FORM_TRIGGER_FAILURE;
   End if;
End if;
End Event;

Output

If the customer PO Number in sales order form has less than 4 digits the form will not populate any error message. If the customer po number field has more than for 3 digits the error message will be populated.

Retry it from following steps:

1. Open the Application Navigator 
2. Navigate to Order Management Responsibility 
3. Open the Sales Order Form 
4. Enter the values in Custom PO Number field with 4 digits
5. While navigating to next field the following error message pops up   

Cust PO Number should be less than 4 digits

How To Make All The Responsibilities Read Only For A User

Here is a sample code could be used to make all the responsibilities read only for a specific user. I am sure we can use it in different variations.

1. Open the Custom.pll in the Form Builder.
2.Add the following sample code in the Procedure Event for the event WHEN-NEW-FORM-INSTANCE
3.Compile the Custom.pll and place under the directory $AU_TOP/resource

BEGIN
IF event_name = ‘WHEN-NEW-FORM-INSTANCE’ THEN
IF FND_PROFILE.VALUE(‘USER_NAME’)=’<USER_NAME>‘ THEN
BEGIN
COPY(‘Entering app_form.query_only_mode.’,’global.frd_debug’);
COPY(‘YES’, ‘PARAMETER.QUERY_ONLY’);
APP_MENU2.SET_PROP(‘FILE.SAVE’, ENABLED,PROPERTY_OFF);
APP_MENU2.SET_PROP(‘FILE.ACCEPT’, ENABLED,PROPERTY_OFF);
formname := NAME_IN(‘system.current_form’);
blockname := GET_FORM_PROPERY(formname, FIRST_BLOCK);
WHILE (blockname is not null) LOOP
IF (GET_BLOCK_PROPERTY(blockname, BASE_TABLE) is not NULL) THEN
SET_BLOCK_PROPERTY(blockname, INSERT_ALLOWED, PROPERTY_FALSE);
SET_BLOCK_PROPERTY(blockname, UPDATE_ALLOWED, PROPERTY_FALSE);
SET_BLOCK_PROPERTY(blockname, DELETE_ALLOWED, PROPERTY_FALSE);
END IF;
blockname := GET_BLOCK_PROPERTY(blockname, NEXTBLOCK);
END LOOP;
END query_only_mode;
END;

The above code will make all the Responsibilities read only for a specific user.

It will fundamentally make all the form functions to behave as passing the parameter QUERY_ONLY.

Back-to-Back Order – How to

Back-to-Back Order is very useful functionality in Oracle Applications.

Key Business Drivers

• Data integration

• Lower inventory cycle time

• Lower inventory cost

• Link supply to specific demand

• Can offer a variety of product to customer

• Used heavily in contract manufacturing environment where the product is standardized and the company plans to focus more on product design rather than manufacturing

Many times business suffers a loss when data is transferred between quotations, orders, purchase orders or invoices?

Damage to any business due to data loss or corruption is always very high. This can be due to a simple user error or data corruption. During the manual transfer of data, the input of incorrect information or staff errors are very real risks. This can have a profound impact as your business grows and staff are under more pressure to process orders in a market where the client expectation is no longer to have their order processed in days or hours but in real-time.

Back to Back order process allows you to process information and orders in very logical manner ensuring a simplistic and efficient process. The integration between quotations, order processing and stock management means that all orders can be processed in real time and you are no longer dependant on a manual process to be run.

e.g. When the PO is received, reservation gets applied automatically against the Sales Order. This prevents allocating material to some other demand.

The key behind the integration of a system is the ability to seamlessly integrate different pieces of information, this leads us to back-to-back order processing.

The key areas that are focused on as part of the back to back process are:-

• Quotations

• Orders

• Requisition

• Invoices (in ‘Oracle Accounts Payable’ and ‘Oracle Accounts Receivable’)

• Purchase Orders

Back to back order processing provides an integrated seamless link from the quotation stage, through to the purchasing of stock (or services), to dispatching, delivering and invoicing your client and the receipt and payment of invoices. It is also extended to invoicing (against PO/receipt) and payment to your supplier. All this process is done using Oracle Work-Flow, standard work flow is given by Oracle but if you want you can modify the same to fulfill business needs. Approval processes are also taken care by Work-Flow.

The entire process can be performed in the minimal amount of time without any redundancy. Each document has reference of some other document so it doesn’t get lost in between. Below are the steps in Back to Back order.

• Quotations are created and sent to the client.

• The client places the order and all required acknowledgements are sent.

• Requisitions / Purchase Orders are automatically created for the required stock.

• Management of awaiting stock from suppliers.

• Tracking and managing supplier and customer communication.

• Receiving of stock and handling of part deliveries.

• Dispatching the order to your customer with management of delivery locations and methods.

• Customer Invoicing.

• Supplier payment.

Some of the important documents that gets created automatically through the different stages in this cycle include (automatic creation of document/s depends on setup).

Quotations, Order Acknowledgements and confirmations, Invoices and Proforma Invoices, Purchase Orders, Stock Receipt Slips, Stock Transfer Slips, Dispatch Notes, Packing to name a few.

For demo please visit two links given below:

• Back-to-Back Order Cycle http://functionalguy.blogspot.com/2009/02/back-to-back-order-cycle.html

• Requisition to Pay Cycle (Procure to Pay) in Oracle http://functionalguy.blogspot.com/2009/02/requisition-to-pay-cycle.html