Script for Receipt creation and receipt application using

API in APPS

Ar_receipt_api_pub.Create_cash
This routine is called to create cash receipts for the payment received in the form of a check or cash.
This routine does not call Oracle Payments directly.
This API routine has 4 output and 44 input parameters in total.

TYPE attribute_rec_type IS RECORD

TYPE global_attribute_rec_type IS RECORD

p_currency_code ………fnd_currencies
p_exchange_rate_type ……………gl_daily_conversion_types
p_customer_id ……………….Customer exists and has prospect code ='CUSTOMER'
…….Customer has a profile defined at the customer level
p_location ………………..The Bill_To location for the customer
p_remittance_bank_account_id ……….user's bank account for depositing the receipt
p_receipt_method_id …………………Identifies the receipt method of the receipt
p_doc_sequence_value ………………Value assigned to document receipt.

Validating Receipt Method ID

• It must be a valid receipt method ID in the AR_RECEIPT_METHOD table.
• Receipt date must lie between the receipt method start date and end date (if not null).
• The creation method code for the receipt class of this particular receipt method ID should
be 'AUTOMATIC,' the remit flag ='Y,' and the confirm flag = 'N' or 'MANUAL.'
• At least one remittance bank account associated with this receipt method ID must have either the multi-
currency flag set to 'Y' or the same currency as the receipt currency. In addition, this should have a bank
account type = 'INTERNAL' and its inactive date (if specified) greater than the receipt_date.

Validating Remittance Bank Account ID

• Be a valid remittance bank account ID for the current receipt method.
• Have the multi-currency flag set to 'Y' or the same currency as the receipt currency. In addition, this
should have a bank account type = 'INTERNAL' and its inactive date (if specified) greater than the
receipt_date.

Validating for Duplicate Receipt

If the combination of the receipt_date, receipt_number, and amount on this receipt matches any existing
receipts which have not been reversed, then the error message AR_RW_CASH_DUPLICATE_RECEIPT is
raised.
Ar_receipt_api_pub.Create_cash(
p_api_version => 1.0,
p_init_msg_list => FND_API.G_TRUE,
p_receipt_number => 'aj_test_api_1',
p_amount => 1000,
p_receipt_method_id => 1001,
p_customer_name => 'Computer Service and Rentals',
p_cr_id => l_cr_id,
x_return_status => l_return_status,
x_msg_count => l_msg_count,
x_msg_data => l_msg_data);
Ar_receipt_api_pub.Apply
Call this routine to apply the cash receipts of a customer (identified cash receipt) to a debit item.
This API routine has 3 output and 34 input parameters

p_cr_id ………….The cash_receipt_id of the receipt which needs to be applied to a given debit item
p_customer_trx_id ………..
p_trx_number …. The trx_number of the debit item to which the receipt is to be applied

Validation p_cr_id
Type must be 'CASH'
Status must not be Reversed or Approved
The receipt must not be Unidentified

Customer Trx ID
• If the Show Closed Invoices flag is set to 'Y,' then the current transaction + installment can have a
payment schedule status of Closed ('CL'). Otherwise, the payment schedule status must be Open ('OP').
• If the Allow Payment of Unrelated Transactions system option = 'Y,' then the current transaction can be
for a customer who is not related to the customer on the receipt. Otherwise, the transaction must be for
the same or related customer on the receipt.
• The transaction must be an Invoice, Credit Memo, Debit Memo, Deposit, or Chargeback.
Note: This transaction can be in a currency that is different from the receipt currency.

Amount Applied
• The amount applied cannot be nu
• The amount applied must not be greater than the line amount for the given customer_trx_line ID (if
specified).
• Depending on the creation sign, natural application flag, allow overapplication flag, and the amount
due remaining of the specified transaction installment, the amount applied is validated to check for
overapplication and natural application.
• For a cross currency application, the following equation should always be valid:
amount applied * trans to receipt rate = amount applied from

Amount Applied From

• During a cross-currency receipt application, the amount applied from cannot be null.
• The amount applied from cannot be greater than the unapplied amount available on the receipt.
• If the transaction currency and the receipt currency are the same, then the amount applied from must
always be null.
• As mentioned previously for a cross currency application, the following equation must always be valid:
amount applied * trans to receipt rate = amount applied from

Trans to Receipt Rate

• For a cross currency application, the trans to receipt rate should have a positive value.
• If the transaction currency and the receipt currency are the same, then the rate should not have any
value specified.
• For a cross currency application, the following equation should always be valid:
amount applied * trans to receipt rate = amount applied from

Discount
• If the amount due original on the transaction (debit item) is negative, then discount = 0 or null.
• If amount applied > 0, then the discount cannot be negative.
• If partial discount flag = 'N' and the transaction has not been completely paid off by the receipt
application, then the discount = 0 or null.
• The discount must not be greater than the maximum discount allowed on the transaction, which is
internally calculated in the API by the discounts routine.

Application Ref Num

If p_application_ref_type is 'CLAIM', then the application reference number can be populated with a
valid deduction number from Trade Management. This deduction/overpayment must be in the same
currency as the debit item being applied to.

Secondary Application Ref ID

If p_application_ref_type is 'CLAIM', then the secondary application reference ID can be populated with
a valid claim ID from Trade Management. This deduction/overpayment must be in the same currency as
the debit item being applied to. If both the application reference number and the secondary application
reference ID are left null, and p_application_ref_type is 'CLAIM', then a new claim will be created in
Trade Management.

Example:
p_api_version => 1.0 ,p_trx_number => 'aj_test_trx_1' ,p_receipt_number => 'aj_test_cr_2'

Program to create and apply Cash Receipt Using API

CREATE OR REPLACE PROCEDURE APPS.XX_CREATE_CASH_RECEIPT_APPLY(errbuf out

NOCOPY varchar2,
retcode out NOCOPY
varchar2)
IS
L_RETURN_STATUS VARCHAR2(240);
L_MSG_COUNT NUMBER;
L_MSG_DATA VARCHAR2(240);
L_CASH_RECEIPT_ID NUMBER;
v_customer_number VARCHAR2(240);
v_cust_name VARCHAR(240);
v_amount NUMBER;
v_receipt_number NUMBER;

CURSOR C1
IS
SELECT * FROM XX_AR_RECEIPTS_GMC;

BEGIN

BEGIN
MO_GLOBAL.SET_POLICY_CONTEXT('S',150);
END;

FOR I IN C1 LOOP

BEGIN
 v_cust_name := I.customer_name; --
substr(I.CUSTOMER_NAME,1,length(I.CUSTOMER_NAME)-1);

SELECT DISTINCT ARC.CUSTOMER_NUMBER

INTO v_customer_number
FROM AR_CUSTOMERS ARC
,HZ_CUST_ACCOUNTS_ALL HCA
,HZ_CUST_ACCT_SITES_ALL HCAS
WHERE HCA.CUST_ACCOUNT_ID = HCAS.CUST_ACCOUNT_ID
AND HCA.CUST_ACCOUNT_ID = ARC.CUSTOMER_ID
AND HCAS.ORG_ID = 150
AND LTRIM(RTRIM(UPPER(ARC.CUSTOMER_NAME))) =
LTRIM(RTRIM(UPPER(v_cust_name)));

DBMS_OUTPUT.PUT_LINE ('Customer Id -
'||v_customer_number);

EXCEPTION
WHEN NO_DATA_FOUNd THEN
DBMS_OUTPUT.PUT_LINE(I.CUSTOMER_NAME||' Customer
Error: '||SUBSTR(SQLERRM,1,150));
END;

v_amount:= to_number(substr(I.AMOUNT,1,length(I.AMOUNT)-
1));
--v_amount := to_number(I.AMOUNT);
v_receipt_number := to_number(I.RECEIPT_NUMBER);

AR_RECEIPT_API_PUB.create_cash
( p_api_version => '1.0',
p_init_msg_list => FND_API.G_TRUE,
p_commit => FND_API.G_TRUE,
p_validation_level =>
FND_API.G_VALID_LEVEL_FULL,
x_return_status => l_return_status,
x_msg_count => l_msg_count,
x_msg_data => l_msg_data,
p_currency_code => 'AED',
p_amount => v_amount,
p_receipt_number => v_receipt_number,
p_receipt_date => sysdate,
p_gl_date => to_date('31-dec-2008'),
p_customer_number => v_customer_number,
p_org_id => 150,
p_receipt_method_id => '2007',
p_cr_id => l_cash_receipt_id);

/* AR_RECEIPT_API_PUB.create_and_apply
( p_api_version => 1.0,
p_init_msg_list => FND_API.G_TRUE,
p_commit => FND_API.G_TRUE,
p_validation_level =>
FND_API.G_VALID_LEVEL_FULL,
x_return_status => l_return_status,
 x_msg_count => l_msg_count,
x_msg_data => l_msg_data,
p_amount => v_amount,
p_receipt_number => v_receipt_number,
p_receipt_date => sysdate,
p_gl_date => to_date('31-dec-
2008'),
p_customer_number => v_customer_number,
p_location => 'Abu Dhabi',
p_receipt_method_id => '2007',
p_trx_number => '500001',
p_cr_id => l_cash_receipt_id
);
*/

END LOOP;

DBMS_OUTPUT.PUT_LINE('Cash Receipt Created & Applied'||'-

'||l_cash_receipt_id||'- Comments : '||l_msg_data||l_return_status);

COMMIT;

EXCEPTION
WHEN OTHERS THEN

DBMS_OUTPUT.PUT_LINE(SUBSTR(SQLERRM,1,150)||'-'||l_msg_data);

END;