SAP GTS Upgrade – A Consulting Approach
About the Document:
This document provides a consulting approach towards upgrading SAP GTS (Global Trade Services) taking into account a case of upgrade from GTS 7.2 to GTS 10.0. Although this document does not entail end to end implementation methodology it details some of the intricate technicalities and project management information, the knowledge of which is very necessary for a consultant/project manager/developer who is about to embark on the GTS upgrade journey.
Table of Contents
- Approach to Upgrade
- Resourcing Requirements
- High Level Project Plan
- Master Guide and Release Notes
- Customs Processing Dependencies
- Configuration Requirements
- Development Requirements
- Customs Processing
- German Customs – Common Issues
- US Customs – Common Issues
Approach to Upgrade
The Primary step towards the upgrade would be the approach i.e. the process in which the upgrade would take place. The process would be based on the following factors:.
ü How Many Sandbox systems do we have available for the upgrade?
ü Budget of the upgrade – Do we have enough budget to procure extra hardware?
ü Restrictions on the duration of the Upgrade
ü Risk Strategy – How much of a risk are we willing to take
Based on the above factors we have the following 3 basic approaches to the Upgrade:
Approach 1: 2 Sandbox Upgrade (Recommended)
The above approach takes into consideration 2 new sandbox systems. Thus the costs involved would be higher but the risks involved would be the least in all the approaches.
Approach 2: Single Sandbox Upgrade
This approach takes into consideration a single sandbox system available for the upgrade. Although the costs involved in this case are less than the previous approach, the risks are considerably higher because there is no way to actually perform the upgrade on production data, rather we would be relying on Development data for the upgrade.
Approach 3: No Sandbox Upgrade (High Risk)
This approach contains the highest risk and is not recommended unless absolutely necessary. Once this upgrade is started in the development system there is very low probability of being able to stop or reverse in case of some major issues.
A wide variety of resources are required to perform the upgrade for SAP GTS (Global Trade Services). Typical Resource requirements and estimated percentage of work involved are specified in the table below:
High Level Project Plan
Formulate a high level project plan based on the activities to be performed in the GTS Upgrade. Allocate the resources accordingly. Sample high level Project Plan as below:
Master Guide and Release Notes
This Master Guide is the central starting point for the technical implementation of SAP Global Trade Services. Use the Master Guide to get an overview of SAP Global Trade Services, its software units, and its scenarios from a technical perspective. The Master Guide is a planning tool that helps you to design your SAP Global Trade Services system landscape.
The Release notes contain all the different features of SAP GTS that have been installed new or have been enhanced as part of this upgrade. The Release notes should be analyzed by taking up each item and measuring the impact that the item would have on the current system once the upgrade is done. This impact analysis is very important to understand how the current system functionality would be affected by this upgrade. This also helps to helps to introduce questions to the business regarding the changes in functionality and have their thoughts on those topics.
Customs Processing Dependencies
In case you are using SAP GTS – Customs processing please keep in mind the following dependencies:
ü ATLAS and AES are the Customs processes used for Germany and US for Customs Processing. German Customs usually use ATLAS for import and AES as export. US Customs uses only AES for both import and export. Thus when you move to ATLAS 8.4/AES 2.1; this means that the import version of German Customs is 8.4 and Export version of German Customs is 2.1. For US it is usually the SAP GTS version; e.g. AES 8.0 for GTS version 8.0; etc.
ü Please check the version of ATLAS or AES (usually the latest versions) that you are moving to as part of the upgrade. Each release from German customs is unique and different thus a lot of time/effort needs to be put towards these scenarios
ü German Customs – Testing time for German Customs need to be pre-booked. Application needs to be made to the German customs by providing the information for your company and the exact dates when the testing period is required. This may take around 2-4 weeks and thus is advisable to apply for at the soonest. The testing of German customs would only be possible during this testing window.
ü German Customs – A new BIN number might be required to be applied in case you are moving to a new release of ATLAS or AES. The BIN number takes 4-6 weeks for receipt and the actual Go-Live date needs to be provided during application. Please check with local German Customs office.
ü US Customs – They usually provide year round testing window and would be already active if case you are using a testing box as well.
ü Download all SAP notes based on the ATLAS/AES versions from the SAP service marketplace. These notes contain important information regarding the configuration that needs to be done as part of every new release.
ü If the middleware used to connect to customs is SEEBURGER, SAP service marketplace also contains EDI conversions for the latest versions for SEEBURGER associated with ATLAS/AES.
ü Check with SEEBURGER by raising an OSS Message in SAP service marketplace to check whether current SEEBURGER versions are fine to support the new upgrade version.
While a GTS Upgrade does not entail much configuration changes from the SPL, Compliance, Preference or Risk Management Functions in GTS, the configuration changes required from a Customs management standpoint might be a considerable amount depending upon the Customs release that you are moving to.
Current System: GTS 7.2 with German ATLAS 8.0/AES 2.0 and US AES 2.0
Target System: GTS 10.0 with German ATLAS 8.4/AES 2.1 and US AES 10.0
- German Customs:
- ATLAS 8.0 and AES 2.0 would be obsolete in GTS 10.0
- Complete new Configuration required for Import – ATLAS 8.4 and Export – AES 2.1
- Please remember that in case you are using only Import then you should only do the changes for ATLAS 8.4 and vice versa
- US Customs:
- AES 7.2 would be obsolete and would need to move to AES 8.0 (latest) since the latest AES 8.0 is not much different in GTS 10.0
- New Configuration for setup of AES 8.0
While each of the release of German Customs contains specific OSS Notes which explains the procedures to be followed for the configuration, the same is not the case for US Customs. Preferred Practice Guides are released for US Customs Configuration. The instructions provided in the notes should be followed to perform the configuration changes required.
The latest Notes and Guides which are currently available are:
ü SAP Note 1686856 – Switching from AES 2.0 to AES 2.1 (Export – Germany)
ü SAP Note 1722158 – Switch from ATLAS 8.3 to ATLAS 8.4 (Import – Germany)
ü SAP GTS US-AES Preferred Practice – SDN – SAP (SAP Business Objects Global Trade Services 8.0. Preferred Practice. US – Automated Export Systems (AES).
In most of the OSS notes described above you might find the following content:
You must make different Customizing settings to use AES 2.1. Delivery Customizing for GTS 10.0 SP 12 or GTS 8.0 SP 22 contains the settings described below.
Before you switch to AES 2.1, you should transfer the delivered Customizing (client 000) to the work client. You can use the match function in the respective view maintenance for this purpose.
The Purpose of this would mean that for each of the items in transaction code SPRO under Global Trade Services->Customs Management you would need to adjust the tables by copying from Client 000 to the work Client. Please follow example below:
Transaction Code: SPRO
Path: IMG->SAP Global Trade Services->Customs Management->Communication Processes->Define messages for Communication Processes
Step 1: Menu->Utilities->Adjustment
Step 2: Provide the RFC Connection to GTS 000 Client (The RFC Connection should be maintained by Basis team)
Step 3: There can be 3 types of entries:
- Same as Delivery Client 000 (Gray/White)
- New entries from Delivery Client 000 (Green)
- Changed entries from Dleivery Client 000 (Yellow)
- Not Present in Delivery Client 000 (Red)
Step 4: Adjust the entries by either accepting the changes/creating new entries/deleting entries. For each of the entries take a calcualted decision whether these entries are required for current scenarios. These entries can always be adjusted during the lifecycle of the project but there is high impact of these entries in the customs areas. (Please note: There might be custom-changes relevant for your project. Make sure those entries are not deleted or removed)
Step 5: Perform the above procedure for all the SPRO entries under Customs Management relevant for the customs procedure as mentioned in the OSS Note.
ABAP Development is a mandate for any type of upgrade. In a GTS Upgrade apart from the usual upgrade tasks like SPAU/SPDD; there might be requirements from the customs management perspective to modify the logic for Customs documents due to the relevant customs procedures. Also in case you are not upgrading to the latest support pack then there might be multiple issues which would require OSS note implementation or investigation from the ABAP Development side.
- SPAU/SPDD – While the development system is being upgraded, there would come a phase in the upgrade procedure where the system would ask to fix the issues with SPAU/SPDD. At this juncture, the list of objects in SPAU and SPDD T-codes, with the relevant Icon color and transports should be extracted from the system. Each of these objects should be carefully inspected and relevant action should be performed on each of the entries. Usually there would not be many changes in user exits unless OSS notes have been implemented manually. These changes can be ignored as these would be automatically updated with the latest Support Pack.
- Customs Document Logic: Few modifications might be needed in some of the German or US Customs logic to wither exclude or include fields/values required as part of the US or German Customs procedures. Example: When you have an NLR License for US AES Customs, the values for the NLR license should only contain “NLR”. However based on the license setup there maybe additional documentation coming from the license. This detail can be removed fromthe customs document by using ABAP development in the BADI for the customs document.
- OSS Notes: Although you maybe upgrading to the latest support pack, there might be certain OSS notes which are created after the support pack release. These notes can be either listed out before the implementation start or during testing procedures. However, it would be handy to have these notes available to help in troubleshooting in case of issues.
Customs Declarations for Customs is an integral part of the GTS Module in SAP. This enables Export and Import Documents to be sent to Customs offices in various countries and receive the responses from the Customs Offices electronically. The Responses from customs can be either acceptance of the customs exports or it might be a rejection of the Customs Declaration along with a valid reason for the same.
Customs processing is dependent on the middleware that is used to connect with the Customs Office. Middleware would be usually SEEBURGER, FEDEX, etc. These companies have strong expertise in handling the mapping between SAP and the Customs office by transforming the SAP IDOCs into customs readable flat file formats.
While processing the customs declarations, there might be a realm of checks, issues or errors that we might receive during testing. Some of the issues/errors with the associated solution proposals are listed below:
German Customs – Common Issues
Issue: Incompletion logs are generated irrationally although the data is correct and the declaration should not be incomplete.
Solution Proposal: Please follow the SAP note for implementation of ATLAS/AES respective versions. These notes suggest changes to the incompletion log procedure i.e. use the incompletion log new Function Module rather than the dynamic field listing in incompletion procedures as was done in previous GTS versions. [Reference OSS Note: 1686856]
Issue: Incorrect EORI number (might also be a translation issue with middleware)
Solution Proposal: The EORI number and the Branch Number (SLLBRA identifier in Business Partner data) have been changed and thus “DE” needs to be added in front of the existing EORI/TIN number to conform to new regulations. The Branch number should also be updated in accordance with the new regulations (Usually it would be 0000).
Issue: No Response for Customs Declaration from Test Customs Server
Solution Proposal: The test Customs server for Germany is usually configured to accept transactions from your company for which the test Customs server has been setup. When you apply for a testing window, German Customs usually sends a PDF document with all details like BIN Number, Location, Authorization, Customs offices, etc. If the same details are not configured in the GTS system no response would be received from test Customs server.
US Customs – Common Issues
Issue: Error in translation (in case of SEEBURGER)
Solution Proposal: Sometimes, for the latest versions of US AES 10.0, certain details sent by SAP are not acceptable during SEEBURGER conversion and the translation fails. The issues might be due to:
ü Previous Document number (PINV) should no longer be provided
ü Document types for CUII should contain values specific to appendix F
ü Document types for CUII should not contain values for Quantity unless filling for Military reasons
Issue: VAT No. or EIN Number check fails during Incompletion log
Solution Proposal: Implement Note 1728933 – US AES: Incorrect length check of the EIN (Implementation)