13. June 2019

10 minutes

HOW TO | EWM & GTS Integration

Technology

Possible Integration Scenarios

Inbound Transit (NCTS) – After customs authority sends permission for unloading, only then the goods may be unloaded. Relevancy for this check is based on entering the previous document (e.g. T1) + MRN number
Safekeeping – begins automatically after inbound transit. Goods can be put away, however reside in customs blocked stock. Posting goods issue or creating loading warehouse task is not permitted while in safekeeping
Outbound Transit (NCTS) – When the customs authority sends permission to load the goods, the delivery is released for goods issue. Other status may be pending Customs Inspection.
Outbound Compliance checks (Legal Control, SPL, Embargo) – At the creation of Outbound Delivery Order, or when ODO or Outbound Delivery are changed manually – Check of outbound delivery before goods issue
Outbound Letter of Credit Check – Check if letter of credit is still valid for the transaction
IBGI – Invoice Before Goods Issue scenario
Bonded Warehouse – Scrapping – (only the Scrapping procedure is supported) – if product is relevant for customs warehousing GTS applies for permission at the customs authority to scrap for duty paid/unpaid stock

EWM Architecture

From the GTS point of view EWM is programmed in a different way than GTS. What you will notice is the absence of the GTS specific GUIDs via which the tables are linked.

EWM uses CIF – Core Interface for interconnection with feeder systems – S/4, R4, SCM.

GTS does not use CIF. The connection from EWM to GTS is done via RFC calls (and queued RFC) with the use of PPF Actions (Post Processing Framework)

EWM also stores the master data from feeder systems similarly as GTS, however this transfer is done via the more robust CIF interface. For debugging between ERP and EWM the tcode sqm2 is often used when a document is stuck in the queue. This can also come handy when trying to debug issues related to GTS. (E.g. when the delivery in EWM is blocked and preventing execution of goods issue)

To the master data in EWM belong also materials and business partners (customers and vendors).

Master data and transactional data – Inbound/Outbound Deliveries, Shipments – in EWM known as Transportation Units, Packing & Picking documents, Goods Movements, Batches, and others are synchronized between EWM and ERP.

In General

ERP, GTS, and EWM have all its own document types, item categories, partner functions which need to be mapped. So not only the common mapping between GTS and ERP but also between EWM and GTS is required. When the EWM consultants talk in familiar language about “ciffing” – via term not known in GTS world, it is similar as triggering the initial transfer to GTS, this time only from ERP to EWM.
Also, what must be mentioned is the presence of three different “outbound deliveries”. The flow goes typically from the creation of Outbound Delivery Request, through Outbound Delivery Order up to the Outbound Delivery (ODR->ODO->OD) Outbound Delivery from ERP is integrated to ODO and after goods issue the OD is created.

Flow starting from ERP vs from EWM

The flow starting via Outbound Delivery through picking, packing and ending via Goods Issue as we know it from ERP is now part of EWM (in some scenarios the old Inventory Management – IM can be used) and of course EWM support batches. Transportation Units can be either created from EWM, or during the outbound delivery distribution to EWM as a copy of shipment. At the end of the EWM process the shipment in ERP after posting goods issue in EWM is enriched by EWM related data.

During the inbound process the materials contained in deliveries can be batch managed, either by creating batch in ERP or later on in EWM.
The moment when the batch is created and filled with information is important for intrastat and import scenarios because the most correct information of country of origin is typically saved to the batch at its creation – be that at inbound delivery creation in ERP, or in EWM, at the creation of goods receipt in EWM or at its replication to ERP. Each client is different but correct information of the country of origin can come e.g. either (in S/4 scenarios) from ASN which creates the delivery, as a field in the IDOC segment of the DESADV message or e.g. from Purchase Info Record. In R/3 scenarios this can of course come from purchase order foreign trade tabs. (S/4 is completely missing foreign trade information stored in EIPO table)

EWM-GTS Integration

As mentioned, to enable the RFC communication the basis need to setup the RFC connections and users in EWM and vice versa in GTS (there are also calls from GTS to EWM).

For a few reasons – easier debugging and prevention of technical issues – it is highly recommended to set up RFC users with intelligent-robust naming convention for each client (DEV,QA,PROD) which would be used exclusively for the communication between EWM and GTS. That means the RFC users for ERP-GTS integration will be different. This will prevent situations when e.g. a blocked RFC user in EWM causes that communication to all other systems is interrupted.

The master data is replicated to GTS and EWM from ERP, that means we don’t need to transfer it again from EWM to GTS. When everything is correctly set up GTS recognizes the transactional data that come from EWM, that is business partners and materials because they are within the same logical system group.

Group of Logical Systems

This is a basis topic but on greenfield projects or where GTS is introduced from scratch it may happen that the technical consultants will initially set this up too.

In simple scenarios the ERP feeder is assigned to one logical system group and GTS system to a second logical system group. Why is it better to set it up on group level and not logical system level has many reasons. It will always result in lower maintenance efforts of the GTS clients in landscape. Important to know is that for simple scenarios in which the master data is replicated from ERP to EWM 1:1 the group of logical systems is the same for EWM and ERPs, so both logical systems are assigned to the same group and GTS keeps its own group. So for three system scenario we still have only two groups.

Customizing GTS

Mapping EWM partner functions and making them available for checks

Basic Partner Functions such as Ship-To and Sold-To, Carrier/Forwarder need to be mapped to GTS – created and assigned to GTS roles and enabled for compliance checks.

Document types

EWM document types which are enabled for checks need to be mapped in GTS

Item categories

Item categories need to be mapped as well. EWM may be adding also some additional items to the documents, such as packing or packaging materials, these should not be forgotten. And when they are added in EWM, they will be probably replicated to ERP (where they may have also new item categories)

Partner number mapping

Important setting without which the integration will not work at all. This setting is different to the one we know between EPR and GTS. Sales Organization and Plant need to be mapped. Information about Sales Org and Plant are stored in EWM within the Business Partner (tcode BP).

An organizational unit of SAP EWM must be mapped to a foreign trade organization of SAP GTS. To do this, you assign a sales organization of EWM with the partner role ‘O’ to a foreign trade organization in SAP GTS using the partner number. The partner number must be the business partner number of the sales organization – not the ID of the sales organization as in mapping for SAP CRM.

The business partner function for the foreign trade organization in the feeder system must be “O”; the function for legal units must be “00000035”.

The partners from SAP EWM must have been assigned to the legal units in SAP GTS. This means you have to assign the partners with partner function 00000035 in SAP GTS to the legal unit using the partner number.

Customizing EWM

EWM has a different and more complex naming convention of object types – documents/items/categories than ERP or GTS.

Multiple types are recognized, such as Document Type, Document Category

Within the Goods Issue customizing – Outbound part of EWM customizing the Document Types are defined and can be marked as relevant for GTS checks.

Define Status Profile – Define a status profile for the checks, and do not set the Inactive indicator for the corresponding status type
Post Processing Framework need to have enabled relevant actions for communication with GTS.

Tcode SPPFCADM

Table TBLSYSDEST needs to be maintained properly

For a given Logical System a correct RFC destination must be entered – so this is client specific.

Testing – How the integration works

Outbound

Usually the Outbound Delivery is created first in ERP system. If the items contain EWM enabled storage location, the delivery is automatically replicated to EWM, where an equivalent document is created – the Outbound Delivery Order.

E.g. Outbound Delivery in ERP – 2000001
E.g. Outbound Delivery Order in EWM will have number 301
GTS will receive outbound delivery “2000001” + outbound delivery order “2000001-301”. From the naming we can immediately tell from where the document originated.
If SAP GTS checks for the outbound delivery order contain errors, SAP GTS returns the relevant status – either blocked, or blocked due technical error, and does not create an outbound delivery for this outbound delivery order.
In the next step when Outbound Delivery is created from Outbound Delivery Order:
If SAP GTS checks for the outbound delivery contain errors, SAP GTS returns the relevant status. – either blocked, or blocked due technical error, and does not permit a goods issue posting for this outbound delivery.
GTS check/block can be overridden by a user with sufficient rights directly from EWM

Note.: For direct delivery orders, which are created solely within EWM without reference to ERP documents, legal control and letter of credit checks are not performed.

Letter of Credit

In the outbound delivery, a letter of credit number from the preceding document exists as a reference document. Only in this case does EWM perform a letter of credit check.

Inbound Transit (NCTS)

Similarly when previous document T1 is maintained and MRN number is entered this inbound delivery becomes relevant for GTS integration.

EWM copies the previous document number and previous document type from SAP ERP before you post goods receipt for an inbound delivery. If there is no previous document number or previous document type in ERP, you can specify both directly in the delivery document in EWM. If the previous document type is relevant to customs blocked stock, EWM posts the stock to a stock type for customs blocked stock.

Note1: If you change the previous document number or previous document type again before posting goods receipt,EWM automatically changes the stock type.

Note2: Authorization for transit must be maintained in GTS system – Authorized Consignee

Outbound Transit (NCTS)

Before you load a vehicle for an outbound delivery, you define whether this outbound delivery is relevant to a transit procedure. As the default value, EWM uses the status type Transit Procedure with the status value Not Relevant.

You can use the Business Add-In (BAdI) Set Transit ProcedureRelevance (/SCWM/SHP_PROC_REL_SET) to define, for example, that all deliveries for a certain country are relevant to a transit procedure. SAP EWM locks the outbound delivery to prevent additional goods issue process steps from being performed, for example, posting the goods issue.

If the customs authority allows the vehicle to be loaded, you set the status type Transit Procedure of the outbound delivery in SAP EWM to the status value Released.

Scrapping

If you use the customs warehousing procedure in SAP Extended Warehouse Management (SAP EWM), the only effect that you have on delivery processing is in the scrapping area. If you work with warehouse requests of the posting change type for scrapping in the scrapping process in the customs warehouse, GTS can apply to the customs authority for permission to scrap.

Related SAP notes

871212 – Mapping SAP EWM and mySAP CRM organizational data for SAP GTS

https://launchpad.support.sap.com/#/notes/%0d%0a%0d%0a%20871212

2494704 – SAP S/4HANA 1709: Release information and restrictions for EWM in SAP S/4HANA

https://launchpad.support.sap.com/#/notes/2494704

2668150 – SAP S/4HANA 1809: Release information and restrictions for EWM in SAP S/4HANA

https://launchpad.support.sap.com/#/notes/2668150

2725467 – Error “ERP Partner role &1 cannot be used” during GTS compliance check

https://launchpad.support.sap.com/#/notes/2725467

2773384 – Deletion of previous document number in EWM does not delete inbound delivery reference

https://launchpad.support.sap.com/#/notes/2773384

SAP versions with their support and feature packs

This article describes integrated functionality of:

SAP S/4 HANA 1809 FPS02

https://help.sap.com/viewer/product/SAP_S4HANA_ON-PREMISE/1809.002/en-US

SAP EWM 9.5 FP02

https://help.sap.com/viewer/product/SAP_EXTENDED_WAREHOUSE_MANAGEMENT/9.5.0.2/en-US

SAP GTS 11.0 SP15

https://help.sap.com/viewer/product/SAP_GLOBAL_TRADE_SERVICES/11.0.15/en-US