Skip to Content

Adventures in GTD

Global trade is often a complex area and presents many challenges for ERP implementations. An example of this is the customs declaration number, also known as GTD or CDN, in Russia. With country specific local requirements there may be uncertainty over what is offered in the standard solution, what the business actually requires and what can be realistically achieved. In such scenarios you have to decide whether to use ABAP to develop your own complete custom solution or work with what has been provided as standard and just look to fill ‘gaps’ with ABAP coding.

This blog is an attempt to discuss aspects of GTD in Russia and give some ideas to the approach you could take. It will cover the following:

  • What is GTD and its purpose
  • How GTD can be handled in standard SAP ERP
  • Ideas on how to handle GTD
  • A glimpse of SAP’s GTD solution in the future

What is GTD?

The Customs Cargo Declaration (also known as GTD or CCD) is part of customs formalities in Russia for goods which are imported into the country. It is a ‘general declaration’ that is used by all customs regimes set by Russian customs legislation from the initial import of a material to the first customer sale. 

I have read and been told many different things about the length and composition of the GTD field! The definition that will be used here is that the GTD is an alphanumeric number of between 25 and 27 characters that is actually made up of four 4 parts, each separated by a forward slash when output. This is also referred to in SAP note 1334140 for example. Using this definition the GTD field comprises the following information:

  1. 1.      The customs office or ID number for import (issuing authority)

e.g. 10001010 Òàìîæåííûé ïîñò Àýðîïîðò Âíóêîâî (ïàññàæèðñêèé)

(Customs post Vnukovo Airport (passenger)

  1. 2.      The GTD or import date

e.g. 280210 (DDMMYY)

  1. 3.      The number of GTD

e.g. I000421

  1. 4.      An item number

e.g. 123

The 4 parts are concatenated together to make the GTD number, for example:

10001010/280210/I000421/123

Accompanying the GTD number is a country of origin. This information relates to the source of the material prior to import into Russia and it is quoted separately to the GTD which is a mandatory characteristic that must always be tracked with the GTD simultaneously. I have seen scenarios where it is possible that different materials can have the same GTD but a different country of origin!

Aside from tracking purposes there is also a financial element to GTD. The GTD is used to report VAT purchase information to the Russian tax authorities when goods are imported from foreign suppliers and the VAT amount paid at customs can be later be refunded.

How is GTD handled in standard SAP ERP?

i)                 Storing the GTD

The recommendation in ECC 6 for MM postings is to use the foreign trade import fields on the purchase order to store the different parts of the GTD number. Within the import section you should go to the ‘prelim doc’ tab and enter the different parts of the GTD number in the relevant fields:

image

 A lot of the information exists about the GTD number on the internet suggests that you should use the preliminary document number (EIPO-VORNU) to store the GTD number. Changes in Russian law in 2006 however meant that the format could be up to 27 characters and the VORNU field was only length 25 characters. The four parts of the GTD number should therefore be entered as follows:

image

 The country of origin field should be entered into the ISO code, field EIPO-VOISO. Further information on entering purchase orders for imports can be found in the online help:

http://help.sap.com/saphelp_erp60_sp/helpdata/en/4d/d8492af1f74c14b2661edf23aeed09/frameset.htm

If you post documents in FI then the GTD should be entered in the field BSEG-SGTXT on the invoice.   

http://help.sap.com/saphelp_erp60_sp/helpdata/en/c5/e18ee277994345a83e724df31ed5fb/content.htm

ii)                Using the GTD

When importing goods VAT is paid at customs and the taxpayer has the right to offset customs VAT for refund. The refund is made on the basis of customs declaration and payment documents (VAT invoice is not required). These are registered in the purchase book report, J_3RF_BUY_BOOK_03, which is a Russian specific report for reporting VAT purchase information to the Russian tax authorities. Both GTD & payment order serve as documents confirming the right for refund (like an invoice-facture received from a supplier). The GTD information is shown in the purchase book report as follows:

image

 Ideas on how to handle GTD

The SAP standard solution described so far provides a means to both store and report the GTD information. Some customers however require more sophisticated handling of the number and solutions to do this can involve using batch management. This approach involves creating a new batch for every goods receipt (import) and the GTD number being maintained as a characteristic of the batch. A big advantage of this approach is the ability to use the standard FIFO based batch determination for the goods issue however the manual entry of the GTD and use of batches may not be suitable for all customers. The alternative approach is to use custom ABAP development – either to develop your own complete solution or to fill gaps in functionality.

One common requirement is to automatically allocate a GTD number to an item at a time of booking in and use a FIFO principle to allocate a GTD number was (aka “use it”) via a goods issue. To fulfil this requirement you can use the standard BAdI MB_DOCUMENT_BADI and method MB_DOCUMENT_BEFORE_UPDATE. GTD information would need to be stored in a custom table and logic developed to look at the movement type and either increase or decrease a count of GTD’s. A timestamp should be included in the table key in order to facilitate the same GTD being used at a different time and any FIFO requirements for using that number.

Using such an approach might mean that updates to a custom table are required to be made from within the purchase order. You can use method CLOSE within the BAdI ME_PROCESS_PO_CUST for this purpose and a further enhancement V50EPROP is available where you can add additional logic to check the data entered into the fields in the PO foreign trade import screen. This could be used for example to ensure that mandatory data requirements are fulfilled or that data entered in the fields which make up the GTD is valid.

Finally a requirement often exists to undertake mass updates of GTD information. It is possible that GTD information may only be provided by a supplier after the purchase order has been created via separate file update for example. In such a scenario it would be quite onerous for a user to manually update the information in what could be a large number of documents. If you are using the standard fields on the purchase order to store the GTD information then you cannot (currently at least!) update them using the function module BAPI_PO_CHANGE and you recommended to develop a separate CALL TRANSACTION program to update them.

A glimpse of SAP’s GTD solution in the future

A new solution for GTD number tracking has been developed by SAP and will be available for customers using the Russian country version as of enhancement pack 5. Information on the release schedule for this can be found on the SAP Service Market Place and the SAP ERP section.

The customs declaration data is stored in a new source database table and new transactions have been developed to enable easier creation of data:

image

 To enable mass entry of data:

image 

Also included in the new solution are the following:

  • The ability to activate GTD tracking by billing type and country of origin of the material
  • Authorisation control over GTD source table maintenance
  • Tracking of GTD usage by either material or billing document (stored in new tables)
  • Support for the Custom union between Russia, Kazakhstan and Belorussia
  • New reporting capabilities for import customs declarations assignments with the ability to show items with open quantities

Summary

The aim of this blog has been to try to provide some insight into how GTD can be handled in the current and future versions of the system. Exactly what solution is adopted will depend upon both legal and customer requirements at the time of implementation. Often in such an implementation a mixture of both global and local expertise will be required. A solution for GTD can achieved in the system without necessarily large scale custom development and the changes coming in the future enhancement pack release should significantly aid customer requirements.

4 Comments
You must be Logged on to comment or reply to a post.
  • I really like the fact that there are many different solutions listed in the Blog.  It really gives a head start no matter which solution is ultimately chosen.

    This will be one that I bookmark.

    Michelle

  • David, thanks for the goood review of SAP solution for GTD.

    But you didn’t mention that in current solution, available as of EhP6, there is some sad logical inconsistency 🙁 As far as I know, the Purchase Ledger report still uses the Froreign Trade data from the PO, while the GTD tracking function uses the GTD data stored in a separate J3R* table. So you have to maintain GTD data for imports twice if you want to use both report and tracking function.

    I will be very glad if you say that I’m wrong.