​

The old reporting module is technically outdated and can no longer handle the high data demands, often leading to performance issues within the system. Additionally, it is no longer actively maintained by us. Part of the old module is being replaced by a new API that is better suited to your needs. For the new, powerful reporting module (based on entirely new infrastructure), we charge an additional fee to ensure its long-term operation.
​

Along with new infrastructure and active maintenance, the module provides all customers with the ability to create modern no-code reports, use a full SQL editor, and access reliable, well-designed report templates.

​

For near-real-time synchronization, we offer the Unlimited Plan. We will assess your requirements for synchronization intervals (hourly to near-real-time), data volumes, and query complexity to determine the additional infrastructure costs Please understand that we must pass these costs directly on to you.

​

This can have several causes which we are listing below.

​

We are syncing data between your Xentral database and our Analytics platform overnight. The Analytics platform is the motor powering the entire Xentral Reporting. For example, this means that on the first of each month, data for the current month is usually not yet available. If you want to compare the current month’s sales with the previous month, this is usually only possible the next day.

​

If all other metrics on the dashboard are up to date, the most likely reason is that you haven’t entered the necessary data for this metric in Xentral or there is no data available for the selected period. In general: The more data we have on your business, the more and better analyses we can offer you. For more information about individual metrics, hover over the question mark icon at the top right of the metric. The tooltips provide information about how we calculate the metric and what data we need for it.

If you’ve purchased our Premium Add-on, you’ll have access to many filter options. Try changing the time intervals as well. There may be no data for the selected period.

If you are a new customer, it’s essential to understand that we need to collect data over some time, especially for warehouse analysis, to display certain metrics.

​

By default, reports are updated once a day over night. It is not possible to directly view the exact timestamp of the last update. If data is missing or outdated, you should first verify whether the expected information exists in the database. If the data in the database is correct but is not displayed in the report, please contact the Xentral Support team to request a synchronization check.

​

You are in preview mode. This is mainly for testing and development purposes. You can review report contents or develop your own reports (trial and error) without worrying about immediate costs. However, only the first 5 rows of the result are displayed.

​

To keep the complexity of the new data model low, we initially only provided certain tables (specifically, those necessary to recreate 98% of the 13,200 custom reports).

Additional tables and fields can be added upon customer request if needed for reporting (and not solely to cover functionality of the missing Xentral API endpoints).

​

There is no setting to increase this limit in the full view. To display the entirety of your data, you can export the data. We have already increased the limit from 1000 to 5000 in the past.

​

​

Those two messages differ in the following ways:

​

If report queries take longer than 5 minutes (e.g. due to their complexity), Xentral terminates the query in the front end. These reports cannot be accessed via the user interface.

In this case, export the desired report directly. There is no time limit on exports and thus no possibility of a timeout.

​

​

The exports are generally visible for 7 days. After that, they expire and are no longer displayed in the system. The download links from the email also stop working after this time.

​

As soon as you make changes to the permalink settings in Xentral, you have to click on Create permalink to generate a new permalink.

​

Exported data is provided in CSV format by default. In the report settings, you can determine which delimiter should be used. If the selected delimiter also occurs in the data values themselves, you can expect problems with the CSV export and the further import in Excel.

A product name such as “Screw, M3” may lead to formatting errors if a comma (,) is used as a delimiter.

To solve the problem, select an alternative delimiter or clean up the data values in the SQL query, e.g. by using the REPLACE function.

​

​

Using the preview does not count as a query. Thus, we recommend using the preview to test your queries. If you click on Execute in the full view, this counts as a query. Each additional query that is carried out on the same day and delivers the same results does not count as a query. All queries on a new date count as a new query.

A reporting query uses up one credit as soon as it is carried out for the first time on a given day. The query can be placed via the user interface, via an export or via the API. Important: A new query is counted if the filter values and the platform (UI, export or API) are changed. This means: As soon as the report has been loaded once, it will be stored in and loaded from the cache. The report always shows the same results (the filters must not be changed) and can be accessed multiple times by multiple users via the UI or FTP. This will not lead to additional costs.

​

In this context, Custom Query refers to the manual execution of reports. In general, it is not necessary to execute a report in your instance before exporting it. Instead, you can click directly on Export after you have opened the full view.

​

In the new reporting module, Xentral typically displays entries in the system currency (in most cases: EUR). This facilitates report creation because all entries can then be aggregated without the need for individual conversion.

However, Xentral also saves the currency of an entry. If you want to see monetary values in their original currency, you can access the untransformed fields xen_ in the relevant tables, e.g. xen_net_revenue or xen_net_profit in invoices or sales_orders. When doing so, the original_currency field shows you the currency in which the amount was entered originally.

Example:

With this query, you can use the standardized system currency as well as request the raw data from a receipt.

In tables that do not have the field original_currency, the xen_ fields are not available since no EUR transformations are carried out in those tables by default. Here, all monetary columns are always displayed in the original currency. One example for this is the products table.

​

For the currency table exchange_rates, the exchange rates are called directly from the ECB API. Thus, you may find differences to the rates displayed in the Currency conversion module. We have found the data quality in the Currency conversion module to be insufficient. Thus, a query using this table would not be effective, but rather result in incomplete data. For this reason, we have outsourced exchange rate management.

​

This table was integrated into the product_trees table in order to allow for better usability.

​

Internationally, the designations gross and net are interpreted differently. Thus, we have made sure to always include a description of the individual reports. You can view this description by clicking on the question mark icon next to the report. In international business relations, gross means that returns, cancellations and additional discounts Thus, the naming explicitly does not refer to taxation issues.

​

The old reporting module relied on MySQL to create reports.

In the new reporting module, the SQL dialect provided by Amazon Redshift is used. This, in turn, is a slightly altered version of PostgreSQL. Here are the most important changes:

​

In the new reporting module, numbers in the result tables are displayed without thousand separators by default and use a dot (.) as the decimal separator.

Examples:

Fields with the type “numeric” in the data catalogue are rounded to six decimal places by default (e.g. 123.456789).

If a different number format is required – for example, a specific number of decimal places, thousand separators, or a comma as the decimal separator – this can be adjusted directly in the SQL expression.

Example for Redshift:

If the field net_price should be rounded to two decimal places and displayed with thousand separators (dots) and a comma as the decimal separator, the following expression can be used in Redshift:

Explanation of components: