Introduction to Oracle Depot Repair

This chapter discusses the key concepts, features, and process flows of Oracle Depot Repair.

This chapter covers the following topics:

• What is Oracle Depot Repair?
• Oracle Depot Repair Key Features
• Business Process Flows
• Setup Parameters
• Integration with Other Oracle Modules

What is Oracle Depot Repair?

Oracle Depot Repair is part of the Oracle E-Business Suite and offers an enterprise-wide solution for managing depot business processes. It targets the service business market from simple, quick services like routine maintenance to complex overhauls. Oracle Depot Repair integrates with other Oracle E-Business Suite modules to provide an integrated comprehensive solution for the service business sector.

The Depot Repair process includes the return of broken and serviceable items, their diagnoses and job estimates, customer approvals and services management, and subsequent return of items to inventory, part harvesting, recycling or scrap. The collection of charges for materials, labor, and expenses for the services is used to invoice the customer.

Depot Repair enables a business to process customer products and parts as well as internally owned items and parts. Parts can be returned from end consumers, field service technicians, partners, distributors, warehouses or other sources.

Customers expect quick and seamless service processing. Oracle Depot Repair provides end-to-end service management functionality for depots that are committed to delivering a total service solution.

Oracle Depot Repair Key Features

The major features of Oracle Depot Repair include:

• Customer Management
• Service Request Management
• Service Order Management
• Service Execution

Customer Management

Oracle Depot Repair provides a number of tools that enable a service organization to better know, understand and serve their customers. Depot supports customer interactions via phone, email, fax, walk in, store front, mobile device and web portal. Depot also provides tools to interact with customers other than end consumer, such as resellers, dealers, distributors, and partners.

Oracle Depot Repair also supports scenarios in which customers walk in at depots for service needs.

Oracle Depot Repair provides service organizations with the right tools and knowledge for responding effectively to the service issues that customers have.

Key customer management features include:

Oracle Depot Repair Workbench

The Service Orders window in Oracle Depot Repair provides the service agent instant access to information about the customer and enables the agent to effectively address the needs of the customer. The customer Profile menu option enables service agents to view the number of open Service Orders, open Service Requests, active contracts, and other details for a selected customer. In the Find Service Requests window, service agents can query for Service Orders to see the Service Order statuses, jobs, and tasks.

Relationship Management

Oracle Depot Repair lets service agents capture the contact's relationship with others in the concerned organization, or other organizations, enabling service agents to engage knowledgeably with customers and other service agents.

Customer Data Store

Oracle Depot Repair enables service agencies to maintain a comprehensive database of all customer interactions with the agency. Oracle Depot Repair maintains detailed service history to trace the origin of a service issue and the follow up actions that solved it.

Service Request Management

Oracle Depot Repair enables service agencies to offer customers the convenience of accessing service through telephone, over the internet or over the counter. Key Service Request management processes include:

• Create and Update Service Requests
• Search Knowledge Management Database

Create and Update Service Requests

Oracle Depot Repair provides tools to create service requests in multiple ways. They can be manually created using the Depot Workbench, created in bulk using the Mass Create Service Order screen, created online using the Returns Portal or created automatically using the Bulk Receiving module. No matter how a service request is created, it can still be viewed and transacted in Oracle Teleservice, iSupport, HTML Service, the Returns Portal and Depot Workbench.

Search Knowledge Management Database

Oracle Depot Repair makes available a database of solutions, which the service agents can search with a view to solving the problem while the customer interaction is in progress. The Oracle Knowledge Management database can also provide information, such as guides, policies, procedures, and FAQs.

Where the problem affecting the current Service Order item is matched up with the solution in the Oracle Knowledge Management database of a similar problem, Oracle Knowledge Management can assist in the Service Order processing by defaulting charge lines for WIP and Task estimates and Bills and Routings for WIP Service Jobs.

Service Order Management

Oracle Depot Repair provides Service Types that enable service providers to be more efficient in managing the service through process automation. Service Types help to classify the Service Order and determine the service management processes and logistics to fulfill the service process.

Oracle Depot Repair supports the following Service Types:

Repair and Return

Use this Service Type when a customer returns the broken or damaged item to the depot for service. After completion of the service, the serviced item is returned to the customer. This Service Type requires:

• A return materials authorization (RMA), or Return line, to receive the customer's broken or damaged item.
• A Sales Order, or Ship line, to ship the serviced item and invoice the customer.

Loaner, Repair and Return

This Service Type combines two Service Types, the Repair and Return, with the Loaner. The loaner concept indicates that depot sends the customer the loaner before the receipt of the customer's broken or damaged item. To track the shipping and return of both the loaner and the broken or damaged item, the system creates four logistics lines, one Sales Order to ship the loaner to the customer, one RMA Order for the return of the customer product into the depot, one Sales Order to ship the serviced item back to the customer and one RMA Order for the return of the loaner item back to the depot.

Exchange

This Service Type represents a scenario when the depot sends an exchange item to the customer after receiving the customer's broken or damaged item. The Exchange Service Type assumes that the serviced item does not return to the customer.

Advance Exchange

This Service Type is the same as the Exchange Service Type except that the depot can send the item to the customer before the service organization receives the customer's broken item.

Loaner

Use this Service Type when the depot sends an item to the customer solely for the purpose of temporarily replacing the damaged product. This Service Type requires a Sales Order to ship the loaner item to the customer and to create an invoice, and an RMA order to track the return of the loaner item. A deposit and return due date may be a requirement. In a loaner scenario, the depot generally does not provide any service to the customer.

Replacement

A Replacement Service Type refers to a scenario when the depot sends an item to the customer without expecting a return. In this scenario, the service provider sends the customer an item to replace the customer's item. The service organization can:

• Link the replacement item to the original item in the Installed Base.
• Change the status of the replaced item to indicate that it is out of service and that the new item has replaced it.

Standard

Use this Service Type when logistics lines are not created automatically at time of Service Order creation. This Service Type is flexible however, and allows the manual creation of RMAs and Sales Orders.

Refurbishment

A Service Order and its associated Service Request can be created in Spares Management of Oracle Field Service as a result of a demand for refurbishment or replenishment. The Service Order has a Service Type of Refurbishment, and has two transaction lines, Move In and Move Out.

The Move In line tracks the shipment of defective items from its original location into the servicing depot. The Move Out line processes the shipment of the serviced items back to the original location.

The processing of Move In and Move Out lines leverages existing Internal Order and Internal Requisition functionality. From the depot's perspective, defective items are received via the Internal Requisition, and usable/serviced items are shipped via the Internal Order.

Service Resolution Management

Oracle Depot Repair improves operational efficiency by providing the following key service resolution management features:

• Job search functionality.
• Process automation based on Service Type, such as automatic creation of logistic lines.
• Estimate creation and approval.
• Leveraging of the depot knowledge base throughout service processing.
• Job creation and release to shop floor.
• Flexible options for receiving items and shipping items.
• Invoicing of final charges.

Service Execution

Use either of the following service modes to execute services:

• WIP (Work In Process): Recommended for use when a business desires costing and parts planning. The WIP mode leverages the costing of items through Oracle Costing. WIP mode is the recommended default execution mode as it allows a business to make use of the Technician Portal, Costing, Demand Planning and Service Parts Planning or Supplier Warranty Management.
• Task: Recommended for use when the services require minimal steps that do not necessarily require a series of sequential steps. In contrast to WIP mode, Task mode does not integrate with Oracle Costing, the Technician Workbench, Costing, Demand Planning, Service Parts Planning or Supplier Warranty Management.

You implement and manage either of these service modes on separate tabs in the Oracle Depot Repair Workbench.

During implementation, you associate the WIP or Task mode with Service Types. Though a service organization can have different Service Types associated with different service modes, it is recommended that a service organization select only one service mode for all Service Types to ensure consistent costing and material planning.

Business Process Flows

Oracle Depot Repair supports the following business process flows:

• Logistics and Maintenance with Call Center Facility
• Logistics and Maintenance without Call Center Facility
• Internal Party Service Operations

You can use either Oracle Work In Process (WIP) or the Task Manager (in Oracle Common Application Components) to manage the service process. Based on your choice, the Service Type for a given Service Order determines which service management process to use.

Logistics and Maintenance with Call Center Facility

This business flow starts with a Service Request, where the call center service agent records a problem. If the service agent cannot resolve the problem using information in Oracle Knowledge Management, the service agent refers the Service Request to a depot service agent. The depot agent can then create a Service Order and an estimate (if required) and seek approval from the customer for further processing.

Depending on the Service Type, the depot service agent completes the different RMA and Sales Order lines to assist the completion of the service process. The service mode (associated to the Service Type) determines whether to use Oracle WIP or JTF Tasks to manage the job. After the service completion, the depot returns the serviced item to the customer. The system captures the material, labor, and expenses that the service needed as charges and transfers that information to Oracle Order Management for invoicing.

Logistics and Maintenance without Call Center Facility

This process is similar to the Call Center, Logistics, and Maintenance business process except that there is no call center.

Businesses that do not incorporate a call center facility, or those that integrate their call center into the depot, can use this process.

Internal Party Service Operations

You can refurbish items and parts that your organization already owns. Oracle Depot Repair lets you process internal service operations in such cases. The customer is an internal party in the corresponding Service Request. RMAs and Sales Orders are not required to process service operations and items and parts can be moved internally from warehouse to warehouse. This is under the assumption that items already exist in a subinventory within the organization letting you create jobs.

Setup Parameters

Depot Repair provides a setup screen that allows administrators to select application configuration options using simple Attribute-Operator-Value (A-O-V) rules. The new setup parameters allow administrators to default values and system behavior based on A-O-V rules and not relying on fixed profile values. Explanatory text is available on the page to make setup and maintenance easier. Dependencies between options are made explicit and clear to understand.

As the Depot Repair application relies on integrations with many other CRM and ERP applications, the setup parameters allow the administrator to setup profiles for the Depot application as well as other applications that are required for successful depot business flows.

Depot Repair provides the ability to automate the disposition of products and the assignment of services to specific resources based on the following two rules engines:

Defaulting Rules Engine

Service queue, SO owner, priority and other service order values default at the time of service order creation based on customer defined rules. The fields that default are: Inventory Organization, RMA Receiving Organization, RMA Receiving, Subinventory, Service organization, SO Owner, Service Priority, Service Type, Ship from Organization, Ship from Subinventory, Vendor Account, etc. Rules are based on service item, service location, customer, contract, etc.

Setting up Defaulting Rules

To set up defaulting rules

1. Navigate to the Defaulting Rules page. This page displays the summary of existing defaulting rules.
2. To set up a new defaulting rule, click Add Another Row button.
3. Enter the values in the following fields:
   • Precedence: Each rule is assigned a Precedence. Rules are evaluated in the order of precedence - the smaller the number, the higher is the precedence. The Precedence field accepts both positive and negative values.
   • Name: Name of the defaulting rule
   • Description: Description of the defaulting rule
   • Entity: Defaults from the system
   • Defaulted Attribute: The value of this field defaults when a defaulting rule is applied to a service order. The list of values for Defaulted Attribute are:
     • Inventory Organization
     • RMA Receiving Organization
     • RMA Receiving Sub-Inventory
     • Service Organization
     • SO Owner
     • Service Priority
     • Service Type
     • Ship From Organization
     • Ship From Sub-Inventory
     • Vendor Account
     • Material Transaction Reason Code
     • Service Warranty

Note: All the attributes with the exception of Disposition Code has an Entity of Service Order.

• Attribute: This enables the user to specify a value from a dynamically generated list of values for the Defaulted Attribute. This list of values is generated based on the selection in the Defaulted Attribute.
• PL/SQL API: This defaults the value returned from a call to the specified PL/SQL API to the Depot Workbench when this rule is evaluated to be true.
• Profile: When you select profile as the value type and there are multiple levels of profile setting (for example, profile values set at the User level and at the Responsibility level), the system behaves the way it does for other profile option selections. This means it defaults from the most specific level that has been set (in this example, giving the User level setting precedence over the Responsibility level setting).

Using Defaulting Rules

To use defaulting rules

1. Navigate to the Depot Repair Workbench and click the New button to navigate to the Service Orders page.
2. Create a new Service Request and click Save. See: Create a Service Request.
3. Create a new service order for the item for which you have set the defaulting rule. See: Create a Service Order in the Depot Repair Workbench, to create a service order.
4. Click in the Service Type field, in the Service Order Information region. Any field for which rules have been created which evaluate to true defaults. You can overwrite the default values till the service order is saved.

Disposition Rules Engine

Service type, service location, service organization, third party service vendor, exchange from location and other values default at the time of service order creation based on customer defined rules. Rules are based on service item, service location, customer, contract, and the like.

Disposition implies a specific set of attributes related to where a product goes and what is done to it, for example the shipping and receiving inventory organization, subinventories, the service type, and the like.

Returns Portal Parameters

The Returns Portal provides an effective and efficient way to enable customers to return products. Customers may exchange or return products for service, repair, testing, calibration or trade-in credit. The Returns Portal allows customers, business partners, and retail associates and distributors to request returns directly via a web portal.

Setting up Returns Portal Parameters

To set up returns portal parameters:

1. Navigate to the Returns Portal Parameters Page. This page displays the summary of existing returns portal parameters.
2. To set up a new parameter, click Add Another Row button.
3. Enter the values in the following fields:
   • Parameter Name: Enter a unique name for the parameter. Parameter name determines system behaviors for the entire business or only conditionally when specific conditions are true.
   • Description: Enter a description of the parameter.
   • Value: Enter a value of the parameter. Parameters are created with values that are enumerated list (Yes or No), integers, decimals, date times or LOVs.
4. Click Save to save the parameter.

For more information see:

Setting Up Returns Portal Parameters, Oracle Depot Repair Implementation Guide.

Setting Up Service Types, Oracle Depot Repair Implementation Guide.

Integration with Other Oracle Modules

Oracle Depot Repair integrates with the following Oracle modules:

Advanced Pricing

Oracle Depot Repair incorporates some but not all Advanced Pricing features. Currently, the following Advanced Pricing features are supported:

• Modifiers, Qualifiers (Auto apply only)
• Secondary Price Lists
• Qualifiers currently supported are:
  • Customer Account
  • Party id (customer_id)
  • Customer class
  • Item category
  • Order Type
  • Operating Unit (Org Id)
  • Line Type
  • Line Category Code

  Assignment Manager

  Oracle Depot Repair uses Assignment Manager to schedule technicians to all open and planned tasks. This module permits the planner to use the Assignment Manager in an assisted or unassisted mode. For more information, see the Oracle Common Application Components User's Guide.

  Bills of Material

  Oracle Bills of Material store lists of items that are associated with a parent item, and information about how each item relates to its parent. Oracle Depot Repair uses Oracle Bills of Material to create service routers that the system uses for a submitted WIP Job, and to create a bill of materials for an item that is linked to a service router.

  Contracts (Contracts Core and Service Contracts)

  Oracle Depot Repair integrates with Oracle Service Contracts to manage service contracts associated with a customer's Installed Base item. Oracle Service Contracts holds all service contracts centrally--including warranties, extended warranties or complex service agreements--and provides the service provider visibility to all service entitlement information. It leverages functionality that Oracle Contracts Core provides to support common contract management activities, such as contract renewal, versioning, article management, and change management.

  Counters

  Counter events and alerts provide a valuable tool to track critical service events that can affect a customer or items in the Installed Base. Oracle Depot Repair uses the Counters module to update item counters periodically, whenever a depot technician performs work on the item, and saves it in the Installed Base record. The Counters module also permits a service provider to set up logical or derived counters that use formulas that incorporate calendar dates, time, and cycle counts to trigger an event, such as a warranty or service contract expiration, or to alert the service provider when to schedule preventive maintenance on a customer's Installed Base item. The system can send alerts by the e-mail notification system to inform service personnel about warranty or service contract expiration, or about a preventive maintenance requirement that is due.

  Field Service

  When an organization sells an item to a customer, service contracts or warranties are often offered to the customer. Most companies offer on-site support for failures of the item. This is where field service is significant. After the customer reports the problem, the field service organization determines:

  • Who and when a field service agent should visit the customer.
  • What parts are needed to solve the problem.

  If a field service agent cannot completed the service on-site, the service may need to be transferred to the depot for completion. Furthermore, internal order refurbishments can be initiated in the Spares Management module within Oracle Field Service.

  HRMS (Human Resource Management System)

  Oracle Depot Repair uses the Oracle HRMS module to define employees and locations.

  Installed Base

  Oracle Installed Base is a repository that tracks all installed customer items. Oracle Installed Base maintains and updates each item record to reflect the most current configuration. Service organizations rely heavily on their installed base to provide accurate customer and item information. The installed base permits quick access to all item records and information. Oracle Depot Repair leverages this information to expedite the service process when services involve incompatibility, configuration, revision, or counter history issues. Oracle Depot Repair integrates with Oracle Installed Base to assist accurate recording of all part and serial numbers that change during an item's life. It retrieves all service contracts and warranties associated with an Oracle Installed Base serialized item or component. Depending on the definition of Oracle Installed Base transaction sub-types, the TeleService Charges APIs update the location and instance ownership information.

  Inventory

  Oracle Depot Repair uses the Oracle Inventory module to manage item and spare parts inventory.

  iSupport

  Self-Service Service Order tracking is now supported in Oracle iSupport. Oracle Depot Repair customers can now search for their Service Orders through an Oracle iSupport self-service user interface. Oracle iSupport will properly authenticate the user and display only Service Orders for accounts which the user is authorized to view.

  Knowledge Management

  Oracle Knowledge Management is an Oracle Service Core module that provides an open architecture repository to store technical information or solution sets. Service agents and technicians can retrieve this information to find a quick resolution to service issues that customers are reporting, or provide assistance in an inspection or item diagnosis. Oracle Knowledge Management provides a security feature that permits only users with specific responsibility to contribute new information to the database.

  Oracle Depot Repair uses the Oracle Knowledge Management Search Engine to find the best possible solutions to resolve service issues. Agents can access the knowledge repository from the Service Request or the Service Order. You can search for solutions by entering a Diagnostic Code or keyword string to query on statements that have links to a symptom, cause, action, or fact solution set. A solution set can also include a Task Template or set of objects that can automate or expedite the service process.

  Notes

  Notes allow technicians, service agents, receiving clerks, billing clerks and others to capture free form notes related to a specific service order. For more information, see the Oracle Common Application Components User's Guide.

  Order Management

  Oracle Depot Repair uses the Oracle Order Management module to create RMA and Sales Orders, and invoice customers for services.

  Oracle Depot Repair integrates with Oracle Order Management Pricing to provide an advanced, highly flexible pricing engine that executes pricing and promotional calculations. It allows Oracle Depot Repair users to view and select a Price List while charging for a service, and while receiving or shipping an item.

  Purchasing

  Oracle Purchasing enables Depot users to request parts and receive purchase orders for outside processing.

  Trading Community Architecture

  The Oracle Trading Community Architecture module integrates with Oracle Depot Repair integrates to track and maintain customer information such as customer name, account, customer contacts, and location.

  Resource Manager

  Oracle Depot Repair uses Resource Manager to manage employees when using Task mode. The Resource Manager permits a user to import employees and non-employees from HRMS into the resource module. You can set up and manage resources as individual resources, or as a team or group, and assign roles and skill sets to distinguish their qualifications. For more information, see the Oracle Common Application Components User's Guide.

  TeleService (Charges)

  Oracle Depot Repair uses TeleService Charges APIs to automatically create charge lines for estimates, actuals and logistics.

  TeleService (Customer Care)

  The Customer Profile summarizes customer information and indicates if a customer is critical. It can provide information such as the number of open Service Requests. A system administrator sets up the profile entries, which contain a set of defined verifications that you can configure. The Customer Profile engine displays these verification results. Oracle Depot Repair uses this functionality for customer management.

  TeleService (Service Requests)

  Service agents typically log a Service Request to record a service issue that a customer is reporting. Oracle Depot Repair invokes Oracle TeleService APIs to automatically create the Service Request after creation of the Service Order header. The TeleService APIs populate the Service Request number into the Service Order Header to permanently link the two source documents with an internal form identity. Depot business flows always start with the creation of a Service Request.

  Task Manager

  Oracle Depot Repair uses the Task Manager to assist service management. The Tasks model leverages the core functionality that Oracle Depot Repair provides by its integration with Resource Manager, Assignment Manager, and Oracle Calendar. The Task mode provides an alternate service process that is intended to manage simple service work that does not require extensive tracking or management processes. After task completion, the technician uses the Debrief Report in Oracle Depot Repair to log the material, labor, and expense transactions. For more information, see the Oracle Common Application Components User's Guide.

  Work in Process

  Oracle Depot Repair uses WIP APIs to automatically create the jobs, operations, materials and resources required to execute service. Technicians can drill down from the Technician Workbench into the native WIP screen to view on hand quantity of parts and other information.

  Note: Oracle Depot Repair provides E-records and E-signature (ERES) functionality in WIP mode via Oracle WIP.