SERVWP

8/7/2019 SERVWP

http://slidepdf.com/reader/full/servwp 1/33

Chapt er 3

Service

8/7/2019 SERVWP


2 Oracle Sales Force Automation Functional Overview

Overview

Oracle Service offers a critical extension to your su pp ly chain by p roviding su pp ort for prod ucts

after you have sold them. By offering you complete access to customer and product profiles,

including current and past service history, Oracle Service helps you strengthen your customerrelationships.

Oracle Service is an integrated customer service solution that provides installed base

man agemen t, supp ort service tracking, service requests, and dep ot repair. You can fully integrateyour service organization with the rest of your business by leveraging Oracle Service with OracleOrder Entry, Oracle Receivables, Oracle Inventory, and Oracle Work in Process. Oracle Service

shares key data with these Oracle Applications modules, such as customer and product masters,

so you can spend less time managing d ata and m ore time servicing your custom ers.

Oracle Quality

Oracle

Manufacturing

OracleInventory

OracleFinancials

OracleHuman

Resources

OracleService

Installed Base

Service ProgramsService Billing

Service RequestsDepot Repair

OracleSales and

Marketing

TerritoriesEvents

PromotionsOpportunities

Literature Fulfillment

OracleProduct

Configurator

OracleOrder Entry

Customer Interaction Solution

Installed Base Management

Oracle Service Installed Base module provides you with information about products that have

been installed at each customer site, as well as the support services for these products. By

capturing information from Oracle Order Entry, Oracle Service provides information about

prod ucts sold to customers or distributors, custom er contacts, shipping d etails, installation dates

and ad dresses, warranties, and service programs ap plied to the installed prod ucts.

8/7/2019 SERVWP


Oracle Service 3

Installed base functionality helps you track the models and options installed at your customer

sites, including serial numbers and product revision numbers. You can also group these product

configurations into flexibly defined systems for service management, distribution of responsibility, or reporting purposes. When you review the products that are installed at a

customer address, you can see whether these products are covered by purchased service

programs or included w arranties.

If you sell products to resellers, who in turn sell them to end customers, you can transfer

installed base information from the reseller to the end customer to keep your installed base

information up-to-date.

Support Services

You can create warranties and service programs to represent the various support services that

you provide to your customers. A warranty that you define for a specific product is appliedautom atically to that prod uct whenever you sell that prod uct. In contrast, a service program is a

support service that you charge to your customer at a particular price; for example, an extended

warranty or an agreement to provide telephone support. For each service program or warrantythat you create, you can define coverage schedules detailing the hours during the day and days

du ring the week wh en customers may request that service for their prod ucts. You can control the

availability of your services by p rodu ct, by customer, or a combination of both.

Oracle Service’s flexible service renewal procedures help you provide your customers with

uninterrupted support. Oracle Service generates sales orders for service renewals and submits

these orders to Oracle Receivables for billing. Service transaction records are available for you to

view the history of a product's service, including the initial service order and all renewals and

terminations of the service.

Service Requests

When your customers call with questions or problems, you can track each call using Oracle

Service’s Service Request module. You can categorize service requests into various user-definedtypes such as stand ard customer calls, hot calls, prod uct installation requ ests, produ ct inquiries,

customer complaints, field failures, field maintenance visits, and returned products. For each

service request that you create, you can enter details such as problem and resolutiondescriptions, actions requested or taken, service personnel assigned to resolve the service

request, the urgency from the perspective of the customer, severities, dates, timestamps, actual

resolution times, problem codes, resolution codes, and so on.

Depot Repair

Oracle Service efficiently manages your repair depot through tight integration with Return

Material Authorizations (RMA) in Oracle Order Entry, discrete job repair functionality and

repair cost tracking in Oracle Work in Process, and invoicing in Oracle Receivables.

You can verify service program or warranty coverage on a product as you process a customer

retur n for repa ir or replacement. For each repair item, you can perform a d iagnosis and create anestimate, or pick a previous estimate for an item. If you choose to apply a customer's service

coverage to the repair, you can m odify the estimate based on the service coverage to ensu re that

the custom er is correctly billed according to the labor, mater ial, and expense coverage. For items

not covered by a service program or warranty, Oracle Service can optionally put the repair onhold until your customer approves the estimate. Oracle Service helps you create repair jobs in

Oracle Work in Process for app roved rep airs. Alternatively, you can send a rep lacement item to

your customer by creating a rep lacement sales order.

8/7/2019 SERVWP



Customer ProductAgreement

Sales OrderService Program

Diagnosis

Service Billing

Installed BaseCustomer Products

Warranty

RMA

Service Request

Knowledgebase

Text Search

ResolutionWorkflow

Closure

Estimate

Sales OrderRepair Job

Repair JobWorkflow

Completion

Quality

Service Billing

Oracle Service Overview

8/7/2019 SERVWP


Oracle Service 5

Key Features

Service Item Definition

· Define serviceable items and service programs

in a central item master shared with Oracle

Inventory

· Define warranties to be included for serviceable

items

Service Orders

· Using Oracle Order Entry, create sales orders for

serviceable products and their service programs

·

Create sales orders for product upgrades and

revision updates

·

Define the integration point in the order cycle to

populate the service installed base from orders for

new products, service programs, and warranties

Agreements

·

Define and administer the agreements you makewith your customers for existing and future

product and service purchases

· Specify price discounts, payment terms, billing

method, and revenue recognition method for each

agreement

Service Pricing and Discounting

· Automate service pricing and discounts using

Oracle Order Entry

· Create automatic and manual discounts based on

service, customer, customer agreement, purchase

order, or order type

· Create fixed-amount service pricing or percentage

of product price

Product Configurations

· Capture pick-to-order and assemble-to-order

configuration options from sales orders

· Capture serial numbers and lot numbers from

shipments

· Group customer products into user-defined

systems

Revenue Recognition and Billing Rules

· Recognize service revenue over multiple periods

using accounting rules defined in Oracle

Receivables

· Create invoices for service using invoicing rules

defined in Oracle Receivables

Service Coverage

· Define coverage schedules detailing the hours

during the day and days during the week

when customers may request service for their

products

· Control the availability of your services by

product, revision, or customer

· Activate new services based on either an

activation date or the installation date of the

serviced product

· Renew service programs as they approach

their expiration dates

· Establish the same service end date

(coterminate) for all services for a given

system, or customer

· Automatically generate credit memos for

terminated services using Oracle Receivables

Service Requests

· Verify service or warranty coverage on-line

as you process service requests

· Define your own service request statuses,

types, priorities, and urgencies

· Enter an unlimited number of actions for each

service request and assign each action to an

appropriate support analyst

Returns

·

Enter returns using Oracle Order Entry’sReturn Material Authorizations (RMA)

·

Create replacement orders

· Receive products returned by customers

Depot Repair

· Charge your customers only for the parts and

services not covered by a service program or

warranty

· Create a Return Material Authorization

(RMA) based on customer, product, and

problem information from a service request

· Perform a diagnosis for each returned item

and provide the customer with an estimate on

the labor and material required for the repair

· Acquire customer approvals before beginning

repair work

· Create repair sales order based on the

approved estimate

8/7/2019 SERVWP



Supported Business Processes

You can create a sales order to sell a serviceable product to a customer. In addition to the

serviceable product, the order can also contain a service program for that product, such as

telephone hotline supp ort for prod uct inquiries, complaints, or problems. You can a lso includ e awarranty w ith the prod uct to cover expense, labor, and material.

As you ship the product to your customer, you can record the product serial number, lot

num ber, or revision. If the prod uct is a 'pick to order' configuration, you can also record the serialnum bers for the various options that your customer selected.

The serviceable product, service program , warranty, and other information such as th e customer

name, installation addresses, contacts, and ship date forms the installed base customer service

database. You can use the installed base to view what products have been sold and to whom,and which products are covered by a service program or warranty. The installed base also helps

you d etermine when th ese sup port services are du e to expire.

Perhap s you sell your p rodu cts to distributors who, in turn , sell them to the end customer. When

you know who the end customer is, you can optionally transfer the serviceable product and itsservice program s and warranty from the distributor to the end customer.

If you n eed to p lan the produ ct installation at the customer site, you can enter a serv ice request to

assign the installation task to a field service engineer. After the installation, you can enteradditional details, or service request actions, which serve as the service history for work

performed at the customer site. Then, you can also activate the prod uct warranty.

For example, if the warranty expires after 90 days, your customer might want to purchase a

service program for extended coverage. You can then create another sales order for this serviceprogr am and bill the customer accordingly.

If your customers pu rchased a service program for telephone su pp ort, they are authorized to call

the hotline during certain business hours. The installed base helps you verify each supported

customer when the customer calls. You can define the different reasons for calls as servicerequest types, with various d egrees of urgency and severity. To track these calls, you can enter aservice request for each call and assign each service request to your support personnel who areresponsible for resolving and closing the service request. Each typ e of service request can have a

resolution process that you d efine, with various actions, owners, and so forth. Once all actionsagainst a serv ice request h ave been comp leted, the service request can be closed.

Oracle Service support s depot repair functionality for customer retur ns, includ ing repair-and-return

and replacement. If the serviceable product becomes defective, your customer may call yourhotline to report this problem. You can enter a service request to track this call, and enter a retu rn

material authorization (RMA) to track the defective product when it is returned to your service

center. After you r eceive the d efective produ ct from your customer, you can replace or rep air it.If you decide to repair it, you can diagnose the problem, enter an estimate for the repair, and

optionally seek customer approval before beginning the repair. The estimate, which you can

enter before, du ring, or after the rep air, can include th e labor and mater ial for your r epair. If the

prod uct is covered by a service program or warr anty, you can app ly the coverage to the estimateto redu ce or eliminate the rep air charges.

If the service program for the telephone su pp ort is du e to expire, perhap s after several months or

a year, Oracle Service reports the expiring supp ort services and enables you to r enew the service

program, and creates a new sales order for the renewal.

8/7/2019 SERVWP


Oracle Service 7

Replace defect iveproduc ts

Receive Order forProduc ts & Support

Services

Provide & Track On-si te support

Prov ide and Trackhotl ine support

Schedule & PerformIni t ial Support

ServicesShip Produc t

Repai r damagedproduc ts

Bi l l Customer

Receive addi t ionalservice orders, &

renew expiringservices

Terminate Service

Cred i t Cus tomer

Transfer Products &Services to another

cus tomer

High Level Business Flow

8/7/2019 SERVWP



Installed Base Management

The Oracle Service installed base tracks products that you have sold to customers. A "customer

prod uct" is an instance of a specific produ ct that you have sold to an end customer or distributor.

The installed base is your information resource to determine each customer's product andinstallation details, and the support services that apply to these products. This repository of

customer product information contains details such as item numbers, serial and lot numbers,

revision history, order numbers, order dates, customer addresses, technical and administrative

contacts, pr ices, quantities, agreements, ship dates, and installation da tes.

Customer Products Window (Detailed View)

Shared Customer Master

Oracle Service shares customer information with other modules such as Oracle Order Entry,

Oracle Receivables, and Oracle Sales and Marketing. Sharing this critical information across your

various organizations helps ensu re that the information is consistent and accurate.

You can define customers in either Oracle Ord er Entry or Oracle Receivables. For each customer,

you can define multiple addresses and specify one or more business purposes for each address.

You can use th ese business pu rposes to indicate bill-to, ship-to, and installation add resses. Youcan also define contacts and assign them to a customer or an ad dress, and telephone nu mbers for

a specific address or customer contact. For each customer product in the installed base, Oracle

Service tracks up to three add resses (bill-to, ship-to, and insta llation) as well as four sep aratecontacts (bill-to, ship-to, technical, and ad min istrative).

Shared Item Master

Oracle Service shares item information with other modules such as Oracle Inventory, Oracle

Order Entry, Oracle Bills of Material, Oracle Work in Process, Oracle Purchasing, Oracle MasterSchedu ling/ MRP, and Oracle Quality.

8/7/2019 SERVWP


Oracle Service 9

In Oracle Inventory, you can define items that represent products or services that are critical to

your service organization, such as:

· Serviceable prod ucts, which are end items that you wish to tr ack in the installed base after

being sold

· Service programs, which represent billable supp ort services such as telephone su pp ort, field

service sup port, extended pr odu ct warran ties, etc.

· Includ ed w arranties, which you can att ach to a specific serviceable prod uct and are ap plied

autom atically wh en you sell those produ cts

· Material, such as replacement p arts, used as you rep air defective customer pr odu cts in a

dep ot repair facility

· Labor and expenses used in depot repair

Oracle Inventory uses the concept of "item attribute groups" to determine how to treat items in

the various Oracle Applications modu les that share the item master. Accordingly, the Serviceattribute group is used by Oracle Inventory and Oracle Service to flag a particular item as a

serviceable prod uct, service program , warran ty, repair material, repair labor, or repair expense.

For example, assume you sell personal comp uters. "Pentium Super" is an en d p rod uct, defined as

a serviceable produ ct for installed base tracking. "90-day warran ty" is an included warr anty tha talways comes with the Pentium Super. "Hotline support" and "Extended coverage" are billable

service programs that you optionally sell along with the Pentium Super, or perhaps sell later

when the included warranty expires. "Power supply A" is a repair material that you sometimes

replace in the Pentium Super. "Stand ard labor rate," with a list pr ice of $50 and a un it of measureof hours, is a billable labor to repair the Pentium Super. "Zone 1 travel expense" is a billable

expense when you have to dispatch an engineer to repair a Pentium Super at a customer site.

Each of these is an item d efined in the Oracle Inventory item master.

Automatic Capture from Order Entry

Oracle Order Entry autom atically popu lates the installed base as you process customer ord ers to

keep your installed base consistent with actual sales of prod ucts and serv ices. As you enterorders in Oracle Order Entry, you can enter installation details for each product, such asinstallation addresses, contacts, and descriptive flexfields for capturing user-defined data. In

ad dition, you can ind icate service program s to sell along with each p rodu ct, with coverage d ates,

prices, and discounts to ap ply.

Service Interface

Using Oracle Order Entry's concept of order cycles, you can determine the point in the order

process wh ere ord er d etails should be copied to the installed base. Service Interface is the cycle

action that Oracle Order Entry uses to add customer products to the installed base, or to modifyexisting customer prod ucts for produ ct upgrad es, revision upda tes, and rep lacements.

Shipping Interface

As you ship products, Oracle Order Entry automatically copies to the installed base the serial

numbers, lot numbers, and revisions that you enter. Serial control, lot control, and revisioncontrol are item attributes you can set in Or acle Inventory as you d efine items.

8/7/2019 SERVWP



Invoicing Interface

Oracle Order Entry interfaces with Oracle Receivables to provide invoicing for serviceable

products, service programs, and depot repairs.

Services Window

Installed Base Interfaces

The first figure in this chapter shows h ow Oracle Service integrates with Oracle Order Entry and

Oracle Receivables. After you enter, book, and ship sales orders, the Installed Base Interface

copies information about sold serviceable products, service programs, and warranties to theOracle Services installed base. The Installed Base Interface also updates the installed base after

ord er cancellations.

To populate the installed base from Oracle Ord er Entry, sales orders m ust u se an ord er cycle that

contains the Service Interface cycle action. Pick Release and Ship Confirm are required cycle

actions for shippable orders. Receivables Interface is a required cycle action for invoicing to takeplace in Oracle Receivables.

After a serviceable product is sold and copied to the installed base, it becomes a customer

prod uct. You can ord er a new service program for a customer p rodu ct, or renew an active service

program that is about to expire. When you order or renew service programs for a customer

product, Oracle Service uses the Order Import program in Oracle Order Entry. Order Import

automatically creates new sales orders for the new or renewed service programs. As you book these sales orders, the Installed Base Interface copies information about the new or renewed

service programs to the insta lled base.

When you need to terminate an active service program, you can use the Terminate Service

window. When you terminate a service program, Oracle Service automatically uses theReceiveables Interface to create credit memos in Oracle Receiveables.

8/7/2019 SERVWP


Oracle Service 11

Enter Orders

Order ImportRenewService

OrderService

Instal led Base

TerminateService

Invoices

BackOrders

Cance lOrders

Pick/ShipOrders

ReceivablesInterface

OracleOrderEntry

OracleService

Oracle

Received

Instal led BaseInterface

(See next Figure)

Installed Base Integration

The following figure shows the Installed Base Interface in more detail. This interface consists of

three concurrent programs which work together to populate and update the installed base.Concurrent programs are background processes that ru n on a schedu led basis, perh aps hou rly or

nightly as determined by your system administrator.

8/7/2019 SERVWP



Book

Orders

CancelOrders

InstalledBase

Service

Interface

AutoCreateInstalled Base

Update

Shipping

Pick/ShipOrders

Installed Base Interface

Installed Base Interface

After you enter, book, and ship sales orders, the Service Interface concurrent program and the

Update Shipping Information concurrent program send order and shipment data to an Installed

Base Interface table. The Au toCreate Installed Base concurrent program processes the ord er d ata

in the interface table to create new customer products, service programs, and warranties in theinstalled base. As the AutoCreate Installed Base program finds shipping information in the

interface table, it updates the customer product records with the ship date, serial numbers, and

revision numbers. If you subsequently cancel a sales order that has already been processed bythe Installed Base Interface, the Cancel Orders screen in Oracle Order Entry sends the

cancellation data to t he interface table. The AutoCreate Installed Base program then u pd ates the

customer p rod uct (i.e. sets the customer p rodu ct status to canceled) in the installed base.

8/7/2019 SERVWP


Oracle Service 13

Customer Product

The customer product, which is an instance of a specific product that you have sold to a

customer, is the heart of the Oracle Service installed base. Each customer product record holds

information about the customer (addresses and contacts), the product sold (quantities, serial

number, revision), the sales order (order number, order date, selling price, agreement), theshipment (shipment da te), and the installation (installation da te).

Business Needs

With Oracle Service you can create customer p rodu ct records by:

· Capturing customer ord er lines autom atically du ring order processing in Oracle Order Entry

· Defining customer p rodu cts manua lly using the Define Customer Produ cts screen in Oracle

Service

Customer Product Types

You can optionally categorize customer products with user-defined customer product types. Forexample, you can create and assign customer product types such as Hardware, Software, UnderContract, etc. Note that customer prod uct types are informat ional only.

You can use customer product statuses to indicate the current state and transactability of a

customer product. For example, customer products generated by new customer orders are

autom atically assigned a cu stomer pr odu ct status of Latest. Defective customer p rodu cts that are

returned and replaced are assigned a status of Replaced in the Oracle Service Depot Repairmod ule. When you cancel order lines in Oracle Ord er Entry, the related custom er prod ucts in theinstalled base are automatically assigned a status of Canceled. When you sell a new product

upgrade in Oracle Order Entry, the customer product to be upgraded is automatically assigned astatus of Upgraded. You can assign a status of "Terminated" for customer products that are no

longer active or supported. In addition to these predefined statuses, you can define your own.

Each of these statuses have attributes that define the manner in which they affect the customer

product.

Customer Product Transfers

If you sell to distributors or dealers, you can transfer customer products from the distributor to

an end customer as end customers identify themselves to your support organization. When youtransfer customer products, any warranties and service programs attached to transferred

customer prod ucts are passed along to the end customer.

8/7/2019 SERVWP



Customer Product Quantity Splits

Each customer product record contains the quantity sold. For serviceable products under serial

control, Oracle Service will automatically split the customer prod uct into qu antities of one. Each

new customer product created from the split carries the same attributes of the original customerproduct, but has a quantity of one and a unique serial number. You can also manually split

customer p rodu cts. Reasons for splitting customer prod uct quantities could be:

· Isolating a quan tity for transfer to an end custom er

·

Setting apart a qu antity to terminate

· Setting apar t a quantity to app ly (order) a new service program

· Setting apart a qu antity to upgrad e or repair

Systems

You can optionally group customer p rodu cts into logical group ings called systems. For examp le,

you can group customer products like printers, monitors, and servers at a customer site into a

logical system. One reason to group customer p rodu cts in this way might be for cotermination of

service program end dates for all customer products in the group. Another reason might be thatthe system represents a place (a floor of a building, an airplane tail number, etc.) where all the

customer prod ucts in the group are located.

Customer Product Audit History

You can view the audit history of customer products, from the initial customer order, through

transfers, splits, add itions to systems, cancellations, and terminat ions. Oracle Service maintainsan au dit trail of changes, including who mad e the change and wh en.

8/7/2019 SERVWP


Oracle Service 15

Support Services

Sup port Services enable your custom ers to make better u se of the produ cts you sell. Using Oracle

Service you can create service programs and warranties that represent the various support

services that you w ant to provide your custom ers.

Service programs are billable support services that help you meet your customers' diverse

support needs. For example, service programs can represent extended warranties or agreementsto provide telephone support. When purchased by customers, these service programs can beattached to serviceable produ cts, wh ich lets you d efine the service entitlement of your customers

for that product.

A warranty that is attached to a serviceable product is applied automatically when you sell that

prod uct. The price of the warr anty is assumed to be incorporated in the prod uct price.

Support Services

Business Needs

With Oracle Service you can:

· Create Service programs and warranties that represent your various sup port services

· Create, maintain, and ad minister as many service programs as you need

· Provide targeted sup port based on prod uct characteristics

· Provide multiple service programs to support the same product

· Allow customers to purchase multiple service program s for the same prod uct

· Flexibly price your service programs using p rice lists in Oracle Order Entry

· Easily renew or term inate your service program s

8/7/2019 SERVWP



Major Features

Flexible Service Programs

With Oracle Service you can create, maintain, and administer as many service programs as are

necessary to meet the service needs and price expectations of each market segment that youservice. Service Programs can be used to sup port you r customers in the following w ays:

· Provide targeted sup port based on prod uct characteristics

For examp le: to supp ort a low priced, high volume produ ct you can define a service programfor hotline sup port. To sup port a m ore complex, higher priced pr odu ct you can define a

service program for on-site supp ort.

· Provide multiple service programs to support the same product

For example: a customer w ho uses your prod uct for critical app lications can pur chase a

service program that ensu res supp ort 24 hours a d ay, 7 days a w eek while a customer who

uses the prod uct for less critical app lications can p urchase a service program that limitssupp ort to weekdays.

· Allow customers to purchase multiple service programs for the same prod uct

For example: one service program may not satisfy all of a customer's n eeds, so a customercan pu rchase multiple service programs for the same prod uct. If your customer w ants both

hotline supp ort and regular preventive maintenan ce, you can define two different service

programs that can be attached to the same customer pr oduct.

Defining service programs that support each market segment's unique needs lets you meet the

expectations of all your customers. For example, in Oracle Order Entry, you can price eachservice program to achieve the market penetration and volume that you need to sustain and

grow your service organization or your bu siness.

Service programs also let you design mass customization solutions. You can provide service

solutions that not only satisfy customers but also help you retain and generate additionalbusiness. To ensure better administration, you can control the availability of your service

programs by product, by customer, or a combination of both. To simplify the management of

service programs, you can coterminate a group of service program s at the same t ime, so that they

can be renewed at the sam e time.

Oracle Service enables you to track the status of each service program purchased by a customer

regard less of the time of its pu rchase. Custom ers can order service program s at the sam e time as

a product order, or later when the customer requires support. You can also identify expiring

service program s and notify your customers, which prevents a break in the sup port services theyreceive.

Included Warranties

Included warranties allow you to automatically associate a support service with a product. You

can define an includ ed warran ty as a component in the bill of material for a serviceable prod uct.The warranty record is automatically associated with the customer product in the installed base

upon ordering and shipment of the product to the customer. Just like service programs,

8/7/2019 SERVWP


Oracle Service 17

warranties are defined by the hours of coverage provided and the scope of the service coverage

in terms of material, labor, and expense.

Each serviceable product can be shipped with one or more base warranties defined as

compon ents in the produ ct's bill of material.

Activating Service

Oracle Service offers several ways to activate or start th e su pp ort services your customers receivefor your product. During order entry, you can specify service start and end dates, or you canspecify the start dates only, then let Oracle Order Entry determine the end dates from service

duration information.

You can define the Service Starting Delay when you define serviceable products in Oracle

Inventory. The Service Starting Delay represents the tim e in days a service program or warran ty

is offset to commence after the shipm ent d ate. For examp le: a radio has a service starting delay of five days. If the radio ships on January 15, five days are added to the shipment date and theservice program starts on January 20. The start date of the warranty is the ship date + starting

delay. The end d ate is calculated by add ing the du ration to the start date of the supp ort service.

Service Coverage

Service coverages list the actual days during the week and hours during the day when your

customers may request service. When you define a service coverage you also determine what

percentage of labor, material, and expenses is covered, and whether a maximum limit exists foreach. You can d efine as m any coverages as you need, then associate each with a service program

or a warranty. Because your service personnel have on-line access to your customers' service

information, they can verify whether customers are contacting them at authorized times, orwh ether material, labor, and expenses are covered by a su pp ort service.

Service Coverage

8/7/2019 SERVWP



Controlled Service Availability

By default, a service program is eligible to service any product. You can limit the availability of a

service program by p rodu ct, customer, or both. You can a lso exclude th e app lication of a service

program to a specific prod uct, customer, or a combination of both.

You can also control the availability of a warranty to a specific serviceable product. By default, a

serviceable product does not include a warranty unless you specified the warranty as a

compon ent in the serv iceable prod uct's bill of material.

Service Program Pricing

You can flexibly price your service programs using price lists in Oracle Order Entry. You can

assign fixed or variable amoun ts to each of your service programs. Fixed p rices are expressed as

actual prices on the price list, whereas v ariable prices are expressed as p ercentage to be ap plied

to the price of the serviceable prod uct. When you enter sales ord ers in Oracle Order Entry for theservice programs your customers want for their prod ucts, Ord er Entry references the app ropriate

price list to find or dynamically calculate the price of your ordered service programs. You can

then adjust the determ ined price by applying discounts.

Ordering Service Programs

As you enter sales ord ers for serviceable prod ucts, you can select one or m ore service programs

to cover each serviceable product. The serviceable product and its service program(s) will then

be on the same sales order and the same invoice.

You can also sell service programs after the sale of the serviceable product. For example: you sell

a telephone with an included warranty that expires after 90 days. After 90 days, your customer

decides to purchase extended service coverage for the teleph one. You can th en sell the extend edcoverage as a service program three mon ths after the original sale.

Regardless of how you start your service order, you can choose from a variety of order

processing options, including dynamically calculated service prices, price adjustments, salescredits, and ap proval cycles that you can app ly to the entire order or sp ecific order lines.

Renewing Service Programs

You can renew your service programs before they expire. The Expiring Services Report lists

service programs and warranties that are due to expire, by customer. To renew service, you can

use the Renew Service Programs window to select the service programs, by customer, that youwant to renew. By default, your sales orders are created in Oracle Order Entry for service

program r enewals.

Terminating Service Programs

When you want to terminate a service program, you can use the Terminate Service Programs

window to select and terminate specific service programs, by customer. By default, credits are

calculated by prorating the days remaining in the service program duration. You can optionallycreate credit memos, automatically, via the interface with Oracle Receivables, for the proratedcredit am ount.

8/7/2019 SERVWP


Oracle Service 19

Automatic Service Program Billing

You can automatically invoice or credit your customers, as appropriate, for service programs

they purchase, renew, or terminate. Oracle Service uses Oracle Receivables, via the Receivables

Interface, to create invoices for service programs on sales orders, or to create credit memos for

service programs that you terminate. Using Oracle Receivables invoicing rules, you can bill inad vance or in arrears.

Service Transaction History

On-line inquiries show detailed information about the products your customers have and the

support services they have recorded against each product in addition to the history of alltransactions relating to the support services. You can use this information to search for and

analyze trends for the way your customers order and use support services, including which

services they renew most often, which services they terminate most often, the average length of time they order service programs for, and to which products they rarely (or frequently) apply

service program s.

You can view th e tran saction history of the following:

·

Any service program or warranty

· A particular service program or warranty

· All supp ort services for a par ticular produ ct

· All supp ort services for a p articular customer

· When a customer pu rchased a service program for a given prod uct

· When a customer renewed or terminated a service program

· How mu ch a custom er was charged for a service program or ren ewal of a service program

· When service programs or war ranties for a particular customer are du e to expire

Transaction History

8/7/2019 SERVWP



Cotermination

Oracle Service enables you to specify a single end date for all the service programs for a specific

customer or system so that service programs for the customer or system will have the same end

date.

The cotermination date is hierarchical, first checking for a system cotermination date, then if

none is found, it defaults to the customer cotermination date. If neither a system nor customer

cotermination date has been set, the service program end d ate is the default.

Suppose you set a cotermination date at the system level of October 31, and a customer

cotermination d ate set at December 1. Service programs first check for th e system coterm ination

date and set the end dates to October 31. If no date had been set at the system level, when thesystem was defined, the customer level cotermination date is used. Another customer has fivesystems, each with a d ifferent coterm ination date. For each system, the ind ividu al cotermination

date becomes the cotermination date for that system only. In turn, if the system had not been

assigned a cotermination date, the customer cotermination date wou ld be used.

A customer is notified late in December that the current service programs covering their power

generators will be replaced on December 1 of the following year with a more comprehensiveservice program, and the current service program will not longer be valid. A cotermination date

is set at the customer level of November 30. The same customer renews a current serviceprogram in January for an existing power generator. In March, the customer orders three morepower generators and service programs for other sites. All service programs are checked for

cotermination. All four service programs w ill coterm ination on Nov ember 30, so the new service

programs can start on December 1.

If a service program is ordered, and there is no cotermination date set at either the customer or

system level, and the Coterminate checkbox has been checked when ordering the service

program, the cotermination da te for each service progra m is the service start date minus one day

plus one year. For example, if a service start date is June 26, 1996, the cotermination date is June

25, 1997.

Any service programs applied to customer products use the current cotermination date at either

the system level or the customer level. If you sh ould change either cotermination date, customer

or system, services ordered after the change use the new cotermination date. For example, if acustomer level cotermination date is August 31, and five service programs are ordered for

customer products in February, the cotermination date is August 31. If the date is then changed

to July 31, and new service programs are ordered, the cotermination date for the existing fiveservice programs is August 31, but the cotermination date for the new service programs is July

31. All subsequen t new service programs h ave the cotermination d ate of July 31 unt il the date ischanged.

You can also define a cotermination lag in days w ith the Service: Minimum Service Dur ation

profile option. For example, you have a cotermination day and month of December 31, and a

cotermination lag of 30 days. All services ending on or before December 1 (December 31 - 30

days) coterminate on December 31 of the current year and services ending after December 1coterminate on December 31 of the following year.

8/7/2019 SERVWP


Oracle Service 21

Service Requests

Most service calls begin with a telephone call from a customer who is experiencing difficulties

either using the product, understanding the product, or with the functioning of the product. The

Oracle Service Service Requests m odu le categorizes each customer request for service into user

definable service request types such as product complaints, field failures, or product inquiries.Service Requests are not limited to the functioning customer products, as you can log requests

for clarification of documentation, resolution of implementation issues, and product upgrade

information.

A service request describes all the necessary information about the customer problem to

determine the best plan of action to effectively resolve the issue. The installed base contains

information about the customer, customer site, and the installed customer product. With directlinkages to th e installed base, you are able to verify customer and produ ct information. You can

verify the curren t service coverage for a customer produ ct or system. If the customer is unknow n

to the installed base all the inform ation can be collected in a non-verify mod e and then v erifiedlater.

While logging service requests you can assign an urgency and severity status for each service

request. An urgency reflects the service request from the caller's view of the event while the

severity reflects the service person's interp retation of the event. Setting these attr ibutes allows atimely resolution for each service request.

In the Service Request setup windows you can fully define your service requests with Type,

Status, Urgency, Severity, Problem, and Resolution codes. Each code serves to refine the

definition of the service request and aid s in problem trend analysis and resolution.

Service requests can have an unlimited number of actions to represent what has been done to

resolve the service request. For each action you can assign an owner, a status, a user-defined

action type, start and end dates and times, and free form text describing the problem and theresolution.

You can link related service requests. For examp le, if two or m ore problems w ere reported in thesame custom er call, you could create two service requests and link th em together.

As you change information abou t service requests and actions, Oracle Service maintains an aud it

history of the changes. For example, if you change the status of a service request from Open:

unassigned to Open: assigned, Oracle Service records the old and new status values, as well asthe user who m ade the change and the d ate.

The Service Request mod ule is integrated with th e Return Material Author ization (RMA) modu le

in Oracle Order Entry. You can indicate that a particular service request involves a return, then

access the Enter RMA window directly from the Service Requests window. The RMA that you

create will be linked to the service request.

Business Needs

With Oracle Service you can:

· Record cu stomer information qu ickly

· Define the customer's requ est for service

· Define service request status, type, priority, and u rgency

8/7/2019 SERVWP



· Verify service programs or w arran ties on line

· Confirm customer information; nam e, number service coverage, prod uct, system, or serial

number

· Provide an aud it trail of service request changes

· Assign problem and resolution codes to each service request

· Define service request and prod uct linkage

· Display each service request in summ ary or detail form at

· Link service requests

Major Features

Caller Identification

Customers reporting a service request hav e several ways to iden tify themselves: customer name,

number, contact name, or product serial number. Based upon this identification you can

determ ine the app ropr iate validation of customer produ cts, service program s, or warranties.

While entering a service request, if you select Verify Request, then the customer and contact

name you enter must exist in the shared customer and contact master. If you haven't yet definedthe customer (for example, you sell to a distributor who in turn sells to the end customer), thenyou can select Do Not Verify Request and enter a new customer name and address. Later, after

you add the new customer name and add ress to the customer master, you can change the servicerequest to Verify Request. Optionally, using Oracle Alert, you could create an alert to

autom atically add the new customer information to the custom er master.

Service Requests (Customer Region)

8/7/2019 SERVWP


Oracle Service 23

Product Identification

You can optionally enter product information for each service request. If you wish to enter

product information, you have the option of selecting any product defined in your Oracle

Inventory item m aster or selecting a customer prod uct from the Oracle Service installed base. If

you wish to select a customer product from the installed base, you can search for customerproducts based on any known attributes such as serial number, order number, customer P.O.,

customer nam e, etc.

Service Requests (Product Services Region)

On-line Service Verification

You can verify service program and warranty coverage as you process requests for customer

service. You can check to verify that appropriate service programs or warranties are in place tocover the service request, or suggest other service programs based upon established policies and

procedures.

Setting up Service Requests

You can define any number of service request types, statuses, urgency codes, severity codes,

problem cod es, or resolution codes.

8/7/2019 SERVWP



Service Request and Action Types

You can define service request and action types to categorize your service requests and action .Following are some examp les of service request t ypes that you can create:

· Request for Information

· Customer Compliant

· Defective Prod uct

· Installation Request

· Preventive Maintenance Visit

· Hot Site

· Bug

Action types define the kind s of actions you can take for all or specific service requ est types. You

can relate specific action types to a particular service request type. Then, as your customer

service personnel process service requests of a given type, they can choose related action types.

Following is an examp le of a service request typ e and related action types that you can create:

Service Request Type: Complaint

Related Action Types:

Assignment

Analysis

Customer Callback

Resolution

Service Request and Action Statuses

You can define service request statuses to indicate the current state of reported service requests

and the actions assigned to them. The service request captures the current state of the service

request, whereas action statuses reflect the current state of each of the actions related to theservice request. For example, a customer calls to report a broken switch on his personal

computer. You could set the service request status to Open and then create an action with the

status Assigned to indicate that the service request has been assigned to a field engineer.Optionally, you could create statuses like Open: unassigned to reflect both the state and

condition of the service requ est.

8/7/2019 SERVWP


Oracle Service 25

You can relate specific statuses to a particular service request or action type. Following is an

examp le of action typ es and related statu ses.

Action Types Related Statuses

Assignment Assigned

Analysis In Process, Done

Customer Callback Engineer Called, Customer Called

Resolution Closed

Service Request and Action Severities and Urgencies

You can define a service requ est's severity and thereby set th e priority. Low, Medium , and H igh

are examples of severities. The service request severity can be app lied to either a service requestor an action. A service request urgency reflects the caller's perception of the reported service

requ est. Low, Medium, and High are examples of urgencies.

Problem and Resolution Codes

A problem code gives meaning to the service request described by the caller. Problem codesisolate the detailed r eason for the call.

A resolution code gives meaning to the r esolution of the service request described by the caller.

Resolution codes isolate the d etailed solution for th e call.

Service Request Defaults

Service Request default values, specified by user, help you enter service requests quickly. You

can set user profiles to d efault the following values as you enter service requests:

· Service Request Type

· Service Request Own er

· Severity

· Urgency

· Action Assignee

· Action Type

· Action Severity

You can overrid e these d efaults if necessary.

8/7/2019 SERVWP


8/7/2019 SERVWP


Oracle Service 27

Depot Repair

Depot Repair manages the repair of damaged products returned by customers. It tracks the

repair process from the time products are received in inventory to the point they are shipped

back to the customer after repair. During this process, you can verify support service coverage

for the damaged product, diagnose the problem with the product, estimate the cost of repair tothe customer, obtain customer approval for the pr ice of repair and d efine repa ir jobs in Work in

Process (WIP) to resolve the problem. At the end of the repair process, you can create a repair

ord er detailing the charges to the customer for the repair.

CustomerCustomerWarehouseWarehouse

RepairRepair

DiagnosisDiagnosis

Estimate Estimate

RepairRepair

DamagedDamaged

ProductProduct

RepairedRepaired

ProductProduct

Sales Sales

Order Order

Estimate Estimate

Details Details

Estimate Estimate

Details Details

Depot Repair Function

Since different companies have different business rules governing this function, Oracle Service

allows you to configure the Depot Repair process to suit each business' needs. For example, a

company that repairs televisions, and relies on individual technicians to diagnose and repair

televisions, can enable the creation of a sales order after a repair has been diagnosed. In thissituation, the company may not create a WIP job for each repair. Another company that repairs

automobiles may wish to allow the creation of a sales order for repair work only after the repair

job has been completed in WIP and the exact price to be charged to the customer is known . Youcan setup Depot Repair to allow Sales Order creation only after the repair job has been

completed. Until then, the technicians are free to change their estimate for rep air costs.

8/7/2019 SERVWP



Depot Repair is tightly integrated with other Oracle Applications. Return Material

Authorizations (RMA) are created in Order Entry. Damaged Products are received by OracleInventory and, once repaired, are shipped back to the customer from Oracle Inventory. Repair

jobs are created and processed in Oracle Work in Process. Sales Orders for r epairs ar e created byOracle Service in Oracle Order Entry and then interfaced to Oracle Receivables for further

processing. Depot Repair enables you to easily manage this complex process. It provides you

with a consolidated, and current view of all products returned for repair enabling you toaccurately answer your custom er's queries. For any rep air line, you can find its latest statu s, date

it was received, the diagnosis, the status of the repair job associated with that line, the support

services associated with the line, estimated repair price, sales order number, and whether theprod uct has been shipped back to the customer or not.

Depot Repair ut ilizes the installed base to determ ine the Supp ort Services covering the retu rned

customer produ ct. If the produ ct is und er serial num ber control, Depot Repair will autom aticallylink the p rodu ct to the correspond ing record in the installed base allowing you to easily view the

sup port services covering the retur ned prod uct. If not, Depot Repair w ill facilitate the d efinitionof a link between the returned product and the corresponding customer product in the installed

base. Even if the product being returned by the customer does not exist in the installed base,Depot Repair still allows you to process the repa ir line. In this case, the informat ion stored in t he

installed base like Service Programs associated with customer products is not available.

Therefore, even if your installed base is not curr ent, you can still use Dep ot Repair to streamlineyour rep air process.

Often, the damaged product returned by the customer is not repairable or a replacement is

needed immediately. Depot Repair will enable you to ship a replacement for the damaged

product whenever you wish. You can control the amount billed for the replacement. You may

also decide to repair the returned product. If you ship a replacement before the damagedproduct is received in Inventory, Depot Repair will even allow you to link the advance

replacement sales order to the repair line in Depot after the damaged product is received in

Inventory.

8/7/2019 SERVWP


Oracle Service 29

Receive Customer Returns (INV)

Create Sales Order, Ship Item(CS, OE)

Repair and Return Replacements

Diagnose and estimate repair (CS)

Customer reports Incident (CS)

Enter RMA (OE)

Get Customer Approval (CS)

Close Repair (OE,CS)

Submit non-standard job (WIP)

Complete WIP transactions (WIP)

Close WIP job (WIP)

Replacement (CS)Replacement (CS)

Issue item to job (WIP)

Depot Repair Process Flow

8/7/2019 SERVWP



Receiving Damaged Products

Return Material Authorizations (RMA)

The repair process may begin with a customer calling the support center with a problem. If you

create a Return Material Author ization (RMA) throu gh th e "Enter Service Request" form, DepotRepair will be able to link each repair line to a RMA as well as a Service Request. A person

diagnosing the problem with the returned p roduct can then view all the symptoms reported bythe client, various actions taken to resolve those symptoms, and the service solutions alreadyattempted. Information such as the customer, etc., is defaulted into the RMA form to avoid

du plicate data entry. In the "Enter RMA" form, each RMA line th at rep resents prod ucts retur nedfor repair should be marked accordingly. This enables the Depot Repair control concurrent

progr am to bring only those produ cts that are to be repaired throu gh Depot Repair.

Once an RMA is fully received, you can view all RMA lines as repair lines in the "Repairs" form

in Depot Repair. The concurren t program, Depot Repair Control, automatically pop ulates Depot

Repair when ever a RMA is fully received in Inventory.

Depot Repair Control

Depot Repair Control, a concurrent program, automatically populates Depot Repair whenever a

RMA is fully received in Inventory. The Depot Repair Control concurrent pr ogram creates repairdata based on RMA receipts. All RMA lines designated as "Repair" lines are eligible. While

creating repair lines, RMA lines for serialized items with a quantity greater than one areautomatically split into multiple lines of quantity one, each with a unique serial number. If the

customer product in the installed base can be identified with the repair line, the program also

links the customer product to the repair line automatically. For non-serialized items, customer

product information is not captured by the concurrent program, but a customer product can belinked to a rep air in the Repairs form.

The Depot Repair Control also updates the status of repair lines whose jobs are closed in WIP,

and closes repair lines that hav e been shipped back to the customer.

8/7/2019 SERVWP


Oracle Service 31

Processing Damaged Products

The Repairs window is used to inquire the status of a returned prod uct, split repair lines, link a

repair line to a customer product in the installed base, capture repair diagnosis, estimate, and

approval information.

Repairs Window

The Repair Jobs wind ow is used to subm it nonstand ard rep air jobs to Oracle Work in Process.

The Repair Orders window is used to create sales orders for replacements and repair orders forrepaired produ cts.

Flexible Repair Process

Depot Repair allows users to flexibly define the minimum status (diagnosed, estimated, or

estimate approved) of repair lines required to create a nonstandard WIP job. For example, if repairs can be started as soon as the problem is diagnosed, this profile option should be set

accordingly, and all repairs that have been diagnosed will be allowed to go into WIP.

Alternately, if the estimate for repairs has to be approved by the customer before repairs canbegin, then by setting the profile option accord ingly, only those repa irs that have estimate

approval from the customer will be allowed to go into WIP. Repairs that do not have estimate

approval from the customer are automatically excluded from being selected to be processed inWIP.

Diagnosis

For every repair line, Depot Repair allows you to select a diagnosis code. You can use this

diagnosis code to determine the material and resource requirements for repairing the product.You m ay also use this code to determ ine the most frequent p roblems with various pr odu cts.

8/7/2019 SERVWP



Repair Estimate

Based on your d iagnosis, you can estimate th e cost of repair to the customer. Your estimate can

include time, material, and expenses that will be incurred by you in repairing the product. You

can use customized price lists to vary repair pr ices by customers, or produ ct lines. If the prod uctis covered by a warranty or service program, you can optionally apply that support service to

discount the estimate by the amount covered by the support service. You can change the repair

estimate even after the repair has commenced so that even unforeseen expenses can be charged

to the custom er.

Estimate Window

Customer Approval

Once you have created an estimate, you can ask your customer to approve the estimate. If the

customer agrees with the estimate, a valid contact for that customer has to approve it.Alternatively, the customer contact may reject the estimate. In this situations, you can either

return the product to the customer or ship a replacement by creating a sales order to ship theproduct or replacement back to the customer. The charges in the estimate will default into thesales order enabling you to charge for services like diagnosis that have alread y been rend ered.

Replacement

If the Damaged Product cannot be repaired or the customer needs a replacement product

immediately, Depot Repair allows you to send a replacement to the customer, and optionallytrack the damaged product through the repair process. Once the item is shipped, the original

customer product in the installed base gets a Replaced status, and a new Customer Product for

the rep lacement is created with a Latest status.

You can also send a replacement before the customer returns the item, and optionally track the

returned item through the repair process. For advance replacements, information about the salesord er that was u sed to ship the replacement can be entered in Depot Repair.

8/7/2019 SERVWP


Repair Job

You can optionally use Oracle Work in Process to track material and resources used in repairing

the damaged products. Depot Repair will create a nonstandard repair job in Work in Process for

this purpose. Depot Repair enables you to group repair lines for the same product returned by

different customers into one rep air job. You can pass the job nam e repair comp letion d ate as w ellas the repair routing to Work in Process. Depot Repair enables you to view the current status of

the repair job. Depot Repair Control updates the repair line status once the repair job has been

completed in Work in Process.

Repair Order

After a product has been repaired, or its estimate rejected, it can be shipped to the customer

using a Repair Order. Depot Repair creates the repair orders in Order Entry using Order Import.

Lines from on e RMA can be selectively chosen and group ed into a single sales order. In add itionto the repa ired item, each line in the estimate d etails becomes a sales ord er line. The sales order

goes through the cycle determined by the order type. Other features such as accounting rules,

invoicing ru les, etc. can also be used.

Order Type

Order types determine the processing flow of the repair orders created by you. The sales order

goes through the order cycle determined by the order type. The order type also determinesaccounting ru les, invoicing ru les, price list, etc.

While creating sales ord ers for Repairs and Returns it is recommend ed to use an Ord er Type that

does not have Service Interface as a cycle step. This is to ensure that th e installed base does n ot

get updated with incorrect information. For Replacements, it is recommended to use an Order

Type with Service Interface as a cycle step because replacements are automatically updated in

the installed base if a customer produ ct is linked w ith the rep air. Separate Pr ofile options may beset to default order typ es for Repair and Return and Replacement sales orders.

Splitting Repair Lines

For products not under serial number control, each repair line brought into Depot Repair has a

quan tity equal to the nu mber of prod ucts received against th e correspon ding RMA line in Oracle

Inventory. However, each product that is returned may require individual processing. For

example, a split may enable you to link a repairs line to a customer product from the installed

base. A split may also be useful in creating multiple jobs for the same RMA line if the repairdiagnoses for different produ cts are different. Therefore Depot Repair allows you to split a rep air

record into two user-defined qu antities or into multiple lines of quan tity one each.

Returned products that are under serial control are automatically split into multiple repair lines

each with a quantity of one. Hence, they cannot be sp lit further.

Date post:	09-Apr-2018
Category:	Documents
Upload:	sa-ra
View:	214 times
Download:	0 times

SERVWP

Documents