Test

Service Level Adjustment

SCA IT Services





SD Service Level adjustments



SD Service Level adjustments ____________________________ 2


Introduction ___________________________________________ 3
The Process: 3


The Service Level Transactions: __________________________ 4
Transaction: ZSDSLUPDATE 5
Display function for Requested GI date and Statistical GI date 5
Update function for Requested GI date and Statistical GI date 6
SL Adjustment reason codes 7
Transaction: ZSDSLLOG 8
Report for evaluation of changed documents 8

Field definitions: _______________________________________ 9
Authorization Roles required for the transactions: 9






















































Area Order Handling Author IT Services Save date 2006-11-17
File Name Service Level adjustments v4.doc Approved by BIT
Version Rev date Page no 2 (9)

SCA IT Services



Introduction





Delivery performance is becoming more and more important, since customers often require
specific minimum levels. Failure to meet such levels, can lead to penalties or even the
loss of the contract.

SCA has measured performance for many years, but has experienced gaps between actual,
perceived and measured outcomes for a variety of reasons. A new Service Level Tool has
therefore been developed to be able to reflect the reality experienced by our customers.

The Service Level Tool will make it possible to correct internal process errors and
compensate for system constraints that don't mirror the actual daily operations.




The Process:
The First Date (Delivery date) on the order schedule line is used for Service Level
calculation. The requested goods issue date from the sales order is calculated from First
date minus transportation Lead-time. This is then used as the base for Service level
comparison.

When changing the First Date, the requested goods issue date will follow. Changes can be
made until the Delivery is created - After that point changes can not be made anymore.
There are several process issues that force us to change dates after the deliveries are
created:
* Customer postpone the order for some reasons

* Goods picked up late due to short lead-time – But still arrives “in time” to the Customer
* System delays – WMS, R3 etc..

* Ex-works Customer – Goods ready but not picked up “in time”


There could also be the opposite scenario:
* Goods issued done “in time” – But arrived to late (Negative SL)

























Area Order Handling Author IT Services Save date 2006-11-17
File Name Service Level adjustments v4.doc Approved by BIT
Version Rev date Page no 3 (9)

SCA IT Services


The Service Level Transactions:



You find the Service Level transactions in the SCA extended menu


→ ZSDSLUPDATE – Service Level update of Statistical dates




































→ ZSDSLLOG – Log List of Service Level updates



































Area Order Handling Author IT Services Save date 2006-11-17
File Name Service Level adjustments v4.doc Approved by BIT
Version Rev date Page no 4 (9)

SCA IT Services



Transaction: ZSDSLUPDATE




Display function for Requested GI date and Statistical GI date


To find out what dates are used in a certain order/delivery, you can now also use
transaction ZSDSLUPDATE in display mode. This is quicker as displaying it in the sales
order schedule line. The statistical GI date, you can only display it here (by selecting the
delivery) or in BW.
















Result, you see the Statistical GI date used for the selected document. In this case the
Statistical GI date is the same












































Area Order Handling Author IT Services Save date 2006-11-17
File Name Service Level adjustments v4.doc Approved by BIT
Version Rev date Page no 5 (9)

SCA IT Services



Update function for Requested GI date and Statistical GI date




















Add the Order or Delivery number for which you want to change the statistical date.

− If you enter an Order number, you can only change the Requested Goods Issue
date.
− If you enter a Delivery number, you can only change the Statistical Goods Issue
date.

You have to fill the tick box for “Update statistical SL date” else you only get a display
function.

Authorization check is done on this level. For changing a Sales order, you need the normal
order change authorization (according to VA02 in the selected Sales Org). If you want to
change the Delivery, you need to have authorization for Goods Movement for Outbound
delivery for this plant. See details at end of the user guide.






































Area Order Handling Author IT Services Save date 2006-11-17
File Name Service Level adjustments v4.doc Approved by BIT
Version Rev date Page no 6 (9)

SCA IT Services

In this case it is a Delivery which already been goods issued on the 2006.08.01, but as this
goods issue was late because of late haulier arrival, we set the statistical GI date to
2006.07.31 which corresponds to the requested GI date. In this case we will have a 100 %
SL for this scenario (Req.GI.date = Stat.GI.date). You have to find the Req.GI.date by
looking in the sales order, or use the original planned date (mostly it is visible in the
Delivery header as planned GI date).


You have to enter a valid Reason code, and optional a comment. Both are displayed in the
Log report.



SL Adjustment reason codes
• Customer postponed the order after the delivery was created
• “Ship To” postponed original delivery date (French process)
• Ex-works Customer – Goods ready but not picked up “in time”
• Goods picked up late – Still delivered “in time” to Customer
• System delay – Still delivered “in time” to Customer
• Goods issued done “in time” – But arrived to late (Negative SL)














To SAVE the update, select the rows and push the button “Update SL Date”.










You get a Verification of that the dates where changed. These are now updated in the
database and will be triggered to the Delta queue of BW. When next BW delta load is done
(currently Mondays and Tuesdays), the Order/Delivery will be changed in BW as well.

















When updating a Sales order, you need to change the dates on each line item.



Area Order Handling Author IT Services Save date 2006-11-17
File Name Service Level adjustments v4.doc Approved by BIT
Version Rev date Page no 7 (9)

SCA IT Services



Transaction: ZSDSLLOG



Report for evaluation of changed documents























Select Sales organisation or Plant and date of change to just see the changes last weeks.
Execute:














You will find data from the change log of the Update transaction. If you Scroll to the right,
you find some more data like the free comments, Customer name, order item nr.




























You see both Orders and Delivery changes in same report. You only see documents for the
Sales organisations you have authorization to display Sales documents for.



Area Order Handling Author IT Services Save date 2006-11-17
File Name Service Level adjustments v4.doc Approved by BIT
Version Rev date Page no 8 (9)

SCA IT Services




Field definitions:




Sales order: Is always filled when the order is updated (from CS). If the delivery is
updated, it is only filled if only 1 order exist in the document flow (it could be an order
combined delivery).

Delivery: Is always filled when the Delivery is updated (from SuS). If the order is updated,
no delivery number is filled.

Week: Determined from the latest requested delivery date on the order. (If it is the
delivery, we check the order in the document flow).
Req.deldat:
st
If the update is on the order, we take 1 Deliv.date from order item (when the customer
should receive the delivery).
st
If the update is done on the Delivery, we take the last one of the 1 delivery dates (same
date which is used for Week calculation). As we can have multiple orders in the delivery.
Req.GI old and Req.GI new:
Filled when updating the Sales order (this is the field used also in BW). We see the field
value before the change, and after. (If the document was updated more than one time, we
get for each time a new line in the log list.

Stat.GI old and Stat.GI new:
Filled when updating the Delivery. This field is on Delivery header. We see the field value
before the change, and after.

RC and Description:
Reason code entered in the update (mandatory). For each reason code there is a
description.

Comment:
Free text field, optional when doing Service Level update

The rest of the fields should be self-explained.


Authorization Roles required for the transactions:


ZSDSLUPDATE (with update flag active)

Orders: Authorisation for all order handling incl. tender process
Deliveries: Authorisation for goods movements (for Logistics)

ZSDSLLOG
a) Display Authorisation for all SD data (Managers)

or
b) Authorisation for all order handling incl. tender process (Customer Service)





Area Order Handling Author IT Services Save date 2006-11-17
File Name Service Level adjustments v4.doc Approved by BIT
Version Rev date Page no 9 (9)