Welcome to our FAQ page! Here, you will find answers to the most frequently asked questions regarding our products and services. This page offers you quick and helpful information that supports you in using our platform. No matter if you need setup assistance, error solutions or tips for optimal usage – our FAQ is here to help you out!
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.
-
The data was created today, meaning on the current date. Data is only updated once overnight between 0:00 and 06:00. This means that changes of the current day are only visible on the following day.
Note
This makes sense for cost reasons as well as according to our usage analysis, since more than 90% of customers do not query their reports multiple times a day. If you need a shorter update interval (e.g. every 3 hours or in nearly real time), you can request this via an individual contract for your instance. To do so, please contact our Customer Development Team by sending an email to accountmanagement@xentral.com.
-
Synchronization error: Compare the data from the database view to the data displayed in the Reporting module. If data is missing in the Reporting module or more data is available, please contact the Xentral support.
Note
We are continuously working to prevent syncing errors. We have already implemented automated data sync processes for specific tables.
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.
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:
-
“You have reached the query limit. Please try again later.” This message means that you have executed to many queries in a short period of time. If you wait for about 1 minute, you can execute new queries. This limitation was introduced to prevent system overload.
-
“Query limit reached” / “credit limit exceeded”. This message means that you have reached your query limit in the full view. The limit depends on the conditions of your subscription. We recommend that you test your queries in preview mode so that no credits are used.
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.
System currency and original currency
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 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:
-
Primary key naming: There are no more generic id fields. The primary key of a table is now called {tabellenname_im_singular}_id. Example: invoice_id instead of simply id in the invoices table.
-
JOINS are more explicit: Due to the changed naming of the IDs, JOINs are now mostly structured in a symmetrical way.
FROM invoices AS i LEFT JOIN invoice_items AS ii ON i.invoice_id = ii.invoice_idHowever, there are a few exceptions to this rule.
-
Earliest date: Instead of 0000-00-00 in the old reporting module, the earliest possible date is now 0001-01-01.
-
Booleans: Boolean fields are now true booleans (TRUE/FALSE) and no longer 0 or 1. Example: artikel.geloescht = 0 becomes products.is_deleted = FALSE. All boolean fields start with is_ or has_.
-
GROUP BY behavior: Redshift follows the ANSI SQL standard. This means: All non-aggregated columns must be included in the GROUP BY clause. The MySQL settings in the old reporting module were less strict, which could lead to inconsistent results
-
Case sensitivity: In MySQL, the WHERE clause is case insensitive by default. By contrast, in Redshift, the filters must be exactly identical with the value in the data set. Example: WHERE groups.group_type = 'Group' does not work if the entry is group.
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:
-
One thousand is displayed as 1000.00.
-
Ten thousand five hundred is 10500.00.
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:
REPLACE(REPLACE(REPLACE(TO_CHAR(net_price, 'FM999G999G999D00'), ',', '#'), '.', ','), '#', '.')Note
With this formatting, the numeric value in the field net_price can have a maximum of nine digits before the decimal point.
Explanation of components:
-
TO_CHAR(…) formats the numeric value
-
FM suppresses leading spaces
-
G represents the thousand separator
-
D represents the decimal separator
-
REPLACE(…, '.', ',') replaces the dot with a comma