Update Guide (GTC 21.07.xx-neu)


The following section offers a short guide to how to update the GlobalTaxCenter (GTC).


The delivery package for the GTC application usually consists of a deployment (directory with files, war file, etc.) and a directory with one or more database scripts.

Once the delivery package has been downloaded, you can begin with the installation. Please follow the order given below (first database and then deployment) when updating. A different order can lead to incorrect system behaviour after the update.


More detailed information on the individual steps can be found in the following sections.

1) Preparatory measures

1.1) Performing a database backup

As a first step, you should create a database backup that can be restored (rolled back) if the update fails. For information on how to do this, please refer to the user manual of your database management system.

1.2) Stopping the web application server

  1. Stop the web application server (e.g. Tomcat) in the usual way using either the command line or the Service Manager.
  2. Delete the contents of the “work” directory in the Tomcat installation.

1.3) Save old deployment

  1. In the subdirectory "\webapps" of the Web Application Server, you can find the deployment installed so far (usually with the name "\gtc" or "\ROOT").
  2. Rename this directory (e.g. "\gtc_<version>_old") and then move it to a directory outside the "\webapps" directory. Under no circumstances may the backuped deployment remain in the "\webapps" directory. This would lead to serious errors later on in the update process. 

1.4) Update SAPJCO (optional for systems with a SAP connection)

The GTC is working with a new SAPJCO version. Provided RFC connections are addressed with the GTC, you must perform the following steps when updating to GTC version 20.11.03 or newer:

  1. Download the suitable connector for your system from this offical SAP-Site.
  2. Delete any old sapjco{*}.jar from this directory: "<Tomcat-root>/webapps/<gtc-root>/WEB-INF/lib".
  3. Paste the new sapjco{*}.jar in this directory:  "<Tomcat-root>/lib". If an old sapjco{*}.jar exists in this folder replace it with the new one.
  4. Delete the old sapjco{*}.dll from the system. It can be in different locations, but in most cases it is in the system32 folder from Windows.
  5. Paste the new sapjco{*}.dll in this directory: "<Tomcat-root>/bin"

If you get any problems with this please contact our hotline.


After the preparations are complete, you can update the database and then the deployment.

2) Update deployment

Copy the new deployment into the subdirectory "\webapps", i.e. "<installation directory Tomcat>\webapps\gtc\". It may need to unzip the zip archive.

Similar to the GTC version installed so far, the new deployment must be told which type of database it should connect to. For this purpose, a reference to the correct database (MySql, Oracle, MS SQL) is created in the central "<gtc-root>\WEB_INF\classes\repository.xml" file. The connection parameters in the respective "repository_<xyz>.xml" must then be updated.

A note on copying configuration files

Avoid simply copying the repository.xml files from the old GTC deployment into the new GTC deployment. This can lead to errors as the contents of the repository files can change slightly over time.

  1. Customizing the "<gtc-root>\WEB_INF\classes\repository.xml" file:
    In this file you inform the GTC what kind of database it should connect to. Look for the line <!ENTITY datasource SYSTEM "repository_mysql.xml"> and replace the term "mysql" depending on your type of database if necessary. If you are using Oracle, use “oracle”. For using a MS SQL database write “mssql” (z.B. <!ENTITY datasource SYSTEM "repository_mssql.xml">).
  2. Transfer the connection settings from "repository_mysql.xml", "repository_oracle.xml" or "repository_mssql.xml" from the previous backup to the directory "<gtc-root>\WEB-INF\classes\" in the file of the same name of the new deployment.

If you know of any other modifications to the deployment (e.g. in the "web.xml" file), please copy these too by editing the respective file.

3) Update database

The database update can be done automatically or manually.

By default you'll get a delivery package without databasescripts and activated automatic datebase update feature.

Optionally you'll have the chance to update the database by manually executing scripts against the database. We can create and send the scripts to you if needed. Please see Section 3.2

3.1 Automatic update of the database

Please make sure to have a current database backup at hand, so it can be restored if needed.

Update of database doesn't need additional tasks. Upon start of application server (see section 5), the database is updated automatically by application.

Reminder: update of the database is done without further notification at startup, please check the log file "gtc_dbMigration.log" for messages. 

After successful update, the logfile should show:


2021-10-22 15:12:57 [INFO ] ###################### Migration successful ######################
2021-10-22 15:12:57 [INFO ] ScriptLocationPath: C:\Tomcat 9.0_GTC\webapps\ROOT\migration/sql
2021-10-22 15:12:57 [INFO ] ConfigLocationPath: C:\Tomcat 9.0_GTC\webapps\ROOT\migration/flywayConfig.properties
2021-10-22 15:12:57 [INFO ] CSVPlaceholderPath: C:\Tomcat 9.0_GTC\webapps\ROOT\migration/FlywayPlaceholders.csv
2021-10-22 15:12:58 [INFO ] ############################################
2021-10-22 15:12:58 [INFO ] Current version: 20211001100000000_DELETE FROM TFLAGCONFIGURATION
2021-10-22 15:12:58 [INFO ] Pending Scripts: No pending scripts
2021-10-22 15:12:58 [INFO ] ############################################

Important: If you update from a version older than  20.06.07 the update may last hours, because the periods will be migrated at start of the tomcat. This might be done in half an hour but can last many hours in the worst case. One database had over 30 periods, this update took over 14 hours. Check the progress of this migration in the file gtc_autorun.log.

3.2 Manual update of the database


Database permissions

To execute the database scripts use a database user who has full permissions to the database schema. Otherwise, it may happen that database tables cannot be created or updated correctly or that the GTC cannot access the tables properly at runtime.

In any case, check the results in the log files to see if there are any anomalies. If you find any errors, please get in touch with the  Hotline GlobalTaxCenter.

If SQL scripts are included with the delivery package, please carry out the following steps:

  1. Start the DBMS of your database server and select the database schema that belongs to the GTC application.
  2. Execute the supplied SQL update scripts in order of the file names or versions on this schema. Use a user who has full permissions on the database.

    Example:
    • 01_MSSQL_8.3.02_8.4.04.sql
    • 02_Insert_Reporting_MSSQL.sql
    • etc.

4) Final steps

  1. Start the Web Application Server as usual from the command line or the Service Manager. Autorun jobs may now be executed when the server is started. These are part of the update and must be executed successfully. Do not cancel the server start, even if it takes longer than usual. If in doubt, contact us at hotline@amana.de
  2. After starting the WAS server, test the access to the GlobalTaxCenter or inform your responsible department to have the access tested if you do not have access data for the GTC yourself.
  3. Change (or an authorized representative) in the Masterdata area to the Administration dialogue and there to the Log tab and open the file "gtc_autorun.log". Check whether the autorun jobs have run successfully or whether error messages are displayed. In case of an error, please contact the Hotline GlobalTaxCenter and send the log files "gtc_autorun.log" and "gtc_system.log".
  4. If errors occur in the web application after the update, please also contact the Hotline GlobalTaxCenter and send the log files.

5) Transfer to other instances

If you are working with different instances (development, test, integration, production, ...) please be careful that you are doing the same steps in each instance.

For example:

  1. In the testing and production environment the GTC is installed in version 19.00.01.
  2. Now you update the testing environment with version 19.00.03.
  3. A few weeks later you will receive a new delivery package and update the testing environment. This now has the version 19.00.07.
  4. The production environment still runs with version 19.00.01.
  5. You receive the permission from the business department to update the production system to version 19.00.07.
  6. In any case, you must first import the scripts of version 19.00.03 before you continue with the installation of version 19.00.07. This is the only way to prevent an inconsistency in the database.

6) TransferClient installation and integration into the GTC

If the GTC (Tax Return module) is also used for electronic transfers to the german tax authorities, the TransferClient version must also be updated at regular intervals. In this case, the GTC update provides a second installation package for the TC. This package has to be installed according to the instructions. During the installation the Web Service URL should be noted, because it has to be stored/updated in the administration area of the GTC.

Due to technical specifications by the german tax authorities, the latest ERiC version of the tax authorities must be used from around mid-April of each year (minimum version increase). Otherwise, the tax authorities will refuse to accept the tax return from this date.

To ensure that tax returns (also relevant for older assessment periods) can continue to be sent with the GTC, the GTC and the associated TransferClient sending module must be updated in time before the minimum version increase.


To configure the TC connection in the GTC, the following steps must be performed. For the configuration, editing authorisations for the area Master Data / Administration are necessary.

  1. Activate Web Service to TransferClient
  2. Setting up the proxy between GTC and TransferClient (optional)
  3. Testing the connection to the TransferClient
  4. Setting up the proxy between TransferClient and tax authorities (optional)

6.1) Activate Web Service to TransferClient

The following configuration must be carried out so that the Elster transmission is available as a web service. On the administration page, the connection to the TC is added. (The TC must be started as a web service).
A new connection of the category "WebService" is set up. The name must be "eric" (case sensitive). 


"Host" and "Port" must be entered according to the TC installation. If the Web Service URL of the TC does not end in "eric", the last part of the URL (e.g. eric29) in the connection must be entered in the field Parameter 1.

CategoryWebService
Nameeric
Host<http://ipOderDns>
Port<Port>
Parameter 1<"eric...">

6.2) Proxy between GTC and TransferClient

The proxy is maintained as a separate connection parameter on the administration page.

CategoryExternal system
NameatcProxy
Host<http://ipOderDns>
Port<Port>
User<UserName>
Password<Password>

6.3) Connection test to the TransferClient

Now the connection to the TC can be tested by clicking on the gear symbol (in the front of the line). A message is then displayed whether the test was successful or not.

With this test only the connection to the TC is tested. It can still happen that the TC itself cannot establish a connection to the tax administration. For this purpose, a proxy may have to be configured or ports may have to be released (see TC instructions).

6.4) Proxy between TransferClient and tax authorities

The proxy is maintained as a separate connection parameter on the administration page.

CategoryExternal system
NameericProxy
Host<http://ipOderDns>
Port<Port>
User<UserName>
Password<Password>
Parameter 1<"Any"/"Basic"/"Digest"/"DigestIE"/"GSS"/"NTLM">