Direct Store Delivery in SAP

4/26/2019
Logistics Execution (LE)

Generated on: 2019-04-26
SAP ERP | 6.00.31
PUBLIC
Warning
This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product
documentation. The information included in custom documentation may not re ect the arrangement of topics in the SAP Help
Portal, and may be missing important aspects and/or correlations to other topics. For this reason, it is not for productive use.
For more information, please visit the SAP Help Portal.
This is custom documentation. For more information, please visit the SAP Help Portal 1
4/26/2019
Direct Store Delivery

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 the Direct Store Delivery process, goods are not distributed via a retail company’s warehouse/distribution
centers.
SAP Mobile Direct Store Delivery (MDSD) is an optional component in a Direct Store Delivery scenario. You can use this
optional application on mobile devices so that your eld sales employees do not have to document all the data from their tours
on paper. When the sales employees return from a tour, they can upload the data they entered on the mobile device to the
backend of DSD ( Direct Store Delivery (Backend) ). The data can then be processed.
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, owers, newspapers)
Directly in uence 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 speci c 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
4/26/2019
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 rst 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:
Speci c 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

4/26/2019
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 i n your system, you must ag 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.
Caution
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.
Note
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-Speci c Master Data

Use
In the master data you maintain speci c additional data for the Direct Store Delivery process. You can enter DSD-speci c data
for the following master data records:
Driver
Vehicle
Tour
4/26/2019
Customer
Material
Integration
Special elds are used to integrate speci c additional data for the Direct Store Delivery component into the ERP master data:
DSD-speci c customer data is integrated in the customer master.
DSD-speci c driver data is integrated into the customer master.
DSD-speci c vehicle data is integrated into the equipment master.
DSD-speci c material data is integrated into the material master.
Tour master data is master data that is speci c 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-speci c 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-speci c driver data:
Activate Direct Store Delivery
For more information, see the Implementation Considerations in Direct Store Delivery (Backend) .
De ne 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 de ned 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
4/26/2019
Lock periods in which the driver cannot carry out a shipment.
Note
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/ eet 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-speci c 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-speci c 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 ).
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.
4/26/2019
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 .
Additional DSD Data: Customer Data

Use
Using this function you can enter additional DSD-speci c 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-speci c customer data is integrated in the customer master of the ERP system.
Prerequisites
To use the DSD-speci c 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) .
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-speci c 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.
4/26/2019
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.
Note
If the customer is a driver, the system displays the Driver tab page. For more information, see Additional DSD Data:
Driver Data .
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 .
If Vehicle Space Optimization is activated, you can maintain data on the Vehicle Space Optimization tab page, which will
in uence the optimization algorithm.
You can nd 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 ag 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.
4/26/2019
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.
Note
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.
4/26/2019
2. Enter the required data.
3. Save your entries.
Additional DSD Data: Material Data

Use
You can use this function to de ne DSD-speci c 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-speci c 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 nd
these system settings in Customizing for Direct Store Delivery backend under Basic Functions.
For more information, see Implementation Considerations in Direct Store Delivery (Backend) .
You need to assign the following screen sequences in Customizing for the system to display the tab pages containing the DSD-
speci c 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 nd the system settings for the screen sequences in Customizing under Logistics General Material Master Con guring
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 in uence the Vehicle Space Optimization of a third party on the VSO Data
and VSO Plant Data tab pages.
Activities
You can nd the system settings for the material master for the Direct Store Delivery backend in Customizing under Material.
4/26/2019
Additional DSD Data: Deal Condition

De nition
A DSD-speci c 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 ful lls the conditions speci ed 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 nal 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 ful ll the assignments as
follows:
“And” condition
The current delivery for the customer must ful ll the conditions speci ed in the deal condition for the following elds:
Sales organization
4/26/2019
Distribution channel
Division
Plant
The system only considers the elds 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 de ned 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 de ne which conditions must be ful lled 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 speci ed a material for a deal condition, you cannot additionally determine a merchandise category or material
group.
If you have speci ed a merchandise category or material group for a deal condition, you cannot additionally determine a
material.
4/26/2019
For example, you can de ne 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 speci c total sales quantity must be reached in a delivery across all materials speci ed 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 bene t from the deal condition in the results:
You de ne the calculation base ( xed or proportional).
You de ne whether the customer receives the deal condition as free goods, or as a value or percentage discount.
You de ne 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 ful lls 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 speci c 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 .
4/26/2019
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 De ne Condition Types for Deal Condition Discounts , you
have speci ed 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 ConnectivityDSD 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-speci c 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.
Note
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.
Note
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 nal settlement run. The back-end system includes the deal condition
data in the nal settlement run.
Additional DSD Data: Manual Discount

4/26/2019
De nition
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 prede ned conditions in the delivery process during a tour. The driver decides whether to offer speci c
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 nal 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 de ned the required conditions in the back end.
In Customizing for Logistics Execution under Direct Store Delivery Handheld Connectivity DSD Connector Settings Mobile
Device Settings De ne Mobile Device Settings, you have activated granting of discounts at global level or for speci c groups .
For each sales area, you have speci ed 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 De ne Condition Types for Manual Discounts .
See also:
DSD Final Settlement Run
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
4/26/2019
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 de nes 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
Sales Driver
Mixed Driver
Preseller
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).
Note
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 speci ed sales area.
Visit Control Process

Use
4/26/2019
Visit control offers you many possiblities, from planning customer visits strategically (basis Visit Plans ) to actually performing
them (basis Visit Lists ).
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 speci c 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, V isit Control functions as follows:
Maintain visit plan
When planning a visit plan you create and manage visit plans.
Generate visit lists
The system uses a report of visit plans to create visit lists for a speci c 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 speci ed 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.
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.
4/26/2019
Note that corresponding visit plans are not affected by changes to visit lists.
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
agged 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.
Order processing
For visit/delivery appointments planned with visit control to be taken into account in order entry, you must ag 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 agged, 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.
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.
4/26/2019
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 in the Direct
Store Delivery component
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 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 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
4/26/2019
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 speci cations 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 speci c dates on which the customer should not be visited or receive deliveries. Customers are also not visited if you
ag 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 that you can use for your day-to-day work.
4/26/2019
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 speci ed 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 speci c dates on which the customer should not be visited or receive deliveries. You can also ag 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.
4/26/2019
Note
When modi ed visit plans are saved, Visit Control checks whether there are already visit lists containing future visits or
deliveries for the modi ed 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
De nition
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.
Note
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 in uence 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 .
4/26/2019
Note
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
Note
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 eld 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:
4/26/2019
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 , Vehicle Space Optimization and Route Accounting .
Transportation Planning uses DSD-speci c master data. For more information about DSD-speci c master data in
transportation planning, see DSD-Speci c Master Data .
4/26/2019
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.
Note
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
4/26/2019
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 (De ne 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 de ned in the material master.
Aggregation Categories
Use
4/26/2019
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
 Example
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 De ne 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 speci ed a sales area.
Activities
You enter customer-speci c descriptions for aggregation categories in Customizing (Customizing table De ne 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 .
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
De nition
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
4/26/2019
Before the capacity limit Number of Stops is taken into account in Dynamic Transportation Plannin g, 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 → De ne 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 ful lled:
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 → De ne
Capacity Limits .
The durations Travel duration , Direct travel duration , and Waiting time must be de ned 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 rst ship-to party
Pluswaiting time at rst ship-to party
Plustravel duration from rst ship-to party to next
Pluswaiting time at next ship-to party
Plustravel duration from previous ship-to party to last
Pluswaiting time at last ship-to party
Plusdirect 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
De nition
A shipment represents a physical goods movement between two or more locations.
4/26/2019
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
Variable capacity
Number of stops
Maximum duration
Loading units
Reload
Use
You can use this function to de ne 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.
4/26/2019
Reload as part of the tour process
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.
4/26/2019
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 nal settlement run.
Example
A delivery driver is on a tour. He or she delivers the materials that have been ordered to the rst 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 identi es 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
Variable capacity
Number of stops
Maximum duration
Loading units
Dynamic Transportation Planning has the following features:
4/26/2019
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.
Note
Dynamic Transportation Planning only takes account of deliveries whose delivery type is agged for Transportation
Planning in DSD Customizing.
If several deliveries for the same ship-to party are selected, Dynamic Transportation Plannin g 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 eld for the execution date of the visit lists is a mandatory eld. The system only selects visit lists that
are agged as active (inactive indicator is not set) and for whose visit plan types the shipment document is agged 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 identi es the speculative loads.
7. The system groups together the deliveries for a visit list.
8. The system assigns the selected deliveries to the rst shipment in the order speci ed.
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 de ned 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.
4/26/2019
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 identi ed for the visit list concerned in the deliveries selected initially.
The shipment document is agged 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 de ned 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 ful lled. 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
Note
You can use the Number of Attempts indicator in Customizing for the visit plan type to in uence dynamic
transportation planning.
If the Consider New Customers checkbox is agged 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-speci c 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 eld on the selection
screen, and the route for the delivery to nd which tour master is to be used.
If stipulated by the visit plan type, the system only creates one shipment per route.
4/26/2019
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.
Note
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
Purpose
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 elds:
Tractor
Trailer
Driver
Alternate driver
Process Flow
1. The system uses tour determination in Dynamic Transportation Planning as follows:
If no vehicle or driver is speci ed in the underlying visit list, the system uses the route, visit plan type and transportation
planning point to read the rst 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, if
available, the trailer until no deliveries remain or the rst 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.
2. 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 shipmen t ag 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 elds 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.
4/26/2019
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
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 elds
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 elds in the shipment header.
2. You select the deliveries you require.
Note
You can use various selection criteria such as shipping point, ship-to party, route, destination, due date, shipping
agent, and others to in uence the selection of deliveries for the shipment. To simplify selection, you can de ne a
selection variant for selecting deliveries in Customizing for each shipment type.
4/26/2019
1. In the following overview, Transportation Planning assigns the selected deliveries to the shipment that has been created.
Note
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.
1. 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.
2. 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.
3. 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
1. Enter a shipment number.
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 rst integrate an optimization algorithm from a third-
party vendor using an interface.
Integration
4/26/2019
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 con gure 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 pro le 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 nished.
4/26/2019
Vehicle Space Optimization Online

Use
You use this function to determine the optimum use of the loading room available for a shipment on a means of transport using
Vehicle Space Optimization (VSO) online.
Prerequisites
If you want the system to be able to call a third-party optimization algorithm using an interface, you have to set the Vehicle
Space Optimization Active indicator in Customizing.
To be able to use Vehicle Space Optimization, you must make the necessary settings in the following areas:
Customizing for Vehicle Space Optimization:
For more information about Customizing, see the Implementation Guide (IMG) under Vehicle Space Optimization.
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
Master data for Vehicle Space Optimization:
Materials (products and packaging)
Vehicles
Customers
To be able to carry out vehicle space optimization online, you must 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:
Select a shipment.
Choose Vehicle Space Optimization in the Shipment Overview on the Appointments tab page.
Choose Start calculation.
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
4/26/2019
The display appears in an ActiveX control.
You can change the displayed VSO packing proposals manually by repacking the load or moving packaging materials.
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.
When you save the 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 con gure 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 theDirect Store Delivery component, and is
therefore integrated into theLogistics 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.
4/26/2019
You can start the following activities for transfer orders in this screen:
Generate
Display conversions
Print
Con rm
The system provides prede ned 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)
4/26/2019
Overall status: Planning, at least, completed.
Procedure
To perform picking based on VSO packing proposals, proceed as follows:
On the SAP Easy Access screen, choose:
Logistics → Logistics Execution → Direct Store Delivery → Transportation Planning → Shipping → Display.
You reach the Display Shipment: Initial Screen.
Enter a shipment number.
Choose Enter .
The Display <Shipment type> <Shipment number>: Overview screen appears
Choose VSO packing proposals from the appointments tab.
The Overview VSO packing proposals (Picking) Shipment <Shipment number> appears
Select the required VSO packing proposals.
If you want to select all the VSO packing proposals that are assigned to a speci c process type, select the respective process
type.
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 con rmed
4/26/2019
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.
Driversthat 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 the shipment is the control document. This means that the shipment is agged 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 tobe delivered to is found) to the spool requestor IDoc
(application V7).
In the sales-oriented business process the visit list is the control document. The visit list de nes 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.
4/26/2019
The system triggers output determination when saving visit lists or shipments.
Output processing:If the shipment in visit list is agged 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
agged 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 gure illustrates the Output Control process:
Process flow for output control in Direct Store Delivery
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
4/26/2019
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 agged 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 de ned 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 process Visit plan type Relevant Documents indicator
Visit list Transportation Make delivery
Logistics-oriented Delivery driver No Yes Yes
Logistics-oriented Sales driver Yes Yes No
Logistics-oriented Mixed case Yes Yes Yes
Sales-oriented Preseller Yes No No
For more information, see:
Roles in Visit Lists
IMG documentation under De ne 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 con gured in Customizing for the visit plan type.
Process Flow
4/26/2019
In the logistics-oriented business process, the shipmentis 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 speci es 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 de nition 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.
Note
So that the driver always has access to current data, you should not perform the download until just before the start
of the tour.
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 de ne the processing routine with which the download is executed for each application and transmission medium (IDoc or
printout).
4/26/2019
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 nds the correct conditions de ned in Customizing when it saves the
visit lists or shipments for a particular combination of data. Output determination de nes 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 de ned 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.
Ouptut Processing
Use
The system processes the output 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 output status. You can set when
the system is to begin with output processing by the processing time.
The processing time for Output Control message processing is:
For the shipment, dependent on the shipment status
For the visit list, dependent on the execution date
Features
4/26/2019
In Customizing, you de ne the processing routines that the system is to carry out during message 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 de ned 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 xed 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
satis ed:
1. Printout and IDoc: The output typesmust be de ned.
Note
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.
1. Printout and IDoc: The minimum shipment statusthat the system requires for the download must be de ned.
Note
You de ne the shipment status in the Customizing table of the download output types.
1. Printout: For each shipment typeand per transportation planning point, it must be de ned which individual messages the
system should print and in which order.
Note
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
4/26/2019
error in the processing log for the individual message.
2. IDoc: For each shipment typeand transportation planning point,it must be de ned 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 de ne 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
ow.
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 ow.
IDoc Creation
In Customizing, you can de ne 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 ow.
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 ow.
Valuated Delivery Note

Use
You use the Valuated Delivery Not e 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. Avaluated 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 de ned for the a valuated delivery note.
The message type must be assigned to a pro forma billing document.
Message determination must be customized.
4/26/2019
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
Note
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.
Note
In the print program /BEV1/VD_BEW_LIEF_BACKGROUND, the system checks whether this is the rst time the
delivery and billing document data is being printed or whether it is a repeat print. If it is the rst 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 ow.
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 xed 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:
4/26/2019
Printout/IDoc: De ne 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 de ned (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.
Printout/IDoc: Output processing only takes place if the visit list to be printed is active.
If this prerequisite is not satis ed, output processing is cancelled. The system displays an appropriate note in the processing log
with the status Incorrect Processing.
Printout: For each visit plan type it must be de ned 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.
IDoc: For each visit plan type it must be de ned which IDocs the system should create and with which function modules.
Features
Print Output
In Customizing, you can de ne 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
4/26/2019
In Customizing, you can de ne which IDocs the system should create and with which function modules.
The system does not save the visit list in the sales document ow. 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 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 nished, 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).
 Example
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.
4/26/2019
You can use the subsequent processes in Route Accounting (for example, check the data in the Settlement Cockpit, trigger the
nal settlement run) irrespective of how you transferred to tour data to the system.
Recommendation
Route Accounting was developed for the nal 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 nal
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 speci c transactions for different tours
Enter all relevant data for a tour ( Tour Data Entry )
Finish off tour maintenance ( Settlement Cockpit )
In the nal settlement run (Settlement Cockpit), the system creates documents and billing documents and makes postings in
SAP FI. After the nal settlement you can display the settlement document, the application log and the document ow. 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
4/26/2019
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 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 con rms 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:
Speci c tour data: For example, expenses resulting from refueling the vehicle, time spent in traffic jams, breaks
and kilometers driven.
Speci c 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 con rms 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 nal settlement run. The system creates documents and billing documents and makes postings in SAP FI.
12. You can call the documents in the document ow. 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

4/26/2019
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 con rmations of receipt
4.Check-in
After nishing 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 con rmed . 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.
Speci c material data
Speci c customer data
Driver data
Driver text settings
Vehicle data
Credit data (credit limit and master data)
4/26/2019
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-speci c master data
The system loads the DSD-speci c 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 de ne 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 rst loads the current, modi ed 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.
4/26/2019
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 lls the elds 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 nd 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 nd 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
4/26/2019
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 nal
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
4/26/2019
Invoices that were issued to the customer when delivery was made
Orders for future deliveries
Settlement Cockpit
De nition
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 ( nal settlement run). In the nal 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 speci c processes
of the execution of the tour.
Check-out/check-in data
4/26/2019
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 con rmation 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.
4/26/2019
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 nal 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.
4/26/2019
Editing time data for a tour
You can enter different and the same time types several times. You can create customer-speci c 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-speci c 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 speci c 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:
4/26/2019
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 de nes 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 nal 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-speci c 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-speci c 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
4/26/2019
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)
4/26/2019
Completed (3)
For each processing step, the processing status speci es 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
1. Select the required tour in your worklist and choose Display Settlement Document.
2. The system displays the settlement document on the right-hand part of the screen.Under the settlement document
header, the system displays the areas for cash differences and quantity differences.
Document ow
Use
You use this function to display the documents created by the system for a settlement document or a tour. In the document ow
display you can determine whether the system has created a document for every relevant tour transaction. In the document
ow display you can view the numerical keys for the different documents.
Prerequisites
Activities
1. In the Settlement Cockpit, select the settlement document required or the tour contained there and choose Document
Flow.
2. The system displays the document ow and corresponding documents to the right of the screen page.
Example
The document ow can contain the following document types:
001 SD shipment
002 Load delivery
003 Return load delivery
004 VC visit list
010 Delivery (backend)
4/26/2019
012 Sales order (backend)
014 Invoice (backend)
015 Accounting document (backend)
016 Contact (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 nal 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 nal 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 nal settlement run in accordance with the Customizing settings.
2. When the system has completed the nal settlement run, it issues a message.
3. You can display the log for the nal settlement run.
Note
In Customizing, you can de ne when and how the system carries out the nal settlement. The system can carry out
the nal settlement as follows:
Automatically after difference determination
Automatically after difference determination, when no differences have occurred
4/26/2019
Manually in the settlement cockpit
Automatically in the background
Result
The system has processed the tours and posted the relevant documents. The nal 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 nancial 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 ).
You can also clear the open items manually ( Executing DSD Clearing Online ).
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).
Note
4/26/2019
The clearing status in the Route Accounting component does not in uence 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).
Note
The clearing status in the DSD Route Accounting component does not in uence clearing in Financial Accounting.
Activities
1. You make a selection and enter a status for each document in the eld 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.
4/26/2019
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
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 de ne in Customizing which elds from the IDocs the system maps to which elds in the DSD
Connector tables. There are much fewer elds 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.
4/26/2019
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 modi ed 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 .
SAP Mobile Direct Store Delivery

Purpose
SAP Mobile Direct Store Delivery (MDSD) is an optional component in a Direct Store Delivery scenario. The application runs on
mobile devices and you can use it as an alternative to having your sales representatives write all data down on paper while they
are on their tour and enter it into the system when they return to the warehouse.
In order to use the mobile application, you have to rst install the backend system and make all relevant Customizing settings.
Integration
Data upload to the backend system at the end of the tour triggers the following:
Errors are monitored
Balances are settled
Sales documents, nancial postings, and materials movements are updated
Upon completion of these processes, nal billing can be processed. Invoices that were created in the backend can be issued to
customers on site from the mobile device. Customers who have not received their invoices on site receive them later.
Features
MDSD supports sales representatives with the following tasks:
4/26/2019
Processing a tour of customer visits
Tracking vehicle merchandise and cash inventory
Note
Other tasks depend on their respective roles.
The Route Accounting functionality allows sales representatives to do the following:
Checking materials out of the warehouse
Making deliveries
Checking in returned materials and collected payments upon return to the warehouse
Balancing and settling materials and payments
Sales representatives can log all tour-related activities using mobile devices. During a tour, they typically do the following:
View a list of all visits and perform the activities that are necessary for each visit, that is sales, delivery, invoice issuing
and cash collection
Rearrange the order of the visits and create new unplanned visits, if necessary
Update the customer’s status with a reason code that indicates why a visit could not be performed
Adjust quantities during the actual delivery process, if necessary
Collect returns
Issue invoices
Collect payments and issues payment receipts
Note
Material and cash shortages are usually charged to the sales representative.
SAP Mobile Direct Store Delivery - Process

Overview
Purpose
This overview covers all activities that need to happen in a Direct Store Delivery process that includes mobile devices:
Data download
Check-out
Tour processing
Check-in
End-of-day
Data upload
Process Flow
4/26/2019
The SAP Mobile Direct Store Delivery (MDSD) process consists of the following main steps:
Download from backend system to mobile device
During synchronization, transactional data and master data is downloaded from the backend system to the mobile device.
Start-of-day
This is the initial activity a sales representative performs at the beginning of the day. Start-of-day consists of recording basic
tour data, such as driver ID, vehicle ID, and odometer reading.
Check-out
Check-out consists of checking what was loaded onto the vehicle. This includes both materials and cash. Sales representatives
can enter potential discrepancies, which can then be veri ed and approved by their supervisors.
Tour processing
Sales representatives view a list of all visits. For each visit, they either perform the associated activities or update the visit
status with a reason code to indicate why they could not visit a customer (for example, customer was closed, driver ran out of
time). Sales representatives can also rearrange the order of their visits as well as create new unplanned visits. The main
activities performed at the customer site are:
Delivery with pre-sold orders – At the customer site, sales representatives take the pre-ordered stock out of their truck
and print a delivery note or an invoice.. If necessary, sales representatives can add items and change item quantities.
The system also supports the return of goods (for example, spoiled goods, wrong items) and the return of empties. Sales
representatives can add returned goods and empties to deliveries.
Delivery without pre-sold orders – This is the delivery of materials that were not ordered. The sales representative sells
the materials directly off his vehicle. In this process, the sales representative creates new deliveries. This includes both
normal outbound deliveries and return inbound deliveries. The physical processing of the delivery is similar to that of pre-
sold order deliveries.
Invoice issuing – In Direct Store Delivery , unlike other SAP systems, delivering and invoicing are part of the same basic
process. The sales representative can issue a legal invoice. Customers who do not receive an invoice, receive a delivery
note instead.
Payment collection – Sales representatives collect payments for current deliveries or outstanding open items.
Customers are issued payment receipts.
Order taking for future deliveries – Sales representatives perform pre-selling order taking. These orders are then
delivered during one of the next tours.
The following general tour-related activities are also supported:
Recording of inventory adjustments – Sales representatives can record inventory adjustments, for example, in the case
of breakages.
Recording driver expenses – Sales representatives can record miscellaneous expenses, such as tolls, parking fees, and
gas.
Check-in
Check-in is a validation of materials returned to the warehouse. The sales representative enters returned quantities, which can
then be veri ed and approved by a supervisor. During pre-settlement balancing, the returned materials (initial balance –
deliveries + returns = check-in balance) are checked.
4/26/2019
End-of-day
End-of-day consists of recording end-of-tour data and returned cash/payments. During pre-settlement balancing, the returned
cash/payments (beginning balance – driver expenses – payments to customers + collections from driver + collections from
customers = end-of-day balance).
Upload from mobile device to backend system
During synchronization, transactional data is uploaded from the mobile device to the backend system.
Administrative Functions
Features
Driver and customer languages

The application supports one driver language (used on screens) and up to two customer languages (used for output). You make
the appropriate language settings in the backend Implementation Guide. The driver language is explicitly set. You can specify
the customer language in the DSD Connector Cockpit andcon gure which two output text languages are to be transmitted to
a device.
Multi role authorizations

All transactions and screens can be assigned to authorization roles. If a transaction or a screen is not assigned to a role, no
authorization check is performed. Some of the mobile transactions are meant to be used by someone other than the driver.
 Example
It is possible that check-in and check-out discrepancies require a supervisor’s approval. In this case, you would assign
discrepancy approval to a supervisor authorization role. This means that sales representatives would have to give their
devices to a supervisor who would enter his password and perform the transaction. The supervisor’s authorization expires on
the device after he has carried out the transaction.
Group-speci c roles
You can assign a role to a group of mobile devices and de ne a password for this combination. This password is then used on all
mobile device that belong to this group.
Time stamps
System dates and time stamps are automatically recorded for each visit, activity, and document. This leaves an accurate audit
trail of what was performed when and how long each task took.
Organizational Units
Use
The organizational units that are relevant for SAP Mobile Direct Store Delivery are:
Sales organization
4/26/2019
Distribution channel
Division
Settlement office
You cannot create or change organizational units on the mobile device. Organizational units are inherited from the route
accounting database. Each uploaded set of mobile device data is processed through a settlement office that is related to a
combination of sales organization, distribution channel, and division.
Customer Master Data

Use
Basic customer master data is downloaded to the mobile device. You can only display this data but you cannot change it or add
new customers.
Features
One-time customers
The mobile application supports transactions with one-time customers, that is customers for whom you do not want to create a
backend customer master record. A special one-time customer master record is used for these transactions. Separate visits
are created for each one-time customer on a tour. All visits are associated with the same one-time customer number. The sales
representative can enter the actual name and address information for the individual one-time customers.
Financial open items
Financial open item information is downloaded for the associated customers. Additionally, when invoices are created on the
device, the associated open items are created as well. Customer payments can be applied towards these open items. Final
matching is performed in the route accounting database.
Tour
De nition
A tour consists of a number of individual visits and corresponds to a shipment to which a driver and a vehicle are assigned. The
visit list for a tour represents the customers to be serviced on that tour. A visit is assigned to one customer only. Multiple visits
can be created for the same customer.
Each visit consists of one or more activities. Activities represent actions to be performed by the sales representative at the
customer site. The following is a list of possible activities:
Deliver pre-sold order
Sell and deliver without pre-sold order, that is sell directly from truck
Take order for future deliveries
Invoice (used in manual invoice generation)
Collect payments
Return delivery
4/26/2019
Take return order for future pickup
Use
The work that needs to be done displayed in a list of visits and activities. The visit contains all customers to be visited and the
activity list contains the actions that need to be performed at each customer’s site.
Sales representatives can also create unplanned visits and activities. Once these are created, they are processed in the same
way as pre-planned visits and activities.
Activities are linked to their associated transaction documents (deliveries, invoices, orders, etc.)
See also Tour-Related Activities .
Tour-Related Activities
Use
SAP Mobile Direct Store Delivery supports sales representatives with a number of activities they need to carry out while on
their tours.
Features
Resequencing visits
The download provides a default order in which the visits are to be carried out. However, the sales representative can
resequence the order of his visits.
Note
The new sequencing information is not uploaded to the backend.
Creating unplanned visits
Sales representatives can create new, unplanned visits. The supported scenarios are as follows:
Existing customer in visit list – It is possible to create additional visits for the same customer within a tour.
Existing customer not in visit list – A visit can be created for a customer who is not in the visit list but whose customer
master record has been downloaded to the mobile device.
One-time customer – A visit is created using the one-time customer number. The sales representative can enter this
customer’s name and address information.
Entering odometer readings
The sales representative can enter the odometer reading at each customer visit. This information is uploaded to the route
accounting database for statistical purposes only.
Changing start-of-day information
The downloaded tour indicates planned driver, co-driver, vehicle, and tour times. At-start-of day, sales representatives can
change the driver and vehicle information. They can also enter the odometer reading.
4/26/2019
Recording driver expenses
Sales representatives can record cash expenses incurred on their tour. You can con gure the application to support various
expense types (tools, gas, parking, etc.). Sales representatives can then enter the individual amounts per expense type. Sales
representative expenses are used in the end-of-day discrepancy calculation.
Material Management
Use
Material master data is downloaded to the mobile device upon check-out. You can display but not create or change this data on
the mobile device.
Features
Material data is organized using the following objects:
Basic and sales area material master view data
Alternative units of measure (UoMs)
Empties bill of materials (BOM)
Product hierarchy
Basic and sales area material master views
The general material master data is separated into two tables and structured in the “basic data” and “sales area” views.
Note
The mobile device inherits organizational units from the Settlement database because the route accounting database only
supports a single sales area.
Alternative units of measure
A table containing associated alternative units of measure (UoMs) is downloaded for each material. Alternative UoM
functionality is explained in greater detail in Inventory Management .
Empties bill of materials (BOM)
Separate empties BOMs are maintained. These BOMs are used to explode tied empties on orders, deliveries, and invoices.
Material sorting and searching
Materials are sorted in list screens (for example, check-out and check-in) according to their material numbers. Sorting is based
on material number and searching is allowed on material description, material number and EAN.
Inventory Management
Use
4/26/2019
With regards to inventory management, some features in SAP Mobile Direct Store Delivery (MDSD) are the same as in the
backend system whereas others are different.
Features
Units of measure
MDSD supports multiple units of measure (UoMs). Sales representatives can choose to change UoMs when processing
deliveries and orders.
Higher-than-base UoMs
If transactions are entered in UoMs that are higher than the base UoM, the quantities are converted to base UoMs.
Sub-base units of measure
Sub-base UoMs are a feature that is speci c to Direct Store Delivery . A sub-base UoM is de ned as a UoM that is a fraction of
the base UoM.
Note
Sub-base UoMs correspond to fractional quantities that are used in other SAP applications. However, instead of 1 bottle
being represented as 0.04167 cases, MDSD uses sub-base UoMs. Materials can have 0 or 1 sub-base UoMs.
 Example
The base UoM for a 12-pack of beer bottles is the “case”. Sales representatives typically perform transactions involving
whole cases. However, there are occasions when individual bottles are delivered.
On-truck stock
The mobile application has balances of on-truck stock levels at all times. The initial stock level is created from the con rmed
check-out quantities. When check-in is performed, the current stock levels are used as planned check-in quantities.
Quantities are automatically updated when deliveries are con rmed or cancelled. Outbound deliveries subtract stock, whereas
returns add stock. On-truck quantities are also updated immediately with inventory adjustments.
Quantities are tracked using a combination of material, unit of measure, and stock type. If a material has a sub-base UoM,
separate inventory records are maintained for the base and the sub-base UoMs.
There are two types of stock: normal stock and damaged/blocked stock. All checked-out stock is assumed to be of type
“normal”. Materials that are returned can be posted to normal or to damaged stock.
Empties
Untied empties are treated as individual materials and, consequently, from an inventory management perspective, are
considered ordinary materials. Tied empties are not tracked in inventory management.
Check-out
Check-out is the process that con rms the stock that has been loaded onto the truck. The planned check-out balances are
downloaded to the mobile device. The sales representative changes the actual quantities as needed, and then con rms any
discrepancies. Usually, a supervisor validates the data.
4/26/2019
Note
Validation can be password-protected.
Check-in
Check-in is performed similarly to check-out. Planned check-in quantities are generated from on-truck stock quantities. The
sales representative adjusts quantities as needed, and any discrepancies are validated.
Inventory adjustments
Between check-out and check-in, sales representative can make inventory adjustments. These adjustments are used to keep
the on-truck stock inventory accurate. For example, if a case of beer is dropped and lost, it needs to be deducted from inventory
so that the application does not treat it as available for sale.
Sales representatives is accountable for all adjustments. From both a business and a technical perspective, inventory
adjustments are adjustments to checked-out and checked-in quantities. Inventory adjustments result in additional check-
in/check-out items on separate adjustment check-out/check-in headers. Negative adjustments mean that a sales
representative has checked in less than planned and positive adjustments mean that he has checked out more than planned.
Payment Processing
Features
On-truck payment balance

On-truck payment balances are tracked similarly to on-truck stock. However, there is no on-route adjustment of payment
balances.
Currencies
Mobile Direct Store Delivery supports one currency. This currency is con gured in the DSD Connector Cockpit .
Collection type
You can specify for each customer whether the sales representative needs to collect payments. You have the following two
options:
Sales representatives do not collect payments at all. In this case, the customer can either mail the payment or use bank
transfer, or the customer’s bill-to partner remits the payments.
Sales representatives collect payments after they have delivered the products.
Payment types
You can con gure different payment types. Cash, check, and credit card are the types most commonly used.
Note
The mobile device payment type con guration must be the same as the payment types in the route accounting database.
4/26/2019
Beginning payments
Unlike material check-out, initial payment/cash balances are not downloaded to the device. After material check-out is
con rmed, sales representatives are prompted to manually enter their initial payment balances (this applies to the delivery
driver and van sales processes; this functionality is not available to presellers).
End-of-day payment count and discrepancies

End-of-day payment count works similar to material check-in. Planned payment counts are generated from on-truck payment
balances. The sales representative can then adjust actual amounts as well as view and con rm any possible discrepancies.
Collections
Use
The customer master collection type eld determines whether payments are collected from a customer whereas payment
methods and types determine how payments are collected.
Payment type
You need to specify for each payment collection customer which payment types can be accepted.
Cash
Check
Credit card
The payment method represents a combination of these payment types:
Payment method
Typical payment methods are:
Cash only
Cash or check
Features
The sales representative initiates collections from the Activity List screen. A collection activity is added to the Activity List
when an invoice is created for a to-be-collected customer. Additionally, sales representatives can perform collections by
creating new collection activities.
When collection is carried out, the system displays a list of all open invoices. From this screen, the sales representative selects
the invoices that are to be assigned to the payment. He then selects collection and chooses the payment type. The mobile
device only displays those types that are valid for the current customer.
Partial payments are supported; nal matching happens in the backend. When the sales representative con rms collection, he
is prompted to print a collections receipt. Collections just like deliveries, invoices, and orders are legal documents, and,
therefore, cannot be changed after they have been con rmed.
Delivery, Invoice, and Order Processing

4/26/2019
Use
The structure of deliveries, invoices, and orders is similar in that all documents consist of headers and items that contain the
following information:
Document header
Document number
Link to visit and tour
Indicator that states if a document was created on the mobile device or downloaded from the backend
Indicator that tracks whether the sales representative has modi ed the document
Create/change time stamp
Status
Cancellation ag and reason code
Document item
Materials and quantities
Sub-items for both normal materials and tied empties
Link to the associated item (for tied empties)
Indicator that tracks whether the sales representative has modi ed the item
Reason code to indicate why the item was changed
Document numbering
Document numbers are speci ed in the DSD Connector Cockpit and downloaded to the individual devices. Document numbers
are incremented by one with every new document of a given type. After the tour data is uploaded in the route accounting
database, the last document number is stored in the DSD Connector Cockpit and used to determine initial number download
for new tour data.
Document status
The status of documents is either unprocessed or con rmed . Document statuses are independent from activity statuses and
are stored on the device in the background. A document is con rmed when it has been transmitted to the customer – either
the document has been printed or the sales representative has indicated customer acceptance. As soon as a document has
been con rmed, it is locked and cannot be changed any more. If a con rmed document needs to be changed, the sales
representative creates a copy of the cancelled document. This way, he can then change the new document while maintaining
the audit trail of the cancelled document. It is also possible for the sales representative to cancel a document without creating a
copy rst.
Editing and displaying documents

Uncon rmed documents can be edited. As soon as a document has been con rmed, it can only be displayed.
Changing documents
4/26/2019
Sales representatives can change documents that have not been con rmed. They can change quantities and order items for
existing deliveries as well as add items. If they need to delete items, these items are not actually deleted but the quantity is set
to zero. When making any of these changes, sales representatives enter reason codes that explain why they have made the
changes.
Tied empties
Tied empties represent the full empties on a document (for example, a full case of 24 beer bottles has 24 implied empty bottles
and 1 implied empty case). Within the mobile application, each item whose material has an associated empties BOM, tied
empties are exploded and added as sub-items. Sub-items for tied empties are displayed on a separate screen. The main screen
only shows the normal material items. The tied empties screen shows totals for each implied empties material number.
 Example
If multiple items have “12 ounce brown bottle” as implied empties, the tied empties screen shows one item for “12 ounce
brown bottle” with the total quantity.
The tied empties summary is the default view but tied empties can also be shown as associated with normal items. This allows
you to view the exact quantity of empties for each individual normal item.
Normal transactions versus return transactions

Deliveries and orders support both outgoing transactions and incoming, that is return transactions. These are not
differentiated at header level. The sales representative has to manually set a return ag at item level to mark an item as a
return. When a return item is added, the sales representative needs to select the reason for the return and indicate whether
the return is going into normal or blocked stock.
Customer master data

The value of some customer master elds has direct impact on delivery and invoice processing. You can specify the following:
Collection type (see Payment Processing )
Proof of delivery (POD) versus invoice (see Invoicing )
Invoice generation method (ditto)
Order Processing
Use
A normal order represents an order for future delivery whereas a return order represents an order for future pickup. From a
processing perspective, orders behave similar to deliveries. Orders can be updated, con rmed and cancelled just like deliveries.
Upon order con rmation, a con guration setting determines whether the order is priced. Processing and display of pricing
results is similar to invoice pricing, except that no splitting or combining is performed.
Delivery Processing
Use
4/26/2019
A delivery represents the actual materials and quantities that were physically delivered to the customer. SAP Mobile Direct
Store Delivery supports two delivery scenarios.
Delivery of pre-sold orders – In this scenario, deliveries with planned materials and quantities are downloaded to the
mobile device. The sales representative can add or changes delivery items as needed so that the delivery re ects the
actually delivered quantities. New items can either represent outbound or return items. The number of the delivery on
the mobile device is the number of the downloaded delivery.
Delivery without pre-sold orders – The sales representative can create new deliveries for a customer visit. In this
scenario, the sales representative rst enters the delivery date and the PO/reference number and then adds individual
items. The mobile device delivery number is the number assigned according to the document numbering routine of the
mobile device.
Con rmation
When the delivery is complete, the customer has to con rm the delivery. The customer master record determines how a
delivery is to be con rmed. The POD/Invoice Indicator eld speci es whether the customer receives a printed Proof of Delivery
(POD) or an invoice. If the sales representative con rms a delivery for a POD customer, the system prints a POD and sets the
delivery status to Con rmed . If he con rms a delivery for an invoice customer, the delivery status is set to Con rmed and the
invoicing routine is triggered.
Con rmation also updates the on-truck inventory balances to re ect the delivered or returned quantities. The mobile device
prevents the sales representative from delivering more products than can be found on the truck
Note
Negative inventory is not supported.
Invoicing
Use
The invoice re ects the actual materials, quantities and values of the materials that have been delivered. The mobile
application supports both downloaded invoices and invoices that are created on the mobile device; however, the latter is more
common.
Features
POD/Invoice
You can specify for each customer whether the customer should receive a delivery note (POD) or an invoice:
If the sales representative issues a proof of delivery (POD), the invoice will be issued by the backend system.
If the sales representative issues an invoice, the customer receives the invoice directly from the sales representative at
the end of the visit
In case a customer is to receive the invoice from the sales representative, there are two possible scenarios.
Invoice created on the mobile device – In this scenario, the invoice is generated by using material and quantity information
directly from the delivery; and pricing is carries out via pricing in DSD. In this case, the invoice number is the number assigned by
the document numbering routine of the mobile device. This scenario is most commonly used because it is not possible to create
an invoice until the actual delivery has been made.
4/26/2019
Downloaded invoice – The backend can be con gured to pre-generate the invoice, which is then downloaded to the mobile
device. The mobile device invoice number is the number of the downloaded invoice. This scenario is very limiting in that once an
invoice is generated in the backend, it cannot be changed. If a change is required, the old invoice is cancelled and a new invoice
is generated that is re-priced on the mobile device. Therefore, this scenario only makes sense in business situations where
deliveries (and thus invoices) are rarely changed.
When an invoice is generated on the mobile device, the device checks that the invoice does not push a customer above his
credit limit. After the credit limit check has been performed, the invoice is displayed for review.
Note
It is not possible to change materials and quantities directly on the invoice; to do so, you have to change the delivery and
regenerate the invoice.
Invoice generation method
You have to specify for each customer who receives an invoice, whether invoices are to be generated automatically or manually.
Typically, invoices are generated automatically as part of the delivery execution process, in which case the sales representative
does not activate invoicing as a separate process.
Some customers may receive multiple deliveries that need to be combined into fewer invoices. This implies that the invoices
cannot be generated as part of delivery processing because the sales representative must rst complete all deliveries before
any invoicing can be carried out.
Con rmation
When the sales representative prints an invoice, it is marked as con rmed. For customers who pay the sales representative
directly, con rmation also results in the creation of an open invoice item. This open item is then available along with downloaded
open items during the payment collection process.
Visit and Activity Statuses

Visits and activities are assigned one of the following statuses:
•Not processed (NP)
•Successfully processed (SP)
•Partially processed (PP)
•Unsuccessfully processed (UP)
•Rescheduled (RS)
Visit statuses
Visit statuses are used to track the completion of visits. Typically, a sales representative must complete all visits before he can
complete his tour. Visit statuses are either set automatically based on the associated activity statuses or the sales
representative can set them manually.
The following table shows the stages at which the various visit statuses are set.
NP SP PP UP RS
4/26/2019
NP SP PP UP RS
Status set
automatically
All activities are X

unprocessed

successfully
processed

unsuccessfully
processed
Activities have X
multiple statuses
and one or more
activities have
status Not
Processed (NP)
Activities have X
multiple statuses
and no activity has
status Not
Processed (NP)
Status set manually
Visit is rescheduled. X
Sales representative
enters reason code
and reschedules the
visit.
Visit is not X
performed. Sales
representative
enters reason code.
Activity Statuses
Activity statuses are used to track the completion of the associated documents. These statuses are set automatically.
The following table summarizes the stages at which the various activity statuses are set.
NP SP PP UP RS
Delivery activity status
Delivery X
downloaded to or
created on mobile
device
Delivery con rmed X

for POD customer
4/26/2019
NP SP PP UP RS
Delivery con rmed X

for invoice customer
Con rmed delivery X

cancelled
Invoice created X
Invoice X
printed/con rmed
Printed/con rmed X
invoice cancelled
Order activity status
Order downloaded X
to or created on
mobile device
Order con rmed X
Con rmed order X

cancelled
Payment collection activity status
Collection created X
on mobile device
Collection X
processed
Collection cancelled X

Direct Store Delivery in SAP

Uploaded by

Copyright:

Available Formats

You might also like

Direct Store Delivery in SAP

Uploaded by

Document Information

Original Description:

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

Direct Store Delivery in SAP

Uploaded by

Copyright:

Available Formats

4/26/2019

Logistics Execution (LE)

SAP ERP | 6.00.31

For more information, please visit the SAP Help Portal.

Direct Store Delivery

Direct Store Delivery (Backend)

Implementing Direct Store Delivery enables you to:

Directly in uence end customers, as the consumer products manufacturer

Optimize process settlement in sales and in distribution

Optimize logistics costs using eﬃcient visit planning

The backend for DSD consists of the following subcomponents:

Outbound deliveries can be:

Incorporated manually into a single shipment using shipment transactions

Route master data

Diﬀerent capacity criteria (optional)

Vehicle Space Optimization

Speci c 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

You have set up an RFC connection.

DSD-Speci c Master Data

DSD-speci c customer data is integrated in the customer master.

DSD-speci c driver data is integrated into the customer master.

DSD-speci c vehicle data is integrated into the equipment master.

DSD-speci c material data is integrated into the material master.

Additional DSD Data: Driver Data

Activate Direct Store Delivery

De ne driver’s license categories

Specify allowed account groups for drivers

Transportation planning points to which the driver has access

Driver’s driving license categories

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

Additional DSD Data: Tour Data

Transportation planning point

For more information on tours, see Tour .

Additional DSD Data: Customer Data

You must make the necessary geocoding settings in Customizing.

The Geocoding screen appears.

2. Enter the required data.

Maintaining Extended Terms of Payment

Permitted payment types

Invalid bank details.

The Extended Terms of Payment screen appears.

3. Save your entries.

Additional DSD Data: 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

Additional DSD Data: Deal Condition