Cs business process

Standard Business Processes in SAP Customer Service
Configured & Compiled By: Subhrajyoti Bhattacharjee, PMP®, Certified SAP ® EAM, Certified ITIL®
E-Mail: subhrajyoti.b@gmail.com, 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.

Cs business process

More Related Content

What's hot

Similar to Cs business process

Recently uploaded

Cs business process