Skip to main content

Desktop App - What's New in Version 2026.6.0

8 Oct 2026 - Important Notices, New Features, Improvements, Bug Fixes, Technical Changes

Written by Vývojář ABRA Flexi

⚠️ Important Notices

⚠️ Records that must not be deleted are now protected against deletion via the API as well. Calls to DELETE and imports with action="delete" now fail with an error for such records. Previously, a record could be deleted via the API even though the record type does not allow deletion.

This also applies to document links (DELETE /c/{firma}/vazba/{id}): deleting them bypassed the matching logic, the document remained paid with no link to the payment, and the matching group could be broken beyond repair. To cancel a payment, use the odparovani action on the paying document; integrations that used link deletion to unmatch documents need to be adjusted.

The uzivatelska-vazba record is deleted as before, with no change.

⚠️ The Windows and macOS installer now installs PostgreSQL 17 instead of version 13. When you update an existing installation, the data is converted to the new version automatically.

The conversion migrates the entire database, so it takes longer for larger installations. We recommend scheduling the update outside of business hours. The disk must have free space roughly equal to the size of the current data. The original data directory is kept as a backup with the version number (for example Data_old_PG13). Once you have verified that everything works, you can delete it.

If a backup from an earlier update remains on the disk, the updater offers to delete it, rename it (for example to Data_old_PG9_3), or cancel the update. The message about insufficient disk space lists any old backups found, along with their sizes.

⚠️ Inventory recalculation is faster by orders of magnitude. On a company's data with ~3 million stock movements, a full recalculation now finishes in ~30 minutes; previously it took on the order of days for such companies (depending on how the system was used). Saving a stock document on a card with many movements was reduced from tens of seconds to ~1 second. A new field, Issued qty (UoM), has been added to receipt items. We also fixed a race condition in which concurrent saving of documents by multiple users could result in over-drawn receipts.

For FIFO warehouses, the valuation of issues from receipts changes where the receipt's value cannot be divided evenly into unit prices with two decimal places — typically for goods tracked by serial numbers, for example 3 pieces for 100.00 CZK. An issue that fully draws down the receipt now calculates the remaining difference so that the sum of the issue valuations matches the receipt's value; previously the difference remained on the stock card and affected its value and average price. This takes effect only at the next inventory recalculation; for companies with closed accounting periods, we recommend scheduling the recalculation and checking its result.

The database function jevydano has been removed — it was replaced by the Issued qty (UoM) field (column mnozMjReal). Custom queries, reports, and scripts that call it will fail after the upgrade and need to be adjusted.

⚠️ Custom report templates may no longer contain expressions in Groovy or JavaScript. For security reasons, only Java expressions are evaluated; a report that uses another language will not render.

⚠️ Link attachments and report templates are more securely protected. The server never returns the content of a local file or of a link to an internal network. A link to a file on the user's computer can still be saved, and the desktop application opens it as before. Public http and https links continue to work, but redirects are not followed. It is no longer possible to save a link with a scheme other than http, https, and file (e.g., ftp: or mailto:); links that are already saved remain.

New Features

  • The Daily exchange rate setting offers a new option, From the current day (update continuously). When a foreign-currency document is created before the Czech National Bank (ČNB) publishes the rate for that day, the last known rate is used and Flexi notifies you. Once the rate is published, it is updated automatically, so subsequent documents on the same day receive the current rate. Previously, a rate downloaded before publication applied for the whole day.

Improvements

  • You can no longer block your own user account via the API. The attempt fails with a 400 error and the message "You cannot block your own user account.", and the account remains functional; this aligns the API behavior with the application, where the button for blocking your own account is disabled. Blocking and unblocking other users and regular editing of your own account work as before.

  • Attachments of linked objects are no longer part of the detail of full. Exporting a document with attachments therefore no longer overloads the response or the server's temporary storage. If you need the attachments, request them using the detail custom; the relations=prilohy parameter works as before.

  • Standard accounting reports can no longer be changed via the API. Creating, editing, or deleting standard reports and their definitions is not possible via the API — previously, a standard report could be overwritten unintentionally and its definition lost. Custom user reports are managed as before. Importing the rozpadRadku property for a standard report now fails with a 400 error instead of being silently ignored.

  • An API filter can select records based on whether a label is filled in: stitky is empty returns records without a label, and stitky is not empty returns records with at least one. Previously, such a filter either failed with an error or silently returned nothing. We also fixed the filter on a label via a relation — for example dodavatel.stitky is empty on the price list, which previously ended with a server error.

  • A user query that has reports linked to it can be deleted via the API and the WUI as well. The reports are preserved; only the links to them are removed. The link to reports for a user query can now also be listed and edited via the reporty collection in the uzivatelsky-dotaz record; until now, it was available only in the desktop application.

  • A JMHZ submission item created via the API now requires both the submission header and the employment relationship to be filled in; otherwise it fails with a 400 error. Any items without these links are removed during the upgrade.

  • Default sorting of records can be turned off using the no-order=true parameter. Records are then returned in the order in which the database provides them. This is useful for fast reading of large records where order doesn't matter. It cannot be combined with order, sort, or start.

  • The most demanding listings may run faster on large datasets because the database is allowed to compute them in parallel on multiple processor cores. This applies to the accounting journal, the invoice items overview, linking documents, and so on.

  • Assets allow you to enter different tax and accounting acquisition prices. Depreciation, the commissioning event, and related reports calculate with both prices separately.

  • The JMHZ Viewer opens directly from Flexi, via the company page /c/{firma}/jmhz/prohlizec, rather than via a temporary file on your computer. The data is not passed in the link, so even large reports with many employment relationships, which previously failed to open because of the URL length, now open correctly. Access is governed by the standard permission for the Monthly report form. If you save the report to Flexi already in the Viewer, the "Was it sent?" prompt in the wizard closes by itself.

  • The message about an unsupported activity code when creating a Monthly report now states the specific activity code, as well as the person and employment relationship concerned.

  • The JMHZ Viewer can update a report that is already saved in Flexi. As a result, changes made after saving from the wizard also make it into the record of saved submissions.

  • The text item with the order number that Flexi adds at the beginning of an invoice when you insert items from an order is now created in all languages configured in the company. Previously, it was saved only in the interface language of the user who performed the conversion, so when printing the invoice in a foreign language, this one line remained untranslated. This applies in both directions — a received order into an issued invoice, and an issued order into a received invoice. Existing documents are not changed.

  • Editing a saved receipt with many items is significantly faster in the web interface. Unnecessary repeated database queries have been eliminated when checking whether the batch, expiration, and best-before date can be changed on items.

  • Reading the accounting journal is faster, especially when reading page by page. The returned data does not change.

  • The message about a mismatch between the accounting warehouse setting and the stock document type now states the code and name of the type that was actually evaluated — for example, "You have set an accounting warehouse, but the stock document type 'VYD-VYR: Issue to production' is non-accounting." Until now, the message did not say which type was involved, and for receipts via bill of materials, the cause was the hardest to track down.

  • The script for resetting a local user's password can also grant the user administrator rights: all server permissions and the default ADMIN role. It also switches other users of type NORMAL to AUTOMATIC. The script is now named reset_uzivatele.bat (Windows) or resetUser.sh (Linux, macOS) and replaces the previous reset_hesla.bat and resetPassword.sh.

  • Demo companies now contain additional data, for example in HR, in variants for tax records, double-entry bookkeeping, and Slovak legislation. Trying out Flexi on demo data therefore covers more areas.

  • The bulk changes dialog opens instantly even in companies with a large address book. Relation fields that grow with the volume of data — Company, Project, Price group, and Manufacturer — are entered using a text field with autocomplete and a magnifier, instead of a list filled with the entire foreign record, so the client no longer runs out of memory. If the entered text matches no record, the dialog reports it and lets you correct it — previously, it was silently interpreted as an instruction to clear the property. Bulk change of the Contact person property is no longer offered for documents, invoices, and contracts, because a contact belongs to a specific company, and a single value across records of different companies produced inconsistent data.

Bug Fixes

  • An import that changes a non-editable date on an existing record now fails with a clear error. This typically concerns the submission date of a saved JMHZ report in the jmhz-podani-hlav record. Previously, it ended with an internal server error, and the statistics showed zero failed records even though nothing was saved.

  • Canceling the link of an advance tax document that has no link to a payment now ends with a clear message: "The selected advance tax document has no link to a payment." Previously, the response returned a Java class name from which it was impossible to tell what was wrong, and the web showed a message describing a completely different situation.

  • Records that belong only to double-entry bookkeeping are no longer offered via the API in a company using tax records. Previously, they appeared in the list of records even though they are not usable in tax records.

  • A document can be created and saved even if its document type has a field filled in that the current license does not allow. This can be, for example, a business transaction without an Intrastat license. Previously, such a value was carried over to the document and validation rejected it, even though the user cannot even see the field. Fields prohibited by the license are no longer validated and are not carried over to a new document or when copying a document. The stored data remains and is used again once the license is restored.

  • The upgrade of a cloud instance now continues even when one company is unavailable. Previously, the entire call ended with an error and the rest of the instance was not upgraded; moreover, companies that the upgrade did not reach could remain in maintenance mode permanently. Now only companies whose schema upgrade actually failed remain in maintenance mode.

  • The database functions Flexi uses for the journal, change tracking, and external identifiers are better protected against abuse via a forged backup.

    Restoring a backup with an unusually modified database structure is rejected, and the server log states which object is the problem. Regular backups are restored as before.

  • The selection of employment relationships in the REGZEC wizard sticks to the records the user actually checked, even if the data changes in the meantime. Previously, rows could be renumbered between checking and sending, and different records than the user saw could end up in the submission to ČSSZ without any notice. Export to XLS and printing from this listing no longer fail with an error.

  • An absence entered outside the duration of an employment relationship now triggers a warning, at both boundaries — before the start date and after the end date. Previously, an absence could be entered for a period before the start date without any reaction. The record can be saved despite the warning; compensation is then calculated only for the days of the employment relationship.

  • A JMHZ submission saved from the Viewer over a manually uploaded file can be used as the basis for a corrective report and a cancellation. Previously, such a submission was saved without a link to employment relationships, and the error appeared only when the corrective report was being compiled. Flexi now finds the link by the PPV ID in the XML among the employment relationships valid in the reporting period, so this also works for employees who are no longer with the company. If the link cannot be found unambiguously, the submission is not saved and the message lists the affected employees by PPV ID. If the PPV ID is missing in the XML, it identifies them by the form GUID; the cause is usually an unfilled OIČ on the person.

  • In a multi-part Monthly report, all parts have an identical fill-in date and time in the header, as required by the ČSSZ rules. Previously, they differed by fractions of a second. A saved report takes the submission date from this value, so it always has the same date regardless of who saves it and how many times.

  • Bulk change of the VAT rate type on document items also works in the desktop application. Previously, the bulk changes wizard offered it, but the change failed even though it went through via the API. In the warehouse, where the value was not stored at all, this option is no longer offered.

Technical Changes

  • The built-in Java runtime environment has been updated to Temurin 11.0.32.1+1.

  • The Hibernate library has been updated from version 3.6 to 6.6. This is an internal technical change to the database layer; the application's functionality and appearance do not change.

Did this answer your question?