You are on page 1of 20

Multi-Client : Follow-up

Project name LISSY Spare Parts – Supply Chain Execution Layer at DB Schenker

Customer DB Schenker
A-Strasse 100
D-43000 Essen
Germany

th
Date May 20 , 2011

Contact Person Jens Kappauf, SAP AG


-

SAP AG
Walldorf, Germany
Contents
1 Approaches to Multi-Client operations 4
1.1.1 Assumptions & Considerations 5
1.2 Architecture and Core Operations 6
1.2.1 Execution Platform 6
1.2.2 Interfaces 7
1.2.2.1 Example: OEM-Communication 8
1.2.2.2 Example: Backend-Communication: 11
1.3 Organizational Setup 12
1.4 Client specific object-IDs 14
1.4.1 Material Numbers 14
1.4.1.1 De-central mapping in EAI 15
1.4.1.2 Central mapping in SCEL 15
1.4.1.3 Recommendation 17
1.4.2 Customers / Vendors 19
1.4.3 Document-IDs 19
1.4.4 Handling Units 20
1.5 Stock ownership 20

SAP AG
Walldorf, Germany
Dear Vendor, (SAP)

Many thanks for your work so far. After carefully checking your documents by our experts we have
to do three more things to get to a proper decision basis:
1. Adjust the scope
2. Shape the commercial model
3. Re-Check the scope from a risk perspective

Finally we would kindly ask you to adjust your proposal as well as the required documents (BRS,
SRS) to cover the following items.

Task:

Please explain what functions or technical set-up are supporting the usage of your software in a
multi-client scenario and how you handle multiple external number ranges, master data, stock
ownerships etc.

SAP AG
Walldorf, Germany
1 Approaches to Multi-Client operations
Task:

Please explain what functions or technical set-up are supporting the usage of your software in a
multi-client scenario and how you handle multiple external number ranges, master data, stock
ownerships etc.

Preface:

SAP ERP can be used as a supply chain execution layer (SCEL) making use of SAP
standard functionality to implement multi-client specific processes as needed by LSPs.

As a response to the tender documents and to provide answers - this document outlines
different solution approaches and highlights recommendations. However, we’d like to
stress that a final design and implementation recommendation requires further analysis.

In order to provide an introduction – and to make use of the limited time-frame to provide a
meaningful answer. We’d first like to introduce SAP’s current understanding and definition of multi-
client LSP operations.

Multi-client operations - in the context of outsourced logistic services – typically include all features
to run and operate outsourced supply-chains:

 Managing multiple warehouses, inventories, OEMs and their distribution channels - with and
without financial ownership of stock.
 Operating Warehouses which are used to store and process products from one or more
customers - with customer specific put-away and retrieval strategies are used in one single
warehouse.
 Storing customer products in specific sections or mixed storage areas.
 Providing and bill value added services.
 Allowing customers to track and trace stock movements providing accurate statuses.

Therefore, in order to outline SAP’s multi-client capabilities and approaches we’d like to split the
generic term “Multi-Client” into the following areas:

Multi Client Operations On-Boarding & Customer Integration


 Client specific object ID’s  On-board and operate client specific
 Materials warehouse infrastructure and services while
 Vendors and Customers also setting up client specific mapping
 Document IDs requirements for system communication
 Handling Units and message orchestration. (Interfaces)
 Stock ownership  Platform and Template Management for an
integrated and continuous improvement of
 Multiple industries in one single the platform with every new warehouse and
warehouse. client. (Re-usability)
 Customer specific operations, processes  Single/Multiple warehouses for different
and put-away & retrieval strategies clients.
 LSP-Backend System integration and
message choreography

Remark:
SAP AG
Walldorf, Germany
In this document, according to the task specified above, we’d like to focus at

 Client specific Object-IDs


 Stock ownership

but would also like to briefly introduce the underlying architecture concept.

Our recommendations are based on the tender documents. Solution approaches have not taken
into consideration a detailed process, as-is as well as to-be analysis. The outlined approach, i.e.
the level of detail is also limited by the available time to create this document.

1.1.1 Assumptions & Considerations

As mentioned at the beginning - warehouse operations and transportation, as well as tracking and
tracing using SAP event management, is not in scope for this document.

This document is primarily focused on managing multiple processes and inventories for different
OEMs. In this context OEM specific object ID's are relevant to distinguish different, potentially
equal, product ID's in one single system avoiding re-labeling and without applying existing BADI
functionalities to enhance and change the material number by adding a pre- or suffix. Furthermore,
apart from materials this also applies for other master data like customers and vendors. In order to
be able to reference to the right customer documents and to make sure that the right statuses will
be reported back to the customer system - the original customer document ID has to be kept as
well. We assume that the following approach to model multi-client specific objects meets the
business requirements.

SAP offers an entire Solution Portfolio with different products to support contract logistics core
operations. This document is primarily focusing on SAP ERP to represent the intended SCEL
(Supply Chain Execution Layer) as proposed by the tender documents. SAP Warehouse
Management as well as SAP Transportation Management Solutions will not be in scope for this
document.

Using SAP ERP as an integration and execution platform represents a configurable framework
based on flexible org.-models where customers can be represented as plants, making use of
existing supply chain execution functionality. This approach, together with proven customizing and
process modeling capabilities will enable a rapid addition, enhancement and deployments of new
services, and on-boarding of new customers. Client on-boarding will be described in a separate
document. This document is about multi-client - mainly about answering the following questions in
the area of client-specific object-IDs:

 Explaining the solution approaches SAP software offers to model individual customer-LSP-
relationships – as described in paragraph:
o Architecture and Core Operations
 In this context: Explaining how customer specific master data is supported by SAP and how
customer stock characteristics can be implemented making use of SAP Inventory
Management. This will be covered in the following paragraphs:
o Client Specific Object-IDs
o Stock Ownership

SAP AG
Walldorf, Germany
1.2 Architecture and Core Operations

In order to outline SCEL core functionalities in the context of handling multiple customers – we
assume the following underlying architecture:

Hereby, while answering the proposal document, we’ll make the following assumptions – which
have already been specified in the previous project proposal delivered end of May:

 The described functionality, process flow and interfaces will focus on SCEL (Supply Chain
execution layer). We assume that SCEL represents a SAP ERP.
 In this context we’ll describe standard supply-chain and logistics execution functionality and
processes – being part of SAP ERP assuming that the LSP will handle, and is responsible
for non-valuated stock.
 Financial processes, valuation topics and billing in behalf of the OEM are not in scope.
 Warehouse Management (WMS) are not in scope and will be connected as external
systems.
 Final interface decision (e.g. for outbound please see project proposal) – will be based on
non-SAP Backend-System capabilities and final scope being documented during
blueprinting.
 For this document we assume that SAP ERP will make use of existing standard interfaces,
while data and parameters are correctly mapped in an existing EAI-tool.
 The tool itself, as well as mapping effort is not considered in this document – as well as any
data migration effort for master- and transactional data. Migration effort in the context of on-
boarding as well as the underlying technical approach should be described in the “On-
Boarding-Concept”

1.2.1 Execution Platform

Each customer has an ERP system of its own – SAP or non-SAP. When products are physically
sent to the warehouse – e.g. as a consequence of RMA-processing, replenishment or
SAP AG
Walldorf, Germany
procurement, electronic messages are sent to the LSP ERP to announce the delivery of materials.
When goods, or are are sold, or supposed to be physically moved or distributed out of the
warehouse, typically an EDI message is sent to the LSP with all the necessary data. For supply
chain execution we recommend to make use of SAP ERP as a central distribution and integration
platform not only being integrated to OEM backend-systems but also to connect to the LSPs’ WMS
as well as TMS systems.

 Inbound communication mainly includes – inbound notifications such as replicated


purchase order or ASNs, outbound requests such as replicated sales orders or outbound
deliveries – but also messages being received from connected backend systems – e.g.
stock movement confirmations etc ...
 Outbound communication is mainly providing updates to the connected customer systems.
These messages typically include stock movements and inventory adjustments for both,
quantity and status.

1.2.2 Interfaces

We assume that SCEL communication will be based on EDI while SCEL will be connected to an
existing EAI-tool. Hereby, Outbound delivery distribution to connected back-end systems (WMS or
TMS) will make use of existing interfaces for delivery replication and distribution e.g. making use of
the following message types: DESADV, TPSLOC or using LE-IDW standard interfaces for de-
central WMS-communication, e.g. OBDLV_SAVE_REPLICA or IBDLV_SAVE_REPLICA. In this
context we’d like to stress that outbound notifications may not only include replicated outbound
deliveries but also replicated sales orders (e.g. using message type ORDERS) – For outbound
communication we therefore distinguish between the following scenarios:

 Execution Only: SCEL will receive replicated outbound deliveries e.g. as DESADV (see
above). There is no sales order replication upfront.
 Order replication: SCEL will receive a sales document (ORDERS) and will create the
follow-up delivery document. Sales order replication allows the LSP to combine orders and
SAP AG
Walldorf, Germany
to optimize distribution and is a pre-requisite for enhanced operations making use of
standard SAP ERP functionality e.g. such as ATP-checks (also gATP via APO), backorder
processing and pricing etc.

The image below shows existing message types four outbound operations to connect SCEL to
legacy, non-SAP TMS or WMS systems. The level of integration as well as the recommended
interfaces and messages are not subject of this document.

Inbound processing can also be based on EDI communication. For SCEL that means that OEM’s
either replicate purchase orders (ORDERS) or inbound deliveries. By default inbound delivery
replication tries to create a preceding purchase order based on existing procurement relationships
– e.g. purchase info records. In order to avoid PO-creation SCEL can be configured to allow
inbound deliveries for execution without having a purchase order. Alternatively inbound deliveries
can be created making use of IBDLV_SAVE_REPLICA. In this case, connecting SCEL as a de-
central execution system, there is no need for a purchase order.

1.2.2.1 Example: OEM-Communication

This simple example shows an ERP system acting as a supply chain execution system. The OEMs
(LSD1 and LSD2) are represented as plants with corresponding plant business partners. For these
partners – type KU (Customer), WE20 partner profiles have been maintained for EDI inbound
communication. In this case ORDERS, PORDCR1 (for a VMI scenario), as well as “execution only”
– IBDLV- and OBDLV messages have been maintained. Outbound communication to the OEM has
been via NAST.

SAP AG
Walldorf, Germany
By default ORDERS is enough to replicate both, sales orders as well as service orders. In this
example PORDCR1 has been used to trigger a VMI process in the LSP-ERP. PORDCR1 inbound
processing was assigned to a SAP Workflow Work-Item to trigger
VMI_PO_CREATE_FROM_ORDRSP_VMI. Typically LSP-stocks are non-valuated stocks (please
also refer to paragraph “Stock Ownership”). By default a procurement process for non-valuated
stock requires an accounting key for cost ventilation. Standard segment structure of PORDCR1
does not include an accounting key. Therefore BADI implementation for definition
ME_BAPI_PO_CUST has been used – and interface IF_EX_ME_BAPI_PO_CREATE_02 mapped
an accounting key “Z”. ORDERS comes with an accounting key.

Data replication to OEM for stock adjustment:

OEM stock adjustment, i.e. updating the OEM back-end system can be done in different ways. If
the OEM is operating a SAP system it is possible to set-up a direct system communication via EDI.
In all cases EAI needs to map the SCEL outbound information into the corresponding OEM-format.
SAP AG
Walldorf, Germany
We’d like to briefly outline two different solution approaches to forward stock movements to the de-
central OEM system:

 Adjustment of the distribution status of the delivery – to finally re-distribute an already


confirmed delivery document to the external OEM.
 NAST processing to trigger MBGMCR (recommended)

The first solution approach is possible, however we do not recommend it – because it requires a
modification in SCEL. Once the CONFIRM_DECENTRAL message has been received from the
de-central WMS, SCEL will call BAPI SHP_BAPI_DELIVERY_CONFIRM_DEC. Here, the following
modification can be applied to change the distribution status LIKP-VLSTK of the affected delivery
and force the system to “re-distribute and already distributed document”.

DATA: ls_yvbuk LIKE vbukvb,


lf_dlv_change TYPE xfeld,
lt_lipsf TYPE TABLE OF LIPSVB.
lf_dlv_change = is_v50agl-dlv_change.
IF NOT is_v50agl-dlv_change IS INITIAL AND
NOT is_v50agl-dlv_change_off IS INITIAL.
CLEAR lf_dlv_change.
ENDIF.
*{ REPLACE R60K900051 1
*\ LOOP AT it_likp WHERE vlstk CA 'AEF'.
* MODIFICATION
DATA: lv_mod_conf_dec(20).
GET PARAMETER ID 'ZOEM_MOD_CONF' FIELD lv_oemconf.
LOOP AT it_likp WHERE vlstk CA 'AEF'
OR
verursys = 'SYSTEM001'
OR
verursys = 'SYSTEM001'.

IF lv_oemconf IS INITIAL AND


IT_LIKP-VLSTK = 'C'.
CONTINUE.
ENDIF.
*} REPLACE
READ TABLE it_yvbuk WITH KEY vbeln = it_likp-vbeln
INTO ls_yvbuk.
PERFORM initialize_confirmation.

Alternatively – and this is recommended – SCEL can trigger NAST to send a MBGMCR once the
delivery document has been updated by a CONFIRM_DECENTRAL. This approach is SAP
standard and just requires a simple function module to compose the EDI-outbound message – in
this case e.g. a function module called ZOEM_OUTPUT_MBGMCR. Alternatively this can also be
done sending a DELINF. However, MBGMCR provides more flexibility. Explaining the core concept
and architectural approach we will also not focus at vendor communication e.g. WHSORD and
stick to the multi-client mapping requirements. EDI configuration will be explained in detail in the
Blueprint document – once the final scope and solution approach for SCEL has been fixed.

Message replication:

To execute the message replication – the OEM partner profile will for outbound-communication will
contain message MBGMCR (see screenshot of partner profiles below) for application ME and a
new Z-message type and a new Z-process code, e.g. ZMDC (i.e. Material Doc. Create). The
processing routine for ZMDC and application ME will be set to EDI-processing, and access
sequence 0003 will be chosen to finally maintain condition records for the following field
combination: Application (ME) + KSCHL (ZMDC) + VGART (WE or WA). In order to be able to
send the message output determination profile for inventory management ME0001 will be updated

SAP AG
Walldorf, Germany
with condition ZMDC, and process code ZMDC will receive a new Z-function module
(ZOEM_OUTPUT_MBGMCR) to create the IDOC.

FUNCTION ZOEM_OUTPUT_MBGMCR.
*"----------------------------------------------------------------------
*"*"Global Interface:
*" IMPORTING
*" VALUE(OBJECT) LIKE NAST STRUCTURE NAST
*" VALUE(CONTROL_RECORD_IN) LIKE EDIDC STRUCTURE EDIDC
*" EXPORTING
*" VALUE(OBJECT_TYPE) LIKE WFAS1-ASGTP
*" VALUE(CONTROL_RECORD_OUT) LIKE EDIDC STRUCTURE EDIDC
*" TABLES
*" INT_EDIDD STRUCTURE EDIDD
*" EXCEPTIONS
*" ERROR_MESSAGE_RECEIVED
*" DATA_NOT_RELEVANT_FOR_SENDING
*"----------------------------------------------------------------------
CLEAR control_record_out.
MOVE control_record_in TO control_record_out.
control_record_out-direct = '1'.
control_record_out-serial = sy-datum.
control_record_out-serial+8 = sy-uzeit.
REFRESH i_gm_itcr.
Refresh i_gm_item.
perform read_matdoc using object.
* Adjust movement types – or map backend parameters.
read table i_gm_itcr with key move_type = 521.
if sy-subrc = 0.
if gv_alreadysentflag = 'X'.
delete i_gm_itcr where move_type = 521.
else.
delete i_gm_itcr where move_type = 601.
endif.
endif.
if gv_alreadysentflag = ' '.
perform create_data
tables i_gm_itcr
int_edidd
using i_gm_head
object.
gv_alreadysentflag = 'X'.
endif.

1.2.2.2 Example: Backend-Communication:

Backend communication involves WMS and TMS integration. In this example the execution layer
will distribute deliveries via LE-IDW i.e. IBDLV and OBDLV. Inbound communication (e.g. from
WMS to ERP) is based on CONFIRM_DECENTRAL and SPLIT_DECENTRAL if the ERP delivery
has been split in the WMS. In this example we have used MBGMCR to adjust ERP-Inventory
Management e.g. in case of scrapping etc …

SAP AG
Walldorf, Germany
Remark:

We would also like to mention, that esp. while no SAP WMS is involved, inbound configuration can
also be based on SD-documents using adjusted movements types to finally post goods receipt.
Similar to existing return-order based scenarios this approach allows using customer-material info
records for mapping purposes to be used for both; outbound as well as inbound processing. We’ll
follow-up on this approach in the context of client specific object-IDs when it comes to integrate
customer material-IDs. Although this is one of SAP Best Practice Scenarios, we do not recommend
this approach for LISSY.

1.3 Organizational Setup

In order to support multi-client supply chain operations, the OEM can be represented in different
ways. The preferred approach is dependent on:

 The number of OEMs in one single system


 The type of business, e.g. if pricing, billing and dunning is also among the outsourced
services.
 The Industry, in case business operations requires industry specific setup and client-wide
configuration – e.g. making use of SAP-IS.

These business imperatives finally determine how OEMs are represented in SCEL.

SAP AG
Walldorf, Germany
This document describes solution approaches making use of SAP standard. We therefore exclude
alternative solutions being based on system modifications are high development efforts. In the
context of near- or standard solutions, SAP offers the following approaches:

 Each OEM will have its own (system)-client in SCEL. This option only makes sense if the
contract relationship and / or the complexity of outsourced operations justify this approach.
Complexity may be influenced by:
o Financial accounting – where the LSP takes over financial operations
o Long term contract relationships or integration scenarios which need a specific
client to run the business – e.g. IS-Retail.
o Technical integration which is tailor made for a particular OEM, e.g.to allow the LSP
to service as a 4PL.
 Multiple OEMs are represented in one single client. We hereby distinguish between the
following options.
o The OEM can be represented as a plant, with his own sales areas, and purchase
organization, while each plant represents a physical warehouse location. Storage
locations can be used to model “Received on dock” and “Available for sales”; and
are – together with an ERP warehouse number – mapped against the external, non-
SAP warehouse (see image above)
o The OEM (and also his stock) can be treated as consignment stock (please also
refer to the paragraph “Stock ownership”). In this context the OEM is represented as
a vendor with special stock for a particular plant, while the storage locations can be
used to represent different warehouse locations of the OEM.

OEMs being represented as plants will usually not justify a specific company code for each OEM.
However, e.g. in case of order replication and outsourced billing and cash collection (which is out
of scope for LISSY) – an OEM specific company code can be implemented as well. In this case
each OEM is differentiated by company code. Each OEM has a company code e.g. by country,
e.g. one or more sales organizations and usually one purchasing organization. The differentiation
SAP AG
Walldorf, Germany
starts at plant and storage location level – while a combination of plant + storage location defines
the warehouse number (WM-warehouse number in ERP) – which can be linked for execution to a
de-central WMS.

Remark:

The way OEMs are modeled in SCEL also influences the solution approach for client specific
object-IDs. For the solution approach for client specific object-IDs we anticipate that the OEM is
represented as a plant. Based on our understanding of the tender documents – we do not see the
need of multiple company codes so far.

1.4 Client specific object-IDs

In order to guarantee OEM-specific non duplicate material numbers in one single system client of
ERP, SAP offers different approaches. These approaches are also dependent on how the OEM is
represented in SCEL.

Remark:

We anticipate that the OEM is modeled as a plant – while multiple plants (OEMs) will share one
single company code. SCEL will use one single client to model the OEM and is the leading system
for master data replication.

SCEL has to deal with client- i.e. OEM-specific object-IDs while also avoiding duplicates. For
master data replication, we therefore anticipate that the connected non-SAP backend-systems
receive distributed master data from SCEL. Once connected to the customer system(s), after
technical on-boarding OEM master data, and applying OEM specific configuration, SCEL will be
the leading system for master data distribution e.g. making use of MATMAS, DEBMAS, CLFMAS
etc ... messages to share the data with WMS, TMS, etc.

Therefore, we assume that the non-SAP backend-Systems are also multi-client capable and
support the outlined solution approach for client specific object-IDs.

The client specific object-IDs include:

 Material Numbers
 Vendors and Customers
 Document IDs
 Handling Units

1.4.1 Material Numbers

There are different ways in SCEL to deal with OEM specific number ranges. We’d first like to
highlight the basic concepts and solution approaches. We can distinguish between internal- and
external number ranges. The following approaches are based on the assumption that re-labeling is
NOT a general option for SCEL and has to be avoided. Hereby SAP supports internal as well as
external number ranges. For SCEL that means:

 External number ranges anticipate that SCEL can make use of the original OEM material
number. In this case duplicates have to be identified and prevented during on-boarding.
Exceptions (duplicates) can receive a new unique (external) material number – while EAI will
take care about mapping – or, it will be re-labeled and receives a new, unique internal number.
 Internal number ranges for several OEMs in one single system-client, will not cause duplicates
but require mapping. This mapping can be done centrally in SCEL or de-central in the EAI tool.
SAP AG
Walldorf, Germany
1.4.1.1 De-central mapping in EAI

A de-central mapping already happens in the EAI-tool. SCEL will be provided with mapped data
and no further mapping will be executed. For output generation or material-ID look up in
operations, de-central mapping comes with a number of restriction or at least requires remote
access from SCEL when it comes to read the mapping tables in EAI. Mapping execution (see
comments below) can than e.g. use 'RFC_READ_TABLE' to access and read the external
information. We do not want to exclude de-central mapping as an option for SCEL, but assume
that a final solution will be based on central mapping.

1.4.1.2 Central mapping in SCEL

Central mapping can use internal as well as external number ranges. We assume that SCEL will
use internal material numbers for execution and the OEM will send his external numbers. Central
mapping means, that the external number will be mapped against the internal number.

Regarding central mapping we have to consider two aspects:

 Where does the mapping itself take place?


 And where is the mapping rule (material ID) stored?

Storing the mapping information:

We assume, in order to avoid duplicates, SCEL is working with internal number ranges. However,
we would also like to mention that the OEM can also be stored as a prefix:

 Storing the OEM ownership information as a prefix of the material number without storing
mapping information. In this case an external number range is used while the owner (OEM) is
concatenated to the original, external material number. Concatenation either takes place in
EAI, or during on-boarding in SCEL reading MATMAS information, using a user exit, before the
master data will be saved. This approach is the most pragmatic approach for SCEL but will
require re-labeling in the WMS backend systems.

Number ranges are linked to the material type. It is also possible to have OEM specific material
types and number ranges – while the external information – the external OEM material number -
can be stored as follows:

 External OEM material-ID in Z-table (mapping table) in SCEL


 External OEM material-ID in standard table M_MAT1A as BISMT
 External OEM material-ID in material master as customer material number (KDMAT) while
using the internal material numbers with OEM material number as KDMAT or IDNLF in logistic
documents:

SAP AG
Walldorf, Germany
 External OEM material-ID as classification information in class type 001 (Material class).
Classification and the use of super-classes is a convenient way to store OEM specific
information – not only the external material-ID. Classification can also be distributed and
received via CLFMAS and CLSMAS and is flexible to maintain.
 External OEM material-ID as additional field in MARC (assuming that the OEM will be modeled
as a plant)
 External OEM material-ID as additional EAN in table MEAN. The multiple EANs are not plant
specific. If the OEM is modeled as a plant (and this is our assumption) the EAN-Category, with
an assigned external number range, might represent the customer code (or plant business
partner ID – of the plant representing the OEM) which is used as the plant code.
 External OEM material-ID is stored in customer material info-record. Material info-records are a
suitable way to store mapping information and to automatically substitute external material
numbers determining the internal ID. This will only work in sales documents and requires a
sold-to party which represents the plant business partner of the OEM, while the ship-to party
represents the receiver of the goods. By default, this will of course not work in purchasing
documents. There is a similar functionality which can be used in procurement which is based
on purchase info-records. In this case the However, it does not make sense and is redundant
to maintain the settings, and to use the customer or vendor of the plant OEM to determine the
material. If customer material info-records should be used, it is possible – if process
requirements allow this - using SD-documents for inbound operations as well. Similar to return
order functionalities using outbound deliveries for inbound processing. However, in this case
procurement functionalities such as third-party order processing, and purchase order creation
can’t use this mapping approach. However, this is needed for LISSY. Although it is not
recommended for SCEL we’d like to mention this because customer material info-records are
sufficient for an execution only scenario as mentioned above. It is furthermore a SAP best
practice approach. (See SAP Best practices).

Mapping execution

Regarding the actual mapping we need to distinguish between process integration via interfaces,
and operational functions where the SCEL-users need to identify the external ID for printing,
reporting or external communication purposes. Central mapping can be done in different ways:

 Inbound and outbound EDI interfaces will re-map the material number while they receive the
data from the external system, e.g. for replicated ORDERS in IDOC_INPUT_ORDERS,
SAP AG
Walldorf, Germany
enhancement in customer function “001” – function exit EXIT_SAPLVEDA_001, with include
ZXVEDU03. The originally transmitted material number will be mapped against the internal
material ID while the original, external ID can be stored as KDMAT. E.g.
OBDLV_SAVE_REPLICA:

 Mapping sources include all described approaches to store the mapping information excluding
customer material info-records or using prefixes. In these cases no mapping will be needed. In
all other cases the material number will be retrieved as follows:
o Z-Table, MEAN or MARC: Table operations to read data from data source
o Reading classification making e.g. making use of BAPIs to select the objects by class
type und number (BAPI_CLASS_SELECT_OBJECTS) and then
BAPI_OBJCL_SPLITKEY to carve out the needed information.
 In order to be able to e.g. select documents (order, deliveries, etc.) or to execute reports
searching for the external material number. The existing conversion routines can be enhanced,
or existing search helps can be adjusted. This is not necessary, if classification or old-material
number (table M_MAT1A) will be used to store the external attributes! In these cases SAP
standard already offers search capabilities and no enhancements are necessary.

1.4.1.3 Recommendation

After having outlined the generic functionality SAP ERP offers to meet multi-client requirements in
the area of material master – we would like to recommend the following approach based on the
existing tender documents:

 Material classification – Class-Type 001 (Material class) with OEM specific fields.
 Interface adjustment to map document data.

SAP AG
Walldorf, Germany
We recommend using class type 001 to classify material numbers. OEM specific parameters like
external material-ID will be stored as characteristics while SCEL will work with unique, internal
material numbers only. External OEM-communication is based on external-IDs. SCEL will
internally map required parameters while processing in- and outbound communication to the OEM.
This mainly includes the following interfaces:

 IDOC_INPUT_ORDERS with function exit e.g. EXIT_SAPLVEDA_001


 BAPI_IDOC_INPUT1 finally calls functions (BTE’s) to create the corresponding sales,
procurement, or delivery documents. In order to apply individual changes and to manipulate
segment data – we recommend to copy the original FM and create a customer Z-FM.
Where the following coding (example only) – can be applied to determine the internal
material number.

In order to determine the internal material number BAPI BAPI_CLASS_SELECT_OBJECTS can


be used (example only) – and called while processing in- and outbound communication. Here, the
local table lt_selcrit contains the external material-ID from the OEM (here: LSD1MAT1) can e.g. be
stored as a characteristic value (here: ZOEM001-01) e.g. for class ZOEM001. The return table
result can be used to map the material number against the internal-ID and store the external-ID
either as KDMAT or IDNLF.

* Select Objects
CALL FUNCTION 'BAPI_CLASS_SELECT_OBJECTS'
EXPORTING
classtype = ‘001’
classnum = ‘ZOEM001’
* LANGUISO =
* LANGUINT =
* KEYDATE = SY-DATUM
* MAXHITS = 100
i_status_locked = gc_yes
i_status_incomplete = gc_yes
IMPORTING
return = ls_ret1
TABLES
selectioncriterions = lt_selcrit
selectedobjects = lt_selobj.
* OBJECTCLASSIFICATION =
IF NOT ls_ret1 IS INITIAL.
CALL FUNCTION 'BALW_RET1_TO_RET2'
EXPORTING

SAP AG
Walldorf, Germany
return_in = ls_ret1
IMPORTING
return_ou = ls_return.
APPEND ls_return TO ext_return.
ENDIF.
*
* Get Objects

1.4.2 Customers / Vendors

If OEM customers and vendors should be migrated as master data, and if esp. for outbound
processing CPD-Address information is not sufficient, customer and vendor data can be
maintained using internal or external number ranges.

 External-IDs: In case of external number ranges (i.e. the OEM master data will be uploaded
during on-boarding) there is a high chance of importing duplicates. Especially if the OEMs are
running SAP systems themselves. Possible solution approaches for external numbering
include using a prefix to distinguish between the different OEM customers / vendors. However,
we recommend making use of internal-IDs especially if one customer has relationships to
multiple OEMs, e.g. an external carrier, which is used by different OEMs.

 Internal-IDs: In case the external-IDs can’t be used in SCEL, we assume that the data is
already mapped in the EAI and SCEL will e.g. use internal numbers with classified vendor and
customer master data (class type 010 and 011), to store the external ID. Alternatively the
customer / vendor master can be enhanced with additional fields or – e.g. if the vendor /
customer data is exclusively used for printing and documentation, the external OEM-key can
be stored in the master data making use of existing fields. In that case SAP offers several
options, e.g. using partner functions and their descriptions, or contact person information to
store the external attributes.

The recommended approach is quite similar to material numbers. We recommend to use internal
ID’s and either do the mapping in EAI, or during document entry. In most cases it is sufficient to
store the external ID as a reference making use of existing fields as mentioned above.

1.4.3 Document-IDs

SAP already offers the possibility to store external document references on document level.
External document ID’s can be stored for reference purposes making use of existing standard
fields for external identification only to mention XBLNR or EXTDELV_NO. For the execution only
scenario SCEL will receive replicated delivery documents via IBDLV- or OBDLV_SAVE_REPLICA.
In these cases where SCEL will be treated like an external LES system – the document number
will be replicated as well. In a multi-client environment this may cause duplicates in SCEL. In order
to avoid duplicates and generate an internal number user exit EXIT_SAPLV50S_001 can be used
– changing parameter CF_FLAG_DOCNUM_NEW:

SAP AG
Walldorf, Germany
As soon as the document will be created, the external-ID can be stored as a reference, while the
parameter CF_FLAG_DOCNUM_NEW will cause the system to pick the next free number from the
document number range. Alternatively – using external number ranges – SCEL can concatenate a
new external number adding a prefix to the original external-ID.

1.4.4 Handling Units

The outbound delivery serves as a basis for the required shipments (preliminary, main,
subsequent). The shipments are planned and executed by the forwarding agents. The handling
units are loaded at the customer departure point and unloaded at the customer ship-to address.

Handling units in a multi-client environment are especially important for inbound processing where
the external handling unit ID will be provided by e.g. vendors or being received from the OEM
system. If the external-ID is anyway not a unique ID, e.g. based on SSCC, SAP can keep the
external HU-ID as a reference and automatically create an SCEL internal HU-ID which is also
updated in the inbound delivery.

1.5 Stock ownership

LSPs usually do not own stocks and therefore usually do not need to valuate third-party stock. SAP
Inventory Management in ERP (ERP-IM) not only offers different ownership concepts, but also
supports different approaches of stock valuation – which can also change during a process.

Example: A kit-to order process (VAS) where the LSP is creating, and selling and billing in behalf-
of the OEM, a valuated product, based on kit-components being stored in OEM-(i.e.-vendor)-
Consignment. In this case the non-valuated consignment stock can be taken to build a valuated kit.
The same applies for processes where LSP’s need to own stock for a “logistic second”.

Non-valuated stock:

Based on the recommendation of how to model the OEM, which organizational elements to use,
we assume that the base scenario regarding SCEL-stock is non valuated stock. Using non-
valuated Stock in SCEL will cause ERP-IM to physically count the stock on plant-(OEM)-level,
without keeping track of valuation. Stock postings will just affect quantities while no accounting
documents will be created.

Stock valuation, together with number range assignments, screen sequence control for master
data attributes and views, is a generic setting which is made on material type-level. Here, we
specify that a material is managed on a quantity basis for the relevant valuation area. For SCEL
that means that the valuation area - the plant level – represents the OEM.

SAP AG
Walldorf, Germany

You might also like