Sap cs standard process document

Standard Business Processes in SAP Customer Service

Configured & Compiled By: Subhrajyoti Bhattacharjee, PMP®, Certified SAP ® EAM, Certified ITIL® E-Mail: [email protected], Location: Perth, Western Australia

1.0 Business Background:

SAP Customer Services is a highly integrated process module which involves a strong integration of

SAP PM (Plant Maintenance), SAP SD (Sales & Distribution), SAP MM (Materials Management), SAP

FI-CO (Finance & Controlling modules) and other SAP Logistics modules like SAP PS, SAP LE etc.

The scenarios supported in this module include Pre-sales scenario for services, Sales scenario for

Services/Spares, Post Sales (Actual Service delivery) scenarios, Special scenarios such as Warranty

Claim processing, Intercompany scenarios, Use of Configurable Services etc.

The scenarios are most apt for Organizations that are heavily into Service sales such as Consulting

organizations <or> Organizations offering support post sale of products, for example Automobile

companies, Industrial Equipment manufacturers, Consumer Durables manufacturers and so on.

2.0 Inclusions & Exclusions in this document:

Given the fact that scenarios within SAP CS can get very complex with highly integrated configurations,

and various levels of permutations and combinations of transactional objects, in this document I have

tried to include at least the Baseline scenarios and provide a brief insight on other possible complexities.

Special scenarios like Warranty Claim processing have not been dealt with in this document as that’s a

separate sub-module altogether which probably should get elaborated in a separate document.

However, simple usage of basic Master warranties has been mentioned in this document.

Configuration aspects have been touched in certain scenarios briefly, wherever the criticality of the

same has been felt necessary. It is to be noted that, same scenarios can be configured or presented in

a different way by different consultants. Hence generalization of the same may not always be possible.

However an effort has been made in presenting processed in closest match to SAP recommended

standards.

3.0 Brief insight into SAP CS Master Data/ Transactional Objects

3.1 Some essential Data Objects

Technical Objects: Customer side Technical objects can be Customer Functional Location, Customer

Equipment and in complex system installations an Installed Base which is a hierarchical representation

of the Technical Objects installed at Customer site.

Mostly we use Customer Equipments as the basic object on which service processing is carried out.

SAP comes with a standard Equipment category “S” whose view profile/business profile is to be

configured in such a way that it includes Service relevant screen sections such as Partners, Warranty,

Structure, Sales and Distribution data, Serialization data section etc. Usually these Equipments are

Serialized Equipments i.e they are a culmination of a Material ID + Unique Serial No. Also, there would

be a Bill of Material of such Equipments clearly highlighting the Spare parts, Assemblies which

constitute the Customer Equipment. A screen snapshot of a Customer Equipment as below.



For Serialization of a Material and subsequent creation of an Equipment view for the Material, a Serial

No. profile should have been configured in SAP and should have been assigned to the Material Master

under Plant data/ stor. 2 view



Transaction <IQ08> is a display list report showing Customer -> Equipment -> Mat No -> Serial No

mapping. You can add further fields to the Output variant.

Task List: This is particularly essential for planned/scheduled Maintenance services based on a

contract or say non-contractual work with standard Activities/Components/External services/PRTs

Transaction: <IA05/IA06/IA07> Create/Change/Display General Maintenance Task List – mostly used

<IA01/IA02/IA03> Create/Change/Display Equipment Task List

Service Products: A Service material (Type DIEN) that usually summarizes the Service work and forms

a line item of a Customer Service Sales Order or a Contract is also defined as a Service item at times.

This is particularly the case when in the Debit memo request generated from DIP processing during

RRB (Resource Related Billing), a first level summarization item is a Service Product with the actual

elements of cost like Material, Internal Labour etc grouped under it <or> To generate Service Orders

from Service Plans based on Service Contracts for periodic service .In the latter case, a Task List may

also be assigned to the same.



At first a Service Material of standard type “DIEN” is created in transaction <MM01/MMS1> and then a

Service Product for the Service Material is created in transaction <OISD>.

The Service Material should have its Sales views active, Sales Organizational assignment done, Item

Category group setting is critical for Sales document processing – Item category determination. Service

Material usually have LEIS Item category group. If the material is subject to Transfer of Requirement,

then a suitable Strategy Group must be set under MRP 3 view. This will be detailed later in the

document.

Transaction: <MM01 Create/MM02 Change/MM03 Display> Material



Transaction: <OISD> Define Service Product

3.1 Transactional Data Objects

Transactional Data Objects covering all the scenarios in this document would include:

- SD: Sales document: Quotation/Sales or Repair Service Order/Service Contract

- SD: Delivery Document

- SD: Billing document

- AR: Payment document

- PM/CS Notifications – Service Request/ Repair Request/ Problem Notification

- PM/CS Order – Pre-sales planning Order/ Unplanned or Planned Service Order/ Repair Service

Order

- Time confirmation documents

- Goods movement documents

These objects will be detailed along with some of their critical configuration aspects, under processes in

later sections of this document.

4.0 Business Processes

4.1 Pre-Sales scenario

Process Background: Customers who may be interested in entering into a Long term Service contract

or procuring short term Services would initially call the Customer Service representative and generate

an enquiry requesting for a Quotation. Customer Service representative can enter the details in SAP

using a CS Notification and allocate it to the respective person responsible to detail the work and



prepare the Quotation. The detailed planning is done on a Service Order and on completion of planning

the planned values are converted to Dynamic items which map to a SD Service Quotation document.

The Quotation is then sent to the customer who may accept or reject it. There may be 2 sub scenarios

here:

- Quotation is binding: Customer is billed at a price agreed in the Quotation on acceptance of the

same, once the services have been performed. In this case Billing form of Type “01” Fixed rate

should have been set in the Quotation -> Post Quotation acceptance, Service Order released and

costs accrued -> Billing is done at a Fixed agreed rate as per Quotation, even if there is deviation in

actual costs incurred.

- Non-Binding or Informative Quotation: Customer would be billed on actual work performed as

accrued in the Service Order once the Quotation is accepted and Service Order released. Billing

Form “02” – Costs would be used. In the scenario steps detailed below, we have used an

Informative Quotation only.

It is to be noted that once a Quotation is created from a Service Order, no further Contracts can be

referenced. System only allows 1 cost account assignment Quotation <-> Service Order

Configuration pre-requisites:

Configurations on SAP SD side and PM side are briefly detailed below, highlighting the most crucial

configuration aspects.

SAP SD: SPRO -> Sales and Distribution - Only the critical settings documented below

1. Sales Document Types for Quotation document and subsequent Order/Contract defined. In this

example, standard document type “AS” has been used for Quotation

2. Assigning Sales Area to Sales orders. We have assigned to “AS” relevant Sales area

3. Sales document items – Item categories “AGE” for “AS”.

4. Sales document items – Assign Item categories: As this is a critical config. Node, a mapping has

been detailed in screenshot below:

The Logic usually followed by the system is:

Sales doc type -> Item category group (derived from sales material master) -> Usage (The

usage SEIN is to be set for Billing relevant items for Dynamic processing) -> Higher level

item category (if sub items are to be there in Sales Order) -> Default item category ->

Manual item categories possible (Optional)

Doc type AS – Quotation settings



5. Reasons for Billing Block

6. Customer Service -> Service Quotation/RRB -> Profiles for Resource Related Billing/Quotation

Creation ***

The DIP profile “QT” configured in this step is the most crucial configuration as this would contain

the rules of converting planned items within the Service Order into Dynamic items to be placed into

Sales Quotation.

Usage – “Quotation creation and Sales pricing’ and mapped to Sales document type “AS”



Characteristics – Cost element (this can take care of all planned costs in fact), Product (Service

product at a higher summary level in Quotation, if required), Cost Center, Activity Type, Material,

Billing Form. All above characteristics, other than product marked “Characteristics relevant”,

“Material Determination”, “No Summarization”.

Anything set for Material determination will then be available in Material Determination configuration

section detailed later.

Sources – 0031 Planned Costs – Line item, 100%



Selection criteria; Cost elements have been primarily used as selection criteria for respective

sources of planned costs in this example.



Material Determination: Please note that all material used in Material determination should have been

created as material masters of Type “DIEN” – Item category group “LEIS”. The Basic, Sales views

should have been at least maintained, and in Costing 1 view tick “Material Origin”, “With Quantity

Structure”

For each Dynamic material to be selected in the DIP conversion, the Source selection criteria is then

set. We have used Cost elements as the basis of the same.



SAP PM: SPRO -> Plant Maintenance & Customer Service -> Maintenance Processing

1. Notification settings: Only the critical settings documented below

- Notification Type “IN” set as a General Service Notification. Standard Notification type S1 can

also be reused.

- Notification screen layout set for Notification type IN. A simple layout has been kept.



- Number range assigned to Notification Type IN

- Transaction start value of IW51 mapped to IN

- Assign Notification Type To Order Type ‘”SRIN” – configured for this process, detailed below

- Standard Partner Determination procedure “SV” assigned to IN

- Catalog profile “CS” configured and assigned to IN

2. Maintenance Order settings: Only the critical settings documented below

- Order Type “SRIN” has been configured as a Revenue Bearing. Service Order. Settlement

profile “90 - Not for settlement set”.



- Credit Limit Checks, Sales Document type for Service Order

Order type “SRIN” marked as a Service Order, linked to Sales Doc Type “AS” and assigned to

DIP profile “QT”

- Number range set for Order type SRIN

- Order type ‘SRIN” assigned to respective Maintenance Plant

- Assigning Costing Parameter “PM01” to Planned Var. Calculation only. This Order type is not for

Actuals processing.



- Partner Determination Profile “SV” set to SRIN

- Set Scheduling parameters for Order type SRIN

- Completion confirmation parameter setting should not be required as this Order type is not for

actuals posting.

- Value category setting for user component PM: As Service Order here is cost and revenue

bearing value categories must include components of both Cost and Revenue nature and must

have been allocated to suitable Cost elements/ Cost element groups

SPRO -> PM&CS -> Maintenance & service processing -> Basic settings -> Settings for display

of cost -> Maintain value categories/Assign Cost Elements to Value Categories



- Assign Cost Condition for Sales Document Type:

SPRO -> PM&CS -> Maintenance & service processing -> Basic settings -> Quotation creation

and Billing for Service Orders -> Assign Conditions for Sales Document types

EK01 has been assigned to “AS”

Process Steps:

1. Inquiry Notification “IN” is created by Customer Service Representative on receiving

Customer call/communication. If Customer is not an existing customer, Customer ID is

created first as Sold to/Ship to party has been kept mandatory entries. Based on business to

business, it may not be mandatory as well. Also Notification can be configured more

elaborately to capture more detailed information.



Transaction code: <IW51> Create Service Notification (General)

Notification “…..” saved

2. Service Order of type “SRIN” is created by allocated department/personnel for detailed

cost planning. The Service Order is created with reference to the Notification created in Step

1 and further planned by the relevant team/personnel with projected hourly charges, material

requirements etc.



Transaction: <IW52> Change Service Notification – Individual, <IW58> Change List

Enter the Notification Number in initial screen

A Service Product (Service Material configured as a Service Product in transaction OISD) added to

summarize the items (Optional), Operations are planned, Material parts are planned, External services if

any are planned and so on.





Click on the Calculator icon to execute the Planned Costs calculation. It will be automatically calculated

when the Order is saved. DONOT release the Order

Planned costs can be copied to estimated costs of Order



Save the Order

Order “…..” saved with notification “……”

3. Quotation is generated through Dynamic Item processing of Service Order items. Using

Sales Pricing

Transaction: <DP80> Create Quotation



Check the Sales Price view. You would notice that the Service Product D100 is the header item under

which the other Dynamic items have been summarized. This is due to relevant DIP setting for Usage

Characteristics “Product” and setting a Product in Service Order (which is optional)

Click on Create Quotation …”Do you really want to create Quotation?” …Yes



Check the Quotation items, pricing conditions, Validity, Terms of payment etc., update them if required,

and save the Quotation.

Check in Document flow of Service Order (Transaction <IW32>) -> Pre-processing document

“Notification” and Post-processing document “Quotation’ will be displayed



Quotation is then Faxed/mailed/printed-posted to Customer for review

4. Quotation is either Accepted or Rejected by Customer

If it is rejected items are blocked/marked with a rejection reason. You can also delete the document

through path “Sales document -> Delete” but this may be avoided for future tracking purpose.

Transaction: <VA22> Change Quotation



If Quotation is accepted (no item rejected in Quotation), Service Order is released and costs are posted

to it.

As long as the Service Order has the system status QUCR – Quotation Created <and/or> a User status

that prevents release of the Order, it cannot be processed further. Transaction <IW32>

The Quotation has to be accepted to change the system status of the Service Order. Pre-requisite for

the same is that a Billing request should have been linked with the Quotation.

<VA01> Create a Billing Request w.r.t. Quotation – “DR” for the quotation with the top level Service

item. Not all costs may be chargeable at Quotation stage. It may just be a statistical document to

process the Service Order further.



Put in a Billing Block if the Dummy “DR” is not to be billed further.



Save the Debit Memo Request



5. Check the Document Flow in Service Order and Check System status

Transaction: <IW32>

You would also Notice that the system status would have changed to QUAC (Quotation Accepted)



The Service Order can now be released, and actual expenses (if any) incurred during the Quotation

submission process is posted to the Service Order and billed through the linked Debit Memo Request.

Usually, Service providers would not be charging customers for providing a Quote. So the process just

ends there, with simple booking of hours spent on preparing the Quote, and closing off the Service

Order.

Transaction code <IW41> For Time booking (without the Activity type if costs are not to be charged to

the Customer further)

6. Technically complete the Service Order

Transaction: <IW32>



4.2 Sales Scenario

Process Background: Sales scenario in Customer Service could refer to the following:

- Normal sale of a Product (say a Laptop or Industrial machinery) to the Customer – with/without

Delivery. This is a standard SD process and just a brief of it will be detailed in Process detail

section below.

Without delivery scenario could be a Customer visiting a retail showroom and buying a Laptop,

where he/she collects the Laptop, accessories, Guarantee cards etc. on payment of Net due.

With delivery scenario could refer to a delivery from the Product Company to the premises of the

customer followed by subsequent billing. Delivery charges may or may not apply based on

Customer location w.r.t. Sales warehouse or as per product sales norms etc.

This process would not be detailed elaborately (with configurations) in this document as it is a

Standard Sales & Distribution scenario with a standard process flow (with screenshots) as

below:

1. Sales Order (usually OR type) creation, complete pricing and other relevant data

Transaction: <VA01/VA02>



2. Outbound Delivery (LF) Document creation <VL01N> / change <VL02N>

Please note: The Outbound Delivery may be automatically created with the Schedule line in

Sales Order. This depends on configuration of Sales Order Type in Sales & Distribution,

where under shipping section “Immediate Delivery “A” or “X” is set. If not, then delivery would

have to be manually created with reference to Sales Order.



3. Picking, Packing (if relevant), Posting Goods issue & creating subsequent Shipping

documents (if applicable) <VL02N>

Once PGI is executed, Goods movement status is complete. The Delivery doc no and a Material doc no

will show up within Document flow section in Sales Order.



If you check the material document in <MB03>, you will find that a movement with movement type 601

has been executed. Stock account would be credited (-) for the outgoing material.

4. Creation of a standard Invoice document and posting of Invoice <VF01/VF02>



After Posting the Invoice, it is released to Accounting. Finally the Sales Order document flow would be

as below:



5. Customer Equipment is created as a Serialized version of the material sold

Transaction: Create Serial No (with Equipment view) <IQ01>.

- Sale of Accessories/Spare parts on receiving a Customer Request Notification. The parts

maybe under guarantee in which case the supplier may charge the customer nothing or certain

charges as per guarantee norms. This is very similar to the Sales scenario, difference being it’s

based on a Customer Notification post sales usually. Brief steps highlighted below:

Please Note: Apart from standard Sales & Distribution configuration, it will involve Notification

configuration on PM side which has been detailed in later sections of this document under Post

Sales Scenario.



1. Service Notification created

Transaction code: <IW51> (Create)/ IW52 (Change)

Notification type: S1



2. Sales Order created from the Notification by Clicking on Sales Order tab

Transaction code: IW52 (Display)

Order type: I have used the Standard Order type “OR” but it is again Business

specific choice. SD configurations should accordingly be done to support the

process.

3. Outbound Delivery creation and processing (same as previous scenario)

Transaction code: Create <VL01N>/Change <VL02N>/ Display <VL03N>

Delivery Type: LF



4. Invoice creation and processing (same as previous scenario)

Transaction code: Create <VF01>/ Change <VF02>/ Display <VF03>

5. Check the Complete Document Flow in Notification or Sales Order

Transaction code: Display Sales Order <VA04>/ Display Notification <IW53>



- Creation of Service/Maintenance Contract for rendering Long term Planned Services such as

yearly services of Air conditioner with coolant change

This will be detailed in Post Sales Scenario -> Service Order processing – Contractual Services

4.3 Post Sales Scenario

Process Background: Post sales scenarios are the actual Customer Service scenarios, with the most

critical ones being:

- Service Order processing – Non contractual Services

- Service Order processing – Contractual Services – Unplanned (Fixed Billing)

- Service Order processing – Contractual Services – Unplanned (T&M Billing)

- Service Order processing – Contractual Services – Planned (Fixed Billing)

- Service Order processing – Contractual Services – Planned (T&M Billing)

- Returns & Repair processing

Service Order processing can again be based on T&M billing (Based on actual costs incurred) or Fixed

rate billing. The above can also be subject to Warranty is and as applicable or configurable services

based on certain conditions. As mentioned earlier, the CS module scenarios can get very complex and

conditional based on the services rendered by the organization. This document would however only

highlight the base scenarios which are the building blocks for further scenarios.

4.3.1 Service Order Processing – Non Contractual services

Process Background: A Customer already dealing with a Service organization or a new customer

gives a call and requests a Service action, without going into a Quotation process i.e. they agree to pay

on whatever is the actual work that would be performed or a Fixed rate applied post the services have

been delivered. This is a one-time service work not bound by any contractual norms. This kind of work



are usually billed on a T&M (Time & Material) basis. In most cases it’s an existing customer. Just in case

it’s a new customer, Customer master records would be set up first and then the work processed further.

Configuration Pre-requisites:

SD settings (Only the critical nodes highlighted)

1. SPRO -> Sales & Distribution -> Basic Functions -> Pricing -> Settings for “DR” Debit memo request

We have created a Document pricing procedure “S” which is assigned to DR. Also the Customer that

we are using in this prototype document is assigned a Customer pricing procedure “S”. So system

determines the pricing procedure for the combination “Sales Area -> Doc pricing procedure ->

Customer pricing procedure -> Default pricing condition”

2. SPRO -> Sales & Distribution -> Sales -> Sales document item -> Assign Item Categories

This is a critical configuration setting for this process. As we use standard SAP SD document type

“DR” for Debit Memo request and standard Item categories associated to it, I have not detailed the

initial settings which is usually already done in standard system.

We have set DR (document type) -> LEIS (Item cat group) -> Usage SEIN -> Blank/L2W (Higher

Item categories) -> L2W (Default Item category). This will allow item category determination for DR

during Dynamic Item processing in DP90.



3. SPRO -> Sales & Distribution -> Sales -> Customer Service -> Profiles for Resource Related Billing

This is again a very critical configuration. Profile created with Usage Billing and Result Analysis. Sales

document “DR” set for Billing request generated through this DIP profile, CR set for Credit Memo

request.

Characteristics included are Product (For service product inclusions), Cost Element (Primary selection

criteria for Cost sources), Activity Type/Cost centre/Material (Optional as Cost elements drive selection)



Sources are Actual Cost – Line item driven here with 100% cost relevance.

Sources in this prototype are driven on Cost element based sets. This is the case where cost elements

pertaining to Labour, Material, Services etc are clearly available/identified to the Logistics team. If this

isn’t the case, then the Source selection may be driven on sets of other characteristics which the

Logistics team is aware of like Material ID sets, Activity type/Cost centre sets etc.



Material Determination – this is the set of Dynamic items which will get picked up to be placed into the

Debit Memo request as request items (L2W category) based on source criteria. The Materials used here

has been set up in SAP MM module as “DIEN” material with Item category Groups set as LEIS, and in

Costing 1 tab, “Material origin”, “With Quantity Structure” have been set.

You would notice in configuration step that there are 2 critical parameters Material Direct and Individual.

Material Direct means that if an actual material no. is there (say a spare part used), then that will be

transferred to the Billing request instead of the Dynamic material. In this case Material should have been

set as a Characteristic. Individual refers to second level of summarization. It’s better to tick all as

Individual Expense Item else during DP90 transaction it often causes issue in determining Expenditure

Items. If it has been set then each individual line will be posted separately to billing request instead of

summarizing under the Dynamic material ID.



Each of this Dynamic material is then mapped to a Selection criterion, which has been kept on a set for

identification of Source cost element.

4. SPRO -> Sales & Distribution -> Sales -> Customer Service -> Assign conditions to Sales Document

type

DR is assigned to Condition type EK01 (Actual costs)



5. SPRO -> Sales & Distribution -> Sales -> Billing -> Maintain Copy control for billing documents ->

Sales Document to Billing document

Sales Document “DR” -> Billing document “L2” with Header, Item mapping to include L2W item

category (for this scenario as per previous configurations)



PM settings (Only the critical nodes highlighted)

1. Basic settings: SPRO -> PM & CS -> Maintenance & Service Processing ->

- Settings for Display of Costs -> Defined Value categories for Costs and Revenues (as Service

Order is Revenue bearing) and assigned them to corresponding Cost elements/Cost element

groups can also be assigned.



- Defined a Settlement profile & its corresponding allocation structure

For a Revenue bearing Service Order, Settlement profile usually should allow settlement to a

Profitability Segment and Revenues should also be accounted as Source in Allocation structure.





2. Notification settings: SPRO -> PM & CS -> Maintenance & Service Processing -> PM & CS

Notifications -> Notification creation -> Notification Type/Notification Content/Partners/Notification

processing

- Notification type”S3” re used: General Service Notification type.

- Define Screen Templates, Assign Number range, Long Text control

- Assign Notification Type to Order type: S3 linked to PM/SM order type SM02 detailed later

- Define Order Types and Special Notification parameters – as in this scenario we will just be

associating the Notification to a Revenue Bearing Service Order, no Sales Order/Contract type

need be associated

- Catalog profile: A standard/customized CS profile can be used for defining Task/Activity codes

- Partner Determination Procedure: PDP “SV” assigned to the Notification type S3

- Notification processing -> Additional Functions -> Define Action box -> Follow up functions

In this node, I have kept the action boxes defined by standard SAP as it is. However from the

actions configured in the action boxes only a couple of specific actions (highlighted ones) will be

used in the process steps as you would notice. If required, these action boxes can be de

assigned in configuration as well.



3. Order settings: SPRO -> PM & CS -> Maintenance & Service Processing -> PM &CS Orders ->

- Function and setting for Order type “SM02” – Order type should be revenue bearing and linked

to Settlement profile as created in steps above

- Check credit Limits, Sales doc types for Service Orders – This node defines a PM Order as a

Service Order and associates it to a DIP Profile (as configured earlier) and a Debit Memo

request document



- Configure Number range fort Order type

- Assign Order type to Maintenance Plant(s)

- Settlement rule : Define Time and Creation of Distribution rule – has been set as Mandatory for

Completion

- Define Notification and Order Integration: SM02 is linked to S3 Notification

- Costing data for Maintenance and Service Orders -> Assign Costing Parameters and RA key

Standard Costing parameters and RA key used

- Partner -> Define PDP and Partner function -> Assign to Order type -> PDP “SV” assigned to

SM02

- Scheduling -> Set scheduling parameters -> Forward scheduling set for Plant, Order type

combination



- Completion confirmations -> Define Control Parameters for Completion Confirmations - set as per

standard for Plant + Order type SM02 combination

Process Steps:

1. Customer call is recorded in a Service Notification of type “S3” as per configuration

Transaction: <IW51>



The Relevant Details are filled in the Notification, Tasks (To do) /Activities (As done) etc are logged into

respective sections and Notification is set into processing by releasing it.

Notification “……” saved.

2. Service Order of type “SM02” is created as a follow on function from the Notification. All

relevant costs such as Expected Service hours, Spare parts if any will be planned in the

Service Order and the same will be released for actual processing. Please Note that in this

case “No sales order” would be associated.

Transaction: <IW52>



As this is a Pure T&M Service Order, Service Product may/may not be associated. We will simply plan

the Labour hours, Material (if any), Service (if any) and release the Order



Planned costs will be displayed on executing the Costing or on saving the order

The Order is planned and released.

3. Time Confirmation against the work performed for the Service Order

Transaction: <IW41>



4. Entering Goods Movement against the Service Order – for components/spare parts

consumed

Transaction: <MB11>

5. Resource Related Billing for Service Order

Transaction: <DP90>



Expenses View

Using Account Indicator against the Lines, you can actually control whether an expense line is actually

relevant for billing or not or Partial billing, for example, a Goodwill or a Warranty item. But that involves a

further level of advanced configuration which has been kept out of scope here. Alternatively, if the case

is to completely ignore an item (say 100 % Goodwill or something like that) simply Lock the Item and it

will not be processed in billing later.

Also % to be billed can be the easy option for telling the system how much of the Line item is to be

billed. By default its 100%. To accommodate a warranty/goodwill item just change the % to be billed to

0.



Check the items, unlock the items you want to process further and click on Billing Request. You will

observe that the Billing request “DR” Line items will bear an Item category “L2W” as per Item category

assignment configuration.



6. Create Billing Document for the Billing Request

Transaction: <VF01 >

Please Note: If the items in the Debit Memo request had not been unlocked, there may be a Header

Block which may not allow processing of the Billing document further. A header level block can be

removed by going into transaction <VA02> ->Debit Memo Request No -> Goto -> Header -> Billing



Ensure that the field Billing Block is empty

On executing <VF01>, Invoice doc as below would be generated and on saving the save,

updated in Sales Order document flow.



Release the document to Accounting in Transaction <VF02> if the Billing document type requires it to be

done separately.

It would create the following Accounts level postings at the simplest level

Customer A/c Dr,

Revenue A/c Cr,

Tax A/c Cr



4.3.2 Service Order Processing – Contractual Services

Process Background: Basically there may be 2 primary sub-scenarios for Contractual Service

Procession. It would include

- Processing Service Contracts with Periodic billing: Fixed periodic billing straight from the

Contract. This would be based on a Billing Plan set against the Service item in the contract.

Usually an “FV” type of billing request is generated out of contract line followed by actual billing.

- Processing Service Contracts with Resource Related Billing: Billing would be on basis of

actual costs accrued on an associated Service Order (Non-revenue bearing) followed by a billing

request. Service Order charges will be billed at actual costs through a Debit Memo request

followed by a Billing document.

In the above processes, Maintenance Plans can also be brought into action for generating Service

Notifications/Service Orders on a periodic basis based on a Service Plan created on a Contract Line

item defined as a Service Product. Service contracts may also have price agreements for certain

material and standard monthly billable charge for certain services.

Service Contracts usually come into effect Post sales of a Customer product to the Customer or post

acceptance of a Quotation on behalf of a customer to execute a Contractual service agreement for a

relevant term post acceptance. Costs and services posted to a Service Contracts are finally settled to

Profitability analysis where it can be further analysed.

In the process scenario described below, we would use a single Contract with 2 line items – one with a

billing plan for Fixed Billing and the other to be driven through a Planned Service Order (generated from

a Maintenance Plan) costs settled to it. There may be another sub scenario where a Customer calls to

request a Service (Service Notification) work based on an existing Contract (Auto contract

determination) leading to a Non-revenue bearing service order that is processed further through

Resources Related Billing and costs settled to the Contract line item. This scenario being a little bit

similar to Repair and Maintenance scenario in next section is not detailed further her




The configuration pre-requisites are similar to the configuration pre-requisites in previous and next

sections. Hence they are only briefly mentioned in this section to avoid repetition wherever possible.

SD side of configuration (All would be under IMG -> Sales & Distribution -> Sales/Billing)

- Document Pricing procedure set for Contract document type “WV”

- Standard Sales document type “WV” for Service and Maintenance Contract activated

- Standard Sales item category ‘WVN” is checked

- Assignment of Sales item category

Doc type WV -> Item category group LEIS -> Usage “Blank” -> Default Item category “WVN

Doc type DR/LV (whichever used as Billing request from Service order) -> Item category group

LEIS -> Usage SEIN -> Default Item category L2W

- Copy control Sales document -> Billing document

Sales doc WV/Item category WVN -> Billing doc FV

Sales doc DR/Item category L2W -> Billing doc F2

- Billing Plan type for Periodic Billing

- Define and Assign Date Categories



- Assign Billing Plan Types to Sales Document Type WV

- Assign Billing Plan Types to Sales Item Category WVN



- Customer Service -> Profile for Resource Related Billing

Same as in previous process section with usage “Billing request and Result Analysis”

PM side of configuration (Mostly would be under IMG -> PM & CS -> Maintenance

Planning/Maintenance Processing)

- Maintenance processing -> Basic settings -> Value categories should capture all ranges of costs

per Cost element/Cost element group assignment. Revenue value category not required in this

case.

- Maintenance processing -> Basic settings -> Settlement -> Settlement profile -> should allow

settlement to Sales Order

- Maintenance processing ->Basic settings -> Settlement -> Allocation structure -> associated with

above settlement profile should capture Sources for all costs and allow settlement further to

receiver SDI (sales document item)

- Maintenance Plan Category created with Outline Agreement as reference



- No. range assigned to Maintenance Plan category

- Maintenance Order type “SM04” created as a Non-revenue bearing order, settlement profile

allowing settlement to Sales Order assigned

Please Note: You have your own choice of Order type. Just set it up as a Non-revenue bearing

Order and allowing settlement to Sales Order.

- Maintenance Order is marked as a Service Order, linked to sales doc type WV

- Maintenance Order type assigned to relevant Maintenance Plant

- Number range set for Maintenance Order type

- Costing variant (standard PM01/ or custom) assigned to Order type

You can use your own costing variant with/without costing sheet as well, depending on

requirement



- Scheduling parameters set for Order Type + Maintenance Plant combination

- Completion confirmation parameter set for Order type + Plant combination

Process Steps:

1. Define Service Product for Maintenance Plans

Transaction code: <OISF>

Prior to this, create a Service Item (Type DIEN) in MM01/MMS1.Then define it as a Service

Product for Maintenance Plan. Also a Maintenance Task List should have being created defining

the Operation(s), Planned spares/services if any of the work. This is a pre-requisite to create a

Service Based Maintenance Plan to generate a Service Order.

2. Creation of Service Contract:

Transaction code: Create <VA41>/ Change <VA42>/ Display <VA43>

Document Type: WV



Assigning 2 Service items to the Contract – one (D120) with a Fixed bill as per a Billing Plan, every

month (say $50 per month for 1 year – Ex. an instalment payment contract), other (D125) with a Service

Product assigned which will be cater to actual costs incurred on a Service Order through Resource

Related billing on periodic special services.



A Billing plan is assigned to the first item (item 10)

The item 20 – Actual cost service product may have a base charge to cover some admin costs or may

not have any base charge. In this scenario, we are assuming that all planned service related charges

will come through the Service Order.

Customer Equipment can be assigned to the Contract Line item by selecting line item -> Extras ->

Technical Objects



Save the Contract - Service and Maint. 40005498 has been saved

3. Fixed periodic billing for Contractual Line item based on Billing Plan

Transaction: <VF04> Process Billing Due List, <VF01>



Select the due item in the list, choose Individual Billing Document and save. This will post the Fixed

monthly due bill and the status of the Line item in the Billing Plan will change from Status A (Not billed)

to status C (Completely processed).This would result in revenue being realised against the Contract

Line item.

4. Creation a Maintenance Plan with reference to item 20 of the Contract

Transaction code: <IP50>

Plan category: CS (configured for this scenario)

In configuration this Plan category has been set to be defined w.r.t an Outline Agreement

(Contract)



The Contract No and Item gets embedded into the Maintenance Plan

Let’s suppose we generate the Maintenance Orders immediately for the whole year to Plan in advance.

In this case we keep the Call horizon as 0. If we want to create the Maintenance Orders near to plan

dates, say 1.5 months prior in a 3 month frequency -> 50% call horizon needs to be set and so on.

Also parameter Scheduling period is for how long we want the schedules to run in advance, in order for

system to identify pending Calls (Orders) to be generated – say we want to plan for the next 6 months,

we set scheduling period as 6 MON. Start of cycle will be defaulted to start of Contract



Maintenance Plan is saved. Maintenance plan 11942 created

5. Maintenance Plan is scheduled

Transaction code: Manual <IP10>/ Automated batch for Deadline Monitoring program

RISTRA20 <IP30>



Save the schedule and check in transaction <IP24> the scheduled orders generated from Maintenance

Plans of category “CS”



6. The Maintenance Order is further planned and released for processing

Transaction code: <IW32>

Planned Labour, Spare, Services costs if any would be displayed in the Costs section.

Maintenance Order processing is similar to the other scenarios where Non-Revenue bearing

maintenance orders have been used.

7. Time confirmation for posting of actual labour hour to Service Order

Transaction code: <IW41>



8. Planned Goods movement for spares if any are posted to Service Order

Transaction code: <MB11>

Since its similar to prior scenarios as well as scenarios detailed later, have just highlighted the

transaction



Unplanned Goods issues can be posted to Order Operations through <IW42> transaction.

9. Resource Related Billing for Service Order

Transaction code: <DP90>

It should post dynamic items to the Contract document as Service Order is Non-revenue bearing.



Check the items, set amount/percentage to be billed and click on Billing request

As you would notice in this case we have used the Service Product line only for summarization i.e. as an

Item category of type L2S, whereas the Actual cost item – Labour cost in this scenario comes up as

actual request item of Item category L2W. Thus Net value of request = Net value of L2W item.





10. Billing document for the Billing request created against Service Order

Transaction code: VF01

Only the Non statistical item in the Billing request will be proposed in the Bill.



The accounting doc is posted and released to accounting.



The Originating Document – Contract + Line No followed by Billing request document no. will be

embedded in the Billing document line item level.

Revenue would also have been posted to Contract Item associated as the Originating document item.

This is evident in controlling document within the Invoice – Accounting document



11. Maintain Settlement rule and Technically Complete the Service Order

Transaction code: IW32

Associated Sales Contract Item is by Default set as the settlement receiver in the distribution rule



12. Settle the Service Order

Transaction code: K088



Document flow in Service Order gets updated <IW32>

Costs get posted to Sales Contract item which can be analysed further in Sales Contract <VA43>

Line item selected -> Environment -> Cost Report



4.3.3 Returns & Repairs Processing

Process Background: In the repairs process, the customer calls up the Customer Service

Representative and informs of Equipment or of a parts issue. The CS Rep. fills in a Notification which

serves and the Returns Material Authorization (RMA) document. During creation of the Notification, they

can also check whether the Equipment is under warranty or not and make a note of the same. As the

Equipment would be repaired in a Service Centre, a Repairs Order of type RAS followed by a Return

Delivery document is created. The part is received and the Repair process in initiated. A PM/CS Service

Order is automatically created based on Repair procedure to plan the detailed work including labour,

material, service charges etc. Repair Order -> Service Order. The Service Order is then released and

processed further. Once the actual costs have been booked to the Services Order and it has been

Technically completed, the Repair of parts is complete. Based on subsequent action in Repair

procedure, an Outbound Delivery document can be created to deliver back the repaired Equipment to

the customer. Post completion of delivery, the Service Order is subjected to Resource related billing

which posts billing items into the RAS Repairs Order. These billing items are then invoiced out to the

customer. Service Order is finally settled to the Repairs Order and postings analysed further in the Sales

Order.


Most of the configuration steps are similar to the previous process configurations. Hence only the critical

aspects of configuration which are specific to this process have been highlighted below:

CO Configuration

IMG -> General Controlling -> Organization -> Maintain Controlling Area

FI-CO Team to ensure that the Controlling area has Sales Order component active for the Fiscal year of

posting. This is required for settling Service Order Costs to Repair Sales Order at the end of Service

Order process.



Please note that there are multiple other CO related settings such as CO-PA settings, Activity planning

settings etc. As this document mainly focuses on CS/SD part of process, touch points have only been

briefly highlighted.

SD Configurations

IMG -> Sales & Distribution -> Basic Functions -> Pricing -> Define and assign pricing procedure ->

Document pricing procedure for RAS is “R” and Customer pricing procedure “S”. accordingly a standard

pricing procedure gets picked up for RAS Sales Order

IMG -> Sales & Distribution -> Account Assignment/Costing



- Revenue Account Determination -> Assign G/L Accounts – Used standard Condition types and

Act keys

- Reconciliation Account Determination -> Assign G/L Accounts – General – standard condition

type used

IMG -> Sales & Distribution -> Availability check and Transfer of Requirements ->

Nodes under this are very critical to this process, as during the process there would be a Transfer of

Requirements from Sales Order (RAS) -> Service Order,

- Define Requirement Class – Standard Requirement class “204” used and assigned to Service

Order Type “SM03”, Assembly Type = “2”, Account Assignment Category = ‘E’



- Requirement Type – Standard Requirement Type “SERP” linked to Requirement Class 204

- Assignment of Requirement Type to Transaction: Item Category “IRRS” -> MRP Type “ “ ->

Requirement Type “SERP” Origin of Requirement “1”



IMG -> Sales & Distribution -> Sales Document -> Sales Document Header/Item/Schedule Line ->

- Sales Document type RAS defined – As per standard configuration

- Assign Sales Area to Sales Document type – Relevant sales area (Sales Org + Distribution

Channel + Division) assigned to RAS

- Define Item categories - The key Item categories in this process are IRRS (Main item – Repair

Service Resources), IRRE (Returns – sub item), IRRP (Repair – sub item), IRAL (Outbound

Delivery post repair – sub item), IRIN (Billing item – sub item), IRIN (Dynamic items for BillDoc).

These are the base ones. Others can be IRLB (Send Replacement – pre repair), IRLA (Pick up

replacement – post delivery of repaired goods), IRPA (Fixed Rate Repairs) etc. It depends on

what is the level of complexity/process steps facilitated through the Repairs Procedure. The

Repairs procedure should have been assigned to the Main Item category IRRS. These are

standard Item categories and it’[s advisable to use SAP’s standard settings to avoid issues while

executing the process.





- Assign Item Categories – This is a very critical step and assignments must be done very

carefully as this process is basically driven on a High Level Main Item “IRRS” followed by sub

items that are triggered on actions of a Repair procedure and concluded by Dynamic item

creations through Resource Related Billing.

For IRRS: RAS -> Item Category Group LEIS (of Service Item) -> Default Item category

IRRS, Manual category IRPA (in case of Fixed rate repairs)

For IRRE: RAS -> Item Category Group NORM (For Repairable item) -> Usage R101 ->

High Level Item IRRS -> Default Item category IRRE

For IRRP: RAS -> Item Category Group NORM (For Repairable item) -> Usage R102 ->

High Level Item IRRS -> Default Item category IRRP



For IRAL: RAS -> Item Category Group NORM (For Repairable item) -> Usage R103 ->

High Level Item IRRS -> Default Item category IRAL

If you want to use Fixed Rate Repairs, the high level item category would simply be IRPA

instead of IRRS (as in this prototype we have demonstrated a Resource Related pricing

scenario and not a Fixed one)

For IRIN: This is critical for the Dynamic item generation and Posting to RAS from PM/CS

Service Order

RAS -> Item Category Group LEIS (of Dynamic items identified in Material Determination) ->

Usage SEIN-> High Level Item IRRS -> Default Item category IRIN



- Assign Schedule Line Categories – Schedule Line category “IR” assigned to Item Category

“IRRE”

IMG -> Sales & Distribution -> Customer Service -> Service Quotation/Resource Related Billing ->

- Profiles for Resource Related Billing/Quotation Creation – This is similar to DIP profile

configuration detailed earlier with Usage “Billing and Result Analysis”. Only difference is

“Product” not used under Usage -> Characteristics in this case. Have used other relevant

characteristics like Cost Element (primary driver in this prototype), Activity Type, Cost Centre



- Assign Conditions to Sales Document Types – Sales document type RAS assigned to condition

type EK01 to capture Actual costs in Service Order during Resource Related Billing.

IMG -> Sales & Distribution -> Customer Service -> Returns & Repairs Processing ->

- Define Repairs Procedure – In this Prototype we have reused SAP standard Repairs procedure

0001 as is as it suffices most requirements. In special cases (such as adding additional Actions

in the procedure or modifying certain Actions types to/from manual/automatic actions), custom

Repair Procedure can be set. This is the most crucial configuration for the Return & Repair

Process.



As you would notice, the Repairs procedure comprises Stages (broadly classified into Accept Repair,

Start Repair, and Confirm Repair), Sequential Actions per stage, If action is Default for this stage, If

action is Manual (Ticked) or Automatic (Manual un ticked) based on Confirmation (Conf.) parameter set

against the Stage -> Action combination. While going through the process, it should be clear as to which

background action/process triggers which confirmation parameter thus triggering a suitable Automatic

action.

PM Configurations – mostly similar to configuration in last process detailed, so will not be elaborately

detailed below

IMG -> Plant Maintenance & CS -> Maintenance and Service Processing -> Basic settings->



- Settings for Display of Costs – Maintain value categories and Cost elements/CE Groups

associated with Value categories. As Service Order is Non-revenue bearing, Cost value

categories should suffice this scenario

- General Order Settlement

–> Maintain settlement profiles - should allow settlement of Maintenance Order to Sales

Document item

-> Allocation structure set in settlement profile should capture all source cost elements/cost

element groups for transfer of costs from Service Order to Sales Order (Repair Order

) during settlement

IMG -> Plant Maintenance & CS -> Maintenance and Service Processing -> Maintenance & Service

Notifications -> Notification creation/Notification processing

- Notification type: Defined a Notification Type Y1 to capture a Repair Request. One can use a

standard Notification type with appropriate action control set as well.

- Screen Template for Notification type:





And so on…..

- Notification No. range set

- Assign Notification type to Order type: Y1 assigned to Order type SM03

- Special Notification Parameters for Service Notification:This is critical to this process. Sales

Order type RAS assigned to Notification type Y1

- Partner Determination Procedure: Standard PDP “S1” is assigned to Notification Type “Y1”



- Notification processing –> Additional Functions –> Define Action Box -> Define Follow up action



There would be a Sequence of Actions which can be triggered from inside the Notification and they

would be triggered based on a standard Function module set in the Action detail section – screenshots

below:



IMG -> Plant Maintenance & CS -> Maintenance and Service Processing -> Maintenance & Service

Order -> Function and setting for Order types

- Configure Order Types: Order type “SM03” is configured as a Non-revenue bearing Order.

(Revenue postings not allowed)

- Credit Limit checks, Sales Document Type for Service Orders: SM03 set with Sales document

type RAS and marked as a Service Order



:

- Indicate Order Types for Refurbishment processing: SM03 has to be set as Refurbishment

processing Order.

- Other critical configuration steps for Orders which should be the same as previous process

section configurations (section 4.3.1 configuration settings for PM) include:

- No. ranges for Orders

- Assigning Order to Maintenance Plants

- Define Notification and Order Integration : SM03 -> Y1

- Assign costing parameters and RA Key to Plant + Order type: we used standard costing variants

PM01 in the system.

- Define Change docs, Collective PR indicators, Operation no intervals

- Scheduling -> Set scheduling parameter

- Completion confirmations -> Define Control parameters for Completion Confirmations

-

-



Process Steps:

1. Customer call is recorded through a Problem Notification

Transaction: <IW54>

Notification type: Y1 (Refer configuration section)

The details of the Equipment + Serial No are added in Reference Object section.

Please Note: If a master warranty has been created against the Equipment in transaction <BGM1>

and/or assigned in transaction <IE02>, and the configuration setting of Customer warranty set to display

a pop-up dialog if there is an existing warranty, at the Notification screen the pop-up[ would come up

and display the same. Based on this, Service agent can make a Note of the same which may then be

taken care of in Billing stage.



Click on Action box item “Log Telephone Call” – fill in the details in the sub screen that opens up. This

section is meant for detailing the conversation between the Customer Service Rep. and the Customer

It would create an Activity which is displayed in the Activity section of the Notification



Next click on the “Repair Order” in the action Box. Repair Order type “RAS” would be raised with a

Service item (D110) and Equipment-Material No. as a sub-item. It will copy most of the details from the

Problem Notification.

Message “Repair order will be created after saving” will be issued. Save the Notification. If it asks for a Technical Reference Object, enter the Equipment No of the Equipment to be repaired.



Notification “………..” created

2. Display Notification

Transaction: <IW53>

Notification No: As created in step 1

Check the Document Flow section

RAS Order would be displayed



Double click on the RAS order and select Edit – Display – All items

The first item is the Service item and the sub-item below it is the Returns item (The Equipment to be

returned from Customer -> Service Depot for repairs). System automatically creates the item structure.

Select the Main item (10) and click on the tab “Repairs” below the All items sub screen. It will show that

there is 1 item For Return and Serviceable item would also be displayed.



In the RAS order you would observe that the Main item (Service item) would have Item category IRRS

(Rep. Serv. Resources) and the sub item (Serviceable item) would have Item category IRRE (Return for

Repairs)

3. Posting the Goods receipt of a piece of Equipment to be repaired

Transaction: <VRRE>

Delivery Type: LR – Returns Delivery

Purpose: The piece(s) of Equipment to be repaired are delivered. The Returns delivery is

created with reference to the RAS Order, sub item. They are posted to non-valuated stock as

sales order stock using the number of Repair requests. The stocks would get received to

Sales Order (E) UR stock in this simulated scenario. In certain organizations it may also be

received to QI stock for Inspection on receipt. This can be triggered by setting up QM

(inspection type “05”) for serviceable material and setting movement type 655 against

Schedule line category IR in SD.



Confirm the Delivery quantity, Dates and other details and save the delivery document

Returns Delivery “……..” has been saved.

4. Perform a Post Goods Issue against the Delivery document

Transaction: VL02

Document No: As created in step 3



Confirm Picking for item

Post Goods issue



5. Check Goods Return posted to Blocked Stock

Transaction: MB52

Stock Type: Special Stock indicator should be selected in initial screen.



6. Post Serviceable Material to Blocked stock for Technician to check and confirm Repairs to

proceed further or to Scrap the Material

Transaction: <MB1B> Transfer Posting from Sales Order (UR) stock to Blocked Stock

Movement Type: 344E – Transfer posting Blocked to Sales Order stock – Reversal

Purpose: This movement is recommended by SAP if Quality Management of Returns

process is not used. This movement also ensures that Customer returned stock is not used

internally.



Document “…..” posted. If you run Warehouse Stock Report transaction <MB52> next, you would find that the stock Quantity would now show under Blocked Stock, as opposed to UR stock in step 6.

7. Technician would perform the Technical Check on Material and confirm whether it can be

Repaired or not. This can be confirmed to the Central Customer Service Rep.

The Service Rep would open the RAS Order in Change Mode <VA02> and go into the

Repairs section for the Main item (10). On clicking on back arrow next, system proposes to

copy item proposal to Start repair -> Confirm the same and the Order would automatically

generate a second sub-item under the main item with item category “IRRP” – Initiate Repair.

The Net value of this item would copy Planned costs in PM: CS Service Order (auto



generated in RAS sales Order in this step as well) into Pricing condition EK02 (Calculated

costs). Service Order is detailed in later steps.



The Repair Status of the Main item (10) now changes to “Business decision made / Under repair”. Also

“Under Repair” field will show an added item count.



8. Check Document Flow in Notification screen

Transaction: IW53

You would Notice that the Returns Delivery would appear completed. You would also notice that the

system has automatically generated a Repair Service Order (Type SM03) based on Repairs Procedure

step associated with RMA scenario. Refer configuration section for details.

Please note that this is a Non-revenue bearing Service Order and should have been checked as a

Refurbishment Order in configuration. It would have been pre-costed with the Labour hours/Material etc

from Task List as defined against the Service Product (which is the sub item in RAS order). Refer to the

configuration section for step to define a material as a Service Product. Planned costs as calculated

would be displayed.



Initial costs – Labour/Material etc. (if any) planned through the Task List linked to the Service Product

(Main item in RAS sales order) would reflect in Service Order Costs section as also against the

Condition type “EK02” in Repairs RAS sales order main item associated.

9. Detailed planning and release of the Service Order

Transaction: <IW32>

Under Planning, plan Labour Hours, Components (Spare parts) required if any, External

Services Required if any and so on.

In the Components section you would note that the system has automatically included the

Serviceable Equipment as a Component and set costing relevancy as “Not relevant to



costing”. This is because we are repairing the Equipment which is already owned by the

customer in principle. If there are additional spare parts that would be required in carrying out

the repair, they would be planned and may/may not be costed (For example: If the repair is

under warranty for the main equipment). In this documented scenario we would see a spare

part being used and costed.

If relevant to costing the added spare part cost would get included in the Service Order cost..

Release the Service Order on completion of planning



10. Time Confirmation and spare part posting to Service Order

Transactions: Time Confirmation <IW41>, Goods movement to Service Order Reservation,

261 Movement type <MB11>



Document “49xxxxxx” posted.

11. Goods receipt of Repaired material to Sales Order Unrestricted stock

Transactions: MB11

Movement Type: 343 E

This is a Transfer posting from Blocked stock to Unrestricted Sales Order stock after

completion of the Service repairs.



Document “…………..” posted

In transaction <MB52>, the stock would be reported under Sales Order UR stock again.

12. Technically Complete the Service Order

Transactions: <IW32>

While performing TECO, system will automatically propose the next action in the Repairs procedure of

the linked RAS Sales Order. On confirming, the repaired item will then be available for Delivery back to

the customer.



13. Confirm that the Repairs are complete and delivery is allowed

Transaction: <VA02>



A new sub item would have been added with item category “IRAL” – Delivery item. The repair screen of

main item would show 1 item for delivery. This would have been automatically created on Service Order

Technical completion, if in Repair procedure it would had been set to automatic. In our Repair procedure

manual creation of delivery item has been set.



14. Deliver the Repaired piece of Equipment back to the Customer

Transactions: <VL01N> Create Outbound Delivery with reference to Sales Order item

Delivery Type: LF – Outbound Delivery



Enter the picked Quantity and Post Goods issue. In Organizations using WM functionality after Picking &

Packing (if HU management is used) a Transfer Order will be created which when confirmed will

automatically lead to PGI. Our demonstrated scenario is simple. It’s Picking -> Confirm picking -> Post

Goods Issue (PGI)

Outbound delivery “……” has been saved. The document Flow in Service Notification would have updated everything till this point.



15. Create Billing Request for Service Order

Transaction: DP90

This leads to creation of additional sub items of category “IRIN” in RAS Sales Order which

would subsequently be billed. This can be found in <VA02> subsequently.



16. Create Billing Document

Transaction: <VF01>

Select and execute. It will select the 2 sub items with item category “IRIN”



Save the Billing document

Document “……” has been saved and would show up in Original Notification document flow.

Invoice document is usually automatically released to accounting. If not, then Release to Accounting in transaction <VF02>



Check the Accounting documents generated

Customer A/c Dr, Revenue A/c Cr, Tax A/c Cr



The controlling document can also be displayed and it will show revenue posting to Profitability Analysis if CO-PA is active

17. Settling and Completing the Service Order

Transaction: KO88

Purpose: This function settles the costs of the service order to the RAS Sales Order - repair

request. A pre-requisite for this is settlement rule must have been set in Service Order which

can be defaulted to Sales Order item based on Settlement profile setting. Also, Controlling

area should allow Costs being posted to Sales Order for the posting fiscal year. As there will

be no further costs, you can also do a business completion of the Service Order.

It is advisable to do a Test run first and then do an actual run.



If you check in the RAS Sales order <VA03> -> Environment -> Cost report, it will display the settled

costs in the report.



For the period-end closing, the system finally settles the repair request within the profitability analysis. This is a

period end closing activity for Controlling Team.

Software

Sap cs standard process document