Important information

The domain name and auth service are now updated.
Please read more


FAQs and known issues

Refer to the frequently asked questions and their solutions.


If you are facing any problems with the plugin, first check the logs and if necessary contact our support or your service partner if you cannot solve the problem on your own.

The more information you can give to the Support team in case of a problem, the sooner we will be able to help you.

Check Log files

You can check the log files to identify the cause of the error. You can also send these to us for further analysis and support. Depending on the error pattern, these 3 log files are relevant to resolve errors.

Browser Log

The browser log is mostly relevant when something in the front end of the store is not running as expected. For example, you click a button and apparently nothing happens. You can see the browser log by pressing F12 in the browser and then switching to the Console.

Shop Log

You can analyze the shop log when unexpected error messages are displayed in the front end or when the plugin is working fine in the front end but does not deliver the result as expected. Sometimes the results from the browser log also indicate that the store log should be analyzed.

You can find it in the JTL admin section, by going to System > Wartung > Log.

The JTL log works has log levels meaning that you will only see log messages if they have been created after the log level (types) has been changed. The plugin logs almost exclusively in the debug log level. The only exception is critical errors. So, if something does not work, you should first activate the debug log level, perform a test order, then deactivate the debug log level again, and check the messages logged in the meantime.

Webserver Log

The web server log becomes relevant when you encounter an Error 500 (= blank page) somewhere. Your hosting can provide you with the web server log.

In the default configuration, the JTL store logs nothing at all in the web server log, not even critical errors like an Error 500. For the store to log these errors, the individual *_LOG_LEVEL values in /includes/config.JTL-Shop.ini.php must be changed from 0 to E_ERROR.

Do not edit the store’s configuration file unless you know what you are doing! Incorrect adjustments here can make your store inaccessible or (encrypted) data unusable. If in doubt, ask your host or service partner for help.


Why can’t an invoice be shipped or finalized?


This is usually the case if the workflow for sending the invoice number was either not created or configured correctly. If the following messages are available in the store log, the parameter of the workflow action has not been created correctly.

*[Unzer] Called SyncWorkflowController with the following data:* `Array ( attrs: {{ Vorgang.Auftrag.Attribute }} invoice_id: {{ Vorgang.Rechnungsnummer }} invoice_date: {{ Datum.Gestartet }} )`
*[Unzer] Plugins360_unzer_shop4ControllersSyncWorkflowController: Missing parameter payment_id or invoice_id* `Array ( {{Vorgang_Auftrag_Attribute}}: )`


If you add the text for the parameter in the field as is, the variables are not replaced and are treated as normal text. Hence, the invoice number is not saved in the store when the workflow is executed and the invoice payment types cannot be finalized.


To avoid this and add the correct value, select Expand and then add the value.