DB Schenker SCEL Multi-Client JK

7/26/2019 DB Schenker SCEL Multi-Client JK

http://slidepdf.com/reader/full/db-schenker-scel-multi-client-jk 1/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

Date May 20th

, 2011

Contact Person Jens Kappauf, SAP AG

-

SAP AGWalldorf, 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




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 amulti-client scenario and how you handle multiple external number ranges, master data, stock

ownerships etc.




1 Approaches to Multi-Client operations

Task:

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

Preface:

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

As a response to the tender documents and to provide answers - this document outlinesdifferent solution approaches and highlights recommendations. However, we’d like tostress 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 ameaningful 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 featuresto run and operate outsourced supply-chains:

Managing multiple warehouses, inventories, OEMs and their distribution channels - with andwithout 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 singlewarehouse.

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 thegeneric term “Multi-Client” into the following areas:

Multi Client Operations On-Boarding & Customer Integration

Client specific object ID’s

Materials Vendors and Customers

Document IDs

Handling Units

Stock ownership

On-board and operate client specific

warehouse infrastructure and services whilealso setting up client specific mappingrequirements for system communicationand message orchestration. (Interfaces)

Platform and Template Management for anintegrated and continuous improvement ofthe platform with every new warehouse andclient. (Re-usability)

Single/Multiple warehouses for differentclients.

LSP-Backend System integration andmessage choreography

Multiple industries in one singlewarehouse.

Customer specific operations, processesand put-away & retrieval strategies

Remark:




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 takeninto 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 andtracing using SAP event management, is not in scope for this document.

This document is primarily focused on managing multiple processes and inventories for differentOEMs. In this context OEM specific object ID's are relevant to distinguish different, potentiallyequal, product ID's in one single system avoiding re-labeling and without applying existing BADIfunctionalities 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 tobe able to reference to the right customer documents and to make sure that the right statuses willbe reported back to the customer system - the original customer document ID has to be kept aswell. We assume that the following approach to model multi-client specific objects meets thebusiness 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 WarehouseManagement as well as SAP Transportation Management Solutions will not be in scope for thisdocument.

Using SAP ERP as an integration and execution platform represents a configurable frameworkbased on flexible org.-models where customers can be represented as plants, making use ofexisting supply chain execution functionality. This approach, together with proven customizing andprocess modeling capabilities will enable a rapid addition, enhancement and deployments of newservices, and on-boarding of new customers. Client on-boarding will be described in a separatedocument. This document is about multi-client - mainly about answering the following questions inthe 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




1.2 Architecture and Core Operations

In order to outline SCEL core functionalities in the context of handling multiple customers – weassume 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 onnon-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 physicallysent to the warehouse – e.g. as a consequence of RMA-processing, replenishment or




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 thewarehouse, typically an EDI message is sent to the LSP with all the necessary data. For supplychain execution we recommend to make use of SAP ERP as a central distribution and integrationplatform not only being integrated to OEM backend-systems but also to connect to the LSPs’ WMSas 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 anexisting EAI-tool. Hereby, Outbound delivery distribution to connected back-end systems (WMS orTMS) will make use of existing interfaces for delivery replication and distribution e.g. making use ofthe 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 thiscontext we’d like to stress that outbound notifications may not only include replicated outbounddeliveries but also replicated sales orders (e.g. using message type ORDERS) – For outboundcommunication 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




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 tolegacy, non-SAP TMS or WMS systems. The level of integration as well as the recommendedinterfaces and messages are not subject of this document.

Inbound processing can also be based on EDI communication. For SCEL that means that OEM’seither replicate purchase orders (ORDERS) or inbound deliveries. By default inbound deliveryreplication 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 allowinbound deliveries for execution without having a purchase order. Alternatively inbound deliveriescan 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 thesepartners – type KU (Customer), WE20 partner profiles have been maintained for EDI inboundcommunication. 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 hasbeen via NAST.




By default ORDERS is enough to replicate both, sales orders as well as service orders. In thisexample PORDCR1 has been used to trigger a VMI process in the LSP-ERP. PORDCR1 inboundprocessing was assigned to a SAP Workflow Work-Item to triggerVMI_PO_CREATE_FROM_ORDRSP_VMI. Typically LSP-stocks are non-valuated stocks (pleasealso refer to paragraph “Stock Ownership”). By default a procurement process for non-valuatedstock requires an accounting key for cost ventilation. Standard segment structure of PORDCR1does 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 mappedan 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. Ifthe 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.




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 amodification in SCEL. Once the CONFIRM_DECENTRAL message has been received from thede-central WMS, SCEL will call BAPI SHP_BAPI_DELIVERY_CONFIRM_DEC. Here, the followingmodification can be applied to change the distribution status LIKP-VLSTK of the affected deliveryand 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'.* MODIFICATIONDATA: lv_mod_conf_dec(20).GET PARAMETER ID 'ZOEM_MOD_CONF' FIELD lv_oemconf.LOOP AT it_likp WHERE vlstk CA 'AEF'

ORverursys = 'SYSTEM001'ORverursys = 'SYSTEM001'.

IF lv_oemconf IS INITIAL ANDIT_LIKP-VLSTK = 'C'.CONTINUE.

ENDIF.*} REPLACE

READ TABLE it_yvbuk WITH KEY vbeln = it_likp-vbelnINTO ls_yvbuk.

PERFORM initialize_confirmation.

Alternatively – and this is recommended – SCEL can trigger NAST to send a MBGMCR once thedelivery document has been updated by a CONFIRM_DECENTRAL. This approach is SAPstandard 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 bedone sending a DELINF. However, MBGMCR provides more flexibility. Explaining the core conceptand architectural approach we will also not focus at vendor communication e.g. WHSORD andstick to the multi-client mapping requirements. EDI configuration will be explained in detail in theBlueprint 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 willcontain message MBGMCR (see screenshot of partner profiles below) for application ME and anew Z-message type and a new Z-process code, e.g. ZMDC (i.e. Material Doc. Create). Theprocessing 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 fieldcombination: Application (ME) + KSCHL (ZMDC) + VGART (WE or WA). In order to be able tosend the message output determination profile for inventory management ME0001 will be updated




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_itcrint_edidd

using i_gm_headobject.

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. fromWMS to ERP) is based on CONFIRM_DECENTRAL and SPLIT_DECENTRAL if the ERP deliveryhas been split in the WMS. In this example we have used MBGMCR to adjust ERP-InventoryManagement e.g. in case of scrapping etc …




Remark:

We would also like to mention, that esp. while no SAP WMS is involved, inbound configuration canalso 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 inforecords for mapping purposes to be used for both; outbound as well as inbound processing. We’llfollow-up on this approach in the context of client specific object-IDs when it comes to integratecustomer 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 differentways. 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.




This document describes solution approaches making use of SAP standard. We therefore excludealternative solutions being based on system modifications are high development efforts. In thecontext 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. Storagelocations 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 caseeach 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




starts at plant and storage location level – while a combination of plant + storage location definesthe warehouse number (WM-warehouse number in ERP) – which can be linked for execution to ade-central WMS.

Remark:

The way OEMs are modeled in SCEL also influences the solution approach for client specificobject-IDs. For the solution approach for client specific object-IDs we anticipate that the OEM isrepresented as a plant. Based on our understanding of the tender documents – we do not see theneed 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 ofERP, SAP offers different approaches. These approaches are also dependent on how the OEM isrepresented in SCEL.

Remark:

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

SCEL has to deal with client- i.e. OEM-specific object-IDs while also avoiding duplicates. Formaster data replication, we therefore anticipate that the connected non-SAP backend-systemsreceive distributed master data from SCEL. Once connected to the customer system(s), aftertechnical on-boarding OEM master data, and applying OEM specific configuration, SCEL will bethe 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 andsupport 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 tohighlight the basic concepts and solution approaches. We can distinguish between internal- andexternal number ranges. The following approaches are based on the assumption that re-labeling isNOT a general option for SCEL and has to be avoided. Hereby SAP supports internal as well asexternal 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.




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 dataand no further mapping will be executed. For output generation or material-ID look up inoperations, de-central mapping comes with a number of restriction or at least requires remoteaccess from SCEL when it comes to read the mapping tables in EAI. Mapping execution (seecomments below) can than e.g. use 'RFC_READ_TABLE' to access and read the externalinformation. We do not want to exclude de-central mapping as an option for SCEL, but assumethat 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 willuse internal material numbers for execution and the OEM will send his external numbers. Centralmapping 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 materialtypes 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:




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 creationcan’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,




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 classtype 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 inthe area of material master – we would like to recommend the following approach based on theexisting tender documents:

Material classification – Class-Type 001 (Material class) with OEM specific f ields.

Interface adjustment to map document data.




We recommend using class type 001 to classify material numbers. OEM specific parameters likeexternal material-ID will be stored as characteristics while SCEL will work with unique, internalmaterial numbers only. External OEM-communication is based on external-IDs. SCEL willinternally 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 canbe used (example only) – and called while processing in- and outbound communication. Here, thelocal table lt_selcrit contains the external material-ID from the OEM (here: LSD1MAT1) can e.g. bestored as a characteristic value (here: ZOEM001-01) e.g. for class ZOEM001. The return tableresult can be used to map the material number against the internal-ID and store the external-IDeither as KDMAT or IDNLF.

* Select ObjectsCALL FUNCTION 'BAPI_CLASS_SELECT_OBJECTS'EXPORTING

classtype = ‘001’ classnum = ‘ZOEM001’

* LANGUISO =* LANGUINT =* KEYDATE = SY-DATUM* MAXHITS = 100

i_status_locked = gc_yesi_status_incomplete = gc_yes

IMPORTINGreturn = ls_ret1

TABLESselectioncriterions = lt_selcritselectedobjects = lt_selobj.

* OBJECTCLASSIFICATION =IF NOT ls_ret1 IS INITIAL.CALL FUNCTION 'BALW_RET1_TO_RET2'

EXPORTING




return_in = ls_ret1IMPORTING

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 outboundprocessing CPD-Address information is not sufficient, customer and vendor data can bemaintained 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 tostore the external attributes.

The recommended approach is quite similar to material numbers. We recommend to use internalID’s and either do the mapping in EAI, or during document entry. In most cases it is sufficient tostore 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 standardfields 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 numberwill be replicated as well. In a multi-client environment this may cause duplicates in SCEL. In orderto avoid duplicates and generate an internal number user exit EXIT_SAPLV50S_001 can be used – changing parameter CF_FLAG_DOCNUM_NEW:



SAP AG

As soon as the document will be created, the external-ID can be stored as a reference, while theparameter CF_FLAG_DOCNUM_NEW will cause the system to pick the next free number from thedocument number range. Alternatively – using external number ranges – SCEL can concatenate anew 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 handlingunits 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 wherethe external handling unit ID will be provided by e.g. vendors or being received from the OEMsystem. If the external-ID is anyway not a unique ID, e.g. based on SSCC, SAP can keep theexternal 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. SAPInventory Management in ERP (ERP-IM) not only offers different ownership concepts, but alsosupports 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 accountingdocuments will be created.

Stock valuation, together with number range assignments, screen sequence control for masterdata attributes and views, is a generic setting which is made on material type-level. Here, wespecify 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.

DB Schenker SCEL Multi-Client JK

Documents