Novinky srpen 2026

31. 8. 2026 (ZENDESK 10391, YouTrack SUPP-10978) — Pracovníka s výplatou složenkou už jde smazat

Když měl pracovník nastavenou výplatu složenkou, nešel smazat vůbec — mazání skončilo hláškou „Nelze smazat 'Person Address', protože existuje '1' záznamů v 'Osoby'“ a opakování nepomohlo. Důvodem byla adresa pro doručení složenky: mazání ji chtělo odstranit dřív, než zmizel samotný pracovník, a protože na ni byla navázaná jeho výplata, systém si to sám zablokoval.

Nově se tato vazba při mazání pracovníka uvolní jako první a smazání proběhne standardně. Ochrana samotné adresy zůstává: pokud pracovníka necháváte a chcete smazat jen adresu, na kterou se posílá složenka, systém to dál nedovolí — nejdřív je potřeba změnit způsob výplaty.

31. 8. 2026 (ZENDESK 10390, YouTrack SUPP-10977) — Záloha má v názvu středisko podle platné smlouvy

Když si pracovník požádal v mobilní aplikaci o zálohu, založila se událost s názvem „Záloha částka Kč pro jméno (středisko)“. Středisko se ale bralo z poslední směny z objednávky bez ohledu na to, jak je stará. Kdo přešel na novou smlouvu a přes objednávky se už neplánuje, měl v závorce středisko dávno skončené práce — například středisko ze smlouvy ukončené loni v prosinci, i když od srpna běží hlavní pracovní poměr jinde.

Nově se středisko z objednávky bere jen z období platné smlouvy; když v něm žádná objednávka není, doplní se středisko přímo ze smlouvy. Pracovníků, kteří aktuálně jezdí na objednávky, se změna nedotýká — těm se dál ukazuje středisko, kde reálně pracují. Již založené otevřené žádosti jsme srovnali.

31. 8. 2026 (ZENDESK 10390, YouTrack SUPP-10977) — V historii přihlášení je vidět platforma a verze mobilní aplikace

U přihlášení pracovníka do mobilní aplikace se do historie zapisovala platforma a verze aplikace jen tehdy, když přihlášení šlo přes přihlašovací bránu. Při řešení dotazu „jakou verzi ten člověk vlastně má?“ tak často nebylo z čeho vyjít.

Nově se platforma (iOS / Android / web) a verze aplikace berou i z údajů, které aplikace posílá s každým požadavkem, takže je historie přihlášení má vždy. Token pracovníka platí měsíc a jednou denně se prodlužuje — nově se zapisuje i toto prodloužení, aby bylo vidět, s čím pracovník chodí teď, ne jen při posledním skutečném přihlášení.

31. 8. 2026 (YouTrack WAS-1915, ZENDESK 10380) — Změna bankovního spojení z aplikace je jeden úkol ke schválení

Když si pracovník v mobilní aplikaci změnil bankovní spojení, přišly vám ke schválení tři samostatné úkoly — zvlášť předčíslí, zvlášť číslo účtu, zvlášť kód banky. Přitom jde o jednu věc: účet se v kartě pracovníka vede jako jeden údaj a po částech ho nelze ani zapsat.

Nově dorazí jeden úkol „Bankovní spojení" a v něm celý účet: v přehledu změny vidíte řádek za předčíslí, číslo účtu, kód banky i IBAN, se starou a novou hodnotou vedle sebe. Nezměněná pole jsou v přehledu šedá, abyste hned viděli, co se vlastně mění. Schválit nebo zamítnout stačí jednou — a napsaný důvod zamítnutí uvidí pracovník v aplikaci u všech polí účtu, takže ví, co má opravit.

Zároveň se nově propíše i zrušení předčíslí nebo IBANu: dřív šlo hodnotu jen přepsat, vymazání se do karty nepromítlo.

31. 8. 2026 (ZENDESK 10386, YouTrack SUPP-10973) — Generování JMHZ pohlídá výběr období před rokem 2026

JMHZ (Jednotné měsíční hlášení zaměstnavatele) se podává až od období leden 2026. V přehledu mezd ale šlo generování hlášení omylem spustit i nad řádkem staršího roku — řádky např. za květen 2025 a květen 2026 se v seznamu liší jen rokem — a systém pak odpověděl matoucí chybou, že pro období neexistuje řádné podání se známým identifikátorem podání.

Nově generování nad obdobím před lednem 2026 skončí rovnou srozumitelnou hláškou „JMHZ reporting starts with period 01/2026 …“, která vyzve ke kontrole roku vybraného řádku. Na správná období nemá změna žádný vliv.

31. 8. 2026 (ZENDESK 10385, YouTrack SUPP-10972) — Mobilní aplikace na iPhonu už nekreslí přes stavový řádek

Na iPhonu se horní řádek obrazovky — přepínač Kalendář/Seznam, tlačítko filtru a obnovení — kreslil přes stavový řádek systému, tedy přes hodiny, signál, Wi-Fi a baterii. Obsah aplikace a ikony telefonu se překrývaly, hůř se četly i mačkaly. Na Androidu byla aplikace v pořádku, protože tam okno pod stavový řádek odsazuje sám systém.

Nově si horní odsazení hlídá společná kostra obrazovek aplikace, takže obsah začíná až pod stavovým řádkem. Týká se to nejen úvodní obrazovky s kalendářem, ale i ostatních obrazovek aplikace včetně těch s titulkem v hlavičce. Spodní navigační lišta zůstává beze změny.

Oprava je součástí nové verze mobilní aplikace — projeví se po jejím vydání v App Store a Google Play a aktualizaci v telefonu.

31. 8. 2026 (ZENDESK 10383, YouTrack SUPP-10970) — Oblíbené brigády jsou v nabídce směn nahoře

Pracovník si v mobilní aplikaci může u kombinace provozovna + pozice zapnout srdíčko a mít ji mezi oblíbenými. V nabídce směn se ale oblíbenost při řazení vůbec nebrala v úvahu — směny se řadily jen podle času začátku, takže oblíbená brigáda skončila podle náhody uprostřed seznamu nebo úplně dole a musela se hledat mezi ostatními.

Nově se v nabídce směn oblíbené řadí na začátek dne — jak v seznamu pod kalendářem, tak v seznamu nabídky. Chronologie zůstává hlavním klíčem: seznam jde dál po dnech od nejbližšího a uvnitř každého dne jsou nahoře nejprve vlastní směny pracovníka, pod nimi oblíbené volné a teprve pak ostatní. Vlastní volba řazení („Seřadit“ podle data nebo typu práce) se nemění a filtr „Pouze oblíbené“ funguje dál beze změny.

31. 8. 2026 (ZENDESK 10380, YouTrack SUPP-10967) — Zamítnutí změny čísla účtu zamítne i předčíslí a kód banky

Když si pracovník v mobilní aplikaci změní bankovní spojení, založí se ke schválení samostatná žádost za každé vyplněné pole — předčíslí, číslo účtu a kód banky. Schválení už od 10. 8. 2026 vyřídí celý účet najednou, zamítnutí ale ne: kdo zamítl špatně zadané číslo účtu, musel zbylé dva úkoly zamítat ještě ručně po jednom.

Nově se účet vyřizuje jako celek v obou směrech. Zamítnutí kteréhokoli z polí účtu — předčíslí, čísla účtu, kódu banky i IBANu — zamítne i ostatní nevyřízené žádosti k účtu téhož pracovníka a uzavře jejich úkoly. Důvod zamítnutí, který napišete, se propisuje ke všem těmto polím, takže pracovník v aplikaci vidí u každého z nich, proč změna neprošla, a může účet rovnou zadat znovu. Ostatních údajů profilu (jméno, adresa, kontakty) se to netýká — ty se schvalují i zamítají dál po jednom.

31. 8. 2026 (ZENDESK 10376, YouTrack SUPP-10963) — www.student.cz: přihlášený pracovník rovnou pokračuje v mobilní aplikaci

Pracovník, který se přihlásil na www.student.cz, skončil ve starých eBrigádách — v části webu, kterou nahradila aplikace Agentura STUDENT. Do aplikace se pak musel přihlašovat ještě jednou.

Nově web po zadání jména a hesla pozná, že jde o pracovníka, a rovnou ho přihlášeného přepne do aplikace na app.student.cz. Druhé zadávání hesla odpadá, přihlašovací údaje zůstávají stejné. Přihlášení se předává týmž zabezpečeným způsobem jako z přihlašovací stránky login.stafio.cz — v části adresy, kterou prohlížeč neposílá na server, takže nekončí v žádném logu.

Inzerentů se změna netýká: kontaktní osoby firem i správci portálu zůstávají po přihlášení na www.student.cz jako dosud. Staré eBrigády se neruší, jen do nich pracovníka přihlášení už nezavede.

31. 8. 2026 (ZENDESK 10381, YouTrack SUPP-10968) — Schválená změna čísla účtu z aplikace platí ode dneska, ne zpětně

Pracovník si v mobilní aplikaci změnil číslo účtu, agentura změnu schválila — a nový účet se v kartě pracovníka objevil s platností od data, odkdy platil ten původní. Vypadalo to, jako by na nový účet chtěly odejít i mzdy za měsíce, které už byly vyplacené na staré číslo.

Bankovní spojení se u pracovníka vede jako historie: každý účet má svoji platnost od–do, aby bylo dohledatelné, kam která mzda odešla. Schválení žádosti z aplikace ale zapisovalo nový účet do už existujícího záznamu, takže přepisovalo i jeho platnost. Odešlých převodních příkazů se to netýká — ty si číslo účtu nesou v sobě — ale sestavy a přehledy, které účet dohledávají podle mzdového období, ukazovaly nový účet i u starších měsíců.

Nově schválení změny účtu původní záznam uzavře ke včerejšku a nový účet založí jako nový záznam s platností od dneška. Historie zůstává pravdivá a nejbližší výplata už jde na nové číslo. Když se účet opravuje ještě týž den, kdy záznam vznikl, nebo se mění jen doprovodné údaje, žádný nový záznam nevzniká.

31. 8. 2026 (ZENDESK 10378, YouTrack SUPP-10965) — Exekuce na běžné výživné: srážka zaúčtovaná do dalšího měsíce už nerozhodí ještě otevřený předchozí měsíc

U pracovníka se souběhem exekucí na výživné a průběžných záloh se koncem srpna znovu objevila vratka běžného výživného a vygenerovaný převodní příkaz nabídl k výplatě jinou částku než hotovostní výplata (o 748 Kč méně). Šlo o novou, dosud skrytou vadu ze stejné rodiny jako chyba opravená 11. 8. 2026 — srpnová oprava funguje správně a měsíce se od ní srážejí přesně na měsíční nárok. Tato druhá vada se mohla projevit teprve po ní, a jen ve zvláštní situaci: když je otevřených více mzdových měsíců najednou a splátka běžného výživného se zaúčtuje do toho novějšího z nich.

Výpočet „kolik má být z běžného výživného sraženo do konce daného měsíce“ totiž od měsíčního nároku odečítal všechny srážky v otevřených měsících — tedy i srážku patřící měsíci následujícímu. Jakmile příkaz z 24. 8. zaúčtoval srpnovou splátku výživného do srpna a červenec byl stále otevřený, začal výpočet považovat červenec za „přeplacený“ a nabízel vratku; hotovostní výplata a převodní příkaz pak tytéž peníze rozpočítávaly každý jinak a rozdíl se každým dalším příkazem obnovoval.

Nově se do vyhodnocení měsíce počítají jen srážky zaúčtované do tohoto měsíce a měsíců předchozích. Vratky z tohoto mechanismu tím mizí, hotovostní výplata i převodní příkaz se srovnají a po zaúčtování srážek už výpočet nenabízí žádné další korekce. U dotčeného pracovníka proběhne při nejbližší výplatě jednorázové dorovnání srážek na správnou výši měsíce (běžné výživné se doplní do plného měsíčního nároku); data v evidenci byla konzistentní, žádná zpětná oprava nebyla potřeba.

29. 8. 2026 (ZENDESK 10379, YouTrack SUPP-10966) — Naplánované serverové úlohy se už nespustí dvakrát

Kontrolní SMS „Blahovec.NET je OK“ dorazila dvakrát a vzniklo podezření, že běží aplikační server dvakrát. Neběžel — obě zprávy poslala jedna a tatáž naplánovaná úloha, která se ale spustila dvakrát.

Aplikační server si naplánované úlohy rozebírá mezi několik souběžných vláken. Označení úlohy jako „běží“ nebylo proti souběhu ošetřené: dvě vlákna si mohla vybrat tutéž úlohu a to pomalejší z nich si po chvilce čekání nezkontrolovalo, že ji mezitím zabralo to rychlejší. Úloha se pak provedla dvakrát a pokud posílala zprávu, přišla dvakrát i ta.

Nově si vlákno úlohu při výběru zamkne a druhé vlákno rovnou přeskočí na další úlohu ve frontě — každou naplánovanou úlohu tak provede právě jedno vlákno. Rozesílání je navíc o něco svižnější, protože se čeká méně.

Chyba se projevovala jen tam, kde je souběžných vláken víc než jedno, a byla nahodilá — postihla přibližně jednu úlohu ze sta. Zdvojené zprávy nezpůsobily žádnou nesprávnost v datech, jen dorazily dvakrát.

28. 8. 2026 (ZENDESK 10373, YouTrack SUPP-10960) — Žádost o zálohu z aplikace: v přehledu událostí je nově vidět firma i u pracovníků bez naplánovaných směn

Když pracovník požádá o zálohu z mobilní aplikace, založí se v přehledu XRM → Události aktivita s názvem „Záloha 2 000 Kč pro Jan Novák (Lidl balení)“ — v závorce je firma, ke které pracovník patří. U části žádostí zůstávala závorka prázdná, takže na první pohled nebylo poznat, koho se záloha týká.

Firma se totiž brala výhradně z poslední naplánované směny na objednávce. Pracovníci, kteří se přes objednávky a směny neplánují — typicky lidé na HPP nebo DPČ přiřazení ke klientovi jen smlouvou — žádnou takovou směnu nemají, a závorka proto zůstala prázdná.

Nově se v takovém případě doplní středisko z platné smlouvy pracovníka. Pořadí zůstává zachované: pokud pracovník naplánovanou směnu má, bere se firma z ní jako dosud, takže dosavadní názvy se nemění.

Název aktivity vzniká v okamžiku založení žádosti, oprava tedy nepřepisuje již existující záznamy. Otevřené žádosti na termín 28. 8. 2026 jsme doplnili zpětně, starší již vyřízené žádosti zůstávají beze změny.

28. 8. 2026 (ZENDESK 10372, YouTrack SUPP-10959) — Registrace zaměstnance: vyjmutý řádek už nezablokuje zápis přidělených identifikátorů

U dávky „Registrace zaměstnance“ (REGZEC) s pěti pracovníky ohlásila ČSSZ telefonicky chybu v jednom řádku. Účetní vadný řádek z dávky vyjmula (akce „Vyjmout z dávky“) a poslala pro dotyčnou osobu novou přihlášku — to je správný postup. Když ale poté dorazila odpověď ČSSZ k původní dávce, její zpracování spadlo: odpověď obsahovala i položku vyjmutého řádku (bez přidělených identifikátorů) a Stafio k ní v dávce nenašlo protějšek. Celé zpracování se tím zastavilo, takže ani zbylé čtyři řádky nedostaly přidělené ID pojistného vztahu a IK MPSV — smlouvy vypadaly přihlášené, ale identifikátory chyběly a měsíční hlášení by nemělo na co navázat.

Nově se položka odpovědi, která nenese žádné identifikátory a nemá v dávce protějšek (typicky právě vyjmutý vadný řádek), při zpracování přeskočí a zbytek dávky se normálně dokončí. Položka s identifikátory, ke které protějšek chybí, dál končí chybou — to je pojistka proti nahrání protokolu z cizí dávky a zůstává beze změny.

Identifikátory dotčené dávky jsme doplnili ze stažené odpovědi dodatečně, ručně není potřeba nic přepisovat.

27. 8. 2026 (ZENDESK 10366, YouTrack SUPP-10953) — Přehled směn v e-mailu je nově přehledná tabulka

E-mail „Směny na následující dny“ vypisoval směny jako souvislý text, ve kterém byly datum, pracoviště a čas oddělené jen mezerami. Tyto mezery ale e-mailový program slučuje do jediné, takže se sloupce nikde nezarovnaly a všechny řádky splývaly do jednoho odstavce. Na telefonu se v tom orientovalo obzvlášť špatně.

Nově je přehled tabulka: vlevo den a datum, vpravo pracoviště a pod ním směna s časem. Potvrzená směna je označená modrým proužkem, zrušená oranžovým, takže je na první pohled vidět, o který případ jde — dosud byly oba stavy stejný černý text. Sloupec s datem se nezalomí ani na úzkém displeji, kde si e-mailový program zvětší písmo.

Dny, na které pracovník žádnou směnu nemá, se už nevypisují vůbec. Přehled tak obsahuje jen dny, kdy se něco děje.

Změna se týká pouze e-mailu; obsah SMS s přehledem směn zůstává beze změny.

27. 8. 2026 (ZENDESK 10371, YouTrack SUPP-10958) — Mobilní aplikace v prohlížeči se u části uživatelů vůbec nenačetla

Pracovnice si nechala poslat odkaz pro nastavení nového hesla, na telefonu na něj klikla, ale stránka aplikace se ani po dvou minutách nenačetla — zůstala stát na úvodním „Načítám aplikaci…“. Netýkalo se to jen hesla: stejně dopadlo jakékoli otevření aplikace v prohlížeči, ať už z odkazu v e-mailu, nebo přímo z adresy.

Aplikace si při startu bere jednu pomocnou knihovnu (zajišťuje živé zprávy a upozornění) ze serveru jejího výrobce. Prohlížeč ji musí zpracovat dřív než samotnou aplikaci — když se ten cizí server neozval, čekal donekonečna a aplikace se nespustila vůbec. Žádná lhůta ani náhradní řešení tam nebyly. Důvodů, proč se server neozývá, je víc: blokuje ho mobilní operátor nebo firemní Wi-Fi, blokování reklam v telefonu, nebo měl výpadek. Podle statistik odeslaných e-mailů na to narazila menší část pracovníků, na iPhonech i na Androidech.

Nově se tato knihovna posílá přímo z adresy aplikace, start už tedy na žádném cizím serveru nezávisí. Týká se to pouze aplikace otevřené v prohlížeči — nainstalovaná aplikace z App Store a Google Play si knihovnu takto nestahuje a tímto nikdy netrpěla.

27. 8. 2026 (ZENDESK 10369, YouTrack SUPP-10956) — Vlastní SMS brána: táž SMS už neodejde dvakrát

Telefon s vlastní SMS bránou Stafia odesílal část zpráv dvakrát — příjemce dostal stejnou nabídku směny dvěma SMS po sobě, obvykle s odstupem půl minuty. V přehledu odeslaných SMS ve Stafiu to vidět nebylo: druhé odeslání se zapíše na tentýž řádek, takže zdvojení se dalo poznat jen z logu v telefonu. V zaznamenaném úseku provozu šlo o 32 zpráv ze 113.

Příčina byla v aplikaci brány a měla dvě části. Průchod frontou spouští jak samotná brána, tak záchranný proces, který ji po uspání systémem oživuje — oba přitom mohly běžet současně a jeden o rozdělané práci druhého nevěděl. Aplikace se sice u každé zprávy ptá, jestli ji už neposlala, ale ptala se dřív, než uplynul nastavený rozestup mezi zprávami; v tom okně, dlouhém klidně půl minuty, stihl druhý průchod tutéž zprávu odeslat.

Nově se oba průchody nemohou překrývat a kontrola „tuhle zprávu už jsem poslal" se navíc opakuje těsně před odesláním. Změna je součástí aplikace brány, projeví se tedy až po její aktualizaci v telefonu (verze 1.1.2).

27. 8. 2026 (ZENDESK 10369, YouTrack SUPP-10956) — Vlastní SMS brána: telefon si bere jen tolik zpráv, kolik jich stihne odeslat

Telefon s vlastní SMS bránou Stafia si z fronty vyzvedne dávku zpráv a rozesílá je s nastaveným rozestupem, aby odesílání nevypadalo jako hromadná rozesílka. Stafio přitom vydanou zprávu drží jen po omezenou dobu (ve výchozím nastavení pět minut) — když se telefon do té doby neozve, vrátí ji do fronty a nabídne znovu, aby se zpráva neztratila, kdyby se telefon vybil nebo aplikace spadla.

Velikost dávky se ale tímto časovým limitem neřídila: telefon si bral až dvacet zpráv, a při rozestupu půl minuty mu jejich rozeslání trvalo přes deset minut. Na druhou polovinu dávky už lhůta nestačila a Stafio ji vydávalo znovu. Telefon poznal, že tyto zprávy už zpracovává, a druhou kopii zahodil — jenže tím se zahodilo i místo v dávce, takže každé další vyzvednutí odbavilo méně zpráv, než mohlo. U jednoho telefonu se takhle 27. 8. vydávalo opakovaně 32 zpráv ze 77 a fronta se vyprázdňovala výrazně pomaleji.

Nově si telefon bere jen tolik zpráv, kolik jich při nastaveném rozestupu stihne odeslat a nahlásit, než jim lhůta vyprší. Zprávy se přestanou vydávat opakovaně a fronta se odbavuje plynule. Na rychlost odesílání ani na hodinový strop počtu zpráv to vliv nemá — mění se jen velikost jedné dávky. Změna je součástí aplikace brány, projeví se tedy až po její aktualizaci v telefonu (verze 1.1.1).

27. 8. 2026 (ZENDESK 10368, YouTrack SUPP-10955) — Odkaz pro nastavení nového hesla dorazí i tam, kde stejný e-mail používá víc účtů

Pracovník požádal v mobilní aplikaci o nové heslo, aplikace potvrdila odeslání, ale žádný e-mail nedorazil — a v odeslané poště po něm nezůstala ani stopa. Stávalo se to u e-mailových adres, které jsou v systému vedené na více záznamech najednou.

Přihlašovací jméno se při žádosti o nové heslo hledá nejdřív mezi uživateli agentury a teprve potom mezi pracovníky. Uživatele šlo najít i podle e-mailu a ten nikde jedinečný není — stejná adresa bývá zapsaná i u služebních účtů (aplikační server, webová služba, robot). Když hledání skončilo u takového služebního účtu, směřoval se e-mail na osobu, pod kterou účet běží; ta žádnou adresu vyplněnou nemá, odesílání proto skončilo chybou „Zvolte aspoň 1 příjemce“ a zpráva vůbec nevznikla. Žadatel přesto viděl obvyklé potvrzení o odeslání, protože to je záměrně stejné ve všech případech, aby z něj nešlo zjistit, které adresy jsou registrované.

Nově se služební účty do hledání neberou vůbec — odkaz na změnu hesla pro ně nemá smysl a jejich e-mail navíc často patří někomu jinému. Zároveň platí, že když stejné přihlašovací jméno nebo e-mail používá víc pracovníků (typicky starý neaktivní záznam a vedle něj nový), odkaz dostane ten aktivní; dřív o tom rozhodovala náhoda a nové heslo se tak mohlo nastavit na záznam, kterým se do aplikace přihlásit nelze.

27. 8. 2026 (ZENDESK 10343, YouTrack SUPP-10930) — Dokument stažený z Word šablony už Word neoznačí za poškozený

Při stažení dokumentu z tiskové šablony se ve Wordu pokaždé otevřelo okno „Aplikace Word zjistila v dokumentu … nečitelný obsah. Chcete obsah tohoto dokumentu obnovit?“ a dokument se dal otevřít až po potvrzení tlačítka Ano. Týkalo se to tlačítka Stáhnout v okně Tisk, tedy stažení dokumentu v původním formátu Wordu. Tisk do PDF, odeslání k elektronickému podpisu ani tisk více záznamů najednou postižené nebyly, protože ty vytvářejí rovnou PDF.

Příčina byla na naší straně, ne v nastavení šablony. Novější verze Wordu si do dokumentu zapisují seznam svých rozšíření, která smí program při čtení přeskočit. Generátor sestav tento seznam ze šablony převzal beze změny, sám ale zná jen jeho starší část — ve vytvořeném dokumentu tak zůstal odkaz na rozšíření, které v souboru není nijak popsané, a Word takový dokument považuje za poškozený. Rozhodovalo přitom jen to, jak novým Wordem byla šablona naposledy uložena: u šablon uložených Wordem z roku 2023 a novějším k tomu docházelo vždy, u starších vůbec.

Nově se do vytvořeného dokumentu zapíše jen to, čemu generátor rozumí, a to jak v hlavním textu, tak v záhlaví a zápatí. Dokumenty se otevírají rovnou, bez dialogu a bez opravy; jejich obsah ani vzhled se nijak nemění. Soubory stažené před opravou zůstávají poškozené — stačí je stáhnout znovu.

28. 8. 2026 (ZENDESK 9981, YouTrack SUPP-10565) — Dva sloupce „Na dobu určitou do" v přehledu Smluv jsou nově rozlišené

Zákazníci s napojením na PAMICA viděli v přehledu Smlouvy (a v panelu Smlouvy na kartě pracovníka) dva sloupce se stejným názvem Na dobu určitou do — nedalo se poznat, který je který. Jeden přitom nese konec doby určité sjednaný v původní smlouvě (ten se nikdy nemění) a druhý aktuální konec platnosti — původní datum posunuté dodatky nebo zkrácené předčasným ukončením.

První z nich se nově jmenuje Původní platnost do, shodně s pojmenováním na kartě smlouvy. Sloupec Na dobu určitou do tak nyní vždy ukazuje aktuální (skutečný) konec platnosti smlouvy.

27. 8. 2026 (ZENDESK 9981, YouTrack SUPP-10565) — Přihláška, kterou ČSSZ přijala bez ID pojistného vztahu, je nově vidět

Odpověď ČSSZ na přihlášku zaměstnance vrací u každého řádku trojici rodné číslo; OIČ; ID pojistného vztahu. Ojediněle se stane, že ČSSZ celé podání označí jako přijaté a bez chyb, ale u řádku trojici nevyplní — buď je celá prázdná, nebo obsahuje jen rodné číslo a OIČ. Pojistný vztah v registru ČSSZ pak nevznikne, Stafio nemá jaké ID uložit a smlouva zůstane bez ID pojistného vztahu.

Dosud se to nijak neprojevilo: podání se v přehledu tvářilo bezchybně a chybějící přihlášení se ukázalo až o měsíce později, typicky když na smlouvu selhala oprava údajů nebo měsíční hlášení. U jedné agentury takto „tiše" neprošlo 9 ze 408 přijatých řádků.

Nově se takový řádek označí jako nepřijatý a doplní se u něj vysvětlení s doporučením ověřit pracovníka na ePortálu ČSSZ a podat novou přihlášku. Vidíte to ve sloupcích ČSSZ přijato a Zpracování ČSSZ — jak v Detailu dat u podání, tak v akordeonu JMHZ na kartě smlouvy.

27. 8. 2026 (ZENDESK 9981, YouTrack SUPP-10565) — Pravděpodobný výdělek se uplatní i u zaměstnance s nulovým průměrem

ČSSZ zneplatňuje odhlášku, ve které je průměrný čistý měsíční výdělek nulový, a Stafio proto takové podání předem zablokuje s doporučením nastavit parametr daní ONZ_PROBABLE_NET_WAGE — pravděpodobný výdělek podle § 355 zákoníku práce.

Jenže parametr se použil jen tehdy, když v rozhodném období nebyla vůbec žádná zúčtovaná pojištěná mzda. Pokud mzda zúčtovaná byla, ale průměr z ní vyšel nula (například měsíc s nulovým čistým výdělkem), vrátil výpočet nulu a podání se zablokovalo — a to i u agentury, která parametr nastavený měla. Hláška odkazovala na nastavení, které bylo hotové a nepoužilo se, takže se z toho nedalo dostat.

Nově se pravděpodobný výdělek uplatní i tehdy, když vypočtený průměr vyjde nula. Odhlášky a opravy u takových zaměstnanců projdou s hodnotou z parametru. Kdo má parametr na nule, pro toho se nic nemění — podání se stále zablokuje stejnou hláškou jako dosud.

27. 8. 2026 (ZENDESK 9981, YouTrack SUPP-10565) — Opravné podání REGZEC už neposílá údaje o skončení u dohod, které teprve skončí

ČSSZ vracela část řádků opravných podání (REGZEC akce 4) s hláškou „027 — Pokud není vyplněno datum skončení zaměstnání, pak atribut podpora v nezaměstnanosti … nesmí být vyplněn.“ Odmítnuté řádky měly jedno společné: šlo o dohody sjednané na dobu určitou, jejichž konec teprve nastane.

U takové dohody je v systému uložený plánovaný konec. Datum skončení se do opravy záměrně neposílá, dokud opravdu nenastane — budoucí datum by ČSSZ odmítla jinou kontrolou. Blok „podpora v nezaměstnanosti“ (druh zaměstnání, doba důchodového pojištění, průměrný čistý výdělek, důvod ukončení) se ale přikládal, kdykoli bylo datum skončení vyplněné, tedy i u plánovaného konce v budoucnu. Podání pak neslo údaje o skončení bez samotného data skončení, což je právě kombinace, kterou kontrola 027 zakazuje.

Nově se oba údaje posílají společně: blok podpory v nezaměstnanosti se přikládá jen tehdy, když se posílá i datum skončení, tedy u zaměstnání, které už skutečně skončilo. U skutečně ukončených smluv se nic nemění.

27. 8. 2026 (ZENDESK 9981, YouTrack SUPP-10565) — Druh výdělečné činnosti nabízí i nestandardní druhy (společník, prokurista, likvidátor)

Pole Druh výdělečné činnosti na kartě smlouvy dosud nabízelo jen kódy odpovídající typu smlouvy — u pracovního poměru 1–9, u dohody o pracovní činnosti A–J, u dohody o provedení práce T–Z a ZA–ZC. Číselník ČSSZ ale zná i skupinu nestandardních pracovněprávních vztahů, které se ve Stafiu vedou pod běžným typem smlouvy: S společník, jednatel, komanditista, ředitel obecně prospěšné společnosti, dále K dobrovolný pracovník pečovatelské služby, M pěstoun a osoba pečující, N smluvní zaměstnanec, O člen družstva, P prokurista, Q člen kolektivního orgánu právnické osoby a R likvidátor. Tyto kódy nešlo v nabídce vybrat, takže u takového pracovníka nešlo evidenci srovnat s registrem ČSSZ.

Nabídka je nově o celou tuto skupinu rozšířená. Hodnota se má nastavovat podle toho, co má u pracovníka zapsaného ČSSZ — kód přiděluje přihláška a v registru je trvalý. Pozor: přechod mezi běžným a nestandardním druhem činnosti nelze provést opravným podáním, ČSSZ jej v opravě nepřipouští.

27. 8. 2026 (ZENDESK 10365, YouTrack SUPP-10952) — Export přehledu Směny už nekončí chybou a vrací přesně to, co vidíte na obrazovce

Export přehledu Objednávky → Směny do souboru končil chybou. Uživatel si vyfiltroval období, zvolil sloupce, spustil export — a místo souboru mu přišlo upozornění „Chyba v úloze na pozadí — column s.labels2_desc_array does not exist“. Export selhal vždy, když byl mezi zvolenými sloupci Štítky, Hodnocení, Schválil nebo Datum schválení; ty jsou přitom v přehledu zobrazené ve výchozím nastavení, takže export nešel spustit prakticky vůbec.

Přehled Směny se na obrazovce plní jinou cestou než jeho export do souboru. Export si sestavuje vlastní dotaz podle seznamu sloupců přehledu a čtyři z nich v tomto seznamu chyběly — u nich pak dotaz odkazoval na sloupec, který v databázi neexistuje, a celá úloha spadla. Nově jsou všechny čtyři sloupce doplněné, exportují se se stejným obsahem, jaký je vidět v přehledu, a úloha doběhne.

Při opravě se zároveň srovnalo, kolik řádků export vrací. Přehled na obrazovce zobrazuje jen směny těch středisek, ke kterým má přihlášený uživatel oprávnění; export toto omezení dosud neuplatňoval a mohl do souboru zahrnout i směny mimo ně. Nově se export řídí stejným pravidlem jako přehled — počet řádků v souboru odpovídá počtu řádků na obrazovce.

27. 8. 2026 (ZENDESK 10363, YouTrack SUPP-10950) — Zaseknutá synchronizace MySMS už nepoloží celou agenturu

Ráno 27. srpna přestala aplikace odpovídat — přehled Pracovníci i další stránky skončily hláškou „Timed out acquiring connection from connection pool.“ a nešlo tak například rozeslat hromadnou SMS. Výpadek se netýkal jen jedné agentury — nefungovaly všechny agentury na společném serveru, přestože chyba vznikla jen u jedné z nich.

Na vině bylo pravidelné stahování zpráv a hovorů z telefonu připojeného přes službu MySMS. Aby se dvě takové synchronizace nepotkaly, zamyká si systém po dobu běhu společný záznam. Spojení na server MySMS se však zaseklo a nemělo nastavený žádný časový limit, takže úloha držela zámek pět hodin. Každá příchozí zpráva z MySMS se za ni mezitím zařadila do fronty a obsadila jedno z volných spojení do databáze — a jakmile došla všechna, přestal server odpovídat i všem ostatním uživatelům.

Nově má každé volání služby MySMS časový limit 30 sekund; když server MySMS neodpoví, synchronizace skončí chybou, zámek se ihned uvolní a úloha se spustí při dalším cyklu znovu. Příchozí zprávy navíc na zámek čekají nejvýš dvě sekundy a poté rovnou skončí chybou místo toho, aby blokovaly spojení do databáze; nezpracovanou zprávu dotáhne následující synchronizace. Jedna zaseknutá služba tak už nemůže zastavit celou aplikaci.

26. 8. 2026 (ZENDESK 10356, YouTrack SUPP-10943) — Mobilní aplikace: změna telefonního čísla v profilu už projde

V mobilní aplikaci se na obrazovce Můj profil nedalo změnit telefonní číslo. Po klepnutí na Změnit u pole Mobil se místo zadání nového čísla objevila hláška „Není možné poslat SMS. Mobil není nakonfigurován.“ a číslo zůstalo původní. Pracovník si tak nové číslo nemohl nastavit sám a musel o změnu požádat koordinátora.

Změnu čísla systém potvrzuje jednorázovým kódem, který pošle SMS na nově zadané číslo. Právě tuto ověřovací SMS se ale nedařilo zařadit k odeslání, protože aplikace pro ni neměla určenou odesílací bránu. Nově chodí ověřovací kód stejnou vyhrazenou cestou jako kód k elektronickému podpisu — dorazí tedy okamžitě a vždy jako SMS, nikdy jako upozornění do téže aplikace, ve které pracovník změnu potvrzuje. Stejně se opravilo i ověření stávajícího telefonního čísla po přihlášení.

26. 8. 2026 (ZENDESK 10358, YouTrack SUPP-10945) — Vyjmutí všech řádků z dávky JMHZ/REGZEC už nekončí chybou

V detailu JMHZ souboru slouží tlačítko Vyjmout z dávky k odebrání vybraných řádků z podání REGZEC nebo PREZEC — typicky po zamítnutí podání ČSSZ, aby v systému nezůstala duplicitní přihláška či odhláška. Když ale uživatel označil všechny řádky dávky — ať zaškrtnutím políčka v záhlaví, nebo postupně jeden po druhém — akce skončila chybou „Některé vybrané detailní řádky JMHZ neexistují.“, přestože řádky v dávce prokazatelně byly. U malých dávek, kde se vyjímají všechny řádky (například zamítnutá odhláška se dvěma záznamy), tak vyjmutí nešlo provést vůbec; výběr části řádků fungoval správně.

Příčinou bylo, že se výběr všech řádků posílá na server v jiné podobě než výběr jednotlivých řádků a akce Vyjmout z dávky tuto podobu neuměla zpracovat. Nově akce zpracuje obě podoby výběru a vyjmutí projde bez ohledu na to, kolik řádků a jakým způsobem uživatel označil.

26. 8. 2026 (ZENDESK 10357, YouTrack SUPP-10944) — Hláška o již registrovaném IČO nově řekne, o kterého zákazníka jde

Při zakládání zákazníka — ručně i tlačítkem Nový z ARES — systém odmítne IČO, které už v agentuře někdo má. Dosud ale hlásil jen „Zákazník s identifikačním číslem 12345678 je již registrován.“ a neprozradil, o který záznam jde. Když se existující zákazník jmenoval jinak, než jaký název se právě zadával — třeba proto, že se firma mezitím přejmenovala — nebo byl ve stavu, který přehled Zákazníci na výchozí záložce nezobrazuje, nedal se dohledat.

Nově hláška obsahuje i název a ID kolidujícího zákazníka, například „Zákazník s identifikačním číslem 12345678 je již registrován (ACME, a.s., Id: ACME).“ Podle něj se dá zákazník rovnou najít — vyhledáváním nahoře, nebo v přehledu Zákazníci přepnutím na záložku Všichni. Samotné pravidlo se nemění: jedno IČO může mít v agentuře jen jeden zákazník.

26. 8. 2026 (ZENDESK 10355, YouTrack SUPP-10942) — Mobilní aplikace: obrazovky Můj profil, Notifikace a Smlouvy jdou znovu posouvat

V mobilní aplikaci se na obrazovce Můj profil nedalo posunout na spodní část stránky. Obsah byl delší než displej, ale posun prstem nedělal nic — pracovník tak neviděl pole pod místem narození a nemohl je vyplnit ani opravit. Stejná vada se týkala i obrazovek Notifikace a Smlouvy a profilu v klientské části, jakmile měly víc obsahu, než se vešlo na displej.

Nově se všechny tyto obrazovky posouvají normálně a stažení prstem shora dál obnoví data.

26. 8. 2026 (ZENDESK 10353, YouTrack SUPP-10940) — Upozornění do aplikace už nespadne zpět na SMS kvůli diakritice

Má-li pracovník nainstalovanou mobilní aplikaci, systém mu místo SMS posílá upozornění do aplikace. U hromadně rozesílaných zpráv — typicky nabídek volných směn — se ale odeslání do aplikace nezdařilo pokaždé, když text zprávy obsahoval české znaky s háčky a čárkami. Systém to vyhodnotil jako nedoručitelnou notifikaci a poslal pracovníkovi běžnou (placenou) SMS. Pracovník, který se právě přihlásil do aplikace, tak dál dostával SMS.

Nově se tyto zprávy doručí do aplikace bez ohledu na diakritiku. SMS se posílá stále jen tehdy, když se upozornění nepodaří doručit na žádné z přihlášených zařízení.

26. 8. 2026 (ZENDESK 10346, YouTrack SUPP-10933) — www.student.cz: přihlašovací okno nabídne stažení mobilní aplikace

V přihlašovacím okně „Přihlášení k účtu“ na www.student.cz přibyl pod formulářem blok Raději v mobilu? s tlačítky Google Play a App Store a s poznámkou, že se do aplikace přihlásí stejným účtem. Kdo přijde na web kvůli směnám, rovnou vidí, že totéž zvládne z telefonu.

Odkazy míří na aplikaci Agentura STUDENT pro Android a iOS — na tytéž obchody, na které odkazují tlačítka v e-mailech pracovníkům. Samotné přihlášení, registrace ani zapomenuté heslo se nemění.

26. 8. 2026 (ZENDESK 10347, YouTrack SUPP-10934) — Přihlášení pracovníka už neblokuje starší zablokovaný účet se stejným e-mailem

Když měl pracovník v systému agentury dva záznamy se stejným přihlašovacím e-mailem — typicky starší účet, kterému agentura zakázala přístup, a nový záznam z pozdější registrace — mohlo přihlášení na web narazit na ten starý a skončit hláškou „Přístup z webu Vám byl zablokován", i když pracovník zadal správné heslo k platnému účtu.

Nově si přihlášení v takovém případě vybere účet, který zablokovaný není, a pracovník se přihlásí normálně. Zákaz přístupu nastavený agenturou zůstává v platnosti — zablokovaný účet se dál přihlásit nedá; změna se týká jen situace, kdy vedle něj existuje i platný účet se stejným e-mailem.

26. 8. 2026 (ZENDESK 10351, YouTrack SUPP-10938) — Zpráva pro pracovníka s více telefony dorazí do aplikace na všechna jeho zařízení

Má-li pracovník nainstalovanou mobilní aplikaci, systém mu místo SMS pošle upozornění do aplikace. Když ale měl přihlášená dvě zařízení — třeba pracovní a soukromý telefon — upozornění odešlo jen na to, na kterém aplikaci naposledy otevřel. Odeslání se povedlo, takže se SMS už neposlala a pracovník, který měl zrovna u sebe ten druhý telefon, nedostal nic.

Nově upozornění odchází na všechna přihlášená zařízení pracovníka. SMS se pošle stále jen tehdy, když se upozornění nepodaří doručit ani na jedno z nich.

26. 8. 2026 (ZENDESK 10350, YouTrack SUPP-10937) — Mobilní aplikace: spodní nabídka už není schovaná pod ovládáním Androidu

Na telefonech s Androidem se spodní nabídka aplikace (Domů, Notifikace, Profil) kreslila až k dolnímu okraji displeje, tedy pod systémový pruh s tlačítky zpět, plocha a přehled aplikací. Popisky tlačítek byly zpola překryté a na dotyk v jejich spodní části reagoval systém místo aplikace.

Nově si spodní nabídka nechá nad systémovým pruhem volné místo podle toho, kolik ho zařízení skutečně zabírá — jinak je to u telefonů s gestovým ovládáním a jinak u těch se třemi tlačítky. Na zařízeních bez systémového pruhu i při vysunuté klávesnici zůstává vzhled nezměněný, stejně jako postranní nabídka na tabletu a na počítači.

25. 8. 2026 (ZENDESK 10345, YouTrack SUPP-10932) — www.student.cz: inzerát po skončení platnosti už nejde otevřít ani na něj odpovědět

Inzerátu, kterému skončila platnost, zmizel z nabídky brigád na webu i z exportu pro pracovní portály — jeho vlastní adresa ale dál fungovala. Kdo se na ni dostal z vyhledávače nebo ze staršího odkazu, uviděl celý inzerát včetně tlačítka Odpovědět a odeslaná odpověď normálně dorazila na kontaktní e-mail inzerátu. Agentuře tak chodily reakce na brigády, které už dávno neběžely.

Nově web u inzerátu po skončení platnosti odpoví, že stránka neexistuje. Vyhledávače ho tak postupně vyřadí ze svých výsledků a odpovědní formulář na něm už není. Pokud by se odpověď přesto pokusila odeslat (třeba z uloženého odkazu), systém ji odmítne s vysvětlením, že platnost inzerátu skončila.

Platné inzeráty se nemění — otevírají se i odpovídá se na ně beze změny a beze změny zůstává i to, čím je konec inzerátu daný: datem konce platnosti zadaným u inzerátu.

24. 8. 2026 (ZENDESK 10335, YouTrack SUPP-10922) — Změna kategorií typů práce už zpětně neblokuje docházku obsazených míst

Když se u typu práce změnil seznam pracovních kategorií (například se z pomocných prací v kuchyni vyřadila kategorie steward), přestala u již obsazených pracovních míst vyhovovat ručně vybraná smlouva, která byla v pořádku v okamžiku obsazení. Každý další zásah — změna konce směny, uzavření docházky, schválení výkazu i výpočet mzdy — pak skončil chybou „Osoba … má ručně vybranou smlouvu …, ale tuto smlouvu není možné použít." Jinou smlouvu přitom často nebylo možné přiřadit, protože nová smlouva s odpovídající kategorií začala platit až později.

Nově se soulad pracovní kategorie smlouvy s typem práce vyžaduje jen při obsazování místa. U místa, které už obsazené je, se při následných kontrolách jeho stávající smlouva přijme i po pozdější změně kategorií — směnu tak lze upravit, docházku uzavřít a mzdu spočítat. Výběr jiné smlouvy zůstává kontrolovaný beze změny: smlouva s nevyhovující kategorií se na místo nově přiřadit nedá.

Přehled Mobilní aplikace – zařízení (registrovaná zařízení pracovníků) se od svého zavedení 11. 8. 2026 nenačetl. Po opravě ze 14. 8. sice přestalo vyskakovat chybové okno, ale místo dat se stránka točila donekonečna s tlačítkem Zastavit — seznam se nedal zobrazit vůbec.

Příčinou bylo, že předvolený filtr Aktivní pracuje se stavem zařízení, který přehled sice načítal, ale neměl ho mezi svými sloupci. Tabulka takový filtr neuměla přiřadit a načítání se nikdy nedokončilo. Chyba byla výhradně ve webové stránce přehledu — žádných dat se nedotkla a na mobilní aplikaci pracovníků ani na ostatní přehledy neměla vliv.

Přehled se nyní načte a předvolba Aktivní omezí výpis na zařízení aktivní za posledních 7 dní. Volbou Žádný filtr zobrazíte všechna zařízení včetně neaktivních a blokovaných.

24. 8. 2026 (ZENDESK 10333, YouTrack SUPP-10920) — Agentura práce Plzeň: nabídka směn končí zadaný počet hodin před začátkem, ne tři dny předem

Aplikace pro obsazování směn nabízela pracovníkům jen směny vzdálené více než tři dny. Směna na zítřek nebo pozítří se v nabídce neobjevila vůbec, i když na ní zbývala volná místa a pracovník na ni měl smlouvu i profesi. Hranice byla pevně zapsaná v kódu a nešla nastavit.

Nově ji řídí parametr vlastníka ASW_JOB_FREE_RESERVE_HOURS_BEFORE: směna se nabízí až do okamžiku, kdy do jejího začátku zbývá zadaný počet hodin. Pro Agenturu práce Plzeň je nastaven na 12 hodin, pracovníkům se tedy nabídnou i směny na následující den. Tentýž parametr už dříve řídil nabídku v nové mobilní aplikaci, takže obě aplikace nyní platí stejné pravidlo.

Beze změny zůstává horní hranice nabídky 51 dní dopředu i pravidla, která rozhodují, komu se která směna zobrazí — platná smlouva pokrývající směnu, typ smlouvy povolený pro dané středisko a povolené profese.

24. 8. 2026 (ZENDESK 10330, YouTrack SUPP-10917) — Emona Kroni: termíny záloh se nabízejí podle typu smlouvy

V mobilní aplikaci se pracovníkovi u žádosti o zálohu nabízely termíny úterý a pátek bez ohledu na to, jakou má smlouvu. Nově se nabídka řídí typem smlouvy: u hlavního pracovního poměru je to pátek, u dohod úterý a pátek a u smluv FAMICO středa.

Pracovník se souběhem více smluv uvidí termíny všech svých smluv dohromady — kdo má současně hlavní pracovní poměr i dohodu, má tedy dál k dispozici úterý i pátek. Beze změny zůstává vše ostatní: nabízejí se termíny na následujících 14 dní, s časem 10:00 a bez státních svátků.

23. 8. 2026 (ZENDESK 10319, YouTrack SUPP-10906) — Stahování souborů už neotevírá novou záložku

Tlačítko pro stažení souboru — ať už jde o dávku JMHZ, sken dokladu nebo přílohu u smlouvy — otevíralo soubor jako novou záložku prohlížeče. Záložka se sice hned zavřela a soubor se uložil, ale prohlížeč takové stahování posuzuje přísněji: vyhodnocuje ho jako stahování otevřené webem, ne vyvolané uživatelem, a hlídá ho samostatným oprávněním. Pokud toto oprávnění někdy někdo pro Stafio zakázal — třeba omylem v dotazu prohlížeče nebo firemním nastavením — klik na stažení pak tiše neudělal nic: soubor se nestáhl a neobjevila se žádná chyba.

Nově se soubor stahuje přímo, bez otevírání záložky, takže na toto oprávnění prohlížeče vůbec nedojde. Změna se týká stahování v celé aplikaci.

Pokud vám stahování nefunguje i po této aktualizaci, zkontrolujte prosím v prohlížeči nastavení Automatické stahování pro adresu Stafia (v Chrome chrome://settings/content/automaticDownloads) — pokud je tam adresa mezi zakázanými, odeberte ji.

21. 8. 2026 (ZENDESK 10322, YouTrack SUPP-10909) — Odeslanou dávku JMHZ už nejde smazat, ani když k ní Stafio nemá odpověď ČSSZ

Mazání JMHZ dávek hlídají dvě pojistky: smazat jde jen poslední vygenerovaný soubor firmy a jen soubor, který není označen jako odeslaný na ČSSZ. U dávky, kterou uživatel odeslal ručně datovou schránkou — takže k ní Stafio nemá žádnou odpověď ČSSZ — se ale obě pojistky omylem přeskočily a odeslaná dávka šla smazat jako kterákoli rozpracovaná.

Nově platí obě pojistky i pro tyto dávky. Bez kontroly zůstává jen dávka, kterou ČSSZ odmítla chybou — tu je naopak potřeba smazat a vygenerovat znovu.

Kalendář na nástěnce dostal čtyři úpravy:

Smluvní upozornění jdou filtrovat podle typu. Položka Smlouvy v boční liště se nově dá rozbalit na čtyři kategorie — Začátek smlouvy, Konec zkušebního období, Konec smlouvy a Odchod ze smlouvy. Kdo chce hlídat třeba jen konce smluv, zaškrtne si jen tuto kategorii; klik na Smlouvy dál vybere vše najednou.

Seznam „Dalších X" v měsíčním pohledu jde přečíst celý. Okno se seznamem událostí dne bylo omezeno na 200 bodů výšky a jeho posuvník se ukazoval jen při najetí myší a špatně se chytal — u dnů s mnoha událostmi se ke zbytku seznamu prakticky nešlo dostat. Okno je nyní až třikrát vyšší a scrolluje běžným posuvníkem prohlížeče, který je vidět trvale a funguje tahem, kolečkem i klávesnicí.

Boční lišta už nezajíždí pod kalendář. Na užších oknech se lišta s výběrem (Narozeniny, Smlouvy, Jubilea…) nechala stlačit a její obsah zmizel pod mřížkou kalendáře. Nově si drží šířku a kalendář se přizpůsobí.

Archivovaní a zakázaní pracovníci z kalendáře zmizeli. Narozeniny, jubilea, smluvní upozornění i potvrzení se dosud ukazovaly i u pracovníků převedených do archivu nebo zakázaných. Nově se tyto události generují jen pro ostatní stavy pracovníků.

21. 8. 2026 (ZENDESK 10324, YouTrack SUPP-10911) — Upozornění na smlouvy v kalendáři uvádí, o kterou smlouvu jde

Kalendář umí hlídat smlouvy — začátek a konec platnosti, konec zkušební doby a odchod ze smlouvy. V popisku upozornění ale stálo jen jméno pracovníka. U lidí, kteří mají ve Stafiu víc smluv souběžně — třeba dohodu a vedle ní smlouvu o praxi — tak nešlo poznat, které smlouvy se upozornění týká: konec praxe v červnu vypadal jako konec dohody uzavřené do konce roku.

Nově je v popisku i typ smlouvy — například Končí smlouva Nováková Jana (Praxe) oproti Končí smlouva Nováková Jana (DPP 2026). Dvojklikem na upozornění se jako dosud otevře přímo ta smlouva, které se týká.

Zároveň se do upozornění už nedostanou smlouvy označené jako Zrušená. Ty se dosud hlásily stejně jako platné, přestože žádný nástup ani konec platnosti nemají, a v kalendáři tak přibývaly položky u dnů, kdy se reálně nic nedělo.

21. 8. 2026 (ZENDESK 10264, YouTrack SUPP-10851) — Vlastní SMS brána: přijatá zpráva pod starým jménem brány už bránu nezastaví

Telefon s vlastní SMS bránou Stafia si každou přijatou SMS ukládá pod jménem brány, kterou mu Stafio naposledy oznámilo, a drží ji, dokud zápis nepotvrdíme. Když se mezitím telefon přepne na jinou bránu, zůstanou mu v paměti zprávy s původním jménem — a Stafio je odmítalo. Telefon je tak měl posílat pořád dokola a spolu s nimi se zastavilo i odesílání: brána zmlkla úplně, přestože chyba se týkala jen příjmu.

Nově Stafio takovou zprávu přijme a zapíše pod bránu, kterou telefon skutečně obsluhuje. Zprávy z doby přepínání se tím neztratí a brána se nezastaví. Má-li jeden telefon dvou SIM karet a nelze tedy určit, které bráně zpráva patří, Stafio ji nezařadí, ale dávku propustí, aby telefon nezůstal viset.

21. 8. 2026 (ZENDESK 10325, YouTrack SUPP-10912) — Odeslání SMS už nečeká na rozeslání upozornění ostatním uživatelům

Odeslání jedné SMS z karty pracovníka trvalo přibližně půl minuty — okno „Zpráva se odesílá“ zůstalo viset a do jeho zavření nešlo v aplikaci pokračovat. U hromadné rozesílky se zdržení násobilo počtem příjemců: rozeslání padesáti zpráv zabralo pětadvacet minut.

Každá nová zpráva ve Stafiu — odchozí i příchozí SMS a e-mail — vyvolá upozornění, které se v reálném čase rozesílá do webové aplikace. Upozornění se vystavovalo i za zprávu, kterou uživatel právě sám odeslal, a posílalo se všem uživatelským účtům firmy včetně servisních. Okno se zavřelo teprve poté, co služba upozornění potvrdila doručení všem; když byla pomalá, čekalo se na ni u každé zprávy až třicet sekund.

Nově se za vlastní odeslanou zprávu upozornění nevystavuje vůbec — uživatel o ní ví, sám ji poslal. Upozornění za příchozí zprávy dostávají jen uživatelé, kteří je skutečně odebírají, místo všech účtů firmy. A na odpověď služby upozornění čeká Stafio nejvýš pět sekund; pokud nestihne odpovědět, práce pokračuje dál a odeslání zprávy se nezdrží. U hromadné rozesílky se upozornění jako dosud vystaví jednou za celou skupinu.

20. 8. 2026 (ZENDESK 10318, YouTrack SUPP-10905) — Vodorovný posuvník v širokých přehledech už není třeba „probudit“ obnovením stránky

Přehledy, které se svou šířkou nevejdou do okna — typicky Smlouvy a Docházka na kartě pracovníka — se někdy otevřely s vodorovným posuvníkem, který nešel použít: dráha se táhla přes celou šířku tabulky, ale jezdec zůstal jako nepatrný čtvereček v levém dolním rohu a ke sloupcům vpravo se nedalo dostat. Po obnovení stránky (F5) už byl posuvník v pořádku.

Příčinou bylo, že si přehled zapamatoval šířku svého okna z okamžiku, kdy se vykreslil, a znovu už ji neměřil. Šířka obsahu se přitom mění i bez změny velikosti okna prohlížeče — například při rozbalení nebo sbalení hlavního menu, při změně jeho šířky tažením nebo při dopočtení rozložení stránky krátce po jejím otevření.

Nově si každý přehled změnu šířky svého okna hlídá a rozměry si sám přepočítá. Posuvník tak odpovídá skutečné šířce hned při otevření přehledu a zůstává správný i po sbalení či rozšíření menu. Platí to pro všechny přehledy ve Stafiu, včetně těch vnořených do karet a záložek.

20. 8. 2026 (ZENDESK 10264, YouTrack SUPP-10851) — Vlastní SMS brána Stafia nerozešle staré zprávy z fronty

Telefon s vlastní SMS bránou Stafia si zprávy k odeslání sám vyzvedává z fronty — na rozdíl od dosavadních bran, které zprávu odesílají jednou, ve chvíli jejího zařazení. Ve frontě každého telefonu ale léta zůstávají jednotlivé zprávy, které se kdysi neodeslaly; po přepnutí telefonu na novou bránu by je telefon při prvním spojení rozeslal, přestože jde třeba o nabídku směny starou dva roky.

Nově brána vydává k odeslání jen zprávy zařazené za posledních 24 hodin. Starší zprávy ve frontě zůstanou a neodešlou se. Pravidel pro opakování neúspěšného odeslání se změna nedotýká — zpráva se jako dosud zkusí odeslat nejvýš šestkrát a nejdřív dvě minuty po předchozím pokusu.

20. 8. 2026 (ZENDESK 10319, YouTrack SUPP-10906) — Náhled velké XML dávky JMHZ už nezastaví prohlížeč

Náhled XML souboru dávky (lupa nad souborem v detailu JMHZ) otevírá soubor v nové záložce prohlížeče s přehledně zvýrazněnou strukturou. U řádných měsíčních dávek, které mívají několik megabajtů a přes sto tisíc řádků, to ale prohlížeč nezvládl — záložka přestala reagovat a nabídla stránku opustit. Stažení souboru přitom fungovalo dál, jen se k němu při zamrzlém prohlížeči bylo těžké dostat.

Nově se náhled souborů nad 1 MB otevře jako prostý text bez zvýrazňování. Otevře se okamžitě a jde v něm normálně listovat i hledat (Ctrl+F). U menších souborů — typicky REGZEC a odpovědí z ČSSZ — zůstává zvýrazněná struktura beze změny. Stažení souboru se nemění vůbec.

20. 8. 2026 (ZENDESK 10320, YouTrack SUPP-10907) — Emona Kroni: v mobilní aplikaci znovu platí limit navazujících směn

V původní zaměstnanecké aplikaci se pracovník nemohl sám přihlásit na směnu, kterou by mu vznikla příliš dlouhá řada dnů bez volna — aplikace ho zastavila hláškou „Bohužel tuto směnu nelze zarezervovat. Je nutné dodržet přestávku. Dopřejte si den volno.“ Po přechodu na novou mobilní aplikaci toto pravidlo přestalo platit: nová aplikace zakládá rezervace jinou cestou, ve které kontrola navazujících směn chyběla, a pracovníci se tak mohli přihlásit na libovolný počet dnů v řadě.

Pravidlo je obnovené a nově dovolí nejvýš šest směn v řadě — sedmou po sobě jdoucí směnu aplikace odmítne stejnou hláškou jako dřív. Odpovídá to nepřetržitému odpočinku v týdnu podle zákoníku práce. Počítají se všechny směny pracovníka bez ohledu na to, na které smlouvě nebo pracovišti je odpracuje.

Přiřazení směny z back-office (agenturou) pravidlo neomezuje — týká se výhradně samoobslužného přihlašování pracovníka v aplikaci.

20. 8. 2026 (ZENDESK 10314, YouTrack SUPP-10901) — Smazaný filtr v přehledu se už nevrací

Filtr, který si v přehledu nastavíte do řádku pod záhlavím sloupců, si Stafio pamatuje ke každému uživateli zvlášť, aby ho při návratu do okna nemusel zadávat znovu. Jeho smazání se ale neukládalo — filtr sice z obrazovky zmizel, v uloženém nastavení však zůstal a při dalším přihlášení se do přehledu vrátil. Nejvíc to bylo znát u přehledů vnořených do karty, například u sekce Dodatky na kartě pracovní smlouvy: zapomenutý filtr na sloupci Platnost od se vracel i při překliku na jinou smlouvu a přehled kvůli němu hlásil „Žádná data".

Nově se zrušení filtru ukládá stejně spolehlivě jako jeho nastavení — jakmile filtr smažete, zůstane smazaný i po odhlášení a v jiném prohlížeči. Stejnou vadou trpělo i rušení dalších voleb přehledu, které si Stafio pamatuje — zrušení řazení sloupce nebo návrat šířky sloupce na automatickou — a je opravené zároveň.

Pokud vám nějaký filtr v přehledu takto uvízl, po této aktualizaci ho stačí jednou smazat — už se nevrátí.

20. 8. 2026 (ZENDESK 10315, YouTrack SUPP-10902) — Stránka pro elektronický podpis se otevírá výrazně rychleji a hned dá najevo, že se načítá

Po kliknutí na tlačítko Dokument k podpisu v e-mailu se několik sekund zobrazovala prázdná bílá stránka a teprve pak naskočil Souhlas s elektronickou komunikací. Pracovníci to často nevydrželi a stránku zavřeli v domnění, že se nenačetla — dokument pak zůstal nepodepsaný.

Příčinou nebylo zpracování dokumentu, to trvá desetiny sekundy. Zdržovalo množství dat, které si prohlížeč musel stáhnout, než mohl cokoli vykreslit — přes 20 MB. Nově se všechny soubory posílají komprimovaně, takže objem stažených dat klesl na necelou třetinu (přibližně 7,5 MB) a stránka se odpovídajícím dílem dřív otevře. Na mobilních datech je rozdíl nejvýraznější.

Než je stránka připravená, ukazuje se navíc točící se indikátor načítání, aby bylo na první pohled zřejmé, že aplikace pracuje, a ne že se stránka nezobrazila. Změna se týká všech stránek otevíraných z odkazů v e-mailech — podpisu dokumentů, vstupního dotazníku i detailu směny — a stejně tak webové verze mobilní aplikace.

20. 8. 2026 (ZENDESK 10126, YouTrack SUPP-10710) — Roční nárok na dovolenou se řídí nastavením u oddělení objednávek

Roční výměru dovolené lze ve Stafiu zadat na dvou místech: přímo na smlouvě pracovníka, nebo u oddělení objednávek na záložce Povolené druhy práce. Nastavení u oddělení má přednost, protože výměra se řídí tím, kde a jakou práci pracovník skutečně odvedl — a přesně tak do výpočtu nároku na dovolenou i vstupovalo. Sloupec Roční nárok na dovolenou v záložce Dovolená ale ukazoval hodnotu ze smlouvy, tedy jiné číslo, než se kterým se počítalo. U dohod, kde je výměra zadaná jen u oddělení a na smlouvě zůstala předvyplněná hodnota z typu smlouvy, se tak zobrazovala nižší (nebo nulová) výměra, než jaká pracovníkovi náležela.

Nově se do sloupce Roční nárok na dovolenou ukládá stejná hodnota, ze které se nárok počítá — výměra podle oddělení a druhu práce, a pracoval-li pracovník během roku na více odděleních s různou výměrou, jejich vážený průměr podle skutečně odpracovaných hodin. Není-li u oddělení výměra vyplněná, bere se jako dosud hodnota ze smlouvy. Ze stejného čísla vychází i sloupec Roční dovolená k čerpání, který u smluv s nevyplněnou výměrou dosud vycházel záporně.

Připomínáme, jak se hodnota zadává: je to počet týdnů dovolené × 40 hodin bez ohledu na to, kolik hodin týdně se podle smlouvy reálně pracuje — 160 = 4 týdny, 200 = 5 týdnů, 240 = 6 týdnů. Skutečné hodiny si Stafio dopočítá z týdenního fondu konkrétní smlouvy; u dohody o pracovní činnosti je to podle zákoníku práce 20 hodin týdně, takže 6 týdnů odpovídá 120 hodinám za plný rok.

Samotný nárok na dovolenou ani žádná částka ve mzdě se touto změnou nemění. Hodnota se do záložky Dovolená zapisuje při výpočtu mzdy, takže u dříve spočítaných mezd se srovná až po přepočtu.

20. 8. 2026 (YouTrack WAS-1882) — Notifikace ze schránky zpráv se konečně zobrazí i jako vyskakovací upozornění

Když ve Stafiu doběhne úloha běžící na pozadí — typicky Exportovat všechny záznamy nad přehledem — přijde o tom zpráva do Notifikací. Vyskakovací upozornění, které o ní mělo dát vědět rovnou na obrazovce, se ale nezobrazovalo: u zvonečku naskočil počet nepřečtených zpráv a záznam se objevil v přehledu notifikací, samotné upozornění však ne.

Nově se upozornění ukáže nahoře uprostřed obrazovky, barvou odpovídá typu zprávy (zelené u úspěšně dokončené akce, červené u chyby) a po deseti vteřinách samo zmizí. Pokud zpráva odkazuje na nějaké místo ve Stafiu — třeba na hotový soubor s exportem — dá se na upozornění kliknout: Stafio odkaz otevře a zprávu zároveň označí jako přečtenou.

20. 8. 2026 (ZENDESK 10313, YouTrack SUPP-10900) — Automaticky zakládané smlouvy: DPP a DPČ dostanou správnou pozici a CZ-ISCO

Když se pracovník obsadí na směnu a Stafio mu k tomu automaticky založí dvojici smluv (dohodu o provedení práce a dohodu o pracovní činnosti), rozděluje se mezi ně pozice podle kategorií práce nastavených u pozice na objednávce — první kategorie patří dohodě o provedení práce, druhá dohodě o pracovní činnosti. Tím lze docílit toho, aby každá z obou smluv šla do registru zaměstnavatelů s vlastním názvem profese a vlastním kódem CZ-ISCO.

Pořadí, ve kterém se obě smlouvy zakládaly, ale nebylo pevně dané — záviselo na tom, jak jsou v databázi uložené řádky nastavení typů smluv pro pracoviště. Když se pořadí obrátilo, vzala si pozici z objednávky dohoda o pracovní činnosti a na dohodu o provedení práce už žádná pozice nezbyla: v jejím textu chyběla pozice a do registru zaměstnavatelů se místo názvu pozice poslal text z číselníku CZ-ISCO, u obou smluv navíc se stejným kódem profese.

Nově je pořadí pevně dané — nejdřív se zakládá dohoda o provedení práce, pak dohoda o pracovní činnosti — takže rozdělení kategorií i pozic odpovídá nastavení. U rychlého občerstvení tak dohoda o provedení práce dostane pozici příprava rychlého občerstvení (CZ-ISCO 94112) a dohoda o pracovní činnosti pozici prodej rychlého občerstvení (CZ-ISCO 52120). Aby rozdělení fungovalo, musí mít pozice použitá na řádce objednávky nastavené obě kategorie práce ve správném pořadí (nejprve kategorii pro DPP, pak pro DPČ). Smlouvy, které vznikly s chybnou nebo prázdnou pozicí, jsme opravili.

Zároveň se druhá pozice vybírá jen z pozic platných k datu nástupu a výběr je nově jednoznačný. Dosud se nabízely i pozice s ukončenou platností, takže vyřazení nepoužívané pozice nemělo na zakládání smluv žádný účinek a mohla se dostat na smlouvu místo té zamýšlené. Přednost při výběru má pozice, která má kategorii určenou pro DPČ nastavenou jako první — tedy pozice, která do této kategorie patří. Pozice pracovišť, které stejnou kategorii nesou jen jako druhou kvůli rozdělení DPP/DPČ, se přeskakují. Pravidlo pro nastavení: v kategorii určené pro DPČ má být právě jedna platná pozice, která ji má jako první (typicky pozice s jedinou kategorií).

Rozdělení funguje i tam, kde se zakládá dvojice dvou dohod o provedení práce (každá pro jinou firmu, například hostesky). Dosud dostaly obě smlouvy první kategorii pozice z objednávky — druhá smlouva pak zůstala bez pozice a do registru zaměstnavatelů šly obě se stejným kódem profese. Nově druhá smlouva dostane první dosud nepoužitou kategorii, takže se rozdělení pozic a kódů CZ-ISCO chová stejně jako u dvojice DPP + DPČ.

19. 8. 2026 (ZENDESK 10251, YouTrack SUPP-10838) — Alternativní osobní čísla: pracovník může mít u každého zákazníka jiné číslo

Pracovník, který pracuje pro víc klientů, má u každého z nich zpravidla vlastní identifikační číslo — klienti podle něj evidují docházku. Ve Stafiu bylo dosud osobní číslo jedno na osobu, takže v denním reportu obsazení pracovních míst se ke všem klientům tisklo totéž číslo.

Nově má karta zákazníka na záložce Ostatní sekci Alternativní osobní čísla, kde se pro jednotlivé pracovníky zadá číslo, které jim přidělil tento zákazník. Číslo je navázané na dvojici pracovník + zákazník, ne na konkrétní smlouvu — při prodloužení nebo založení nové smlouvy zůstává zachované a platí pro všechna pracoviště daného zákazníka. Na kartě pracovníka se vyplněná čísla zobrazují vedle pole Osobní číslo jen pro čtení.

Denní report obsazení pracovních míst nyní ve sloupci s osobním číslem tiskne číslo přidělené tím zákazníkem, pro kterého se sestava vytváří. Pokud pro danou dvojici žádné alternativní číslo zadané není, tiskne se jako dosud osobní číslo pracovníka. Šablony sestav se neměnily. Agendu zapínáme na vyžádání.

19. 8. 2026 (ZENDESK 10312, YouTrack SUPP-10899) — Upozornění „Opustit stránku?" se po uložení už nezobrazuje

Po uložení změn na kartě pracovníka (například změny stavu spolu s opravou e-mailu nebo mobilu) se při odchodu ze stránky či zavření okna mohlo zobrazit upozornění „Opustit stránku? Neuložené změny budou ztraceny.", přestože všechny změny byly v pořádku uložené — znovu se objevilo i plovoucí tlačítko Uložit. Příčinou byl souběh: kontrola duplicitního e-mailu či mobilu, která se spouští při změně těchto polí, doběhla někdy až po dokončení ukládání a formulář omylem znovu označila za rozpracovaný. Čím větší databáze pracovníků, tím byla situace pravděpodobnější.

Nově výsledek kontroly, který žádnou hodnotu formuláře nemění, rozpracovanost nenastaví. Upozornění se při odchodu zobrazí jen tehdy, když ve formuláři skutečně zůstávají neuložené změny. Ukládání dat touto chybou nebylo nijak dotčeno — všechny takto uložené změny jsou zapsané.

19. 8. 2026 (ZENDESK 10310, YouTrack SUPP-10897) — E-podpis: ověřovací SMS kód dorazí i pracovníkům bez souhlasu se zasíláním nabídek

Pracovník, který nemá povolené zasílání nabídek přes SMS, nemohl dokončit elektronický podpis dokumentu. Po otevření podpisového odkazu se místo stránky s podpisem zobrazila chyba „It is not allowed for … to send SMS." a ověřovací kód nedorazil — na mobilu ani na počítači. Příčinou byla kombinace nastavení „Zakázat posílat nevyžádané SMS", které blokovalo každou SMS pracovníkovi bez souhlasu, tedy i ověřovací kód dvoufaktorového ověření, který si pracovník otevřením podpisové stránky sám vyžádal.

Nově se ověřovací kódy (kód pro elektronický podpis a kód pro potvrzení mobilního čísla) posílají vždy — nejde o nevyžádané obchodní sdělení. Hromadné a nabídkové SMS zůstávají pro pracovníky bez souhlasu blokované beze změny. Pracovníkovi, kterému podpis dříve selhal, stačí znovu otevřít odkaz z e-mailu.

19. 8. 2026 (ZENDESK 10309, YouTrack SUPP-10896) — Odhláška REGZEC 2: údaj „odchodné/odbytné/odstupné náleží“ se posílá jen u důvodů, kde ho ČSSZ očekává

Odhláška zaměstnance ze sociálního pojištění (REGZEC 2 – Skončení) se u pojištěného zaměstnání s vyplněným důvodem skončení odesílala vždy i s údajem „odchodné/odbytné/odstupné náleží“. ČSSZ ale tento údaj připouští jen u důvodů skončení 4 – Organizační důvody a 5 – Zdravotní důvody; u ostatních důvodů (například Dohodou se zaměstnavatelem § 49 ZP) podání zamítla s chybou „REGZEC25_LT: 027 … atribut 'employee/unemplcomp/@belong' nesmí být vyplněn“ a skončení se na ČSSZ nezaevidovalo.

Nově se údaj „odchodné/odbytné/odstupné náleží“ do odhlášky vkládá jen při důvodech skončení 4 a 5, kde je povinný. Dříve zamítnuté odhlášky stačí po této opravě vygenerovat a odeslat znovu — zamítnuté podání na ČSSZ nic nezaevidovalo, opakovanému odeslání nic nebrání.

19. 8. 2026 (ZENDESK 10306, YouTrack SUPP-10893) — Dávka pro zdravotní pojišťovnu: cizí písmena ve jméně se už nepřevádějí na otazník

Soubor hromadného oznámení zaměstnavatele pro zdravotní pojišťovny se generuje v historickém znakovém kódování (Latin 2), které zná jen českou a slovenskou diakritiku. Písmeno z cizí latinky — například rumunské „ş“ v příjmení Cereş — se proto do souboru zapsalo jako otazník a kontrola pojišťovny soubor odmítla s hláškou „Zadané příjmení obsahuje nepovolené znaky.“

Nově se písmeno, které v kódování dávky neexistuje, nahradí stejným písmenem bez diakritiky (Cereş → Ceres), tak jak je u podání zdravotním pojišťovnám běžné; pojištěnec je jednoznačně určen číslem pojištěnce. Otazník zůstává jen pro znaky mimo latinku. Jméno ve Stafiu se nemění — dříve odmítnutou dávku stačí znovu vyexportovat a podat.

19. 8. 2026 (ZENDESK 10308, YouTrack SUPP-10895) — eObjednávky: obsazenou směnu lze smazat i u pracovníka bez e-mailu

Smazání obsazené směny v eObjednávkách (tlačítko Smazat, které směnu nejdřív uvolní, uvědomí pracovníka a teprve pak odebere pracovní místo) končilo u některých směn hláškou „Není možné smazat obsazené pracovní místo“, přestože do začátku směny zbývalo více než 24 hodin. Skutečnou příčinou nebylo obsazení směny, ale chybějící e-mailová adresa u přiřazeného pracovníka — informační e-mail o zrušení směny nešlo odeslat a zastavil celou operaci ještě před uvolněním. Chování nezáviselo na tom, odkud se směna maže; z přehledu směn i z detailu směny se totiž provádí stejný postup.

Nově se informační e-mail zakládá jen tomu příjemci, který má adresu vyplněnou. Směna se uvolní a odebere, zákazník i pracovník dostanou zbylé notifikace (u pracovníka bez e-mailu SMS) a operace doběhne do konce. Stejná úprava platí i pro tlačítka Přiřadit a Vyměnit, která ze stejného důvodu selhávala u pracovníků bez e-mailu.

19. 8. 2026 (ZENDESK 10304, YouTrack SUPP-10891) — Měsíční souhrn mezd podle společnosti se v desktopovém klientovi načte

Přehled Měsíční souhrn mezd podle společnosti v desktopovém (Java) klientovi se při načtení celé historie bez vyplněného Období prakticky nedopočítal — točil se jen ukazatel načítání. Sloupce Základ srážkové daně, Základ zálohové daně, Sleva na dani, Daňový bonus na děti, Dovolená a Dny nemoci se počítaly z příliš složitého pohledu na mzdy, a to znovu pro každý řádek přehledu.

Nyní se tyto sloupce počítají přímo z měsíčních souhrnů mezd (včetně externích), se stejnými hodnotami i stejným rozsahem viditelnosti. U zákaznických dat, kde se přehled předtím nenačetl vůbec, se celá historie (410 řádků) načte místo původních téměř 10 minut zhruba za minutu a půl. Pro běžnou práci doporučujeme vyplnit Období — přehled se pak vrátí do několika vteřin.

19. 8. 2026 (ZENDESK 10307, YouTrack SUPP-10894) — Blok potvrzení bez smlouvy na ČSSZ platí i pro potvrzení rezervace

Pravidlo z 3. 8. 2026 — pracovníka bez smlouvy přihlášené na ČSSZ (bez IDPPV) smí méně než 72 hodin před akcí potvrdit jen uživatel s rolí Supervisor — se dosud uplatnilo pouze při obsazení volného místa. Potvrzení pracovníka, který na místě už měl rezervaci (včetně rezervace převedené na náhradníka), kontrolou neprošlo a proběhlo bez omezení; touto cestou přitom jde naprostá většina potvrzení. Stejně tak se kontrola neuplatnila, když se na místo s cizí rezervací obsadil jiný pracovník, ani při samotném převedení rezervace na náhradníka.

Kontrola nyní platí pro všechny způsoby potvrzení ze Stafia stejně — obsazení volného místa, potvrzení rezervace, obsazení jiného pracovníka na místo s cizí rezervací i převedení rezervace na náhradníka (tím se pracovníkovi zakládají smlouvy a odchází mu vyrozumění, proto pod pravidlo patří také). Beze změny zůstává vše ostatní: přihlášení pracovníka přes webový portál a mobilní aplikaci, hromadný import ani přepočty uzavřených akcí kontrole nepodléhají a držitelé role Supervisor mohou potvrzovat kdykoli.

19. 8. 2026 (ZENDESK 10302, YouTrack SUPP-10889) — Duplicitní Id stavu aktivity hlásí konkrétní hodnotu

Při zakládání nového stavu aktivity (Administrace → XRM → Základní data → Typy aktivit, sekce Stavy) se při zadání již použitého Id objevila obecná hláška „Záznam v ‚Stav aktivity‘ již existuje.“, ze které nebylo poznat, které pole kolizi způsobilo. Id stavu přitom musí být jedinečné napříč všemi typy aktivit, ne jen v rámci jednoho typu — snadno se tak stane, že se převezme Id od jiného typu aktivity.

Nově hláška uvádí i konkrétní hodnotu, například „Záznam ‚POTVRZENI1.P‘ v ‚Stav aktivity‘ již existuje.“, takže je hned zřejmé, že stačí zvolit jiné Id.

19. 8. 2026 (ZENDESK 10301, YouTrack SUPP-10888) — Záložka Historie obsazování se znovu načítá

Záložka Historie obsazování na detailu objednávky a na řádce objednávky se nenačetla — místo dat zůstal viset ukazatel načítání s tlačítkem „Zastavit" a nepomohlo ani přepnutí datumového filtru. Přehled Historie obsazování v menu Objednávky přitom fungoval normálně.

Příčinou byla chyba v definici tabulky na těchto dvou záložkách: datumový filtr v liště (Posledních 35 dnů, Dnes, Včera, Posledních 12 měsíců) odkazoval na pole, které tabulka neznala, a načítání se na tom zastavilo. Pole bylo doplněno a záložka se načítá i s výchozím filtrem Posledních 35 dnů.

19. 8. 2026 (ZENDESK 10301, YouTrack SUPP-10888) — Zapamatovaný datumový filtr přehledu už nekončí chybou

Když si přehled zapamatoval datumový filtr z minulé návštěvy (uložené nastavení tabulky uživatele), mohlo se stát, že se po dalším otevření stránky data nenačetla — dotaz na server odešel s neplatnou hodnotou data („Invalid Date") a skončil chybou. Projevovalo se to podle toho, v jaké podobě bylo datum ve filtru uložené; stejný filtr vybraný ručně z lišty přitom fungoval.

Nově se datumové hodnoty při obnově zapamatovaného filtru převádějí do podoby, kterou tabulka očekává — stejně, jako když filtr vyberete ručně. Zapamatované filtry se tak načtou správně.

19. 8. 2026 (YouTrack WAS-1877) — Oprava datumových filtrů v dalších přehledech (deníky komunikace, obchodní smlouvy a další)

Stejná chyba, kvůli které se nenačítala záložka Historie obsazování (datumový filtr v liště odkazoval na pole, které tabulka neznala), byla nalezena a opravena i v dalších přehledech: deník komunikace na kartě osoby zákazníka, dodavatele a osoby dodavatele a přehled Obchodní smlouvy se kvůli ní nenačetly vůbec (zůstal viset ukazatel načítání); v přehledech Inzeráty, Pracovníci — kmenoví a Pracovníci — brigádníci selhal výběr datumového filtru z lišty (Posledních 35 dnů, Dnes, Včera, Posledních 12 měsíců).

Všechny uvedené přehledy se nyní načítají správně a datumové filtry v liště fungují.

18. 8. 2026 (ZENDESK 9063, YouTrack SUPP-9643) — Fakturovanou směnu už nelze převést na jinou smlouvu

Dialog Obsazení pracovního místa (převod pracovních míst na jinou smlouvu) dosud dovolil změnit smlouvu i u směny, která už byla na vystavené faktuře. Směna tím přešla pod jinou smlouvu — případně i pod jinou společnost — a z obsahu faktury zmizela, přestože faktura zůstala vystavená se svými částkami.

Nově systém převod směny ve fakturovaném stavu (Fakturované, Vypočtené, fakturované, Část. vyplacené, fakturované, Vyplacené, fakturované) odmítne s hláškou „Pracovní místo … je již fakturované, smlouvu nelze změnit. Nejprve zrušte fakturaci směny." Pokud je změna smlouvy skutečně potřeba, je nejdřív nutné zrušit fakturaci směny, poté smlouvu změnit a směnu vyfakturovat znovu. Převod nevyfakturovaných směn (včetně vypočtených — mzda se smaže a přepočítá) funguje beze změny.

18. 8. 2026 (ZENDESK 9068, YouTrack SUPP-9648) — Ukončení exekuce v průběhu měsíce už nezpůsobí dvojnásobnou srážku

Když byla exekuce, na kterou se v běžícím měsíci už srazilo (například při zálohách po směnách), označena jako vyřízená ručně — typicky poté, co exekutor vydal pokyn k ukončení — přestal výpočet srážek už provedenou srážku vidět. Celou měsíční zabavitelnou částku pak nabídl další exekuci v pořadí, takže hrozilo, že se za jeden měsíc srazí až dvojnásobek zákonného maxima.

Nově se srážky provedené v daném měsíci na ukončenou exekuci započítávají do vyčerpání měsíční zabavitelné částky. Další exekuce v pořadí tak v měsíci ukončení dostane jen případný zbytek do zákonného limitu a naplno se začne srážet až od následujícího měsíce.

18. 8. 2026 (ZENDESK 7927, YouTrack SUPP-8507) — Nárok na dovolenou pod jeden týden se do PAMICA přenášel jako nula

Roční nárok na dovolenou se do PAMICA posílá v týdnech, zatímco Stafio ho vede v hodinách normalizovaných na čtyřicetihodinový týden (160 hodin = 4 týdny). Přepočet ale dělil celočíselně, takže se výsledek vždy zaokrouhlil dolů na celé týdny: nárok 188 hodin dorazil do PAMICA jako 4 týdny místo 4,7 a nárok nižší než 40 hodin se přenesl jako nula týdnů, přestože smlouva zároveň dostala příznak, že nárok na dovolenou má.

Nově se přepočet počítá desetinně a zaokrouhluje na dvě desetinná místa. Smlouvy s nárokem v celých násobcích čtyřiceti hodin se nijak nemění.

Připomínáme, že zaškrtnutí Nárok na dovolenou v PAMICE se řídí tím, jestli má smlouva ve Stafiu nenulový roční nárok. Pokud se u přenesené smlouvy políčko nezaškrtne, má smlouva ve Stafiu nárok 0 hodin — výchozí hodnota se nastavuje u typu smlouvy a na konkrétní smlouvě ji lze přepsat.

18. 8. 2026 (ZENDESK 9365, YouTrack SUPP-9945) — Krácení dovolené lze zadat i na smlouvu bez odpracované směny

Převod nevyčerpané dovolené na navazující smlouvu (karta osoby → Mzdy → Krácení dovolené) dosud nešel dokončit, dokud na nové smlouvě neexistovala aspoň jedna mzda — vložení řádku krácení skončilo chybou „Aspoň 1 mzda musí existovat pro krácení dovolené". Dovolenou tak nebylo možné převést hned při ukončení staré a založení nové smlouvy; muselo se čekat na první odpracovanou směnu.

Nově lze řádek krácení (kladný i záporný) vložit, upravit i smazat na jakékoli smlouvě bez ohledu na to, zda na ní už mzda existuje. Nárok na dovolenou se přepočítá ihned. V přehledu Dovolená se řádek nové smlouvy objeví až ve chvíli, kdy na ní vznikne nárok podle zákonných podmínek (např. u dohod odpracování aspoň 80 hodin) — zadané krácení se v něm pak už zohlední.

18. 8. 2026 (ZENDESK 10286, YouTrack SUPP-10873) — Zaseknuté odeslání ověřovacího SMS kódu už neblokuje podpis smlouvy

Ověřovací kód pro elektronický podpis smluv se odesílá přes SMS bránu BulkGate. Když spojení s bránou výjimečně zamrzlo, držela se po celou dobu podepisovaná obálka — pracovníkovi se stránka podpisu „nekonečně načítala" a kód dorazil až po uvolnění spojení (18. 8. takto jedno odeslání viselo 20 minut).

Nově je volání SMS brány omezeno na 15 sekund. Když brána neodpoví, odeslání kódu ihned selže a stránka se uvolní — pracovník si kód vyžádá znovu tlačítkem, místo aby mnoho minut čekal na zamrzlou stránku.

18. 8. 2026 (ZENDESK 10283, YouTrack SUPP-10870) — Přehledy s lištou stavů už nespadnou na chybu 500

Když prohlížeč přišel o uloženou definici stavů workflow — typicky když se inicializace aplikace přerušila přesně ve chvíli vydávání nové verze — spadly všechny přehledy s lištou stavů (Pracovníci, Smlouvy a další) na celostránkovou chybu 500 „Cannot read properties of undefined (reading 'PersonState')". Pomohlo jen odhlášení a nové přihlášení.

Nově si stránka chybějící definici stavů sama znovu stáhne ze serveru a zobrazí se normálně; i kdyby se ji stáhnout nepodařilo, přehled se otevře bez lišty stavů místo chybové stránky.

18. 8. 2026 (ZENDESK 10276, YouTrack SUPP-10863) — Do PAMICA lze posílat pozici místo poznámky ze smlouvy

Do PAMICA se jako název pracovního poměru dosud posílala poznámka ze smlouvy. Ta u řady zákazníků obsahuje jen druh smlouvy („DPP", „HPP 40"), takže se informace o tom, na jaké pozici člověk pracuje, do PAMICA nedostala vůbec a bylo nutné ji tam zadávat ručně.

Nově lze u vlastníka přepnout parametr PAMICA_EMPLOYMENT_NAME z hodnoty NOTE na WORK_CATEGORY. Pak se místo poznámky posílá kategorie práce ze smlouvy doplněná podle druhu smlouvy: dohoda o provedení práce dostane příponu „DPP", hlavní pracovní poměr na dobu neurčitou příponu „N" a hlavní pracovní poměr na dobu určitou zůstane bez přípony — to je rozlišení, které PAMICA potřebuje pro výkazy pro stát. Smlouva bez vyplněné kategorie práce se pošle jako dosud.

Název je v PAMICA omezen na 48 znaků; delší se ořízne, přípona ale zůstane zachována. Výchozí hodnota parametru je NOTE, takže bez přepnutí se pro nikoho nic nemění.

18. 8. 2026 (ZENDESK 10257, YouTrack WAS-1871) — JMHZ lze vygenerovat i bez chybných smluv (vědomé vynechání s potvrzením)

Když měsíční hlášení JMHZ obsahovalo smlouvu, kterou by ČSSZ zamítla vadou 20262 — příjem na smlouvě neregistrované u ČSSZ, zatímco osoba má jinou registrovanou — kontrola dosud zastavila celé generování, dokud se neopravily všechny uvedené smlouvy. V den zákonného termínu tak nešlo podat vůbec nic, například když se čekalo na protokoly ČSSZ.

Nově se při generování zobrazí potvrzovací dialog se jmenovitým seznamem problémových smluv a důvodem u každé z nich. Můžete generování zrušit a chyby nejdřív opravit, nebo zvolit „Vygenerovat bez uvedených smluv" — hlášení se vytvoří jen z formulářů, které ČSSZ přijme, a odešlete ho v zákonném termínu (tedy i s nárokem na slevy na pojistném). Vynechané smlouvy zůstanou uvedeny u vygenerovaného souboru (včetně toho, kdo a kdy vynechání odsouhlasil) i v oznámení po dokončení. Po opravě — přeobsazení směn nebo importu ID PPV — tyto osoby doplníte opravným podáním; to umí přidat i osobu, která v řádném hlášení nebyla.

Kontrola navíc nově hlídá i smlouvy přihlášené k sociálnímu pojištění, kterým ještě nebylo naimportováno ID PPV z odpovědi ČSSZ. Dřív takové podání odešlo a ČSSZ ho kvůli vadě 20262 celé zamítlo; teď se na to přijde ještě před vytvořením souboru — smlouvu buď dořešíte importem odpovědi ČSSZ, nebo ji rovněž vynecháte a doplníte opravným podáním.

18. 8. 2026 (ZENDESK 10278, YouTrack SUPP-10865) — Růžové prohlášení: děti vybrané ze seznamu se propisují do tisku i přehledu

Když se dítě v sekci Dodatečné daňové zvýhodnění růžového prohlášení vybralo ze seznamu osob (namísto ručního vypsání jména do pole Text), zůstala tabulka vyživovaných dětí v náhledu tisku i v dokumentu k podpisu prázdná a v přehledu chybělo rodné číslo. Tisková sestava i přehled totiž četly jen textové údaje řádku a vazby na osobu dítěte si nevšímaly.

Nově se jméno i rodné číslo dítěte dotáhnou z navázané osoby: tabulka podle § 35c se v dokumentu vyplní včetně rodných čísel a rodná čísla vidíte i v přehledu. Ručně vypsané údaje mají i nadále přednost.

Opravili jsme při tom i dvě starší vady tiskopisu: křížek Zletilé dítě se dosud nezaškrtával nikdy (věk se z rodného čísla nepočítal) a tabulka dětí na druhé straně tiskopisu se od roku 2018 netiskla vůbec.

18. 8. 2026 (ZENDESK 10277, YouTrack SUPP-10864) — Vstupní dotazník: srozumitelná hláška při adrese bez čísla domu

Když pracovník ve vstupním dotazníku — nebo kdokoli při úpravě adresy osoby — uložil českou adresu bez čísla popisného, orientačního i evidenčního, skončilo ověření adresy v registru RUIAN nic neříkající anglickou chybou „An error occurred while validating the address". Nebylo z ní poznat, co je špatně a co opravit.

Nově se v takové situaci zobrazí srozumitelná výzva „Vyplňte číslo popisné, orientační nebo evidenční." Zároveň jsme počeštili i obecnou chybu ověření adresy pro ostatní nečekané odpovědi registru („Při ověřování adresy došlo k chybě.").

17. 8. 2026 (ZENDESK 10232, YouTrack SUPP-10819) — Změna daňového prohlášení už nestornuje vyplacené mzdy

Změna v daňovém prohlášení — typicky přidání nebo odebrání dítěte či jiné slevy — dosud už vyplacené mzdy dotčených měsíců stornovala a založila znovu. V pokladně tak vznikla sada storen a stejně velká sada nových mezd; když změna neměla na částky vliv (například sleva na dítě se v měsíci s nízkým příjmem neuplatní), zbyla z toho jen platba na 0 Kč, kterou bylo nutné ručně „vyplatit".

Nově se vyplacené mzdy při změně prohlášení jen přepočítají, stejně jako při měsíční optimalizaci: má-li změna finanční dopad, vznikne jedna opravná mzda s rozdílem (doplatek či srážka); nemá-li, vznikne nanejvýš jeden nulový řádek zaznamenávající změnu evidované slevy pro daňové sestavy. Storna a nulové platby už nevznikají. Smazání celého prohlášení se chová postaru (mzdy na prohlášení odkazují, proto se stornovat musí) a uzavřená období zůstávají chráněná.

Zároveň jsme zpřesnili výjimku z 11. 8.: nulová opravná mzda se u pracovních míst se stravenkovým oceněním ukládá už jen tehdy, když pohledávka za stravenky skutečně chybí a mzda ji musí nést. U existujících pohledávek se nulový řádek zakládat přestal — tím mizí i zbylých zhruba 90 nulových řádků měsíčně zmíněných v tiketu 10232.

17. 8. 2026 (ZENDESK 10274, YouTrack SUPP-10861) — Změna období v daňovém prohlášení se propíše do dodatečných zvýhodnění

Když jste v růžovém prohlášení opravili Období — typicky proto, že se prohlášení nestihlo podepsat od původního měsíce — období zůstalo staré v řádcích sekce Dodatečné daňové zvýhodnění. Bylo potřeba je přepsat ještě jednou ručně a na tento druhý krok se snadno zapomnělo. Řádek si totiž období z hlavičky bral jen ve chvíli svého vzniku a další změny hlavičky už nesledoval.

Nově se změna období v hlavičce prohlášení propíše i do řádků dodatečného zvýhodnění. Změníte-li například období ze 7–12 na 8–12, řádek se sám přepne na 8–12 a přepočte se u něj částka slevy.

Řádky, u kterých jste období nastavili ručně jinak než v hlavičce, zůstávají beze změny. Typicky jde o slevu na dítě uplatňovanou jen za část roku — ta se automaticky nepřepíše a upravíte si ji sami, stejně jako dosud.

17. 8. 2026 (ZENDESK 10266, YouTrack SUPP-10853) — Vstupní dotazník: cizinecká oprávnění se konečně uloží

V novém vstupním dotazníku končilo uložení stránky s cizineckými údaji chybou Sloupec 'Residence Permit No' není součástí 'Osoby' a pracovník se nedostal dál.

Dotazník posílá od konce července i druh a číslo pobytového oprávnění s jeho platností a platnost pracovního povolení — potřebujeme je pro hlášení JMHZ. Ukládací funkce osoby ale těchto šest údajů neznala, odmítla je a spolu s nimi celou stránku. Vedlejším důsledkem bylo, že se cizinecká oprávnění nedala uložit vůbec nikde.

Nově se všech šest údajů zapíše k pracovníkovi normálně. Kdo na chybu narazil, stačí stránku dotazníku uložit znovu.

17. 8. 2026 (ZENDESK 10273, YouTrack SUPP-10860) — Slevy na dani se do PAMICA přenášejí v celé roční výši

Sleva na poplatníka se do PAMICA přenášela zkrácená podle období uvedeného v růžovém prohlášení. U prohlášení podepsaného například na srpen až prosinec se místo roční slevy 30 840 Kč poslalo 12 850 Kč. PAMICA si přitom slevu podle data od/do krátí sama, takže výsledná měsíční sleva vycházela zhruba 1 071 Kč místo 2 570 Kč — sleva se zkrátila dvakrát.

Nově se posílá celá roční částka slevy, jak ji PAMICA očekává. Období čerpání se přenáší dál beze změny (datum od a do) a krácení podle něj provede PAMICA. Stejně se to týká i daňového zvýhodnění na 1.–3. dítě.

Oprava se projeví až dalším přenosem osoby do PAMICA — u osob přenesených dříve je potřeba přenos zopakovat. Prohlášení platná na celý rok byla i dosud přenášena správně.

17. 8. 2026 (ZENDESK 10271, YouTrack SUPP-10858) — Náhled obrázkové přílohy jde spolehlivě rolovat

U některých příloh nešlo po otevření náhledu rolovat. Týkalo se to naskenovaných obrázků (JPG, PNG): sken se zobrazuje na celou šířku okna, takže dokument na výšku je zhruba třikrát vyšší než okno a bez rolování z něj byla vidět jen horní část. Posuvník u pravého okraje se přitom tvářil správně — měl velikost odpovídající délce dokumentu, ale kolečko myši ani tažení posuvníku s obrázkem nepohnuly.

Náhled obrázku používal vlastní, JavaScriptem řízené rolování. To se nastavovalo ve chvíli, kdy obrázek ještě nebyl načtený, a se skutečnou velikostí obrázku se už potom nesrovnalo. Nově náhled roluje běžným způsobem prohlížeče, takže funguje kolečko myši, klávesnice i tažení posuvníku bez ohledu na to, jak rychle se obrázek načte.

Zobrazení příloh ve formátu PDF, Word či Excel se nemění.

17. 8. 2026 (ZENDESK 10270, YouTrack SUPP-10857) — Odhlášení z pohovoru uchazeče skutečně odebere z termínu

Uchazeč, který se odhlásil z pohovoru, mohl v události zůstat: agentura ho v poli Reference viděla dál a počítal se do obsazenosti termínu, přestože si sám odhlášení potvrdil a dostal e-mail „Žádný termín se mi nehodí".

Při odhlášení i při změně termínu systém rušil původní přihlášku dotazem, který nerozlišoval, o kterou přihlášku jde — vybral libovolný záznam dané osoby, klidně účast na pohovoru z loňska nebo pověření personalistky daným termínem, a navíc vždy jen jeden. Dokud měl uchazeč jedinou přihlášku, vycházelo to náhodou správně; jakmile jich měl víc, zrušil se cizí záznam a aktuální rezervace zůstala. Ze 147 odhlášení a změn termínu za poslední tři měsíce dopadlo takto 37, tedy zhruba čtvrtina.

Nově se ruší právě přihlášky uchazeče na budoucí termíny pohovoru, a všechny — ne jen první nalezená. Pověření personalistek ani záznamy o účasti na již proběhlých pohovorech se nemažou.

Chcete-li si ověřit obsazenost termínu, otevřete událost pohovoru v kalendáři aktivit; pole Reference nyní obsahuje jen skutečně přihlášené uchazeče. Pokud jste některému uchazeči vraceli stav ručně, jeho přihlášku je stále potřeba odebrat v události — ruční změna stavu rezervaci neruší.

17. 8. 2026 (ZENDESK 10270, YouTrack SUPP-10857) — Testovací pracovník: odkaz na podpis dokumentů v nové aplikaci už není neplatný

Navázali jsme na opravu z 14. 8. Pracovník označený štítkem Testovací pracovník dostával odkaz na podpis dokumentů do nové aplikace (Stafio GO) bez přihlašovacích údajů — v odkazu chyběl přihlašovací token, takže se podpis nedal otevřít. Příčina je tatáž jako u vstupního dotazníku: adresa nové aplikace neměla u dané instance evidovaný záznam, bez kterého přihlášení nelze vystavit, a obálka přitom odešla jako úspěšně odeslaná.

Záznam jsme doplnili pro další instanci. Odkazy odeslané před opravou zůstávají neplatné — testovacímu pracovníkovi je potřeba odeslat obálku k podpisu znovu. Instance, kde na jedné databázi působí více agentur, řešíme dál samostatně: uplatní se vždy jen jeden záznam, takže ostatní agentury na téže databázi potřebují vlastní adresu.

17. 8. 2026 (ZENDESK 10269, YouTrack SUPP-10856) — Odhlášení z vlastní směny nově ve dvou fázích: Odhlásit a Omluvit

Z potvrzené směny se pracovník v mobilní aplikaci nedokázal odhlásit vůbec — karta i detail takové směny zůstávaly bez jakéhokoli tlačítka, a to i u směny na některý z příštích dnů. Odhlásit šla jen rezervace, kterou agentura ještě nepotvrdila, a ani ta ne v den konání směny. Pracovník, který na směnu nemohl přijít, tak neměl v aplikaci žádnou cestu, jak to dát vědět.

Nově se odchod z vlastní směny dělí na dvě fáze. Do stanovené lhůty před začátkem směny se nabízí červené tlačítko Odhlásit, po jejím uplynutí až do začátku směny oranžové tlačítko Omluvit. Obojí směnu uvolní stejně a nabídne ji dál ostatním; rozdíl je v tom, že pozdní odchod je zřetelně označený jako omluva. Po začátku směny už se nenabízí ani jedno.

Řídí to dva nové parametry vlastníka v Vlastník → Parametry. ASW_JOB_CANCEL_HOURS_BEFORE udává, kolik hodin před začátkem směny končí možnost se odhlásit; platí pro rezervovanou i potvrzenou směnu. ASW_JOB_EXCUSE_ENABLED hodnotou TRUE zapne tlačítko Omluvit — prázdná hodnota nebo FALSE ho nezobrazí vůbec. Dokud zůstanou oba parametry prázdné, chování se nemění: odhlásit lze jen nepotvrzenou rezervaci a jen na jiný než dnešní den.

Chcete-li obojí povolit, vyplňte ASW_JOB_CANCEL_HOURS_BEFORE třeba hodnotou 3 (pracovník se odhlásí nejpozději 3 hodiny před začátkem) a ASW_JOB_EXCUSE_ENABLED na TRUE, aby se v poslední fázi mohl aspoň omluvit. Tlačítko Omluvit můžete kdykoli vypnout zpět na FALSE, aniž byste přišli o odhlašování.

17. 8. 2026 (ZENDESK 10270, YouTrack SUPP-10857) — Odhlášení z pohovoru funguje i u naplněného termínu

Uchazeč, který si vybral termín pohovoru, se z něj nemohl odhlásit ve chvíli, kdy se termín mezitím naplnil do svého limitu. Naplněný termín totiž zmizel ze seznamu úplně — tedy i tomu, kdo na něm už byl přihlášený — a spolu s ním zmizela i volba Odhlásit se – žádný termín mi nevyhovuje, protože se nabízí jen k termínu, na kterém uchazeč stojí. Náboráři pak takový uchazeč vypadal jako neomluvený.

Nově zůstává naplněný termín viditelný tomu, kdo na něm už přihlášený je. Ostatním se stále nenabízí, takže se přes limit nikdo nepřihlásí.

Chcete-li uchazeči umožnit změnu termínu, stačí, aby použil odkaz z potvrzovacího e-mailu o pohovoru; v seznamu uvidí svůj stávající termín, všechny volné termíny svého střediska a volbu pro odhlášení.

17. 8. 2026 (ZENDESK 10268, YouTrack SUPP-10855) — Sloupec Zdroj v přehledu mezd je česky

V přehledu Mzdy → Přehled mezd ukazoval sloupec Zdroj anglické popisky Holiday Spendl¤ a Work Statement Line¤. Podle tohoto sloupce se přitom filtruje, čím je mzda vyvolaná, takže nebylo poznat, která hodnota znamená proplacení dovolené.

Nově se vypisuje Proplácení dovolené a Pracovní výkaz.

Chcete-li si vyjet všechny dovolené určené k proplacení za jedno období, nastavte v přehledu mezd filtr Období na požadovaný měsíc a Zdroj na Proplácení dovolené; výsledek pak lze uložit do Excelu tlačítkem pro export.

17. 8. 2026 (ZENDESK 10267, YouTrack SUPP-10854) — Srozumitelná hláška při změně data směny v pracovním výkazu

Když se v pracovním výkazu přepsalo pole Datum směny na jiný den, systém změnu odmítl hláškou Směna 9.8.2026 není v intervalu platnosti mezi 6.8.2026 a 6.8.2026. U jednodenního pracovního místa jsou obě data stejná, takže hláška působila jako chyba systému a hlavně neporadila, co dělat dál.

Směna patří ke konkrétnímu pracovnímu místu z objednávky a nelze ji přesunout mimo dny, na které je toto místo naplánované. Nově se u jednodenního místa vypíše ten jeden den a hláška rovnou navede na správný postup.

Chcete-li ve výkazu nahradit jeden den jiným, použijte v tabulce řádků výkazu Vyjmout práci na chybný den a poté Přidat práci (Ctrl+1) s pracovním místem na požadovaný den. Odpracované hodiny i schválení směny zůstanou zachované; výkaz musí být ve stavu Otevřeno.

17. 8. 2026 (ZENDESK 10264, YouTrack SUPP-10851) — Příchozí SMS přes BulkGate: závěr dlouhé zprávy zůstává na konci a opakovaný díl se nepřipočítá

Navázali jsme na opravu z 15. 8. Při skládání zprávy z více částí se ukázala další dvě chování brány BulkGate:

• U zprávy o třech a více částech se závěrečná (krátká) část mohla připojit dřív než část plná a skončila pak uprostřed textu. Nově platí pravidlo, že část zaplněná na maximum nikdy není poslední, takže se plné části skládají vždy před závěr zprávy.
• BulkGate opakuje předání téže části, pokud mu odpověď nedorazí včas. Opakovaný díl se dřív k textu připojil podruhé; nyní se rozpozná a zahodí.

Tři zprávy z 16. a 17. 8., kterých se to týkalo, jsme uvedli do pořádku.

U zpráv o třech a více částech platí, že BulkGate neposílá číslo dílu — pořadí plných částí proto odpovídá pořadí, ve kterém je brána předala. Dvoudílné zprávy se skládají vždy správně.

17. 8. 2026 (ZENDESK 10266, YouTrack SUPP-10853) — Odkaz na vstupní dotazník v e-mailu platí opět měsíc

Pracovník, který na odkaz vstupního dotazníku klikl později než den po odeslání e-mailu, skončil na stránce Tudy cesta nevede — Odkaz již není platný a dotazník nemohl vyplnit. Ostatním, kteří odkaz otevřeli hned, přitom fungoval normálně, takže se chyba těžko rozpoznávala.

Odkaz v e-mailu i SMS s sebou nese přihlašovací klíč s omezenou platností. Ta byla vždy jeden měsíc, ale u agentur, které mají adresu aplikace na vlastním serveru, se od konce července vydával klíč z přihlašovacího systému nové mobilní aplikace — a ten platí jen 24 hodin.

Nově se krátkodobý klíč vydává pouze pro odkazy mířící do nové mobilní aplikace. Odkazy na vstupní dotazník a na elektronický podpis platí opět měsíc. Pracovníkům, kterým odkaz mezitím vypršel, stačí pozvánku odeslat znovu — nový odkaz už bude mít měsíční platnost.

15. 8. 2026 (ZENDESK 10264, YouTrack SUPP-10851) — Příchozí SMS přes BulkGate: dlouhá zpráva je v jednom řádku a znovu vyskočí upozornění

Dlouhá SMS přijatá přes bránu BulkGate se v přehledu příchozích SMS i v komunikaci rozpadla na několik řádků po zhruba 67 znacích. Zároveň se u těchto zpráv neobjevovalo dialogové okno Nová zpráva — u SMS přijatých přes MySMS přitom obojí fungovalo správně.

BulkGate posílá každou část dlouhé zprávy samostatně a obě části dorazí do systému současně. Skládání částí se tak nikdy nestihlo uplatnit a každá část se uložila jako vlastní zpráva; ve výjimečných případech si navíc části navzájem přepsaly text. Upozornění na novou zprávu se pak nezaložilo vůbec, protože se při jeho vytváření nepodařilo určit, komu z uživatelů patří.

Nově se části jedné zprávy zpracovávají po sobě, takže se spolehlivě spojí do jednoho řádku se správným pořadím textu, a upozornění Nová zpráva dorazí všem uživatelům, kteří mají zapnutou kontrolu nových SMS — jednou za celou zprávu, ne za každou její část. Sloučený text se propíše i do konverzace v aplikaci. Zprávy, které se rozpadly dříve, jsme zpětně spojili.

15. 8. 2026 (ZENDESK 10265, YouTrack SUPP-10852) — eObjednávky: poznámka klienta je opět vidět už v předmětu potvrzovacího e-mailu

Když klient v aplikaci eObjednávky založil objednávku a připsal k ní poznámku, potvrzovací e-mail měl stejný předmět jako objednávka bez poznámky — ✅ Potvrzení vytvoření objednávky 202621287. Poznámka byla až v těle zprávy, takže se při větším počtu objednávek snadno přehlédla. Původní objednávkový systém přitom takový e-mail označoval v předmětu slovem NOTE!

Nově se předmět chová stejně jako dřív: obsahuje-li objednávka poznámku od klienta, začíná předmět textem NOTE! — například NOTE! ✅ Potvrzení vytvoření objednávky 202621287. Objednávky bez poznámky mají předmět beze změny.

Příznak se řídí poznámkou, kterou zadal klient při vytvoření objednávky. Poznámky, které si k objednávce dopíše agentura, předmět e-mailu neovlivňují. Pokud se navíc některý řádek objednávky nepodařilo obsadit, zůstává v předmětu i dosavadní upozornění ❌ ERROR! — u objednávky s poznámkou se pak zobrazí oba příznaky.

15. 8. 2026 (ZENDESK 10263, YouTrack SUPP-10850) — Formuláře: bublina Uložit po uložení zase zmizí

Na formulářích, které mají pod sebou tabulku se zaškrtávacím sloupcem — typicky Pracovní smlouva s tabulkou Dodatky (sloupec Podepsáno), dále dodatek nebo daňové prohlášení — svítila plovoucí bublina Uložit trvale. Byla vidět hned po otevření formuláře, ještě než uživatel cokoli změnil, a nezmizela ani po uložení. Nešlo tak poznat, zda jsou změny uložené, nebo na uložení teprve čekají.

Příčinou bylo rozpoznávání rozepsané editace v tabulce: zaškrtávací políčko je v tabulce zobrazené pořád (aby šlo kliknout přímo v řádku), a systém tuto trvale přítomnou buňku vyhodnocoval jako otevřený editor, tedy jako neuloženou změnu.

Nově se za rozepsanou editaci považuje jen buňka, ve které uživatel skutečně stojí. Bublina Uložit se tak objeví až při první změně a po uložení zmizí. Chování zavedené v březnu zůstává zachováno — při psaní do buňky tabulky se bublina zobrazí okamžitě, není nutné z buňky odklikávat.

14. 8. 2026 (ZENDESK 10261, YouTrack SUPP-10848) — eObjednávky: po úpravě času směny se hodiny k proplacení opět počítají podle přestávek

V klientské aplikaci eObjednávky (eobjednavky.student.cz) se po úpravě času směny do pole Odpracováno hodin dosadil prostý rozdíl časů od–do. Neodečetla se neplacená přestávka nastavená na oddělení objednávek — směna 10:00–18:00 tak ukázala 8 h místo 7,5 h — a při uložení nebo schválení se tato hodnota zapsala, jako by ji klient zadal ručně.

Stejná chyba byla v červenci opravena v aplikaci na app.student.cz (ZENDESK 10016). Aplikace na adrese eobjednavky.student.cz je ale samostatný starší program a oprava se do něj tehdy nedostala — běžela tam verze z 10. 6. 2026, do které jsme nyní opravu doplnili.

Nově aplikace po každé změně času od/do přepočítá hodiny k proplacení na serveru podle neplacených přestávek pracoviště (správně nyní spočítá i směnu přes půlnoc) a ručně zadanou hodnotu pošle jen tehdy, když ji klient v poli skutečně přepsal — jinak hodnotu dopočítá server. Možnost hodiny ručně upravit (např. proplacení přesčasu nebo dřívější odchod) zůstává zachována.

14. 8. 2026 (ZENDESK 10248, YouTrack SUPP-10835) — Úloha Změna profilu: při odmítnutí se nově zobrazí důvod

V úkolu Změna profilu (XRM – řízení vztahů → Úkoly) se schvalují změny, které si pracovník zadal v mobilní aplikaci. Když ale aplikace změnu uložit odmítla — třeba proto, že zadané číslo účtu už používá jiný pracovník — tlačítko Schválit na oko neudělalo nic: formulář se překreslil, žádost zůstala nevyřízená a nikde se neobjevilo vysvětlení proč.

Nově se důvod odmítnutí zobrazí jako chybová hláška. Stejně se chová i tlačítko Zamítnout. Samotná pravidla, která změnu odmítnou, se nemění — jen je teď vidět, co brání uložení.

14. 8. 2026 (ZENDESK 10262, YouTrack SUPP-10849) — Pracovníci: filtr sloupce Stav pracovníka už nenabízí dva názvy téhož stavu

V přehledu Pracovníci mohl filtr ve sloupci Stav pracovníka nabízet pro jeden stav dvě hodnoty — například na záložce Zájem jak Zájem, tak Čekající. Šlo o jeden a tentýž stav: „Čekající" byl pouze zastaralý výchozí popisek, který se u části záznamů udržel v mezipaměti seznamu. Věcný rozdíl mezi oběma hodnotami žádný nebyl, filtr přes jednu z nich ale našel jen část pracovníků daného stavu.

Příčinou bylo, že se popisek stavu do mezipaměti seznamu ukládal podle kontextu přihlášení, ve kterém byl záznam pracovníka naposledy změněn — u změn provedených např. z mobilní aplikace nebo systémovými úlohami se místo názvu stavu z vašeho náborového workflow uložil výchozí popisek systému.

Ukládání popisku je opraveno tak, aby vždy odpovídalo názvům stavů nastaveným ve workflow dané agentury, a stávající záznamy v mezipaměti jsme přepsali na správné názvy. Filtr tak nyní nabízí pro každý stav jedinou hodnotu. Pokud jste měli ve sloupci uložený filtr na starý popisek (např. Rovná se „Čekající"), zrušte ho — jinak přehled nic nenajde.

14. 8. 2026 (ZENDESK 10256, YouTrack SUPP-10843) — Mobilní aplikace: popisky tlačítek Zavolat, E-mail a Odeslat SMS se už nelámou uprostřed slova

Na obrazovce Profil v mobilní aplikaci jsou vedle sebe tři tlačítka pro kontakt na agenturu. Jejich popisky se lámaly uprostřed slova — místo Zavolat se zobrazovalo Zavo / lat, místo E-mail pak E- / mail a místo Odeslat SMS dokonce Odes / lat / SMS.

Příčinou bylo rozdělení šířky obrazovky: tlačítka jsou tři vedle sebe, a když se do jednoho z nich vešla ikona i text na jeden řádek, zbylo na samotný popisek jen asi 46 bodů. Do toho se nevešlo ani jedno celé slovo, takže je aplikace rozdělila. Netýkalo se to jen zvětšeného systémového písma — na běžném telefonu se text lámal vždy.

Nově se popisek, pokud se vedle ikony nevejde, přesune pod ikonu a dostane celou šířku tlačítka. Zavolat i E-mail se tak vejdou na jeden řádek a Odeslat SMS se zalomí nanejvýš v mezeře mezi slovy. Na širší obrazovce (tablet, počítač) zůstává původní podoba s ikonou a textem vedle sebe. Všechna tři tlačítka jsou nyní stejně vysoká.

14. 8. 2026 (ZENDESK 10249, YouTrack SUPP-10836) — Výběr banky: v seznamu je nově i kód banky

Ve výběru banky (u bankovního účtu pracovníka i partnera, ve vstupním dotazníku i v aplikaci pro pracovníky) se dosud nabízel jen název banky. Kdo si pamatuje spíš kód než název, musel ho dohledávat jinde.

Nabídka nyní zobrazuje kód banky a za ním její název — například 0100 - Komerční banka, a.s. Seznam je tím zároveň seřazený podle kódu a při psaní do pole se vyhledává i podle kódu, nejen podle názvu. Uložené účty ani sestavy se nemění, jde jen o popisek v nabídce.

Připomínáme, že banky se ze seznamu nemažou — v číselníku Nastavení → Kódy bank má každá banka platnost od a platnost do. Banka, která už neexistuje, se ukončí datem v minulosti a od té chvíle se v nabídce nenabízí, ale u dříve zadaných účtů zůstane její název čitelný. Smazáním záznamu by se název banky u historických účtů ztratil.

14. 8. 2026 (ZENDESK 10259, YouTrack SUPP-10846) — Mobilní aplikace – zařízení: přehled se opět načte

Nový přehled Mobilní aplikace – zařízení (registrovaná zařízení pracovníků) se od svého zavedení 11. 8. 2026 nenačetl a místo dat skončil chybovým oknem „failed to parse select parameter".

Příčinou byl zápis předvoleného filtru Aktivní na této stránce: byl uvedený jiným způsobem, než jaký přehledy používají, takže se do dotazu na server dostal prázdný název sloupce a server takový dotaz odmítl přečíst. Chyba se týkala jen tohoto jednoho přehledu, žádná data nebyla dotčena a na ostatní přehledy ani na mobilní aplikaci samotnou neměla vliv.

Filtr je nyní zapsaný standardním způsobem — přehled se načte a volba Aktivní správně omezí výpis na zařízení aktivní za posledních 7 dní.

14. 8. 2026 (ZENDESK 10190) — Zásady ochrany osobních údajů aplikace: nová stránka a seznámení uživatelů

Mobilní aplikace má nyní vlastní zásady ochrany osobních údajů (Privacy Policy), které popisují právě to, co dělá aplikace — jaké údaje zpracovává, komu je předává a jak dlouho je uchovává. Dokument vznikl také jako stránka v redakčním systému, takže si jeho znění spravujete stejně jako ostatní své právní dokumenty a nemusíte kvůli úpravě žádat o zásah do aplikace. Zároveň jsme rozšířili obrazovku, která se uživateli zobrazí po přihlášení: dosud po něm chtěla pouze souhlas se zpracováním osobních údajů, nově mu vedle toho předloží i zásady ochrany osobních údajů k seznámení. Obojí potvrdí jedním tlačítkem a o každém dokumentu zvlášť vznikne záznam s datem, časem, IP adresou a odkazem na konkrétní verzi znění — v administraci je najdete v Pracovníci → Smlouvy → GDPR souhlasy. Vydáte-li kterýkoli z dokumentů v nové verzi (jako novou stránku), aplikace si o něj při nejbližším přihlášení řekne znovu; dokumentu, který se nezměnil, se to netýká a uživatel jej znovu nepotvrzuje.

14. 8. 2026 (ZENDESK 10252, YouTrack SUPP-10839) — Mzdy: srážka pojistného u pracujícího důchodce se počítá stejně jako ve výkazu ČSSZ

Na sestavě Vyúčtování mezd nemusel sedět kontrolní součet: čisté mzdy (a v návaznosti doplatek na účet) vycházely o 1 Kč jinak, než dá přepočet hrubých mezd minus pojistné a daně uvedené na sestavě.

Příčinou byl rozdíl v zaokrouhlení u pracujícího starobního důchodce se slevou na pojistném. Výpočet mzdy srážel pojistné přímo sníženou sazbou 0,6 % se zaokrouhlením nahoru, zatímco pokyny ČSSZ předepisují zaokrouhlit zvlášť pojistné (7,1 % ze základu) a zvlášť slevu (6,5 % ze základu) — a přesně tak se částky vykazují v měsíčním hlášení zaměstnavatele (JMHZ/PVPOJ) i na Vyúčtování mezd. U některých vyměřovacích základů se oba postupy liší o 1 Kč, takže se pracovníkovi srazilo o korunu víc, než kolik za něj zaměstnavatel na ČSSZ skutečně odvádí.

Výpočet mzdy nyní sráží důchodci pojistné stejným dvoukrokovým postupem jako výkaz, takže srážky, vyúčtování i hlášení sedí na korunu na sebe. Odvody byly správné i dosud — sestava i hlášení na ČSSZ se shodovaly, platit se má podle nich. Změna se projeví u nově počítaných mezd; už spočtené mzdy se zpětně nemění (případný přepočet mzdy srážku srovná). U ostatních zaměstnanců se nic nemění.

14. 8. 2026 (ZENDESK 10218, YouTrack SUPP-10805) — Aplikace pro pracovníky: vybraná pole profilu lze pracovníkovi zamknout nebo skrýt

Blok úpravy profilu v aplikaci pro pracovníky nabízel ke změně všechna evidovaná pole. U pracovníka se smlouvou sice žádná změna neprojde bez schválení agentury (zakládá se úkol Změna profilu), přesto u některých údajů nedává smysl, aby o ně pracovník vůbec žádal — typicky pracovně-právní stav, rodné číslo nebo přepínače slev na dani, které se stejně řídí podepsaným Prohlášením poplatníka.

Jednotlivá pole profilu teď jde pro agenturu nastavit do dvou režimů: jen ke čtení (pole se zobrazí, ale nejde změnit a nelze o změnu ani požádat) a skryté (pole se v aplikaci vůbec nezobrazí). Nastavení se týká pracovníků se smlouvou; uchazeč před nástupem si profil doplňuje dál jako dosud. Zámek vyhodnocuje server, takže ho neobejde ani starší verze aplikace v telefonu.

Výchozí chování se nemění — bez nastavení zůstává profil takový, jaký byl. Nastavuje se v konfiguraci aplikace pro konkrétní agenturu, takže si můžete vybrat libovolnou podmnožinu polí; napište nám, která pole zamknout a která skrýt.

14. 8. 2026 (ZENDESK 10032, YouTrack SUPP-10616) — Testovací pracovník: odkaz do nové verze vstupního dotazníku už není neplatný

Pracovník označený štítkem Testovací pracovník dostává pozvánku do vstupního dotazníku s odkazem do nové aplikace (Stafio GO) místo do stávajícího dotazníku — díky tomu si lze novou verzi vyzkoušet, aniž by se to dotklo ostatních pracovníků. Odkaz ale končil hláškou „Odkaz je neplatný nebo vypršel, kontaktujte svého konzultanta" a dotazník se vůbec neotevřel.

Příčinou bylo, že systém k odkazu nedokázal vytvořit přihlašovací údaje: adresa nové aplikace neměla u dané instance evidovaný záznam, bez kterého přihlášení nelze vystavit. Nepříjemné bylo, že se to nijak neprojevilo — pozvánka odešla jako úspěšně odeslaná a jen v ní byl odkaz bez přihlášení, takže chyba vyšla najevo až u pracovníka, který na odkaz klikl.

Záznam jsme doplnili pro instanci, které se hlášení týkalo. Pozvánky odeslané před opravou zůstávají neplatné — je potřeba poslat pracovníkovi pozvánku znovu. Na zbývajících instancích, kde štítek zatím do nové aplikace nevede, řešíme totéž samostatně.

14. 8. 2026 (ZENDESK 10250, YouTrack SUPP-10837) — Přihláška na ČSSZ: profese (CZ-ISCO) se u smlouvy bez pozice nově dovodí z kategorie práce i po obsazení směny

Agenturám, které mají zapnuté určování profese podle pozice na smlouvě (parametr EMPLOYMENT_JOB_CLASSIFICATION_WORK_TYPE_SOURCE = CONTRACT), selhávala přihláška zaměstnance na ČSSZ (REGZEC) hláškou „Zaměstnanec … nemá vyplněnou profesi (kód ISCO)", pokud smlouva neměla vyplněnou Pozici a pracovník už byl obsazen na směnu. Dokud směna neexistovala, systém profesi správně dovodil náhradně z Kategorie práce na smlouvě; jakmile ale smlouva dostala obsazenou směnu, přednost dostala větev určování profese podle první směny, která tento náhradní dopočet neměla — a přihlášku zablokovala kontrola chybějícího ISCO.

Větev určování profese podle první směny nyní v režimu určování podle smlouvy umí stejný náhradní dopočet z kategorie práce jako ostatní větve: nemá-li smlouva pozici, vezme se první platný CZ-ISCO kód (4–5 míst) z pozic zařazených do kategorie práce smlouvy. Chování agentur s určováním profese podle odpracovaných směn (výchozí režim) se nemění. Doporučení nadále platí: nejspolehlivější je pozici na smlouvě vyplňovat — náhradní dopočet z kategorie je pojistka, ne náhrada správných dat.

Registrace nového pracovníka v nové aplikaci pro přihlašování na směny končila obecnou hláškou Chyba hned po vyplnění e-mailu a nešla dokončit. Serverová registrační funkce empl_person_reg neměla přidělené právo pro anonymní webovou roli, pod kterou registrace z aplikace běží — právo měli jen přihlášení uživatelé s rolí BASE.CLOUD nebo FULL.ACCESS, kterých se samoregistrace netýká. Role webové registrace pracovníka (EMPLOYEE_EMPLOYEE_REG_BASE) teď právo na registrační funkci dostává automaticky při aktualizaci rolí.

Při ověřování opravy se ukázala druhá vada: aplikace posílá datum narození ve tvaru 01.01.2000, server ale u registrace očekával jen tvar 2000-01-01, takže by registrace spadla na nesrozumitelnou chybu data. Registrační funkce nyní přijímá datum narození v obou podobách (i ve tvaru s lomítky).

Opraveno a ověřeno na instanci, které se hlášení týkalo (registrace projde až po potvrzovací e-mail); na ostatní instance se oprava dostane se standardní aktualizací databáze.

Na základě dalšího testování jsme registrační obrazovku téhož dne doladili: chybová hláška při odeslání neúplného formuláře nově vyjmenuje, která pole nebo souhlasy chybí (dříve jen obecné „Vyplňte"), a kalendář pro výběr data narození je přeložený — do češtiny, slovenštiny i ukrajinštiny se nyní překládají všechny vestavěné texty komponent aplikace (kalendář, výběry času, kontextové menu), které dosud zůstávaly anglicky.

14. 8. 2026 (ZENDESK 10247, YouTrack SUPP-10834) — Daňové prohlášení: výběr osoby zase nabízí založené děti a vyživující osoby

V řádku daňového zvýhodnění na formuláři Daňové prohlášení přestal dialog Výběr osoby nabízet osoby založené jako dítě, přestože v systému existovaly — našel jen běžné pracovníky. Stejně tak pole Další osoba vyživující děti nenabízelo osoby založené jako vyživující osoba. Šlo o vedlejší následek úpravy z 3. 8. 2026 (ZENDESK 10124), která dětem a vyživujícím osobám dala v hledání vlastní kategorii s vlastním detailem — výběrové dialogy se ale dál ptaly jen na kategorii původní.

Oba dialogy teď hledají i v nových kategoriích, takže založené dítě či vyživující osobu najdou stejně jako dřív; nalezené dítě se v seznamu ukazuje s popiskem Dítě místo dřívějšího zavádějícího „Pracovník". Nabídka běžných pracovníků se nemění a žádná data nebylo potřeba opravovat.

Aplikace nabízí nahrání kartičky zdravotní pojišťovny na dvou místech — ve vstupním dotazníku na stránce Zdravotní pojišťovna a na obrazovce Můj profil v sekci Doklady. Agentury, které kartičku nesbírají, ji teď mohou z obou míst skrýt.

Ve vstupním dotazníku o tom rozhoduje nový přepínač konfigurace stránky request_health_insurance_card_scan. Když se nastaví na false, zmizí výzva i tlačítko pro nahrání včetně náhledu už nahraného skenu a sken zároveň přestane být povinný pro cizince (jinak by nešlo pokračovat dál). Dlaždici na Mém profilu řídí nastavení aplikace screen.health_insurance_card.enabled, stejně jako je tomu u občanského a řidičského průkazu.

Výchozí chování se nemění — bez nastavení zůstává nahrání kartičky nabízené na obou místech jako dosud. Změna se projeví po nasazení nové verze mobilní aplikace.

13. 8. 2026 (YouTrack WAS-1691) — Smlouvy u pracovníka: tlačítko Nová sada smluv

Na kartě pracovníka v přehledu Smlouvy přibylo tlačítko Nová sada smluv, které dosud šlo vyvolat jen z přehledů pracovníků a smluv nebo z formuláře pracovníka. Sada smluv se tak dá založit přímo od smluv dané osoby, bez přecházení jinam.

Tlačítko je aktivní i bez označení řádku — pracovník se do dialogu předvyplní podle karty, na které jste. Zbytek dialogu (výběr sady, platnost, daňové prohlášení, odeslání k podpisu, tisk) zůstává beze změny.

13. 8. 2026 (YouTrack WAS-873) — Vstupní dotazník v aplikaci ukládá evidenční číslo pojištěnce bez lomítka

Cizinec zadává ve vstupním dotazníku EČP (evidenční číslo pojištěnce). Pole ho přijímalo i ve tvaru s lomítkem (900544/0004) a v této podobě ho také uložilo k pracovníkovi, přestože se EČP na ČSSZ hlásí bez lomítka. Nově se lomítko i mezery odstraní ještě před uložením — zadat je uživatel může dál, u pracovníka se ale vždy objeví jen číslice. Kontrola platnosti čísla (9–10 číslic, desetimístné dělitelné jedenácti) zůstává beze změny a na hlášení ČSSZ to nemá vliv, do XML se lomítko nikdy nedostalo.

13. 8. 2026 (ZENDESK 10246, YouTrack SUPP-10833) — Pracoviště se v přehledech ukáže hned po vytvoření smlouvy, ne až v den nástupu

Sloupce Pracoviště, Společnost, Pozice, Kategorie práce a Místo braly údaje ze smluv platných k dnešnímu dni. Smlouva se ale běžně zakládá několik dní před nástupem, takže do dne nástupu zůstávaly sloupce prázdné — a pracoviště nebylo vidět zrovna ve chvíli, kdy se pracovníkovi plánují směny. Nově se berou všechny smlouvy, které ještě neskončily, tedy i ty, které teprve začnou platit. Pracoviště se tak objeví hned po uložení smlouvy.

Smlouvy, kterým platnost skončila, ze sloupců mizí jako dosud. Sloupec Platná smlouva se nemění — ten i nadále znamená „má smlouvu platnou dnes". Změna se projeví všude, kde se tyto sloupce zobrazují: Pracovníci, Hledání v CV, Pracovníci (oprávnění), Telefonní komunikace a Kniha ubytování.

13. 8. 2026 (ZENDESK 10246, YouTrack SUPP-10833) — Sloupec Pracoviště v přehledu Pracovníci se doplní i u smluv, které začaly platit později

Sloupec Pracoviště (a stejně tak Společnost, Pozice, Kategorie práce a Místo) ukazuje pracoviště z právě platných smluv pracovníka. Hodnota se ale přepočítávala jen ve chvíli, kdy se se smlouvou něco dělo. Když se smlouva založila dřív, než začala platit — typicky večer před nástupem — spočítala se v době, kdy platná ještě nebyla, a druhý den už ji nic nepřepočítalo: v přehledu zůstalo prázdno, přestože na kartě pracovníka smlouva s pracovištěm byla. Stejně tak u smluv, které platit přestaly, zůstávalo pracoviště zobrazené dál. Rozdíl se postupně nasčítával a týkal se i sloupce Věk, který se mění o narozeninách.

Nově se tyto sloupce přepočítávají každou noc, takže smlouva platná od dnešního dne je v přehledu vidět hned ráno a skončené smlouvy z něj zmizí. Kromě toho se přehled aktualizuje okamžitě i při změně dodatku smlouvy (dodatek může mít vlastní pracoviště a platnost) — dosud se úprava samotného dodatku do přehledu nepropsala vůbec. Existující nesrovnalosti byly hromadně opraveny při nasazení, není potřeba nic dělat ručně.

13. 8. 2026 (ZENDESK 10225) — Report obsazenosti umí PDF i novější Excel (XLSX) a formát jde nastavit pro každé oddělení zvlášť

Denní report obsazenosti chodil zákazníkům výhradně jako Excel 97-2003 (.xls) a formát byl společný pro všechna oddělení, protože se bral z nastavení naplánované úlohy. Poštovní servery některých odběratelů ale starý formát příloh odmítají a report jim vůbec nedorazil. Nově má oddělení objednávek vlastní nastavení Formát reportu obsazenosti — když je vyplněné, použije se přednostně (PDF, XLS, nově i XLSX), jinak platí formát z úlohy jako dosud. Jedno oddělení tak může dostávat PDF nebo XLSX, aniž by se cokoli měnilo ostatním.

Zároveň generátor sestav ze šablon v Excelu umí nový formát XLSX (Excel 2007 a novější). Přibyl typ šablony XLSX šablona; sestavy z ní vznikají se stejným obsahem i formátováním jako dosud (styly, sloučené buňky, podmíněné formátování, vzorce, obrázky). Stávající šablony ve starém formátu fungují beze změny — přepnutí je volba u konkrétní sestavy, ne plošná změna.

12. 8. 2026 (ZENDESK 10244, YouTrack SUPP-10831) — Smazání zdravotní pojišťovny už nesmaže nahranou kartičku

Sken kartičky zdravotního pojištění je přílohou záznamu v akordeonu Zdravotní pojišťovny na kartě pracovníka, uživateli se ale zobrazuje mezi ostatními dokumenty v sekci Dokumenty. Když se pak záznam pojišťovny smazal (typicky při opravě údajů cizince, kdy se špatný záznam smaže a založí nový), zmizel s ním natrvalo i sken kartičky — v Dokumentech po něm nezůstala stopa, do koše se nedostal a v Historii změn nebylo o smazání nic, protože změny zdravotního pojištění se dosud vůbec nelogovaly. Zvenčí to vypadalo, že dokument zmizel sám od sebe.

Nově se sken při smazání záznamu pojišťovny nezahazuje, ale předá mezi dokumenty pracovníka (typ Ostatní, popis Zdravotní pojištění) — v sekci Dokumenty tedy zůstane, jen už není navázaný na pojišťovnu. Kdo chce kartičku opravdu smazat, smaže ji přímo v náhledu dokumentu; to se nemění. Zároveň se změny záznamu zdravotního pojištění (pojišťovna, platnost od/do, číslo kartičky, stav kartičky i přiložený sken) nově zapisují do Historie změn na kartě osoby, takže je vidět, kdo a kdy záznam založil, změnil nebo smazal. Historie se vede dopředně — u dříve smazaných záznamů se zpětně nedoplní.

12. 8. 2026 (ZENDESK 10238, YouTrack SUPP-10825) — REGZEC u smlouvy bez směn nenacházel zařazení pracovníka

Oprava (akce 4) i hlášení změn (akce 3) do registru zaměstnanců ČSSZ u smlouvy bez obsazených směn končily chybou „obsahuje odebranou hodnotu v .job.attrs.preplace, aktualizační XML nelze vytvořit" — typicky po opravě data nástupu u pracovníka, jehož směny se při zpracování mezd zúčtovaly na souběžné smlouvy. Předpokládané místo výkonu práce se v takovém případě má vzít ze Zařazení pracovníka (zařazení na středisko), jenže systém zařazení dohledával k datu začátku platnosti smlouvy. U celoročních rámcových smluv platných od 1. ledna se zařazení založené k datu nástupu v průběhu roku nikdy nenašlo, podání vyšlo bez místa výkonu práce a generování spadlo na výše uvedené chybě. Nově se zařazení dohledává k datu nástupu — podání ze zařazení převezme středisko (místo výkonu práce i pozici s ISCO) a oprava data nástupu jde vygenerovat. Směny, pokud na smlouvě jsou, mají i nadále přednost.

11. 8. 2026 (ZENDESK 10232, YouTrack SUPP-10819) — Přepočet mezd už nezakládá nulové opravné mzdy

Měsíční optimalizace zdravotního pojištění při uzávěrce přepočítává mzdy všech osob v období. U osob, kde přepočet nic nezměnil, se dosud ukládala opravná mzda s nulovým rozdílem — jen za červenec 2026 jich tak u jedné agentury vzniklo přes 1 200. Nulové mzdy pak překážely v příkazech k úhradě a musely se ručně „vyplácet“ nulovou platbou přes pokladnu. Nově se opravná mzda s nulovým rozdílem vůbec nezakládá; výjimkou jsou pracovní místa se stravenkovým oceněním, kde mzdový řádek může nést pohledávku za stravenky. Už existující nevyplacené nulové opravné mzdy zmizí samy při příštím přepočtu dané osoby.

11. 8. 2026 (ZENDESK 10234) — Hledání pracovníka podle telefonu nenašlo číslo napsané bez mezer

Filtr sloupce Mobil hledal číslo přesně v té podobě, v jaké je zobrazené, tedy s mezerami (+420 774 375 858). Kdo číslo napsal běžným způsobem bez mezer (774375858, +420774375858), nenašel nikoho a přehled zůstal prázdný, přestože pracovník s tímto číslem v systému je. Nově filtru na oddělovačích nezáleží — číslo jde zadat s mezerami i bez nich, s předvolbou i bez ní, a funguje i zadání jen části čísla. Platí to ve všech přehledech, kde je sloupec s telefonem: Pracovníci, Hledání v CV, Zájemci, Přehled smluv, přehledy směn a plánovací tabule, Obálky k podpisu, Pohovory, Plán osob, Hromadné SMS a maily, Historie přihlášení i Kontaktní telefon u nákladového střediska. Pole Hledat v záhlaví aplikace (Alt+Q) zvládalo všechny podoby čísla i dosud a nemění se. Pokud přehled nic nenajde, vyplatí se také zkontrolovat, jestli v něm nezůstal starší filtr v jiném sloupci — je vidět dole pod přehledem a vypne se tlačítkem Vypnout filtr.

11. 8. 2026 (ZENDESK 8902) — Stahování pošty ze schránek Microsoft 365 (Graph API)

Stahování příchozí pošty do aplikace (například vytěžování reakcí uchazečů ze schránky agentury) dosud umělo jen protokoly POP3/IMAP s přihlášením jménem a heslem. Microsoft ale u schránek Microsoft 365 přihlašování heslem definitivně vypnul (u POP3/IMAP již dříve, u SMTP od března 2026), takže schránky provozované na Microsoft 365 nešlo připojit vůbec. Aplikace nově umí poštu z takových schránek stahovat přes Microsoft Graph API s přihlášením registrované aplikace (OAuth2) — bez hesla ke schránce. U mailového účtu se zvolí typ příjmu GRAPH a vyplní se údaje aplikace registrované správcem Microsoft 365 zákazníka (tenant, client id, client secret); aplikace pak schránku pravidelně vybírá, maily ukládá do přehledu příchozí pošty včetně příloh, páruje je na osoby a zpracované zprávy ze schránky odklízí do koše. Odesílání z takové adresy se řeší beze změny přes SendGrid účet, na heslech Microsoftu nezávislý.

11. 8. 2026 (ZENDESK 10231) — Srážky běžného výživného skákaly mezi výplatami a příkaz k úhradě se lišil od hotovostní výplaty

U zaměstnavatelů, kteří vyplácejí zálohy průběžně po směnách (a mají tak rozpracovaná dvě mzdová období najednou), se srážka běžného výživného při generování převodního příkazu jednou strhla a vzápětí vrátila — na příkazu se objevovaly dvojice stejné částky s opačnými znaménky, částka k výplatě se lišila od hotovostní výplaty a srážky exekucí „skákaly do plusu i do mínusu". Příčinou bylo, že výpočet srážky za konkrétní měsíc si strop běžného výživného počítal i z nároku měsíců následujících, takže výsledek neměl ustálenou hodnotu a každý další přepočet ho „opravoval". Nově se strop počítá jen z nároku do počítaného měsíce: hotovostní výplata i převodní příkaz dávají stejné srážky, běžné výživné se za měsíc srazí přesně ve výši měsíčního nároku (pokud na něj zabavitelná část mzdy stačí) a případný dřívější přeplatek se pracovníkovi při nejbližší výplatě jednorázově vrátí.

11. 8. 2026 (ZENDESK 10182) — Notifikace do mobilní aplikace místo SMS a nový přehled Mobilní aplikace

Zprávy pracovníkům, které dosud odcházely jako placené SMS, se nově doručí jako notifikace do mobilní aplikace, pokud ji má pracovník nainstalovanou a v posledních 7 dnech ji použil. Notifikace se na telefonu zobrazí jako běžné systémové oznámení, i když aplikace není zrovna otevřená — stačí, aby jí pracovník při prvním spuštění povolil oznámení. Když notifikaci nelze doručit (pracovník aplikaci delší dobu neotevřel nebo ji odinstaloval), zpráva se automaticky pošle jako klasická SMS, takže o ni nikdo nepřijde. Opravili jsme také technickou závadu, kvůli které se zařízení pracovníků do systému vůbec neregistrovala a notifikace značkových aplikací (Emona Kroni, CALLUP, Stafio) nebylo možné doručit. V hlavní nabídce navíc přibyl přehled Mobilní aplikace — seznam pracovníků s registrovanou aplikací, stavem zařízení a datem poslední aktivity, takže je vidět, komu budou notifikace chodit místo SMS. Jedna výjimka platí vždy (doplněno 11. 8. 2026, ZENDESK 10233): jednorázové ověřovací kódy chodí výhradně SMS a do aplikace se neposílají nikdy. Týká se to kódu k elektronickému podpisu — i po klepnutí na „Poslat kód znovu“ — a stejně tak kódů pro potvrzení a změnu telefonního čísla. Slouží totiž jako druhý faktor: kód doručený do téže aplikace, ve které se podepisuje nebo ve které se číslo mění, by ověření zbavil smyslu. Platí to i do budoucna, až bude podepisování probíhat přímo v aplikaci.

10. 8. 2026 (ZENDESK 10190) — Souhlas se zpracováním osobních údajů v aplikaci: nově i po kontaktních osobách firem

Mobilní aplikace vyžaduje po přihlášení souhlas se zpracováním osobních údajů — dokud ho člověk neudělí, dál ho nepustí a nabídne mu jen souhlasit, nebo se odhlásit. Dosud se ale ptala pouze brigádníků; kontaktní osoby firem, které aplikaci používají pro objednávky, souhlas vyžádaný neměly, přestože pro ně systém eviduje vlastní znění určené firmám. Nově se souhlas vyžaduje i po nich, se stejným chováním jako u brigádníků. Druhá část opravy se týká odkazu na plné znění: tlačítko na obrazovce se souhlasem otevíralo zásady ochrany osobních údajů aplikace, tedy jiný dokument, než proti kterému se souhlas eviduje. Nově otevře přesně to znění, které člověk odsouhlasuje — brigádníkovi znění pro brigádníky, kontaktní osobě firmy znění pro firmy. Kdo už souhlas udělil, nic nového dělat nemusí. Beze změny také zůstává, že po vydání nové verze znění (jako samostatného dokumentu) si aplikace při nejbližším přihlášení vyžádá souhlas znovu.

10. 8. 2026 (ZENDESK 10217) — Změnu bankovního účtu z mobilní aplikace nešlo schválit

Když si pracovník v mobilní aplikaci změnil bankovní účet, vznikl ke schválení samostatný úkol za každé změněné pole zvlášť — jeden pro číslo účtu, druhý pro kód banky. Bankovní účet se ale ukládá jako jeden celek, ve kterém je číslo účtu i kód banky povinné, takže schválení jednoho pole samo o sobě neprošlo: u pracovníka, který zatím žádný platný účet neměl, skončilo hláškou Sloupec 'Kód banky' v 'Platební účet osoby' je povinný (a u druhého úkolu obdobně u čísla účtu), a u pracovníka s existujícím účtem vzniklo mezi schválením prvního a druhého pole nové číslo účtu se starým kódem banky. Nově se při schválení kteréhokoli z bankovních polí zapíše účet celý — chybějící údaje se doplní z ostatních čekajících žádostí téhož pracovníka, případně z jeho současného účtu — a zbývající žádosti nad účtem se tím vyřídí zároveň. Druhá část opravy se týká mazání úkolů: schválit nebo zamítnout změnu profilu jde jen z detailu úkolu, takže jeho smazáním zůstala žádost navždy nevyřízená a pracovník měl pole v aplikaci trvale zamčené odznakem Čeká na schválení, aniž by ho mohl zadat znovu. Nově se při smazání úkolu žádost automaticky zamítne, pracovníkovi přijde informace o zamítnutí a pole se mu odemkne. Žádosti, které osiřely dřív, jsme takto vyřídili.

10. 8. 2026 (ZENDESK 10221) — Stravenkový paušál bez mzdy se nedostal do příkazu k úhradě

Příkaz k úhradě zařadil stravenkový paušál jen pracovníkům, kterým se zároveň posílala mzda. Pokud měl pracovník k výplatě jen stravenkový paušál (například v daném měsíci už neodpracoval žádnou směnu a mzda byla nulová), do příkazu se nedostal vůbec a paušál šlo vyplatit jen hotovostně. Příčinou bylo, že výběr osob do příkazu vychází z předpočítaného přehledu mezd a závazků, který se obnovuje jen při změně mzdy, pohledávky nebo platby — stravenkový paušál se ale stává splatným 10. dne následujícího měsíce „sám od sebe", žádná změna ho neprovází, a výběr osob se o něm proto nedozvěděl. Nově se splatné závazky vůči pracovníkovi při sestavování příkazu ověřují přímo v aktuálních datech, takže pracovník se splatným stravenkovým paušálem se do příkazu zařadí i bez mzdy. Dosud nevyplacené paušály není potřeba nijak opravovat — nejbližší vygenerovaný příkaz k úhradě je zahrne.

10. 8. 2026 (ZENDESK 10222) — Stravenkový paušál se při přepočtu mzdy napočítal vícekrát

Přepočet mzdy (například po přepočtu zdravotního pojištění, kdy se směny přesouvají mezi smlouvami) založil pohledávku stravenkového paušálu znovu v plné výši, přestože už za dané pracovní místo existovala — pracovníkovi se tak paušál napočítal dvakrát i třikrát. Výpočet totiž při každém uložení mzdy zakládal pohledávku bez kontroly, jestli už existuje. Nově se paušál za pracovní místo založí jen jednou; další přepočty už existující pohledávku respektují. Duplicitní pohledávky vzniklé před opravou jsme odstranili — žádná z nich nebyla proplacená, výše paušálů k výplatě je nyní správně.

10. 8. 2026 (ZENDESK 10219) — Plánování směn na DPP nepočítalo s náhradou za dovolenou

Při obsazování a rezervaci směn na dohodu o provedení práce hlídá aplikace měsíční limit započitatelného příjmu (pro rok 2026 je to 11 999 Kč), nad kterým vzniká povinnost odvodů. Kontrola ale počítala jen mzdu za naplánované směny — náhradu mzdy za dovolenou (čerpanou i proplacení nevyčerpané) nezapočítávala, protože náhrada není mzdou za směnu. Osobě s dovolenou v daném měsíci tak šlo naplánovat směny až do plné výše limitu a překročení se ukázalo až při výpočtu mezd chybou o překročení limitu DPP. Nově kontrola při plánování náhrady za dovolenou započítává, jakmile je jejich částka spočítaná — plánování se tedy zastaví na limitu včetně dovolené, stejně jako to počítá mzdová uzávěrka. Stejné doplnění platí i pro obdobnou kontrolu hranice pojištění u dalších typů dohod. Směny naplánované nad limit před touto opravou zůstávají — je potřeba je ubrat ručně.

9. 8. 2026 (ZENDESK 10211) — Registrace uchazeče přes API: heslo už není povinné

Registrační formulář postavený nad standardním API (funkce person.register) musel dosud po uchazeči vždy chtít heslo — bez něj registrace skončila hláškou Musíte vyplnit heslo. Nově je parametr password volitelný, takže formulář na webu zákazníka nemusí pole pro heslo vůbec obsahovat. Když heslo nepřijde, Stafio si založí vlastní interní heslo, které se nikam neodesílá; uchazeč si své heslo nastaví později přímo v aplikaci volbou Zapomenuté heslo (na e-mail mu přijde odkaz pro nastavení hesla). Do té doby je zaregistrovaný, ale do aplikace se nepřihlásí. Registrace s heslem funguje beze změny. Zároveň jsme do dokumentace API doplnili popis parametrů emergency_contact (nouzový kontakt, u nezletilých odpovědná osoba) a domain.

9. 8. 2026 (ZD#9204 · YouTrack WAS-1813) — Obsah platebního příkazu: náhrady za nevyčerpanou dovolenou nebyly vidět

V původní (Java) aplikaci přehled Obsah platebního příkazu nezobrazoval náhrady mzdy za nevyčerpanou dovolenou — tedy mzdy, které nevznikly ze směny. Samotný příkaz k úhradě byl v pořádku a peníze odešly správně, jen v zobrazení obsahu příkazu tyto položky chyběly, takže součet zobrazených řádků nesouhlasil s celkovou částkou příkazu. Nově se tyto řádky zobrazují a mají i srozumitelný popis Náhrada mzdy za nevyčerpanou dovolenou (dříve u nich popis zůstával prázdný). Na sestavení a odeslání příkazu k úhradě nemá změna žádný vliv.

9. 8. 2026 (ZENDESK 8921) — Stejné číslo účtu u dvou pracovníků: volba „Ignorovat duplicitu" na kartě osoby nefungovala

Když dva pracovníci sdílejí jeden bankovní účet (typicky účet ubytovny nebo rodinného příslušníka), nešlo druhému z nich účet uložit ani po zaškrtnutí volby Ignorovat duplicitu. Uložení karty osoby vždy skončilo hláškou Tento bankovní účet není možné použít, protože je již použit u jiného pracovníka. Kontrola duplicity se totiž na kartě osoby spouštěla ještě dřív, než se zaškrtnutá volba stihla uplatnit — obejít to šlo jen zadáním účtu v části Bankovní účty na kartě osoby. Nově se zaškrtnutá volba respektuje a účet jde uložit rovnou. Bez zaškrtnutí zůstává vše beze změny: účet už použitý u jiného pracovníka aplikace dál odmítne a jméno druhé osoby přitom neprozradí.

7. 8. 2026 (ZENDESK 10209) — Zákaznický web s nabídkou brigád mohl po nasazení nové verze zůstat bez inzerátů

Na webu s nabídkou brigád (například arenacallup.cz) se mohly přestat zobrazovat všechny inzeráty, přestože v aplikaci zůstaly zveřejněné. Nabídka se pro rychlost čte z připravené kopie inzerátů a nasazování nové verze tuto kopii zahazovalo dřív, než stihla vzniknout nová — web tak zůstal prázdný. Chybějící kopii měla dopočítat úloha na pozadí, ta ale od 4. srpna na databázích bez plánovače končila technickou chybou, takže se nabídka už sama neobnovila. Nově se při nasazení připraví nová kopie vedle stávající a přepne se na ni, až je kompletní — web mezitím obsluhuje ta původní. Zároveň úloha na pozadí opět doběhne i tam, kde ji spouští aplikační server. Chování při zveřejňování a úpravě inzerátů se nemění.

7. 8. 2026 (ZENDESK 10207) — Tisk a odeslání smlouvy: okno se točilo donekonečna, když nebyl vybraný žádný záznam

Okno Tisk smlouvy (a stejná okna u dalších sestav) se mohlo otevřít s údajem Počet dokumentů 0 — tedy bez jediného záznamu, se kterým by mohlo pracovat. Aplikace na to nijak neupozornila a každé tlačítko se pak zachovalo jinak špatně: Tisk a Stáhnout nechaly navždy točící se kolečko bez jakékoli hlášky, Odeslat k podepsání → Odeslat hned skončilo nesrozumitelnou technickou chybou a Odeslat k podepsání → Uložit k odeslání dokonce oznámilo, že dokument byl zařazen do fronty, přestože se nezařadilo nic. Nově aplikace v takové situaci rovnou srozumitelně oznámí Není vybrán žádný záznam. a okno zůstane použitelné. Zároveň jsme okno ošetřili tak, aby se kolečko zastavilo i při jakékoli jiné neočekávané odpovědi. Chování při běžném tisku a odesílání vybraných smluv se nemění.

7. 8. 2026 (ZENDESK 10208) — Aplikace mohla během nasazování nové verze přestat odpovídat

Při nasazování nové verze se mohlo stát, že aplikace přestala načítat data — stránky se otevřely, ale přehledy zůstaly prázdné s točícím se kolečkem. Příčinou bylo, že nasazovací skript pokaždé znovu vytvářel několik databázových pravidel nad tabulkami smluv, přestože se vůbec nezměnila. Taková úprava si vyžádá výhradní přístup k tabulce, a pokud v tu chvíli běžela delší operace (například hromadný tisk složky pracovníka), zařadily se za ni všechny ostatní požadavky a aplikace se zastavila. Nově nasazování ověřuje skutečný stav těchto pravidel a nezměněných se vůbec nedotkne; pokud je navíc tabulka právě používaná, nasazení se po pěti sekundách samo ohlásí chybou místo aby čekalo. Změna se týká výhradně nasazování nových verzí, chování aplikace ani dat se nemění.

7. 8. 2026 (ZENDESK 10206) — Nešlo obsadit pracovní místo: „Hodnota SPLIT_JOBS_TO_FULLFILL_HOUR_FUND neexistuje v Parametry vlastníka"

Obsazení pracovního místa se zaškrtnutou volbou Vytvořit pracovní výkaz skončilo chybou Hodnota 'SPLIT_JOBS_TO_FULLFILL_HOUR_FUND' neexistuje v 'Parametry vlastníka'. a místo se neobsadilo. Stejná chyba mohla zastavit i potvrzení směny ze zaměstnaneckého webu a mobilní aplikace, uzavření objednávky, import objednávek nebo měsíční docházku — tedy vše, co zakládá pracovní výkaz. Příčinou bylo, že zakládání výkazu od nedávné úpravy vyžadovalo, aby parametr vlastníka SPLIT_JOBS_TO_FULLFILL_HOUR_FUND (plné využití hodinového fondu smlouvy) fyzicky existoval, přestože jeho výchozí hodnota je vypnuto. Nově se chybějící parametr chová jako vypnutý a chybu už nevyvolá; zároveň jsme parametr doplnili všem vlastníkům, aby byl vidět a nastavitelný v Vlastník → Parametry. Chování při samotném zakládání výkazu se nemění.

7. 8. 2026 (ZENDESK 10204) — Import objednávky: duplicitní řádek už nenechává pracovní místo bez směny

Když byla ve zdrojovém souboru importu tatáž osoba dvakrát na stejný den a stejné středisko (například dovolená zadaná pod dvěma smlouvami), import správně ponechal jen poslední záznam — směnu z prvního řádku smazal. Pracovní místo prvního řádku ale zůstalo obsazené, jen už bez jediné směny. Takové místo pak zablokovalo uzavření celé objednávky hláškou Není možné uzavřít objednávku, pracovní místo … neobsahuje žádné směny. a bylo nutné ho dohledat a ručně uvolnit. Nově import takové místo rovnou uvolní, takže objednávka jde uzavřít bez zásahu. Vlastní chování importu se nemění — z duplicitních řádků dál platí ten poslední.

7. 8. 2026 (ZENDESK 10202) — Výplata dovolené v hotovosti: falešná hláška „Osoba nemá zdravotní pojišťovnu"

Při vytvoření platby v hotovosti za proplacení dovolené mohla aplikace ohlásit Osoba … nemá zdravotní pojišťovnu, přestože osoba zdravotní pojišťovnu vyplněnou má. Kontrola totiž u platby za dovolenou (která nemá konkrétní směnu) vyžadovala, aby záznam pojišťovny pokrýval celou dobu platnosti smlouvy — a selhala, když byl záznam pojišťovny zapsán až po začátku smlouvy. Nově se u těchto plateb kontroluje vyplácené období (měsíc dovolené), stejně jako se u běžné mzdy kontroluje den směny. Kontrola samotná zůstává: bez pojišťovny platné ve vypláceném období se platba nevytvoří. Stejná logika vypláceného období se nyní používá i pro kontrolu podepsaných smluv (parametr Vyžadovat podepsané smlouvy) a kontrolu úplnosti osobních údajů při platbě.

7. 8. 2026 (ZENDESK 10195) — Detail JMHZ souboru: náhled XML souboru dávky

V detailu JMHZ souboru (Pracovníci → Smlouvy → JMHZ) nefungoval náhled XML souboru dávky — po kliknutí na lupu se otevřelo okno, ve kterém se soubor nikdy nenačetl. Vestavěný prohlížeč dokumentů totiž formát XML nepodporuje. Nově se XML soubor otevře v nové záložce prohlížeče s přehledným zvýrazněním struktury — stejně, jako už funguje náhled odpovědi z ČSSZ. Změna platí pro náhled všech XML souborů v aplikaci.

7. 8. 2026 (ZENDESK 10194) — Přehled JMHZ souborů: nový sloupec Období

V přehledu Pracovníci → Smlouvy → JMHZ přibyl sloupec Období s měsícem, za který se dávka podává (ve tvaru 202606 = červen 2026). Dosud bylo nutné období zjišťovat otevřením dávky a stažením XML souboru. Sloupec je vyplněný u JMHZ dávek (řádných i opravných) včetně historických; podání REGZEC se k žádnému období nevztahují, u nich zůstává prázdný.

7. 8. 2026 (ZENDESK 10192) — Uzavření objednávky: hláška o překročeném limitu DPP nově uvádí osobu

Při uzavírání objednávky se mohla objevit hláška o překročení mzdového limitu pro DPP, ale byla anglicky a obsahovala jen dvě čísla — dosaženou hrubou mzdu a limit. U objednávky se stovkami osob tak nebylo jak zjistit, koho se týká. Nově je hláška česky a uvádí jméno pracovníka a číslo smlouvy, u kontroly součtu za víc DPP téhož zaměstnavatele pak jméno a období. Vlastní kontrola se nemění — uzavření se zastaví úplně stejně jako dosud, jen teď rovnou víte, u koho máte mzdu opravit.

7. 8. 2026 (ZENDESK 10186) — Falešná hláška „MySMS error" u telefonů odesílajících přes BulkGate

Uživatelům, kteří mají u svého účtu navázaný telefon pro odesílání SMS, se v aplikaci opakovaně (klidně i dvacetkrát denně) objevovala červená hláška MySMS error — Error communicating with MySMS. Check the password. a u telefonu v nastavení přibyl chybový text o špatných přihlašovacích údajích. S odesíláním SMS to přitom nesouviselo: aplikace se pokoušela přihlásit do služby MySMS i u telefonu, který přes MySMS vůbec neposílá a žádné heslo k ní nemá — a přihlášení s prázdným heslem samozřejmě selhalo. Hláška tak mohla obviňovat i bránu, která odesílala zcela bez problémů, a komplikovala hledání skutečné příčiny při potížích s SMS. Nově se do MySMS přihlašuje pouze telefon, který je pro MySMS skutečně nastavený; falešné hlášky i chybový text u telefonu jsme odstranili.

7. 8. 2026 (ZENDESK 10185) — Mobilní aplikace: volná směna zmizí z nabídky, jakmile začne

V nabídce volných směn zůstávala dnešní směna vidět celý den — i dlouho po svém začátku (například směna od 6:00 se v 10:30 pořád nabízela), přestože se na ni už nešlo přihlásit a karta neměla žádné tlačítko. Viditelnost nabídky se totiž řídila jen datem směny, kdežto možnost přihlásit se i časem jejího začátku. Nově nabídka končí přesně ve chvíli, kdy končí možnost se přihlásit — směna zmizí ze seznamu i z teček v kalendáři. Vlastní směny pracovníka se nemění: rezervovaná i obsazená směna zůstává v aplikaci vidět i v průběhu a po skončení.

Zároveň přibyl parametr vlastníka ASW_JOB_FREE_RESERVE_HOURS_BEFORE (Vlastník → záložka Parametry), kterým si nastavíte, jak dlouho před začátkem směny se na ni jde ještě přihlásit. Prázdná hodnota (výchozí, dosavadní chování) znamená, že na dnešní směnu se přihlásit nelze a z nabídky zmizí, jakmile začne. Číslo — třeba 3 — povolí přihlášení i tentýž den, nejpozději 3 hodiny před začátkem; pracovník se tak ráno přihlásí na odpolední směnu. O stejný čas dříve směna zmizí i z nabídky, aby se nenabízelo něco, na co se už přihlásit nedá.

Opraven také překlep na tlačítku u volné směny — nově je popsané Rezervovat.

6. 8. 2026 (YouTrack WAS-1785) — Příkaz k úhradě: volba Zahrnout pouze osoby s podepsanými smlouvami začala fungovat

Checkbox Zahrnout pouze osoby s podepsanými smlouvami v dialogu Vytvořit příkaz k úhradě se sice dal zaškrtnout, ale na výsledek neměl žádný vliv — mzdy k nepodepsaným smlouvám se do příkazu dostaly stejně. Hodnota z formuláře se kvůli dvěma neshodám v pojmenování k filtru vůbec nedostala. Nyní se volba uplatní: mzda u nepodepsané smlouvy se do příkazu nezahrne a osoba se objeví v přehledu Nezahrnuté s důvodem.

6. 8. 2026 (YouTrack WAS-1743) — Příkaz k úhradě: nová volba Zahrnout jen osoby bez zadlužení

V dialogu Vytvořit příkaz k úhradě přibyl checkbox Zahrnout jen osoby bez zadlužení. Když ho zaškrtnete, do příkazu se nedostanou platby pro pracovníky, kteří mají neuhrazenou pohledávku některého z exekučních druhů (pokud není vyřízena manuálně), nebo mají na kartě pracovníka v sekci Zadlužení nastaveno cokoli jiného než Žádný dluh. Takoví pracovníci se objeví v přehledu Nezahrnuté s vysvětlením, proč platba nevznikla. Volba je ve výchozím stavu vypnutá, takže bez zaškrtnutí se příkaz sestavuje úplně stejně jako dosud.

6. 8. 2026 (YouTrack WAS-1084) — Dodatky: doplněny údaje Vloženo a Změněno

Formulář dodatku měl dole popisky Vloženo a Změněno, ale zůstávaly prázdné — u dodatku se totiž vůbec neevidovalo, kdo a kdy ho založil nebo naposledy změnil (na rozdíl od smlouvy, kde se tyto údaje ukazují běžně). Dodatek si nyní tyto údaje ukládá a formulář je zobrazuje stejně jako u smlouvy. U dodatků založených dříve zůstanou popisky prázdné, dokud se dodatek znovu neuloží.

6. 8. 2026 (YouTrack WAS-1700) — Přehledy: hromadné zakládání úkolů a událostí

Všude, kde jde z přehledu odeslat hromadnou SMS nebo e-mail, přibylo vedle těchto ikon nové tlačítko Aktivita s volbami Úkol a Událost. Označte pracovníky v přehledu a jedním krokem jim založte aktivitu — funguje to i s volbou „označit vše", kdy se do pole Komu doplní počet vybraných osob stejně jako u hromadné SMS.

Úkol a událost se přitom chovají odlišně, protože úkol nemůže mít víc řešitelů: označíte-li deset osob a zvolíte Úkol, vznikne deset samostatných úkolů, každý pro jednu osobu. Zvolíte-li Událost, vznikne jedna událost s deseti účastníky. Ostatní údaje (název, popis, termín, kopie, reference) jsou u všech založených úkolů shodné.

Na přehledech uchazečů výběrového řízení a na osobách připojených k partnerovi se do nové aktivity předvyplní i výběrové řízení, respektive partner — ale jen tehdy, když je u všech označených řádků stejný. Dosavadní položky Nová událost a Nový úkol z nabídky „Nová…" byly do nového tlačítka přesunuty.

6. 8. 2026 (YouTrack WAS-1571) — Mobilní aplikace: úplné ocenění vlastní směny

U vlastní obsazené směny se v aplikaci zobrazovala jen část mzdového výměru — typicky pouze odměna za práci (například „0 Kč/pr."), zatímco ve Stafiu měla směna „50 Kč/h. + 150 Kč/h. + 0 Kč/pr.". Aplikace totiž brala ocenění z řádku objednávky, kde ještě není hodinová sazba navázaná na konkrétní smlouvu. Nově se u vlastní směny — na kartě směny, v jejím detailu i v přehledu Moje směny a Archiv — ukazuje stejný výměr jako ve Stafiu. U volných nabídek zůstává ocenění řádku objednávky, protože sazba podle smlouvy vzniká až obsazením směny.

6. 8. 2026 (YouTrack WAS-1679) — Mobilní aplikace: přečtené notifikace přestanou být zvýrazněné

Na úvodní obrazovce se smlouvami a dokumenty měla v sekci Notifikace každá zpráva červenou tečku „nepřečteno" a tučný text — natrvalo. Zvýraznění nezmizelo ani po otevření obrazovky Notifikace, kde se přečtení ukládá, ani po odhlášení a novém přihlášení. Nově tečka i tučné písmo zmizí u zpráv, které už pracovník přečetl.

6. 8. 2026 (YouTrack WAS-1572) — Mobilní aplikace: srozumitelný popis u změny hesla

Okno Změna hesla (Profil → Můj profil) vybízelo k zadání aktuálního hesla, přestože takové pole ve formuláři není — stačí dvakrát zadat nové heslo. Popis nyní odpovídá skutečnosti.

6. 8. 2026 (YouTrack WAS-1570) — Mobilní aplikace: hvězdička oblíbené směny má barvu podle kalendáře

Hvězdička u oblíbené směny svítila zlatou barvou, zatímco tečka Oblíbené v kalendáři i její vysvětlivka v legendě jsou oranžové. Hvězdička na kartě směny i v detailu směny nyní používá stejnou oranžovou barvu, takže je na první pohled zřejmé, ke které tečce v kalendáři patří.

6. 8. 2026 (ZD#10154 · YouTrack SUPP-10738) — Přehledy: z „označit vše" lze jednotlivé řádky odškrtnout

Doplnění včerejší úpravy (viz záznam z 5. 8. 2026). Kdo potřebuje zpracovat celý filtr až na několik záznamů — třeba označit 200 objednávek a pět z nich vynechat — udělá to nově přímo: zaškrtne vše a nechtěné řádky odškrtne. Odškrtnuté řádky zůstanou odškrtnuté i po dolistování dalších stránek a hromadná akce je vynechá. Zaškrtávátko v záhlaví přejde do mezistavu, aby bylo poznat, že výběr není úplný.

Zaškrtávátko v záhlaví se přitom chová takto: je-li zaškrtnuté, kliknutím se režim „označit vše" ukončí a výběr se zruší celý. Je-li v mezistavu (tedy něco je odškrtnuté), kliknutím se označí zase všechno a dřívější odškrtnutí se zahodí. Výběr i odškrtnuté řádky se ruší také při změně filtru nebo vyhledávání.

6. 8. 2026 (ZD#9060 · YouTrack WAS-1777) — Nový přehled Změny profilu

Změny profilu odeslané pracovníky z mobilní aplikace byly dosud vidět jen jednotlivě v úkolech typu „Změna profilu". Nově je v menu Pracovníci → Smlouvy → Změny profilu souhrnný přehled všech žádostí: kdo změnu poslal, který údaj, původní a nová hodnota, stav (čeká na schválení / schváleno / zamítnuto), případný důvod zamítnutí a kdo žádost vyřídil. Schvalování zůstává v detailu úkolu.

6. 8. 2026 (ZD#10174 · YouTrack SUPP-10758) — Mobilní aplikace: minimální pauza mezi směnami podle pracoviště

Při samoobslužné rezervaci směny hlídala aplikace napříč celým Stafiem natvrdo 3 hodiny mezi směnami a nastavení Minimální pauza mezi směnami v detailu pracoviště se používalo jen při obsazování směny agenturou — pracovník si tak mohl vzít navazující směnu, kterou pravidla pracoviště nedovolují. Nově se při rezervaci z aplikace uplatňuje hodnota nastavená u pracoviště a hláška řekne konkrétní počet hodin (např. „Mezi směnami musí být pauza alespoň 16 h.“). Tři hodiny zůstávají jako spodní mez, takže u pracovišť bez vyplněné pauzy se nic nemění.

Protože tohle nastavení nově řídí i samoobslužné rezervace, přibylo pole Minimální pauza mezi směnami (h) přímo do detailu pracoviště (záložka Základní údaje, sekce Ostatní). Dosud existovalo jen v databázi a nastavit ho mohla pouze podpora.

Zároveň zelený pruh „Máte naplánovanou směnu…“ na úvodní obrazovce zůstával viset i poté, co už pracovník žádnou budoucí směnu neměl — například po přihlášení jiného účtu na totéž zařízení ukázal směnu předchozího uživatele. Pruh se nyní při každém načtení úvodní obrazovky zahodí, když žádná nadcházející směna neexistuje.

6. 8. 2026 (ZD#9060 · YouTrack SUPP-9640) — Žádost o výmaz osobních údajů maže i fotografii pracovníka

Agenda „Požadavek na úpravu osobních údajů“ (detail osoby → záložka Ostatní) při vyřízení žádosti typu Zapomenutí nebo Výmaz nově odstraní kromě ostatních osobních údajů i profilovou fotografii pracovníka (včetně fotografie nahrané z mobilní aplikace).

6. 8. 2026 (ZD#10156 · YouTrack SUPP-10740) — Standardní API: registrace z webu zákazníka zná pracoviště, střediska a nouzový kontakt

Standardní zákaznické API (POST /rpc/call) dostalo dva nové endpointy pro registrační formulář na vlastním webu zákazníka: department.list vrací pracoviště a cost_center.list střediska („chci pracovat jako“), volitelně zúžená na vybrané pracoviště — formulář tak umí dvoustupňový výběr pracoviště → střediska a nabídku si zákazník řídí sám přiřazením pracovišť a středisek API účtu přímo ve Stafiu. Registrace person.register nově přijímá nouzový kontakt (u nezletilých odpovědná osoba), který se ukládá do profilu pracovníka na stejné místo jako z mobilní aplikace, a volitelný parametr domain určující šablonu potvrzovacího e-mailu (token z přihlášení jménem a heslem doménu nenese a registrace by bez něj skončila chybou). Referenční ukázková aplikace na api-demo.stafio.cz všechny novinky předvádí v registračním formuláři.

Návazné zpřesnění předchozí opravy: neomluvená absence se v měsíčním hlášení dosud odečítala od započtených dnů pojištění na všech souběžných smlouvách pracovníka u téhož zaměstnavatele, přestože směna patří konkrétní smlouvě. ČSSZ takové formuláře přijímala, ale doba důchodového pojištění vykázaná na ELDP tím byla u ostatních smluv o den či více kratší. Nově se absence odečítá jen formuláři smlouvy, na jejíž směně vznikla; směny bez vazby na smlouvu se dál počítají všem smlouvám pracovníka. Vykazování přesčasů se nemění.

6. 8. 2026 (ZD#10171 · YouTrack SUPP-10755) — JMHZ: neomluvená absence mimo pojistný interval už neshazuje celé hlášení

Formulář měsíčního hlášení odečítal od započtených dnů pojištění všechny neomluvené absence pracovníka v měsíci — i ty, které nastaly před vznikem účasti na pojištění dané smlouvy (typicky u souběžné dohody s přihláškou k pojištění až koncem měsíce). U pracovníka s jednodenní účastí a starší absencí tak formulář vykázal 0 započtených dnů, ale nenulový vyměřovací základ, což ČSSZ odmítá nepropustnou vadou 20059 (kontrola 59, část 5) — a s jediným vadným formulářem pokaždé zamítla na vstupní kontrole celý balík 1 000 formulářů. Přesně to šest týdnů drželo ve smyčce hlášení AS 04/2026: každé týdenní opravné kolo skončilo „Celá dávka zamítnuta", ČSSZ přitom část formulářů z odmítaných dávek potichu zpracovávala a protokoly pak vracely stovky navazujících vad 40251/40238.

Nově se od pojistné doby odečítají jen absence ležící uvnitř pojistného intervalu formuláře (jiné se nevykazují ani v odečítaných dobách) a přibyla pojistka podle katalogu kontrol: klesnou-li odesílané započtené dny na nulu, vyměřovací základ ELDP se vykáže jako 0 — stejné pravidlo, které už platilo pro celoměsíční nemoc, se nyní vyhodnocuje z odesílané hodnoty započtených dnů (pokrývá tedy i kombinaci nemoci s absencí a doplatek mzdy po skončení smlouvy). Oprava je nasazená na všech databázích.

6. 8. 2026 (ZD#10153) — Mobilní aplikace: dashboard podle pracoviště a odkazy na novou verzi podpisu a dotazníku

Konfiguraci mobilní aplikace, kterou backend posílá po přihlášení, může nově upravit automatizace vlastníka podle přihlášeného pracovníka — dosud platila jen jedna společná pro celou firmu. Typicky se tak dá řídit varianta úvodní obrazovky: pracovníci pracovišť, kde se chodí na směny, uvidí směnový dashboard, ostatní (např. na HPP) dokumentový, tedy smlouvy, dokumenty k podpisu a upozornění. Automatizace se zakládá v Administrace → Systémové → Automatizace jako typ Proces nad procesem Platform_Brand_Ptrg, takže si seznam pracovišť udržuje zákazník sám.

Zároveň přibyl přepínač, kterým vlastník přejde na novou verzi vstupního dotazníku a elektronického podpisu pro všechny pracovníky najednou. Odkazy v pozvánce do dotazníku i ve výzvě k podpisu pak vedou do nové mobilní aplikace (a nesou k ní příslušné přihlášení) místo staršího webového portálu; dosud to šlo zapnout jen jednotlivé osobě štítkem Testovací pracovník.

6. 8. 2026 (ZD#7429 · YouTrack SUPP-7855) — Dokumenty: stažení jen vybraných souborů

Panel Dokumenty doplňuje hromadné akce z 30. 7.: vedle tlačítka Stáhnout vše přibylo Stáhnout vybrané — zaškrtnutím karet lze označit jen některé skeny a stáhnout je v jednom ZIP archivu dokumenty.zip, se stejným přečíslováním stejnojmenných souborů. Zaškrtávátka a Vybrat vše jsou nově dostupné na všech panelech Dokumenty, tedy i tam, kde dokumenty nelze mazat (např. přílohy přijaté pošty) — tam slouží jen pro výběr ke stažení, tlačítko Smazat vybrané se dál nabízí pouze s právem mazání.

6. 8. 2026 (YouTrack WAS-1773) — Přehled smluv se načítá a exportuje výrazně rychleji

Přehledy smluv — Smlouvy, vyhledávací přehled Smlouvy s rozšířenými sloupci o pracovníkovi i panel Smlouvy v kartě pracovníka — braly data z pohledu, který u každého řádku počítal i údaje o první směně (Datum první směny, Zdroj data první směny) — a to i tehdy, když tyto sloupce nebyly zobrazené ani exportované. U větších agentur se tím prodražilo jak otevření přehledu, tak export.

Nově všechny tři používají připravenou definici, která počítá jen ty sloupce, které jsou opravdu potřeba. Na instanci s 36 tisíci smlouvami se první stránka přehledu načte za 6 sekund místo 108, panel v kartě pracovníka za 1 sekundu místo 2,6 a export všech 31 843 smluv trvá 23 sekund místo 111 (proti stavu před opravou z předchozí novinky, kdy vůbec nedoběhl). Zobrazená data ani chování přehledů se nemění.

6. 8. 2026 (ZD#10169 · YouTrack SUPP-10753) — JMHZ: kontrola příjmu na neregistrované smlouvě běží na všech databázích a zná i stornované registrace

Kontrola z 21. 7. (ZD#10053), která zastaví generování měsíčního hlášení, když je příjem zadaný na smlouvě neregistrované u ČSSZ (bez ID PPV), zatímco osoba má jinou smlouvu s přiděleným ID PPV, byla dosud nasazená jen na části databází. Právě tento případ přitom stál za šestitýdenní smyčkou hlášení 05/2026 u jednoho zákazníka (ZD#10169): na smlouvě se stornovanou registrací (REGZEC 8) zůstala vystornovaná mzda v nulovém součtu, formulář se proto dál odesílal s interním číslem smlouvy místo ID PPV a ČSSZ ho odmítala nepropustnou vadou 20262 — a s ním na příjmu pokaždé celý druhý balík podání (245 formulářů), takže se zbytek hlášení nikdy nezpracoval.

Kontrola je nově nasazená na všech databázích a její hláška výslovně pokrývá i vystornovanou mzdu se součtem 0 Kč: i nulové mzdové řádky na stornované či neregistrované smlouvě je potřeba přesunout na registrovanou smlouvu — jinak smlouvu drží v hlášení.

6. 8. 2026 (ZD#10167 · YouTrack SUPP-10751) — JMHZ: nahrání protokolu hlídá, že soubor patří právě tomu podání

Import protokolu ČSSZ dosud ověřoval jen variabilní symbol, identifikátor hlášení a období — ty jsou ale shodné pro řádné podání i všechna opravná hlášení téhož měsíce. Soubory protokolů z datové schránky přitom mají pro všechna kola stejný název, takže se snadno stalo, že se k podání omylem nahrál protokol ke staršímu kolu. Takový import prošel bez chyby a formuláře podání označil jako přijaté, přestože ČSSZ ve skutečném protokolu část z nich zamítla. Další opravné hlášení pak zamítnuté formuláře poslalo znovu jako opravy formulářů, které ČSSZ neeviduje, a ČSSZ je vracela s vadou 40238 — hlášení se tak točilo v kruhu, i když v aplikaci vypadalo téměř hotové.

Nově import porovná datum podání uvedené v protokolu s okamžikem odeslání vybraného podání a soubor patřící jinému kolu odmítne se srozumitelnou hláškou, ke kterému podání nahraný protokol patří.

6. 8. 2026 (ZD#10165 · YouTrack SUPP-10749) — Export přehledu do souboru zvládne i desetitisíce řádků

Export většího přehledu na server (tlačítko Export, který se připraví na pozadí a pošle odkazem ke stažení) končil u rozsáhlých dat chybou. V Úlohách na pozadí pak úloha Export to CSV skončila ve stavu Chyba s trváním přesně pět minut — tolik má úloha na dokončení vyhrazeno. U přehledu Smlouvy s více než třiceti tisíci řádky se to stávalo pokaždé, export tedy nešlo stáhnout vůbec.

Příčiny byly dvě, obě v přípravě souboru. Sloupce počítané funkcí (například Elektronický podpis) si databáze pro každý řádek znovu vyhodnocovala celý postup místo toho, aby ho použila opakovaně, a samotný soubor se skládal řádek po řádku tak, že se s každým dalším řádkem přepisoval celý dosavadní obsah — u velkého exportu tedy práce rostla s druhou mocninou počtu řádků.

Nově se počítané sloupce vyhodnocují jednotným postupem pro celý export a soubor se skládá najednou. Zmíněný export smluv se tím zkrátil z „nedoběhne za pět minut" na dvě minuty a zrychlení se týká všech serverových exportů, ne jen přehledu smluv.

6. 8. 2026 (ZD#10170 · YouTrack SUPP-10754) — JMHZ: protokol s vadou 40226 už neoznačí přijaté formuláře jako zamítnuté

Když ČSSZ v protokolu k měsíčnímu hlášení vrátila vadu 40226 (v hlášení chybí individualizované součásti, které registr zaměstnanců očekává — například po stornu registrace, které se v registru ČSSZ dosud nepromítlo), vyhodnotilo Stafio celý protokol jako zamítnutí celého podání: všechny dosud nerozhodnuté formuláře podání označilo jako nepřijaté a doporučilo odeslat nové řádné hlášení. To bylo špatně — podle katalogu kontrol ČSSZ je vada 40226 výjimka, která podání nezamítá (výsledkem je částečné přijetí) a chybějící součásti se doplňují běžným opravným hlášením. Nové řádné hlášení by naopak ČSSZ zamítla jako duplicitní (vada 40326) a příští opravné hlášení by zbytečně poslalo už přijaté formuláře znovu jako nové — ČSSZ je pak vrací s vadou 40251 „ID zaměstnání již použito".

Nově se vada 40226 při nahrání protokolu (i při dotazu na stav zpracování) vyhodnotí správně: přijaté formuláře zůstanou přijaté, import se dokončí a v hlášce se zobrazí detail vady se seznamem chybějících součástí a pokynem doplnit je opravným hlášením.

5. 8. 2026 (ZD#9981 · YouTrack SUPP-10565) — REGZEC: oprava údajů hlídá chybějící ID pojistného vztahu

Do hromadné opravy údajů v registru zaměstnanců ČSSZ (REGZEC akce 4 se společným odůvodněním) se mohly dostat i smlouvy, kterým ČSSZ nikdy nepřidělila ID pojistného vztahu — typicky proto, že jejich původní přihláška byla zamítnuta a nová se po opravě dat už nepodala. Pojistný vztah pak v registru ČSSZ neexistuje, oprava nemá co opravovat a ČSSZ celý řádek zamítne s vadou 002 Neuveden povinný údaj ID pojistného vztahu.

Nově se taková smlouva do hromadné opravy vůbec nezařadí — vykáže se v seznamu přeskočených se srozumitelným vysvětlením a doporučením podat pro ni novou přihlášku (po vyjmutí zamítnutého řádku z původní dávky). Stejná kontrola zastaví i individuální opravu jedné smlouvy, která by dopadla stejně.

5. 8. 2026 (ZD#10154 · YouTrack SUPP-10738) — Přehledy: „označit vše" platí pro celý filtr

V přehledech (například Objednávky) šlo zaškrtávátkem v záhlaví tabulky označit vše, ale označila se jen právě načtená část řádků. Jakmile uživatel sjel níž a tabulka dolistovala další řádky, ty už označené nebyly a zaškrtávátko v záhlaví se samo odškrtlo. Hromadná akce — třeba Uzavřít u objednávek — se pak podle toho, kde byl přehled zrovna odrolovaný, provedla jen nad tou částí řádků, která zůstala označená. Práci s větším filtrem tak bylo nutné dělat po částech.

Nově označení vydrží: řádky, které se dolistují, se doznačí samy a zaškrtávátko v záhlaví zůstane zaškrtnuté. Hromadná akce se provede nad všemi záznamy odpovídajícími nastavenému filtru, ne jen nad viditelnou částí.

Výběr padá při změně filtru nebo vyhledávání, po ní je tedy potřeba označit vše znovu. Odškrtávání jednotlivých řádků z takového výběru přibylo hned druhý den, viz záznam z 6. 8. 2026 výše.

5. 8. 2026 (ZD#10158 · YouTrack SUPP-10742) — Žádosti o změnu profilu: žádné prázdné žádosti a srozumitelný název údaje

Když pracovník v mobilní aplikaci uložil číslo bankovního účtu, vznikly v přehledu Úkoly tři úkoly ke schválení místo dvou — kromě čísla účtu a kódu banky i úkol na IBAN, který pracovník vůbec nevyplňoval, s prázdným popisem IBAN: — →. Aplikace totiž při uložení tuzemského účtu pro jistotu vymaže pole IBAN a toto vymazání se dosud vyhodnotilo jako změna, i když žádný IBAN uložený nebyl. Pracovníkovi navíc zůstalo pole IBAN v aplikaci zamčené s odznakem Čeká na schválení, dokud takový úkol někdo nevyřídil. Totéž nastávalo opačně u pole Předčíslí při přepnutí na IBAN.

Nově se vymazání údaje, který stejně žádnou hodnotu neměl, bere jako žádná změna — úkol nevznikne a pole zůstává pracovníkovi přístupné. Skutečné vymazání vyplněné hodnoty se posuzuje beze změny, tedy jako žádost ke schválení. Prázdné žádosti, které takto vznikly dříve, jsme odstranili.

Druhá část se týká detailu úkolu Změna profilu. V tabulce s porovnáním Původní / Po změně se u většiny údajů zobrazoval technický název sloupce — u bankovního účtu například account_no nebo bank_code. Nově se všude ukáže český název údaje (Číslo účtu, Kód banky, IBAN, …), stejný jako v popisu úkolu.

5. 8. 2026 (ZD#10157 · YouTrack SUPP-10741) — eObjednávky: přihlášení už nezastaví výpadek jiné instance

Klienti se nemohli přihlásit do eObjednávek — přihlašovací obrazovka odpověděla technickou hláškou Could not query the database for the schema cache. Retrying. a dál nepustila. Nešlo ani založit nový klientský účet. Přitom přihlašovací údaje byly v pořádku a databáze dané agentury běžela bez potíží.

Příčina byla v tom, jak přihlašování hledá, do které instance uživatel patří. Nenajde-li účet v databázi, kam požadavek dorazil, ptá se postupně ostatních instancí. Dosud stačilo, aby jediná z nich odpověděla nečekanou chybou, a hledání se okamžitě ukončilo — a to i tehdy, když ta správná instance byla teprve na řadě. Právě to se stalo: jedna z instancí měla po údržbě dočasně nedostupné rozhraní a odpověď z ní se zobrazila všem přihlašujícím se klientům.

Nově se instance, která odpoví chybou, přeskočí a hledání pokračuje dál. Přihlášení tak závisí jen na dostupnosti té databáze, ve které účet skutečně je. Pokud se účet nenajde nikde, odpověď zůstává stejná jako dosud — Neplatné jméno nebo heslo. Mobilní aplikace a přihlášení přes login.stafio.cz se tato změna netýká, ty se takto chovaly už dříve.

4. 8. 2026 (ZD#10142 · YouTrack SUPP-10726) — Mobilní aplikace: souhlas se zpracováním osobních údajů se ukládá a vyžaduje po přihlášení

Registrační obrazovka mobilní aplikace sice nabízela zaškrtávátko Souhlasím s GDPR a bez něj registraci nedokončila, ale zaškrtnutý souhlas se nikam neukládal — v přehledu GDPR souhlasy po něm nezůstala žádná stopa. Po přihlášení se souhlas neřešil vůbec, takže pracovník, který se zaregistroval v aplikaci, mohl aplikaci používat bez jediného uloženého souhlasu. Na webu je přitom tato kontrola dávno zavedená: bez souhlasu s aktuální verzí znění se do sekce Moje nedostane nikdo.

Nově aplikace obojí dohání. Souhlas zaškrtnutý při registraci se uloží stejně jako na webu — s datem, časem a IP adresou, a proti konkrétní verzi dokumentu. Po přihlášení se navíc zobrazí blokující obrazovka Zpracování osobních údajů všem, kdo souhlas s právě platnou verzí uložený nemají; bez odsouhlasení aplikace dál nepustí, druhou možností je odhlášení. Jakmile agentura zveřejní novou verzi znění, aplikace si o souhlas řekne znovu — web i aplikace přitom čtou tutéž konfiguraci, takže se nastavuje na jednom místě.

Agentur, které souhlas v systému nastavený nemají, se změna netýká — obrazovka se jim neobjeví. Pro klientskou část (eObjednávky) byl navíc opraven odkaz na znění souhlasu: mířil na souhlas pro brigádníky, nově vede na souhlas pro firmy.

4. 8. 2026 (ZD#10141 · YouTrack SUPP-10725) — Mobilní aplikace: občanský a řidičský průkaz lze v profilu pracovníka skrýt

V mobilní aplikaci nabízel profil pracovníka v sekci Doklady nahrání občanského průkazu (přední i zadní strana) a řidičského průkazu. Některé agentury tyto doklady evidovat nesmějí, proto jdou nově obě dlaždice pro danou aplikaci vypnout — pak se nezobrazí ani náhled dříve nahraného skenu a pracovník nemá jak nový sken nahrát. Už uložené skeny se nemažou, jen se v aplikaci nenabízejí.

Ve výchozím stavu zůstávají obě dlaždice zapnuté, takže pro ostatní agentury se nic nemění. Vypnuto je zatím jen v aplikaci Agentury STUDENT. Ostatní doklady — kartička zdravotní pojišťovny, výpis z rejstříku trestů a u cizinců cestovní pas a povolení k pobytu — zůstávají beze změny.

4. 8. 2026 (ZD#10145 · YouTrack SUPP-10729) — Zapomenuté heslo: vždy stejná odpověď a žádný nefunkční odkaz

Obrazovka Zapomenuté heslo odpovídala pokaždé jinak podle toho, komu zadaná adresa patří. U neregistrované adresy vypsala Neplatné jméno nebo heslo, jinde Není možné poslat ztracené heslo, neboť e-mail není zaregistrován — z odpovědi tak šlo zjišťovat, které e-maily v systému jsou a které ne. Nově odpoví vždy stejně: Zaslali jsme vám informace o tom, jak nastavit nové heslo. Odkaz přitom dorazí jen na skutečně registrovanou adresu, na ostatní se nepošle nic.

Druhá část opravy se týká portálů určených jen pro pracovníky. Když o nový odkaz požádal kontakt zákazníka, e-mail sice přišel, ale po vyplnění nového hesla obrazovka skončila chybou role „null" does not exist a heslo se nenastavilo. Takový odkaz se teď vůbec negeneruje a obrazovka odpoví stejnou hláškou jako ve všech ostatních případech. Pracovníků se změna nijak nedotýká — odkaz jim chodí a funguje beze změny.

Třetí část se týká portálů na vlastní adrese agentury. Pokud tutéž e-mailovou adresu měla i osoba jiné agentury, mohl odkaz dosud odejít té druhé — nebo neodejít vůbec. Nově se na takové adrese hledá jen mezi osobami dané agentury. Ve sdílené aplikaci Stafio, kterou používá více agentur společně, se nic nemění.

4. 8. 2026 (ZD#10139 · YouTrack SUPP-10723) — Mobilní aplikace: zablokovaný pracovník se už nepřihlásí

Mobilní aplikace při přihlašování nekontrolovala stav osoby, takže se do ní přihlásil i pracovník, který má v Stafiu stav Zablokovaný. Týkalo se to i pracovníků, kteří si účet zrušili sami tlačítkem Zrušit účet v profilu — zrušení účtu sice smaže e-mail i telefon a osobu zablokuje, ale přihlašovací jméno a heslo zůstávají, takže se pracovník mohl přihlásit zpět úplně stejnými údaji jako předtím. Na webu byla kontrola v pořádku, chyběla jen v mobilní aplikaci.

Nově aplikace přihlášení osoby ve stavu Zablokovaný odmítne hláškou Přihlášení se nezdařilo. Pracovníků v ostatních stavech se změna nijak netýká. Chování při zrušení účtu zůstává jinak beze změny — karta osoby, smlouvy, odpracované směny i mzdy zůstávají zachované a agentura může účet obnovit vrácením stavu na Aktivní a doplněním kontaktů, které se ukládají do poznámky u osoby.

4. 8. 2026 (ZD#10145 · YouTrack SUPP-10729) — Nastavení nového hesla z e-mailového odkazu opět funguje

Pracovník, který si nechal poslat odkaz na změnu hesla, sice odkaz v e-mailu dostal, ale po zadání nového hesla mu obrazovka Nastavení nového hesla vrátila chybu permission denied for function password_set_new8 a heslo se nenastavilo. Postiženi byli všichni pracovníci i externí zákazníci přihlašující se do mobilní aplikace; přihlášení pod uživatelským účtem Stafia problém nemělo.

Příčinou bylo chybějící oprávnění: funkce pro nastavení hesla se v červnu vyměnila za novou verzi, ale role, pod kterou aplikace odkaz z e-mailu zpracovává, ji neměla povolenou. Oprávnění je doplněné na všech databázích, takže odkaz z e-mailu nové heslo nastaví napoprvé. Na samotné obrazovce ani na pravidlech pro heslo se nic nemění.

4. 8. 2026 (ZD#10143 · YouTrack SUPP-10727) — Zapomenuté heslo: shodný e-mail u více osob už nezastaví odeslání odkazu

Obrazovka Zapomenuté heslo v mobilní aplikaci skončila nesrozumitelnou databázovou hláškou more than one row returned by a subquery used as an expression, pokud zadaný e-mail nebo přihlašovací jméno patřilo více než jedné osobě — třeba když se táž adresa objevila u dvou karet osob. Odkaz na nastavení nového hesla se v takovém případě vůbec neodeslal.

Nyní aplikace duplicitu zvládne a odkaz pošle první nalezené osobě, stejně jako kdyby byla adresa v systému jen jednou. Totéž se opravilo i u přihlašování, kde tatáž chyba mohla přihlášení shodit, pokud dvě osoby sdílely přihlašovací jméno. Na hlášky při neznámém jménu nebo hesle se nic nemění.

4. 8. 2026 (ZD#10150 · YouTrack SUPP-10734) — Mobilní aplikace: tečky v kalendáři se počítají podle nastaveného filtru

Kalendář na úvodní stránce mobilní aplikace kreslil tečky bez ohledu na filtr. Po jeho nastavení tak den mohl mít tečku Volné, přestože seznam směn pod kalendářem hlásil Pro tento den nejsou směny — tečky se počítaly ze všech směn, filtr se použil jen na seznam.

Nově se do kalendáře promítá tentýž filtr jako do seznamu dne. Firma, provozovna a přepínač jen oblíbené omezí, které směny se do teček počítají — den bez odpovídající směny zůstane prázdný. Filtr podle stavu nechá jen tečku daného stavu: Volné ponechá volné směny, nabídnuté výměny a oblíbené, Obsazené, Rezervované a Náhradník vždy jen tečku vlastní směny v tomto stavu. Legenda pod kalendářem se přizpůsobí — vysvětluje jen tečky, které jsou v zobrazeném měsíci opravdu vidět. Bez nastaveného filtru se kalendář chová stejně jako dosud.

4. 8. 2026 (ZD#10146 · YouTrack SUPP-10730) — Mzdy podle oddělení objednávek: přehled se filtruje okamžitě místo řádů minut

Přehled Měsíční souhrn mezd podle oddělení objednávek a místa práce (v Stafiu pod Pracovní agentura → Mzdy, na webu Mzdy podle pracoviště) se po zadání filtru nedočkal výsledku — grid zůstal prázdný a dotaz běžel v řádu minut, aniž by ohlásil chybu. Přehled totiž musel nejdřív spočítat všechny mzdy v celé historii a teprve pak z nich vybral zadané období a společnost.

Nově se zadané období, společnost i osoba použijí hned při čtení mzdových záznamů, takže se zpracuje jen to, co je opravdu potřeba. Dotaz na jednu společnost a jedno období, který dřív trvalo přes 6 minut, se vrátí do vteřiny; načtení posledních tří měsíců za všechny společnosti trvá několik vteřin. Zobrazovaná čísla se nijak nemění — jde čistě o zrychlení.

4. 8. 2026 (ZD#10137, ZD#10138 · YouTrack SUPP-10721, SUPP-10722) — Osoby: opraveno chybové okno „kurzor get_value_ se již používá" při otevření karty osoby

Otevření karty osoby v klientovi Stafio končilo chybovým oknem „kurzor „get_value_" se již používá" a karta se nenačetla. Chyba se objevila po úpravě zdravotních pojišťoven z 3. 8., která zavedla zemi pojištění — pole Zdravotní pojišťovna, Stav karty a Platnost od/do dočasné karty si zemi přihlášeného uživatele zjišťovala v nevhodnou chvíli a databáze dotaz odmítla.

Načítání těchto polí je opravené, karta osoby se otevře normálně. Zobrazované hodnoty se nemění — pojišťovna i stav karty se dál berou podle země přihlášeného uživatele.

3. 8. 2026 (ZD#10133 · YouTrack SUPP-10717) — Mobilní aplikace: pracovní výkaz jde stáhnout i odeslat přímo z přehledu směn

Tlačítka Stáhnout výkaz a Odeslat výkaz byla dosud jen v detailu směny — pracovník musel směnu nejdřív rozkliknout. Nově se obě nabízejí přímo na kartě směny v přehledu: na úvodní stránce pod kalendářem, v Seznamu směn i v Mých směnách. Objeví se u směn, na které je pracovník obsazený nebo přidělený, na vlastním řádku pod tlačítkem Odhlásit. Archiv směn zůstává beze změny — u proběhlých směn už výkaz existuje.

Zároveň se opravilo stahování výkazu v prohlížeči: dokument se připravuje několik vteřin a otevření se v té době tvářilo, že se nic nestalo (prohlížeč ho vyhodnotil jako nevyžádané vyskakovací okno). Nyní se výkaz spolehlivě otevře v nové záložce, a to jak z přehledu, tak z detailu směny. Připomínáme, že stažením výkazu si pracovník výkaz zároveň zakládá — vzniká ve stavu Otevřený (neschválený).

3. 8. 2026 (ZD#10135 · YouTrack SUPP-10719) — Mobilní aplikace: v detailu směny je kontakt na personalistu, který objednávku založil

Detail směny v mobilní aplikaci nově ukazuje řádek Kontakt se jménem a telefonem uživatelského účtu, který danou objednávku založil. Pracovník tak vidí, na koho se obrátit, přímo u směny — u volných i u vlastních — a nemusí kontakt hledat jinde. Řádek se objeví pod sazbou, hned nad poznámkou a mapou.

Pokud účet, který objednávku vytvořil, nemá u sebe vyplněný telefon, řádek se nezobrazí — telefon se doplňuje v Uživatelé. Kontakt se ukazuje jen tam, kde si to zákazník přeje; ve výchozím stavu ho aplikace zobrazuje, u Agentury STUDENT a Emona Kroni zůstává skrytý.

3. 8. 2026 (ZD#10061 · YouTrack SUPP-10645) — Objednávky: pracovníka bez smlouvy přihlášené na ČSSZ nelze potvrdit méně než 72 hodin před akcí

Potvrzení pracovníka na akci nově kontroluje, zda má jeho smlouva přidělené IDPPV, tedy zda je nahlášená na ČSSZ. Pokud IDPPV chybí a do začátku směny zbývá 72 hodin nebo méně, potvrzení se odmítne hláškou „Smlouva pracovníka XY není přihlášena na ČSSZ. Méně než 72 hodin před začátkem akce může pracovníka potvrdit pouze uživatel s rolí Supervisor." Dřív než 72 hodin před akcí se nic nemění — na nahlášení smlouvy je ještě čas.

Výjimku má nová role Supervisor, jejíž držitelé smí pracovníka potvrdit kdykoli a přebírají odpovědnost za jeho nahlášení. Roli přiděluje správce v Uživatelé, takže okruh oprávněných osob lze měnit bez zásahu do nastavení. Kontrola se týká jen potvrzení v Stafiu — přihlášení pracovníka přes webový portál, hromadný import ani přepočty uzavřených akcí neomezuje. Smlouvy o dílo, které IDPPV nikdy nemají, jsou z pravidla vyňaté.

3. 8. 2026 (ZD#10132 · YouTrack SUPP-10716) — Mobilní aplikace: stažení pracovního výkazu funguje i u směny, ke které výkaz ještě nevznikl

Tlačítka Stáhnout výkaz a Odeslat výkaz v detailu směny končila technickou hláškou „Hodnota 'JOB_COUNT_PER_WORK_STMT' neexistuje v 'Parametry vlastníka'.", pokud k dané směně ještě neexistoval pracovní výkaz. U směn s již založeným výkazem stažení fungovalo.

Nově se chybějící výkaz založí přímo při generování sestavy — stejně, jako to od 19. 7. dělá sekce Dokumenty v detailu směny. Stažení i odeslání výkazu e-mailem tedy projde napoprvé. Pozor: stažením výkazu si pracovník pracovní výkaz zároveň zakládá — vzniká ve stavu Otevřený (neschválený).

3. 8. 2026 (ZD#10130 · YouTrack SUPP-10714) — Úkoly: srozumitelná hláška při vkládání přílohy ke smazanému úkolu

Když se příloha vkládala k úkolu, který mezitím zmizel — typicky proto, že ho někdo smazal v jiném okně a v tom vašem zůstal otevřený —, systém vložení odmítl technickou hláškou „Hodnota '123456' neexistuje v 'Činnost'.". Z interního čísla nebylo poznat, co se stalo ani co s tím dělat.

Nově se v této situaci objeví „Záznam v 'Činnost' byl odstraněn." Stačí tedy obnovit stránku (F5) a přílohu vložit k aktuálnímu úkolu. Kontrola navíc proběhne dřív, než se soubor začne ukládat.

3. 8. 2026 (ZD#10134 · YouTrack SUPP-10718) — Mzdy: proplacení dovolené má vlastní vysvětlení místo obecného „Náhrada mzdy"

Mzda vzniklá proplacením nevyčerpané dovolené se v přehledu odměn i v platebním příkazu popisovala obecným textem „Náhrada mzdy". U běžných mezd se vysvětlení skládá z údajů pracovního výkazu (období, hodiny, sazba, zakázka), jenže proplacení dovolené žádný výkaz nemá, takže zbyl jen tento nic neříkající text.

Nově se u těchto mezd zobrazuje „Náhrada mzdy za nevyčerpanou dovolenou", tedy pojmenování podle § 222 odst. 2 zákoníku práce. Text se počítá při zobrazení, takže se změna projeví i u dříve vytvořených proplacení dovolené. U mezd z pracovních výkazů se nic nemění.

3. 8. 2026 (ZD#10119 · YouTrack WAS-1727) — Srážky: nové logické typy se srážkou v plné výši (exekuce a insolvence mimo třetinový výpočet)

V konfiguraci typů srážek přibyly tři nové logické typy: Exekuce – srážka v plné výši, Insolvence – srážka v plné výši a Insolvence přednostní – srážka v plné výši. Chovají se stejně jako logický typ „Pohledávka" — sráží se celá neuhrazená částka bez třetinového výpočtu a nezabavitelného minima — a hodí se pro dva časté případy: blokaci výplat, dokud exekutor či insolvenční správce nesdělí, jak srážet, a insolvence, kde se má srazit vše a odeslat správci.

Rozdíl proti „Pohledávce": srážky pod novými typy se správně vykazují v atributu 10116 „Srážky ze mzdy evidovány" měsíčního hlášení JMHZ a na výplatní pásce se přiřazují do měsíce, ve kterém se skutečně srážely. Pokud dnes vedete skutečné exekuce či insolvence pod typem s logickým typem „Pohledávka", stačí u typu srážky změnit logický typ — výše srážek ani způsob práce se nezmění.

3. 8. 2026 (ZD#10128 · YouTrack SUPP-10712) — Mzdy: přesun slevy na dani na jinou společnost se po přepočtu skutečně projeví

Když se pracovníkovi se souběhem u dvou společností přesunula sleva na poplatníka z jedné společnosti na druhou (úpravou období daňových prohlášení), mzdy se sice automaticky přepočítaly, ale sleva zůstala u původní společnosti a nová ji nedostala — v přehledu Mzdy měsíčně původní společnost dál ukazovala „Použito se slevou" a nová „Nepoužito". Opakovaný přepočet nepomohl.

Příčinou byla interní měsíční „rezervace" daňového prohlášení z dřívějšího výpočtu mzdy: přepočet ji nemazal, takže původní společnost si slevu držela navždy a druhé společnosti ji výpočet odmítl přiznat (prohlášení už bylo ten měsíc „použito jinde"). Nově se rezervace při každém přepočtu odvozuje znovu z aktuálního stavu prohlášení, takže se sleva po změně období správně přesune. Mzdy pracovníků dotčených při dnešních úpravách jsme přepočítali.

3. 8. 2026 (ZD#10124 · YouTrack SUPP-10708) — Vyhledávání: děti z daňového prohlášení mají vlastní detail

Děti a další vyživující osoby zapsané v daňovém prohlášení (sleva na dítě) se ve fulltextovém našeptávači nabízely jako Uchazeč a klepnutí otevřelo prázdný formulář Nový pracovník — záznam vypadal, jako by v systému zároveň byl i nebyl. Karta pracovníka totiž tyto pomocné záznamy záměrně nezobrazuje.

Nově mají tyto záznamy ve vyhledávání vlastní typ Dítě resp. Vyživující osoba (včetně samostatného přepínače ve výsledcích hledání) a klepnutí otevře jejich vlastní detail se jménem, rodným číslem a datem narození.

Současně jsme z vyhledávacího indexu uklidili „duchy" — záznamy kontaktů a osob smazaných v minulosti, které se v našeptávači dál nabízely, ale nešlo je otevřít. Mazání kontaktů, interních zaměstnanců a klientů nyní odstraňuje i jejich záznam ve vyhledávání.