Oracle Receivables Module Technical Details

Oracle Receivables Module Technical Details

Oracle Accounts Receivable uses the following tables for recording customer account information:

The major tables containing parties and customer accounts information in Oracle Receivables are grouped by business function.
• HZ_PARTIES
• HZ_CUST_ACCOUNTS
• HZ_PARTY_SITES
• HZ_CUST_ACCT_SITES_ALL
• HZ_CUST_SITE_USES_ALL
• HZ_LOCATIONS
• HZ_PARTY_RELATIONSHIPS
• HZ_ORGANIZATION_PROFILES
• HZ_CONTACT_POINTS
• HZ_CUST_ACCOUNT_ROLES
• HZ_PERSON_PROFILES
• HZ_ORG_CONTACTS

Transaction Tables
• RA_CUSTOMER_TRX_ALL
• RA_CUSTOMER_TRX_LINES_ALL
• RA_CUST_TRX_LINE_GL_DIST_ALL
• AR_PAYMENT_SCHEDULES_ALL
• AR_CASH_RECEIPTS_ALL
• AR_CASH_RECEIPT_HISTORY_ALL
• AR_RECEIVABLE_APPLICATIONS_ALL
• AR_ADJUSTMENTS_ALL

HZ_PARTIES
A party is an entity that can enter into a business relationship.
This table stores basic information about parties, which is true regardless of this relationship to the deploying company. Entities are modeled only once in HZ_PARTIES, regardless of how many roles they play. For example, if an organization is a customer, a distributor, and a partner, there is still only one record for them in HZ_PARTIES.

Parties can be one of four types:
Organization - Oracle Corporation
Person - Jane Doe
Group – Doc Household
Relationship - Jane Doe at Oracle Corporation

HZ_LOCATIONS
A location is a point in geographical space described by an address and/or geographical Indicators such as latitude or longitude.
• This table stores information about an address such as: street address and postal code.
• This table provides physical location information about parties (organizations and people) and customer accounts.
• Records in HZ_LOCATIONS can store delivery and postal code information about a location, store latitude and longitude, and can be used to determine the appropriate calculations and tax rates for sales tax and VAT calculations.

HZ_PARTY_SITES
This table links a party (HZ_PARTIES) and a location (HZ_LOCATIONS) and stores location-Specific party information such as a person’s mail stops at their work address.
• One party can point to one or more party sites.
• One location can point to one or more party site.
• Party sites serve as the intersection between parties and locations, allowing for a many-to-many relationship between the two.

HZ_RELATIONSHIPS
This table stores information about relationships between two entities, for example, one party and another party.
• The SUBJECT_ID and OBJECT_ID columns specify the relationship that exists between two parties. For example, if the party relationship type is “Parent Of,” then a holding company could be the “SUBJECT_ID” in the relationship while one of its subsidiaries could be the OBJECT_ID. Creating a party contact causes a party relationship to be created.
• A party can have different relationships with one or more other parties that can change over time.

HZ_ORGANIZATION_PROFILES
This table stores a variety of information about a party of type Organization.
• This table gets populated when a party of type ORGANIZATION is created.
• Historical data is also stored in this table.

HZ_PERSON_PROFILES
This table stores a variety of information about a party of type Person.
• For example, this table could contain the correct spelling and phonetic pronunciation of the person’s name.
• Some information in this table may also be entered into the HZ_PARTIES table.

HZ_ORG_CONTACTS
This table stores a variety of information about an organization contact.
• The records in this table provide information about a contact position such as job title, rank, and department.
• This table is not used to store information about a specific person or organization. For example, this table may include a record for the position of Vice President of Manufacturing that indicates that the contact is a senior executive, but it would not include the name of the person in that position.

HZ_CUST_ACCOUNTS
This table stores information about customer/financial relationships established between a Party and the deploying company.
• Because a party can have multiple customer accounts, this table may contain several records for a single party. For example, an individual person may establish a personal account, a family account, and a professional account for a consulting practice.

HZ_CUST_ACCT_SITES_ALL
This table stores information about customer/financial account sites information.
Stores information about customer sites. One customer account can have multiple sites.

HZ_CUST_SITE_USES_ALL
This table stores information about the business purposes assigned to a customer account site.
• A customer account site can have multiple purposes, but each record in this table only specifies one purpose for a customer account site. For example, a customer account site may be assigned as a ship-to site in one record and as a bill-to site in another record.

HZ_CUST_ACCOUNT_ROLES
This table stores information about a role or function that a party performs as related to a customer account. For example, Jane Doe might be the Legal Contact for a specific customer account of Corporation ABC. Note that account ownership such as financial responsibility for an account is determined by the single party ID that is stored directly on the HZ_CUST_ACCOUNTS table.

HZ_CONTACT_POINTS
This table stores information about how to communicate with parties or party sites using electronic media or methods such as Electronic Data Interchange (EDI), e-mail, telephone, telex, and the Internet.
• Each medium or method should be stored as a separate method in this table. For example, the attributes of a complete telephone number connection should be stored in a record, while EDI information should be stored in a different record.

RA_CUSTOMER_TRX_ALL
This table stores invoice, debit memo, commit-ment, chargeback, bills receivable, 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 and these are all distinguished by their transaction types stored in RA_CUST_ TRX_ TYPES_ALL.

RA_CUSTOMER_TRX_LINES_ALL
This table stores information about invoice, debit memo, credit memo, bills receivable, and commitment lines. It describes to the customer the charges that appear on these documents.

AR_PAYMENT_SCHEDULES_ALL
This table stores all transactions except adjust-ments and miscellaneous cash receipts. A miscellaneous cash receipt is one that is not connected to a customer.
• All customer-related activity is logged in this table.
• This table is updated when an activity occurs against an invoice, debit memo, chargeback, credit memo, on-account credit, bills receivable,
receipt, or commitments.

RA_CUST_TRX_TYPES_ALL
This table stores information about each transaction type for all classes of transactions, for example, invoices, commitments, and credit memos.
• Each row includes Auto Accounting information
as well as standard defaults for the resulting invoices. The primary key for this table is CUST_TRX_TYPE_ID.

AR_TRANSACTION_HISTORY_ALL
This table is a Bills Receivable-specific table containing the history of a transaction’s lifecycle.
• A new row is created each time there is activity on the transaction or the status of the transaction has changed.
• This table stores the header for the Receivables posting information.

AR_DISTRIBUTIONS_ALL
This table stores the accounting distributions for cash receipts, miscellaneous receipts, adjustments, credit memo applications, cash receipt applications, and bills receivable transactions.

AR_CASH_RECEIPTS_ALL
This table stores one record for each receipt entry.
• All cash receipts are logged in this table.
• Oracle Receivables creates records concurrently in the AR_CASH _RECEIPT_ HISTORY_ ALL, AR_PAYMENT_ SCHEDULES_ ALL, AR_DISTRI-BUTIONS_ALL, and AR_ RECEIVABLE_ APPLICA-TIONS_ALL tables for invoice-related receipts.
• For receipts that are not related to invoices, records are created in the AR_MISC_CASH_ DISTRIBUTIONS_ALL table instead of the AR_RECEIVABLE_APPLICATIONS_ ALL table.

AR_CASH_RECEIPT_HISTORY_ALL
This table stores all of the activity that is contained for the life cycle of a receipt.
• Each row represents one step.
• The status field for that row tells you which step the receipt has reached.
• Possible statuses are Approved, Confirmed, Remitted, Cleared, and Reversed.

AR_RECEIVABLE_APPLICATIONS_ALL
This table stores all accounting entries for cash and credit memo applications.
• Each row includes the amount applied, status, and accounting flex field information.

AR_MISC_CASH_DISTRIBUTIONS_ALL
This table stores all accounting entries for miscellaneous cash applications.
• Miscellaneous cash cannot be invoiced, such as stock revenue, interest income, and investment income.
• AR_CASH_RECEIPTS_ALL stores one record for each payment, and this table stores one record for each distribution of the receipt.

AR_RECEIPT_CLASSES
This table stores the different receipt classes that you define.
• Receipt classes determine whether the receipt[s] belonging to this class are created manually or automatically, and whether the receipts go through the different steps in a receipt’s life-cycle.

AR_RECEIPT_METHODS
This table stores information about Payment Methods, receipt attributes that you define and assign to Receipt Classes to account for receipts and their applications.
• For automatically created receipts, a Payment Method defines the rules for creating these receipts.
• For manually created receipts, a Payment Method defines a user-definable type for the receipt.
• Each Payment Method is associated with a set of bank accounts, which forms the set of bank accounts you can assign to your receipt.

Oracle Receivables Module Technical Details

Oracle Receivables Module Technical Details

Oracle Accounts Receivable uses the following tables for recording customer account information:

The major tables containing parties and customer accounts information in Oracle Receivables are grouped by business function.
• HZ_PARTIES
• HZ_CUST_ACCOUNTS
• HZ_PARTY_SITES
• HZ_CUST_ACCT_SITES_ALL
• HZ_CUST_SITE_USES_ALL
• HZ_LOCATIONS
• HZ_PARTY_RELATIONSHIPS
• HZ_ORGANIZATION_PROFILES
• HZ_CONTACT_POINTS
• HZ_CUST_ACCOUNT_ROLES
• HZ_PERSON_PROFILES
• HZ_ORG_CONTACTS

Transaction Tables
• RA_CUSTOMER_TRX_ALL
• RA_CUSTOMER_TRX_LINES_ALL
• RA_CUST_TRX_LINE_GL_DIST_ALL
• AR_PAYMENT_SCHEDULES_ALL
• AR_CASH_RECEIPTS_ALL
• AR_CASH_RECEIPT_HISTORY_ALL
• AR_RECEIVABLE_APPLICATIONS_ALL
• AR_ADJUSTMENTS_ALL

HZ_PARTIES
A party is an entity that can enter into a business relationship.
This table stores basic information about parties, which is true regardless of this relationship to the deploying company. Entities are modeled only once in HZ_PARTIES, regardless of how many roles they play. For example, if an organization is a customer, a distributor, and a partner, there is still only one record for them in HZ_PARTIES.

Parties can be one of four types:
Organization - Oracle Corporation
Person - Jane Doe
Group – Doc Household
Relationship - Jane Doe at Oracle Corporation

HZ_LOCATIONS
A location is a point in geographical space described by an address and/or geographical Indicators such as latitude or longitude.
• This table stores information about an address such as: street address and postal code.
• This table provides physical location information about parties (organizations and people) and customer accounts.
• Records in HZ_LOCATIONS can store delivery and postal code information about a location, store latitude and longitude, and can be used to determine the appropriate calculations and tax rates for sales tax and VAT calculations.

HZ_PARTY_SITES
This table links a party (HZ_PARTIES) and a location (HZ_LOCATIONS) and stores location-Specific party information such as a person’s mail stops at their work address.
• One party can point to one or more party sites.
• One location can point to one or more party site.
• Party sites serve as the intersection between parties and locations, allowing for a many-to-many relationship between the two.

HZ_RELATIONSHIPS
This table stores information about relationships between two entities, for example, one party and another party.
• The SUBJECT_ID and OBJECT_ID columns specify the relationship that exists between two parties. For example, if the party relationship type is “Parent Of,” then a holding company could be the “SUBJECT_ID” in the relationship while one of its subsidiaries could be the OBJECT_ID. Creating a party contact causes a party relationship to be created.
• A party can have different relationships with one or more other parties that can change over time.

HZ_ORGANIZATION_PROFILES
This table stores a variety of information about a party of type Organization.
• This table gets populated when a party of type ORGANIZATION is created.
• Historical data is also stored in this table.

HZ_PERSON_PROFILES
This table stores a variety of information about a party of type Person.
• For example, this table could contain the correct spelling and phonetic pronunciation of the person’s name.
• Some information in this table may also be entered into the HZ_PARTIES table.

HZ_ORG_CONTACTS
This table stores a variety of information about an organization contact.
• The records in this table provide information about a contact position such as job title, rank, and department.
• This table is not used to store information about a specific person or organization. For example, this table may include a record for the position of Vice President of Manufacturing that indicates that the contact is a senior executive, but it would not include the name of the person in that position.

HZ_CUST_ACCOUNTS
This table stores information about customer/financial relationships established between a Party and the deploying company.
• Because a party can have multiple customer accounts, this table may contain several records for a single party. For example, an individual person may establish a personal account, a family account, and a professional account for a consulting practice.

HZ_CUST_ACCT_SITES_ALL
This table stores information about customer/financial account sites information.
Stores information about customer sites. One customer account can have multiple sites.

HZ_CUST_SITE_USES_ALL
This table stores information about the business purposes assigned to a customer account site.
• A customer account site can have multiple purposes, but each record in this table only specifies one purpose for a customer account site. For example, a customer account site may be assigned as a ship-to site in one record and as a bill-to site in another record.

HZ_CUST_ACCOUNT_ROLES
This table stores information about a role or function that a party performs as related to a customer account. For example, Jane Doe might be the Legal Contact for a specific customer account of Corporation ABC. Note that account ownership such as financial responsibility for an account is determined by the single party ID that is stored directly on the HZ_CUST_ACCOUNTS table.

HZ_CONTACT_POINTS
This table stores information about how to communicate with parties or party sites using electronic media or methods such as Electronic Data Interchange (EDI), e-mail, telephone, telex, and the Internet.
• Each medium or method should be stored as a separate method in this table. For example, the attributes of a complete telephone number connection should be stored in a record, while EDI information should be stored in a different record.

RA_CUSTOMER_TRX_ALL
This table stores invoice, debit memo, commit-ment, chargeback, bills receivable, 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 and these are all distinguished by their transaction types stored in RA_CUST_ TRX_ TYPES_ALL.

RA_CUSTOMER_TRX_LINES_ALL
This table stores information about invoice, debit memo, credit memo, bills receivable, and commitment lines. It describes to the customer the charges that appear on these documents.

AR_PAYMENT_SCHEDULES_ALL
This table stores all transactions except adjust-ments and miscellaneous cash receipts. A miscellaneous cash receipt is one that is not connected to a customer.
• All customer-related activity is logged in this table.
• This table is updated when an activity occurs against an invoice, debit memo, chargeback, credit memo, on-account credit, bills receivable,
receipt, or commitments.

RA_CUST_TRX_TYPES_ALL
This table stores information about each transaction type for all classes of transactions, for example, invoices, commitments, and credit memos.
• Each row includes Auto Accounting information
as well as standard defaults for the resulting invoices. The primary key for this table is CUST_TRX_TYPE_ID.

AR_TRANSACTION_HISTORY_ALL
This table is a Bills Receivable-specific table containing the history of a transaction’s lifecycle.
• A new row is created each time there is activity on the transaction or the status of the transaction has changed.
• This table stores the header for the Receivables posting information.

AR_DISTRIBUTIONS_ALL
This table stores the accounting distributions for cash receipts, miscellaneous receipts, adjustments, credit memo applications, cash receipt applications, and bills receivable transactions.

AR_CASH_RECEIPTS_ALL
This table stores one record for each receipt entry.
• All cash receipts are logged in this table.
• Oracle Receivables creates records concurrently in the AR_CASH _RECEIPT_ HISTORY_ ALL, AR_PAYMENT_ SCHEDULES_ ALL, AR_DISTRI-BUTIONS_ALL, and AR_ RECEIVABLE_ APPLICA-TIONS_ALL tables for invoice-related receipts.
• For receipts that are not related to invoices, records are created in the AR_MISC_CASH_ DISTRIBUTIONS_ALL table instead of the AR_RECEIVABLE_APPLICATIONS_ ALL table.

AR_CASH_RECEIPT_HISTORY_ALL
This table stores all of the activity that is contained for the life cycle of a receipt.
• Each row represents one step.
• The status field for that row tells you which step the receipt has reached.
• Possible statuses are Approved, Confirmed, Remitted, Cleared, and Reversed.

AR_RECEIVABLE_APPLICATIONS_ALL
This table stores all accounting entries for cash and credit memo applications.
• Each row includes the amount applied, status, and accounting flex field information.

AR_MISC_CASH_DISTRIBUTIONS_ALL
This table stores all accounting entries for miscellaneous cash applications.
• Miscellaneous cash cannot be invoiced, such as stock revenue, interest income, and investment income.
• AR_CASH_RECEIPTS_ALL stores one record for each payment, and this table stores one record for each distribution of the receipt.

AR_RECEIPT_CLASSES
This table stores the different receipt classes that you define.
• Receipt classes determine whether the receipt[s] belonging to this class are created manually or automatically, and whether the receipts go through the different steps in a receipt’s life-cycle.

AR_RECEIPT_METHODS
This table stores information about Payment Methods, receipt attributes that you define and assign to Receipt Classes to account for receipts and their applications.
• For automatically created receipts, a Payment Method defines the rules for creating these receipts.
• For manually created receipts, a Payment Method defines a user-definable type for the receipt.
• Each Payment Method is associated with a set of bank accounts, which forms the set of bank accounts you can assign to your receipt.

AR_ADJUSTMENTS_ALL
This table stores information about the adjustment applied to the Invoices.

AR to GL Transfer (General Ledger Transfer Program)

AR to GL Transfer is a process which is concerned with the transfer to data from A to the GL Module.

The General Ledger Transfer Program is a standard spawned program provided by Oracle to transfer the data from AR to GL. The program picks up all the eligible records and transfers them to the gl_interface. All the transactions that have been accounted and are complete, and have not been transferred to GL will be picked up.

When submitting the program to transfer the records to GL form AR user can determine the transactions to be transferred by specifying a General Ledger Date Range when submitting the Interface Program. The user specifies a GL date that Receivables will use to select the transactions for posting.

When you run General Ledger Interface, Receivables transfers transaction data into the GL_INTERFACE table and generates the Posting Execution Report. This report provides the list of transactions make up the entries to the general ledger. 

Note: If you are using the Oracle Applications Multiple Reporting Currencies (MRC) feature, you must run the General Ledger Interface program for your primary set of books and each of your reporting set of books

The General Ledger Transfer Program consists of a number of Parameters some of which are discussed below:

Post in Summary:

When the user runs the General Ledger Transfer Program he has the option of choosing a parameter to perform a Summarized or Detailed Transfer

Choose a Posting Detail of Summary or Detail.

This controls how Receivables creates journal entries for your transactions in the interface table.

• If you select Detail(No), then the General Ledger Interface program creates at least one journal entry in the interface table for each transaction in your posting submission.

• If you select Summary(Yes), then the program creates one journal entry for each general ledger account.

Run Journal Import: If the user selects a value = ‘YES’ Oracle will submit the Journal Import process and create Journals for the transferred records. If the user selects the parameter to be ‘NO’ Oracle will not submit the Journal Import Program and the user will be able to see the data in the GL Interface.   

When Submitting the General Ledger Transfer Program Oracle will also check if all the submitted code combinations are valid or not. In case there are any code combinations which are inactive or invalid in GL the Program will report it to the user and process the remaining records.

How to Identify if a record is transferred to GL: Once a transaction has been transferred to General Ledger the user must be abe to identify that the transactions have been transferred to GL. In order to enable the user to find out these details Oracle has specified a field: POSTING_CONTROL_ID in the table : ra_cust_trx_line_gl_dist , If the value of the columns is -3 it means that the record has not been transferred to GL.

RA_CUST_TRX_LINE_GL_DIST_ALL: POSTING_CONTROL_ID NOT NULL Receivables posting batch identifier:

–1 means the record was posted by the old posting program (ARXGLP);

–2 means it was posted from old Release 8 Revenue Accounting;

–3 means it was not posted;

–4 means it was posted by the Release 9 RAPOST program.

How to identify a transaction which has been transferred to General Ledger?

The import puts rows into gl_import references REFERENCE21 to REFERENCE30

If the journal is imported in detail these are added to REFERENCE1 to REFERENCE10 in GL_JE_LINES. In summary mode the references map from there to GL_IMPORT_REFERENCES as there is no 1 to 1 relationship between the lines in gl and there source references.

Below is list from Oracle on which reference fields are populated with what values depending on the transaction category.

If you are customizing it should be note that these are subject to change without warning or notice.

USER_JE_CATEGORY_NAME = Adjustment

Reference21 : POSTING_CONTROL_ID
Reference22 : AR_ADJUSTMENTS.ADJUSTMENT_ID
Reference23 : AR_DISTRIBUTIONS.LINE_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : AR_ADJUSTMENTS.ADJUSTMENT_NUMBER
Reference26 : RA_CUST_TRX_TYPES.TYPE
Reference27 : RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID
Reference28 : 'ADJ'
Reference29 : 'ADJ_'||AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_ADJUSTMENTS'

USER_JE_CATEGORY_NAME = Sales Invoice

Reference21 : POSTING_CONTROL_ID
Reference22 : RA_CUSTOMER_TRX.CUSTOMER_TRX_ID
Reference23 : RA_CUST_TRX_LINE_GL_DIST.CUST_TRX_LINE_GL_DIST_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : HZ_CUST_ACCOUNTS.ACCOUNT_NUMBER
Reference26 : 'CUSTOMER'
Reference27 : RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID
Reference28 : 'INV'
Reference29 : 'INV_'||RA_CUST_TRX_LINE_GL_DIST.ACCOUNT_CLASS
Reference30 : 'RA_CUST_TRX_LINE_GL_DIST'

USER_JE_CATEGORY_NAME = Credit Memo

Reference21 : POSTING_CONTROL_ID
Reference22 : RA_CUSTOMER_TRX.CUSTOMER_TRX_ID
Reference23 : RA_CUST_TRX_LINE_GL_DIST.CUST_TRX_LINE_GL_DIST_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : HZ_CUST_ACCOUNTS.ACCOUNT_NUMBER
Reference26 : 'CUSTOMER'
Reference27 : RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID
Reference28 : 'CM'
Reference29 : 'CM_'||RA_CUST_TRX_LINE_GL_DIST.ACCOUNT_CLASS
Reference30 : 'RA_CUST_TRX_LINE_GL_DIST'

USER_JE_CATEGORY_NAME = Debit Memo

Reference21 : POSTING_CONTROL_ID
Reference22 : RA_CUSTOMER_TRX.CUSTOMER_TRX_ID
Reference23 : RA_CUST_TRX_LINE_GL_DIST.CUST_TRX_LINE_GL_DIST_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : HZ_CUST_ACCOUNTS.ACCOUNT_NUMBER
Reference26 : 'CUSTOMER'
Reference27 : RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID
Reference28 : 'DM'
Reference29 : 'DM_'||RA_CUST_TRX_LINE_GL_DIST.ACCOUNT_CLASS
Reference30 : 'RA_CUST_TRX_LINE_GL_DIST'

USER_JE_CATEGORY_NAME = Chargeback

Reference21 : POSTING_CONTROL_ID
Reference22 : RA_CUSTOMER_TRX.CUSTOMER_TRX_ID
Reference23 : RA_CUST_TRX_LINE_GL_DIST.CUST_TRX_LINE_GL_DIST_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : HZ_CUST_ACCOUNTS.ACCOUNT_NUMBER
Reference26 : 'CUSTOMER'
Reference27 : RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID
Reference28 : 'CB'
Reference29 : 'CB_'||RA_CUST_TRX_LINE_GL_DIST.ACCOUNT_CLASS
Reference30 : 'RA_CUST_TRX_LINE_GL_DIST'

USER_JE_CATEGORY_NAME = Receipts

Receipts Journal
Reference21 : POSTING_CONTROL_ID
Reference22 : AR_CASH_RECEIPTS.CASH_RECEIPT_ID||'C'
||AR_CASH_RECEIPT_HISTORY_ALL.CASH_RECEIPT_HISTORY_ID
Reference23 : AR_DISTRIBUTIONS.LINE_ID
Reference24 : AR_CASH_RECEIPTS.RECEIPT_NUMBER
Reference25 : Null
Reference26 : Null
Reference27 : AR_CASH_RECEIPTS.PAY_FROM_CUSTOMER
Reference28 : 'TRADE'
Reference29 : 'TRADE_'|| AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_CASH_RECEIPT_HISTORY'

Application Journal
Reference21 : POSTING_CONTROL_ID
Reference22 : AR_CASH_RECEIPTS_ALL.CASH_RECEIPT_ID||'C'
||AR_RECEIVABLE_APPLICATIONS_ALL.RECEIVABLE_APPLICATION_ID
Reference23 : AR_DISTRIBUTIONS.LINE_ID
Reference24 : AR_CASH_RECEIPTS.RECIPT_NUMBER
Reference25 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference26 : RA_CUST_TRX_TYPES.TYPE
Reference27 : AR_CASH_RECEIPTS.PAY_FROM_CUSTOMER
Reference28 : 'TRADE' or 'CCURR'
Reference29 : 'TRADE_' or 'CCURR_'|| AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_RECEIVABLE_APPLICATIONS'

USER_JE_CATEGORY_NAME = Misc Receipts

Header
Reference21 : POSTING_CONTROL_ID
Reference22 : AR_CASH_RECEIPTS.CASH_RECEIPT_ID
Reference23 : AR_DISTRIBUTIONS.LINE_ID
Reference24 : AR_CASH_RECEIPTS.RECEIPT_NUMBER
Reference25 : AR_CASH_RECEIPT_HISTORY.CASH_RECEIPT_HISTORY_ID
Reference26 : Null
Reference27 : AR_CASH_RECEIPTS.PAY_FROM_CUSTOMER
Reference28 : 'MISC'
Reference29 : 'MISC_' || AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_CASH_RECEIPT_HISTORY'

Distributions
Reference21 : POSTING_CONTROL_ID
Reference22 : AR_CASH_RECEIPTS_ALL.CASH_RECEIPT_ID
Reference23 : AR_DISTRIBUTIONS_ALL.LINE_ID
Reference24 : AR_CASH_RECEIPTS_ALL.RECEIPT_NUMBER
Reference25 : AR_MISC_CASH_DISTRIBUTIONS_ALL.MISC_CASH_DISTRIBUTION_ID
Reference26 : null
Reference27 : null
Reference28 : 'MISC'
Reference29 : 'MISC_'AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_MISC_CASH_DISTRIBUTIONS'

USER_JE_CATEGORY_NAME = Credit Memo Application

Reference21 : POSTING_CONTROL_ID
Reference22 : AR_RECEIVABLES_APPLICATIONS.RECEIVABLE_APPLICATION_ID
Reference23 : AR_DISTRIBUTIONS_ALL.LINE_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference26 : RA_CUST_TRX_TYPES.TYPE
Reference27 : RA_CUSTOMER_TRX.BILL_TO_CUSTOMER_ID
Reference28 : 'CMAPP'
Reference29 : 'CMAPP_'||AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_RECEIVABLE_APPLICATIONS'

USER_JE_CATEGORY_NAME = Bills Receivable

Reference21 : POSTING_CONTROL_ID
Reference22 : AR_TRANSACTION_HISTORY.TRANSACTION_HISTORY_ID
Reference23 : AR_DISTRIBUTIONS.LINE_ID
Reference24 : RA_CUSTOMER_TRX.TRX_NUMBER
Reference25 : AR_TRANSACTION_HISTORY.CUSTOMER_TRX_ID
Reference26 : RA_CUST_TRX_TYPES.TYPE
Reference27 : RA_CUSTOMER_TRX.DRAWEE_ID
Reference28 : 'BR'
Reference29 : 'BR_'||AR_DISTRIBUTIONS.SOURCE_TYPE
Reference30 : 'AR_TRANSACTION_HISTORY'

Upon running the Program the data will be interfaced to the GL Module in the table GL Interface where the user can identify any of the transferred record using the above references.

Even After transferring the data to General Ledger the AR module will still retain all the entries that have been transferred and can be used by for future reference

AR to GL transfer process is required for transferring all the AR data to GL so that financial reports can be prepared for all the expected revenue, receivables for the business.