Paid Repair Configuration

Create New Sales Document-ZRA

Copy RA document type and rename as ZRA

Two relevant Sales Document Indicators for Repair

F is what we are currently using, material on the order is that we are repairing
G uses material determination, choose the service to be performed on the material

Document pricing procedure is R for repair. Important in determining the pricing

procedure for repairs.
Assign sales area to Sales Document types

For all applicable sales areas.

Sales Document Item Categories

2 New item categories

Assign repair procedure to item category.

Purpose of these two item categories is to drive the costs for the repairs to other
cost elements, different service order. Section on requirement class and
requirement type will provide some further detail.

Assignment of item categories

SO type

ItCatGrp Repir
Action

The materials used in the current process are NORMS. Order type ZRA with a NORM
material would normally determine an item category of IRPA. However, there is a
user exit in place that chooses alternative item category ZRPA. The item

categories then determined based on the repair action and the sub-item and higher
level item category.

User status for ZRA Header

The sole purpose of the assignment of the profile to the ZRA order is for CCC to flag
the orders for asset recovery. For instance, if CCC knows the order is Preapproved asset recovery knows they can begin work on it without having to
contact the customer. There is no additional functionality behind the statuses.

Repair Procedure

Stages and actions of repair procedure

Actions that can happen at each stage. Which actions are default, and which are
manual.
Assign the repair procedure to the item category. The higher level item category
IRPA, ZRPA.

Billing type

Billing type FR.

Standard billing type for RA/RAS order type ,not customized.

No changes to this billing type

Jenny from China tested the cancellation, so we know this works.

Account determination procedure is custom

this is the VSEA procedure, not specific to repair, Kevin chose it because it it is what
is used everywhere else

Copy control: Sales document to Billing document; Sales document to

delivery documents

Copy control for Billing

ZRA to FR

Repair uses order related billing, not delivery related billing like other sales orders
This is causing the GTS issue since delivery is on different line than where the
invoicing is done

We can change to delivery related billing, but this would be a big change
Noticed this in config, perhaps might help with the GTS issue, not sure, need to
investigate, discuss with Manoj

Header detail

Item detail

Item categories available for copying ZRA to FR, some of these we dont use, but
may at some point
IRIN, IRNI this could be used for time & materials
IRGN, IRLN standard functionality allows for debit/credit memo

Detail copy control IRRA

These are all standard copying routines, we dont use the ones that start with 9
(Winnie uses these for other SD reasons)
These copy routines are programs, which can be enhanced
For example, to find the program begind a specific control, you can open the
selection list:

This opens up the program:

These copy controls are necessary, but not much to them, dont change much for
paid repair, but in other SD areas these have been enhanced significantly
Also, need the copy controls for the two deliveries (ZG11, ZG22), this is configured
in another area in IMG (see below)
Copy control ZRA to ZG22 (inbound delivery) and ZG11 (outbound delivery)

Header Detail

Item Detail

Again, nothing special or customized for paid repair, just need these copy controls

Output for documents

Config sequence:
1. Condition type
2. Access sequence for condition type (no changes here, the same one used in
4.6C was used in ECC) determines which fields used used to drive the
output, e.g. sales organization, etc this is where the configuration is
mapped to master data, txn VV33, the access sequence defines

note in config these Key Combinations are configured:

select one, Field determine which are used on the billing document

Table NACH has these entries, e.g. search for ERNAM = SUPPORT_KH

These are based on sales org and distribution channel, this is how the outputs
are triggered.
When you open a record, it show which printer to go to, format, when to
send, etc.

specific printer will be on the Communication button, Output device

also note that the fields that are available for an access sequence are defined
in the following txn, once the table is known from the access sequence:

these three fields are made available in the access sequence. Be careful
when adding/remiving fields because these tables can be used by other
access sequences, you can create new tables for specific purposes, note 916
is a custom table
you can add additional fields to the table, e.g. Item Category if you want to
conditionalize pricing or outputs based on this

the condition technique (access sequence) is an important concept because it

is used in a lot of different places, like pricing, delivery output, purchasing
output, etc.

3. Output determination procedure (e.g. for contracts C1, paid repair FR

defines the relevant outputs)
4. Assign output determination procedure to sales or billing document itself
Significant change here is that the forms and routines are changed, Kevin had to
change the linkages between the old an d new ones
Step 1:

Step 2

Step 3

Step 4

-------------------------------

Using the condition technique

Output for billing documents

Choose Maintain Output types this is step 1 from list above

New output for contracts note this is not related to Paid Repair, C1 is for contracts,
FR is for paid repair
For paid repair, we use the procedure ZG0001

No new condition types were created for repair, but the billing outputs are the same
as the ones we used for paid repair previously
Note that the processing routines/programs have the custom logic specifically for
paid repair, for example in ZF_BILLING_INVOICE it checks the sales doc type (ZRA)
and prepends an R:

New output for C1 billing documents. SMIE for Email, SMIJ for Japan (pre-printed
forms) and the rest of the world SMIN.
Same access sequence

New program and forms, Alice worked on these (old ones are gone, smartforms and
sapscript, etc now these are PDF). Standard SAP output forms are very basic, hardly
usable. Most companies cr5eate their own.

Same partner in partner function folder (BP)

The three outputs are assigned to Output Procedure ZV0001.

Assign Output Procedures to the Billing documents.

generate the output, tcode VV31.

Then create master data to

Pricing
Current pricing as configured (vs the way we intended to be set up)
Repair pricing is different from regular parts pricing
DIP Profile pricing not used, reporting advantages among other (to be discussed)
As configured: ZSEB copied to ZREPA1
This has changed recently by Winnie (removed obsolete conditions and updated G/L
account assignments)
GTS:
Billing doc created from sales order, GTS is based on the shipment so cant see the
repair shipments
IRPA main repair pricing (billed, not delivered)
IRAL the outbound shipment (contains the customer delivery)
No standard process for repair and GTS since delivery is separate from billing

Possible solution (from SAP): create a pro forma invoice from doc that is delivered,
this creation should not impact the current repair pricing this could then trigger
the GTS process since pro forma is submitted to GTS, change item category to
pricing relevant, statistical pricing condition copied to IRAL item category, no foreign
trade statistical conditions currently, use ZGF* conditions on 4 th line (IRAL)
Need 3 new ZGF* conditions to match the 3 for repair ZGFQ, ZGFR (equivalent)
Only on repair depot ZRA order, foreign trade value is the repair charge (PO cost)

DIP Profile (to be changes):

This depends on how they want to do pricing (uplift, T&M) per material, i.e.
specific platen would be fixed price, other parts would be T&M
Fixed price:

Fixed price would come off IRPA like it does today

DIP profile would transfer statistical prices to ZRA

T&M:
IRPA is billable, new item category with cost-based pricing

IRPA is fixed price, note relevant for pricing:

Also the billing form is 01 fixed rate

So this pulls in the pricing when the material is first entered on the main item ZRA
So when the DIP profile is used for Fixed Price, the IRNI item category is used for
statistical t&m

This shows the material and labor charges used in the repair, note this is price
relevant and statistical value

The real pricing does not change for fixed in this scenario, the price from
material/customer is still the actuall price (just like IRRA), the only difference is the
actual cost details are brought over from the service order as statistical value for
reporting)

For T&M with DIP profile, the main item would have IRRA item category
This is relevant for billing and pricing is statistical:

This wont drive to the right revenue account

As an example:
Fixed price:
Today With DIP
IRPA

IRPA

IRRE IRRE
IRRP IRRP
IRAL

IRAL
IRNI (statistical dynamic items, 1 per material, labor comes over per activity

type)
Note that with the DIP profile there would be additional subitems added to the ZRA
(IRNI) when DP90 runs (those map to the actual materials) this is useful for
reporting, on the customer invoice we can configure how these show to customer,
e.g. price is 1 rollup price on the invoice but we could show the materials used in
the repair (without price probably would not do this)

Time & Materials

Today this is simply a price override
With DIP Profile:
IRRA on main item (based on material assignment as T&M not fixed price)
IRRE
IRRP
IRAL
IRIN (dynamic billing items, 1 per material, labor comes over per activity type)
Default behavior for customer invoice is all of the IRIN items appear on invoice with
a price
For the cost plus:

Condition record based on a % uplift (e.g. 250%)

Link this to master data (the material cost X the uplift condition record)

Other calculations (such as price not to exceed 50% new customer price)
can be build into this

Would need a new item category group (e.g. ZORM) which would need to be
assigned to material master, this needs coordination with SD team since their
pricing would be impacted based on their item categories

Item category group on the material master would need to be updated, coordinate
with SD
Other option (not using above approach) would be a user exit, new Ztable or field
on the material master, etc. Not recommended since this is not standard, although
SD may push back since it affects them

Third scenario: if there are different level s of service

If Business Dev want different levels of service (e.g. Premuim Rebuild vs Standard
Rebuild) then material determination would need to be used (LEIS, LEIC item
category groups) since these would be DIEN type materials (these are services)
There would be a new field on the ZRA for the service product, it would flow like
this:
1) Enter the E* serviceable material on main ZRA items
2) Popup would appear for type of service, the DIEN materials and selection
would be added to the item as service product
Standard material determination would be used to drive this

Accounting Indicators:
By default, all items are billable (even if a repair is initiated from notification and
contract)
Then you can change the accounting indicator to reflect the true repair allocation
(contract, good will, billable, etc). Then when the costs go to COPA they can see the
true cost (for reporting) of repairs, this is an option as available for different kinds of
cost and revenue reporting
We dont do anything like that today see if Applied does this
Billing workbench (only with DP90): this allows for flexibility on customer billing,
such as 10 actually hours for repair but only want to charge the customer 5 hours,
this will still show 10 hours for reporting, plus how much was given away (not billed)
This can be helpful in testing, e.g. Paid Repair only during DP90, Welch Allen and
Smith&Nephew uses accounting indicators heavily for reporting

3 New condition types

ZGP0 replaces ZGPR same access sequence and strategy (needed b/c different
pricing from E*parts)
ZGP1 replaces ZGPC
ZGP2 replaces ZGPQ

Needed different repair prices. ZGPR, ZGPC, and ZGPQ for E parts are for sale not
repair. In addition, ZGPC and ZGPQ were technically discounts or surcharges which
didnt work for repair pricing.
ZGD1, ZGS1 customer specific discount, surcharges not used in repair, all
discounts are either customer-specific pricing (by cust number) or price override
Initial intention was to not have 3 separate pricing conditions, just 1 for paid repair
and use the DIP profile to calculate the discounts/pricing
*** this is an area to enhance, replace current pricing with DIP
Accounting indicators, billing forms would be major changes when switching to DIP

Access sequences remain the same. The main difference is that the condition class
is B prices.

Maintain pricing procedures

New pricing procedure to enable repairs to function differently than sales.

New account key ZRL to push revenue to the correct account. Replaces ZD4 which
pushed revenue to a discount G/L account.

Different Price Override, ZVQR. Same reason as the creation of the other condition
records, so that repair pricing can behave differently than sales pricing.
Future: move to formula-based pricing (cost plus, etc.)

Per Manoj, there is also potential to remove one of the conditions to simplify, repair
does not need this complexity for paid repair
Today it is difficult to report cost and revenue for specific materials, they can now
start to calculate gross margin this is a key direction for Business Development
(this is on the ZRA sales order cost report, standard reports for this PMIS to show
profit, etc)
Costs come from: 1) confirmation of labor (svc ord), 2) PO costs (svc ord) 3) material
reservations/confirmations (svc ord)
Today these do not show up in pricing on ZRA, but do show up on cost reports since
all costs settle to the sales order
Slightly different settings on ZVQR and ZVQP these are the override conditions
(ZVQR does not allow for $0 pricing???) the only different is category (one is
pricing the other is discount)
How pricing is determined

Key needs to be set up for all sales orgs

R is the document pricing procedure associated at the header of the ZRA document
type in configuration.
Revenue account determination

Assign invoice FR to ZKOFI3

New account key for revenue

Tables for revenue account determination by access sequence

Entries from table 5 and 2. Tables to drive the revenue to the right accounts.

Availability check and transfer of requirements.

Determines what will happen to the repair order based on the item category
How we got the system to determine when to use the ZSPD Service order type. This
is important in separating intercompany from local repair orders.

Determination of requirements types using transaction (by item category)

Requirements type and class are different for the ZRRP item category. ZRRP
controls creation of the service order.

Define requirements types

Define types, this links the ZEPD to the Z99 so when the ZRRP item category, it
knows to fire off thte ZEPD with the Z99

Define requirements class

Assign the ZSPD service order type to Requirements class Z99.

Settlement profile is assigned to the ZRA sales order, note ZRPA item category has
requirements type SE and req class 039, this is assigned REVREC settlement profile:

Assign text procedure

This determines what texts are available and whether they copy to subsequent
document. E.g. you may want certain text to be entered on the ZRA sales order,
this also determines which texts copy to other documents, whether they print on
the invoice, etc.
Kevin set this up basically as it was used in 4.6C but he did change the linkages to
make it useable for the new repair process.

Sales document header

Assign text procedure to header

Assign procedure 80 to ZRA

80 is the most used text procedure and has been customized.

Assign to item categories as well (ZRRP and ZRPA as well) this allows for text to be
entered at the item level, e.g. they were planning to enter the serial number at the

item level and have this copy to the delivery for Asset Recovery. All the items on
the ZRA have the same texts as the header, no different functionality.

Delivery block for item category schedule line

This enables the ZR delivery block to be automatically enabled when the IRAL/ZRAL
item is created (when the service order is TECOd)

Below the items selected , the associated actions are not allowed while the delivery
block is assigned

Assign delivery block for schedule line category for item category

This schedule line category is assigned the ZR delivery block, also the movement
type when the delivery is made.
Also note that for the IRRE item category for the inbound delivery is IR, which has a
653 movement type but no delivery block.

Incompletion procedure
Determines which fields on the sales order are required or not, e.g. header reason
code, etc. When the $0 pricing was added, the Net Value was required. Kevin has
to change this to not required so there could be sales order with $0 price.

Assign to item category

Assign Z1 to IRPA and ZRPA-Net value not required in this incompletion procedure.
Allows for the price to be overridden to $0. Note he changed the incompletion
procedure for IRPA from 25 to Z1 since Z1 does not require Net Value.

No specific configuration for this, just copied from 4.6C order

Plant Maintenance
Serial number profiles

We created new serial number profile: VGQ7

For repair materials, we wanted to do specific things e.g. serialization mandatory for
certain movements
Many of the repair materials have this serialization profile

New serial number profile

Note that the default category was changed from S to M after go live. In 4.6C these
were assigned M.

Note that QMSL procedure has Ser Usage 3, which makes the inspection lot
mandatory (one of the requirements for Pd Repair)

02 02 assignments (optional) allow it to copy through to all the functions

What is key to us is the flow groups: for example for ser procedure MMSL Maintain
goods receipt and issue doc., we want to ensure that on specifific movement types
certain ser functions happen: e.g. 101 do not serialize, but on inbound/outbound
delivery 653E make serialization required

Define flow groups to refine the procedure further

Background: Kevin S had defined a profile group 101 that applies to his
movements (non-paid repair). Kevin H set up new group SYST that applies to the
paid repair movements
Note that all the SYST for all ser profiles the MMSL procedure makes serialization
required and creates the equipment view (the EqReq field 02)

Create SYST to add to the profiles

In the assignment screen in IMG, forces serialization for certain movements

653 movement type bringing in the material to customer owned stock (on in
bound receipt)
343 and 350 are Quality movement types (one is Quality blocked, other is Quality
unrestricted)
This is tied to the schedule line category, see above.

This would need to change for EPM, handling the swap material movement, etc.
Create new Service Orders

2 Service orders-One for Subs, one for depot, identical copies of each other

Need to assign order types to plants.

Mark order types for service, this is for customer-facing transactions, different from
plant maintenance which is an internal function

Up to Release 2.2 in SAP, there was no such thing as Customer Service when 3.0
came out in 1995, all they did was add partners for end customers (this made it
customer service)

Mark orders for refurbishment

The system requires that the order be a refurbishment order for this process. Think
about this order type when rethinking your exchange program. Especially if they
are valued. You send out a refurbished piece of equipment as part of an exchange
program. The one coming back that will need to go into your exchange pool is
probably not in the best condition and needs to be refurbished. You would use a
PM04 order type, actually issue the material to be refurbished to the service order,
then the cost to refurbish the material gets settled to the material itself (split
valuation) and affects the cost of the exchange pool. This would require split

valuation. The alternative is different materials (suffix/prefix) to get the cost

differences between new / refurbished parts. See what AMAT does.

Note that the ZSPR, ZSPD are basically copies of the standard SM03 order type

The PM04 would/could be used for the exchange program, but it does require split
valuation (see above).
Create default profile for external procurement

So currently this single value profile is assigned to both local ZSPR and depot ZSPD
order types
Bruce wants a different cost element associated with the ZSPD (52* not 51*), so the
way to do this is to create a new profile and associate it with the ZSPD. I could also
default the Purch Org and Group since it is just Bruce.
Details
The profile is assigned to the service order. If you create a new one for depot with
the correct cost center then it will default in the service order and will not have to
be manually changed.

New Config 11-14-2011

Added new ZREPDEP ext profile

Then assign this new ext profile to the 0930 ZSPD order type: (IMG path from
screenshot below)

Assign profiles

Per plant and order combination

Scheduling Parameters
Set these for ZSPD to stop the reservations from getting moved out to completion
date for service order.

Before changes (actually this is the current config for 595S ZSPD)

Kevin just deselected the Automatic scheduling and changed it to 4 Current Date,
this should now drive MRP for the service order creation date.
Default Control Key

For each combination of Order Type and Plant

In theory, the ZSPR service order could default to ZS02 since it will always be sent
to a repair depot (perhaps not always, in the case of a Taiwan or Singapore repair
for local customer). Best not to change this since the procedure would change, also
it would create ZS02 for all operations (for cleaning they may not want this).

Costing Parameters
Allows for planned and actual costs to be compared on a percentage basis.

Plant and order type combination

Note 11/14/2011 added the entries for 401A ZSPR, also fixed Japan since it has the
intercompany RA key ERDK909255, also updated all the ZSPR 495J orders in ERP
that had incorrect RA key, none of the svc ords were TECO so this is OK
Per Kevin H, there is not practical different between ZSM1 and PM01 the
calculatations are probably the same, check with Jasmine for detail

Planned and actual costs, results analysis key.

Partner determine procedure

Allows for partners to be assigned to the service order (SP default for header we
did not have this in 4.6C, for example see below in ERP, we did this for all our SM
service orders in ECC):

Confirmation parameters
These parameters are the same for both the ZSPR and ZSPD orders, no differences

For each plant/service order combination. Very little here to be concerned with here
since we use so little of this, e.g. we dont do mass confirmations, we dont do
backflushing so the Post open reservations wont kick in. check F1 for each of
these options for help.