My Oracle Support Banner

How to Make Customer, Account, Bill to and Ship to Addresses Filtered by Organization in Depot Repair (Doc ID 1348826.1)

Last updated on JULY 14, 2020

Applies to:

Oracle Depot Repair - Version 11.5.10.2 to 12.1.3.4 [Release 11.5 to 12.1]
Information in this document applies to any platform.
Form:CSDREPLN.FMB - Repairs


Purpose

Like most modules in the CRM area, Depot Repair does not restrict the user from entering or seeing information filtered by his operating unit (or MOAC in R12). When entering a new Service Request in the Repair Workbench, the user can select a customer and customer account linked to any organization. He can then select any address linked to that customer party for the 'Bill To' or 'Ship To' address on that Service Request. When any of those addresses do not exist yet in a Sales Order generated through that Service Request or Repair Order, the system will automatically create it as a customer account site in that operating unit (if profile option "Service: Action For Missing Account/Account Site in Charges" is set to "Allow the Automatic Creation of Account/Account Site").

The reason for this behaviour is that the accounts and addresses are selected from the 'party' level data that is commonly used in the Service modules. Party data is not 'org striped' as it is called, meaning all data is available in all organizations. Parties are linked to Accounts, which are org striped. When Depot Repair submits a Sales Order (e.g. for the logistics lines), that Sales Order is created in the Order Management module which is based on Account level information. So the Sales Order will need to have access the address as selected on the Service Request. If that does not exist for the organization in which the Sales Order is created, the system can configured to not stop the repair process, assuming the correct address was selected by the user, meaning there is a need for it in that organization. This is according to intended functionality in eBusiness Suite.

In a business model where users should not have access to other operating units, that may be undesirable for any reason.

The steps listed in this document will guide the reader to limit the options for the user so he can select records from his own organization only, so no new account sites will be created. This is done through personalizations on the Repair Workbench.

Scope

Though the steps are explained in detail, this should be implemented by a user with experience with forms personalizations. He/she should be able to understand what is behind the sql statements used to alter the list of values (lov) contents, so that a different or additional requirement (e.g. validation against a different organization than MO: Operating Unit) can be implemented as well, hence taking the steps in this document as an example.

The assumptions are:

Details

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Purpose
Scope
Details
 1. Apply Patch  14780706
(Patch 6080802
  - 1OFF:11i.ATG_PF.H.RUP6:FNDCUSTM CONTEXT SETTING NOT WORKING PROPERLY contained the original fix, but this patch has been superseded).
 2. Replace the lov on customer name by a new statement that filters on org id
 3. Replace the lov for account number
 4. Validate if the (defaulted) bill to address exists in the current organization
 5. For the ship to address, there is a similar personalization to validate:
 6. Replace the lov for Bill To address
 7. Replace the lov for Ship To Address
References

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.