, , , , ,

Accounts Receivables (AR) Tables Information

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.

Look these table also

AR_CASH_RECEIPTS_ALL
AR_MISC_CASH_DISTRIBUTIONS_ALL
AR_CASH_RECEIPTS
AR_MISC_CASH_DISTRIBUTIONS

/by
, , , , , ,

Receipt API in Oracle Receivables

Autolock box provides a functionality to create receipts using interface method. Recent versions of oracle applications, especially 11.5 onwards, Receipt API is getting used as they are flexible to the user’s need, and customization across all kinds of interfaces, loading.
Here are the receipt APIs used in 11i applications:
ar_receipt_api_pub.Create_cash
ar_receipt_api_pub.Apply
ar_receipt_api_pub.Unapply
ar_receipt_api_pub.Reverse
ar_receipt_api_pub.Apply_on_account
ar_receipt_api_pub.Unapply_on_account
ar_receipt_api_pub.Activity_application
ar_receipt_api_pub.Activity_unapplication
ar_receipt_api_pub.Apply_other_account
ar_receipt_api_pub.Unapply_other_account
ar_receipt_api_pub.create_misc
ar_receipt_api_pub.set_profile_for_testing
ar_receipt_api_pub.Apply_Open_Receipt
ar_receipt_api_pub.Unapply_Open_Receipt

Receipt On Account & Unapplied – SQL Query

A cash receipt is an applied receipt if it is associated with a customer number and an open invoice(s).
An unapplied receipt is a cash receipt that can be applied to a customer account if it is associated with a customer number but not associated with an invoice (that is, there is no invoice for the sale or the invoice number is unknown).
An on-account receipt (cash-in-advance) is:
* recorded to the customer account
* applied against the invoice when the invoice is generated
An unidentified receipt is from an unknown source.
An Application Advice Form is required for any receipt labeled as unidentified.
Here is the simple query to find the On-Account and UnApplied amount for a customer.
 

SELECT   NVL (SUM (DECODE (
                         ara.STATUS,
                         ‘ACC’, -amount_applied,
                         0
                       )), 0),
                   NVL (SUM (DECODE (
                         ara.STATUS,
                         ‘UNAPP’, -amount_applied,
                         0
                       )), 0)
              FROM ar_receivable_applications_all ara,
                   ar_cash_receipts_all acr
             WHERE ara.cash_receipt_id = acr.cash_receipt_id
               AND acr.customer_site_use_id = ‘&&site_use_id’
               AND ARA.STATUS IN ( ‘ACC’, ‘UNAPP’ )                
               AND ara.confirmed_flag IS NULL
          GROUP BY acr.currency_code,
                   acr.customer_site_use_id;


Receipt Status – Oracle Applications

A receipt can have one of the following statuses:
Approved: This receipt has been approved for automatic receipt creation. This status is only valid for automatic receipts.
Confirmed: The customer has approved the application of this receipt and their account balances have been updated within Receivables. This status is only valid for automatic receipts.
Remitted: This receipt has been remitted. This status is valid for both automatic and manually entered receipts.
Cleared: The payment of this receipt was transferred to your bank account and the bank statement has been reconciled within Receivables. This status is valid for both automatic and manually entered receipts.
Reversed: This receipt has been reversed. You can reverse a receipt when your customer stops payment on a receipt, if a receipt comes from an account with non-sufficient funds or if you want to re-enter and reapply it in Receivables. You can reverse cash receipts and miscellaneous transactions.

/by
, , , ,

What is auto lockbox in oracle applications?

Lockbox is a service provided by banks by which your company gets the customers payments directly to a lockbox interface tables and creates receipt for the payments deposited into your account. If you have an Auto Lockbox, the bank records the information that you request such as check number, check amount, numbers and amount for the invoices to be paid.
Oracle provides you with the tools to:
* Oracle interface tables for the data received from the bank
* Validate the data to see if it is accurate, complies with the controls provided
* Correct the data
* Apply the receipts to the customer’s open invoices.

A typical Lockbox transmission contains various different records, each with relevant data. Controls are provided at each level to ensure that the transmission was successful and to verify that the count and dollar amounts are consistent with what the bank indicated. These controls are at the transmission, Lockbox, batch and receipt levels. The records also contain information such as your bank account (by Lockbox) and the details for the receipts the bank received. The Lockbox may be used for checks, wires and any other receipts that you receive. You define what the data from the bank will look like and how you will use it.
Oracle Accounts Receivables Module provides the feature such that the customer can directly make the payment for their invoices in the Bank.The Bank would send a datafile in a  agreed transmission format which we we import in Receivables through AutoLockbox.After successful import the Receipts get created in the final stage.
This is a three step process
1) Validate the data file
2) Import the data file which created the Post Batch
3) Run the Post Batch  (ie Post Quick Cash) which would actually create the Receipts and applies against the Invoice on the Information provided in the data file.
Following are the main tables for auto lockbox

AR_PAYMENTS_INTERFACE_ALL
AR_INTERIM_CASH_RECEIPTS_ALL
AR_INTERIM_CASH_RCPT_LINES_ALL
AR_CASH_RECEIPTS_ALL
AR_CASH_RECEIPT_HISTORY_ALL
AR_DISTRIBUTIONS_ALL
AR_RECEIVABLE_APPLICATIONS_ALL
AR_PAYMENT_SCHEDULES_ALL

/by
, ,

Naming Conversion Table Name end with _ALL, _TL, _VL, _V, _F, _A, _B, _S, _AVN and its Meaning

  • _ALL : Table holds all the information about different operating units. Multi-Org environment. You can also set the client_info to specific operating unit to see the data specific to that operating unit only.
  • _TL : are tables corresponding to another table with the same name minus the _TL. These tables provide multiple language support. For each item in the table without _TL there can be many rows in the _TL table, but all with different values in the LANGUAGE column.
  • _B : these are the BASE tables.
    They are very important and the data is stored in the table with all validations.
    It is supposed that these table will always contain the perfect format data.
    If anything happens to the BASE table data, then it is a data corruption issue.
  • _F : these are date tracked tables, which occur in HR and Payroll. For these there are two date columns EFFECTIVE_START_DATE and EFFECTIVE_END_DATE which together with the PK identifies a row uniquely. The date intervals cannot overlap. Many think they are Secured data. Guess someone from Oracle confirms.
  • _V : tables are the views created on base tables
  • _VL : are views for multi language tables which combines the row of the base table with the corresponding row of the _TL table where the LANGUAGE = USERENV(‘LANG’).
  • _S : are sequences, used for finding new values for the primary key of a table.
  • _A : are Audit Shadow Tables
  • _AVN : and _ACN are Audit Shadow Views (when data was changed, and with what values
/by
, , ,

Troubleshooting Remit To Address in Oracle Receivables

Troubleshooting Details

1.  Setup and Usage of Remit-To Address in Oracle Receivables

Define remit-to addresses to let your customers know where to send payment for their invoices. Receivables uses the addresses that you define in the Remit To Addresses window to provide default remit-to information when you enter transactions.  Remit-To Addresses are also printed on invoices and optionally printed on Statements and Dunning Letters (Based upon the selections in the System Options window for AR). 

If you use AutoInvoice but have not defined a remit-to address that can be derived for a specific bill-to address,  AutoInvoice will reject all invoices for which it could not determine a remit-to address with the following message in the AutoInvoice Import Execution report:

Errors: 1) Cannot get remit to address

If you do not wish to set up a remit-to address for each location, you can set up one remit-to address with a default assignment. Receivables will then use this address for all locations or for any locations for which you do not have specific location assignments. This ensures that AutoInvoice will not reject invoices because it could not determine a remit-to address.

For more on setting up Remit-To Addresses in Oracle Receivables including step-by-step instructions and screenshots, refer to Note 1101666.1, How to Setup a Remit-To Address in Release 12 Oracle Receivables.
2. Troubleshooting Remit-To Address Issues and Errors on Transactions

    a. Error: Cannot Get Remit To Address

This is the most common error reported for Remit-To Addresses.  The steps below outline how you can determine what value should be used and also how to fix this problem.

Alternate Error Presentations:

WARNING: No default remit-to address found
WARNING: No default remit-to address (country) found

        i. Identify The Customer Bill-To Address

The Remit-to Address is derived based upon the customer Bill-To Address.  You should therefore begin troubleshooting by identifying the Bill To Address (State, Postal Code and Country)

        ii. Identify the Operating Unit on the Transaction

For a Manual Invoice, this can be found by looking at the list of values on the Transaction Source as shown below:

For AutoInvoice this can be found
Responsibility:  Receivables Manager
Navigation:  Control > AutoInvoice > Interface Lines

As shown above the Operating Unit field will be displayed.  If AutoInvoice failed with an error, query this form for any rows where the “Errors Exist” checkbox is checked.  This will return a listing of all rejected records.  Find the row that is showing a rejection reason of ‘Cannot Get Remit To Address’ and take note of the operating unit displayed for that row.

        iii. Check your Remit-To Address Setup

Note 1101666.1 explains in detail how to set up a Remit-To Address. 

Open the Remit-To Address form as shown below

Responsibility: Receivables Manager
Navigation:  Setup > Pring > Remit To Address

Find the row or rows associated to your Operating Unit and check to see if the bill to address is covered by the “Receitps From” definition.

The most common cause of an error in deriving a Remit-To address is in this “Receipts From” mapping.  A best practice to avoid problems is to set a default remit-to address for all countries where you transact.  This allows you to avoid errors during AutoInvoice and transaction entry.  In the example above we have defined this California address as the default for all Canadian bill-to addresses. 

Note: You can derive an alternate remit-to address with a more narrow definition.  For example, if you have a default for the United States with a New York address but then have a California address that is mapped to a specific Postal Code range, the system will use the California address ahead of the default address for any address in the from/to postal code range

In this example the Invoice had a Florida address but tthe Receipts From shows no combination that includes this Florida Address.   Assuming the Row above with the New York address also does not cover this Florida addess we can fix this defaulting issue by modifying the “Receipts From” to include the Bill  To address from the Invoice.

    b. Can I Use Additional Factors to Default the Remit-To Address?

At this time the only factors available to derive remit-to address are Geography and Operating Unit.

    c. Remit-To Address is not Defaulting

Refer to section 2a and verify that the address is properly mapped in the ‘Receipt From’ setup.

    d.  Unable to Delete Obsolete Remit-To Address

Receivables does not allow for a remit-to address to be deleted.  It is suggested that instead of deleting an address, the Receipt From values under the address simply be deleted.

    e. Remit-To Address Does Not Include All Address Segments

ARXSURMT.fmb , Remit to Address Form has Record group State based on the following query:

select state_code, description
from ar_remit_to_state
where country = :loc.country

Ar_remit_to_state is a view based on hz_locations table.  Data is populated in this table as customer addresses are created thus if you have not yet defined customers the LOV will not show the segments as available for selection. 

For more on configuring geographies in R12 refer to Note 554492.1 Setting Up Geography Hierarchy And Address Validation in Release 12

    f. Remit-To Bugs and Other Common Errors

Row
 Release Error String or Presentation  Cause Recommended Fix*
1
 12.0 When using Multiple Org’s in AR, if a transaction type is entered for operating unit “A” and then subsequently changed to a transaction type associated with operating unit “B”, the Remit-To address is not being updated to reflect this change. Bug 8642210 Remit To Address not properly refreshed Recommended Patch: 
12.0 Patch 9451008
12.1 Patch 9343518
Fixed File: ARXTWMAI.pld 12.0: 120.163.12000000.72
12.1: 120.180.12010000.46
2
 12.0
Re-display the remit-to address details, the following error message is displayed:
No HZ_CUST_ACCT_SITES was found for ID XXXX
 Bug 8522000 Recommended Patch:
12.0: patch 8331653
Fixed File: HzPuiAccountSiteAMImpl.java 120.22.12000000.3
12.1Patch 8522000
Fixed File: HzPuiAccountSiteAMImpl.java 120.25.12010000.2

Fix is included in 12.0.6 and 12.1.2 forward
3
 12.0 iSetup is creating duplicate Remit-To addresses instead of updating existing records Bug 6729003 Patch 6729003
See also Note 550257.1
4
 12.0 AR_DEPOSIT_API is not Defaulting the correct remit-to address via the Bill To Location Bug 9451008 Recommended Patch:  Patch 9451008
Fixed File: ARXDEPLB.pls
12.0.6
120.11.12000000.4
12.1
120.12.12010000.3
5
 12.0 
REP-0069: Internal error
REP-57054: In-process job terminated:Terminated with error:
REP-1419: MSG-00100: DEBUG: BeforeReport_Trigger +
 Remit-To Address was not defined and invoice print was attempted Define remit to address and/or default remit-to
6
 12.0
Query a transaction returns:
ORA-01422: exact fetch returns more than requested number of rows
ORA-06512: at "APPS.ARP_TRX_DEFAULTS_3", line 1463
Debug log showed:
selecting the default remit to address.
EXCEPTION: arp_trx_defaults_3.get_default_remit_to()
EXCEPTION: arp_trx_defaults_3.get_remit_to_address()
---------- Parameters for arp_trx_defaults_3.get_remit_to_address() ----------
p_match_state : NJ
p_match_country : US
p_match_postal_code : 07095
p_match_address_id :
p_match_site_use_id :
EXCEPTION: arp_trx_defaults_3.get_remit_to_default()
 Remit-To address not properly defined Review/correct setup.
7
 11.5 – 12.1
When printing a specific credit memo, it errors with the following:
MSG-43749: There is no remit to address defined for country US and state XX.
REP-1419: 'remit_to_control_idformula': PL/SQL program aborted.
 The zip code for this credit memo was not included in any of the existing remit-to ranges. Make sure a valid range is defined for the zip code on the transaction.

1. SetupPrintRemit-To Address –> Add a range for zip code 09136 (this problem zip code in this example) which is the zip for the credit memo.
2. A new line can be added, or you can alter the existing range for the that state to include the new zip code

Alternately you can set a default to be used to avoid this issue.
8
 11.5 – 12.1 
APP-FND-00676 The flexfield routine FDFGDC cannot read the default 
reference field specified for this descriptive flexfield
 Incorrect setup of descriptive flexfield for Customer Form Customer form and Remit-To address form share a common foundation.  Enhancement 3100593 was logged to split these apart.  Until this is fixed it is suggested that the DFF not be used on the Reference Field for the Address InformationDFF
9
 11.5 
Remit-to Address Does Not Exist In The List of Values.
State/Country combination already exists.
APP-AR-96282 Error: Invalid value for party_site_id
 Data Corruption of unknown origin (rare occurrence) Perform the following steps to resolve this issue: Verify Issue
1.) select address_ id
from ra_remit_tos_all
where country = ‘DEFAULT’
and state = ‘DEFAULT’;

2.) Select address1, address2, address3, city, state
from ra_addresses_all
where address_id = ‘&address_id_step1’;

If query 2 returns no rows then corruption exists.  Contact Support for assistance
10
 11.5
Entering new Remit-To address returns:
APP-AR-96282: Error: The following SQL error occurred:
ORA-29861: domain index is marked LAODING/FAILED/UNUSABLE
 Corrupt domain index 1. Rebuild the domain indexes associated to the form as described  in Note 165115.1

HZ_CUST_ACCT_SITES_ALL_T1
HZ_LOCATIONS_N15
HZ_STAGE_PARTY_SITES_T1
11
 11.5
Opening Remit-To Form from OM returns:
ORA-06550: line 1, column 7:
PLS-00905: object APPS.ARP_STAX_165 is invalid
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
ORA-06512: at "APPS.ARP_STAX", line 371
Item Validation Organization is not set. 1. Order Management Responsibility, N: Setup > System Parameters > Values
2. Select the ‘Generic Parameters’ Category.
3. Pick your org into ‘Item Validation Organization’
4. Save your work.
12
 11.5 
ORA-06550: line 1, column 7:
PLS-00905: object APPS.ARP_STAX_5749 is invalid
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
ORA-06512: at "APPS.ARP_STAX", line 371
FRM-40735: WHEN-NEW-FORM-INSTANCE trigger raised unhandled exception ORA-06550.
Tried to compile ARP_STAX_5749 package and got the following error message:
PLS-00920: parameter plsql_native_library_dir is not set.
 ARP_STAX package for this ORG_ID was in status invalid. set parameter plsql_native_library_dir and bounce the DB to take effect
13
 11.5 
APP-AR-96282 Error:Value for Party_site_number must be unique.
 The profile HZ: Generate Party Site Number is ‘No’

The remit-to-address does not have the field to enter the site number in that case must be generated

 This is ER: 3297103: ‘GENERATE PARTY SITE NUMBER’ IS ‘NO’,SITE NUMBER IS
COUNTED BY AUTO.

Workaround
———-

1. Go into the responsibility: System Administrator
2. Create a new responsibility to have the privileges to create the remit-to-address setup
3. Assign thjavascript:void(0)at responsibility to the user in charged to do that

or

1. Go into the responsibility: system Administrator
2. Navigate to Profile System
3. Put the profiles
HZ: Generate Contact Number
HZ: Generate Party Number
HZ: Generate Party Site Number
in Yes, for the User designated to create the remit-to-address or a Dummy user that will do that
14
 11.5 
Rep-1401: 'C_Remit_To_Concatenateformula' Ora-01403: No Data Found
 Remit-To Address and/or Default not defined Setup Remit-To Address as per Note 1101666.1
15
 12 Remit to address does not show in Dunning  Bug 9437627 Patch 10198415

Fixed File ardlgm.lpc 115.47.15104.38 (or higher).

*Note: that the patch recommendation is for the latest released version of the file and not necessarily the version that included the fix.  For example, if version 46 is the fixed file, the recommended patch may contain version 72 of the fixed file.  This fix will include the bug fix referenced here as well as any other bug fix released since the bug was resolved.

3. Troubleshooting Printing Related Remit-To Address Issues and Errors

    a. Remit-To Address is Not Printing, No Errors

By default the system should print the remit-to address from the invoice when printing statements, dunning and invoices.  If this does not print verify the following:

1) Check in Setup -> System -> System options, Alternate Region- Miscellaneous if the Print Remit to Address flag is checked
2) Verify that the invoice has a remit-to address defind

    b.  Remit-To address Errors with MSG-43749: There is no remit to address defined for country and state

This problem has been reported when the default value contains postal codes.  Removing the postal code has proven to remedy this symptom.

    c. Is it possible to highlight the Remit-To Address when printing?

In BPA, you can select “Bold” or “Regular” for the content item value.

Hence, you can duplicate the default template and make the remit to address as “Bold”.  It is even possible to make BOLD only a part of the Remit-To address.
Instead of using BPA content item ‘Remit To Address Formatted’, use each individual content item such as ‘Remit Address 1’, ‘Remit Address 2’ etc.

4.  Descriptive Flexfields on Remit-To Addresses

The top zone of the Remit-To Address form displays the “Address Information” DFF. This is by design. This allows one to see additional address info for the current address displayed. The “Receipts From” zone is where the “Remit Address Information” DFF is available

/by