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

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.1
Patch 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

  1.    Order on Hold
  2.     Inventory Period NOT open
  3.     No enough on-hand quantity
  4.     No enough quantity to reserve/transact
  5.     No on-hand quantity in required sub-inventory
  6.     The Lot from which items are selected is inactive/expired
  7.     Lot control Item Lot Divisible Option not enabled
  8.     Specified Lot is Disallowed Transaction (Applied on Material Status)
  9.     Item On-Hand to Disallowed Transaction (Applied on Material Status)
  10.     Wrong Item reservation (even inventory have enough quantity)
  11.     Inventory reserved for other sales orders
  12.     Inventory picked-up by other sales orders
  13.     Previously done return to stock not properly performed
  14.     Cycle Count Adjustments
  15.     Serial Control Item Serial number not allocated or not assigned 
  16.     Manually Backordered 
  17.     Move order is in pending state       

  *********************************************************************************

1. Check in Shipping Transaction Form, make sure the order still in “Ready to Release”.
2. There might be a lot of possibilities for this problem:
A) Order on hold
B) Do not have enough qty
C) Lot expired
D) Wrong reservation (even inventory have enough qty)
E) Inventory reserved for other orders.
F) Inventory picked up by other orders
G) Previously return to stock not done properly.
3. Case A,
Check if the order is on hold. Check the order type in Shipping Transaction Form → “Detail” →“Source”.
4. There is another way to check the order type. That is go to WMS Control Board → “Picking”.
5. Or go to OM Shipping View to see the order type.
6. Go to the correct “Sales Order View” instant accordingly by keying in the order# and order type.
7. Click on “Open Order” → “Action” → “Additional order info”.
8. Do the same for order level and line level.
9. Case B & C,
-Go to Material Workbench to check if the lot has expired or not having enough inventory for this order.
10. We can check if any lot is reserved for other order as well.
11. In Material Work Bench, go check for each lot in the physical locator by clicking on the “Attribute” button. (lot level reservation)
12. Alternatively, go to Shipping Transaction Form → OM Shipping View,
-or go to “Lot Number” (Ctrl + L), click on Attribute column to check the SO reservation of the lot.
13. Compare the SO info with the order that are having problem.
14. Case D,
-Go “Reserve Supply” form (Ctrl + L) to check if the order is wrongly reserved.
15. Case E,
-in the “Reserve Supply form, we can check if the qty is being picked up by other order as well. (order level reservation regardless of lot)
16. Also, can go to Material Workbench → Availability, to check for the available to reserve.
17. Case F,
-it might have high possibility the qty is taken up by order with different line, or other orders which have been auto launched.
18. If this is the case, must do backorder.
19. Go to Transact Move Order Form → tab “Pick Wave” → View/Update allocation → Lot/Serial.
20. Click on the checkbox for order which need to be backordered, then go to Tool → Back Order Line.
21. Case G,
-Ask the user if the order has done return to stock previously.
22. If yes, it might has high possibility that the return to stock not done properly.
23. Check the lot state, must be in “Resides in inventory”.
24. Check in Material Workbench to see if the lot is still packed with LPN or not.
25. Check also if the lot is in physical locator rather than logical locator.
1 Back Orders

  • The Oracle “term” backorder is astatus on the order line or delivery line indicating that you have tried to release an order for picking in your warehouse, but that the pick release was UNSUCCESSFUL because there was no available inventory.(Backorder can be partial or complete). The Oracle term backorder does NOT mean that you have open purchase orders for the out-of-stock item from your vendors.
  • The term  backorder is also used in business a little differently than in Oracle. The term “An item is on backorder” usually means that the item is not in stock, but the shipping company has already placed purchase orders from their suppliers to restock the item.
  • Backorder is when you do not fulfill the Sales Order, or if the inventory is out of stock for delivery to customer.

2 Drop Shipment

  • Drop shipment on the other hand is a method of order fulfillment where the organization taking the order does NOT maintain their own inventory for the drop-shipped product, but fulfill their orders through 3rd party vendors who directly ship to the end customer ordering the product.

For example,

  • A orders item x from B
  • B orders item x from C
  • C ships Item x to A.
  • B bills A for the order, C bills B for the order

A – Customer
B – Oracle Processing Company
C – Supplier

3 Back to Back Orders

In Back to Back Order the shipment process is also completed through OM as a standard order after the item is received against a PO.

What is the major difference between drop shipment and back to back order ?

  • In B2B the source will be internal but the item would be procured after the order is created or after the demand is made.
  • In Drop Ship the source will be external
  • In Drop Ship orders, material is directly shipped to the customer from the supplier. Thus, inventory is not affected. In this case, only logical receiving is done. But in the case of Back-to-Back orders, material is taken from inventory.
  • Drop Ship orders may have many Purchase Orders connected to them. In Back-to-Back orders one PO is tied to one Sales Order.
More on Drop Shipment & Back to Back Orders(Functional)
High Points for EBS Base Functionality for Drop Shipment
  • Drop shipment order processing in EBS is managed using workflow
  • Drop ship functionality is based on source type of an order line (Internal/External)
  • You can automate your PO/BPA release creation based on ASL/sourcing rule information
  • Drop ship process uses standard OM workflows.
  • You can use Sales order Purchase order discrepancy report to identify discrepancies between the OM and the PO
  • There is a links OM and PO to provide visibility through entire supply chain Flow.
The entire Drop shipment process flow can be best understood as figure below: 
drop shipment
Points for Implementation Considerations
  • Order line attribute: Source Type (need to be external). You can be defaulted from item or order type
    • Menu -> Responsibility Order Entry Super User/setup/Orders/Types
    • Setup an order type using the cycle defined in the previous step (a),an order number source, a valid standard value rule set.
  • Item attributes (OM and Purchasing)

You need to do the setup for these attributes:

-Purchased (PO) Enabled
-Purchasable (PO) Enabled
-Transactable (INV) Enabled
-Stockable (INV) Optional
-Reservable (INV) Optional
-Inventory Item (INV) Optional
-Customer Ordered (OE) Enabled
-Customer Orders Enabled (OE) Enabled
-Internal Ordered (OE) Disabled
-Internal Orders Enabled (OE) Disabled
-Shippable (OE) Optional
-OE Transactable (OE) Enabled

  • Setup requisition import parameters
  • You can also use grouping by Vendor
  • You can also set the multiple distributions set to No
  • ASL and/or Sourcing rule relationship need to be setup for Automatic PO creation
  • Oracle recommends using a logical organization for drop shipment. Exclude this organization for planning purposes. It can be worked around using non nettable Dropship subinventory

 Back to Back Order
As mention above this is ability to create specific supply orders for customer sales orders.
These are main features avaible in EBS

  • Designate specific items as B2B orderable
  • Enter sales order lines for these items, and have the supply automatically created via a requisition
  • Have the requisition converted into a Purchase Order or a release of a blanket Purchase Order
  • View the requisition number or PO number and its status from the Sales Order (using reservation details window)
  • Reserve the supply from the Requisition to the PO and finally to the Sales Order once the PO is received
  • Pick, ship and finally invoice the customer for the product.
  • Note to Buyer’s field in the requisition captures the Sales order information
  • Line status information shows the progress of the order
    PO Req Created
    PO Req Requested
    PO Created
    PO Received
  • If line is manually reserved it progresses to “Awaiting Shipping”
  • Changes and Cancellations on sales orders:
    • Reservation is changed
    • Notification sent to Buyer

Back to Back orders