DSD Backend ERP2005 EN 6761 PDF

Direct Store Delivery
(Backend)
ADDON.ISBEV_PRODUCTIVE
Release 6761
SAP Online Help 07.02.2007
Copyright
© Copyright 2007 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP AG. The information contained herein may be
changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary
software components of other software vendors.
Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft

Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400,
OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner,
WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC
are trademarks or registered trademarks of IBM Corporation.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered
trademarks of Adobe Systems Incorporated in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are
trademarks or registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World
Wide Web Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for
technology invented and implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and
services mentioned herein as well as their respective logos are trademarks or registered
trademarks of SAP AG in Germany and in several other countries all over the world. All other
product and service names mentioned are the trademarks of their respective companies.
Data contained in this document serves informational purposes only. National product
specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP
AG and its affiliated companies ("SAP Group") for informational purposes only, without
representation or warranty of any kind, and SAP Group shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP Group products and
services are those that are set forth in the express warranty statements accompanying such
products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
Direct Store Delivery (Backend) 6761 2

Icons in Body Text
Icon Meaning
Caution
Example
Note
Recommendation
Syntax
Additional icons are used in SAP Library documentation to help you identify different types of
information at a glance. For more information, see Help on Help → General Information
Classes and Information Classes for Business Information Warehouse on the first page of any
version of SAP Library.
Typographic Conventions
Type Style Description

Example text Words or characters quoted from the screen. These include field
names, screen titles, pushbuttons labels, menu names, menu paths,
and menu options.
Cross-references to other documentation.
Example text Emphasized words or phrases in body text, graphic titles, and table
titles.
EXAMPLE TEXT Technical names of system objects. These include report names,
program names, transaction codes, table names, and key concepts of a
programming language when they are surrounded by body text, for
example, SELECT and INCLUDE.
Example text Output on the screen. This includes file and directory names and their
paths, messages, names of variables and parameters, source text, and
names of installation, upgrade and database tools.
Example text Exact user entry. These are words or characters that you enter in the
system exactly as they appear in the documentation.
<Example text> Variable user entry. Angle brackets indicate that you replace these
words and characters with appropriate entries to make entries in the
system.
EXAMPLE TEXT Keys on the keyboard, for example, F2 or ENTER.

Direct Store Delivery (Backend) ................................................................................................ 6

DSD-Specific Master Data ..................................................................................................... 9
Additional DSD Data: Driver Data .................................................................................... 10
Additional DSD Data: Vehicle Data.................................................................................. 11
Additional DSD Data: Tour Data ...................................................................................... 12
Additional DSD Data: Customer Data .............................................................................. 13
Using Geocoding .......................................................................................................... 15
Maintaining Extended Terms of Payment..................................................................... 16
Additional DSD Data: Material Data................................................................................. 17
Additional DSD Data: Deal Condition............................................................................... 18
Deal Conditions in the DSD Process............................................................................ 21
Additional DSD Data: Manual Discount ........................................................................... 23
Visit Control.......................................................................................................................... 24
Visit Control Process ........................................................................................................ 26
Roles in Visit Lists ............................................................................................................ 29
Visit Plan........................................................................................................................... 30
Editing Visit Plans ......................................................................................................... 31
Visit List ............................................................................................................................ 33
Editing Visits Lists......................................................................................................... 35
Transportation Planning....................................................................................................... 36
Loading Units.................................................................................................................... 38
Aggregation Categories.................................................................................................... 39
Tour .................................................................................................................................. 40
Shipment .......................................................................................................................... 42
Reload .............................................................................................................................. 43
Dynamic Transportation Planning .................................................................................... 45
Tour Determination ....................................................................................................... 48
Processing Individual Shipments ..................................................................................... 49
Vehicle Space Optimization ................................................................................................. 51
Vehicle Space Optimization Online.................................................................................. 53
Follow-On Processes of Vehicle Space Optimization ...................................................... 55
Picking Based on VSO Packing Proposals .................................................................. 57
Output Control...................................................................................................................... 59
Visit Plan Type in Visit Control ......................................................................................... 62
Logistics-Oriented Business Process............................................................................... 63
Sales-Oriented Business Process.................................................................................... 64
Message Control .............................................................................................................. 65
Output Processing ........................................................................................................ 66
Output Processing for Shipments ............................................................................. 67

Valuated Delivery Note.......................................................................................... 69

Output Processing for Visit Lists ............................................................................... 70
Route Accounting................................................................................................................. 72
Final Maintenance for Completing Tours ......................................................................... 74
Entering Tour Data on Mobile Devices......................................................................... 76
Download.......................................................................................................................... 77
Upload .............................................................................................................................. 78
Tour Data Entry ................................................................................................................ 79
Settlement Cockpit ........................................................................................................... 82
Processing of Tour Data in the Settlement Cockpit...................................................... 83
Processing of Visit Data in the Settlement Cockpit ...................................................... 86
Application Log ............................................................................................................. 88
Settlement Document ................................................................................................... 89
Document Flow............................................................................................................. 90
DSD Final Settlement Run ............................................................................................... 91
Inkasso-Auszifferung........................................................................................................ 92
DSD Clearing in the Background.................................................................................. 93
DSD Clearing Online .................................................................................................... 94
Direct Store Delivery Connector .......................................................................................... 95

Direct Store Delivery (Backend)

Purpose
Direct Store Delivery (DSD) is a business process that is used in the consumer products
industry to distribute goods directly to the end customer. In a Direct Store Delivery process,
distribution does not involve a retail company’s warehouse/distribution centers.
The backend is the basis for integrating a mobile solution. The mobile solution supports
drivers’ activities during the shipment process.
Implementing Direct Store Delivery enables you to:
● Make materials available to stores and customers quickly (for example, food, drink,
flowers, newspapers)
● Directly influence end customers, as the consumer products manufacturer
● Optimize process settlement in sales and in distribution
● Optimize logistics costs using efficient visit planning
The backend for DSD consists of the following subcomponents:

Master Data
In the master data for the Direct Store Delivery component, you maintain specific data for the
Direct Store Delivery process that remains unchanged over a considerable period of time and
contains information that is required repeatedly in the same format.
Visit Control
You use visit control in the Direct Store Delivery component to plan periodically recurring
customer visits carried out by drivers (different roles) on their tours, within a logistics process.
Visit control consists of a strategic part (visit plans) and an operational part (visit lists).
In visit plans, you specify, among other things, which customers are to receive deliveries or
visits in which sequence, and how often. You can also specify the drivers and vehicles to be
used for a shipment.
The system creates visit lists for set days from visit plans. You can process visit lists manually
and can therefore react to sudden or unique events. During dynamic transportation planning,
the system uses visit lists as the basis for creating shipments.
Transportation Planning
Using transportation planning from the Direct Store Delivery component, you plan and
organize tours with the aim of incorporating due deliveries into shipments.
Outbound deliveries can be:
● Incorporated manually into a single shipment using shipment transactions
● Incorporated into a single shipment or into several shipments by the system using
dynamic transportation planning
Dynamic transportation planning takes the following into account when creating
shipments:
○ Visit lists
○ Route master data
○ Different capacity criteria (optional)

Using the shipment list the system provides you with an overview of all shipments created.
From the shipment list you can access shipment maintenance.
Vehicle Space Optimization

To use vehicle space optimization in the Direct Store Delivery component, you must first
integrate an optimization algorithm from a third-party vendor using an interface.
Vehicle Space Optimization optimizes the order of delivery items for a shipment onto
packaging materials (for example, pallets) and the order of these packaging materials in a
vehicle. The system presents the results of Vehicle Space Optimization (packing proposals
for vehicle space optimization) in a colored graphic that you can print out. You can change the
order of the load in this loading graphic manually.
You use the determined packing proposals for vehicle space optimization to control picking in
the warehouse.
Output Control
You implement Output Control for the Direct Store Delivery component if you want the system
to automatically group together tour data for output control.
Route Accounting
Route Accounting begins after a vehicle is loaded and ends once all tour transactions have
been posted. DSD Route Accounting supports delivery and route sales using:
● Specific information and documents for each tour
● Entry of outgoing and incoming control data
● Entry of information and documents that drivers (with different roles) hand in after their
tour to the settlement office
● Settlement of documents and data entered with the data available in the ERP system
● Settlement of documents and data entered in the ERP system.

Drivers who have returned from a tour hand in the documents from their tour to the settlement
office, along with any handheld devices. These include, for example:
● Documents
● Cash
● Credit card documents
● New orders
● Tour data contained in a handheld

You can use Route Accounting without using handhelds. Drivers enter tour activities by hand
in the relevant documents. You can transfer this handwritten tour data subsequently in the
settlement cockpit in the system. You use the settlement cockpit to display and correct tour
data, and to enter additional data manually.
Direct Store Delivery Route Accounting is an offline solution. This means that data is
exchanged from a handheld to the ERP system at the start and end of a tour. It is not possible
to transfer data during a tour.
Implementation Considerations
● If you want to use the Direct Store Delivery component, see the current information in
SAP Note 755712.

● If you want to use the backend of the Direct Store Delivery component in your system,
you must flag the checkbox Direct Store Delivery Active.
● If you want to use the mobile part of the DSD process in your system, in the Activate
Sales Area Processes table, you must have set the identically named indicator. Once
you have set the indicator, the system activates checks in different functions (for
example, driver master, shipment). These checks are performed to ensure that the
process deals only with sales areas.
● If you want to implement Vehicle Space Optimization for the Direct Store Delivery
component in your system, you must set the Vehicle Space Optimization indicator to
active in Customizing. You must set this indicator for the system to be able to use a
third party administrator’s optimization algorithm via an interface.
Vehicle Space Optimization can only be implemented once the following

prerequisites have been met:
■ You have registered an optimization algorithm from a third party

administrator in the operating system.
■ You have set up an RFC connection.
For the system settings for the activating Direct Store Delivery and Vehicle
Space Optimization, see Customizing under Basic Functions.
● If you want to use Route Accounting from the Direct Store Delivery component in your
system, you must switch on the EA-SCM enhancement and activate the Direct Store
Delivery component in Customizing.

DSD-Specific Master Data

Use
In the master data you maintain specific additional data for the Direct Store Delivery process.
You can enter DSD-specific data for the following master data records:
● Driver
● Vehicle
● Tour
● Customer
● Material
Integration
Special fields are used to integrate specific additional data for the Direct Store Delivery
component into the ERP master data:
● DSD-specific customer data is integrated in the customer master.
● DSD-specific driver data is integrated into the customer master.
● DSD-specific vehicle data is integrated into the equipment master.
● DSD-specific material data is integrated into the material master.

Tour master data is master data that is specific for the DSD backend.

Additional DSD Data: Driver Data

Use
You can use this function to enter additional driver data in the customer master record. You
can process the additional driver data required by the DSD Backend by choosing Additional
DSD Data. The system then displays the extra tab page Driver.
Integration
The DSD-specific driver data is integrated in the customer master of the ERP system. When
you choose Additional DSD Data you are taken to the Driver tab page in the customer master.
The system treats a driver as a customer. By making the appropriate Customizing settings,
the system can clear materials and receipts/issues on the driver’s account.
Prerequisites
You need to perform the following Customizing activities so that the system can use the DSD-
specific driver data:
● Activate Direct Store Delivery

For more information, see the Implementation Considerations in Direct Store Delivery
(Backend) [Seite 1].
● Define driver’s license categories
● Specify allowed account groups for drivers
Features
When you select a customer number, the system checks whether the related account group is
defined for drivers. The system recognizes from the allowed account group that this customer
master record concerns driver master data. You can enter the following data on the Driver tab
page:
● Transportation planning points to which the driver has access
● Driver’s driving license categories
● Lock periods in which the driver cannot carry out a shipment.
If in the Customizing table Activate Sales Area Processes you have set the
identically named indicator, the system only allows you to specify one sales
area for each driver.

Additional DSD Data: Vehicle Data

Use
You can use this function to enter additional vehicle data in the vehicle master record
(equipment/fleet master). If you choose the DSD Vehicle Data tab page within the vehicle
master, you can maintain the additional vehicle data required by the DSD backend.
Integration
The DSD-specific vehicle data is integrated with the ERP equipment/vehicle master. The
additional vehicle data is found on the DSD Vehicle Data tab page.
Prerequisites
You need to perform the following Customizing activities to be able to use the DSD-specific
vehicle master data:
● Activate Direct Store Delivery and, if required, Vehicle Space Optimization

For more information, see the Implementation Considerations in Direct Store Delivery
(Backend [Seite 1]).
● Assign means-of-transport type to equipment category and vehicle type
Features
You can enter the following vehicle data on the DSD Vehicle Data tab page:
● Trailor load
● Set indicator for your own vehicle or an external vehicle
● Variable capacity
● Vehicle type for vehicle space optimization (VSO vehicle type), provided you have
activated vehicle space optimization.
● Transportation planning points
● Driver’s license categories
● Lock period(s)

Additional DSD Data: Tour Data

Use
You use this function to enter tour data for the Direct Store Delivery process.
Features
You create a tour for a route and a visit plan type. Among other things, the tour contains the
following information:
● Transportation planning point
● Driver
● Alternate driver
● Vehicle
● Trailer
The system checks if the required driver license category for the vehicle is covered by the
driver’s license category of the assigned driver.
The system uses this tour master data during dynamic transportation planning. If you create
several tours for the same route with the same visit plan type and the same transportation
planning point, the system distributes the deliveries to the shipments in Dynamic
Transportation Planning in line with the tour sequence that you created.
For more information on tours, see Tour [Seite 40].

Additional DSD Data: Customer Data

Use
Using this function you can enter additional DSD-specific customer data in the customer
master record. If you choose the tab page Additional Data DSD within the customer master,
you can maintain the additional customer data required by DSD.
The system displays the Visit Information tab page and – if vehicle space optimization is
active – Vehicle Space Optimization tab pages.
Integration
The DSD-specific customer data is integrated in the customer master of the ERP system.
Prerequisites
To use the DSD-specific customer master data, you need to activate Direct Store Delivery
and – if required – Vehicle Space Optimization. For more information, see Implementation
Considerations in Direct Store Delivery (Backend) [Seite 1].
Features
The following determine the tab pages the system displays:
● The system displays the Vehicle Space Optimization tab page if the customer is not a
driver, and you have activated Vehicle Space Optimization in Customizing.
Enter the customer-specific data that the system requires for an optimization run on the
Vehicle Space Optimization tab page.
● The system displays the Visit Information tab page if the customer is not a driver.
The system displays a selection of appropriate calendar types on the Visit Information
tab page. You can see from the calendar when a customer is to receive a delivery, or
when visits are scheduled.
The system displays the visit and delivery times in color in the calendar.
If you choose Display Visit Plans or Display Visit Lists, the system branches to the
display mode for the visit plans or lists. The system proposes the visit plans/lists in
which this customer appears in the next seven days. You cannot process visit plans or
lists within or from the customer master.
If the customer is a driver, the system displays the Driver tab page. For more
information, see Additional DSD Data: Driver Data [Seite 10].
Activities
Choose the customer’s desired visit/delivery dates.
The system displays the planned visit/delivery times for the customer in a calendar in the
customer master on the Visit Information tab page.
You can geocode the customer’s address data on this tab page. The system issues unique
coordinates (length and width degree). For more information, see Using Geocoding [Seite 15].
If Vehicle Space Optimization is activated, you can maintain data on the Vehicle Space
Optimization tab page, which will influence the optimization algorithm.
You can find system settings for the customer master data in Customizing under Customer.


Using Geocoding
Use
In customer geocoding the system determines the corresponding geographical degrees of
longitude and latitude for a customer’s address data.
Depending on the data available in the system, geocoding provides exact results, no matter
the level on which it is performed. Geocoding can, for example, be performed at country,
region, zip code, street or house number level. The geocoding data contained as standard in
mySAP ERP functions at regional and country level. If you want to perform geocoding at
house number level, for example, you must obtain and install the corresponding data for the
area in question from the third party administrator.
You can execute geocoding for a particular customer directly from the customer master (tab
page Visit Information), or for several customers using the Geocoding report. You can specify
several customers in the selection screen in the report. You can use a flag to ensure that the
system only geocodes those customers whose address data has changed.
Prerequisites
If you need geocoding to be more precise than it is at regional level, you must obtain and
install the relevant data from a third party administrator.
You must make the necessary geocoding settings in Customizing.
For more information about geocoding, see the Implementation Guide under General Settings
under Set Geocoding.
Procedure
To execute geocoding using the report, proceed as follows:
...
1. On the SAP Easy Access screen under Logistics → Logistics Execution → Direct Store
Delivery → Master Data → Customer → Geocoding.
The Geocoding screen appears.
2. Enter the required data.
3. Choose Execute.
You can also execute this report in the test run. In this case the system does not
save the data.
The Display Logs screen appears. This lists the geocoding results.
Result
The system has performed geocoding with longitude and latitude data for the selected
customer. If you have connected maps from a third party administrator, the result of the
geocoding is that the system displays customers graphically on an electronic map in visit
plans and visit lists.

Maintaining Extended Terms of Payment

Use
You use extended terms of payment to monitor the payment history of your customers more
precisely. For each customer you can store information relating to the following areas:
● Payment history
● Document transfer
● Permitted payment types
● Invalid bank details.
Prerequisites
You must have entered customers for whom you want to maintain extended payment
conditions in the customer master.
Procedure
To maintain extended payment conditions, proceed as follows:
...
1. On the SAP Easy Access screen under Logistics → Logistics Execution → Direct Store
Delivery → Master Data → Customer → Maintain Extended Terms of Payment.
The Extended Terms of Payment screen appears.
2. Enter the required data.
3. Save your entries.

Additional DSD Data: Material Data

Use
You can use this function to define DSD-specific material data in the material master record.
You access the function from the DSD Data tab page and, if Vehicle Space Optimization is
active, VSO Data and VSO Plant Data in the material master.
Integration
DSD-specific material data is integrated in the ERP material master.
Prerequisites
In Customizing, you must activate the Direct Store Delivery backend and, if required, Vehicle
Space Optimization. You can find these system settings in Customizing for Direct Store
Delivery backend under Basic Functions.
For more information, see Implementation Considerations in Direct Store Delivery (Backend)
[Seite 1].
You need to assign the following screen sequences in Customizing for the system to display
the tab pages containing the DSD-specific material data:
● Screen sequence BD for the DSD Data tab page
● Screen sequence BV for the following tab pages:
○ DSD Data and
○ VSO Data and
○ VSO Plant Data

You will find the system settings for the screen sequences in Customizing under Logistics
General → Material Master → Configuring the Material Master → Assign Screen Sequences
to User/Material Type/Transaction/Industry Sector
Features
You can assign a DSD grouping to a material in the material master, on the DSD Data tab
page.
By assigning a DSD calendar type to a DSD grouping, you can schedule appointments for
visits and deliveries for each material. This means that materials with different DSD groupings
and different calendar types can have different delivery cycles (for example, daily and weekly)
in Visit Control.
You can maintain material-dependent data that will influence the Vehicle Space Optimization
of a third party on the VSO Data and VSO Plant Data tab pages.
Activities
You can find the system settings for the material master for the Direct Store Delivery backend
in Customizing under Material.

Additional DSD Data: Deal Condition

Definition
A DSD-specific agreement for a sales deal that has a limited period and is either in the form
of free goods or a monetary rebate.
Use
You create a deal condition in the back-end system with the appropriate conditions (such as
preferred customers). If a deal condition fulfills the conditions specified in the back-end
system, the system takes the deal condition into account when preparing the deliveries for a
tour and transfers the data to the mobile device. The mobile device calculates the granted
deal condition for invoicing during the tour.
Drivers cannot create or change a deal condition on their mobile device. You
make all the settings that affect a deal condition in the back-end system.
At the end of the tour, you transfer the rebates granted with the other tour data to the back
end. The system includes all the tour data in the final settlement run, including the granted
rebates.
You can display lists for the deal conditions and the resulting discounts and free goods
discounts.
Structure
Header Data
You specify which general settings you want to be valid for a deal condition in the header
data.
● Name and description of the deal condition
● Deal condition type
● Validity period
● Status
Assignments
You specify in the assignments which customers are entitled to a deal condition (inclusive
assignment) and which are not (exclusive assignment).
A deal condition is transferred to the mobile device at the start of a tour only for customers
who fulfill the assignments as follows:
● “And” condition
The current delivery for the customer must fulfill the conditions specified in the deal
condition for the following fields:
○ Sales organization
○ Distribution channel
○ Division
○ Plant

The system only considers the fields with entries for the deal condition.
● “Or” condition
Any of the following data can serve as additional conditions:
○ Customer
○ Customer Groups
○ Higher-Level Customer
You have defined the following conditions:
■ Sales organization 001
■ Distribution channel 555
■ Customer 1234
■ Customer group 4321

This deal condition is only valid for customer 1234 of sales organization 001 and
distribution channel 555, or for all customers in customer group 4321, sales
organization 001, and distribution channel 555.
Conditions
Here you define which conditions must be fulfilled for a deal condition in a delivery, so that the
mobile device applies a deal condition. You can use several variants of the conditions.
The following dependencies between material, merchandise category, and

material group apply for the conditions:
■ If you have specified a material for a deal condition, you cannot

additionally determine a merchandise category or material group.
■ If you have specified a merchandise category or material group for a

deal condition, you cannot additionally determine a material.
For example, you can define the following conditions so that a deal condition is valid:
● Which material can be in a delivery and what quantity of the material.
● Which material must be contained in a delivery.
● Whether a specific total sales quantity must be reached in a delivery across all
materials specified in the deal condition.
For the total sales quantity, the system only considers materials whose target quantities
are reached or exceeded in the delivery.
Result
You specify how you want the customer to benefit from the deal condition in the results:
● You define the calculation base (fixed or proportional).
● You define whether the customer receives the deal condition as free goods, or as a
value or percentage discount.
● You define whether or not the driver is free to choose or reject the deal condition
proposed by the system (whether or not the deal condition is obligatory).

If a deal condition is obligatory and the delivery fulfills the criteria, the mobile
device applies this deal condition automatically.
If a deal condition is not obligatory, the driver can activate the deal condition on
the mobile device.
The system considers an active deal condition when creating the invoice.
Integration
The deal condition is part of the DSD process and can be used in connection with mobile
devices.

Deal Conditions in the DSD Process

Purpose
You can use this process to link a material or monetary rebate to specific conditions. This
creates buying incentives for the customers who are visited by a driver on a tour.
Prerequisites
You use mobile devices in your DSD process.
Customizing (Back End)

● You have set the DSD Active indicator in Customizing for Logistics Execution under
Direct Store Delivery → Basic Functions → Activate Direct Store Delivery.
● You have made settings for the following areas in Customizing for Logistics Execution
under Direct Store Delivery → Deal Condition:
○ Deal condition types
○ Field selection
○ Customer hierarchy type for each sales area
● In Customizing for Logistics Execution under Direct Store Delivery → Handheld

Connectivity → DSD Connector Settings → Mobile Device Settings → Specify
General Settings → Define Condition Types for Deal Condition Discounts, you have
specified the valid condition types for the deal condition.
DSD Connector
You have made settings for the following areas on the SAP Easy Access screen by choosing
Logistics Execution → Direct Store Delivery → Handheld Connectivity → DSD Connector
Cockpit:
● Driver/vehicle assignment
● Driver master
● Vehicle master
Process Flow
The deal condition is integrated into the DSD process as follows:
...
1. You enter the DSD-specific master data for a deal condition in the back end.
2. You create a delivery and shipment based on a sales order.
3. The system transfers the data on the deal condition together with the tour data.
The system transfers all deal conditions that are valid for a customer on the day
of the tour to the mobile device.
Note that if you want to give free goods discounts, the vehicle must be loaded
with the relevant materials.
4. The driver starts his or her tour as part of the DSD process.
5. The mobile device takes account of all active deal conditions for invoicing.

Depending on the system settings for the deal condition, either the mobile
device automatically takes account of an active deal condition for invoicing, or
the driver can activate or deactivate the deal condition manually.
6. The driver completes the tour and returns to the distribution center.
7. You transfer the tour data to the system (back end), including the results of the deal
condition.
8. You complete the tour in the back end with the final settlement run. The back-end
system includes the deal condition data in the final settlement run.

Additional DSD Data: Manual Discount

Definition
A condition that the driver can grant to the customer for deliveries during a tour. These
conditions are generally discounts such as price markdowns. Whether or not drivers can give
manual discounts depends on their authorizations.
Use
Drivers can use predefined conditions in the delivery process during a tour. The driver
decides whether to offer specific conditions to a customer, and which conditions to offer. The
driver can grant these discounts at item level and header level in a delivery (depending on his
or her authorizations).
For price determination, the mobile device treats the manual discounts in the same way as
regular price conditions.
At the end of the tour, the tour data including the manual discounts (with condition type,
amount, currency or percentage value) are transferred from the mobile device to the back end
for processing in the final settlement run.
The back end displays the absolute discount or percentage values for manual discounts at
header level and item level of the delivery, and uses this data to complete the tour.
Integration
You use mobile devices in your DSD process.
Customizing
You have set the DSD Active indicator in Customizing for Logistics Execution under Direct
Store Delivery → Basic Functions → Activate Direct Store Delivery.
You have defined the required conditions in the back end.
In Customizing for Logistics Execution under Direct Store Delivery → Handheld Connectivity
→ DSD Connector Settings → Mobile Device Settings → Define Mobile Device Settings, you
have activated granting of discounts at global level or for specific groups.
For each sales area, you have specified the condition types for manual discounts that are
relevant for the mobile device in Customizing for Logistics Execution by choosing Direct Store
Delivery → Handheld Connectivity → DSD Connector Settings → Mobile Device Settings →
Specify General Settings → Define Condition Types for Manual Discounts.
See also:
DSD Final Settlement Run [Seite 91]

Visit Control
Use
You use visit control in the Direct Store Delivery component to plan and execute periodically
recurring customer visits in the logistics process.
Visit control consists of visit plans and visit lists, and how they are used and integrated into
the supply chain.
Visit plans are used for long-term, strategic planning. In visit plans, you group together
customers that you want to visit or make deliveries to in one tour. You can assign drivers and
vehicles, among other things, to visit plans. In a visit plan, you can maintain set non-
appointments for every assigned customer. This simply states a time when the customer
should not be visited or have deliveries made.
The system creates visit lists for set days from these strategic visit plans. If necessary, you
can adjust these manually and can use them in operational business.
You use the following visit lists:
● In logistics for planning shipments
● In sales for controlling visits

Visit control defines in which order the driver will visit or deliver to the group of customers
entered in the visit plan/list for a particular day. If you want to manually change the given
order you must take the following into consideration:
● Visiting and opening times
● Geographical location of customers
● Periodicity with which customers are contacted (for example, on Friday once a
fortnight)
Visit control is aimed at two user groups with different roles:
● Individuals (roles) who create and manage, or can view, visit plans and visit lists:
○ Strategic planner
○ MRP controller
○ Administrator in sales-office-based personnel
○ Order entry administrator
● Individuals (roles), for whom visit lists can be created:
○ Delivery Driver [Seite 29]
○ Sales Driver [Seite 29]
○ Mixed Driver [Seite 29]
○ Preseller [Seite 29]
If you want to include electronic maps in visit control, you must implement and use a graphical
information system (GIS) from an external provider using the Internet Graphic Server (IGS).

If in the Customizing table Activate Sales Area Processes you have set the
identically named indicator, the system creates the visit plan or visit list in
dependence on the sales area. The system checks whether the assigned
customers have been created in the specified sales area.

Visit Control Process

Use
Visit control offers you many possiblities, from planning customer visits strategically (basis
Visit Plans [Seite 30]) to actually performing them (basis Visit Lists [Seite 33]).
Visit control groups together customers that are regularly visited or have deliveries made to
them on periodically recurring days (for example, every Wednesday). You can also assign a
driver, and if necessary, a co-driver and a vehicle (tractor and, if necessary, a trailer) to each
visit plan.
The system uses the visit plans to generate visit lists for specific days during a set time
period. You can adjust these visit lists manually. You can, for example, insert an additional
customer, remove an existing one or change the vehicle or the driver. In practice, visit lists
are used as the basis for planning shipments, in other words, for goods deliveries and
controlling customer visits.
Process Flow
Ideally, Visit Control functions as follows:
...
1. Maintain visit plan

When planning a visit plan you create and manage visit plans.
2. Generate visit lists
The system uses a report of visit plans to create visit lists for a specific period of time.
This means that the system uses the regular objects in a visit plan (for example, every
Monday) to create a visit list for every applicable day in a regular object within the
specified period.
Before the system saves a newly created visit list you can specify a means of
transport and a driver by implementing a BAdI method.
3. Process visit lists manually

Visit lists form the basis of day-to-day activities. Visit lists display which customers are
to be visited in which order on a set day. They may already state the driver and/or the
vehicle involved.
If changes are made at short notice in day-to-day activities because of a public holiday,
you can make the appropriate changes to the visit list by manually inserting or
removing a customer.
○ Cancel a visit to the customer in question
○ Change visit to another date (and to another visit list).
We recommend that you delete visit lists that were not processed because of a
public holiday, after you have transferred the affected customers to other visit
lists.
You can move an entire visit list to another day by manually changing the
execution date of the visit list.
Note that corresponding visit plans are not affected by changes to visit lists.

4. Map customer appointments as a time stream

The system saves all visit or delivery appointments for a customer as a time stream.
The system determines these appointments from the rule objects in the visit plans,
taking into account possible non-appointments and the visit lists that have already been
created and may have been adjusted manually.
The visit plan category for a visit plan or visit list is very important when creating time
streams. In Customizing, you can assign a calendar type to every visit plan category.
Based on this Customizing setting, the system can create several time streams for a
customer for each calendar type, for example, a time stream for outbound
appointments and one for visit appointments.
If you have not assigned any calendar type to a visit plan category the system will not
create a time stream.
The system creates a time stream, as standard, for each year.
The system uses these time streams in order processing to determine a customer’s
required delivery date, as long as you have flagged the underlying order type as DSD-
relevant in Customizing, and have assigned the relevant calendar type.
The system creates a time stream either using the report /DSD/VC_CAL_FILL, which
you can schedule as a regular background process, or automatically following the initial
request from the system regarding these appointments. The system needs the time
stream
○ In order entry when determining the required delivery date, based on planned
visit/delivery appointments, using visit control and
○ In the customer master (DSD Additional Data pushbutton, Visit Information tab)
when selecting a calendar type. As soon as the time stream is available, the
determined appointments appear in color in the calendar.
5. Order processing
For visit/delivery appointments planned with visit control to be taken into account in
order entry, you must flag the order type used as DSD-relevant in Customizing, and
must also assign a calendar type.
As soon as you have created an order with a flagged, corresponding order type, the
system uses the assigned calendar type and the minimum lead time to check the next
date planned for a visit/delivery to this customer, and then enters this as the required
delivery date. The system takes this date from the customer’s time stream. If there is
still no time stream available, the system creates the time stream when it creates the
order.
If the visit list/plan that underlies this appointment has a route, the system incorporates
this route in the order. Otherwise the system carries out SAP standard route
determination.
6. Dynamic Transportation Planning
Using dynamic transportation planning the system automatically groups deliveries to
form shipments. Visit lists are a tool for determining the itinerary sequence when
creating a shipment and, in some cases, may also specify a vehicle and a driver. The
system updates the numbers in the underlying visit lists created for shipments using
dynamic transportation planning.
Note that if changes are made to shipments the same changes are not
automatically made to visit lists.

If in the Customizing table, Activate Sales Area Processes you have set the
identically named indicator, the system only assigns deliveries with the same
sales area (as the underlying visit list) to a shipment. The system also checks
whether the assigned driver is created in this sales area.
For more information about dynamic transportation planning, see the documentation for
Transportation Planning [Seite 36] in the Direct Store Delivery component.
7. Route Accounting
As soon as deliveries/visits have been performed and the drivers have returned to the
plant, all the existing data must be processed. Further processing is performed with
Route Accounting [Seite 72] in the Direct Store Delivery component. Route Accounting
considers whether there was an underlying shipment or visit list for the deliveries/visits
performed.
○ Successful deliveries, goods sold, or orders received are documented using

order creation and change (optional), and deliveries.
○ The system creates an SD sales activity for an unsuccessful visit, in other

words, a visit for which no delivery exists and no order/deliver can be created,.
This SD sales activity details why the visit was not performed. The system
updates the document number of this SD activity type in the underlying visit list
for the corresponding customer.
For more information about route accounting, see the documentation for Route Accounting
[Seite 72] in the Direct Store Delivery component.

Roles in Visit Lists

You can create visit lists for different people (roles):
Delivery driver
Driver who visits customers with the intention of delivering ordered goods. This means that
deliveries already exist for these customers in the system.
The delivery driver visits customers in the sequence in which they are listed in the shipment.
In automatic shipment creation performed with dynamic transportation planning, visit lists
were used as proposals for the itinerary.
Sales driver
Driver who visits customers with the intention of selling goods. For this purpose a sales driver
drives around with a speculative load. If customers give drivers an order, the drivers takes the
goods from their vehicles and give them to the customer.
The sales driver visits customers in the sequence in which they are listed in the visit list. The
shipment only contains the speculative load, which is the delivery that has been issued to the
driver.
Mixed driver
The mixed driver is a driver who visits customers as both a delivery driver and a sales driver.
The mixed driver visits customers for the following reasons:
● To deliver ordered goods
● To sell goods from their speculative load

The mixed driver visits customers in the sequence in which they are listed in the visit list. In
addition to the speculative load, which is the delivery issued to the driver, the shipment also
contains deliveries for customers.
Preseller
Sales employee who visits customers with the intention of collecting orders. The preseller
does not bring any goods with them.
The preseller visits
● Potential customers to collect new orders
● Existing customers to collect additional orders.

The delivery driver then delivers new or additional orders on their next tour.
The preseller visits customers in the sequence in which they are listed in the visit list.

Visit Plan
Use
You use visit plans to plan customer visits and deliveries that recur periodically as part of the
logistics process.
In the general data for the visit plan you specify:
● The validity period of the visit plan
● How frequently the visit plan is carried out (once a week on Tuesdays, for example)
● The visit plan type
● Which vehicle is assigned to the visit plan (optional)
● Which driver is assigned to the visit plan (optional)

You then assign a visit plan the customers to whom the specifications in the general data of
the visit plan category apply, and whom you want to visit or make deliveries to during a tour.
The system can display the customer’s goods receiving times or visit times at customer level
in the visit plan. In Customizing for Visit Control, you specify which source you want the
system to use for the times. The sources can either be the goods receiving times for the
unloading point or the visit times of the relevant contact person. You process both sources in
the customer master.
In addition, you can also process no-delivery dates for each customer. The are a subset of
the rule object for the visit plan and describe specific dates on which the customer should not
be visited or receive deliveries. Customers are also not visited if you flag them as inactive. If
there is a non-delivery data or an inactive indicator for the customer, the system makes sure
the customer does not receive any deliveries, by omitting them from the visit lists.
If you have installed a third-party map and geocoded your customer address data, you can
display the customers contained in a visit plan on the map. All customers assigned to a visit
plan are linked to one another. This allows you see at a glance whether it makes geographical
sense to group the customers in the same visit plan.
Based on the visit plan, the system creates the visit list [Seite 33] that you can use for your
day-to-day work.

Editing Visit Plans

Use
You use the Visit Planning functions to edit new or existing visit plans.
You use visit plans to plan customer visits and deliveries that recur periodically as part of the
logistics process. From a worklist, you choose customers with certain common criteria
(general data on visit plan type), which you then add to a visit plan. You also edit the itinerary
for visit plans. The driver specified in the visit plan visits or makes deliveries to the customers
assigned to the visit plan on a route.
Features
The following functions are available for editing visit plans:
● Create visit plans
● Maintain visit plans
● Display visit plans
Activities
In the general data for the visit plan you specify:
● The validity of the visit plan
● How frequently the visit plan is carried out (once a week on Tuesdays, for example)
● The visit plan type
● Which vehicle is assigned to the visit plan
● Which driver is assigned to the visit plan

At customer level in the visit plan, you can display the goods receiving hours or visit times as
stored in the customer master data.
In Customizing for Visit Control, you specify which master data source you want the Visit
Control function to reference for data on goods receiving hours and visit times. You specify
the source for each visit plan type. The sources can either be the goods receiving times for
the unloading point or the visit times of the relevant contact person.
You can also maintain non-appointments for each customer. Non-appointments are a subset
of the rule object for the visit plan and describe specific dates on which the customer should
not be visited or receive deliveries. You can also flag a customer as inactive. If there is a non-
appointment or an inactive indicator for a customer, Visit Control makes sure the customer
does not receive any deliveries by not including him or her in the visit lists.
If you have installed a third-party map and geocoded your customer address data, you can
display the customers contained in a visit plan on the map.
The system uses symbols to represent customers and connects these symbols with a line,
according to their sequence in the visit plan. If you want the visit plan to be shown along with
the relevant customers on the map, choose Update GIS.
Based on the visit pan, the system creates the visit list, which you can use for your day-to-day
work.
When modified visit plans are saved, Visit Control checks whether there are
already visit lists containing future visits or deliveries for the modified visit plans.

Visit lists that have already been created are listed for information in a dialog
box. You can cancel the procedure for saving the visit plans in the dialog box.
Visit Control does not automatically copy changes that are made to the visit
plans to existing visit lists.

Visit List
Definition
List of customers for a particular day in a given sequence. The visit list determines:
● The order of the visits
● The date of the visits
● Which driver visits the customers
Use
You use visit lists as a basis for making your customer visits and deliveries.
Visit lists are compiled from visit plans but do not have to be a one-to-one copy of the plans.
The visit plan and visit list may be different if
● You have set the inactive indicator for a customer in the visit plan
● You have excluded a customer from the visit list on a particular

date by specifying a non-appointment in the customer’s rule
object
● You have added or deleted customers manually in the visit list.
If you edit visit lists manually, you can
● Add and delete customers
● Change the sequence of customers
● Change general data in the visit list
● Change the driver
● Change the vehicle
● Move the entire visit list to a different day

You can assign a visit list reference documents at customer level and at visit list header level.
The reference document is an existing document number with the sales document object.
Assigned reference documents can influence how the visit list is carried out. For example, you
can assign the document number of the speculative load (delivery document) to a visit list
with a visit plan type that represents a van seller. If the visit plan type represents a mixed
driver, you can specify the numbers of the delivery documents that the mixed driver has to
deliver to the customers at customer level.
You assign the reference documents in visit list editing by selecting a visit list or customer and
choosing Edit → Reference Documents.
As well as the reference documents that are relevant before the visit list is
carried out, there are also reference documents that are entered by the system
after the visit list is carried out. These reference documents are used to log the
customer visits. The system can create an SD sales activity document for an
unsuccessful customer visit, for example, specifying the reason for that fact that
no order was generated.


Editing Visits Lists

Use
You can use the visit list functions to edit the templates that determine the order of a driver’s
customer visits and deliveries on a particular day.
The Visit Control function creates visit lists from visit plans. Visit lists do not have to be a one-
to-one copy of visit plans.
Features
The following functions are available for editing visit lists:
• Generate visit lists
• Maintain visit lists
• Display visit lists
Activities
When the Visit Control function creates visit lists, it does not overwrite existing lists. If you
want to create a visit list from a visit plan for a period for which there is already a visit list in
the system, Visit Control does not create a second visit list.
If you only specify the creation date (To date) and leave the From date field empty, the Visit
Control function automatically determines the creation date, the From date, for each visit plan.
You can create visit lists in simulation mode.
To display the error log, choose Goto → Log → Generation errors.

Transportation Planning
Use
Using transportation planning from the Direct Store Delivery component you plan and
organize tours with the aim of grouping outstanding deliveries into shipments. You can then
execute the shipments.
Transportation Planning includes the following functions:
● Dynamic Transportation Planning for creating shipments while taking account of, for
example, visit lists, tour master data and capacity criteria.
● Shipment for manual planning of individual shipments
● Shipment List for a better overview and simpler processing of the shipments that have
been created
The system executes transportation planning using the following data records:
● Driver (customer master record)
● Vehicles (equipment/vehicle master record)
● Tours (assignment of drivers and vehicles to tour master records)
● Visit lists
Integration
Transportation Planning is part of the Direct Store Delivery component and is integrated into
the logistics process. Visit Control takes place before Transportation Planning. Vehicle Space
Optimization (optional) and Route Accounting take place after Transportation Planning.
For more information, see Visit Control [Seite 24], Vehicle Space Optimization [Seite 51] and
Route Accounting [Seite 72].
Transportation Planning uses DSD-specific master data. For more information about DSD-
specific master data in transportation planning, see DSD-Specific Master Data [Seite 9].

Transportation Planning Sequence

in the Document Flow
Order Delivery Shipment Billing

Doc.
1 2 3
1 – Transportation Planning
2 – Vehicle Space Optimization (opt.)
3 - Route Accounting
Features
Dynamic Transportation Planning has the following characteristics:
● You can use Dynamic Transportation Planning to group shipments for the deliveries
that require transportation and that have at least the same:
○ Visit plan type
○ Transportation planning point
○ Route
● If you have assigned a vehicle, a trailer, a driver and a second driver in the Visit List or
in the Route Master, the system assigns the relevant data to the individual shipments.
The system manages drivers, second drivers, vehicles and trailers in the customer
master and in the equipment/vehicle master.
In the Customizing table, Activate Sales Area Processes, you have set the
identically named indicator, the system checks that the deliveries assigned
belong to the same sales area, and that the driver assigned has been created in
this sales area.

Loading Units
Use
You use loading units as another capacity limit with which you can limit the maximum delivery
quantity for a vehicle in Dynamic Transportation Planning in the DSD process.
A loading unit is a unit of measure that does not depend on the units of measure in order
processing.
Prerequisites
You have activated the capacity limit loading unit in Customizing (Define Capacity Limit).
Activities
The system calculates the total quantity in the loading unit in the order and in the delivery,
and displays the loading unit together with the aggregation categories. For information
purposes, the system also displays the loading unit in the shipment as a total of the combined
deliveries in the shipment. For conversions within the loading unit, the system uses the
conversion factor that you defined in the material master.
Dialog Box Example:

Loading Units and Aggregation Categories
Loading units and aggregation categories
Document number 4711
Picking view
Barrels 5
Crates 10 Aggregation
Containers 0 categories
….. …
Loading View
Loading units 2 Loading

units

Aggregation Categories
Use
Aggregation categories are enhanced article master data. You use aggregation categories to
total the quantities of all the items in an aggregation category in a document.
The system can perform aggregation for the following documents:
● Sales order
● Delivery
● Transportation
In the beverage industry, for example, aggregation categories allow you to

estimate the volume of an order in crates, irrespective of what is contained in the
crates.
Prerequisites
● To use the aggregation categories you must specify in Customizing (Customizing table
Define Categories of Totals Fields) which of the four proposed aggregation categories
you wish to use, and what their description should be (for example, barrels, crates).
● In Customizing for the material master you must have assigned the screen sequence
BD (when using DSD without vehicle space optimization) or BV (if you are using DSD
vehicle space optimization).
● In the material master in the DSD Totals view, you must have selected one of the listed
aggregation categories, have assigned a unit of measure, and have processed the
corresponding conversion factor.
● The aggregation categories are only visible in the material master when you have
specified a sales area.
Activities
You enter customer-specific descriptions for aggregation categories in Customizing
(Customizing table Define Categories of Totals Fields). The number of aggregation categories
is limited to four.
In the order and the delivery the system displays the aggregation categories with the Loading
Units [Seite 38].
The system calculates and displays aggregation categories in orders, deliveries and
shipments as follows:
● In an order the system calculates aggregation categories dynamically and does not
save them.
● In a delivery the system calculates and saves aggregation categories.
● In a shipment (shipment list) the system displays aggregation categories in the Direct
Store Delivery.

Tour
Definition
Combination of route, visit plan type and additional data.
In addition to the route and visit plan type, you can enter additional default transportation
values (such as tractor, trailer, driver, and alternate driver) and the following capacity limits:
● Number of stops
Before the capacity limit Number of Stops is taken into account in Dynamic
Transportation Planning, you must activate the relevant criterion in Customizing
for DSD Transportation Planning. You do this in the SAP Reference IMG under
Logistics Execution →Direct Store Delivery → Transportation Planning → Define
Capacity Limits.
● Maximum duration
If you want transportation planning to take account of the maximum duration

capacity criterion for dynamic transportation planning, the following prerequisites
must be fulfilled:
● The relevant capacity limit must be activated in Customizing.

You do this in the SAP Reference IMG under Logistics Execution
→Direct Store Delivery → Transportation Planning → Define Capacity
Limits.
● The durations Travel duration, Direct travel duration, and Waiting

time must be defined for each customer in the visit list.
If you have entered default values for these durations in the Customizing
settings for the visit plan type, the system will use these in the visit lists.
Based on these durations, the system determines the total duration in
Dynamic Transportation Planning and compares it with the maximum
duration.
The total duration is determined as follows:
○ Direct travel duration from starting point to first ship-to

party
○ Plus waiting time at first ship-to party
○ Plus travel duration from first ship-to party to next
○ Plus waiting time at next ship-to party
○ Plus travel duration from previous ship-to party to last
○ Plus waiting time at last ship-to party
○ Plus direct travel duration from last ship-to party to

destination point
The system cannot calculate the exact total duration until it knows which
customer was the last customer of the tour. The system needs this

information to calculate the travel duration from the last customer to the
destination.

Shipment
Definition
A shipment represents a physical goods movement between two or more locations.
For the system to create a shipment, shipping-relevant deliveries must exist.
Use
You use Transportation Planning to group pending deliveries into shipments and then to
perform the shipments.
The outbound delivery documents contain routes that the system calculates in route
determination, and a transportation planning date for the delivery.
Dynamic transportation planning is responsible for grouping together outbound deliveries into
shipments that have at least the same route, visit plan type and the same transportation
planning date.
The following restrictions can be taken into account for a shipment in Dynamic Transportation
Planning:
● Weight
● Volume
● Number of stops
● Loading units

Reload
Use
You can use this function to define which additional materials should be loaded onto the
vehicle during a tour, or unloaded before the end of the tour.
The driver interrupts the current tour and returns to the distribution center for a
stop-off to load additional material onto the vehicle, or unload material that is no
longer required. At this point, the back end transfers the changes in quantity
made for each material during the process. The vehicle stock is updated
accordingly on the mobile device. The driver can then continue the tour.
Reload as part of the tour process
Final
Check-out
check-in
Start of End of tour

tour
Tour
Driv er notif ication:

Change to v ehicle stock
required
Prov ision Back end:

of required Entry of
material new data
Interruption to tour
Reload check-out Data transf er & Reload check-in

(optional) physical reloading/unloading (optional)
Integration
The function is designed for use on mobile devices and for paper-based processes.
You can use the check-in and check-out functions for this process.
For more information, see Entering Tour Data on Mobile Devices.
When checking in or out during a stop-off, you can only enter the current vehicle
stock quantities.
Prerequisites
● The tour must be started but not yet completed.
● You can only reload or unload materials for a delivery if you already transferred the
materials during the initial data transfer on the mobile device before the start of a tour.

Features
● You can use transaction /DSD/SV_RELOAD to create a document for a shipment in
the back end. You enter the material data concerning the reload in this document. You
can enter data on the materials that have been reloaded or unloaded in the same step.
The system can handle up to 99 stop-offs, which are stored in the back end as
the reload sequence.
Based on the document created, you can generate and print a material list showing the
materials that have been reloaded and the relevant quantities. This list can be accessed by
the driver or senior storeperson.
If drivers synchronize their mobile device before resuming the tour, the system automatically
updates the stock data on the mobile device.
You can only change the reload data if it has not yet been transferred to the
mobile device. Once the data has been transferred, you can no longer make
changes.
Goods movements must be made separately.
Materials that are reloaded during a stop-off are initially debited to the driver. The system
does not post these materials to the relevant customer accounts until the final settlement run.
Example
A delivery driver is on a tour. He or she delivers the materials that have been ordered to the
first three customers. Everything goes according to plan. What is not planned, however, is for
the driver to receive returns and empties. He or she still has four customers who want to
purchase more material than they had originally ordered, that is, more than is already on the
vehicle. The driver realizes that the vehicle stock will not be sufficient for the remaining
deliveries. The driver informs the distribution center of the planned changes during the tour.
He or she then returns to the distribution center to update the vehicle stock. The driver
unloads the returns and the empties and loads the missing material. The driver then
continues the tour with the updated data on the mobile device.

Dynamic Transportation Planning

Purpose
In Dynamic Transportation Planning you can select deliveries according to various criteria and
then group them together to make shipments. Visit lists form the basis for the grouping and
the sequence of deliveries in shipments. The system must create these visit lists before it can
create shipments. You can select visit lists in Dynamic Transportation Planning according to
Visit plan type, Execution date and Route.
The system identifies tours for a particular route and visit plan type, and creates the
shipments in the correct order.
When executing Dynamic Transportation Planning, the system takes account of the capacity
limit you have activated. Possible capacity limits are:
● Usable load
● Volume
● Number of stops
● Loading units
Dynamic Transportation Planning has the following features:
● Grouping of several shipments with a single call
● Evaluation of visit lists for the order of the customer visits and, if available, the vehicles
and drivers to be used
● Evaluation of the tour master for the sequence of shipments and the tour staffing (if
this has not been predetermined by the visit list)
● Consideration of the active capacity criteria when creating shipments
● Listing of the compiled shipments as a proposal (simulation run) or for direct creation
● Automation of all process steps
● Consideration of speculative loads (deliveries, whose ship-to party is the driver for the
visit list) that can be assigned directly in the visit list header or that can be recognized
as speculative loads from their ship-to parties.
● Consideration of deliveries that are directly assigned to a customer in a visit list
Process Flow
...
1. You can access the Dynamic Transportation Planning component from the SAP Easy
Access screen by choosing Logistics → Logistics Execution → Direct Store Delivery
Backend → Transportation Planning → Dynamic Transportation Planning.
2. The system selects the deliveries according to the information that you enter.
The route contained in the deliveries is an important control parameter. The system
uses the route to determine the tours, which in turn determine the vehicles and drivers.

Dynamic Transportation Planning only takes account of deliveries whose

delivery type is flagged for Transportation Planning in DSD Customizing.
If several deliveries for the same ship-to party are selected, Dynamic
Transportation Planning treats these deliveries as a complete delivery.
3. The system selects the visit lists according to your entries. You can limit the selection
according to visit plan type and route. The input field for the execution date of the visit
lists is a mandatory field. The system only selects visit lists that are flagged as active
(inactive indicator is not set) and for whose visit plan types the shipment document is
flagged as a relevant document.
4. The system sorts the visit lists according to the following sort criteria and evaluates the
visit lists in the sorted order:
a. Visit plan type
b. Route
5. The system selects the explicitly assigned deliveries.
6. The system identifies the speculative loads.
7. The system groups together the deliveries for a visit list.
8. The system assigns the selected deliveries to the first shipment in the order specified.
Assuming you have determined the capacity criteria and activated them in
Customizing, the delivery data (weight, volume, loading unit and variable capacity) is
compared with the limits defined in the vehicle master of the assigned vehicle. As soon
as one of the limits is exceeded, the system does not assign any more deliveries to the
shipment.
Whether the system assigns the remaining deliveries from the visit list concerned to
other shipments or whether it disregards the remaining deliveries and starts evaluating
the next visit list depends on several different factors.
Apart from capacity restrictions, the system distributes the remaining deliveries to other
shipments if:
○ No vehicle or driver is entered in the visit list.
○ No speculative load is entered in the visit list.
○ No speculative load was identified for the visit list concerned in the deliveries
selected initially.
○ The shipment document is flagged as a relevant document in the visit plan type
of the visit list.
If the capacity limit of the vehicle is reached in the second shipment as well, the system
creates a third shipment. The system repeats this process until all the selected
deliveries have been assigned.
In addition to the capacity limits you have defined in the vehicle master for each
vehicle, the system also checks – if activated - the limit for the number of stops and the
time limit (maximum duration).
The limit for the number of stops means that the system can only assign the number of
deliveries or ship-to parties within this limit to a shipment. The system treats all
deliveries for the same ship-to party as a single delivery.
Speculative loads have no effect on the calculation of the number of stops and the
duration. The systems regards customers who are entered in the visit list but are not
receiving a delivery as a stop and also takes them into account when calculating the
duration.

For the system to be able to use the time limit properly, you have to arrange your
customers in a realistic itinerary and maintain the corresponding times. Only if these
prerequisites are met will the system be able to calculate the times during dynamic
transportation planning and compare them with the maximum duration limit.
As soon as an active limit is reached, the system closes the shipment and creates
another one, provided the above-mentioned prerequisites are fulfilled. The system
always checks the limits in the following sequence:
a. Usable load
b. Volume
c. Number of stops
d. Variable capacity
e. Duration
f. Loading units
You can use the Number of Attempts indicator in Customizing for the visit plan
type to influence dynamic transportation planning.
If the Consider New Customers checkbox is flagged in the Rules area of the
Dynamic Transportation Planning selection screen, the system groups together
the deliveries that it could not assign to a shipment (because no suitable visit list
was evaluated) into shipments according to the following criteria:
■ The system creates route-specific shipments.
■ The system does not assign deliveries without a route to a shipment.
■ The system uses the visit list type entered in the Visit Plan Type for New
Customers field on the selection screen, and the route for the delivery to
find which tour master is to be used.
■ If stipulated by the visit plan type, the system only creates one shipment
per route.
Once the system has completed Dynamic Transportation Planning, it displays the
corresponding log. You can navigate from the log to the display of the delivery. Once
Dynamic Transportation Planning has been performed, you can branch to the shipments that
have been created.
We recommend that you check the shipments created by the system after the
production run, that is, after Dynamic Transportation Planning.
To check the shipments created by the system, call the Shipment List for DSD
Transportation Planning and display the shipments.

Tour Determination
Use
The system uses tour determination during Dynamic Transportation Planning.
The system also uses tour determination when creating shipments (manually) for entering
default values in the following shipment header fields:
● Tractor
● Trailer
● Driver
● Alternate driver
Process Flow
9. The system uses tour determination in Dynamic Transportation Planning as follows:
If no vehicle or driver is specified in the visit list, the system uses the route, visit plan
type, and transportation planning point to read the first tour. The system adopts the tour
data (tractor, trailer, driver, alternate driver) and the capacity limits Number of Stops
and Max. Duration from the tour. The system assigns deliveries to the tractor and trailer
until there are no deliveries left to be distributed, or until the first capacity limit has been
reached. If one of the named criteria is met, the shipment is completed in the system. If
the settings for the visit plan type allow this, the system reads the second tour and
assigns the other deliveries.
10. For manual creation of shipments the system uses tour determination as follows:
If you enter a route and a sequence number in the shipment header, the system uses
the visit plan type for which the Manual shipment flag is set in Customizing to read the
relevant tour. The system copies the values maintained during this tour for tractor,
trailer, driver, and alternate driver to the fields with the same name in the shipment
header.

Processing Individual Shipments

Use
Use these functions if you want to manually process individual shipments, as opposed to a
group of several shipments with Dynamic Transportation Planning.
Prerequisites
You can include shippable deliveries in the shipment when manually creating shipments. All
deliveries that meet the following prerequisites are considered shippable:
● The delivery type must be relevant for shipping.
● At least one delivery item category in the delivery must be relevant for shipping.
● The delivery must contain a route, and the delivery must be relevant for shipping.
● The delivery header must not contain a reason for blocking the shipment.
● The deliveries must have a transportation planning status other than C (completely
processed).
Note regarding driver’s license category:

When you create a shipment, the system reads the driving license categories in
the driver and vehicle masters to determine whether the driver is authorized to
drive the selected vehicle. Therefore, the number of driving license categories
assigned to the vehicle has to be a partial quantity of the number of driving
license categories assigned to the driver. If this is not the case, the system
displays an error message.
Features
The following functions are available for processing individual shipments:
● Creating Individual Shipments
● Changing Individual Shipments
● Displaying Individual Shipments

Using these transportation planning functions you can:
● Manually enter information on shipment header fields
● Manually select deliveries
● Include deliveries in a shipment
● Make the system propose the tour data (vehicle, trailer, driver, passenger) from the
tour master by entering a route and sequence number in the shipment header
Activities
Create Shipment
...
...
1. You enter the necessary data for the fields in the shipment header.
2. You select the deliveries you require.

You can use various selection criteria such as shipping point, ship-to party,
route, destination, due date, shipping agent, and others to influence the
selection of deliveries for the shipment. To simplify selection, you can define a
selection variant for selecting deliveries in Customizing for each shipment type.
3. In the following overview, Transportation Planning assigns the selected deliveries to the
shipment that has been created.
In this view, you can manually remove deliveries from the shipment. You can
also manually add deliveries that have not yet been allocated to a shipment.
You can change the sequence of the deliveries in the shipment using drag and
drop. If you move deliveries to a shipment, or remove deliveries, a dialog box
appears if required. The dialog box shows that there are more deliveries in the
shipment for the same ship-to party.
4. If you highlight a shipment or a delivery and choose Delivery Overview, Transportation

Planning displays an overview of the cumulative quantities for each ship-to party of the
shipment and additional information on the means of transport.
5. If you highlight a shipment or a delivery and choose Materials Overview, Transportation
Planning displays an overview of the materials in the deliveries. In this case,
Transportation Planning does not take returns into account.
6. Vehicle Space Optimization: If you use vehicle space optimization from the DSD
process the status of vehicle space optimization will be displayed on the Deadlines tab
page on the overview screen. From this tab page you can branch to vehicle space
optimization. For more information about vehicle space optimization, see the
documentation entitled Vehicle Space Optimization.
Change Shipment
...
...
1. Enter a shipment number.

2. In the following overview you can manually change the data for the selected shipment.
Display Shipment
...
...

2. In the following overview Transportation Planning shows the data for the selected
shipment.

Vehicle Space Optimization

Use
Vehicle Space Optimization (VSO) calculates the optimum arrangement of the delivery items
for one shipment which require packaging materials, such as pallets. Vehicle Space
Optimization also calculates the arrangement of packaging materials (PKM) for a particular
means of transport. The results of these calculations are the packing proposals from vehicle
space optimization (VSO packing proposals).
The system displays the VSO packing proposals graphically. You can change the height,
width and length of VSO packing proposals, as well as choose a different position for a
packing proposal. The system can also consider requirements such as overhang, preferred
loading positions, loading direction, and other factors in the calculations.
You can print out the loading chart and the VSO loading list as templates for loading.
In order to use the Vehicle Space Optimization component, you must first integrate an
optimization algorithm from a third-party vendor using an interface.
Integration
Vehicle Space Optimization is part of the Direct Store Delivery (DSD) component.
● Vehicle Space Optimization is integrated in the Create Shipment, Change Shipment

and Display Shipment applications.
○ To call the enhancements in Vehicle Space Optimization, choose the Vehicle

Space Optimization button on the Deadlines tab page in the overview screen of
the corresponding application.
○ The system displays the status of vehicle space optimization in the appropriate
overview screen.
● When you save a planned shipment, the system starts Vehicle Space Optimization
automatically.
● You can also start Vehicle Space Optimization when creating shipments by choosing
Dynamic Transportation Planning.
● The system also displays the status of vehicle space optimization in the DSD
Transport List application.
The Follow-On Processes of Vehicle Space Optimization enable you to use the results of
vehicle space optimization (VSO packing proposals) during picking. You can also use VSO
packing proposals to control warehouse functions.
The following prerequisites must be met for you to integrate an optimization algorithm from a
third-party vendor:
● You have to install and start an RFC server in order to integrate an external
optimization algorithm.
● You have to configure a TCP/IP connection for the RFC server.
● You have to install and register an appropriate third-party ActiveX control in the client
in which the SAP Frontend is running.

Features
Vehicle Space Optimization calculates the optimum arrangement of the delivery items within a
shipment (VSO packing proposals) and determines the arrangement of packing proposals for
a particular means of transport.
The arrangement of packing proposals that Vehicle Space Optimization generates is
dependent on parameters from the following areas:
● Optimization profile for plant and shipment type
● Customer master for the customers receiving the deliveries
● Material master for the materials to be delivered
● Material master for the packaging material used
● Vehicle master
● Stacking and packing instructions from vehicle space optimization

You can conduct vehicle space optimization for single shipments online or in the background
when saving a planned shipment or in collective shipment processing using dynamic
transportation planning. You can print out the results of vehicle space optimization as a
template for the loading. You can print out a loading list that contains the results of vehicle
space optimization, in addition to the standard information (VSO loading list).
Constraints
The system cannot use Vehicle Space Optimization for shipments that already contain VSO-
relevant delivery items for which picking has already begun or has finished.

Vehicle Space Optimization Online

Use
Use this function to determine the optimum use of the loading room available in the vehicle for
a shipment using Vehicle Space Optimization (VSO) online.
Prerequisites
For the system to be able to call an optimization algorithm from a third-party via an interface,
you have to flag the Vehicle Space Optimization Active checkbox.
To be able to use Vehicle Space Optimization, you must make the necessary settings in the
following areas:
3. Customizing for Vehicle Space Optimization:
For more information about Customizing, see the Implementation Guide (IMG) under
Vehicle Space Optimization.
4. Area menu for Vehicle Space Optimization:
○ Process overstackability
○ Assign a packaging material to a VSO vehicle type
○ Edit packaging material attributes for the packing group

5. Master data for Vehicle Space Optimization:
○ Materials (products and packaging)
○ Vehicles
○ Customers
To be able to carry out vehicle space optimization online, you need to have created a
shipment that is assigned to a vehicle and at least one delivery. The delivery must have
vehicle space optimization-relevant items.
Activities
When you have created a shipment, proceed as follows:
1. Select a shipment.
2. Choose Vehicle Space Optimization in the Shipment Overview on the Appointments tab
page.
3. Choose Start calculation.
4. The system starts vehicle space optimization. On the basis of the settings entered, the
optimization algorithm determines the:
○ Best way of arranging delivery item materials with the packaging materials
(VSO packing proposals)
○ Arrangement of these packing materials in the means of transport
The display appears in an ActiveX control.

You can change the displayed VSO packing proposals manually by repacking
the load or moving packaging materials.

5. Print the loading chart for the particular means of transport. In addition to the loading
chart, you can also print the VSO loading list. The VSO loading list contains the VSO
packing proposal data.
6. When saving the acquired vehicle space optimization data, the system saves the VSO
packing proposals along with shipment.

Follow-On Processes of Vehicle Space

Optimization
Use
Use the Follow-On Processes of Vehicle Space Optimization to control warehouse functions.
If you use the Warehouse Management (LE-WM) component, the system supports you in
grouping together packaging materials and products based on the VSO packing proposals
that are identical to the proposals generated in the upstream component Vehicle Space
Optimization.
To be able to use Follow-On Processes of Vehicle Space Optimization, you also have to
implement Vehicle Space Optimization.
To use VSO Packing Proposals in the Follow-On Processes of Vehicle Space Optimization,
you have to configure Warehouse Management (LE-WM) in such a way that the system can
pick deliveries. You need to allow partial picking in Customizing.
Integration
The Follow-On Processes of Vehicle Space Optimization component is part of the Direct
Store Delivery component, and is therefore integrated into the Logistics Execution
component. It uses the transfer orders (TO) of the SAP Warehouse Management (LE-WM)
component.
Within the Direct Store Delivery component, you can use the Follow-On Processes of Vehicle
Space Optimization in the Display Shipment transaction of the Logistics Execution
component.
Within Transportation Planning for the Direct Store Delivery process, you can also call the
Shipment List application in which you can execute the Generate Transfer Orders function of
the Follow-On Processes of Vehicle Space Optimization in the background.
Features
The system lists the VSO packing proposals from Vehicle Space Optimization in a separate
screen, grouped by process type.
The system groups the VSO packing proposals from the Vehicle Space Optimization
component by process types. The corresponding list appears in a separate screen.
You can start the following activities for transfer orders in this screen:
● Generate
● Display conversions
● Print
● Confirm
The system provides predefined forms in the Follow-On Processes of Vehicle Space
Optimization component. You can use these forms to print transfer orders on TO documents
and labels.
The system can generate a handling unit (HU) automatically for each VSO packing proposal
of a shipment. To create a handling unit, the system groups a packaging material together
with the products picked for that packaging material. You can also pack all the generated
handling units of a shipment into higher-level handling unit. This higher-level handling unit is
the means of transport.

For more information about handling units, see the Handling Unit Management (LO-HU)
component.
Constraints
You have to take the following constraints into account when using the Follow-On Processes
for Vehicle Space Optimization component:
● When the system creates a shipment from existing handling units (that is, the system
takes the material from a storage location in which handling units are managed), the
system cannot create any handling units using the Follow-On Processes of Vehicle
Space Optimization component.
● You cannot use vehicle space optimization or the follow-on processes for VSO for a
shipment if picking has already started, or has been completed for deliveries in this
shipment.

Picking Based on VSO Packing Proposals

Use
You use this procedure to perform picking using transport requests from the Warehouse
Management (LE-WM) component. The system carries out this picking on the basis of
packing proposals from vehicle space optimization.
The system creates at least one transport shipment for every delivery in a packing proposal.
For more information on Warehouse Management (LE-WM), see the documentation under
Warehouse Management (LE-WM).
Prerequisites
If you want to carry out picking on the basis of VSO packing proposals, the shipment must
have one of the following statuses after vehicle space optimization:
● VSO status: OK (display yellow or green).

The VSO status OK means that the system has successfully completed the vehicle
space optimization procedure for this shipment. The system has created VSO packing
proposals.
● Aggregated picking status: A (relevant for picking)
● Overall status: Planning, at least, completed.
Procedure
To perform picking based on VSO packing proposals, proceed as follows:
1. On the SAP Easy Access screen, choose:
Logistics → Logistics Execution → Direct Store Delivery → Transportation Planning →
Shipping → Display.
You reach the Display Shipment: Initial Screen.

3. Choose Enter.
The Display <Shipment type> <Shipment number>: Overview screen appears.

...
4. Choose VSO packing proposals from the appointments tab.

The Overview VSO packing proposals (Picking) Shipment <Shipment number> appears
5. Select the required VSO packing proposals.
If you want to select all the VSO packing proposals that are assigned to a
specific process type, select the respective process type.
6. Choose Goto → Create TOs.
Within Transportation Planning for the Direct Store Delivery process, you can
also create transport requests from the Shipment List.
To reach the shipment list application from the SAP Easy Access screen choose

Logistics → Logistics Execution → Direct Store Delivery → Transportation

Planning → Shipment List.
Result
Using the follow-on processes of Vehicle Space Optimization you have performed picking on
the basis of VSO packing proposals.
If the system has performed picking successfully, all the deliveries contained in the shipment
will have the following status:
● Overall status of picking/stock placement: fully picked
● Overall status of WM activities: WM TO confirmed

Output Control
Use
You implement Output Control for the Direct Store Delivery if the system is to automatically
group together all tour data for output control.
All tour-relevant information is saved in the system (for example, visit lists, deliveries, drivers,
and so on). Output Control separates the visit lists and shipments. The system displays the
related documents for each (shipments, visit lists and if necessary dependent documents
such as deliveries) in output control, from where the documents are printed either in paper
form or in IDoc format.
In this documentation we use the term download (data transfer). Download

refers both to data transfer to the printer and the provision of data in IDocs.
Output Control is intended for use by the following users:
● MRP controllers (logistics and sales and distribution) that check the messages.
● Drivers that take the printed out documents with them on their tours (for example,
delivery notes, visit lists, and so on).
Which information is relevant for the driver depends on the type of customer visit. There are
two different business processes in Output Control:
● In logistics-oriented business processes [Seite 63] the shipment is the control

document. This means that the shipment is flagged as a relevant document in the visit
plan type of the visit list that the shipment is based on. Once the shipment has a
certain status (for example, scheduled), the system carries out the download. The
system then transfers all shipment-dependent data (for example, deliveries for this
shipment or visit list in which the customer to be delivered to is found) to the spool
requestor IDoc (application V7).
● In the sales-oriented business process [Seite 64] the visit list is the control document.
The visit list defines the itinerary of the customers who are visited without having
goods delivered to them. Consequently, such visit lists are not linked to shipments.
The point at which the system executes the downloads is, as a rule, dependent on the
date on which the visit list is carried out. For the download, the visit list and if
applicable, the reference documents (for example, orders) are relevant. The download
takes place from application VL (Visit list).
To be able to use Output Control, Direct Store Delivery must be activated in Customizing.
Features
● The starting point for Output Control are existing shipments and visit lists.
You can group deliveries together to form shipments manually or by using Dynamic
Transportation Planning.
● When you implement Dynamic Transportation Planning, the system adjusts the
customer data from the deliveries so they are in concordance with the customer data
from the visit lists (depending on the visit plan type and the execution date). If they are
consistent, Dynamic Transportation Planning assigns the deliveries in the itinerary
sequence stated in the visit list.
● The system triggers output determination when saving visit lists or shipments.

● Output processing: If the shipment in visit list is flagged as a relevant document,

(according to visit plan type), the system carries out the download via output control for
application V7 (shipment).
For visit lists, where shipment documents are not flagged as relevant documents, the
system carries out the download via output control in application VL (visit list).
● Message processing: You can display processing logs for control purposes or
process already existing messages and process these again.
The following figure illustrates the Output Control process:
Process flow for output control in Direct Store Delivery
Logistics-oriented business process Sales-side business process
Deliveries
Visit list Dynamic transportation planning

Message Shipment
determination
Application VL Message
determination
Application V7
Message processing
Application VL Application V7
Print output spool request / Print output spool order /

IDocs IDocs
Processing log for downloading Processing log for downloading
the visit list the visit list
Message processing
In Customizing, you assign an appropriate message type to each sales

document object (for example, shipment, visit list). The sales document objects
are closely connected to the related application.
The system controls the output control in the Direct Store Delivery Process
through two applications:
■ Application V7 (shipment) for the logistics-oriented business process
■ Application VL (visit list) for the sales-oriented business process

The system carries out the download from application V7 (shipment) for visit lists
that Dynamic Transportation Planning is based on. In this case, the shipment
represents the relevant document.
For visit lists that do not have shipments, the system carries out the download
through application VL (visit list). In this case, it is the visit list exclusively that is
flagged as a relevant document in Customizing for the visit plan type.
In Customizing for the visit plan type, you set the indicator to show whether the
shipment document or the visit list is defined as relevant document. Using this
indicator, the system controls with which of the two applications the download is
to be carried out.

Visit Plan Type in Visit Control

We recommend you make the following settings for the visit plan type in Customizing
(depending on the type of business process and visit plan type) for the DSD process:
Business Visit plan type Relevant Documents indicator

process
Visit list Transportation Make delivery
Logistics- Delivery driver No Yes Yes

oriented
Logistics- Sales driver Yes Yes No
oriented
Logistics- Mixed case Yes Yes Yes
oriented
Sales-oriented Preseller Yes No No
For more information, see:
● Roles in Visit Lists [Seite 29]
● IMG documentation under Define Visit Plan Types

Logistics-Oriented Business Process

Use
You use the logistics-oriented business process to compile the documents that a van seller,
delivery driver, or mixed driver (combination of van seller and delivery driver) requires for a
tour.
Prerequisites
The following are the prerequisites for using output control for the logistics-oriented business
process:
● Message control is set up appropriately for the shipment
● Logistics-oriented processes are configured in Customizing for the visit plan type.
Process Flow
In the logistics-oriented business process, the shipment is the controlling document (relevant
document):
1. When the system saves a shipment, it generates a message for application V7
(shipment).
2. In Customizing, you can specify the minimum shipping status for the download. You
specify this for the message type that triggers the download.
3. When it performs a download, the system transfers all data that is dependent on the
shipment, according to the Customizing settings (deliveries for the shipment or the visit
list containing the customers to be visited) to the spool request or IDoc.

Sales-Oriented Business Process

Use
You use the sales-oriented business process to provide presellers with the collected
documents they require for their tour.
Presellers require only a visit list for their tours. The visit list specifies which customers are
assigned to the tour. The preseller visits the customers with the aim of generating new orders
or winning new customers. Since presellers by definition do not make deliveries, they do not
have shipments.
The system controls the download of the visit lists using the message control for the VL (visit
list) application.
Prerequisites
● The sales-oriented business process is set up in Customizing for the visit plan.
● Output control (message control) is set up appropriately for the visit lists.
Process Flow
In the sales-oriented business process, the visit list is the control document (relevant
document):
...
1. The time of the download depends on the date on which the visit list is carried out.
So that the driver always has access to current data, you should not perform the
download until just before the start of the tour.
2. The system only transfers (download) the visit list and any reference documents that
have already been assigned (orders, for example) to the IDoc or print output.

Message Control
Use
Message control is the central process for Output Control in DSD. Using message control, the
system automatically controls the output or subsequent processing of messages that are
linked to shipments and visit lists. In Customizing for Output Control you define the
processing routine with which the download is executed for each application and transmission
medium (IDoc or printout).
Output Control uses condition technique from the ERP system.
Process Flow
Message control can be divided into different sections:
...
1. Output Determination
Output determination is successful if the system finds the correct conditions defined in
Customizing when it saves the visit lists or shipments for a particular combination of
data. Output determination defines whether and when (shipping time) the system must
process a particular output type for a sales document object. There is an output
determination schema for each shipment type and visit plan type (1:1 ratio).
2. Output Processing
Output processing begins with the shipping time. The system creates a message
depending on the results of output determination and carries on processing this
message for a defined period of time. Output processing creates the printout or the
IDocs. Output processing runs differently for shipments and visit lists depending on the
type of download (printout or IDoc). After the download, the system creates a
processing log.
3. Message Processing
In the maintenance transaction for visit lists, you can process, with the correct
authorization, all related messages for a visit list:
○ Messages for visit list

The system displays all messages for the selected visit list.
○ Messages for the shipment

If the system has assigned a shipment to a selected visit list via the header-
reference documents, it displays all messages for this shipment document.
For each message you can display the processing parameters and the processing log.
You must have the correct authorization to be able to process messages (for example,
repeat, delete, change).
For more information about output control, see the standard system.

Output Processing
Use
The system processes the messages created from output determination by formatting the
messages in a particular format for printing or creating IDocs. The system then displays the
progress of output processing in the message status. You can set when the system is to
begin with output processing by the processing time.
The processing time for Output Control output processing is:
● For the shipment, dependent on the shipment status
● For the visit list, dependent on the execution date
Features
In Customizing, you define the processing routines that the system is to carry out during
output processing for each output type, application and transmission medium.
You enter all output types that trigger the DSD download in the DSD Output types
Customizing table.

Output Processing for Shipments

Use
The system uses this process to control the output (printout and IDocs) of the data collated
during output determination.
During message processing of the shipment, the creation of spool requests or IDocs is
dependent on the shipment status. In the Customizing table for the DSD output types, you
enter the minimum shipment status required for the system to be able to process the
message successfully. If the shipping status differs from the value defined in Customizing,
output processing is aborted with a corresponding note in the processing log with status
Incorrect Processing.
For each sales document object there is a fixed assignment to an application in the system. In
Output Control, message control for the shipment is based on application V7 (shipment).
Prerequisites
If the system is to use output processing for the download (printout and IDoc) during
shipment, the following conditions must be satisfied:
...
1. Printout and IDoc: The output types must be defined.
When creating output types for the download you must make the following
settings:
■ The Condition Access indicator must be set.
■ If the system is to create a change message after a download has been

completed for a change in the shipment, the Multiple Transmission
indicator must be set.
2. Printout and IDoc: The minimum shipment status that the system requires for the
download must be defined.
You define the shipment status in the Customizing table of the download output
types.
3. Printout: For each shipment type and per transportation planning point, it must be
defined which individual messages the system should print and in which order.
By default, the system groups all documents together in a spool request. If the
system is not to transfer the print output of a message to the printer for the
triggering DSD message, set the Different Printer indicator in Customizing. The
print output then continues, based on the printing settings of the individual
messages to be printed. This is necessary if, for example, one of the documents
(for example, delivery note) must be printed on a separate printer because of
the different paper format.
The system creates a processing log for each shipment in which the processed
messages for each document, and any errors that have arisen are logged. If
errors occur during processing of an individual message, the system logs the
error in the processing log for the individual message.

4. IDoc: For each shipment type and transportation planning point, it must be defined
which IDocs the system should create and with which function modules.
Features
Print Output
● In Customizing, for each shipment type and transportation planning point, you can
define which individual messages the system should process sequentially for the
relevant application. The system begins by processing the individual message as soon
as it processes the output type relevant for the download.
● Documents for which the system should create a printout are determined by the
system from the shipment document flow.
The system determines which visit list is assigned to a shipment using the header
reference documents for the visit list, because visit lists are not saved in the document
flow.
IDoc Creation
● In Customizing, you can define for each shipment type and transportation planning
point which IDocs the system should create and with which function modules.
● Documents for which the system should create an IDoc according to output type are
determined by the system from the shipment document flow.
The system determines which visit list is assigned to a shipment, using the header
reference documents for the visit list, as visit lists are not saved in the document flow.

Valuated Delivery Note

Use
You use the Valuated Delivery Note function to inform the driver of the amount they are to
collect from a customer when they make a delivery, based on the current conditions. A
valuated delivery note is a standard delivery note that is enhanced with price data.
In practice there may be a time delay between the creation of an order and a delivery note.
During this time the customer might have made changes to the order (type and quantity), or
prices or conditions might have changed. So that the driver can deliver the order while the
current prices apply and, if applicable, can perform settlement immediately (for example,
when being paid in cash), it is important that the price information can be taken straight from
the delivery note. A valuated delivery note provides this information.
Prerequisites
The following Customizing settings must be made to allow you to use the Valuated Delivery
Note function:
● The message type must be defined for the a valuated delivery note.
● The message type must be assigned to a pro forma billing document.
● Message determination must be customized.
● Print program /BEV1/VD_BEW_LIEF_BACKGROUND must be assigned to the form

/BEV1/VDINVOICE1.
● Copy control must be set up from the delivery to the billing document.
Features
To ensure that the price data is up-to-date when a valuated delivery note is printed, the
system creates a pro forma billing document in the background. The system uses the pro
forma billing document to determine the current price data.
The Valuated Delivery Note function is shipped as follows:
● Print program /BEV1/VD_BEW_LIEF_BACKGROUND
● Form /BEV1/VDINVOICE
This form is a template that can be changed to suit individual customer

requirements.
For each message type assigned to a valuated delivery note, the system also creates a pro
forma invoice when it saves the delivery.
In the print program /BEV1/VD_BEW_LIEF_BACKGROUND, the system checks

whether this is the first time the delivery and billing document data is being
printed or whether it is a repeat print. If it is the first time it has been printed, the
system prints a pro forma billing document, if it is a repeat print the system does
not print a pro forma billing document.
The system issues the pro forma billing document in the document flow.

Output Processing for Visit Lists

Use
The system uses this process to control the output (printout and IDocs) of the data collated
during output determination for visit lists (without shipment).
During output processing of the visit list, the creation of spool requests or IDocs is dependent
on the execution date.
For each sales document object there is a fixed assignment to an application in the system. In
Output Control message control for the visit list is based on application VL (visit list).
Visit lists must be active (Inactive indicator not set), so that output processing
creates spool requests or IDocs for the visit list.
Prerequisites
The following settings must be entered for output processing of visit lists:
...
1. Printout/IDoc: Define output types
○ The Condition Access indicator must be set.
○ The Multiple Transmission indicator cannot be set. Only one download takes
place for each visit list. Each further download can be requested separately.
○ By default, the value of the shipping time must be 2 (=job and time information),
and a processing routine must be entered in which the shipping time is defined
(as a rule the execution date of the visit list).
The download of a visit list (sales-oriented business process) is, as a rule,

dependent on the execution date of the visit list. Output processing takes place
by means of a periodically scheduled job that processes the due messages and
consequently triggers the download.
2. Printout/IDoc: Output processing only takes place if the visit list to be printed is active.
If this prerequisite is not satisfied, output processing is cancelled. The system

displays an appropriate note in the processing log with the status Incorrect
Processing.
3. Printout: For each visit plan type it must be defined which individual messages the
system should print in which order.
By default, the system groups all documents together in a spool request. If the
system is not to transfer the printout of a message to the printer of the triggering
DSD message, set the Different Printer indicator in Customizing. The print
output then continues based on the printing settings of the individual messages
to be printed.
The system creates a processing log for each visit list in which the processed
messages for each document, and any arising errors are logged. If errors occur

during processing of an individual message, the system logs the error in the
processing log for the individual message.
4. IDoc: For each visit plan type it must be defined which IDocs the system should create
and with which function modules.
Features
Print Output
● In Customizing, you can define for each visit plan type which individual messages the
system should process sequentially for a particular application. The system begins by
processing the individual message as soon as it processes the output type relevant for
the download.
● Documents for which the system should create a printout are determined from the
reference documents in the visit list.
IDoc Creation
● In Customizing, you can define which IDocs the system should create and with which
function modules.
● The system does not save the visit list in the sales document flow. During output
processing from visit list reference documents, the system determines those
documents for which an IDoc ist to be created.

Route Accounting
Use
You implement Route Accounting so that after a tour you can carry out the following for tour
activities documented during a tour:
● Enter
● Check
● Maintain
● Release to settlement
● Post
Entering outgoing and incoming control data is optional. Route Accounting begins after
Output Control [Seite 59] and ends once all the tour transactions have been posted.
Depending on their roles (for example, preseller, sales driver), drivers need information on
how to carry out their tours. The system can provide the driver with this information in two
variants:
● Variant 1: Printout of the documents relevant to the tour

During the tour the driver enters the various tour activities non-electronically on
documents (for example, delivery notes, .shipping papers).
● Variant 2: Use of mobile devices

During the tour the driver enters the various tour activities electronically on a mobile
device.
Once the tour is finished, you have to transfer the data to the system so that it can then be
processed in the Settlement Cockpit:
● If you have used the non-electronic variant (printout), transfer the data that was
entered on the documents to the system using the Tour Data Entry function. Using tour
data entry, you can manually enter a lot of data quickly and in a structured way.
● If you have used the electronic variant (mobile device), the system transfers the data
(upload) as soon as the mobile device is connected to the system (for example, when
the mobile device is placed in the base station).
You can switch between electronic and non-electronic entry of tour activities.
If, for example, a mobile device was temporarily out of order, you could give the
driver the necessary information in paper form. Once the tour is completed, you
can transfer the data collected during the tour back into the system manually
using Tour Data Entry. The system supports you for the tour and the
subsequent processes. When the mobile device is available again, use it for the
next shipment as usual.
You can use the subsequent processes in Route Accounting (for example, check the data in
the Settlement Cockpit, trigger the final settlement run) irrespective of how you transferred to
tour data to the system.
Route Accounting was developed for the final processing of documented tour
activities based on the use of mobile devices or documents. We recommend

you use mobile devices. Using Route Accounting with mobile devices has the
following advantages:
● Reduced processing time for each business transaction
● Low risk of input errors and redundancies
● Reduced internal costs
Integration
Route Accounting is part of the Direct Store Delivery component.
You create shipments using the single document or collective processing transaction. The
system employs SAP standard message processing to transfer the movement data using the
EDI standard or ALE control. The system transfers master data using the SAP integration tool
Application Link Enabling (ALE).
To transfer the master data for the Route Accounting component to mobile devices, the
system uses special transactions contained in a separate area menu.
After completion of the tour, the data is transferred from the mobile devices to the ERP
system by means of upload procedures. The relevant documents (sales orders, deliveries,
billing documents, FI documents) are created or updated in the final settlement run.
Constraints
The Route Accounting component is an offline solution. This means that data is exchanged
between a handheld and the system at the start and end of a tour. It is not possible to transfer
data during a tour.

Final Maintenance for Completing Tours

Use
You implement this process to:
● Document specific transactions for different tours
● Enter all relevant data for a tour (Tour Data Entry [Seite 79])
● Finish off tour maintenance (Settlement Cockpit [Seite 82])

In the final settlement run (Settlement Cockpit), the system creates documents and billing
documents and makes postings in SAP FI. After the final settlement you can display the
settlement document, the application log and the document flow. The system displays the
processing status of the tour in the settlement document. The system displays error
messages and their causes, as well as success messages in the application log.
Prerequisites
● Deliveries and shipments exist in and are planned in the system.
● To be able to use Route Accounting, the EA-SCM enhancement must be switched on

and the Direct Store Delivery component must be activated in Customizing.
Process Flow
The Route Accounting process begins after output control [Seite 59] and ends once all the
tour transactions have been posted.
...
...
1. The system displays the master data and transaction data necessary for a tour in lists,
documents or in IDocs. Drivers receive their documents and begin their tours.
2. When you perform a check-out, the controller confirms the results of the check-out
(material stock and cash amounts) when the tour begins from the distribution center or
plant.
3. During the tour the driver enters all relevant data:
○ Specific tour data: For example, expenses resulting from refueling the vehicle,
time spent in traffic jams, breaks and kilometers driven.
○ Specific customer visit data: For example, delivery completed, orders, returns,
empties, invoices, waiting times, time to unload and receipts.
4. At the end of the tour, the driver goes back to the distribution center or plant.
5. When you carry out a check-in, the controller confirms the results of the check-in
(material stock and cash amounts) when the driver arrives at the plant site.
6. The driver hands the documents into the settlement office:
○ Papers issued before the start of the tour, which the driver may have made
manual changes or additions to
○ New documents (for example, new orders)
○ Check-in /check-out papers

7. In Tour Data Entry, you select the visit lists or shipments to be processed and enter the
tour data added by the driver in the system.
8. In the Settlement Cockpit you check and maintain the data.

9. The system determines material differences and differences in means of payment,

based on the results from check-outs and check-ins.
10. You save the settlement document. After this, data can no longer be changed
(exception is collection assignment).
11. You perform a final settlement run. The system creates documents and billing
documents and makes postings in SAP FI.
12. You can call the documents in the document flow. The system displays error messages
and their causes, as well as success messages in the application log. In the settlement
document you can display different statuses and differences for materials and means of
payment.
Result
The tour is completed in the system.

Entering Tour Data on Mobile Devices

When you use the Route Accounting component in combination with handhelds, the system
processes the data in the following single steps:
1. Data download
The system loads the master and movement data required to execute a tour, on an
intermediate server (middleware server) using an interface (IDocs = intermediate documents).
The intermediate server then transfers the data to the handhelds. The transferred data is
available to drivers when they are on their routes.
2. Check-out
At the start of the tour a check-out can be performed for the goods loaded on the vehicle, and
the amount of cash available. This is normally performed by a second person (the checker).
The data is entered on the handheld device. If any differences are found, they have to be
checked and recorded. This is important because the driver is responsible for the goods on
the vehicle.
3. The actual route – delivering the goods

The driver enters all transactions related to the delivery of goods to customers that occur
during the route, directly in the handheld device. Some of the most important transactions are:
● Changing delivery items in an existing delivery
● Creating new orders and/or delivery documents
● Writing invoices
● Receiving payment to settle invoices
● Writing confirmations of receipt
4. Check-in
After finishing the route, the driver returns to the depot. The goods (full products and empties)
that the driver brings back (unsold merchandise or returns) are counted, entered in the
handheld device, and confirmed. Both cash and checks received as payment are dealt in the
same way.

Download
Use
You only employ the functions in the SAP Easy Access folder Download when using mobile
devices (handhelds).
If you use the functions in the SAP Easy Access folder Download, you can transfer the
following data to handhelds.
● Specific material data
● Specific customer data
● Driver data
● Driver text settings
● Vehicle data
● Credit data (credit limit and master data)
● Credit data (open items)
Note the following differences in the data transfer (download) of master and movement data:
● Master Data
○ SAP Standard Master Data

The system activates the required SAP standard master data during the data
transfer (download) using the SAP ALE distribution model.
○ DSD-specific master data

The system loads the DSD-specific master data required to execute a tour, on
an intermediate server (middleware server) using an interface (IDocs =
intermediate documents). The intermediate server then transfers the data to the
handhelds. The transferred data is available to drivers when they are on their
routes.
● Movement data
The system activates the movement data during the data transfer (download) using the
message determination in the shipment list/visit list. You can define the scope of the
movement data to be transferred in Customizing.

Upload
Use
The system has a separate database for Route Accounting (Route Accounting Database).
When data is uploaded from a mobile device to an SAP system, the system first loads the
current, modified data for each tour from the driver’s handheld to an intermediate server.
Communication between the intermediate server and the Route Accounting Database in the
SAP System is based on creating and processing IDocs or direct processing using BAPIs. In
the settlement cockpit you can call tour data from the SAP Route Accounting Database and
prepare the tour data for the subsequent route settlement process.

Tour Data Entry

Use
You use the Tour Data Entry function to enter the following data in the system:
● Tour data and documents that the driver hands into the settlement office after a tour
● Check-out and check-in results
Integration
Tour Data Entry is a part of Route Accounting and belongs to the Direct Store Delivery
process.
Tour data entry uses the SAP authorization concept.
Prerequisites
To be able to use Tour Data Entry, the EA-SCM enhancement must be switched on and the
Direct Store Delivery component must be activated in Customizing.
Features
Data Selection (Including Selection Results)
After a tour is over, you can quickly update documents that have had changes made to them
during a tour and enter the additional information in the settlement office. The system later
adjusts the route settlement processes in the Settlement Cockpit so it agrees with the data in
the system.
You assign the appropriate system data by selecting the corresponding visit list or shipment
according to different criteria before entering tour data in a selection screen. Only then does
the screen for entering tour data appear.
The system displays documents and fills the fields with the planned data which was already
available in the system before the tour. This entry help means that you only have to edit the
changed data at header and item level (actual data).
You can take back the tour status Released for a settlement as long as the settlement has not
yet begun (no settlement document available). The system displays a dialog box in which you
can decide between display mode and resetting the release. You cannot release any tours in
Tour Data Entry. To release a tour to settlement, you must set an indicator within the
settlement process in the Settlement Cockpit.
The system displays settled tours in the selection result in display mode.
Entry and Administration of Tour Data on Tab Pages

On the Tour Entry screen you can edit selected visit lists or shipments. The screen is
separated into two screen areas: In the upper screen area you can see a list of the visits to be
made and can additionally enter visits already made. In the lower screen area you edit the
related tour data on the following tab pages:
● General header data

On the General Header Data tab page you edit, for example, information about
swapping a particular means of transport with another driver or the assignment of a
means of shipment for the tour.
● Check-in/check-out
On the check-out/check-in tab page, you process the

○ Itemization of an executed check-out.

Here you find a list of all materials, their quantities and payment methods dealt
with by the driver that the controller determined for the vehicle at the beginning
of the tour.
○ Itemization of an executed check-out.

Here you will find a list of all materials, their quantities and payment methods
dealt with by the driver that the controller determined for the vehicle at the end
of the tour.
● Tour distances and times

On the Tour Distances and Times tab page, you process the information the driver has
added regarding distances (mileage) of individual visits or the whole tour.
● Customer visit
On the Customer Visit tab page you process detail information about:
○ Additional customer visits that are not on the visit list
○ Customers from the visit list that the driver did not visit
● Delivery execution
On the Delivery Execution tab page you process the driver’s notes on the printed
delivery notes about the material and quantities actually delivered (and taken back).
For example:
○ Changes to quantities of individual material items
○ Cancellation of whole delivery items (for example, wrong order)
○ Sales or additional materials that were freely available in the vehicle

(speculative load)
○ Empties returned by the customer
● External billing document

On the External Billing Document tab page, you process invoices that a driver has
given out during a tour to a customer.
● Payment processing
On the Payment Processing tab page, you process the payment transactions with and
without customer assignment, for example:
○ Collection from customer (pay in cash)
○ Receipts from customer from open items
○ Records from the driver about receipts, expenses that arose in connection with
the tour but had nothing to do with the customer visit itself, such as parking
fees, petrol, tolls, and so on.
● Sales order
On the Order tab page you create new orders that are only delivered with one of the
nearest tours.
Activities
The system separates the tour data entry into visit lists and shipments:
...
1. You select the shipments or customers to be processed in a selection screen.

2. The system displays the selection results in a list.

3. The system carries out an authorization check.
4. The system displays the related customer or visit data.
5. You make changes or additions to the customer or visit data on the tab page.
6. Once you have saved your data, tour data entry is complete and the data is available to
the Settlement Cockpit for final settlement.
Example
Examples of tour documents:
● Delivery notes with notes about additional materials which differ from delivered
quantities and returned materials (empties and so on)
● Delivery notes for extra customers visited
● Receipts and expenses records
● Distance and time records
● Check-in/check-out records
● Invoices that were issued to the customer when delivery was made
● Orders for future deliveries

Settlement Cockpit
Definition
Tool used to prepare the transferred data or subsequently entered data from tours and
customer visits for route settlement.
Use
Drivers returning from a tour, deliver the documents belonging to their tour to the settlement
office. These include, for example:
● Documents
● Cash
● Credit cards
● New orders
● Miscellaneous tour data

You carry out the administrative part of a tour in the settlement office. You use the Settlement
Cockpit to:
● Display tour data
● Make corrections to the entered tour data
● If necessary, enter additional data manually.

Once the tour data has been processed in the Settlement Cockpit, the system issues a status
for each tour. This status indicates if there were any errors or releases the tour data for further
processing (final settlement run). In the final settlement run the system creates documents
based on the tour data in the ERP system.

Processing of Tour Data in the Settlement Cockpit

Use
You use the Settlement Cockpit to check and if necessary edit selected tour data that was
entered in large quantities in tour data entry or was imported by data transfer (upload).
There are different types of tour data:
● General tour data

General tour data is basic data that you created before a tour was executed and that
does not document any specific processes of the execution of the tour.
● Check-out/check-in data
Check-out/check-in data is data on material or cash stocks present in the vehicle when
it leaves the plant or returns from a tour. A checker gives the driver confirmation of the
check results in document form.
● Differences in quantities and payment methods

Differences are deviations in quantities and payment methods that the system detects
from the check-in/check-out data. These are differences that arose whilst loading or
during a tour.
The calculated differences are subtracted or added to a driver’s account.
● Time data for a tour

You can enter time data with reference to:
○ A tour
○ A customer visit.
Time types with reference to a tour can be:
■ Breaks
■ Traffic jams
■ Repair time during a tour

Time types with reference to a customer visit could be:
■ Waiting times
■ Unloading times
● Distance information for a tour

Distance information for a tour (without reference to a customer visit) is data that a
driver documents during a tour for different distance types. The driver chooses
between:
○ Distance information for the whole tour
○ Distance information for customer visits
● Collection data for a tour

Collection data for driver’s receipts and expenses is data with reference to a tour
(without reference to a customer visit).

You cannot assign expenses to a customer visit that arose due to fuelling the
vehicle. Expenses for fuel have a reference to the tour.
Prerequisites
● The tour whose data you want to edit must be listed in the Settlement Cockpit worklist.
● To be able to edit tour data, the data pending editing must be released (status 2 =
released). Only when the tour data is released can you:
○ Process tour data
○ Execute difference determination
○ Carry out a final settlement

You can reverse a release by choosing Cancel Manual Release.
Features
The following functions are available for editing tour data in the Settlement Cockpit:
...
● Editing General Tour Data

You can make changes to the general tour data.
● Edit check-out/check-in data

In the Settlement Cockpit in Route Accounting you can check and edit results from
check-ins and check-outs.
● Determining differences in quantities and payment methods

The system determines the differences on the basis of the opening balances as
follows:
Quantity differences for each material = Check-out quantity
minus the delivered quantity
plus the returned quantity
minus the check-in quantity
Difference in means of payment = Check-out amount

minus expenditure
plus receipts
minus the check-in amount
You can check the determined differences and carry out any required adjustments in
the Settlement Cockpit. If you have made any adjustments, you must run difference
determination again.
If you have saved the settlement document, you cannot make any further
changes to the tour data.
● Editing time data for a tour

You can enter different and the same time types several times. You can create
customer-specific time types in Customizing.
● Processing distance information for a tour

In the Settlement Cockpit in Route Accounting you can process distance information for
different distance types. You can create customer-specific distance types in
Customizing.
● Processing collection data for a tour

You can edit collection data for the driver’s receipts and expenses in the Settlement
Cockpit in Route Accounting, that has a reference to a tour. You can separately
process collection data that is assigned directly to a customer visit under Visit Data.

Processing of Visit Data in the Settlement Cockpit

Use
You use these functions to edit customer data or selected customer visit data in the
Settlement Cockpit.
Customer visit data is data that refers to customer visits and which you issue before a tour
begins in the ERP system and complete after a tour. This ensures the driver has all the
information he requires during the tour (for example, shipment data, data on deliveries,
customers, materials). During the tour, the driver adds any processes that occur during the
tour to the customer visit data. When the driver returns from the tour, you enter the added
customer visit data to the system and check and edit the customer visit data in the Settlement
Cockpit.
You can edit the following data for a customer visit:
● General data about the customer visit

General data about a customer visit is basic data that you created before carrying out a
customer visit and that does not document any specific processes carried out during
the customer visit (for example, customer, address, contacts).
● Data regarding executing deliveries to customers

Delivery execution data is, for example, data regarding quantities that differ from the
plan, that the driver has delivered, collected empties, or returns.
● Data regarding unplanned orders placed by customers during the visit

During a customer visit, the driver received an additional order from the customer or
has to change and existing order.
● Data regarding unplanned invoices created by the driver during the tour
If a driver creates an invoice during a customer visit, he has to document this
transaction.
● Different time data related to the customer visit

You can enter time data with reference to:
○ A tour
○ A customer visit.
Time types related to a customer visit could be, for example:
○ Waiting times
○ Unloading times
● Different distance data related to the customer visit

Distance data related to a customer visit is data that drivers have documented during
their tour and which has to be assigned to a particular customer visit. The distance type
defines the type of distance information. (For example, extra journeys made).
● Collection data related to the customer visit

Collection data is data concerning receipts and expenses of the driver related to a
customer visit (for example, receipts issued when the customer pays the for a delivery;
payments, if the driver pays out an amount for received empties).

Prerequisites
The customer visit data that you want to edit must be listed in the Settlement Cockpit worklist.
Features
The following functions are available for editing customer visit data in the Settlement Cockpit:
● Editing delivery execution data

You can make changes to the general customer visit data.
● Executing the order entry

You can edit delivery execution data for a customer visit, for example, change
quantities if a driver has made a delivery of an unplanned amount or if the driver takes
back empties or returns.
● Displaying invoices
You can display invoices that a driver has created during a customer visit. The
Settlement Cockpit only displays invoices that were created using Route Accounting.
The system does not display invoices created using the Billing (SD-BIL) component in
the Settlement Cockpit.
If the driver has made handwritten changes to invoice documents, you can
subsequently edit the invoice documents in the Settlement Cockpit. If you perform the
final settlement run, the system generates the relevant documents in SAP SD.
● Recording time data for a customer visit

You can enter different and the same time types several times. You can create
customer-specific time types in Customizing.
● Recording distance information for a customer visit

In the Settlement Cockpit in Route Accounting you can process distance information for
different distance types. You can create customer-specific distance types in
Customizing.
● Enter and assign collection data for a customer visit

You can edit collection data for the driver’s receipts and expenses in the Settlement
Cockpit in Route Accounting, that has a reference to a customer visit.

Application Log
Use
You use this function to display an application log. The application log contains the results of
settlement processes. You can determine whether the system has performed an error-free
settlement run. The application log contains the following areas:
● Delivery
● Driver document
● Payment posting
● Delivery posting GI (material outgoing posting)
● Invoices
● Clearing
For each settlement run performed, the system displays a different application log.
Prerequisites
The system must have performed a settlement run.
Activities
1. In the Settlement Cockpit select the settlement document required or a tour contained
there and choose Display Application Log.
2. The system displays application logs to the right of the screen page.
3. If you expand the application logs and select an entry, the system displays the
corresponding message text.

Settlement Document
Use
You use this function to display a document with which the system informs you about
executed settlement runs. A settlement document provides you with an overview of the
processing status of the process steps that you performed in the settlement cockpit. The
system also displays the cash and quantity differences for the tour.
The settlement document is divided into three areas:
● Header
● Cash differences
● Quantity differences
In the header the system displays the general route data and the processing status of the
individual settlement-relevant process steps. The system displays one of the following
statuses in the settlement document header:
● Not relevant (0)
● Relevant, not started (1)
● Relevant, in process (2)
● Completed (3)
For each processing step, the processing status specifies whether the process step is
relevant for the settlement run and if it has been processed. Only once all process steps that
are relevant for the settlement run have the processing status 3 (completed) does the system
set the settlement status to status 2 (relevant, in process).
In the area Cash differences, the system displays the results of difference determination for
the cash amounts.
In the area Quantity differences, the system displays the results of difference determination
for the material quantities.
Prerequisites
Activities
4. Select the required tour in your worklist and choose Display Settlement Document.
5. The system displays the settlement document to the right of the screen page. Under the
settlement document header, the system displays the areas for cash differences and
quantity differences.

Document Flow
Use
You use this function to display the documents created by the system for a settlement
document or a tour. In the document flow display you can determine whether the system has
created a document for every relevant tour transaction. In the document flow display you can
view the numerical keys for the different documents.
Prerequisites
Activities
6. In the Settlement Cockpit, select the settlement document required or the tour
contained there and choose Document Flow.
7. The system displays the document flow and corresponding documents to the right of
the screen page.
Example
The document flow can contain the following document types:
● 001 SD shipment
● 002 Load delivery
● 003 Return load delivery
● 004 VC visit list
● 010 Delivery (backend)
● 012 Sales order (backend)
● 014 Invoice (backend)
● 015 Accounting document (backend)
● 016 Sales activity (backend)
● 998 Settlement document

DSD Final Settlement Run

Use
You use this function to make all the required postings at the end of Route Accounting.
The system processes all tour transactions during the final settlement run. The system
updates existing documents and creates new documents if required. The system also posts
the incoming and outgoing payments for customers in Financial Accounting.
Prerequisites
You must have released the tours for processing.
The system must have determined the differences for all tours that are released for
settlement.
Features
The system carries out the following processing steps during the final settlement:
...
1. Creation/processing of customer documents

2. Creation of driver’s documents
3. Posting of payments for balanced items in SAP FI
4. Posting of goods movements
5. Collection clearing of the items assigned in the Settlement Cockpit/Tour Data Entry
Activities
...
1. The system executes a final settlement run in accordance with the Customizing
settings.
2. When the system has completed the final settlement run, it issues a message.
3. You can display the log for the final settlement run.
In Customizing, you can define when and how the system carries out the final
settlement. The system can carry out the final settlement as follows:
● Automatically after difference determination
● Automatically after difference determination, when no differences

have occurred
● Manually in the settlement cockpit
● Automatically in the background
Result
The system has processed the tours and posted the relevant documents. The final settlement
is complete.

Inkasso-Auszifferung
Use
After the system has posted the business transactions for a tour as documents, the system
posts the receipts entered that the driver has collected from the customers during the tour.
When the receipts from the driver are posted, the system clears the payables from the
customers in question in financial accounting.
Features
● When you have made the appropriate settings in Customizing, the system can
automatically clear the open items after the settlement run (Executing DSD Clearing in
the Background [Seite 93]).
● You can also clear the open items manually (Executing DSD Clearing Online [Seite
94]).
● You can display a log after the clearing.

DSD Clearing in the Background

Use
Use this function to clear open items for a customer (credit entry resulting from a payment,
and debit entry resulting from an invoice) in background processing.
The system performs the automatic clearing of open items in a single step.
Prerequisites
The following requirements have to be met before you can perform DSD clearing in the
background:
● The tour must have been coordinated so that Route Accounting can determine
whether (and which) open items exist for a payment.
● The driver’s receipts from the customer visits must be assigned to the appropriate
deliveries or billing documents.
● The deliveries contained in the tour must be billed.
● The billing documents must be released for Financial Accounting.
● Automatic clearing must be allowed for the company code used.
● The customer visit must have clearing status CP (clearing possible).
The clearing status in the Route Accounting component does not influence
clearing in Financial Accounting.
Features
The system executes automatic clearing of the open items for the selected documents in the
background. The system displays a log stating the cleared items.

DSD Clearing Online

Use
You use this function to perform DSD clearing online.
Prerequisites
The following requirements have to be met before you can perform DSD clearing online:
● The tour must be settled.
● The driver’s receipts from the customer visits must be assigned to the appropriate
deliveries or billing documents.
● The deliveries contained in the tour must be billed.
● The billing documents must be released for Financial Accounting.
● Automatic clearing must be allowed for the company code used.
● The customer visit must have clearing status CP (clearing possible).
The clearing status in the DSD Route Accounting component does not influence
clearing in Financial Accounting.
Activities
1. You make a selection and enter a status for each document in the field Man.Coll.Stat.
(Collection assignment: Manually issued status).
2. The system clears those objects whose status permits clearing.
3. The system displays a log stating the cleared items.

Direct Store Delivery Connector

Purpose
You can employ the DSD Connector when drivers and presellers use mobile devices on their
tours, which need to be equipped with the data and functions the employees require to
perform their activities.
The DSD Connector component converts and saves tour-related data received from the
backend of the DSD system. The saved data can be received by the mobile device,
processed on the mobile device and then sent back to the backend of the DSD system.
Use of the DSD Connector is a technical prerequisite for supplying the mobile devices with
the required data.
Integration
The DSD Connector is part of a system landscape that consists of the following components:
• DSD Backend
• DSD Connector
• SAP Mobile Engine
• Mobile DSD
DSD Connector in the DSD system landscape
IDocs RFC HTTP
SAP Mobile
DSD DSD Mobile DSD
Back End Connector Engine (MDSD)
RFC RFC HTTP
DSD
Connector
Cockpit Separator Mobile Device
Server (Front End)
SAP System
Features
The DSD system generates IDocs when it saves shipments or DSD visit lists. These IDocs
are used as an interface for connecting mobile devices to the backend of DSD and are sent
using the ALE layer.

SAP Mobile Engine does not have the SAP_APPL layer and is therefore unable to process
IDocs. The DSD Connector Input Interface receives IDocs sent from the DSD system and
converts them. The DSD Connector Input Interface is called by the ALE layer. It converts the
IDocs using assignment rules.
Using these assignment rules, you define in Customizing which fields from the IDocs the
system maps to which fields in the DSD Connector tables. There are much fewer fields in the
DSD Connector tables than in the IDocs. When you have assigned the data from the IDocs to
the target structures in the DSD Connector, the system saves this data in the DSD Connector
tables.
Once the master data has been saved, the DSD Connector Input Interface launches the
determination of the condition records in the DSD system for the materials and customers
listed in the tour-related data.
The DSD Connector Cockpit is an application interface that is connected to the DSD
Connector.
In the DSD Connector Cockpit, you assign a driver and a vehicle to a mobile device. Using
this assignment and the driver and vehicle data from the IDocs (that the DSD system has
transferred), the DSD Connector Input Interface assigns the tour-related data to a mobile
device. This means that the tour-related data can later be sent to the correct mobile device.
You call the DSD Connector Cockpit using transaction /DSD/ME_CPT.
A mobile device sends a synchronization request via the SAP Mobile Engine to the DSD
Connector. On the basis of this synchronization request, the SAP Mobile Engine calls a range
of functions in the DSD Connector using Remote Function Call (RFC). These functions read
the tour-related data for the calling mobile device from the DSD Connector tables and send it
via the SAP Mobile Engine to the mobile device.
With the next synchronization request, the mobile device transfers all the data that was
created or modified during a tour via the SAP Mobile Engine to the DSD Connector. When
doing this the SAP Mobile Engine also calls a range of functions in the DSD Connector using
RFC. The SAP Mobile Engine passes the data from the DSD Mobile Device on to these
functions, which then save the transferred data in the tables in the DSD Connector.
When all data has been successfully uploaded from the DSD Mobile Device to the DSD
Connector, the upload from the DSD Connector to the DSD system is started. To do this, the
transfer function (upload) in the DSD Connector is called. The upload function reads all data
that belongs to a tour from the DSD Connector and converts it into the structures of the DSD
system. With this converted data, the transfer BAPIs in the DSD system are then called by
RFC. After numerous checks, these BAPIs save the data in the Route Accounting database.
The data is then ready to be settled in the DSD Settlement Cockpit.

DSD Backend ERP2005 EN 6761 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DSD Backend ERP2005 EN 6761 PDF

Uploaded by

Copyright:

Available Formats

Direct Store Delivery

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft

Java is a registered trademark of Sun Microsystems, Inc.

MaxDB is a trademark of MySQL AB, Sweden.

Direct Store Delivery (Backend) 6761 2

Icons in Body Text

Type Style Description

Direct Store Delivery (Backend) 6761 3

Direct Store Delivery (Backend) ................................................................................................ 6

Direct Store Delivery (Backend) 6761 4

Valuated Delivery Note.......................................................................................... 69

Direct Store Delivery (Backend) 6761 5

Direct Store Delivery (Backend)

● Directly influence end customers, as the consumer products manufacturer

● Optimize process settlement in sales and in distribution

● Optimize logistics costs using efficient visit planning

The backend for DSD consists of the following subcomponents:

● Incorporated manually into a single shipment using shipment transactions

○ Route master data

○ Different capacity criteria (optional)

Direct Store Delivery (Backend) 6761 6

Vehicle Space Optimization

● Specific information and documents for each tour

● Entry of outgoing and incoming control data

● Settlement of documents and data entered in the ERP system.

● Credit card documents

● Tour data contained in a handheld

Direct Store Delivery (Backend) 6761 7

Vehicle Space Optimization can only be implemented once the following

■ You have registered an optimization algorithm from a third party

■ You have set up an RFC connection.

Direct Store Delivery (Backend) 6761 8

DSD-Specific Master Data

● DSD-specific customer data is integrated in the customer master.

● DSD-specific driver data is integrated into the customer master.

● DSD-specific vehicle data is integrated into the equipment master.

● DSD-specific material data is integrated into the material master.

Direct Store Delivery (Backend) 6761 9

Additional DSD Data: Driver Data

● Activate Direct Store Delivery

● Define driver’s license categories

● Specify allowed account groups for drivers

● Transportation planning points to which the driver has access

● Driver’s driving license categories

● Lock periods in which the driver cannot carry out a shipment.

Direct Store Delivery (Backend) 6761 10

Additional DSD Data: Vehicle Data

● Activate Direct Store Delivery and, if required, Vehicle Space Optimization

● Assign means-of-transport type to equipment category and vehicle type

● Set indicator for your own vehicle or an external vehicle

● Transportation planning points

● Driver’s license categories

Direct Store Delivery (Backend) 6761 11

Additional DSD Data: Tour Data

● Transportation planning point

Direct Store Delivery (Backend) 6761 12

Additional DSD Data: Customer Data

Direct Store Delivery (Backend) 6761 13

Direct Store Delivery (Backend) 6761 14

Direct Store Delivery (Backend) 6761 15

Maintaining Extended Terms of Payment

● Permitted payment types

● Invalid bank details.