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
Oracle Depot Repair - Version 220.127.116.11 to 18.104.22.168 [Release 11.5 to 12.1] Information in this document applies to any platform.
Form:CSDREPLN.FMB - Repairs
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.
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:
data should be filtered based on the value for profile MO: Operating Unit
data for customer (accounts) is shown only when that customer (account) has an account site in the organization. If not, then that customer will not be shown in the lov.
for the Bill To and Ship To lov, the record will be there if there is a corresponding account site in the current organization.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!