Tuesday, July 21, 2009
Oracle Order Import sample code
OE_ORDER_PUB.Process_Order
DECLARE
l_api_version_number NUMBER := 1;
l_return_status VARCHAR2 (2000);
l_msg_count NUMBER;
l_msg_data VARCHAR2 (2000);
/*****************PARAMETERS****************************************************/
l_debug_level NUMBER := 1; -- OM DEBUG LEVEL (MAX 5)
l_org NUMBER := 5283; -- OPERATING UNIT
l_no_orders NUMBER := 1; -- NO OF ORDERS
l_user NUMBER := 28573; -- USER
l_resp NUMBER := 53073; -- RESPONSIBLILTY
l_appl NUMBER := 660; -- ORDER MANAGEMENT
/*****************INPUT VARIABLES FOR PROCESS_ORDER API*************************/
l_header_rec oe_order_pub.header_rec_type;
l_line_tbl oe_order_pub.line_tbl_type;
l_action_request_tbl oe_order_pub.request_tbl_type;
l_line_adj_tbl oe_order_pub.line_adj_tbl_type;
/*****************OUT VARIABLES FOR PROCESS_ORDER API***************************/
l_header_rec_out oe_order_pub.header_rec_type;
l_header_val_rec_out oe_order_pub.header_val_rec_type;
l_header_adj_tbl_out oe_order_pub.header_adj_tbl_type;
l_header_adj_val_tbl_out oe_order_pub.header_adj_val_tbl_type;
l_header_price_att_tbl_out oe_order_pub.header_price_att_tbl_type;
l_header_adj_att_tbl_out oe_order_pub.header_adj_att_tbl_type;
l_header_adj_assoc_tbl_out oe_order_pub.header_adj_assoc_tbl_type;
l_header_scredit_tbl_out oe_order_pub.header_scredit_tbl_type;
l_header_scredit_val_tbl_out oe_order_pub.header_scredit_val_tbl_type;
l_line_tbl_out oe_order_pub.line_tbl_type;
l_line_val_tbl_out oe_order_pub.line_val_tbl_type;
l_line_adj_tbl_out oe_order_pub.line_adj_tbl_type;
l_line_adj_val_tbl_out oe_order_pub.line_adj_val_tbl_type;
l_line_price_att_tbl_out oe_order_pub.line_price_att_tbl_type;
l_line_adj_att_tbl_out oe_order_pub.line_adj_att_tbl_type;
l_line_adj_assoc_tbl_out oe_order_pub.line_adj_assoc_tbl_type;
l_line_scredit_tbl_out oe_order_pub.line_scredit_tbl_type;
l_line_scredit_val_tbl_out oe_order_pub.line_scredit_val_tbl_type;
l_lot_serial_tbl_out oe_order_pub.lot_serial_tbl_type;
l_lot_serial_val_tbl_out oe_order_pub.lot_serial_val_tbl_type;
l_action_request_tbl_out oe_order_pub.request_tbl_type;
l_msg_index NUMBER;
l_data VARCHAR2 (2000);
l_loop_count NUMBER;
l_debug_file VARCHAR2 (200);
b_return_status VARCHAR2 (200);
b_msg_count NUMBER;
b_msg_data VARCHAR2 (2000);
BEGIN
DBMS_APPLICATION_INFO.set_client_info (l_org);
/*****************INITIALIZE DEBUG INFO*************************************/
IF (l_debug_level > 0)
THEN
l_debug_file := oe_debug_pub.set_debug_mode ('FILE');
oe_debug_pub.initialize;
oe_debug_pub.setdebuglevel (l_debug_level);
oe_msg_pub.initialize;
END IF;
/*****************INITIALIZE ENVIRONMENT*************************************/
fnd_global.apps_initialize (l_user, l_resp, l_appl);-- pass in user_id, responsibility_id, and application_id
/*****************INITIALIZE HEADER RECORD******************************/
l_header_rec := oe_order_pub.g_miss_header_rec;
/*****************POPULATE REQUIRED ATTRIBUTES **********************************/
l_header_rec.operation := oe_globals.g_opr_create;
l_header_rec.order_type_id := 2159; -- domestic return
l_header_rec.sold_to_org_id := 659018;
l_header_rec.ship_to_org_id := 635775;
l_header_rec.invoice_to_org_id := 635776;
l_header_rec.order_source_id := 9;
l_header_rec.booked_flag := 'N';
l_header_rec.price_list_id := 39825;
l_header_rec.pricing_date := SYSDATE;
l_header_rec.transactional_curr_code := 'USD';
l_header_rec.flow_status_code := 'ENTERED';
l_header_rec.cust_po_number := '1211314AFA';
/*****************INITIALIZE ACTION REQUEST RECORD*************************************/
l_action_request_tbl (1) := oe_order_pub.g_miss_request_rec;
/*****************INITIALIZE LINE RECORD********************************/
l_line_tbl (1) := oe_order_pub.g_miss_line_rec;
l_line_tbl (1).operation := oe_globals.g_opr_create;
l_line_tbl (1).inventory_item_id := 826543;
l_line_tbl (1).ordered_quantity := 1;
--l_line_tbl(1).unit_selling_price := 2000; -- The price is done using adjustments
--l_line_tbl(1).unit_list_price := 2000;
l_line_tbl (1).calculate_price_flag := 'Y';
l_line_tbl (1).return_reason_code := 'B2';
--l_line_tbl(1).line_number := 1;
l_line_adj_tbl (1) := oe_order_pub.g_miss_line_adj_rec;
l_line_adj_tbl (1).operation := oe_globals.g_opr_create;
l_line_adj_tbl (1).list_header_id := 148129;
l_line_adj_tbl (1).list_line_id := 651550;
l_line_adj_tbl (1).change_reason_code := 'MANUAL';
l_line_adj_tbl (1).change_reason_text := 'Manually applied adjustments';
l_line_adj_tbl (1).operand := 2000;
l_line_adj_tbl (1).pricing_phase_id := 2;
l_line_adj_tbl (1).updated_flag := 'Y';
l_line_adj_tbl (1).applied_flag := 'Y';
l_line_adj_tbl (1).line_index := 1;
FOR i IN 1 .. l_no_orders
LOOP
/*****************CALLTO PROCESS ORDER API*********************************/
oe_order_pub.process_order (
p_api_version_number => l_api_version_number
, p_header_rec => l_header_rec
, p_line_tbl => l_line_tbl
, p_action_request_tbl => l_action_request_tbl
, p_line_adj_tbl => l_line_adj_tbl
-- OUT variables
, x_header_rec => l_header_rec_out
, x_header_val_rec => l_header_val_rec_out
, x_header_adj_tbl => l_header_adj_tbl_out
, x_header_adj_val_tbl => l_header_adj_val_tbl_out
, x_header_price_att_tbl => l_header_price_att_tbl_out
, x_header_adj_att_tbl => l_header_adj_att_tbl_out
, x_header_adj_assoc_tbl => l_header_adj_assoc_tbl_out
, x_header_scredit_tbl => l_header_scredit_tbl_out
, x_header_scredit_val_tbl => l_header_scredit_val_tbl_out
, x_line_tbl => l_line_tbl_out
, x_line_val_tbl => l_line_val_tbl_out
, x_line_adj_tbl => l_line_adj_tbl_out
, x_line_adj_val_tbl => l_line_adj_val_tbl_out
, x_line_price_att_tbl => l_line_price_att_tbl_out
, x_line_adj_att_tbl => l_line_adj_att_tbl_out
, x_line_adj_assoc_tbl => l_line_adj_assoc_tbl_out
, x_line_scredit_tbl => l_line_scredit_tbl_out
, x_line_scredit_val_tbl => l_line_scredit_val_tbl_out
, x_lot_serial_tbl => l_lot_serial_tbl_out
, x_lot_serial_val_tbl => l_lot_serial_val_tbl_out
, x_action_request_tbl => l_action_request_tbl_out
, x_return_status => l_return_status
, x_msg_count => l_msg_count
, x_msg_data => l_msg_data
);
/*****************CHECK RETURN STATUS***********************************/
IF l_return_status = fnd_api.g_ret_sts_success
THEN
IF (l_debug_level > 0)
THEN
DBMS_OUTPUT.put_line ('success');
END IF;
COMMIT;
ELSE
IF (l_debug_level > 0)
THEN
DBMS_OUTPUT.put_line ('failure');
END IF;
ROLLBACK;
END IF;
END LOOP; -- END LOOP
/*****************DISPLAY RETURN STATUS FLAGS******************************/
IF (l_debug_level > 0)
THEN
DBMS_OUTPUT.put_line ('process ORDER ret status IS: '
|| l_return_status);
DBMS_OUTPUT.put_line ('process ORDER msg data IS: '
|| l_msg_data);
DBMS_OUTPUT.put_line ('process ORDER msg COUNT IS: '
|| l_msg_count);
DBMS_OUTPUT.put_line ('header.order_number IS: '
|| TO_CHAR (l_header_rec_out.order_number));
DBMS_OUTPUT.put_line ('adjustment.return_status IS: '
|| l_line_adj_tbl_out (1).return_status);
DBMS_OUTPUT.put_line ('header.header_id IS: '
|| l_header_rec_out.header_id);
DBMS_OUTPUT.put_line ('line.unit_selling_price IS: '
|| l_line_tbl_out (1).unit_selling_price);
END IF;
/*****************DISPLAY ERROR MSGS*************************************/
IF (l_debug_level > 0)
THEN
FOR i IN 1 .. l_msg_count
LOOP
oe_msg_pub.get (p_msg_index => i, p_encoded => fnd_api.g_false, p_data => l_data, p_msg_index_out => l_msg_index);
DBMS_OUTPUT.put_line ('message is: ' || l_data);
DBMS_OUTPUT.put_line ('message index is: ' || l_msg_index);
END LOOP;
END IF;
IF (l_debug_level > 0)
THEN
DBMS_OUTPUT.put_line ('Debug = ' || oe_debug_pub.g_debug);
DBMS_OUTPUT.put_line ('Debug Level = ' || TO_CHAR (oe_debug_pub.g_debug_level));
DBMS_OUTPUT.put_line ('Debug File = ' || oe_debug_pub.g_dir || '/' || oe_debug_pub.g_file);
DBMS_OUTPUT.put_line ('****************************************************');
oe_debug_pub.debug_off;
END IF;
END;
/
Order to Cash Flow
Data Flow for Order to Cash Modules
1. Order Entry
This is first stage, when the order is entered in the system, it creates a record in order headers and Order Lines table.
- Enter header details: Once you enter details on the order header and save it or move it to lines, record goes to one table oe_order_headers_all
- No record exists in any other table for this order till now
- Enter Line details for this order: Enter different item numbers, quantity and other details in line tab. When the record gets saved, it goes to one table. Order header details will be linked with line details by order HEADER_ID.
2. Order Booking
This is next stage, when Order is booked then the Flow status changed from Entered to Booked. At this stage, these below table get affected.
- oe_order_headers_alL
- oe_order_lines_all
- wsh_delivery_details
- wsh_delivery_assignments
*In shipping transaction form order status remains “Ready to Release”.
At the same time, Demand interface program runs in background and insert into inventory tables mtl_demand.
3. Reservation
This step is required for doing reservations SCHEDULE ORDER PROGRAM runs in the background and quantities are reserved. Once this program get successfully get completed, the mtl_demand and mtl_reservations table get updated.
4. Pick Release
Pick Release is the process of putting reservation on on-hand quantity available in the inventory and pick them for particular sales order.
Pick release can be done from ‘Release Sales Order’ form or ‘Pick release SRS’ program can be scheduled in background. In both of these cases all lines of the order gets pick released depending on the Picking rule used. If specific line/s needs to be pick release it can be done from ‘Shipping Transaction form. For this case Pick Release is done from ‘Release Sales Order’ form with Pick Confirm=NO.
Once pick release is done these are the tables get affected:
- If step 3 is not done then MTL_RESERVATIONS gets updated now.
- # wsh_new_deliveries
# wsh_delivery_assignments
# wsh_delivery_details
# mtl_txn_request_headers
# mtl_txn_request_lines
# mtl_material_transactions_temp
# mtl_serial_numbers_temp
# mtl_serial_numbers
*In shipping transaction form order status remains “Released to Warehouse” and all the material still remains in source sub-inventory. We need to do Move Order Transaction for this order. Till this no material transaction has been posted to MTL_MATERIAL_TRANSACTIONS
5. Pick Confirm/ Move Order Transaction
Items are transferred from source sub-inventory to staging Sub-inventory. Here material transaction occurs.
Order line status becomes ‘Picked’ on Sales Order and ‘Staged/Pick Confirmed’ on Shipping Transaction Form.
# mtl_material_transactions_temp
# oe_order_lines_all
# mtl_material_transactions
# mtl_transaction_accounts
# wsh_delivery_details
# wsh_delivery_assignments
# mtl_onhand_quantities
# mtl_serial_numbers_temp
# mtl_serial_numbers
6. Ship Confirm
Here ship confirm interface program runs in background. Data removed from wsh_new_deliveries.
The items on the delivery gets shipped to customer at this stage.
# wsh_delivery_details
# wsh_serial_numbers
# mtl_transaction_interface
# mtl_material_transactions
# mtl_transaction_accounts
# mtl_demand, mtl_reservations
# mtl_onhand_quantities
# mtl_serial_numbers_temp
# mtl_serial_numbers
7. Enter Invoice
After shipping the order the order lines gets eligible to get transferred to RA_INTERFACE_LINES_ALL. Workflow background engine picks those records and post it to RA_INTERFACE_LINES_ALL. This is also called Receivables interface, that mean information moved to accounting area for invoicing details. Invoicing workflow activity transfers shipped item information to Oracle Receivables. At the same time records also goes in the table RA_INTERFACE_SALESCREDITS_ALL which hold details of sales credit for the particular order.
ra_interface_lines_all (interface table into which the data is transferred from order management) Then Auto-invoice program imports data from this table which get affected into this stage are receivables base table. At the same time records goes in ra_customer_trx_all and ra_customer_trx_lines_all
8. Complete Line
In this stage order line level table get updated with Flow status and open flag.
oe_order_lines_all
9. Close Order
This is last step of Order Processing. In this stage only oe_order_lines_all table get updated. These are the table get affected in this step.
oe_order_lines_all, oe_order_headers_all
Auto Invoice Program in Oralce EBS 11i Receivables
Auto Invoice is a program that can be used to import and validate transaction data from other financial systems from which one can create invoices, debit memos, credit memos, and on-account credits. It rejects transactions with invalid information to insure the integrity of the data. This fits well with in Oracle ERP or to integrate with any third party application.
What is inside AutoInvoice
AutoInvoice is a program set consists of 3 main programs. Each program will have unique nature of work to do and they are called internally except Purge program whose execution is derived on the setup otherwise ready to execute stand alone.
Master (RAXMTR)
Import (RAXTRX)
Purge (RAXDEL)
1. Auto Invoice Master program RAXMTR
Selects and marks records in the interface tables to be processed based on the parameters the user entered and then calls the AutoInvoice Import program. Auto Invoice Master program has no report output.
•Gathers statistics, it means it gathers the stats on interface tables and set the stats on certain indices on interface tables
•Marks interface records for processing by marking request_id
•Submits multiple workers for Parallel Processing by creating instances for request.
2. Auto Invoice Import Program Validates the selected record and creates transaction if it passes validation. Any record that fails validation is left in the interface table with an error code. Depending on the setup, related records may be rejected as well. This program has an output file called Auto Invoice Execution report, which you can view by clicking the View Report button in the Requests window.Working of Auto invoice , Validates data, Inserts records, Deletes interface data Only when system option purge set to ‘Y’
3. Auto Invoice Purge Program Deletes records from the interface tables. If you set the Purge Interface Table system option to No in Define System Option window, Auto Invoice does not delete processed records from the interface tables after each run,and we must submit Auto Invoice Purge Program periodically to clean up the interface tables. This program only deletes transaction lines that have been successfully imported.
Deletes all rows where interface_status =‘P’
• Ra_interface_lines
• Ra_interface_distributions
• Ra_interface_salescredits
Oracle Receivable’s Auto Invoice program will be used to import and validate Invoices. A custom feeder program is required to transfer data from the Advantage extract files and populate the Auto Invoice interface tables (RA_INTERFACE_LINES_ALL and RA_INTERFACE_DISTRIBUTIONS_ALL).If there is need to run populate sales credit into RA_INTERFACE_SALESCREDITS_ALL table. When run, AutoInvoice produces the AutoInvoice Execution Report and the AutoInvoice Validation Report. Any entries which failed validation can be reviewed in Oracle Receivables’ AutoInvoice Interface Exceptions window. Depending on the error, changes may need to be made in Receivables, the feeder program or the imported records in the interface tables.
How Autoinvoice Execution works
Normally, Auto Invoice can be divided into three major phases, Pre-grouping: here the validates all of the line level data takes place, Grouping: groups lines based on the grouping rules and validates header level data, Transfer :validates information that exists in Receivables tables
What happen when AutoInvoice run?
Once the Auto invoice Program gets called, the following activity takes place is part of execution process. This can be analyzed by debug options.
Line, accounting, and sales credit information for each line populates 3 interface tables
Lines are ordered and grouped
Tax is calculated
GL date is determined
GL accounts are assigned using Auto Accounting
Tax, freight, commitments, and credit memos are linked to transaction lines
All transactions are batched
Validated lines are used to create the transaction
How Data is flowing?
Select, insert and update and delete take place on certain tables once it is logged out.
Selects
– RA_INTERFACE_LINES_ALL
– RA_INTERFACE_DISTRIBUTIONS_ALL
– RA_INTERFACE_SALESCREDITS_ALL
Updates/Insert
– RA_INTERFACE_ERRORS_ALL
– RA_CUSTOMER_TRX_ALL
– RA_CUSTOMER_TRX_LINES_ALL
– AR_PAYMENT_SCHEDULES_ALL
– AR_RECEIVABLE_APPLICATIONS_ALL
Inserts
– RA_INTERFACE_ERRORS_ALL
AutoInvoice Exception Handling
Records that fail validation are called ‘Exceptions’. Exceptions stay in Interface Tables which is RA_INTERFACE_ERRORS_ALL. Errors can be corrected in the Exception Handling window. Once corrections are made, Auto invoice must be resubmitted. Records that pass validation get transferred to Receivables tables
AutoInvoice Exception Handling Windows
-Interface Exception window displays exception messages associated with all invalid records
-Interface Lines window displays records that fail validation, provides an error message and can be used to correct the errors
-The Line Errors windows displays errors associated with a specific line, and can only be opened from Interface Lines window
-Interface Exceptions window displays Interface Id, Exception Type, Error Message and Invalid Value associated to the error
-Data cannot be edited in this window, but error can be viewed and corrected by clicking the Details button
-Error Message and Column name with invalid data are displayed in the Message column, and the invalid value that needs to be corrected is displayed in the Invalid Value column
Automate credit memo application against invoices in Oracle Receivables
This is a Generic Solution......
For instance if we get receivable invoices from multiple billing systems which includes invoices, credit memo's & debit memo's....Auto Invoice program will create invoices in AR. But sometimes thousand's of credit memo's are not applied against their invoices then we have two options to automate this business scenario.
we can't apply these many credit memo's against invoices manually....
( If the users had to perform this activity manually, they would query the Credit Memo in the Transactions form. Navigate to Menu > Actions > Applications and it would open up the Applications form. The users would then select the Invoice number in the ‘Apply-To’ field and save the application. This would apply the Credit Memo to the Invoice).
Scenario1:
1. Create a Zero amount Receipt using AR_RECEIPT_API_PUB.CREATE_CASH API
2. Apply the Receipt to the Credit Memo using AR_RECEIPT_API_PUB.APPLY API
3. Apply the Receipt to the Invoice using AR_RECEIPT_API_PUB.APPLY API
We considered the following validations in our program. These validations were specific to our Business requirements
1. The Credit Memo and the Invoice are both in the same currency.
2. There is no overaplication allowed
3. When the receipt is applied to the Invoice and the Credit Memo, the amount applied is the least of the Invoice balance amount or the Credit Memo balance amount.
Query to check if Invoice currency and CM currency is same or not
SELECT 'Y'
INTO l_flag
FROM ar_payment_schedules a , ar_payment_schedules b
WHERE a.customer_trx_id = l_inv_trx_id
AND b.customer_trx_id = l_cm_trx_id
AND a.invoice_currency_code = b.invoice_currency_code ;
l_inv_trx_id is the customer_trx_id of the invoice
l_cm_trx_id is the customer_trx_id of the credit memo
If the value of l_flag is NULL, then the invoice currency and the cm currency is not same.
Query to retrieve the balance amount of the transaction
-- INV BALANCE
SELECT acctd_amount_due_remaining
INTO l_inv_bal_amt
FROM ar_payment_schedules
Where customer_trx_id = l_inv_trx_id ;
-- CREDIT MEMO BALANCE
SELECT acctd_amount_due_remaining
INTO l_cm_bal_amt
FROM ar_payment_schedules
Where customer_trx_id = l_cm_trx_id ;
-- Amount applied should be the least of inv balance and cm balance
SELECT LEAST(l_inv_bal_amt, abs(l_cm_bal_amt))
INTO l_amount_applied
FROM DUAL;
Query to retrieve the customer_id of the transaction
SELECT customer_id
INTO l_customer_id
FROM ar_payment_schedules
WHERE customer_trx_id = l_inv_trx_id ;
At this point of time, we know the customer_trx_id , customer_id of the Invoice and the Credit Memo and we also know the amount to be applied. The next important thing is the receipt_method_id that uses for creating the receipt.
The validations for the receipt_method_id is as follows
1. It must be a valid receipt method ID in the AR_RECEIPT_METHOD table.
2. Receipt date must lie between the receipt method start date and end date (if not null).
3. 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’
4. 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.
STEP 1 > Create a ZERO amount Receipt
To create a ZERO amount receipt, use the AR_RECEIPT_API_PUB.CREATE_CASH API
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_receipt_number => 'TEST98',
p_amount => 0,
p_receipt_method_id => l_receipt_method_id,
p_customer_id => l_customer_id ,
p_cr_id => l_cr_id,
x_return_status => l_return_status,
x_msg_count => l_msg_count,
x_msg_data => l_msg_data);
In the above code,
| Parameter | Description |
| p_api_version | Always pass 1.0 for this parameter |
| p_init_msg_list | If set to FND_API.G_TRUE, the API does initialization of the message list. |
| p_commit | Used to specify if the API should commit. |
| p_receipt_number | The receipt number of the ZERO amount receipt |
| p_amount | The amount of the receipt. In our case, it is 0 |
| p_receipt_method_id | Identifies the payment method of the receipt. |
| p_customer_id | The customer_id of the Customer. |
| p_cr_id | This is an OUT parameter. It is the cash_receipt_id of the receipt created by the API |
| x_return_status | OUT parameter. Return Status of the API Call |
| x_msg_count | OUT parameter. Number of messages in the API message list |
| x_msg_data | OUT parameter. Message in encoded format if x_msg_count = 1 |
STEP 2 > Apply the Receipt to the Credit Memo
To apply the Receipt to the Credit Memo, use the AR_RECEIPT_API_PUB.APPLY API
AR_RECEIPT_API_PUB.APPLY(
p_api_version => 1.0,
p_init_msg_list => FND_API.G_TRUE,
p_commit => FND_API.G_TRUE,
p_receipt_number => 'TEST98',
p_customer_trx_id => l_cm_trx_id ,
p_amount_applied => -1 * (l_amount_applied) ,
x_return_status => l_return_status,
x_msg_count => l_msg_count,
x_msg_data => l_msg_data
);
In the above code,
| Parameter | Description |
| p_customer_trx_id | Customer_trx_id of the Credit Memo |
| p_amount_applied | The amount to which the receipt is to be applied. In our case we are applying the receipt to the Credit Memo and hence the amount_applied must be negative. We have calculated the l_amount_applied in one of the queries above |
STEP 3 > Apply the Receipt to the Invoice
To apply the Receipt to the Invoice, again use the AR_RECEIPT_API_PUB.APPLY API
AR_RECEIPT_API_PUB.APPLY(
p_api_version => 1.0,
p_init_msg_list => FND_API.G_TRUE,
p_commit => FND_API.G_TRUE,
p_receipt_number => 'TEST98',
p_customer_trx_id => l_inv_trx_id ,
p_amount_applied => l_amount_applied ,
x_return_status => l_return_status,
x_msg_count => l_msg_count,
x_msg_data => l_msg_data
);
In the above code,
| Parameter | Description |
| p_customer_trx_id | Customer_trx_id of the Invoice |
| p_amount_applied | The amount to which the receipt is to be applied. In our case we are applying the receipt to the Invoice and hence the amount_applied must be positive. We have calculated the l_amount_applied in one of the queries above |
Scenario1:
ARP_PROCESS_APPLICATION.CM_APPLICATION
Subscribe to:
Posts (Atom)