Uživatelská tlačítka (custom buttons) nově zvládnou předat cílové aplikaci i rozsáhlý výběr záznamů. Pokud by výsledná adresa překročila povolenou délku, Flexi seznam vybraných záznamů uloží do dočasného úložiště a v adrese předá jen odkaz data-url, přes který si cílová aplikace data sama stáhne. Podporu tohoto způsobu předání musí do svých aplikací zapracovat jejich autoři — bez ní se u rozsáhlého výběru předá odkaz, který aplikace nezpracuje; menší výběry fungují beze změny. Uložená data mají omezenou platnost a lokální dočasné úložiště se promaže při každém startu serveru.

Jednotné měsíční hlášení zaměstnavatele je nově přístupné přes API. Evidenci jmhz-podani-hlav lze číst, exportovat a zakládat v ní nová podání; podání se vždy importuje celé včetně vnořených položek, protože úprava ani smazání již existujícího podání přes API možné není.

Zpracování mezd lze nově řídit přes API bez desktopového klienta. Přibyly evidence vypocet-mzdy pro výpočet jedné mzdy, zruseni-vypoctu-mzdy pro zrušení výpočtu (volitelně i s uživatelskými změnami mzdových složek), vypocet-mezd pro hromadný výpočet mezd za zadaný rok a měsíc a generovani-zavazku-mezd pro následné vygenerování závazků a interních dokladů.

Účtová osnova pro neziskové organizace nově obsahuje nákladový účet 523 Odměny členům orgánů obchodní korporace, zařazený ve výkazu zisku a ztráty na řádek A.III.10. Mzdové náklady. Účet přibývá i v již existujících firmách s neziskovou legislativou, takže odměny volených členů statutárních orgánů (typicky u společenství vlastníků) lze účtovat v souladu s vyhláškou č. 504/2002 Sb.

Účetní závěrkové výkazy (sestavy) je nově možné definovat kompletně i mimo desktopovou aplikaci — přes API přibyly evidence uziv-predpis pro uživatelský předpis řádku sestavy a rozpad-radku pro rozpad řádku sestavy na jednotlivé účty. Uživatelské předpisy lze u vlastních sestav nejen číst, ale i měnit a importovat, rozpad řádků slouží pouze pro čtení.

Endpoint pro vytvoření uživatele (/u) přijímá nově data i v XML a JSON, nejen jako formulářová data nebo parametry v URL. Endpoint /u/{userId} pro editaci uživatele nově rozumí i XML, umí měnit i oprávnění a je tak funkčně shodný s /c/{firma}/uzivatel/update.

V metadatech evidencí se nově i u kolekcí (vazeb) uvádějí příznaky visible, editable a další, stejně jako je tomu u běžných položek.

Načítání salda je rychlejší. Filtr uhrazeno/neuhrazeno se dříve vyhodnocoval nadvakrát a u firem s velkým množstvím nespárovaných položek a párovacích symbolů dokázal výpis salda na dlouho zablokovat; nově se vše spočítá jedním průchodem a saldo se otevře výrazně rychleji.

Název účtu se v Obratové předvaze a ve Stavech účtů nově zobrazuje v jazyce aplikace — například v anglickém prostředí se použije anglický název účtu, a pokud na účtu vyplněný není, zobrazí se původní název. Stejně se názvy účtů chovají i v souvisejících tiskopisech.

Export externích identifikátorů (ExtID) v API u evidencí, které skládají data z více tabulek — například skladova-karta , odberatel nebo dodavatel — je výrazně rychlejší. Při exportu statisíců záznamů se doba zpracování zkrátila řádově. Správně nově funguje také řazení skladových karet podle ceny z ceníku, které dříve pořadí nerespektovalo.

Průvodce hlášením REGZEC nyní při chybějícím nebo neplatném variabilním symbolu neskončí jen chybovou hláškou, ale rovnou otevře konkrétní záznam k doplnění. Pokud pro OSSZ chybí bankovní spojení, otevře se nastavení, a pokud je vyplněné špatně nebo vůbec, otevře se přímo dané bankovní spojení.

Databázové optimalizace. Dotazy ověřující existenci záznamů, jsou nyní rychlejší — namísto procházení a počítání všech vyhovujících řádků stačí najít první záznam. Vlastní databázové funkce (např. fnn, minvalue, compareid) jsou nyní efektivnější a umožňují paralelní zpracování. Zrychlení se projeví napříč celým systémem a zejména nad velkými objemy dat.

Generování UUID dokladů a vyhledávání podle nich je rychlejší.

Při generování závazků z mezd se práce na střediska nově rozdělí i tehdy, když zaměstnanec nemá vyplněné odpracované hodiny — u procentního (stálého) rozdělení se použijí zadaná procenta místo dřívějšího zaúčtování celé částky na výchozí středisko. Pokud má zaměstnanec zadané měsíční rozdělení podle hodin a odpracované hodiny chybí, upozorní na to nově varovná hláška.

Pro evidenci objednávka vydaná je nově k dispozici konfigurovatelná tisková sestava, kterou si můžete sami upravit — stejně jako u faktur, nabídek vydaných nebo objednávek přijatých.

Nově registrovaní zákazníci pracují ve webovém rozhraní rovnou v novém vzhledu.

Heslo osoby se nyní drží jen na hlavičce osoby, ne u jednotlivých nastavení, a propisuje se stejně bez ohledu na to, zda ho zadáte v aplikaci nebo přes API. Dříve se zadané heslo v některých případech ignorovalo nebo se do hlavičky vůbec nepropsalo. Heslo lze nově také smazat vyprázdněním obou polí (přes API prázdnou hodnotou vlastnosti password) a lze zadat už při zakládání nového zaměstnance; uložení záznamu bez zásahu do hesla ho nemění a samotná změna hesla nezakládá nové nastavení osoby.

Import, který přes filtr s akcí delete maže více nastavení téhož záznamu najednou, u osoby končil chybou a u osoby blízké se nastavení fakticky nesmazalo. Nově takový import projde u osob, pracovních poměrů i osob blízkých a časová osa se správně dopočítá — sousední nastavení se prodlouží, takže v platnosti nevznikne díra; u osoby blízké se navíc při importu nově uplatňují stejné kontroly data platnosti jako u osoby a pracovního poměru.

V agendě Pohyby na účtech skončilo kliknutí na tlačítko Zůstatek chybou aplikace, pokud byl vybraný řádek bez vyplněného účtu. Nově je tlačítko v takovém případě nedostupné.

Zadání příliš velkého čísla do číselného pole — například do pole Kurz v agendě Kurzy pro cenotvorbu — končilo pádem s obecnou hláškou o chybě při práci s databází. Kontrola počtu míst nezohledňovala desetinná místa a hodnotu mimo povolený rozsah propustila až do databáze. Nově se zobrazí srozumitelná validační hláška.

Při importu osoby včetně vnořených pracovních poměrů se kontroly pracovního poměru tiše přeskočily a do protokolu se pouze zapsala chyba o neexistujícím nastavení osoby – nastavení totiž v tu chvíli ještě nebylo uloženo v databázi. Nově se použije nastavení z právě importovaných dat, takže validace proběhnou standardně, a případná chybová hláška navíc uvádí, o kterou osobu a k jakému datu jde.

Opravena bezpečnostní slabina na rozhraní /mini-rmi, které v předchozích verzích přestalo respektovat serverový seznam povolených tříd.

Opravena kontrola oprávnění u dávkového administrátorského API při použití prefixu s verzí (/v2/admin/batch).

Opravena bezpečnostní chyba umožňující spustit kód na serveru přes šablonu v URL uživatelského tlačítka. Šablony nově nemohou vytvářet instance tříd určených ke spouštění příkazů; běžné konstrukce šablon zůstávají beze změny.

Na instalacích mimo cloud se zapnutým serverovým přihlašováním bylo možné provést dávkovou administraci přes /admin/batch zcela bez přihlašovacích údajů – požadavek prošel s právy správce instance a útočník si tím mohl založit vlastního administrátora.

Obnova firmy ze zálohy nyní i v navazujících krocích (úklid dat doplňků atd.) pracuje pod neprivilegovanou databázovou rolí dané firmy.

Přílohy se přes ?inline=true zobrazí v prohlížeči jen u typů application/pdf , image/png , image/jpeg , image/gif a image/webp , ostatní se nově vždy stáhnou. Odpovědi s obsahem přílohy navíc posílají restriktivní bezpečnostní hlavičky a přihlašovací cookie nese SameSite=Lax a na HTTPS i Secure — webové integrace na jiné doméně, které se spoléhaly na přenos cookie mezi weby, je nutné upravit.

Dobropis vytvořený funkcí Vytvoř dobropis nerespektoval u typu dokladu volbu Variabilní symbol primárně z čísla objednávky — variabilní symbol se odvodil z vlastního čísla dobropisu ještě před převzetím údajů z dobropisované faktury a už se nepřepočítal. Platné pro desktop i pro akci dobropisuj volanou přes API.

Výpočet mezd volaný přes akci mohl skončit vnitřní chybou v situacích, kdy měl uživatele pouze upozornit — typicky u mzdové složky se záporným základem v obdobích, kde jde jen o varování. Nyní výpočet doběhne a varování se korektně zobrazí; tam, kde jde o skutečnou chybu, výpočet nadále skončí chybou.

Měsíční hlášení zaměstnavatele rozdělené na více dávek se při volbě Otevřít v prohlížeči a exportu do XML otevíralo jako několik samostatných záložek, z nichž každá viděla jen svou dávku — zpětné uložení podání do Flexi tak bylo neúplné. Nyní se všechny dávky jednoho podání předají prohlížeči najednou v jedné záložce a lze je uložit jako jedno kompletní podání.

Na macOS se při práci s kusovníkem opakovaně objevoval chybový dialog s hlášením „column must be valid, was -1“ — vracel se při každém kliknutí do stromu kusovníku a znemožňoval s ním rozumně pracovat. Nyní se chyba už neobjevuje a editace hodnot i ukládání šířek a pořadí sloupců fungují beze změny.

V XML hromadného oznámení pro zdravotní pojišťovnu se PSČ zapisovalo tak, jak bylo zadáno — tedy včetně případných mezer (např. „530 02“), soubor kvůli tomu neprojde kontrolou schématu a pojišťovna ho odmítne. Nyní se mezery z PSČ odstraňují jak u adresy zaměstnavatele přebírané z nastavení firmy, tak u adresy zaměstnance z karty osoby. Starších tiskových výstupů hromadného oznámení ani Přehledu o platbě pojistného se změna netýká.

Opraveno přidávání srážek do již vypočtených mezd — nově se srážky automaticky doplní do vypočtených měsíců bez nutnosti opakovaného zrušení výpočtu. Zlepšena také validace srážek v zamčených obdobích, která nyní kontroluje zamčení pouze v modulu Mzdy a umožňuje upravovat základní vlastnosti srážky i v ostatních uzamčených modulech.

Výpočet kurzového zisku při přecenění cizoměnových zůstatků nově vychází správně — do součtu se za určitých okolností započítaly i doklady mimo zvolené období a kurzový rozdíl pak vyšel v nesprávné výši. Průvodce uzávěrkou navíc nově upozorní hláškou „Nemáte uzavřené minulé období. Vypočtené kurzové rozdíly mohou být v nesprávné výši.“, pokud se má v rámci uzávěrky provést přecenění a některé z předchozích období zůstalo neuzavřené.

Pokud máte ve Windows nastavený nový Outlook, odesílání e-mailů z Flexi nyní funguje včetně příloh.

Na položkách souhrnné faktury vytvořené z obchodního případu chyběly příznaky „kopírovat z dokladu“ u účtů DPH a základních účtů a u členění DPH či kontrolního výkazu. Účty se sice při vzniku faktury dotáhly správně, ale pozdější změna na hlavičce faktury se na položky už nepropsala a hrozilo chybné zaúčtování.

Odpočet zálohového daňového dokladu od konečné faktury s odlišnou sazbou DPH nyní jde provést i tam, kde položky nemají vyplněnou skupinu plnění. Volba skupiny plnění se při odpočtu nabízí vždy — tedy i když je na položkách jediná nebo žádná — a nově je mezi možnostmi také „Jiná skupina“, která umožní odpočíst položky s prázdnou nebo odlišnou skupinou plnění; platí pro práci v aplikaci i přes API.

Doplněk Pokročilé párování plateb u pokladního dokladu hradícího více faktur uváděl v popisu všech rozdělených plateb stále první spárovanou fakturu. Popis nyní odpovídá dokladu, který platba skutečně hradí; popis zadaný uživatelem nebo importem zůstává zachovaný.

Vyskladnění zboží s evidovanou šarží nebo expirací — například při inventurní korekci — už nekončí chybou o nepovoleném záporném stavu skladu v situacích, kdy je zboží fyzicky skladem; do dostupného množství konkrétní šarže či expirace se již nezapočítávají rezervace odběratelů, které mají vlastní kontrolu. Zároveň jsme opravili výpočet stavu na skladě u položek se záporným množstvím, takže dostupné množství nyní odpovídá skutečnosti.

Při vytváření výdejky z objednávky přijaté se nejstarší dostupná expirace předvyplňuje spolehlivěji: když nejstarší expirace na požadované množství nestačí, nabídne se další dostupná místo toho, aby pole zůstalo prázdné, a zohledňuje se rezervace navázaná na zdrojovou položku objednávky, takže si objednávka neblokuje vlastní realizaci. U více stejných položek na dokladu se navíc hlídá i množství již vybrané na téže expiraci; předvyplněné množství k realizaci se přitom nemění.

Při hromadné objednávce vytvářené z uživatelského dotazu se u ceníkových položek s nastaveným balením nabízelo nulové množství místo hodnoty spočítané dotazem, a objednávku tak nebylo možné použít. Nově se i u těchto položek předvyplní správné množství z dotazu; objednávání ze zdrojových obchodních položek se zároveň nemění a dál pracuje s rozpadem podle balení.

Do hromadného oznámení na zdravotní pojišťovnu se nyní správně nabídnou i zaměstnanci, kteří u vás někdy v minulosti již pracovní poměr měli — dříve stačil jakýkoli dřívější odvod pojistného a takový zaměstnanec se v oznámení neobjevil vůbec. Přihlášení se nenabídne pouze tehdy, když zaměstnanci bezprostředně před začátkem nového poměru běžel jiný — navazující nebo souběžný — poměr, ze kterého pojištění už trvá.

Při vytváření opravného měsíčního hlášení skončilo označení pracovního poměru ke stornu chybou, že individualizovaný formulář typu storno smí obsahovat pouze hlavičku, a hlášení nebylo možné dokončit. Nově se u pracovních poměrů určených ke stornu individualizovaná část vůbec nenačítá ani nevyplňuje a hlášení se vytvoří správně.

Vytvoření příjemky z přijaté objednávky s položkou, která má kusovník a jejíž komponenta chybí na skladě, končilo chybou aplikace. Příčinou bylo, že objednávka na doobjednání komponent, kterou systém v tomto případě zakládá automaticky, se otevírala a kontrolovala pravidly příjemky. Nově se pro každý nově vzniklý doklad použijí pravidla odpovídající jeho typu a realizace objednávky do příjemky proběhne bez chyby.

Při párování úhrad k faktuře v cizí měně mohl vzniknout nesmyslně vysoký kurzový rozdíl, pokud byla úhrada napárována mimo pořadí podle data zaúčtování — typicky zápočet s dřívějším datem zaúčtování spárovaný až po pozdějších úhradách. Nyní se zbytkový kurz faktury počítá ze stejné množiny úhrad v korunách i v měně, takže kurzový rozdíl vychází správně bez ohledu na pořadí párování.

Měl-li uložený filtr podobu, kterou filtrovací dialog neumí zobrazit (například podmínku „nebo“ mezi dvěma různými poli), skončilo jeho otevření nebo použití z oblíbených filtrů chybou a dialog spadl. Nyní se v takovém případě zobrazí srozumitelné varování o nepodporovaném formátu uloženého filtru, filtr se neaplikuje a s dialogem lze dál normálně pracovat.

U dohody o provedení práce a u zaměstnání malého rozsahu se v Jednotném měsíčním hlášení zaměstnavatele u odloženého příjmu již nevyžaduje znak „P“ na druhé pozici kódu ELDP a nevykazuje se ELDP část hlášení. Podle Všeobecných zásad pro vyplňování ELDP se totiž příjem zúčtovaný po skončení takového vztahu považuje za příjem měsíce, ve kterém vztah skončil.

Export evidence do formátu XLS a XLSX přes API u evidencí s vazbami (např. ceník) končil chybou. Vazba je nyní v sešitu zapsaná jako odkaz na záznam ve stejné podobě jako v exportu XML nebo CSV (např. code:ZBOZI), popisný text odkazovaného záznamu se už neexportuje.

Zesílena bezpečnost reportů. Přísnější kontrola výrazů v tiskových sestavách, které nově nesmějí přistupovat k interním vlastnostem objektů zneužitelným ke spuštění cizího kódu. Zdroj zadaný v reportu textovou lokací — obrázek, podreport, šablona stylů nebo překlady — se nově načte jen přes HTTP a HTTPS a přístup na interní a lokální adresy je odmítnutý. Obrázky a podreporty z veřejných adres se načítají dál.

Aktualizovány knihovny třetích stran, u kterých byly hlášené bezpečnostní zranitelnosti — mimo jiné komponenty pro zpracování XML a tiskových sestav, ovladač databáze PostgreSQL a kryptografická knihovna.

Schémata pro Jednotné měsíční hlášení zaměstnavatele vycházejí z verze 1.4.3.4 vydané ČSSZ, včetně tří nově přidaných formulářů (pěstoun, mezinárodní pronájem pracovní síly a OZP/TPP). Kontrola generovaného podání tak odpovídá aktuálnímu datovému rozhraní ČSSZ.

Schéma pro elektronické podání REGZEC vychází z verze ČSSZ 1.4.0.3. Kontrola údajů je nově přísnější — položka s prázdnou hodnotou podáním neprojde a je nutné ji před odesláním doplnit.