FAQ Reports - Frequently Asked Questions

The old reporting module is technically outdated and can no longer handle the high data demands, often leading to system slowdowns. Additionally, it is no longer actively maintained. 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.

The old legacy reporting module will remain unchanged until the end of 2024. Starting in January 2025, we will introduce initial restrictions to gradually phase down traffic on this module (new reports cannot be created, and existing reports will be read-only). Currently, the plan is to sunset the module by the end of June 2025. We recommend familiarizing yourself with the new reporting module (or alternatively the API) early on to avoid unnecessary pressure in Q2 2025.

The entire infrastructure used for the new reporting module is outside your Xentral instance. Here, all data is consolidated and can be efficiently retrieved without putting a load on your own database. Therefore, data must be regularly synchronized between your database and our analytics platform. This usually happens once a day, between 10 p.m. and 4 a.m. Orders or other data you import during the day will therefore only be visible the following day.

We synchronize the data nightly between your Xentral database and our analytics platform, which powers the entire new Xentral reporting module. See "Why don’t the orders I just imported into Xentral appear on the dashboards? Why are they not showing up in the reports?" This means, for example, that on the 1st 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.

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.

If the rest of the metrics on the dashboard are current, it’s most likely because you haven’t entered the necessary data for this metric in Xentral or there is no data available for the selected period. Generally, the more data we have about 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; 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.

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).

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.

This table has been integrated into the "product_trees" table for better usability.

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:

SELECT net_revenue AS “Revenue in EUR”, xen_net_revenue AS “Revenue in original currency”,  original_currency AS “Original currency” FROM invoices;

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. Here, ll monetary columns are always displayed in the original currency. One example for this is the products table.

Exported data is provided in the standard CSV format. In the report settings, you can specify which delimiter should be used. Issues with CSV export and importing into Excel often occur when the chosen delimiter also appears within the data values.

For example, an item name like “Screw, M3” can lead to formatting errors if a comma (,) is used as the delimiter.

To resolve the issue, you can either choose an alternative delimiter or clean the data values in the SQL query, e.g., using the REPLACE function.

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

Examples:

Fields of type numeric in the data catalog 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:

REPLACE(REPLACE(REPLACE(TO_CHAR(net_price, 'FM999G999G999D00'), ',', '#'), '.', ','), '#', '.')

Explanation of components:

The old module used MySQL to create reports.

The new reporting system uses the SQL dialect of Amazon Redshift, which is a slightly modified version of PostgreSQL. Here’s an overview of the most important changes: