Important information

The API reference is now available here.
The deprecated API reference is available here.


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 support 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 usually 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 tab.

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 Administration > Fehlerbehebung > Logbuch.

The JTL log works has log levels, which means 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 that were logged during this time.

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.

icon warning
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 usually happens if the workflow for sending the invoice number was either not created or configured incorrectly. 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. See also Create workflows.