Automotive Consulting Solution
Customer specific processes in the automotive industry - Sales and
Shipping
Agenda
1. Benefit for the Customer
2. Description of the Function
3. The Function in the System
4. Technical Information
© SAP SE or an SAP affiliate company. All rights reserved.
2
Customer Benefit
Solution
 Proven solutions/services of SAP Automotive Consulting
 Solutions already running productive at several customers
 Solutions and documentation are available in German and English
Cost
 Exact calculation of implementation cost. Implementation for fixed price
 6 months of free follow up care operations for bug corrections starting at
the date of installation within the development landscape. Afterwards
chargeable consulting support starts
 No additional ongoing costs (i.e. maintenance cost)
Time
 Prompt implementation possible
 Defined timeframe for implementation
© SAP SE or an SAP affiliate company. All rights reserved.
3
Agenda
1. Benefit for the Customer
2. Description of the Function
3. The Function in the System
4. Technical Information
© SAP SE or an SAP affiliate company. All rights reserved.
4
Motivation
 There are a lot of customer specific requirements, that need to be realized at the
incoming order and at the shipping process
 The goal is a technically standardized realization of the requirements without
modifications
 To face the requirements in the area of EDI, the SAP ACS “Exit control
framework” was used to show transparently, for which customer which processes
are used respectively activated
© SAP SE or an SAP affiliate company. All rights reserved.
5
Basic information
Customer specific requirements could be divided into the following areas:
 EDI In- and Outbound including the processing of additional fields/information
 Forms (e.g. print out of additional fields/information)
 Functions/logics at the incoming order and shipping
In the following presentation, the function/logics at sales inbound and shipping are
shown with selected customer examples.
© SAP SE or an SAP affiliate company. All rights reserved.
6
Agenda
1. Benefit for the Customer
2. Description of the Function
3. The Function in the System
4. Technical Information
© SAP SE or an SAP affiliate company. All rights reserved.
7
CUMMINS: Requirements
Customer logic:
Cummins Power Generation (CPG) is sending forecast delivery schedules (FDS)
via EDI. When CPG has transmitted for one material a FDS in the last week and
in the actual week doesn’t transmit a call for this material, it could be assumed,
that CPG has no more requirements for this material. CPG isn’t sending a
cancelation message. The fact, that no new call is transmitted, is the indicator that
for this material no more requirements are needed.
At the normal EDI inbound process, a processed FDS is active in the SDscheduling agreement until a new FDS actualizes the existing call. If CPG doesn’t
transmit a new call, it is the sign, that the old call is not valid any more and the
existing schedule lines have to be deleted from the scheduling agreement. This is
done via the processing of the Zero-quantity-FDS.
© SAP SE or an SAP affiliate company. All rights reserved.
8
CUMMINS: FDS processing logic
At the inbound processing of FDS from CPG, the actual call date and the actual
call number are written per sold-to party in an additional table. The update is done
even if the processing in the scheduling agreement failed. As CPG always
transmits all the materials, for which requirements are existing, it is enough to
protocol the actual FDS data per sold-to party.
This entry in this table means, that the most actual calls from CPG are dated at
the 27.08.2010.
© SAP SE or an SAP affiliate company. All rights reserved.
9
CUMMINS: Creation of Zero-quantity-FDS
After the processing of the FDS, a program checks for the sold-to party of the
above mentioned additional table in all SD scheduling agreements the actuality of
the FDS data. As soon as a call date in a scheduling agreement is older than the
date, which has been actualized in the additional table via the incoming FDS, a
Zero-quantity-FDS is created for this SD scheduling agreement.
© SAP SE or an SAP affiliate company. All rights reserved.
10
NISSAN/CAMI: Requirements
Customer logic:
The customer orders a material for different model years. As a customer material
number changes independently from the model year and the maintenance of the
customer material number would be quite intransparent, the model year should be
used in the field “usage” of the scheduling agreement to distinguish the model
years.
Usage of Summarized JIT-calls:
Generally, for the processing of Pick-up-Sheet orders (GM, TOYOTA-Manifest,…)
as well as KANBAN-numbers (NISSAN, HONDA) summarized JIT-calls should be
used. Consequently, the logic for the field “usage” has to be transferred to the JITarea.
© SAP SE or an SAP affiliate company. All rights reserved.
11
NISSAN/CAMI: Settings
Customizing:
To be able to use different usages in JIT, the qualifier “UI” has to be customized in
the additional JIT reference numbers.
Maintenance of an additional table:
As the manual filling of the additional
fields in Summarized JIT-calls is only
limited (Maximum of 3 fields at headerand item level), it should be possible to
maintain different fields/meanings for
each customer. With an additional table
could be controlled per combination of
sold-to party and partner description,
which fields are displayed in the
transactions JIT1/JIT2/JIT3.
© SAP SE or an SAP affiliate company. All rights reserved.
12
NISSAN/CAMI: Master data
Maintenance of the JIT-customer:
In the field “Usage” is filled with the corresponding model year.
© SAP SE or an SAP affiliate company. All rights reserved.
13
NISSAN/CAMI: Display of the JIT calls
The processed JIT calls look in the following way:
The JIT-customer is determined depending on the usage in the JIT call.
© SAP SE or an SAP affiliate company. All rights reserved.
14
HONDA: Requirements
Customer logic:
 HONDA transmits “RAN”-Orders to the suppliers, which is processing them
as Summarized JIT-calls.
 Generally, the ordered quantities are chosen in the following way, that only
complete packing units could be created.
 It’s possible, that ordered quantities are not enough to result in a full
container. As soon as this situation occurs, HONDA transmits a “Batch”number that defines, which materials are to be bundled together. A sequence
number determines, in which order the material need to be packed.
Additionally, a “Small-Lot”-number (as another sort criterion) is transmitted.
This “Small-Lot”-number has to be printed on the labels.
© SAP SE or an SAP affiliate company. All rights reserved.
15
HONDA: Display of the JIT-call in the system
Quantity matches with two full
containers, no „Batch“,
„Small-Lot“ or Sequence-No.
Total of materials in the mixed
container matches with a full
container
© SAP SE or an SAP affiliate company. All rights reserved.
The RANnumber is on
item level
„Batch“, „Small-Lot“ and Sequence-No.
are sorting and arrangement criteria for
mixed containers
16
HONDA: Creation of outbound delivery
For each RAN-number, an outbound delivery is created.
Es existiert die gleiche Auslieferungsnummer für alle Positionen.
© SAP SE or an SAP affiliate company. All rights reserved.
17
HONDA: Packing of the HONDA-Batch:
Access
The packing order is graphically prepared for the end user at the packing station.
The access is the outbound delivery number:
© SAP SE or an SAP affiliate company. All rights reserved.
18
HONDA: Packing of the HONDA-Batch:
Packing instruction
The packing instruction shows, how the employee has to pack, standing in front of
the pallet/wire basket.
The packing order is:
1. In front starting with sequence 000001,
one place corresponds with quantity 1
2. To the right
3. To the back
4. To the right, whereas the new
sequence starts with 000002, as soon
as the quantity for sequence 000001 is
consumed.
5. …
© SAP SE or an SAP affiliate company. All rights reserved.
3
4
1
2
19
MITSUBISHI: Requirements
Customer logic:
The customer transmits in the RAN-orders only the requirement date. Based on
this date, the JIT standard processing could determine a planned shipping date.
The pick up of the order is an via a carrier. Additionally to the requirement date of
the customer, the carrier transmits a planned shipping date as well. As the rest of
the transmitted data corresponds to original data from the customer as well, that
means the requirement date is filled again, the JIT standard processing would
ignore the planned shipping date in the IDoc and run the scheduling, which would
overwrite the planned shipping date of the IDoc.
© SAP SE or an SAP affiliate company. All rights reserved.
20
MITSUBISHI: New JIT scheduling
At the processing of a JIT call, the calculation of the planned shipping date only
should take place, as soon as the corresponding field in inbound message is
empty. When it is filled, the planned shipping date should be taken from the IDoc
and not be calculated again.
To be able to match this requirement, the transit time could be set up in an
additional table. This table is the basis for the new logic of the scheduling for JITcalls with respect to the calculation of the planned shipping date.
© SAP SE or an SAP affiliate company. All rights reserved.
21
Cross customer: JITH-additional fields – Requirements
Customer logic:
As soon as the customer, which is supplied via Summarized JIT-calls, tranmits
additional field (e.g. Material Issuer), those information should not be lost, when
JIT delivery schedule are created via transaction JITH for the JIT requirements.
That means, at the creation of the JIT delivery schedule, the addional information
has to be transferred to the JIT delivery schedule IDoc.
© SAP SE or an SAP affiliate company. All rights reserved.
22
Cross customer: JITH-addional fields – Incoming JIT-IDoc
Customer transmits in
additional fields in the
JIT-call:
© SAP SE or an SAP affiliate company. All rights reserved.
23
Cross customer: JITH-additional fields – created JITdelivery schedule from JITH
The additional data is transferred to the IDoc of the JIT delivery schedule so that
the table for the additional data is filled via the JIT delivery schedule.
© SAP SE or an SAP affiliate company. All rights reserved.
24
Further customer specific functions I
CHRYSLER „CLAUSE 092“
The deliveries to the customer are generally packed into returnable packing
materials (returnables). If there are not enough returnables, the supplier could
use non-returnables as well. For this case, the supplier could invoice a surcharge
for the non-returnables. In the invoice, the quantities have to be shown separately.
CHRYSLER/POLARIS „Blanket Orders“
Commercial changes of contracts, like e.g. changes of prices, new order
numbers, … are transmitted from the customer with so called “Blanket Orders”.
They are sent in the form of an order (ANSI-code 850) and don’t contain
quantities, which are to be delivered. Consequently, they should not be processed
as an standard order in the SAP ERP system. Instead, the “contract information”
is processed with a separate function, which sends a message (e.g. E-Mail or
System-Mail) to one or several customers to inform about the content of the
message.
© SAP SE or an SAP affiliate company. All rights reserved.
25
Further customer specific functions II
HONDA IPP-indicator (Initial Parts Production)
As soon as a material is shipped to the customer for the first time, IPP (Initial
Parts Production)- information need to be sent to out with the paching units
(Handling Units). The IPP-information is maintained for each handling unit and
transferred to the outbound-IDoc of the ASN.
HONDA „Cage Orders“
Problems in the production at HONDA could lead to a change of the (customer)
material number. For those materials as well as for samples, HONDA is
transmitting so called “Cage Orders”. In other words, orders, which are processed
in the SAP ERP with Summarized JIT-calls. Partly, there are no requirements for
those materials in the system. That means, with the transaction for release
creation (see SAP ACS “Release creation for SD scheduling agreements” as well)
or with transaction JITH, forecast- and JIT delivery schedules could be created.
As soon as requirements exist, the standard HONDA shipping process with
Summarized JIT calls could be followed.
© SAP SE or an SAP affiliate company. All rights reserved.
26
Agenda
1. Benefit for the Customer
2. Description of the Function
3. The Function in the System
4. Technical Information
© SAP SE or an SAP affiliate company. All rights reserved.
27
Technical Information
Available for SAP ERP ECC 6.0
Activation of automotive industrialized solution in SAP ERP System not
necessary
Technical installation is possible remotely
Modification-free
Delivery in Z-namespace
© SAP SE or an SAP affiliate company. All rights reserved.
28
Source of Information
Internet
Overview-, Detail- and Customer presentations

http://www.sap.com/acs
Email - distribution list
Signing up through mario.rebitzer@sap.com
OSS-System
Notes (Search term: Automotive Consulting Solutions)
© SAP SE or an SAP affiliate company. All rights reserved.
29
Thank you!
Mario Rebitzer
Platinum Consultant
Industry Area Automotive
SAP Deutschland SE & Co. KG
Hasso-Plattner-Ring 7
69190 Walldorf, Germany
M +49/ 170 22 00 287
S +49/ 6227 7 44674
E mario.rebitzer@sap.com
© SAP SE or an SAP affiliate company.
All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an
SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE
(or an SAP affiliate company) in Germany and other countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional
trademark information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind,
and SAP SE or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or
SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and
services, if any. Nothing herein should be construed as constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related
presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated
companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be
changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment,
promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties
that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking
statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.
© SAP SE or an SAP affiliate company. All rights reserved.
31