This chapter discusses the key concepts, features, and process flows of Oracle Depot Repair.
This chapter covers the following topics:
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.
The major features of Oracle Depot Repair include:
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:
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.
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.
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.
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:
Entering Service Requests
Searching the Oracle Knowledge Management Database
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.
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, 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.
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:
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:
Areturn materials authorization (RMA), or Return line, to receive the customer's broken or damaged item.
A Sales Order, or Ship line, to ship the repaired item and invoice the customer.
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.
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.
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.
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 requirements. The customer has no expectation of repairs.
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:
Link the replacement item to the original item in the Oracle Installed Base.
Change thestatus of the replaced item to indicate that it is out of service and that the new item has replaced it.
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.
A Repair Order and its associated Service Request can be created in the Spares Management module 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.
The repair centres require the ability to interface with third parties to fulfill a customer's service requirements. Repair centres track the movement of products, work, and financial obligation between all the parties involved in executing a repair. For a third party repair execution, an Outside Processing (OSP) operation is created in the Repair Technician Portal. OSP operations are not specific to Depot Repair, they are standard in Work in Process (WIP). Essentially, completing the OSP operation triggers the creation of a purchase order with a request to procure service from a third party.
The return only repair functionality is used when a repair type is setup to have an RMA line. In this case, there is no corresponding ship line. When an item is returned, you have the following options:
Items are returned for credit
Items are returned to stock
Items are returned for salvage
For example, when an item is returned, all the parts are first salvaged, the parts are recycled, and the remaining parts are scrapped.
Use either of the following repair modes to manage repairs:
WIP (Work In Process): Recommended for use when the repairs require a series of sequential steps and materials management. The WIP mode leverages the costing of items through Oracle Costing.
Task: Recommended for use when the repairs 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.
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.
Oracle Depot Repair improves operational efficiency by providing the following key repair resolution management features:
Automatically creating charge lines based on Repair Type.
Leveraging of the service depot knowledge base throughout repair processing.
Creating Repair Jobs and releasing them to shop floor.
Providing flexible options for receiving items and shipping items.
Invoicing of final charges.
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.
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.
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.
You can refurbish items that your organization already owns. Oracle Depot Repair lets you process internal repairs in such cases. The customer is an internal party in the corresponding Service Request, and is defined as an internal party either in the Oracle Installed Base Install Parameters, or with an Internal classification type in Oracle Order Management, or both. RMAs and Sales Orders are not required to process internal party repairs. This is under the assumption that items already exist in a subinventory within the organization letting you create Repair Jobs.
Oracle Depot Repair integrates with the following Oracle modules:
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.
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.
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.
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.
Note: Counters is now integrated into 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 Oracle 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 email notification system to inform service personnel about warranty or service contract expiration, or about a preventive maintenance requirement that is due.
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 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.
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.
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.
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.
Oracle Depot Repair uses the Oracle Inventory module to manage item and spare parts inventory.
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.
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.
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.
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.
For receiving, Oracle WIP uses Oracle Purchasing to perform outside processing of a repair from the WIP Router.
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.
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.
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.
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.
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.
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.
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.
The following table presents the business functions in a depot that the Oracle Depot Repair integrating applications impact.
| Integrating Oracle Module | Customer Interaction | Repair Management (WIP Mode) | Repair Management (Task Mode) | Logistics | Billing/ Invoicing |
|---|---|---|---|---|---|
| Advanced Scheduler | -- | -- | X | -- | -- |
| Assignment Manager | -- | -- | X | -- | -- |
| Bills of Material | -- | X | -- | -- | X |
| Contracts (Contracts Core and Service Contracts) | X | -- | -- | X | X |
| Counters | X | X | X | X | -- |
| Field Service | -- | -- | X | -- | X |
| General Ledger | -- | -- | -- | -- | X |
| HRMS | -- | X | X | -- | -- |
| Installed Base | X | X | X | X | -- |
| Inventory | -- | X | X | X | X |
| iSupport | X | -- | -- | -- | -- |
| Knowledge Management | X | X | X | -- | -- |
| Notes | X | X | X | -- | -- |
| Order Management | -- | -- | -- | X | X |
| Purchasing | -- | -- | -- | X | -- |
| Receivables | -- | -- | -- | X | X |
| Resource Manager | -- | -- | X | -- | -- |
| Task Manager | -- | -- | X | -- | X |
| TeleService (Charges) | -- | X | X | X | X |
| TeleService (Customer Care) | X | -- | -- | -- | -- |
| TeleService (Service Requests) | X | -- | -- | -- | -- |
| Work in Process | -- | X | -- | -- | X |