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 is part of the Oracle E-Business Suite and offers an enterprise-wide solution for managing depot repair processing. It targets the repair business market from simple, quick repairs to routine maintenance. Oracle Depot Repair integrates with other Oracle E-Business Suite modules to provide an integrated comprehensive solution for the repair business sector.

The depot repair process includes the return of broken and serviceable items, their diagnoses and repair job estimates, customer approvals and repairs management, and subsequent return of items to customers. You use the collection of charges for materials, labor, and expenses for the repairs to invoice the customer.

The depot repair process also includes the processing of item refurbishments, where the items either belong to an internal party, or the items are received from a field service warehouse and then returned to the warehouse after repair.

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

Oracle Depot Repair enables service organizations to meet customer expectations, and draw maximum benefit by improving service readiness.

Oracle Depot Repair Key Features

The major features of Oracle Depot Repair include:

Customer Management

Oracle Depot Repair can use a call center environment to improve customer interaction with service depots. Customers can use an access number to contact the relevant service depot where they can log Service Requests. The primary focus of the service representatives in the call center is to understand the customer's issue and resolve it on the first call, if possible, thereby avoiding escalations or call transfers. This lets service agency experts focus on their areas of expertise without the constant distraction of explaining well-documented issues and solutions.

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

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

Key customer management features include:

Oracle Depot Repair Workbench

The Repair 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 Repair Orders, open Service Requests, active contracts, and other details for a selected customer. In the Find Repair Orders window, service agents can query for Repair Orders, to see the Repair Order statuses, repair jobs, and repair 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 agencies.

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 repair 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 or over the counter. Key Service Request management processes include:

Service Request Builder

Oracle Depot Repair lets you enter new Service Requests to gather appropriate data. It lets service agents record customer information and attempt problem resolution to solve issues in the very first interaction.

Searchable Oracle 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 Repair 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 Repair Order processing, by providing charge lines for WIP and Task estimates, and Bills and Routings for WIP Repair Jobs.

Repair Type Processing

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

Oracle Depot Repair supports the following Repair Types:

Repair and Return

Use this Repair Type when a customer returns the broken or damaged item to the service depot for repair. After completion of the repair, you return the repaired item to the customer. This Repair Type requires:

Loaner, Repair and Return

This Repair Type combines two Repair Types, the Repair and Return, with the Loaner. The loaner concept indicates that service 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 charge lines. This Repair Type requires two RMA Orders and two Sales Orders. Use this Repair Type when a customer uptime is critical.

Exchange

This Repair Type represents a scenario when the service depot sends an exchange item to the customer after receiving the customer's broken or damaged item. The Exchange Repair Type assumes that the repaired item does not return to the customer. The system can generate an internal Repair Order for the returned item, but there is not necessarily an association between the repaired item and the original exchange item.

Advance Exchange

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

Loaner

Use this Repair Type when the service depot sends an item to the customer solely for the purpose of renting. This Repair 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. The customer has no expectation of repairs.

Replacement

A Replacement Repair Type refers to a scenario when the service 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:

Standard

Use this Repair Type when the service agent is uncertain about the customer's needs. This Repair Type is flexible however, and requires the manual creation of RMAs and Sales Orders.

Refurbishment

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

The Move In line tracks the shipment of the defective item from Spares Management, and its reception into the depot. The Move Out line processes the shipment of the repaired item back to Spares Management.

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/repaired items are shipped via the Internal Order.

Repair Job Management

Use either of the following repair modes to manage repair jobs:

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

During implementation, you associate the WIP or Task mode with Repair Types. Though a service organization can have different Repair Types associated with different repair modes, it is recommended that a service organization select only one repair mode for all Repair Types to enhance usability.

Repair Resolution Management

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

Business Process Flows

Oracle Depot Repair supports the following business process flows:

You can use either Oracle Work In Process (WIP) or the Task Manager (in Oracle Common Application Components) to manage the repair process. Based on your choice, the Repair Type for a given Repair Order determines which repair 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 service depot repair agent. The service depot agent can then create a Repair Order and an estimate (if required) and seek approval from the customer for further processing.

Depending on the Repair Type, the service depot repair agent completes the different RMA and Sales Order lines to assist the completion of the repair process. The repair mode (associated to the Repair Type) determines whether to use Oracle WIP or the Task Manager in Oracle Common Application Components to manage the repair job. After the repair completion, the service depot returns the repaired item to the customer. The system captures the material, labor, and expenses that the repair 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, but it requires that their customers to send serviceable items directly to a service depot.

Internal Party Repairs

You can refurbish items that your organization already owns or repair an item that your organization took possession of through a field service agent instead of against an RMA. Oracle Depot Repair lets you process internal repairs in such cases. The customer is an internal party in the corresponding Service Request. RMAs and Sales Orders are not required to process internal repairs. This is under the assumption that items already exist in a subinventory within the organization letting you create repair 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 from 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 repairs to specific resources based on the following two customer defined rules:

Defaulting Rules Engine

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

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.

    the picture is described in the document text

  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 repair order.

      The list of values for Defaulted Attribute are:

      • Inventory Organization

      • RMA Receiving Organization

      • RMA Receiving Sub-Inventory

      • Repair Organization

      • Repair Owner

      • Repair Priority

      • Repair Type

      • Ship From Organization

      • Ship From Sub-Inventory

      • Vendor Account

    • Value Type: It lists attributes whose values default using Defaulting Rules. Valid list of values for Value Type are:

      • 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).

  4. Click the Details icon to navigate to the Update Defaulting Rule page.

    the picture is described in the document text

    This page displays the details of the defaulting rule you entered. Use this page to specify a value for the defaulted attribute and the conditions to trigger the rule.

  5. In the Defaulting Conditions region, click Add Another Row to enter a self-explanatory name for the condition.

    Defaulting Conditions region enable you to define one or more conditions for a defaulting rule. All the conditions must evaluate to true to execute the defaulting rule.

  6. Click Apply to save your work and navigate back to the Defaulting Rules page.

  7. Click Save to save the Defaulting Rule.

  8. Duplicate icon duplicates the condition.

  9. To delete a defaulting rule, click the corresponding Remove icon in the Defaulting Rules page.

Using Defaulting Rules

To use defaulting rules

  1. Navigate to the Depot Repair Workbench and click the New button to navigate to the Repair Orders page.

  2. Create a new Service Request and click Save. See: Create a Service Request.

  3. Create a new repair order for the item for which you have set the defaulting rule. See: Create a Repair Order in the Depot Repair Workbench, to create a repair order.

    the picture is described in the document text

  4. Click in the Repair Type field, in the Repair Order Information region. Any field for which rules have been created which evaluate to true defaults. You can overwrite the default values till the repair order is saved.

Disposition Rules Engine

Repair type, repair location, repair organization, third party repair vendor, exchange from location and other values default at the time of repair order creation based on customer defined rules. Rules are based on repair item, repair 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 repair type, and the like.

Integration with Other Oracle Modules

Oracle Depot Repair integrates with the following Oracle modules:

Advanced Scheduler

Oracle Advanced Scheduler enables optimal scheduling of tasks and trips for field service business needs. While the Assignment Manager (in Oracle Common Application Components) searches for qualified resources to complete a field service task (based upon selection criteria set within the Assignment Manager), these qualified resources transfer to Oracle Advanced Scheduler to make the actual assignments based upon previously defined constraints. Oracle Advanced Scheduler uses the Assignment Manager to schedule Field Service tasks.

Assignment Manager

Oracle Depot Repair uses Assignment Manager to schedule technicians to all open and planned repair 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 repair routers that the system uses for a submitted WIP repair job, and to create a bill of materials for an item that is linked to a repair 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

Note: The Counters module is now incorporated in Oracle Installed Base.

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 service 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:

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

General Ledger

Oracle Depot Repair integrates with Oracle General Ledger to provide the functionality of recording and tracking all costs associated with every Oracle Depot Repair WIP mode repair, and of creating general ledger accounts.

HRMS (Human Resource Management System)

Oracle Depot Repair uses the Oracle HRMS module to define employees and locations where you ship, deliver internally, or bill the ordered goods and services.

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 must 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 repair process when repairs 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 Repair Order reporting is now supported in Oracle iSupport. Oracle Depot Repair customers can now search for their Repair Orders through an Oracle iSupport self-service user interface. Oracle iSupport will properly authenticate the user and display only Repair 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 constantly enriched active 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 Repair 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 repair process.

Notes

A note records descriptive information, which users have created, about business transactions to provide referencing. Oracle Depot Repair uses the Notes module to access the comment log that relates to a specific transaction. The Notes module creates and passes information to all other Oracle applications. Upon transmission and receipt of a note, the system automatically sends an alert to the Oracle Depot Repair module to signal that a new note is present. Service employees can pass valuable information that can influence the repair process. The Notes module permits users to post both public or private notes, where public notes can be published to a Web site, and private notes are only accessible to employees that work inside the service organization. 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, validate customer accounts, and invoice customers for repairs.

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 a repair, and while receiving or shipping an item.

Purchasing

For receiving, Oracle WIP uses Oracle Purchasing to perform outside processing of a repair from the WIP Router.

Receivables

The Oracle Receivables 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. 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)

With the Charges module, a service organization can bill customers for provided services in response to support Service Requests, field Service Requests, and service depot repairs. Charges also creates a return material authorization (RMA) to return a defective item for repair, loan, or replacement. Returns from a customer occur for a variety of reasons including damage, shipment error, and repair. With the Charges capability of processing return material, you can manage customer expectations while controlling inventory receipts and processing customer credit. Oracle Depot Repair uses TeleService Charges APIs to automatically create the charge lines when the service depot has determined the Repair Type.

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 Repair Order header. The TeleService APIs populate the Service Request number into the Repair Order Header to permanently link the two source documents with an internal form identity. Service depot business flows always start with the creation of a Service Request.

Task Manager

Oracle Depot Repair uses the Task Manager to assist repair 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 repair process that is intended to manage simple repair 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.

Note: Oracle Depot Repair provides E-records and E-signature (ERES) functionality in Task mode via the Debrief screen for each Task.

Work in Process

Oracle Depot Repair uses Oracle Work in Process (WIP) to assist the repair of broken or damaged items. Oracle WIP permits assignment of resources, material, and outside processing. A WIP summary report tracks the associated costs with a completed WIP repair job. You can submit WIP mode repair jobs with or without an assigned routing.

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