Nová verze Helios iNuvio 3.0.2026.1101

Řady platebních transakcí V editoru Řady platebních transakcí bylo přidáno pole pro přednastavení tiskového formuláře. Při tisku dokladu platební transakce přes akci Tisk → Tisk formulářem (F8) se přednostně použije přednastavený tiskový formulář. Pokud si uživatel na Řadě platebních transakcí tiskový formulář nepřednastaví, pak se při tisku zobrazí seznam tiskových formulářů k výběru.

Adresa příjemce platby (ISO 20022) Na bankovním spojení lze nově nastavit Adresu příjemce pro export (záložka 2 - Platební příkazy, oddíl [1] Export). Uživatel má na výběr: dle vazby - viz. základní vazba na organizaci či zaměstnance na bankovním spojení (záložka 1 - Bankovní spojení, oddíl [2] Vazba). Toto nastavení je výchozí. jiná adresa - uživateli se zpřístupní nová pole pro zadání adresy. Povinné atributy jsou Obec a Země. dle jiné organizace - nutno vybrat z číselníku organizací Cílem této úpravy je, aby bylo možné na bankovním spojení zadat skutečnou adresu příjemce platby.

Skutečná adresa příjemce platby může být odlišná od vazby (např. Bankovní spojení týkající se exekuce zaměstnance. Toto bankovní spojení má vazbu na zaměstnance, ale příjemcem platby je exekutor.) nebo ji lze využít v případě, kdy bankovní spojení nemá vazbu (např. Bankovní spojení pro odvody z mezd (sociální pojištění, daně apod.)). Nové nastavení se netýká vlastní organizace, tj. na organizaci č. 0 nejsou tato pole viditelná. V přehledech Bankovní spojení, Řádky tuzemských platebních příkazů a Zahraniční platební příkazy je možné zobrazit nové sloupce Adresa příjemce platby.

Na funkcionalitě generování platebních příkazů (z fakturace, mezd, salda, leasingu) se nic nemění. Bankovní pluginy budou postupně upravovány, aby v exportu přihlížely k novému nastavení.

Upraveno dohledávání kurzu na hlavičce a řádku bankovního výpisu (sjednocení s jinými přehledy systému). Hlavička bankovního výpisu Po změně data výpisu se datum kurzu a kurz dohledají znovu podle nastavení Jak hledat kurz. Dohledají se i tehdy, když byl kurz předtím zadaný ručně. Kurz se hledá od data výpisu, ne od data kurzu. Dřív se při nastavení „kurz předchozího dne“ datum kurzu s každým přepočtem (i při změně měny) posunulo o další den zpět.

Nový kurz se uloží do hlavičky a trigger s ním přepočítá úhrady na řádcích, stejně jako při ruční změně kurzu. Řádek bankovního výpisu Ručně zadané datum kurzu, i u druhého kurzu pro třetí měnu, dohledá přesný denní kurz k tomuto dni (např. 30. 9. → kurz z 30. 9.) bez posunu podle nastavení. Po smazání data kurzu se kurz dohledá podle nastavení jako dřív. Změna data úhrady přepočítá datum kurzu, kurz a počet jednotek podle nastavení Jak hledat kurz.

Platí jen při nastavení Kurz pro řádky brát z = řádku výpisu a jen u řádku v cizí měně. Při nastavení “z hlavičky výpisu” k dohledávání pro řádky výpisu nedochází. Společné Když se kurz nenajde, kurz a počet jednotek jsou 1 a datum kurzu zůstane prázdné. Již uložené řádky se nepřepočítávají, změna platí jen při editaci.

Na Firemní platební kartě je nové nastavení „Text vč. částky CM“ (zaškrtávátko vedle pole „Text dokladu platební transakce“). Pole je v editoru Firemní platební karty viditelné, pokud je navázáno bankovní spojení v cizí měně. Výchozí stav je zaškrtnuto. Existujícím platebním kartám s bankovním spojením v cizí měně se nastaví zaškrtnuté, tzn. nezměněné chování. Generování platební transakce v CM z řádku bankovního výpisu: zaškrtnuto: text jako dosud, tj.

Transakce: <částka> <měna> - <text podle nastavení Text na kartě> , nezaškrtnuto: jen <text podle nastavení Text na kartě> , bez „Transakce: … - “.

Upraveno chování pole číslo protiúčtu řádku bankovního výpisu (vč. vzoru řádku bankovního výpisu). Pokud je číslo protiúčtu prázdné, pak se při výběru bankovního spojení naplní údaji z vybraného bankovního spojení. Pokud je číslo protiúčtu naplněné (ručně nebo importem), pak se změnou/výběrem bankovního spojení nezmění. Důvodem změny je, aby importované údaje nebyly přepisovány výběrem bankovního spojení.

Import výpisů z BankApp. Při importu výpisů automatem mohlo dojít k tomu, že se nanaimportovaly kódy bank. Opraveno.

V procesu přípravy a účtování bankovního výpisu se chybně na řádku bankovního výpisu nastavoval semafor Výsledek příprava účtování. Chyba se vyskytla v případě, že uživatel ručně doplnil účetní účet na řádek výpisu. Po zaúčtování řádku do Deníku se semafor chybně změnil na červenou barvu, tj. chybu. Opraveno.

Adresa príjemcu platby (ISO 20022) Na bankovom spojení je možné odteraz nastaviť Adresu príjemcu pre export (záložka 2 - Platobné príkazy , oddiel [1] Export ). Používateľ má na výber: podľa väzby – viď základná väzba na organizáciu alebo zamestnanca na bankovom spojení (záložka 1 - Bankové spojenie , oddiel [2] Väzba ). Toto nastavenie je predvolené. iná adresa – používateľovi sa sprístupnia nové polia na zadanie adresy. Povinnými atribútmi sú Obec a Štát.

podľa inej organizácie – je potrebné vybrať organizáciu z číselníka organizácií. Cieľom tejto úpravy je umožniť zadať na bankovom spojení skutočnú adresu príjemcu platby. Skutočná adresa príjemcu platby sa môže líšiť od adresy vyplývajúcej z väzby (napr. bankové spojenie týkajúce sa exekúcie zamestnanca. Toto bankové spojenie má väzbu na zamestnanca, ale príjemcom platby je exekútor). Prípadne ju možno využiť v situáciách, keď bankové spojenie nemá žiadnu väzbu (napr.

bankové spojenie pre odvody zo miezd – sociálne poistenie, dane a pod.). Nové nastavenie sa netýka vlastnej organizácie, t. j. pri organizácii č. 0 nie sú tieto polia viditeľné. V prehľadoch Bankové spojenie , Riadky tuzemských platobných príkazov a Zahraničné platobné príkazy je možné zobraziť nové stĺpce Adresa príjemcu platby. Na funkcionalite generovania platobných príkazov (z fakturácie, miezd, salda a leasingu) sa nič nemení. Bankové pluginy budú postupne upravované tak, aby pri exporte zohľadňovali nové nastavenie.

ICS dovoz - do tiskového zdroje Poplatky (xPoplatky) u položek deklarace bylo přidáno pole Datum vyměření (DatumVymereni). Datum vyměření poplatku tak lze použít v uživatelských tiskových sestavách.

ECS vývoz - číslo položky licence v Předložených dokladech bude do elektronické deklarace generováno vždy, když bude vyplněno (dosud bylo omezení jen na doklady typu Licence).

ICS dovoz - do Nastavení parametrů, záložka 9 - Kontroly byla přidána nová oblast 2 - Výpočet cla s jednou kolonkou pro seznam předložených dokladů, které má výpočet cla ignorovat při nabízení k vyplnění. Kolonka má výchozí hodnotu Y126. Pokud bude Výpočet cla nabízet výběr chybějících dokladů, uvedené kódy z výběru vyřadí. Tímto se potlačí opakované dotazy na doklad Y126, případně i na další, které si do kolonky doplníte (oddělené čárkou).

ICS dovoz - Úprava akce Výpočet cla (posílá i upřesnění režimu z hlavičky).

Úprava akce “Kopie předchozích dokladů z 1 položky”. Akce nepřebere hrubou hmotnost z cílové položky, pokud je v 1. položce více předchozích dokladů s MJ=KGM.

Při načtení Povolení k vykládce se mohlo stát, že nebyly načteny závěry. Nyní opraveno.

ICS dovoz - Do editoru pro záruky (záložka 4, skupina Zajištění celního dluhu) přidáno tlačítko “Součet cla z položek”, které do kolonky “Výše” vysčítá vypočtené clo z položek deklarace. Do součtu NENÍ zahrnuta případná spotřební daň ani DPH.

ICS dovoz - při načtení potvrzení opravy celního prohlášení (CZ404C) se na položkách deklarace nově aktualizují údaje podle celního úřadu: celní nomenklatura, doplňkový kód, země původu, množství, hrubá a čistá hmotnost, cena ve fakturační měně, celní hodnota a statistická hodnota. Platí pro opravu s dodatečně vyměřeným clem i bez něj. Provedené změny se zobrazí v seznamu změn po načtení zpráv. V seznamu změn se informace o založených a smazaných položkách nově zobrazují samostatně, ne u první položky.

ECS vývoz, NCTS tranzit - podpora zpráv ve verzi ECS 1.18 a NCTS 1.21: z popisu zboží, značek nákladových kusů a dalších textových údajů se při odeslání odstraňují na začátku a na konci textu nově i speciální mezery, které celní správa odmítá.

ICS dovoz - zpřesněna kontrola stavů deklarace, při kterých je možné generovat jednotlivé zprávy.

Samostatný odpis - přidán export odepisované výše zajištění, pokud je vyplněna ICS dovoz - možnost poslat skeny dokladů zprávou CZ471C i před přidělením MRN ICS dovoz - přidána kontrola pravidla RN0107 pro zásilky malé hodnoty (nutnost uvádět identifikátory výrobků od 1.11.2026).

ICS dovoz - upraveno načtení poplatků z dodatečného výměru cla (CZ404C). Do deklarace na záložku 5 byl přidán atribut “Poplatky celkem” pro celkovou výši vyměřených poplatků. V atributu “Poplatky” zůstane jako dosud informace o výši naposledy vyměřených poplatků. V platebním výměru bude nově i datum vyměření poplatku pro možnost odlišení dříve vyměřeného cla a dodatečně vyměřeného (nebo vráceného) cla. U kolonky “Poplatky celkem” lze kliknout na tlačítko se třemi tečkami, které zobrazí přehled dříve vyměřených poplatků.

ICS dovoz - po načtení zprávy CZ404 s celním výměrem po propuštění bude stav deklarace přepnut na “Doměřené clo” (dosud by přepínán na “Celní dluh”) Oba uvedené stavy byly přidány do nastavení automatického posílání emailů při změně stavu deklarace.

Celní deklarace – Analýza chyb opět zobrazí popis chyby z chybové zprávy celní správy při odmítnutí deklarace podepsané nesprávným certifikátem.

ICS Dovoz - při podání deklarace (CZ415C) bez vyplněného deklaranta končil export chybou Incorrect syntax near '='. Opraveno.

ICS dovoz - opravena chyba „NULL není platné desetinné číslo“ při výpočtu cla v položce deklarace. Chyba nastávala u zboží, na které se kromě běžného cla vztahuje více antidumpingových nebo vyrovnávacích cel se stejným základem (např. clo z celní hodnoty a dvě antidumpingová cla z hmotnosti). V takovém případě se nyní do položky uloží celková částka cla a sazba cla zůstane nevyplněná.

Ověření organizací přes Finstat nyní funguje i s vlastní licencí Finstatu. Do globální konfigurace přibylo pole FinStat API privátní klíč, které se vyplňuje spolu s veřejným klíčem (dříve FinStat API klíč); oba klíče zákazník obdrží od Finstatu. Bez privátního klíče Finstat ověření odmítal chybou Invalid verification hash. Privátní klíč se zobrazuje skrytě, tlačítkem vedle pole jej lze zobrazit a zase skrýt. Pole pro veřejný klíč je prodloužené na 128 znaků.

Bez vyplněného veřejného klíče se dál používá vestavěný klíč.

Přehledy Došlá pošta (131) a Odeslaná pošta (132) jsou nově dostupné v HELIOS API včetně zápisu – záznamy pošty lze přes API číst, zakládat, upravovat, mazat i tisknout. Při založení stačí zadat schránku: pořadové číslo, období podle data a údaje ze schránky se doplní stejně jako v editoru, po zadání organizace nebo zaměstnance se doplní adresa. Platí stejná omezení jako v editoru, např. poštu s uzavřeným pohybem nelze měnit.

REST API – DIČ organizací: sloupce Skupinové DPH (SkupinoveDPH) a Hodnotu DIČ DPH na organizaci automaticky neaktualizovat (HodnotuDicDPHnaOrganizaciNeaktualizovat) lze nově zadat při založení DIČ i změnit. Při zadání nebo změně DIČ přes REST API se z něj odstraní mezery a odřádkování na začátku a na konci, stejně jako v editoru. Aktuální DIČ plátce a neplátce DPH se přes REST API nastavuje novými akcemi přehledu DIČ organizací: dicOrg_aktualni_dic (nastavení aktuálního DIČ plátce DPH), dicOrg_aktualni_dic_neplatce (aktuální DIČ pro neplátce DPH, jen při zapnutém kontrolním hlášení DPH) a dicOrg_zruseni_aktualniho_dic (zrušení nastavení aktuálního DIČ).

Akce se chovají stejně jako odpovídající akce v přehledu DIČ organizací v Helios iNuvio. Opraveno: založení dalšího DEČ (DIČ končícího -EX) téže organizace a země v editoru DIČ organizací mohlo skončit chybou „DIČ je již nastaveno jako aktuální pro neplátce DPH“.

Organizace – ověření v registru ARES z editoru organizace už nehlásí rozdíl v názvu nebo adrese, který ve skutečnosti neexistuje. K chybě docházelo u znaků jako Ř, ů nebo ě, pokud měl SQL server nebo databáze nastavené jiné třídění než české.

Doplnili jsme použití konfigurace proxy serveru (Globální konfigurace → Firemní konstanty → Proxy server) i pro dotazy do registrů ARES, FinStat a do Insolvenčního rejstříku. Typické je například použití v přehledu Organizace, menu Akce → Rejstříky: Aktualizace/ověření dle ARES Aktualizace/ověření dle FinStat ČR-Hromadné ověření v Insolvenčním rejstříku.

Hromadné ověření v Insolvenčním rejstříku Akce ČR-Hromadné ověření v Insolvenčním rejstříku je nově v přehledech Oběhu zboží (Akce → Další akce) a v Účetním deníku a Účetním deníku celkem (Akce → skupina Kontroly). Ověří organizace z označených dokladů nebo řádků deníku, každou jen jednou; řádky bez organizace se vynechají. Výsledné okno je stejné jako při spuštění z číselníku organizací. Akci uvidí jen uživatel s právem na hromadné ověření v IR.

V Účetním deníku není v oddělené databázi. V Nastav přehledů Oběhu zboží a Deníku je nová vazba Organizace v Insolvenčním rejstříku. Nedostupnost ISIR Při chybě spojení nebo chybě na straně ISIR se dotaz zopakuje (3 opakování s čekáním 10, 20 a 30 s, časový limit dotazu 60 s). Na jedné organizaci se čeká nejvýš 5 minut. Organizace, kterou se nepodaří ověřit, se přeskočí a ověřování pokračuje. Datum a čas poslední kontroly IR se nezmění, příští opakovaná kontrola v ten samý den organizaci ověří znovu.

Po 5 neověřených organizacích za sebou se ověřování ukončí (ISIR zjevně neběží). Organizace ověřené v daný den se znovu neověřují. Opakované spuštění automatu tak ověří jen zbytek. Místo hlášky u každé chyby se na konci zobrazí jeden souhrn neověřených organizací s důvodem. V automatu se s ním naloží podle nastavení chybových hlášek automatu, ověřování už na chybě neskončí. Chybová hláška nese skutečnou příčinu (např. timeout), aby šlo zjistit, co se u zákazníka děje.

Aktualizace knihovny pro práci s tokeny JWT (JOSE 4.0.2) na serveru Inuvia. Přihlašování integrovaných aplikací pomocí clientId funguje dál, algoritmy podpisu HS256, HS384 i HS512 jsou podporované beze změny. Upozornění pro partnery a integrátory: server nově přísněji kontroluje kódování clientId. Hlavička i obsah tokenu musí být kódované přesně podle RFC 7515 (Base64URL): bez doplňkových znaků „=“ na konci, se znaky „-“ a „_“ místo „+“ a „/“ a bez mezer a zalomení řádků.

Dosud server nepřesně kódovanou hlavičku nebo obsah toleroval, nově takový clientId odmítne s chybou „Invalid clientId“. Podpis tokenu se takto kontroloval už dřív. Týká se jen aplikací, které clientId skládají vlastním kódem. Aplikace, které token vytvářejí běžnou knihovnou JWT, ho kódují správně a změna se jich nedotkne. Doporučujeme ověřit přihlášení integrace na betaverzi.

REST API: opraveno čtení přehledu Platební transakce (firemní platební karty), které vždy skončilo chybou Access violation. Řada platebních transakcí se nyní přebírá ze systémového parametru cashOffice; není-li zadán, použije se přednastavená řada platebních karet uživatele, jinak REST API vrátí chybu „Není zadán systémový parametr: Pokladna“. Stejně se chová i čtení přes MCP server Helios Inuvio.

Faktury vydané – sloupec Stav e-Faktury nově ukazuje průběh odeslání e-faktury přes e-Link podle odpovědí, které e-Link vrací. Hodnoty sloupce Stav e-Faktury: Neodesláno – XML e-faktury zatím nebylo vytvořeno. Odesláno manuálně – XML bylo vytvořeno zprávou, která nemá zaškrtnuto „Zprávy odeslat na e-Link“. Soubor odesílá uživatel sám. Odesláno e-Link (dříve „Odesláno automatizovaně“) – XML bylo vytvořeno zprávou se zaškrtnutým „Zprávy odeslat na e-Link“ a předáno k odeslání přes e-Link.

Z e-Linku zatím nepřišla žádná odpověď. Peppol: Chyba, Přenos, Odesláno, Výzva finančního úřadu, Přijato finančním úřadem, Chyba validace, Varování – stav přenosu faktury sítí Peppol. Doklad: Akceptováno, Podmíněně akceptováno, Zpracovává se, Přijato, Odmítnuto, Dotazováno – stav vyřízení faktury u odběratele. Zrušeno odeslání – po akci Zrušení příznaku exportu ZeFA XML. Jak se stav mění: Po odeslání přes e-Link se stav aktualizuje s každou odpovědí z e-Linku.

Zobrazuje se vždy stav z poslední odpovědi. Když odpověď obsahuje stav přenosu v Peppolu, zobrazí se ten (Peppol: …). Jinak se zobrazí stav dokladu (Doklad: …). Odpověď bez stavu předchozí hodnotu nemění. Po zrušení příznaku exportu zůstane Zrušeno odeslání i v případě, že z e-Linku později přijde odpověď k původnímu odeslání. Po novém exportu se stav sleduje znovu. Komunikace e-Link – sloupec Stav dokladu se nově vyplňuje jen tehdy, když ho e-Link v odpovědi pošle.

Jinak zůstává prázdný. Dříve se u nově odeslané faktury doplňovalo Podmíněně akceptováno a u odpovědí bez stavu Dotazováno. U faktur odeslaných před aktualizací se Stav e-Faktury zpětně nepřepočítává. Změní se až s další odpovědí z e-Linku.

Byl upraven tiskový zdroj pro tisk faktur a dobropisů z Dopravy: Pole stazky, vozidla a úseku v tiskové pipeline xPohybyZboziDoprava mají nově stálé názvy. Uživatelské formuláře, které používaly pole s číslem na konci názvu (např. DatCasPocatek_X1039), je potřeba přepojit na nové názvy polí.

EET 2.0 - Nad přehled faktur vydaných byla do nabídky Úhrady doplněna nová akce Úhrada EET - QR. Akce vygeneruje úhradu s původem Úhrada - ruční zadání na zbývající neuhrazenou částku se zatrženými příznaky EET , Párovat s bankou a V přípravě a rovnou tržbu zaregistruje.

Při účtování prvotních dokladů : zápočtů ve fakturaci, pokladních dokladů, bankovních výpisů a úhrad , lze automaticky účtovat i kurzový rozdíl a dorovnání (pokud je nastaveno na příslušné řadě dokladů - faktur). V případě, že nedojde z jakéhokoliv důvodu k zaúčtování prvotního dokladu, nedojde ani k zaúčtování kurzového rozdílu a dorovnání, i když v těchto dokladech chyba není. Úprava se týká druhé fáze účtování - přenosu účetních dokladů z přededitace do účetního deníku (se zapnutou přededitací nebo bez přededitace).

Pokud je účtování s přededitací, v procesním okně je zobrazena chyba : Pokud nedojde k zaúčtování kurzového rozdílu z výše uvedeného důvodu, je zobrazeno v procesním okně chybové hlášení “Kurzový rozdíl nebyl účtován (není zaúčtován prvotní doklad)“. Pokud nedojde k zaúčtování dorovnání z výše uvedeného důvodu, je zobrazeno v procesním okně chybové hlášení “Dorovnání nebylo účtováno (není zaúčtován prvotní doklad)“. Je-li v přededitaci prvotní doklad opraven, dojde k zaúčtování do účetního deníku jak prvotního dokladu, tak i kurzového rozdílu a dorovnání.

Pokud je účtování bez přededitace, v procesním okně je zobrazena pouze chyba prvotního dokladu. Automatické účtování agend nepodporuje automatické účtování kurzových rozdílů a dorovnání. V tomto případě jsou prvotní doklady účtovány zvlášť a účtování kurzovních rozdílů a dorovnání z úhrad také zvlášť. Zde k žádné úpravě nedošlo.

Editor dokladu oběhu zboží: opuštění pole Období stavu bez změny hodnoty už zbytečně neukládá data dokladu; ukládá se jen při skutečné změně období.

Faktury vydané a přijaté, navazování záloh. Byla opravena chyba, kdy se dobropis od konečné částky faktury odečítal, místo aby se přičítal. Na dokladech, na kterých byl dobropis navázaný před opravou, je třeba dobropis ze záloh odvázat a navázat znovu. U dobropisu navázaného na konečnou fakturu se nově správně počítá neuplatněná záloha, a to i v přehledu faktur k datu. Už navázaný dobropis se při automatickém výběru záloh znovu nenabízí. Dobropis se správně přičítá i u proforma faktury a včetně korekcí z doplňkových položek.

V přehledu faktur k datu byla opravena také neuplatněná záloha u přijatých zálohových faktur.

Oprava datumu splatno na zádržném (akce “Změnit splatnost“ v přehledu zádržného). Faktura musí být zaúčtována. Pro variantu, že se jedná o změnu datum splatno na zádržném a v účetním deníku na dokladu zaúčtování faktury jsou zapsány vazby na řádky kontace , provedena úprava algoritmu opravy na účetním dokladu (účetní obraz dané faktury). Ke změně datumu párování v účetním deníku dojde jen na těch řádcích účetního dokladu, které mají vazbu na řádek účetního kódu s druhem řádku “Zádržné“ a pole “Datum brát z“ je nastaveno na “Zádržného“.

Fakturácia - Faktúra vydaná - e-Faktúra SK: e-Faktúra SK – číslo faktúry (BT-1) a odkaz na pôvodnú faktúru v dobropise (BT-25) podľa zdroja čísla pre KV DPH: Ak faktúry vydané vystavujete v externom systéme a do Helios Inuvio ich zakladáte importom, doklad dostane interné číslo podľa číselného radu nastaveného v Helios Inuvio. Odberateľ však faktúru dostal pod pôvodným číslom z externého systému. To isté číslo sa musí uviesť v kontrolnom výkaze DPH aj v XML e-Faktúry.

Ktoré číslo sa použije, určuje voľba Zdroj čísla pre KV na číselnom rade dokladov: 0=Číslo faktúry je prenášané číslo dokladu v Helios Inuvio (rad + poradové číslo) 1=Dodávateľská faktúra je prenášaná hodnota z poľa Dodávateľská faktúra 2=Evidenčné číslo daňového dokladu je prenášaná hodnota z poľa Evidenčné číslo daňového dokladu ; ak je prázdne, hodnota z poľa Dodávateľská faktúra Číslo faktúry v XML e-Faktúry (BT-1, cbc:ID ) sa plní rovnako ako číslo v kontrolnom výkaze DPH, takže XML a KV DPH sa zhodujú.

Oprava odkazu na pôvodnú faktúru v dobropise: Dobropis vydaný doteraz odkazoval na pôvodnú faktúru (BT-25, cac:BillingReference ) vždy interným číslom dokladu v Helios Inuvio. Pri radoch s voľbou 1 alebo 2 sa teda odkaz nezhodoval s číslom, pod ktorým faktúra odišla odberateľovi. Teraz BT-25 v dobropise obsahuje rovnaké číslo ako BT-1 pôvodnej faktúry. Pri voľbe 0 sa nič nemení. Upozornenia: Voľba Zdroj čísla pre KV sa na doklad prevezme z číselného radu pri jeho založení alebo importe.

Ak voľbu na rade zmeníte neskôr, už založené doklady si ponechajú pôvodné nastavenie. Pri voľbe 1 alebo 2 musí byť príslušné pole na doklade vyplnené. Inak sa XML e-Faktúry nevygeneruje a zobrazí sa hláška „Faktúra vydaná: Chýbajú povinné údaje pri identifikácii dokladu.“ Pole Dodávateľská faktúra má najviac 20 znakov. Dlhšie číslo (do 30 znakov) zadajte do poľa Evidenčné číslo daňového dokladu a na rade nastavte voľbu 2.

Faktúra vydaná - e-Faktúra SK - Vlastné XML e-FA cez externú (slepú) procedúru: Pri exporte e-Faktúry z Faktúry vydanej alebo Dobropisu vydného možno namiesto štandardne generovaného XML použiť vlastné XML, ktoré poskladá externá (slepá) procedúra dbo.ep_ZeFA_VlastniXML. Kedy sa procedúra volá: Procedúra sa volá iba vtedy, ak v databáze existuje. Volá sa po vstupných kontrolách (Peppol ID dodávateľa a odberateľa, organizácie, sadzby DPH) a pred tým, ako Helios začne skladať XML.

Pravidlá pre procedúru: Nesmie vracať výsledkovú sadu (SELECT). XML sama nikam neukladá ani neprevádza. Robí to Helios Inuvio. Popis je v Heliose Inuvio v v Konfigurácii - Globálne konštanty - Systémové konštanty cez “Akcie” - Zoznam externých doplnkov pod verejným názvom “OZ – e-Faktura – vlastní XML”, kde je aj popis definície. Informácie pre správcu databázy - právanie podľa výsledku procedúry: @xml = NULL, alebo procedúra neexistuje: Helios vygeneruje XML štandardne ako doteraz.

@xml obsahuje XML: Helios použije vrátené XML a sám ho negeneruje. Kontroluje iba to, že XML má jediný koreňový element Invoice (faktúra) alebo CreditNote (dobropis) v mennom priestore UBL 2.1. Obsah podľa EN 16931 a Peppol BIS 3.0 nekontroluje. Za jeho správnosť zodpovedá autor procedúry. XML prevedie do UTF-8 s deklaráciou <?xml version="1.0" encoding="UTF-8"?>. XML uloží rovnako ako štandardné XML: do správy, alebo do Peppol dokumentu na odoslanie cez Helios e-Link.

Nastaví príznak Vlastné XML ( VlastniXML = 1 ) v TabPeppolDokument aj v TabDokZboDodatek. Pri štandardnom XML je príznak 0 a pri opakovanom generovaní sa prepíše. Chyba v procedúre: export dokladu sa ukončí a nič sa neuloží. Používateľovi sa zobrazí hláška s textom chyby z procedúry (pozri nižšie). Rovnako sa ohlási aj chyba SQL Servera (napr. neexistujúca tabuľka). XML s nesprávnym koreňom: export sa ukončí hláškou, že procedúra vrátila XML, ktoré nemá jediný koreňový element v požadovanom mennom priestore.

Hlásenie chýb z procedúry: Na hlásenie chýb slúži nová hláška 93277 „Chyba v externej procedúre: %s“ , lokalizovaná do slovenčiny, angličtiny a nemčiny. Namiesto %s sa dosadí nelokalizovaný text chyby z procedúry, najviac približne 190 znakov:.

Fakturácia - e-Faktúra (SK) - Generovanie XML e-FA Peppol BIS 3.0: Oprava generovania dátumu splatnosti (BT-9) a prázdnych dátumov v XML: Pri generovaní XML e-Faktúry z dobropisu vydaného (UBL Credit Note, typ 381) sa dátum splatnosti zo záložky dokladu nezapisoval do elementu cac:PaymentMeans/cbc:PaymentDueDate (BT-9). Ak mal dobropis kladnú sumu na úhradu v BT-115, príjemca takýto doklad pri importe odmietol, lebo nebolo splnené pravidlo BR-CO-25.

Dátum splatnosti sa teraz zapisuje podľa sumy na úhradu (BT-115): Suma na úhradu je kladná: dátum splatnosti je povinný a zapíše sa do XML. Pri dobropise sa zapíše do cac:PaymentMeans/cbc:PaymentDueDate , pri faktúre do cbc:DueDate. Ak na doklade nie je vyplnený, generovanie XML skončí hláškou „Chýba dátum splatnosti (BT-9), doklad má kladnú sumu na úhradu“ a XML sa nevytvorí. Suma na úhradu je nulová alebo záporná: dátum splatnosti sa do XML nezapisuje, ani keď je na doklade vyplnený.

Kontrola platí pre dobropis vydaný aj pre faktúru vydanú. Ďalej sa opravilo zapisovanie prázdnych dátumov. Prázdne dátumy splatnosti ( cbc:DueDate , cbc:PaymentDueDate ) a DUZP ( cbc:TaxPointDate , cbc:ActualDeliveryDate ) sa teraz do XML nezapisujú vôbec. Odporúčanie pre používateľov: pri Faktúrach vydaných a Dobropisoch vydaných s kladnou sumou na úhradu vždy vyplňte dátum splatnosti.

Fakturácia – Faktúry vydané – e-Faktúra SK: e-Faktúra SK – oprava kódu dôvodu oslobodenia od DPH (BT-121) a adresy bez ulice (BT-35, BT-50): Ak sa na doklade použil dôvod oslobodenia od DPH s národným kódom začínajúcim na SK-… (napr. SK-§22_3-mimo ZD ), kód sa zapísal do elementu cbc:TaxExemptionReasonCode (BT-121). Tento element smie obsahovať len kódy z medzinárodného číselníka VATEX, preto takáto e-Faktúra v sieti Peppol neprešla validáciou. Dôvod oslobodenia sa teraz do XML zapisuje len do BT-120 = Text dvôvodu oslobodenia od DPH.

Úprava platí pre faktúry vydané, dobropisy vydané aj pre sadzby DPH zo zúčtovaných zálohových faktúr. Niektoré obce nemajú pomenované ulice, takže organizácie z takýchto obcí majú pole Ulica prázdne. Pri generovaní XML e-Faktúry kontrola vyžadovala ulicu pri dodávateľovi aj odberateľovi, a preto sa XML pre takéto organizácie nedalo vygenerovať. Opravou sa zabezpečilo, že kontrola v Helios Inuvio už ulicu nevyžaduje. Povinné zostávajú názov, IČO, PSČ, obec a krajina.

Element cbc:StreetName (BT-35 pri dodávateľovi, BT-50 pri odberateľovi) sa zostaví len z vyplnených údajov. Lomítko sa zapíše, len ak je vyplnené súpisné aj orientačné číslo. Rovnako sa zostavuje aj adresa miesta dodania ( cac:Delivery ). Odporúčanie: pri organizáciách v obciach bez ulíc vyplňte aspoň súpisné číslo. Podľa zákona č. 125/2015 Z. z. o registri adries tvorí adresu budovy: obec súpisné číslo a ulica s orientačným číslom, ak ich obec určila.

Fakturácia - Faktúra prijatá - e-Fakturácia SK: Import XML e-Faktúry Peppol BIS 3.0 (UBL 2.1) do Faktúr prijatých: Prijaté e-Faktúry v XML-formáte Peppol BIS Billing 3.0 (UBL 2.1) je teraz možné načítať do Helios Inuvio a založiť z nich doklady vo Fakturácii – Faktúry prijaté. XML e-Faktúry sa načítajú do evidencie Prichádzajúca komunikácia e-Link, Peppol XML dvoma spôsobmi: manuálne cez akciu Správy - Načítanie správ. automatizovane z aplikácie Helios e-Link.

Údaje z načítaného XML si môžete pred založením dokladu pozrieť cez Akcie – Náhľad. Pred prvým prenosom je potrebné nastaviť v Fakturácii - Ďalšie v tabuľke “ Prichádzajúca komunikácia e-Link, Peppol xml ” cez Akcie : Konfiguráciu prenosu - toto nastavenie systém si pamätá: a) Identifikátor vlastnej organizácie b) Zakladať neexistujúce bankové spojenie (IBAN) c) Ukladať prílohy z e-Faktúry do dokumentov Priradenie radov dokladov - toto nastavenie systém si nepamätá (je potrebné ho pred každou akciou vyplniť) : kde sa nastaví číselný rad, do ktorého sa doklady založia za “Faktúry prijaté (380, 383, 386, 388)” a číselný rad pre “Dobropisy prijaté” (381).

Akcia Prenos založí z označených e-Faktúr doklady podľa typu dokladu (BT-3). Pri prenose sa vykonajú tieto kontroly za: Odberateľa = za 0.-tú organizáciu (vlastnú) Forma úhrady: s údajom podľa kódu BT-81, najprv v poli Kód pre e-Faktúru , potom podľa doplnkového kódu. Ak sa nenájde, doklad sa založí bez formy úhrady a zobrazí sa varovanie. Dátum splatnosti: chýbajúci dátum splatnosti (BT-9) založenie dokladu neblokuje. Pri dobropise sa dátum splatnosti číta z elementu cac:PaymentMeans/cbc:PaymentDueDate.

a) Ak v XML e-Faktúry chýba, dopočíta sa podľa pravidiel (viď dokumentácia). b) Ak je v XML e-Faktúry výsledok na doplatenie s kladnou sumou a neobsahuje dátum splatnosti (BT-9) ani platobné podmienky (BT-20), doklad sa založí s varovaním a s dopočítaným dátumom platnosti (pravidlo BR-CO-25). Varovania a chyby: ručné načítanie zastavia len chyby validácie. Varovania, napr. dobropis bez odkazu na pôvodnú faktúru, načítanie nezastavia. Duplicitná e-Faktúra má rovnaké číslo dokladu (BT-1), rovnaký Peppol ID dodávateľa (BT-34) a rovnaký druh dokladu (faktúra alebo dobropis).

Ručné načítanie: duplicitné XML sa nenačíta a zobrazí sa hláška s odkazom na už načítaný záznam. Automatické načítanie z e-Linku: záznam sa uloží, lebo e-Link ho musí prevziať, ale označí sa chybou DUPLICITA s odkazom na pôvodný záznam. Prenos: duplicitný záznam sa do Faktúr prijatých neprenesie, ani keď sa pôvodný záznam ešte neprenášal. V takom prípade preneste pôvodný (starší) záznam. Kontrola duplicity vo Faktúrach prijatých zostáva zachovaná.

Odporúčanie pre používateľov: Na formách úhrady vyplňte Kód pre e-Faktúru (BT-81, napr. 30 = prevodný príkaz, 58 = SEPA prevod). Na kartách dodávateľov nastavte lehotu splatnosti, aby sa pri e-Faktúrach bez BT-9 dopočítal správny dátum splatnosti. Číselným radom faktúr prijatých priraďte DK DPH, prípadne skontrolujte Kód DPH na daňových kľúčoch na vstupe, aby sa riadkom priradil správny DK DPH.

e-Faktúra (SK) - Faktúra vydana - generovanie XML: Bola opravená chyby generovaného XML e-Faktúry pre Faktúru vydanú realizačnú s viacerými % DPH, kde sa odpočítala nedaňová zálohová faktúra. Chyba spôsobovala, že XML bolo nevalidné. Po oprave sú správne načítané údaje do elementov XML e-Faktúry, ktoré je už v Peppol sieti validné.

Fakturácia - Faktúra vydaná - e-Faktúra SK - Merné jednotky: e-Faktúra SK – povinná merná jednotka na položkách faktúry a dobropisu vydaného (BT-130) Každý riadok e-Faktúry musí obsahovať kód mernej jednotky fakturovaného množstva (BT-130, pravidlo BR-23 normy EN 16931). Ak niektorá položka dokladu mernú jednotku nemala, vygenerované XML e-Faktúry neprešlo validáciou. Pri ukladaní faktúry vydanej a dobropisu vydaného sa preto teraz kontroluje, či majú všetky položky dokladu vyplnenú mernú jednotku.

Kontrolujú sa skladové aj textové položky. Kontrola sa spustí, len ak platia všetky tieto podmienky: v konštantách je zapnutá e-Fakturácia, na číselnom rade dokladu je povolená e-Faktúra, na doklade je na záložke 6-Dodatky zaškrtnutý atribút e-Faktúra. Ak na doklade nie je vyplnený, rozhoduje nastavenie číselného radu. Ak niektorá položka nemá mernú jednotku, doklad sa neuloží a zobrazí sa hláška „Merná jednotka je pre e-Fakturáciu povinná, doplňte ju na všetkých položkách dokladu.“ Samotnú položku bez mernej jednotky je možné uložiť, kontrola zastaví až uloženie celého dokladu.

Kontrola platí v editore dokladu aj pri zakladaní a zmene dokladu cez Helios API, kde sa vykoná po uložení všetkých položiek. Faktúr prijatých sa kontrola netýka. Odporúčanie: skontrolujte, či majú merné jednotky používané na faktúrach vydaných vyplnený kód podľa číselníka UN/ECE Rec. 20 (napr. H87 = kus, C62 = jednotka, KGM = kilogram, HUR = hodina). Ak sa e-Faktúra pre niektorý doklad nemá generovať, zrušte na ňom na záložke 6-Dodatky označenie e-Faktúra.

Odeslání dat do Reporting CZ z Dashboardu BI se nově zapisuje do žurnálu (Konfigurace → Systémové konstanty → Žurnál). Událost „BI - odeslání dat do Reporting CZ - start“ zaznamená, kdo, kdy a z jakého počítače odeslal které období, např. „Období ID 27 (2019)“. Událost „BI - odeslání dat do Reporting CZ - konec“ zaznamená výsledek: „OK – data předána, přepočet spuštěn“, nebo „CHYBA – <krok>: <zpráva>“. OK znamená, že Reporting CZ data převzal a spustil přepočet; přepočet na straně Reporting CZ pak běží samostatně.

Přenos spouštěný programem HeBISync se do žurnálu nezapisuje.

HeBISync: datové pumpy, které odkazují na systémovou databázi (%SysDB%), nově fungují i se systémovou databází, jejíž jméno obsahuje pomlčku, mezeru nebo jiný zvláštní znak. Dříve export takové pumpy skončil chybou SQL a data se nepřenesla.

HeBISync: pokud se při dávkovém exportu datové pumpy (s rozdělením podle ID) nepodaří zapsat CSV soubor, export této pumpy se ukončí, neúplný soubor se do Reporting CZ neodešle a přenos skončí s chybou (návratový kód 3). Dříve se v takovém případě mohl odeslat neúplný soubor.

Helios Reporting (BI) – HeBISync: zabezpečené spojení s Reporting CZ Program HeBISync (pravidelný automatický přenos dat do Helios Reporting) komunikuje se serverem Reporting CZ stejně zabezpečeně jako Helios: přes OpenSSL 3, nejméně TLS 1.2 a s ověřením certifikátu serveru. Dříve používal OpenSSL 1.0.2 (podpora skončila v roce 2019), povoloval starší protokoly TLS 1.0 a 1.1 a certifikát serveru neověřoval. Ověření certifikátu lze v nouzi vypnout stejným klíčem jako v Heliosu: v souboru Helios.INI ve složce instalace (vedle HeBISync.exe) sekce [Application], TLSTrustServerCertificate=1.

HeBISync pak do logu zapíše upozornění. HeBISync používá knihovny libssl-3.dll a libcrypto-3.dll, které jsou ve složce instalace Heliosu; libeay32.dll a ssleay32.dll už nepotřebuje.

Přenos dat do Reporting CZ programem HeBISync (naplánovaná úloha) nově používá jen platnou registraci BI. Pokud Helios registraci zablokoval (např. po zjištění, že patří jiné databázi), nebo registrace chybí, HeBISync data neodešle, zapíše do logu chybu „Registrace BI je zablokovana nebo chybi“ a skončí s návratovým kódem 2.

Helios Reporting (BI) – HeBISync: spolehlivý zápis logu Když log zadaný parametrem /L nejde zapsat (neexistující složka, chybějící právo zápisu, soubor zamčený jiným během), HeBISync už neskončí chybovým oknem. Log zapíše do HeBISync.log ve složce TEMP uživatele, pod kterým běží, s úvodním řádkem POZOR (původní cesta a příčina), a přenos dat pokračuje. Samotný název souboru nebo relativní cesta v /L se nově vztahují ke složce s HeBISync.exe (stejně jako u /R).

Dříve se log se samotným názvem bez upozornění zapsal do složky TEMP. Opraveno přepisování posledního znaku logu při každém zápisu (rozbité konce řádků).

Helios Reporting (BI) – HeBISync vrací návratový kód podle výsledku přenosu Program HeBISync (pravidelný automatický přenos dat do Helios Reporting) nově vrací návratový kód, podle kterého Plánovač úloh Windows nebo spouštěcí dávka (např. IF ERRORLEVEL) pozná, že přenos selhal. Dříve vracel vždy 0. Kód se zapíše i do logu („Návratový kód : N“); při více chybách platí nejvyšší. 0 – přenos proběhl bez chyby 1 – chybné parametry nebo definice Report*.ini, přenos se nespustil 2 – chyba připojení k databázi nebo chybí API klíč Reporting CZ 3 – chyba exportu nebo odeslání některého souboru (ostatní soubory se odešlou) 9 – neočekávaná chyba Neočekávaná chyba se zapíše do logu.

Dříve v takovém případě HeBISync zobrazil chybové okno (I/O error 105) a naplánovaná úloha zůstala viset, dokud ho někdo nezavřel.

Helios Reporting (BI) – kódování souborů Report*.ini Definice datových pump (Report.ini, Report_user.ini, Report_<databáze>.ini) se načtou správně v kódování Windows-1250 i UTF-8 (s BOM i bez něj), v Heliosu i v programu HeBISync. Kódování se rozpozná samo. HeBISync dříve u souboru uloženého v UTF-8 poškodil diakritiku v odesílaných datech (např. názvy druhů pohybů) a u UTF-8 s BOM nenačetl první sekci [Exporttab…]. Helios už nezávisí na kódové stránce Windows – soubory bez UTF-8 čte vždy jako Windows-1250.

Helios Reporting (BI) – definice datových pump v Report*.ini Velikost dávky se čte z klíče IDMEZCount, jak uvádí dokumentace i dodávaný Report.ini. Dříve se klíč ignoroval a dávka měla vždy 100 000 záznamů. Původní název IDMEZRecCount zůstává funkční. Sekce [ExporttabN] v Report.ini, Report_user.ini a Report_<databáze>.ini už nemusí být číslovány souvisle – do uživatelského souboru stačí vykopírovat jen potřebné sekce. Dříve se načítání zastavilo u prvního chybějícího čísla.

Platí pro export z widgetu BI v Heliosu i pro program HeBISync.

Helios Reporting (BI) – adresa serveru Reporting CZ v systémových URL Adresa serveru Reporting CZ už není pevně v programu. Je uložená v systémových URL adresách (TabURL) jako nový druh 67 „Reporting CZ (Helios BI)“ s výchozí hodnotou https://helios.reporting.cz. Při změně serveru stačí upravit tuto adresu, není potřeba nová verze. Helios: adresu používají všechny funkce widgetu BI na dashboardu – aktivace, deaktivace, zjištění stavu, export dat, přepočet i demo přihlášení.

HeBISync: adresu načte z databáze po připojení a zapíše ji do logu („Adresa Reporting CZ : …“); použije ji pro odeslání dat, zápis do žurnálu i přepočet. Nová databáze obsahuje adresu v každé legislativě, existující databázi ji doplní aktualizace. Již existující adresu aktualizace nepřepisuje. Pokud adresa v databázi chybí (např. HeBISync proti databázi před aktualizací), použije se dosavadní adresa https://helios.reporting.cz.

Helios Reporting (BI) – HeBISync: zápis chyb přenosu do žurnálu Reporting CZ Program HeBISync (pravidelný automatický přenos dat do Helios Reporting) zapisuje chyby přenosu nejen do logovacího souboru a do logu v Heliosu, ale odesílá je i do žurnálu na straně Reporting CZ. O chybě se tak dozví i uživatelé, kteří pracují pouze v Reportingu. Do žurnálu se odesílají jen chyby (např. chyba při vytváření CSV souboru, když je soubor používán jiným procesem).

Ostatní zprávy z logu se neodesílají. Záznam v žurnálu obsahuje verzi Heliosu, název souboru/tabulky, které se chyba týká, a text chyby.

HeBISync – nové parametry příkazového řádku pro přenos jen vybraných dat do Helios Reporting: /R:"soubor.ini" – vlastní definiční soubor datových pump. Je-li uveden, načte se výhradně tento soubor; Report.ini ani Report_user.ini / Report_<databáze>.ini se nepoužijí. Soubor bez cesty se hledá ve složce s HeBISync.exe. Pokud soubor neexistuje nebo neobsahuje žádnou datovou pumpu, přenos se nespustí a chyba se zapíše do logu. /C:"F" – po přenosu se přepočítají jen data zvoleného modulu: F – finance, I – položky, A – splatnost.

Bez parametru se přepočítává vše jako dosud. Jiná hodnota je chyba a přenos se nespustí. Oba parametry lze nastavit i v editoru příkazového řádku (HeBISync.exe spuštěný bez parametrů): pole Report INI a seznam Přepočet. Další změny: Sekce [ExporttabN] v definičních souborech už nemusí být číslovány souvisle – stačí vykopírovat z Report.ini jen potřebné sekce. Velikost dávky se čte z klíče IDMEZCount, jak uvádí dokumentace (dřívější IDMEZRecCount zůstává funkční).

Do logu se zapisuje použitý definiční soubor, modul přepočtu a počet načtených datových pump; parametry spuštění jsou v logu i při chybě definice. Při chybě připojení k databázi se už nespouští přepočet dat a program neskončí chybovým oknem.

Opraveno zapisování pohybu umístění do Protokolu zavedení majetku přes REST API.

Upraveno API Majetek - Protokoly zavedení V úpravě byl řešen vztah údajů zaslaných přes API a údajů přednastavených na typu majetku.

Upravena definice sloupce Zaměstnanec-změna (TabMaInvSt.CisZam_Zmena) v přehledu Položky inventury.

Předzpracování mezd – import z Firemních aktivit/Externí procedúry - doch. MS Předzpracování mezd – import z Firemních aktivit/Externí procedúry: opravena chyba, kvůli které se nenaimportovaly nepřítomnosti (docházkové mzdové složky), pokud měla firemní aktivita vyplněnou poznámku. Stejná oprava se týká importu z externí procedury.

Zdravotní pojištění - přehled - dlouhé příjmení/jméno Nad přehledem Výpočet mzdy byl upraven distribuční tiskový formulář: Sys. č. / Název -326 / Zdravotní pojištění - přehled tak, aby se v případě dlouhého příjmení/jména zaměstnance správně zobrazovalo příjmení/jméno zaměstnance i na následující straně.

Registrace zaměstnance - průměrný čistý výdělek a datum změny země rezidence - kontroly před exportem 10377 Průměrný měsíční čistý výdělek - kontrola před exportem už u akce Oprava chybných údajů nevyžaduje Průměrný měsíční čistý výdělek v případě, pokud není vyplněno datum skončení zaměstnání, u akce Skončení zaměstnání kontrola upozorňuje na nulový příjem vždy (pokud není důvod neposkytnutí podkladů 2) 10459 Platnost změny kódu státu rezidentství od - datum Platnost změny kódu státu rezidentství od je vyžadováno kontrolou u Změny a Opravy jen tehdy, když se stát rezidentství v daném období změnil.

V následujících distribučních tiskových formulářích: Sys.č. / Název -335 / Potvrzení při změně zaměstnání bez čisté mzdy -1193 / Potvrzení při změně zaměst.- příloha (příjem) -1194 / Potvrzení při změně zaměstnání -1591 / Potvrzení při změně zaměstnání (AJ) bylo upraveno zobrazování dlouhé adresy a názvu profese.

Registrace zaměstnance - odhláška statutára vs. odstupné Odhláška zaměstnance s druhem výdělečné činnosti M až S (např. člena statutárního orgánu) v registraci zaměstnance nově obsahuje údaj, zda náleží odchodné, odbytné nebo odstupné (ID 10378). Bez tohoto údaje ČSSZ takovou odhlášku odmítala.

Definice rizik – rozšíření V Definici rizik byly v sekci Rozšiřující druhy práce doplněny dva nové atributy Jiný s názvem druhu práce , obdobně jako v doplňujících údajích zaměstnance. Funkce Přiřazení rizik tyto údaje přenese do doplňujících údajů zaměstnance společně s ostatními druhy práce. Název druhu práce se přenese pouze u zaškrtnuté volby, takže ručně zadaný název u zaměstnance zůstane zachován.

RZD - Vyúčtování daně a daňového zvýhodnění - formulář (sys.č. -7800) Byl upraven nápočet v řádcích 32 přeplatek na dani po slevě a a 32b doplatek na daňovém bonusu.

Zrušení nelegislativních přehledů Ve stromečku Mzdy (pod zaměstnanci) byly zrušeny volby přehledů, které už nejsou legislativně platné: Oznámení na OSSZ (přihlášky/odhlášky ČSSZ) Hlášení dohod (výkaz příjmů z DPP) Oznámení na ÚP (cizinci) Přehledy se dají dál otevřít z přehledu Registrace zaměstnance. V ribbonu přibyla skupina Oznámení do roku 2026 se třemi tlačítky. Každé otevře příslušný přehled jako navazující, filtrovaný na aktuální mzdové období (u ČSSZ bez záznamů s typem akce 4).

Tlačítka jsou jen v hlavním přehledu Registrace zaměstnance. V Doregistraci a Dodatečném přihlášení nejsou.

Generátor mzdových sestav – změna využití mzdových složek 090 a 091 od 1. 1. 2027 V souvislosti se zrušením srážkové daně od 1. 1. 2027 dochází ke změně využití mzdových složek 090 a 091. Za mzdová období do prosince 2026 včetně slouží tyto mzdové složky pro evidenci srážkové daně. Počínaje mzdovým obdobím leden 2027 budou využívány pro evidenci speciální zálohové daně. Upozornění: Pokud mzdové složky 090 a 091 používáte v definicích sestav v Generátoru mzdových sestav, je nutné tyto definice zkontrolovat a případně upravit, včetně označení příslušných řádků sestavy.

Za mzdová období do prosince 2026 včetně: Odvod srážkové daně. Od mzdového období leden 2027: Odvod speciální zálohové daně. Úpravu je nutné provést tak, aby označení řádků odpovídalo mzdovému období, za které je sestava vytvářena.

Portál ZP - přímé odesílání hromadných oznámení a přehledu o výši pojistného Pro odeslání hlášení na Portál ZP (hromadné oznámení zaměstnavatele, přehled plateb pojistného) již není nově potřeba externí komponenta Signer a knihovna PortalZP.dll (pro 64bit již nebyla potřebná knihovna od dodavatele k dispozici). Způsob odeslání se z pohledu uživatele nemění. POZOR !!! Dříve se podpisový certifikát nastavoval v tomto případě až v komponentě Signer (nemusel být nastaven na definici zprávy pro odeslání).

Nyní musí být nastaven přímo v definici zprávy pro odeslání na záložce Certifikáty, El.podpis. Je tedy třeba zkontrolovat definici zprávy a certifikát doplnit, pokud není na definici nastaven. Toto se týká zprávy ve formátu Hlášení změn pro zdravotní pojišťovny - portál ZP (XML) v přehledu Hlášení změn ZP a zprávy Přehled o platbě pojistného - portál ZP (XML) v přehledu Měsíční exporty za organizaci. Současně musí být zatržen atribut Výstupní zprávy podepisovat certifikátem el.podpisu.

Redukční hranice pro výpočet náhrady za nemoc Od ledna 2027 se mění nastavení redukčních hranic: Nové redukční hranice: 1. redukční hranice 301,53 Kč (1 723 × 0,175) 2. redukční hranice 452,20 Kč (2 584 × 0,175) 3. redukční hranice 904,23 Kč (5 167 × 0,175).

Slevy na pojistném - Průměrná mzda Pro rok 2027 se mění průměrná mzda na hodnotu 51 663 (mzdové konstanty na záložce 2 - DNP a pojištění v sekci [5] Slevy na pojistném.) Tato hodnota má zásadní vliv na určování slevy na sociálním pojištění zaměstnavatele.

Sociální pojištění - maximální vyměřovací základ Od 01/2027 se zvyšuje hranice maximálního vyměřovacího základu na sociální pojištění na částku 2 479 824 Kč.

Hranice pro 15% daň ze závislé činnosti od 01/2027 Pro účely výpočtu zálohy na daň ze závislé činnosti podle  § 38h zákona o daních z příjmů  definována 15% sazba zálohy do 3násobku průměrné mzdy, který činí pro rok 2027 154 989 Kč.

Zaručená mzda od 01/2027 Sdělení MPSV č. 171/2026 Sb. 1. skupina: 148,30 Kč/hod, 24 900 Kč/měs. 2. skupina: 178,00 Kč/hod, 29 880 Kč/měs. 3. skupina: 207,70 Kč/hod, 34 860 Kč/měs. 4. skupina: 237,30 Kč/hod, 39 840 Kč/měs. Skupiny 5–8 a typy sazby 1–4 se generují nulové jako dosud. Pozor: sdělení uvádí, že bod 2 se nepoužije, pokud novela zákoníku práce (sněmovní tisk 300) od 1. 1. 2027 zruší § 112.

Minimální mzda od 01/2027 Od ledna 2027 (sdělení MPSV č. 171/2026 Sb.) dochází ke změně minimální mzdy MinMz_Mes1 – základní sazba měsíční mzdy 24 900 Kč MinMz_Hod1 – základní sazba hodinové mzdy 148,30 Kč DBonus_MinMzMesic 24 900 Kč , DBonus_MinMzRok 149 400 Kč (6 × 24 900) MinMz_Mes2 a MinMz_Hod2 (invalidé) zůstávají 0, beze změny.

Zaměstnání malého rozsahu od roku 2027 Od ledna 2027 je rozhodný příjem pro účast na pojištění (zaměstnání malého rozsahu) 5 000 Kč (10 % průměrné mzdy 51 663 Kč zaokrouhleno dolů na celých 500 Kč). Nastaveno v konstantách TabMzKons.ObcasneZam a TabMzKons.DuchPoj_Hranice pro rok 2027.

DNP - redukční hranice Od ledna 2027 platí nové redukční hranice pro dávky nemocenského pojištění. V Heliosu se jedná pouze o informativní údaj: 1. redukční hranice 1 723 Kč 2. redukční hranice 2 584 Kč 3. redukční hranice 5 167 Kč.

Zdravotní benefity - hranice Konstanta Průměrná mzda (TabMzKons.PN_RH1_HodCastka) má pro rok 2027 hodnotu 51 663 Kč (NV č. 177/2026 Sb.). Platí i pro další roky, dokud se nezmění. Roční limit zdravotních benefitů se bere přímo z této konstanty (100 % průměrné mzdy), pro rok 2027 je tedy také 51 663 Kč. Stejnou konstantu používá i výpočet slevy na SP (viz IND-10667).

Dohody o provedení práce (DPP)- odvod pojistného Od ledna 2027 se zvyšuje hranice, do které zaměstnanci pracující na základě dohody o provedení práce nebudou muset platit sociální ani zdravotní pojištění. Nově se jedná o částku 12 499 Kč. Jestliže DPP tuto hranici přesáhne, podléhá odvodům pojistného.

Generátor mzdových sestav V Rozšiřujících funkcích ve skupině Ostatní je nový vzorec NADLIMIT_REKREACE_ZAJEZDY. Vrací daněnou část příspěvku na rekreace a zájezdy nad limit, tedy hodnotu z Mzdových údajů „Rekreace a zájezdy - daněná část (nad limit)“.

Integrace s AVA: druhý pracovní poměr zaměstnance poslaný z AVA se nově založí jako další pracovní poměr (kopie karty zaměstnance s přípravou nástupu) a nepřepíše přípravu nástupu prvního pracovního poměru. Pokud zaměstnanec ještě žádný pracovní poměr nemá, další pracovní poměr se nezaloží a AVA dostane chybu. Mzdové údaje, vzdělání, údaje cizince a důchod přijaté z AVA se přiřadí ke správnému pracovnímu poměru. Směny zaměstnance se do AVA posílají jen za dny, kdy trvá pracovní poměr.

Mezi Heliosem a AVA se nově přenáší i zakázka z mzdových údajů zaměstnance. Při smazání adresy zaměstnance v AVA se v Heliosu vymaže i číslo orientační a popisné. Zaměstnanec založený v Heliosu z AVA se nově odešle zpět do AVA i s osobním číslem, které mu Helios přidělil (pokud je odesílání zaměstnanců do AVA zapnuté). Změna útvaru poslaná z AVA se u zaměstnance, který už má pracovní poměr, zapíše do karty zaměstnance a do jeho mzdových údajů. Po výpočtu mzdy nebo u uzavřených mzdových údajů se útvar ani zakázka z AVA nezmění a AVA dostane chybu.

E-mail a mobil (pracovní i soukromé) a pracovní telefon, které se smažou v AVA, se smažou i v Heliosu; soukromý telefon a ostatní kontakty zůstávají. Opravena chyba při příjmu pracovního poměru z AVA bez vyplněného druhu pracovního poměru. Středisko poslané z AVA se zapíše do karty zaměstnance už v přípravě nástupu, takže je po vzniku pracovního poměru v kartě zaměstnance i ve mzdových údajích. U zaměstnance, který už má pracovní poměr, se z AVA nově přebírají změny doplňujících údajů (např.

držitel karty ZTP/P, zdravotní omezení, vedoucí pozice, místo výkonu práce) a dosaženého vzdělání. Vzdělání se po výpočtu mzdy zaměstnance z AVA nezmění a AVA dostane chybu. Datum a důvod ukončení pracovního poměru poslané z AVA se u zaměstnance s pracovním poměrem zapíšou jako plánovaná změna k měsíci ukončení. Ukončení s datem v aktuálním mzdovém období z AVA zapsat nejde (AVA dostane chybu), zadá ho mzdová účetní v Heliosu. U dalšího pracovního poměru téže osoby (kopie karty zaměstnance založená příjmem pracovního poměru z AVA) se do přípravy nástupu převezme zdravotní omezení a držitel karty ZTP/P z původní karty zaměstnance.

Pozdější změny těchto údajů z AVA se zapíšou i do nezpracované přípravy nástupu dalšího pracovního poměru. Změna zdravotní pojišťovny, čísla pojištěnce nebo profese zaměstnance přijatá z AVA se nově zapíše i do již založené nezpracované přípravy nástupu (zdravotní pojišťovna i u dalších pracovních poměrů téže osoby). Dosud se tyto údaje do přípravy nástupu převzaly jen při jejím založení. Obec místa výkonu práce přijatá z AVA nově doplní i název obce podle číselníku obcí, stejně jako při výběru kódu v Heliosu.

Obec, která v číselníku obcí ještě není, se při příjmu z AVA do číselníku založí (jde-li o šestimístný kód obce), místo aby se odmítly všechny doplňující údaje zaměstnance. Plánovaná změna mzdy přijatá z AVA se nově odmítne, pokud typ mzdy (měsíční, hodinová) v ní chybí nebo nesouhlasí s typem mzdy ve mzdových údajích zaměstnance. Dřív se částka naplánovala bez ohledu na typ mzdy, takže hodinová sazba se mohla naplánovat jako měsíční mzda. Typ mzdy plánovanou změnou z AVA změnit nejde.

Denní úvazek poslaný z AVA se nově zapíše do přípravy nástupu stejně jako týdenní úvazek a po vzniku pracovního poměru je i ve mzdových údajích. Dosud se z AVA převzal jen týdenní úvazek a denní zůstal nulový. Roční výměra dovolené nového zaměstnance poslaná z AVA (Pinya) se nově zapíše do přípravy nástupu jako změna zákonného ročního nároku na dovolenou, například 5 týdnů jako navýšení o 5 dní. Nárok na dovolenou se z ní spočítá při převodu přípravy do mzdové evidence.

U zaměstnance s už převedenou přípravou se výměra z AVA nemění.

Zaměstnanecké benefity od roku 2027 vytvořeny 3 nové mzdové složky (MS) : 140 - Rekreace a zájezdy se shodným nastavením jako MS 084, ale s novým typem Základu pro daň 141 - Vybrané zdravotní programy se shodným nastavením jako MS 084, ale s novým typem Základu pro daň 142 - Vybrané sociální služby se shodným nastavením jako MS 084, s novým typem Základu pro daň Od roku 2027 se vytváří nové MS 140-142 Generování nových MS proběhne až při uzávěrce 12/2026 pokud někdo uzavře prosinec na starší verzí, kontrola před výpočtem mezd v lednu 2027 se pokusí tyto MS do číselníku dogenerovat.

Pokud by uživatel potřeboval tyto MS před výpočtem mezd v lednu, použije klasickou akci na přehledem Číselníku MS - Aktualizace podle legislativy. v uživatelském číselníku MS si uživatel vytvoří jen ty MS, které využije ve své praxi Mzdové konstanty : vytvořen nový atribut TabMzKons.RocniLimit_Rekreace v editoru se nachází zde : upravena UP pro Aktualizaci MK - od roku 2027 nový atribut nastavuje na hodnotu 20.000,- tabulka Výpočet mzdy ( TabZamVyp ) - vytvořeno 6 nových atributů Rekreace a zájezdy - nedaněná část (do limitu) Rekreace a zájezdy - daněná část (nad limit) Vybrané zdravotní programy - nedaněná část (do limitu) Vybrané zdravotní programy - daněná část (nad limit) Vybrané sociální služby - nedaněná část (do limitu) Vybrané sociální služby - daněná část (nad limit) tabulka Mzdový list ( TabMzdList ) - vytvořeno 6 nových atributů Rekreace a zájezdy - nedaněná část (do limitu) Rekreace a zájezdy - daněná část (nad limit) Vybrané zdravotní programy - nedaněná část (do limitu) Vybrané zdravotní programy - daněná část (nad limit) Vybrané sociální služby - nedaněná část (do limitu) Vybrané sociální služby - daněná část (nad limit) hlídání ročních limitů ve Výpočtu mzdy : MS 084 - Zdravotní nepeněžní benefity : beze změny MS 085 - Nepeněžní benefity : hlídáni ročního limitu ve výpočtu mzdy zrušeno MS 140 - Rekreace a zájezdy : zavedeno hlídáni ročního limitu ve výpočtu mzdy proti hodnote TabMzKons.RocniLimit_Rekreace MS 141 - Vybrané zdravotní programy : připraveno ve výpočtu mzdy na možné zavedení limitu, zatím limit není MS 142 - Vybrané sociální služby : připraveno ve výpočtu mzdy na možné zavedení limitu, zatím limit není Výpočet mzdy : nadlimitní částky nových benefitů se přičítají k základu pro Sociální pojištění nadlimitní částky nových benefitů se přičítají k základu pro Zdravotní pojištění nadlimitní částky nových benefitů se přičítají k základu pro Daň nadlimitní částky nových benefitů se přičítají do sumy nadlimitních částek pro výpočet pojistného Hasičů a Rizikáčů nadlimitní částky nových benefitů se přičítají do Úhrnu příjmů pro daň nadlimitní částky nových benefitů se přičítají do VZ pro výpočet DVZ podlimitní i nadlimitní částky se ukládají do příslušných nových atributů Mzdový list - nápočet : nové atributy se plní z odpovídajících atributů ve Výpočtu mzdy upraven atributy týkající se sumací částek osvobozených od daně, SP a ZP upraven atributy týkající se sumací nadlimitních částek benefitů upraveny atributy PL pro ML týkající se částek osvobozených od daně i nadlimitních částek benefitů.

Sleva na studenta a sleva za umístění dítěte od roku 2027 Od 1. 1. 2027 je v programu opět možné uplatňovat slevu na studenta a slevu za umístění dítěte (školkovné). Sleva na studenta – lze ji opět zadávat ve Mzdových údajích zaměstnance. Sleva se zohlední při měsíčním výpočtu mzdy i v ročním zúčtování daně. Sleva za umístění dítěte (školkovné) – lze ji opět zadávat v ročním zúčtování daně. Číselník slev a odpočtů – obě slevy se od roku 2027 automaticky doplní při aktualizaci mzdových konstant, pokud v číselníku chybí.

JMH - haléřové částky V případě, že bylo ve firmě uplatňováno konto pracovní doby, mohlo docházet k tomu, že vznikaly haléřové položky, které vstupovaly do měsíčního hlášení a způsobovaly chybu při odeslání na ČSSZ. Opraveno. Příčina: částka vyúčtování konta pracovní doby se do mzdové složky (MS dle konstant, např. 168) vkládala bez zaokrouhlení na měnu (na setiny). Ze složky se pak setiny propsaly do hrubého příjmu, základu daně a čisté mzdy ve výpočtu (TabZamVyp) a odtud do JMHZ (ID 10286, 10297, 10344).

Procedura hp_MzKontoPD_Vyrovnani nově zaokrouhluje částku vyúčtování před vložením MS do mzdy podle desetinných míst mzdové měny (CZK = celé Kč). Při výpočtu vyrovnání „hodiny × sazba aktuálního období“ se zaokrouhluje přímo součin, bez mezizaokrouhlení na 2 desetinná místa. Haléřový rozdíl ze zaokrouhlení se zohlední v dalším vyrovnání konta (odečítá se skutečně vyplacená částka vyrovnání). Přehled konta PD (měsíční a denní) zůstává beze změny, částky v něm jsou dál na 2 desetinná místa.

Mzdy - tiskový formulář Zdravotní pojištění - počet pojištěnců (-1245) - úprava Byl upraven tiskový formulář tak, aby se v případě, kdy jsou na vybrané ZP pouze ukončení pracovní poměry s odvodem pojištění, zobrazovali tito zaměstnanci na samostatné stránce.

Předregistrace - opakovaný nástup Předregistrace zaměstnance: u jednoho zaměstnance (RČ) lze v jednom mzdovém období založit více předpokládaných nástupů. Pokryje to posun nástupu po stornu i nástup na více PP v jednom měsíci (např. HPP a dohoda). Zrušena unikátnost Akce + Rodné číslo + Mzdové období v tabulce TabMzPredregistrace. Nový (neveřejný) atribut IdNastupu: u oznámení o nenastoupení odkazuje na předpokládaný nástup, který stornuje. Ke každému předpokládanému nástupu lze založit nejvýše jedno oznámení o nenastoupení.

Hláška při opakování: „Oznámení o nenastoupení k tomuto předpokládanému nástupu již existuje.“ Editor předregistrace: místo zákazu se uživatele jen zeptá, pokud pro stejné RČ už existuje nestornovaný předpokládaný nástup se stejným datem nástupu („Pro zaměstnance již existuje předpokládaný nástup se stejným datem nástupu. Chcete přesto pokračovat?“, výchozí odpověď Ne).

Zaokrouhlování povinného příspěvku zaměstnavatele na PF za rizikovou práci Povinný příspěvek zaměstnavatele do PF za rizikové práce (MS 076 a srážka MS 948) – příspěvek (procento z VZ pro SP) se nově zaokrouhluje na celé koruny nahoru podle zákona 324/2025 Sb. Dříve se zaokrouhloval matematicky (např. VZ 35 956 Kč × 4 % = 1 438,24 Kč → dříve 1 438 Kč, nově 1 439 Kč). Stejná částka se zapisuje do MS 076 i MS 948.

NOVINKA - RLFO verzia 2027 - platná od 24. 11. 2026 Do generovania eRLFO boli zapracované nasledovné zmeny: bol doplnený element “uplatnOopMdOdRd”, ktorý je od 1/2027 povinný UPOZORNENIE: Nasadenie novej verzie eRLFO zo strany Sociálnej poisťovni prebehne pravdepdobne 24.11.2026 , tzn. od 24.11. 2026 bude možné uploadovať XML súbor len vo verzii 2027. Tlačový formulár Sociálna poisťovňa vydá až po distribúcii tejto verzie, z toho dôvodu bude distribuovaný v najbližšej ďalšej verzii.

Generátor mzdových sestav (SK): funkce DOH_POL (dohadné položky) při změně útvaru nebo jiného údaje mzdové karty během roku ukazuje hodnoty pod útvarem, na kterém byl zaměstnanec v daném měsíci. Dosud se tvorba dohadných položek zobrazovala ve všech měsících pod útvarem z ledna. Nový parametr Z vrací zůstatek dohadných položek k poslednímu dni předchozího měsíce.

ÚPRAVA - Generátor mzdových zostáv - rozširujúca funkcia Dohadné položky Rozširujúca funkcia DOH_POL bola upravená nasledovne:.

Žádost o vystavení PD A1 a žádost o určení uplatnitelné legislativy (SK): klasifikace činnosti NACE se v XML posílá s kódem, který vyžaduje portál slovensko.sk, takže žádost jde na portálu elektronicky podepsat.

ÚPRAVA - Predspracovanie - Import dochádzkovej mzdovej zložky z modulu Firemné aktivity Nad prehľadom Predspracovanie akcia Import podakcie: Firemné aktivity Dochádzkové systémy Externá procedúra pri importe dochádzkovej mzdovej zložky v prípade, kedy malo plnenie úloh vyplnený atr. Poznámka skončila chybovou hláškou: “Neplatný názov stĺpca XY”. Upravené.

NOVINKA - Definícia rizík - rozšírenie Nad prehľadom Doplňujúce údaje akcia Definícia rizík bola definícia rozšírená o atribúty pre prenos vlastných činností podľa zvláštnych predpisov. Konkrétne v sekcii Činnosti podľa zvláštnych predpisov pribudli: atribút pre zaškrtávacie políčko atribút pre zadanie vlastného názvu činnosti.

NOVINKA - Stravné nad limit od 12/2026 MPSVaR SR dňa 28. 10. 2026 zverejnilo Oznámenie o sumách stravného č. 255/2026 Z. z, ktoré platí od 1. 12. 2026. Jedná sa nasledovné sumy: a) 9,80 eura pre časové pásmo 5 až 12 hodín, b) 14,60 eura pre časové pásmo nad 12 hodín až 18 hodín, c) 21,70 eura pre časové pásmo nad 18 hodín. Táto zmena zvyšuje od 1. 12. 2026 maximálny možný príspevok zamestnávateľa na jedlo na sumu 55 % zo sumy € 9,80, t. j. € 5,39 (teraz € 5,12).

Na základe tejto zmeny je v systéme Helios Inuvio je k dispozícii aktualizácia mzdových konštánt (cesta: Konštanty a číselníky/Mzdové konštanty akcia Aktualizácia konštánt), ktorá po spustení nad aktuálnym mzdovým obdobím 12/2026 zvýši konštantu Limit na hodnotu 5,39 (cesta. Konštanty a číselníky/Mzdové konštanty záložka Ostatné sekcia Výpočet PPHZ, pobočky, stravné časť Stravné).

ÚPRAVA - Žiadosť o určenie uplat. leg./o vystavenie A1 - SK NACE Nad prehľadom Doplňujúce údaje boli upravené nasledovné formáty správy: Žiadosť o vystavenie A1 - vyslaní do 1 štátu EU Žiadosť o určenie uplatniteľnej legislatívy - viac ako 1 štát EÚ tak, aby sa ku každému kódu z oficiálneho číselníka SK NACE priradil interný kód Sociálnej poisťovne.

NOVINKA - Tl. fomulár Mzdový list - daňová rezidencia Nad prehľadom Ročné zostavy bol upravený distribučný tlačový formulár: Sys.č. / Názov / Od / Do -400362 / Mzdový list / 1. 1. 2009 nasledovne: do hlavičky bola pridaná časť “Daňová rezidencia”, ktorá načítava aktuálne údaje z Doplňujúcich údajov označených zamestnancov do hlavičky do časti “Trvalé bydlisko” bol pridaný “Štát”.

NOVINKA - OOP DVP/DPČ dôchodcovia rozšírená o MD, OD, RD Od 1.1.2027 si OOP môžu uplatniť aj osoby na materskej, otcovskej a rodičovskej dovolenke, ak vykonávajú prácu na základe dohody o práci vykonávanej mimo pracovného pomeru. Uvedené vyplýva z § 227a novely č. 158/2026 Z. z.  zákona o sociálnom poistení: "Zamestnanec v právnom vzťahu na základe dohody o brigádnickej práci študentov a zamestnanec v právnom vzťahu na základe dohody o vykonaní práce alebo dohody o pracovnej činnosti, ktorý je fyzickou osobou uvedenou v § 4 ods.

1 písm. b) alebo od 1.1.2027 fyzickou osobou na materskej, otcovskej alebo rodičovskej dovolenke má právo určiť dohodu na účely uplatnenia odvodovej odpočítateľnej položky. Na základe tejto novinky vznikli v systéme Helios Inuvio nasledovné zmeny: v editore Mzdové údaje záložka Odvody podzáložka Poistenie sekcia Odvodové zvýhodnenie od 1/2027 nový atribút “Súbeh MD, OD, RD na DVP/DPČ”, ktorý je možné označiť len ak je súčasne označený atr. DVP/DPČ - dôchodcovia, MD, OD, RD (pôvoný názov bol: DVP/DPČ - dôchodcovia) a zamestnanec nemá aktívny dôchodok pre uplatnenie OOP dôchodcovia.

nad prehľadom Registračné listy FO po spustení akcie Zmeny OOP sa prenosnom okne zobrazia aj zamestnanci pracujúci na základe DVP, DPČ, ktorý majú zaškrtnutý atr. Súbeh MD, OD, RD na DVP/DPČ.

Mzdy SK – od roku 2027 se v číselníku Poisťovne (záložka Krátenie VZ, MZ ku kráteniu VZ) atribut Prerušenie poistenia (X) u systémových poisťovní nastavuje jen u fondu Úrazové poistenie (UP), a to na MZ 103, 215, 217, 219, 234, 244, 245, 246 a 249. U zdravotných poisťovní a ostatných fondov sociálneho poistenia se atribut ruší. Existující databáze upraví kontrola při otevření Výpočtu mzdy v lednu 2027 a zneplatní dotčené vypočtené mzdy.

ÚPRAVA - Číselník Poisťovne - atr. Prerušenie od 1/2027 Po update na túto verziu a vyššiu sa od 1/2027 zjednotení nastavenie priradených mzdových zložiek v číselníku Poisťovne na záložke Krátenie VZ sekcia MZ ku kráteniu VZ v atribúte X (Prerušenie poistenia). Čo sa mení: V číselníku Poisťovne majú niektoré mzdové zložky zapnutý príznak v stĺpci X v poisťovniach, kde to význam nemá. Od spracovania miezd za január 2027 sa toto nastavenie zjednotí.

Správne nastavenie: Len poisťovňa so symbolom UP by mala mať zaškrtnutý atribút X pri nasledovných dochádzkových mzdových zložkách, ktoré reprezentujú tzv. prerušenie sociálneho poistenia: DMZ Názov mzdovej zložky 215 - Návšteva lekára - neplatená 217 - Sprievod RP - neplatený 219 - Sprievod RP ZPS - neplatený 234 - Prekážky zo všeobecného záujmu 245 - Väzba, výkon trestu odňatia slobody 246 - Neplatené voľno 249 - Neplatené voľno - KZ 103 - Rodičovská dovolenka 244 - Absencia Čo musíte urobiť: Nič.

Úpravu urobíme my v rámci aktualizácie na túto verziu a vyššiu. Mzdy spracované do decembra 2026 sa nemenia a nič sa spätne neprepočítava. Odporúčame: Pri prvom spracovaní miezd za 1/2027 (aspoň jedného zamestnanca) skontrolujte toto nastavenie. Samotné označenie atr. X je možné vykonať aj ručne a to hromadnou akciou Prerušenie poistenia. Zoznam distribučných mzdových zložiek (DMZ), ktoré by mali byť v tejto sekcii priradené: zdravotné poisťovne (SK) obsahujú DMZ: 101, 103, 104, 200, 201, 202, 204, 220, 223, 234, 245 sociálne poisťovne (SK) (okrem symbolu UP) obsahujú DMZ: 101, 103, 200, 201, 202, 204, 215, 217, 219, 220, 223, 234, 244, 245, 246, 249 poisťovne so symbolom UP obsahuje DMZ: 101, 103, 200, 201, 202, 204, 215, 217, 219, 220, 223, 234, 244, 245, 246, 249.

Pri ďalšom pracovnom pomere tej istej osoby (kópia karty zamestnanca založená príjmom pracovného pomeru z AVA) sa do prípravy nástupu prevezme zdravotné obmedzenie a držiteľ karty ZTP/P z pôvodnej karty zamestnanca. Neskoršie zmeny týchto údajov z AVA sa zapíšu aj do nespracovanej prípravy nástupu ďalšieho pracovného pomeru. Zmena zdravotnej poisťovne alebo profesie zamestnanca prijatá z AVA sa novo zapíše aj do už založenej nespracovanej prípravy nástupu (zdravotná poisťovňa aj pri ďalších pracovných pomeroch tej istej osoby).

Doteraz sa tieto údaje do prípravy nástupu prevzali len pri jej založení. E-mail a mobil (pracovné aj súkromné) a pracovný telefón, ktoré sa zmažú v AVA, sa zmažú aj v Heliose; súkromný telefón a ostatné kontakty zostávajú. Obec miesta výkonu práce prijatá z AVA novo doplní aj názov obce podľa číselníka obcí, rovnako ako pri výbere kódu v Heliose. Obec, ktorá v číselníku obcí ešte nie je, sa pri príjme z AVA do číselníka založí (ak ide o šesťmiestny kód obce), namiesto toho, aby sa odmietli všetky doplňujúce údaje zamestnanca.

Plánovaná zmena mzdy prijatá z AVA sa novo odmietne, ak typ mzdy (mesačná, hodinová) v nej chýba alebo nesúhlasí s typom mzdy v mzdových údajoch zamestnanca. Predtým sa suma naplánovala bez ohľadu na typ mzdy, takže hodinová sadzba sa mohla naplánovať ako mesačná mzda. Typ mzdy plánovanou zmenou z AVA zmeniť nie je možné. Denný úväzok poslaný z AVA sa novo zapíše do prípravy nástupu rovnako ako týždenný úväzok a po vzniku pracovného pomeru je aj v mzdových údajoch.

Doteraz sa z AVA prevzal len týždenný úväzok a denný zostal nulový. Ročná výmera dovolenky nového zamestnanca poslaná z AVA (Pinya) sa pri slovenskej legislatíve do prípravy nástupu nepreberá, nárok na dovolenku určuje Helios podľa zákona ako doteraz.

ÚPRAVA - Súbeh rodičovskej dov. s nárokom na materské - VP Ak otec, ktorý je v pracovnoprávnom vzťahu k zamestnávateľovi, prevezme starostlivosť o dieťa a požiada Sociálnu poisťovňu o materské, u zamestnávateľa je na rodičovskej dovolenke v súlade s § 166 ods. 1 Zákonníka práce, v zmysle ktorého mužovi patrí rodičovská dovolenka v súvislosti so starostlivosťou o narodené dieťa v rovnakom rozsahu ako patrí žene materská dovolenka. Čas rodičovskej dovolenky otca podľa § 166 ods.

1 Zákonníka práce sa na účely dovolenky posudzuje ako doba výkonu práce (ďalej VP) v súlade s § 144a ods. 1 psím. a) Zákonníka práce. Ak otec po skončení poberania materského pokračuje v rodičovskej dovolenke, z pohľadu Zákonníka práce ide o prehĺbenie starostlivosti o dieťa a zamestnávateľ je v súlade s § 166 ods. 2 Zákonníka práce povinný mu poskytnúť rodičovskú dovolenku až do dňa, v ktorom dieťa dovŕši 3 roky veku. Čas rodičovskej dovolenky otca podľa § 166 ods.

2 Zákonníka práce sa na účely dovolenky v súlade s § 144a ods. 3 písm. b) Zákonníka práce neposudzuje ako doba VP. Z pohľadu systému Helios Inuvio doteraz používateľ výpočet nároku na dovolenku o zamestnanca vyradeného z evidenčného stavu na rodičovskú dovolenku, ktorý súčasne mal Súbeh poberania materskej dávky pri vyňatí na RD v prípade potreby upravoval nárok na dovolenku ručnou korekciou. Od mzdového obdobia 1/2027 sa v prípade takéhoto súbehu, táto doba bude automaticky započítavať do VP pre účely výpočtu nároku na dovolenku (viď atribúty Dni výkonu práce - bežný rok a Dni výkonu práce v mesiaci nad prehľadom Mzdové údaje).

Do logování rychlosti byl doplněna možnost vkládat si krátké uživatelské poznámky do logu (max. 255 znaků). Pomocí těchto poznámek je možné si rozdělit logy do více částí, pokud je například logování nejprve prováděno s nějakým nastavení, pak se nastavení změní a logování se provede znovu. Poznámku do logu lze vkládat přímo akcí nad dokladem (Systém / Logování - rychlost / Přidat poznámku ) nebo přímo v přehledu zalogovaných operací. Zde je také možné poznámku případně opravit.

Poznámka se vkládá s novým typem záznamu "user note".

REST API – log chyb: varování z kontrol při zápisu záznamu (např. z formuláře dokladu), která se dosud u některých částí REST API ztrácela, se nyní zapisují do logu chyb REST API spolu s ID záznamu. Týká se zápisu dat z AVA (modely AVA) a zápisu zakázek, uchazečů o zaměstnání a zařízení mobilit. Odpověď REST API se nemění. Při importu faktury nebo dobropisu přijatého z AVA se navíc zapíše varování, pokud má zvolená řada dokladu nastavený jiný zdroj kurzu DPH než kurz faktury – doklad se z AVA zakládá vždy se zdrojem kurzu DPH „kurz faktury“ stejně jako přes REST API pro faktury.

REST API – faktury: při založení faktury vydané nebo přijaté přes REST API se nyní vrátí varování, pokud má zvolená řada dokladu nastavený jiný zdroj kurzu DPH než kurz faktury. REST API vždy respektuje kurz poslaný v požadavku, a proto zakládá doklad se zdrojem kurzu DPH „kurz faktury“ bez ohledu na nastavení řady. Faktura se založí jako dosud; varování se vrátí v odpovědi a zapíše se do logu chyb REST API, takže je rozdíl proti nastavení řady vidět.

REST API: popis přehledu (meta) u došlých objednávek v řešení a u importu pohybů servisu uváděl jeden sloupec dvakrát a specifikace přehledu pak vynechala sloupce, které za ním následovaly. Opraveno. U uzavřených došlých objednávek se zároveň opravil příznak interních komentářů, který se nevyhodnocoval podle správné tabulky.

Jazykové soubory pro angličtinu, němčinu a slovenštinu (32bitové i 64bitové) se vyrábějí spolu s verzí, takže obsahují překlady všech hlášek dané verze.

Kontextové menu nad nadpisy sloupců v přehledech nabízí akci Nastav.. (F4). Nastavení sloupců, řazení a filtru tak lze otevřít přímo z gridu, bez nabídky Přehled. Uživatel bez práva Nastav vidí položku zakázanou.

Doplněny chybějící a opraveny nepřesné překlady hlášek do angličtiny, němčiny a slovenštiny, včetně hlášek partnerských řešení. Texty, které se nepřekládají (názvy produktů, zkratky apod.), se ve všech jazycích zobrazují česky.

REST API: Monitor aktivit nově eviduje i použití jednotlivých endpointů REST API, stejně jako používání přehledů a jejich akcí. Záznamy jsou pod položkou Inuvio REST API a akce nese název endpointu, např. [GET] browses/data. Zaznamenává se každé volání endpointu nad databází, i neúspěšné. Když zápis do Monitoru aktivit v některé databázi selže, vypne se evidence jen pro tuto databázi. Dosud se vypnula až do ukončení aplikace, takže se po přepnutí do jiné databáze nic nezaznamenávalo.

Rozkopírování do jiných databází je ve cvičné databázi nově zakázané i u uživatelského menu, uživatelských tabulek, externích akcí, automatu, obecných vazeb a přehledů, pomocných kategorií, textů e-mailů a automatizace. Stejně jako export a rozkopírování číselníků ohlásí „Tato funkcionalita není v cvičné databázi povolena!“. Import do cvičné databáze zůstává povolený.

V přehledu Zprávy je nová akce Uložit na disk (skupina Ostatní). Pro označené zprávy uloží do vybraného adresáře kopii obsahu zprávy (atribut Dokument), a to i u nepodepsaných zpráv; zprávy v databázi zůstávají beze změny. Je-li ke zprávě uložena podepsaná zpráva, uloží se vedle se stejným jménem a přídavkem _signed (s příponou .xml, .p7s nebo .txt podle obsahu). Pokud má v jednom běhu více zpráv stejné jméno souboru, další soubory dostanou číslo zprávy.

Při existenci cílového souboru se akce zeptá na přepsání (Ano, Ano všem, Ne, Ne všem). Zprávy bez uloženého obsahu se přeskočí s hlášením „Dokument není uložen v databázi“.

Spuštění SQL příkazu z editoru SQL v přehledu (Ctrl+Q, tlačítka OK a ExecSQL) se nově zapisuje do žurnálu jako událost „SQL editor (Ctrl+Q) – spuštění příkazu“: kdo, kdy, na jakém počítači, v jakém přehledu, zda byl příkaz upraven a s jakým výsledkem. Obsah příkazu se neukládá, záznam obsahuje jen jeho otisk, podle kterého lze poznat opakované spuštění stejného příkazu. Záznam nelze ze žurnálu smazat.

Pokud se nad stejnou databází střídal 32bitový a 64bitový Helios, spouštěla se při startu opakovaně kontrola struktur databáze a start se tím během dne zbytečně zdržoval. Velikost a datum programu se nově evidují zvlášť pro 32bitovou a 64bitovou verzi, takže kontrola proběhne pro každou z nich jen jednou.

REST API: metadata akce (actions/meta) vracela u interních akcí (typ 99) v atributu actionIconId prázdný řetězec místo hodnoty null. Atribut nyní odpovídá specifikaci (celé číslo nebo null) a shoduje se s výpisem akcí (actions/list).

REST API: počítané sloupce přehledů, které nemusí mít hodnotu (např. Úkoly – Plnění (hod), Doklady zboží – saldo a penalizace), jsou nově v popisu přehledu i v dokumentaci API uvedené jako nepovinné (nullable). Dřív byly vedeny jako povinně vyplněné, přestože server v nich vracel prázdnou hodnotu, a klient vygenerovaný ze specifikace na tom mohl skončit chybou. V aplikaci lze u těchto sloupců ve filtru zvolit i podmínku na nevyplněnou hodnotu.

Časové razítko (editor dokumentů, výměna zpráv, podpis XML zpráv): spojení se serverem časových razítek (TSA) přes https používá jen TLS 1.2 a 1.3 a ověřuje certifikát serveru – důvěryhodnost vydavatele podle úložiště certifikátů Windows, platnost a shodu se jménem serveru. Se serverem s nedůvěryhodným, prošlým nebo cizím certifikátem se spojení odmítne (hláška „TLS certificate validation failed: error …“). Žádost o razítko nově obsahuje jednorázovou hodnotu (nonce), kterou Helios v odpovědi kontroluje.

Používá-li TSA certifikát, kterému Windows nedůvěřují (např. testovací TSA), je třeba doinstalovat kořenový certifikát vydavatele mezi důvěryhodné kořenové certifikáty a Helios restartovat. E-mail přes OAuth2 (profil e-mailu typu OAuth2, např. Microsoft 365): získání tokenu i odeslání přes SMTP se zabezpečením SSL/TLS používá jen TLS 1.2 a 1.3 a ověřuje certifikát serveru stejně jako u časového razítka. Je-li v profilu jako SMTP server uvedena IP adresa nebo jiné jméno, než na které je certifikát serveru vystaven, odeslání skončí chybou 75788 – v profilu je třeba uvést jméno serveru (např.

smtp.office365.com).

Práce s obrázky (načítání, zobrazení a tisk obrázků uložených v záznamech): komponenta ImageEn aktualizována na verzi 15.2.3.

REST API – faktury, dobropisy a zakázky: založení nebo změna dokladu už neukládá kartu nalezeného dodavatele, odběratele nebo příjemce zakázky, pokud se zadané údaje (včetně IČO a DIČ, podle kterých se organizace hledá) od karty neliší; jinak se zapíšou jen změněné údaje. Dříve se tím měnila verze řádku karty a u části organizací i datum a autor poslední změny na účet REST API.

Nová verze komponenty: Developer Express 26.1.6.

REST API – položky storna výdeje a storna příjmu: změna měrné jednotky už nemění celkovou požadovanou evidenční cenu, stejně jako v editoru položky. Dřív se cena při změně MJ s neukončeným převodem nepatrně změnila a při vymazání MJ se vydělila koeficientem původní MJ.

Organizace – aktualizace podle registru Finstat (SK): když ověření selže (např. vyčerpaný limit dotazů nebo nedostupná služba), zobrazí se místo prázdného okna přehled chyb s důvodem u každé organizace. Pro IČO, které Finstat nezná, se zobrazí hláška „organizace nebyla v registru nalezena“, stejně jako u ARES.

Došlo k úpravě rozložení editoru pro spouštění logování, aby byl přehlednější a výběry v něm lépe dostupné.

REST API – faktury (/api/v1/invoices): rekapitulaci DPH lze při založení faktury zadat i u faktury s měnou DPH jinou než hlavní měna, např. u faktury v EUR vystavené pod zahraniční registrací DPH vlastní firmy. Částky DPH se zadávají v měně DPH; rozdíl proti výpočtu Inuvia se zapíše jako korekce rekapitulace DPH (doplňková položka). Doposud API takovou rekapitulaci odmítlo chybou. Podporovaná je měna DPH shodná s hlavní měnou nebo s měnou faktury.

Změna chování: u faktury s měnou DPH jinou než hlavní měna vrací načtení faktury (GET) rekapitulaci DPH v měně DPH, doposud ji vracelo v hlavní měně. U ostatních faktur beze změny. U faktury s formou úhrady zaokrouhlovanou na padesátníky se po korekci rekapitulace DPH přepočtou korekce zaokrouhlení stejně jako při uložení v editoru dokladu – faktura založená přes REST API se pak při následném uložení už nemění.

Invoices REST API nově podporuje dobropisy vydané a přijaté přes endpoint /api/v1/creditNotes (issued a received). Dobropisy jde zakládat, číst včetně položek a rekapitulace DPH a mazat stejně jako faktury. Všechny částky dobropisu se zadávají i vracejí kladně. Nepovinné pole originalInvoiceId propojí dobropis s původní fakturou. Endpoint /api/v1/invoices pracuje dál jen s fakturami: dobropis přes něj nejde přečíst ani smazat (dříve šlo dobropis smazat přes DELETE faktury).

Dokumentace REST API faktur a dobropisů je na /doc/invoices.

REST API – faktury (/api/v1/invoices/issued a /api/v1/invoices/received): rekapitulace DPH zadaná při založení faktury (vatRecapitulation) se na faktuře správně projeví i tehdy, když se DPH v hlavičce faktury zaokrouhluje hruběji než na položkách (např. na desetníky). Rozdíl proti výpočtu Heliosu se nově zapisuje jako korekce rekapitulace DPH (doplňková položka) místo textové položky „Korekce DPH“, takže se neobjevuje jako řádek na tisku faktury a při dalším uložení dokladu se nezmění.

Stejně se zpracovává rekapitulace DPH faktur a dobropisů přijatých importovaných z AVA. Změna chování: u faktury vydané v řadě, která nemá zapnuté Povolit úpravu DPH, se zadaná rekapitulace DPH lišící od výpočtu Heliosu odmítne chybou „Rekapitulaci DPH nelze upravit, na řadě dokladu není povolena úprava DPH“ a faktura se nezaloží. Doposud se faktura založila s DPH podle výpočtu Heliosu a zadaná rekapitulace se tiše ignorovala. Pro zadávání vlastní rekapitulace je potřeba na řadě povolit úpravu DPH; rekapitulace shodná s výpočtem Heliosu projde i bez ní.

Nelze-li rekapitulaci DPH na zadané částky upravit (např. částka DPH u sazby bez DPH), API vrátí chybu „Rekapitulaci DPH nelze upravit na zadané částky“ a faktura se nezaloží.

Doplněn nový licencovaný modul Helios e-Link.

Export sestav do PDF, XLSX, RTF a dalších formátů: komponenta eDocEngine aktualizována na verzi 5.0.0.642 (opravy výrobce při exportu obrázků).

Do žurnálu se nově zapisuje správa uživatelů a rolí: založení uživatele, přidání a smazání uživatele v databázi a na SQL Serveru, změna hesla (vlastní i správcem, bez hesla samotného), změna přihlašovacího jména, zapnutí a vypnutí přístupu k Helios Inuvio REST API a speciálních systémových práv a založení a zrušení role. Záznamy mají úroveň Vysoká a nelze je smazat. Zapisují se i akce z Helios Konzole.

Doklad založený z přehledu Organizace akcí Nový doklad (faktura vydaná, expedice, nabídka, došlá objednávka, příjemka, výdejka, poptávkové řízení, kontaktní jednání) se po uložení tlačítkem Def.OK nezpracoval podle nastavení Def.OK – nespustila se externí akce, tisk ani automat. Nově se tyto akce provedou stejně jako při založení dokladu přímo v jeho přehledu.

Hlášení chyb: komponenta EurekaLog aktualizována na verzi 7.16.2.0 (opravy výrobce).

Přístup k databázi: komponenta Devart SDAC aktualizována na verzi 13.1.0 (mimo jiné opravy výrobce při ukládání dat z dotazů nad více tabulkami).

Tiskové sestavy: komponenta ReportBuilder aktualizována na verzi 23.05 (opravy výrobce mimo jiné v exportu do PDF, náhledu PDF a odesílání sestav e-mailem).

Tiskový dialog sestav: počet kopií lze zadat v rozsahu 1 až 9999. Neplatná nebo prázdná hodnota se nahradí jednou kopií, potvrzení dialogu klávesou Enter už nevede k chybové hlášce.

Pro registraci tržeb dle legislativy EET 2.0 přibyl licencovaný modul “Konektor EET 2.0”. V nastavení EET (Možnosti, Konfigurace/správa systému, Firemní konstanty) se zobrazuje zeleně, že je modul v licenci textem „Konektor EET 2.0 v licenci - OK“. Pokud v licenci není, zobrazí se červeně upozornění, že tržby určené k registraci nebude možné registrovat z Helios Inuvio a je třeba si licenci opatřit na AVAplace:. Konstantu “Používat elektronickou evidenci tržeb” lze nově nastavit i na hodnoty EET Test a EET Zapnuto.

Nastavení na hodnotu EET Zapnuto má smysl až po spuštění produkčního prostředí pro EET 2.0. Potřebné informace o krocích, které je třeba učinit v souvislosti s přípravami na ostrý provoz EET 2.0 v Helios Inuvio, získáte v článku poradny Příprava na ostrý provoz EET 2.0 - Poradna (CZ) – HELIOS Inuvio .

Nová verze komponenty: Developer Express 26.1.5.

Datové schránky: odesílání datové zprávy teď kontroluje legislativní limity - nejvýše 50 příloh a celková velikost příloh nejvýše 100 MB. Při překročení se zpráva neodešle a zobrazí se příslušná hláška. Opraveno přetečení paměti (Out of memory) při odeslání, příjmu a stahování velkoobjemových datových zpráv (VoDZ) blížících se 100 MB, včetně stahování jednotlivých příloh a ověření platnosti zprávy. Ověření platnosti zprávy nyní funguje i pro velkoobjemové zprávy.

Opravena diakritika v názvech a jménech (odesílatel, adresát, názvy příloh) u stahovaných velkoobjemových zpráv. Funguje i adresa prostředí datových schránek bez www. Při stahování zpráv se v průběhové hlášce nyní uvádí i ID zprávy, takže je při chybě známo, která zpráva je problematická.

Po ztrátě spojení se SQL serverem (např. výpadek sítě, odpojení notebooku od Wi-Fi po uspání) zobrazí HELIOS hlášku „Spojení se SQL-serverem bylo přerušeno. Příčinou může být výpadek sítě nebo SQL-serveru.“ a ukončí se. Dříve mohl v takové situaci hlásit různé nesrozumitelné chyby, např. „Object was open“, a pracovat dál bez funkčního spojení. Výpadek pomocného spojení pro načítání počtu notifikací už práci neovlivní – počet notifikací se dál načítá přes hlavní spojení.

Zpřesněny popisy a bublinová nápověda cenových sloupců položek dokladů, došlých objednávek, pokladního prodeje a servisu. Ceny označené jako „valuty“ nebo „v cizí měně“ jsou nyní správně popsány jako ceny v měně dokladu – u dokladu v hlavní měně se shodují s cenami v hlavní měně. Popis atributů Primární cena a Druh vstupní ceny nově vysvětluje, že vlastní cena položky se při zadávání (také přes HELIOS API) zadává do Primární ceny a druh vstupní ceny určuje, jak se tato hodnota čte.

Položky pokladního prodeje nově obsahují sloupec Primární cena.

Zabezpečená komunikace s externími službami (datové schránky, portál zdravotních pojišťoven, odesílání e-mailů, import číselníku finančních úřadů, dashboardy BI a další) nově používá aktuálně podporovanou knihovnu OpenSSL 3 a protokol TLS 1.2 nebo novější. Aplikace nově ověřuje certifikát serveru proti důvěryhodným certifikátům ve Windows. Spojení se serverem s neplatným, prošlým nebo self-signed certifikátem se odmítne. Typicky se to může projevit u interního SMTP serveru – jeho certifikát je potřeba opravit nebo ho přidat do důvěryhodných certifikátů Windows.

Ověřování lze nouzově vypnout v souboru Helios.INI v sekci [Application] položkou TLSTrustServerCertificate=1.

Uložení přehledu do souboru (např. do XLS v automatu), kdy cesta nebo název souboru obsahuje sloupce přehledu, už nekončí chybou SQL „Incorrect syntax near 'WHERE'“ u přehledů Kontrola stavu pokladen a Stav bankovních účtů k datu. U přehledů, které nemají definován unikátní klíč, se nyní místo chyby SQL zobrazí hláška „Přehled nemá definován unikátní klíč!“. Týká se to sloupců přehledu použitých v cestě nebo názvu souboru v automatu, ve zprávách, při tisku do dokumentu, v cestě do cloudu a při vytváření dokumentu ze vzoru.

Protokol o chybě (BugReport) nyní obsahuje podrobnější technické informace – průběh volání i v doplňkových knihovnách a stav ostatních vláken aplikace. Usnadní to rychlejší nalezení příčiny nahlášených chyb. Na rychlost aplikace to nemá vliv.

REST API: Obsahuje-li query parametr text, který není platně zakódovaný v UTF-8 (např. diakritika odeslaná v kódování Windows-1250), vrátí server chybu 400 s kódem BadEncoding#001 a českou hláškou s názvem parametru. Dříve vracel obecnou hlášku bez názvu parametru a u požadavku bez přihlášení nebo u dokumentace API chybu 500.

REST API: Seznamy agend (faktury vydané a přijaté a jejich položky, zakázky, uchazeči, mobilní zařízení, seznamy e-shopu) nově přijímají parametr filterId – identifikátor (ID nebo GUID) uložené sestavy přehledu agendy. Data se omezí podmínkou sestavy, obdobně jako parametr reportIdent u browses/data.

REST API: Snapshot dat z přehledu (browses/snapshot) nově podporuje parametr onlyCount – s onlyCount=true se snapshot nezaloží a vrátí se jen počet záznamů – a parametr rowVersion, kterým lze snapshot omezit na záznamy změněné od dané verze.

REST API: Detail záznamu agend (faktury vydané a přijaté, e-shop: sklady, kategorie, zákazníci, slevy, objednávky, produkty, ceníky, způsoby dopravy) nově kontroluje query parametry stejně jako seznam a ostatní endpointy API. Neznámý parametr v URL detailu API odmítne chybou 400; dříve se tiše ignoroval.

REST API: U agendy faktur (invoices/issued, invoices/received) se parametr filter nyní kontroluje samostatně, ještě před sloučením s podmínkou agendy. Filtr s nevyváženými závorkami, komentářem nebo koncovým AND/OR/NOT API odmítne chybou 400 (BadFilter#004 až BadFilter#007); takto zadaným filtrem bylo dříve možné získat i doklady jiného druhu než faktury dané agendy.

REST API: Parametry top a skip pro stránkování nově přijímají hodnoty až do 9223372036854775807 (64bitové celé číslo), takže lze stránkovat i tabulky s více než 2 147 483 647 řádky. U dat ze snímku (snapshots/data) už velké hodnoty skip a top nekončí chybou „Integer overflow“.

Pole Spouštěč akce v monitoringu akcí bylo prodlouženo na 100 znaků.

REST API: Atribut jiné tabulky než hlavní tabulky přehledu nebo její vazby v parametrech select, orderBy a filter nyní API odmítne hned jako neznámý atribut (chyba 400, BadSelect#001, BadOrderBy#001, BadFilter#002). Dříve skončil obecnou chybou Error#001, ve filter i s textem chyby SQL, u názvu obecného přehledu (hvw_…) chybou 404.

REST API: Parametr filter přehledů nově podporuje funkce LEN, UPPER, LOWER, LTRIM, RTRIM, TRIM, LEFT, RIGHT, SUBSTRING, CHARINDEX, REPLACE, CONCAT, COALESCE, NULLIF, IIF, YEAR, MONTH, DAY, EOMONTH, DATEFROMPARTS, GETUTCDATE, SYSDATETIME, ABS, ROUND, FLOOR, CEILING a SIGN, výraz CASE WHEN … THEN … ELSE … END a LIKE … ESCAPE. Funkci je nutné zapsat se závorkami, jinak API vrátí chybu 400 (BadFilter#008); nevyvážené CASE a END vrací BadFilter#009.

HELIOS API: u organizací už nelze zadávat ani měnit údaje, které systém plní sám – saldo a součty uhrazených a neuhrazených faktur před a po splatnosti, celkovou částku a pozastavené částky faktur, datum jejich aktualizace, předběžnou korekci splatnosti, pořadová čísla PZ2, údaje o ověření nespolehlivého plátce, jiného důvodu ručení a SK plátců DPH, datum kontroly insolvenčního rejstříku a datum aktualizace v registru ARES. Tyto údaje plní napočty, ověření z webu a akce v přehledu organizací.

Pokus o jejich zápis přes API skončí chybou.

Skupina ikon pro spouštění logování byla přesunuta na záložku system.

REST API nově nabízí tisk u dalších 28 přehledů. Jde například o Definované přehledy, Uchazeče o zaměstnání, Školení a lékařské prohlídky, Variabilní symboly, Kategorie organizace, Balicí skupiny a balicí listy, Protokol o provedené práci, Finanční analýzu, Typ pracovní doby, Kurzy mzdových měn, Filtraci tabulek, Personální složky, Vstupní doklady dodatečných souvisejících nákladů, Kontrolní hlášení CZ a jednotlivé části kontrolního výkazu DPH SK.

V programu se nic nemění - týká se to pouze tisku vyvolaného přes REST API.

Slovenský překlad hlášek: zkratky upraveny podle slovenských zvyklostí. DPP → DVP (dohoda o vykonaní práce) v mzdách: Výkaz príjmov DVP; Hlásenie DVP na SSZ - kontrolný prehľad; Súbeh MD, OD, RD na DVP/DPČ; DVP/DPČ - dôchodcovia, MD, OD, RD (i s odvodovým zvýhodnením); hlášení o neplatném druhu důchodu při souběhu na DVP/DPČ. DUZP → DDPP: Povolený rozdiel dní medzi DDPP a dátumom vystavenia; Nebol nájdený dátum DDPP. RZD: Dátum podpisu žiadosti o RZD (dříve rozepsáno „ročné zúčtovanie dane“).

Opravy podle revize slovenského překladu v mzdách: mzdová složka MZ místo MS: Platobný príkaz bude generovaný iba z paušálnych mzdových zložiek typu Záloha z paušálov (referenčná MZ 119) a obdobně u atributu Iba z paušálov. Základ pre soc.poi. - iba mimo rizikovej práce a práce v HZZP (dříve soc.poj. a HZSP). V prehľade Dane chýba systémový záznam pre preddavkovú daň so symbolom „PD“ (dříve zálohovú daň „ZD“). Upozornění výpočtu mzdy: PIPP místo PJPP, Príspevok PDS místo PDP a opravené poškozené znaky (skrátiť, zdaniť, zrážková daň).

V tiskové frontě pro tisk přes iNuvio Server (tabulka TabESServicePrints) přibyl sloupec resultedDocumentIds. Po zpracování tisku se do něj zapisuje seznam ID dokumentů, které tisk založil, oddělených čárkami. Pokud tisk žádný dokument nezaloží, zůstane sloupec prázdný. Sloupec odpovídá sloupci Print_resultedDocumentIds u příloh zpráv (TabESServiceAttachments). Není veřejný, v přehledu se tedy nezobrazuje; slouží integracím, které potřebují po tisku dohledat vzniklé dokumenty.

Akce zpřístupněné přes REST API nově vracejí podrobný popis v atributu actionDescription, a to v seznamu akcí (actions/list) i v jejich metadatech (actions/meta). U externí akce se popis bere z pole Technický popis, u interní akce ho určuje implementace. Seznam akcí lze nově filtrovat dotazem search, který hledá v názvu, nápovědě i popisu akce bez ohledu na diakritiku a velikost písmen - stejně jako u seznamu přehledů. Nápověda a popis se do odpovědi zařazují, jen když jsou vyplněné.

Barvení sloupců přehledu lze nově řídit i z tabulky připojené vazbou. Do názvu barvicího sloupce _HeIQ_CC_, _HeIQ_CB_ a _HeIQ_CP_ je možné vložit systémový název hlavní tabulky přehledu a obarvit tak její sloupec, i když je barvicí sloupec v jiné tabulce nebo pohledu připojeném vazbou. Formát je _HeIQ_CB_<C_><T_><A>, kde <T_> je systémový název hlavní tabulky následovaný podtržítkem. Například _HeIQ_CB_1_TabDokladyZbozi_NavaznaObjednavka obarví sloupec NavaznaObjednavka tabulky TabDokladyZbozi.

Dosud bylo možné obarvit pouze sloupec z téže tabulky či vazby, ve které je barvicí sloupec. Bez změny názvu se chování nemění.

Nová verze komponenty: EurekaLog 7.16.1.1.

Hláška o odepřeném přístupu k eServeru nyní uvádí přihlašovací jméno, podle kterého se kontrola ptala, a rozlišuje, zda uživatel nemá zaškrtnuté povolení pro eServer, nebo zda v tabulce uživatelů vůbec není. Druhý případ typicky znamená, že služba běží pod jiným účtem, než pod kterým se autentizuje klient — obvykle při Windows autentizaci (LoginMode=2 v Helios.ini) a službě spuštěné pod účtem Local System.

Nastavení widgetů na nástěnce (období a řazení daňového kalendáře, datum kurzů ČNB a NBS, řazení seznamu událostí, velikost tlačítek widgetu Workflow) se nově ukládá hned při změně. Pokud má uživatel spuštěno více Heliosů najednou, změny provedené v jednom z nich už nepřepíše Helios zavřený jako poslední. Daňový kalendář si nově pamatuje zvolené vzestupné řazení i po aktualizaci dat a po novém spuštění Heliosu.

Při vypnutých notifikacích (StopNotif=1 v Helios.ini nebo parametr -N) Helios Inuvio už neotevírá druhé, notifikační spojení na SQL server. Každý přihlášený uživatel tak drží o jedno spojení méně, což se projeví hlavně na terminálových serverech.

Upraveno dotažení hodnoty “SQL-server běží od” pro statistiku v globální konfiguraci. On SQL Server 2019 (15.x) and earlier versions, and SQL Managed Instance, you require VIEW SERVER STATE permission. On SQL Server 2022 (16.x) and later versions, you require VIEW SERVER PERFORMANCE STATE permission on the server.

HELIOS iNuvio nově umí vydat své ovládací prvky rozhraní Microsoft UI Automation, aby šly automatizovaně testovat a ovládat. Týká se to příkazů pásu karet, uzlů navigočního stromu, tlačítek rychlých voleb, textu chybových hlášek, řádků a skupin přehledů a polí editorů. Každý takový prvek má stálý identifikátor, který se nemění mezi spuštěními programu, takže se na něj dá spolehlivě odkazovat. Funkce je ve výchozím stavu vypnutá a zapíná se přepínačem příkazové řádky -GUIA.

Bez něj se program chová úplně stejně jako dosud. Je to záměrné rozhodnutí: zapnuté UI Automation zpřístupní obsah obrazovky ostatním programům běžícím pod týmž přihlášením, což u systému se mzdovými daty není žádoucí zapnout natrvalo.

Rozhraní pro pluginy (Plugin Interface) bylo rozšířeno o funkci PotvrzeniGlobalnimHeslem. Plugin s ní může před spuštěním akce vyžádat potvrzení globálním heslem stejně jako Helios: uživateli s nastaveným speciálním systémovým právem „Vyžadovat globální heslo“ se zobrazí standardní dialog pro zadání hesla, ostatním uživatelům dotaz, zda si přejí pokračovat. Funkce je k dispozici od verze 3.0.2026.0967. Preferovaným způsobem volání je funkce plgPotvrzeniGlobalnimHeslem z jádra pluginu (HeCore, unita plgMain).

Ta sama ověří verzi Heliosu: v podporované verzi zavolá PotvrzeniGlobalnimHeslem, ve starší verzi zobrazí jen dotaz, zda si uživatel přeje pokračovat (výchozí odpověď Ne). Při přímém volání PotvrzeniGlobalnimHeslem musí plugin verzi Heliosu ověřit sám, jinak ve starší verzi dojde k chybě.

Tiskové sestavy a formuláře: zrychleno opakované otevírání náhledu a tisk formulářů i přehledů. Program už před každým tiskem znovu nenačítá seznam tiskáren a jejich vlastnosti z ovladače, ale jen tehdy, když se seznam tiskáren ve Windows změní (tiskárna přibyla, byla odebrána nebo přejmenována, např. u tiskáren přesměrovaných přes vzdálenou plochu). Projeví se to hlavně na Windows 11 u tiskáren, jejichž ovladač odpovídá pomalu.

V přehledu Skupiny nástrojů přizpůsobení přibyla akce Doplnit chybějící skupiny. Založí skupiny, které jsou zadané u nástrojů přizpůsobení (např. definovaných přehledů, externích akcí, uživatelských sloupců, sestav nebo tiskových formulářů), ale v přehledu skupin dosud chyběly, a oznámí jejich počet. Přehled nově ukazuje počet záznamů a datum aktualizace i pro Asistenta a Filtraci tabulek a v akci Přehledy lze otevřít Filtraci tabulek pro vybranou skupinu.

Tisk do souboru ve formátu PDF/A: dokumenty vytvořené ve starších verzích mohly mít chybně zapsaná metadata dokumentu (např. jméno autora s diakritikou). Validátory PDF/A, mimo jiné validátor Národního archivu, pak soubor nerozpoznaly jako PDF/A a označily ho za nevalidní. Chybu odstranila nová verze tiskové komponenty ReportBuilder, která je součástí aktuální verze systému. Dokumenty vytvořené v aktuální verzi mají metadata v pořádku a validací PDF/A-1b procházejí.

Dokumenty vytvořené dříve je potřeba vygenerovat znovu. Dodatečně opravit je nelze, zejména jsou-li elektronicky podepsané – každá úprava by podpis zneplatnila.

Nastavení sestav: uživatel, který nemá právo „Uložit sestavu“, už nemůže přepsat veřejnou sestavu tím, že ji pod stejným názvem uloží jako soukromou – ostatní uživatelé by k ní dosud ztratili přístup. Uživatel s tímto právem je před takovým přepisem upozorněn, že ostatní uživatelé ke sestavě ztratí přístup.

Hromadně pro e-mail: při zrušení akce bez odeslání (ESC nebo zavření okna) se už nemažou dokumenty, které uživatel ručně přidal do jednotlivých příloh – zůstávají u dokladu i na disku. Maže se jen to, co akce sama vygenerovala (PDF, přílohy ze zpráv, např. ISDOC).

Hromadná změna práv v přehledu Zobrazení práv nově při povolení práva Vidět zpřístupní i modul, do kterého přehled patří. Dříve se u uživatelů, kteří v daném modulu neměli žádné právo, právo nezměnilo, přestože akce proběhla bez chyby. Opravena také chyba v negativních právech: při úpravě práv více vybraným uživatelům najednou v Editoru práv dostal každý druhý uživatel opačná práva, než byla nastavena.

Pluginy (externí akce) spuštěné v Heliosu s řádkovým přepínačem /XX už nezobrazují informační ani chybová hlášení, která posílají přes rozhraní Heliosu (Info a Error). Text hlášky se místo toho zapíše do Žurnálu jako událost Externí plugin, s názvem pluginu a typem hlášky. Pluginové akce tak lze spouštět bez obsluhy, například z Automatu, bez obalování každé akce do vlastního automatu. Platí i pro starší pluginy. Zápis do Žurnálu proběhne, je-li úroveň žurnálování alespoň 1.

Dotazy pluginů (Ano/Ne) a vlastní okna pluginů se zobrazují dál.

Upravená hlavní nabídka nově respektuje změnu umístění přehledu. Pokud se přehled v definici uživatelských soudečků přesune do jiného soudku (např. ze Skladů do Nákupu a prodeje), zobrazí se v upravené hlavní nabídce v novém soudku a ponechá si nastavenou viditelnost. Dříve zůstával v původním soudku, dokud se upravená nabídka nezrušila. Zároveň se opravilo zobrazení přehledů externího soudku po smazání nebo přesunu jeho prvního přehledu – zbývající přehledy se už nezobrazují mimo soudek v kořeni nabídky.

Nově přidané přehledy se v upravené hlavní nabídce i nadále zobrazují jako skryté; zpřístupní se zaškrtnutím v definici hlavní nabídky.

REST API – došlé objednávky: při změně organizace (PUT) se nově dopočítají údaje z nové organizace (DIČ, kontaktní osoba, bankovní spojení, konstantní symbol, měna a kurz) stejně jako v editoru; dříve se uložení změny mohlo odmítnout chybou cizího klíče DIČ. Při zadání měny nebo data případu se kurz načte podle kurzovního lístku k datu případu, kurz zadaný ve vstupu zůstane zachován.

Při přepnutí režimu práv z negativních na pozitivní se nově vypne i dvoustavové zadávání práv. Dříve zůstalo zapnuté a v pozitivních právech pak nešla spustit hromadná změna práv ani kopírování práv do dalších databází. Databázi, které se to už stalo, opraví otevření a uložení formuláře Změna režimu práv.

Editor obrázku zobrazoval u obrázků ve formátu WebP ve stavovém řádku formát „wbmp“ a při uložení obrázku do souboru nabízel příponu .wbmp. Nyní se zobrazuje i nabízí správně „webp“.

REST API: přehledy definic práv (druhy dokladů zboží, sestavy, schránky evidence pošty, skupiny leasingů, definice práv finanční analýzy) a přehled Disponenti skončily při čtení dat chybou, pokud obsahovaly sloupec s celým jménem uživatele. Sloupec se nyní načte správně.

REST API: sloupce stavů účtů a salda ke dni, jejichž hodnotu počítá až aplikace podle zadaného data, už REST API nenabízí. Dříve je vypisovala v popisu přehledu a jejich čtení končilo chybou SQL; nově v popisu přehledu nejsou a jejich použití ve výběru sloupců, filtru, třídění nebo v sestavě vrací chybu „Sloupec … není na API přístupný“. Sloupce uložené a výchozí sestavy se nově řídí právy na sloupce stejně jako výběr sloupců — sloupec, na který uživatel nemá právo, vrací chybu 403 místo hodnot.

Pro výběr všech sloupců (select=*) se sloupce bez práva vynechají.

Integrace AVA: při přenosu víc než 1000 záznamů najednou (např. plný přenos číselníku) se nyní zapíše potvrzení publikace z AVA. Dříve zůstaly záznamy v logu synchronizace jen ve stavu přijato.

V přehledu "Země" se při použití akce "Nastavení vlastní země" se nelogoval údaj ve sloupci “Datum změny”. Opraveno.

Opraveno: při importu definice uživatelské tabulky ze souboru se nenahrál skript validace, pokud tabulka neměla zároveň vyplněný skript pro novou větu. Projevovalo se to při ručním importu, autoimportu, instalaci pluginu i při rozkopírování uživatelských tabulek do dalších databází. Definice importované dříve je potřeba naimportovat znovu.

REST API: čtení všech sloupců přehledů Kapacitní plán, Etapy, Certifikáty a zkoušky – certifikovaní, Vícenásobné vztahy, Skupiny nástrojů přizpůsobení, Položky na paletě, Došlé objednávky – položky a Personální složky (pracovní pozice) končilo chybou SQL kvůli chybnému výrazu některého počítaného sloupce. Výrazy jsou opravené. U Personálních složek (pracovní pozice) byl odstraněn sloupec Má dokument, který se ke složce pracovní pozice nevztahoval.

REST API: seznam přehledů (browses/list) a stromy přehledů už nenabízejí přehledy, které přes REST API nejde přečíst — přehledy bez unikátního klíče a přehledy závislé na dočasné tabulce, kterou zakládá jen aplikace Helios Inuvio. Dříve je seznam nabídl a jejich načtení skončilo chybou.

Opravena chyba, kdy uložení záznamu databáze v Konfigurace → Systémové konstanty skončilo chybou Access violation, pokud databáze odkazovala na vlastní ikonu, která v ní už neexistuje (typicky po obnově databáze ze zálohy). Neexistující ikona se nyní při uložení zruší a použije se implicitní ikona. Totéž platí i v ostatních editorech, ve kterých se nastavuje vlastní ikona (např. oblasti dokumentů nebo workflow).

Majetek – Výsledky inventury: sloupec Položka vícekrát se nově zobrazuje jako logický (zaškrtávací) a REST API ho vrací jako true/false místo 0/1. Opraveno také chybné označení duplicity u řádků, u kterých karta majetku nebyla nalezena – takové řádky se už jako položka uvedená vícekrát neoznačují.

REST API: přehledy syntetických účtů, deníku, výkazových řádků, majetku (účetní sazby, způsoby odpisu), měrných jednotek zboží a ukazatelů výkazových sestav FIA vracely v datech některé sloupce s jinou velikostí písmen než v metadatech (např. Id místo ID, KodMj1 místo KodMJ1). Názvy sloupců v datech nyní odpovídají metadatům.

REST API: dokumentace OpenAPI (/doc/system) už nepopisuje hodnoty řádků dat přehledů, snapshotů, sestav a akcí ani hodnoty systémových parametrů jako text. Jsou uvedené jako hodnoty libovolného typu včetně null, takže odpovědi s čísly a logickými hodnotami proti dokumentaci projdou validací a generátory klientů pro ně nevytvářejí řetězce.

Integrace s AVA: podepisované dokumenty uživatele, který má v Heliosu kartu zaměstnance s dalším pracovním poměrem (kopii karty se stejným přihlašovacím jménem), se do AVA nepřenesly, načtení dokumentu skončilo chybou. Opraveno: jako vlastník dokumentu se nyní použije jedna karta zaměstnance, přednostně ta, která už je v AVA, jinak základní karta zaměstnance.

Opraven pád programu při ukončení během startu (např. po zrušení přihlášení) při použití vestavěného prohlížeče Chromium (parametr -icef). Doplněk plgASOLChromium 3.0.2026.1031 používá Chromium 154 a nově je k dispozici i pro 64bitovou verzi.

Dokumenty ze vzoru - chybně zapsané pole se nyní ohlásí přímo při generování. Obsahoval-li vzor pole zapsané ve špatném tvaru, dosud se generování tvářilo jako úspěšné. Na místě takového pole se v dokumentu objevila hláška, ale v přehledu průběhu nic nenaznačovalo, že něco není v pořádku - u delšího vzoru se tak chyba dala snadno přehlédnout a přišlo se na ni až u hotového dokumentu. Nyní se takový vzor v přehledu průběhu označí jako chybný a pod ním se vypíše seznam vadných polí, každé na vlastním řádku.

Autor vzoru tak rovnou vidí, která pole opravit. Samotné generování se tím nezastaví - dokument vznikne jako dosud a ostatní pole se naplní. Změna se projeví i v souhrnu: vzor s chybně zapsaným polem se nově započítá mezi chybné záznamy, zatímco dřív procházel jako bezchybný.

Opraveno podepisování elektronických podání pro Finanční správu (DPH, souhrnné a kontrolní hlášení, DzPPO) certifikátem s klíčem EC – podpis nyní používá SHA-256 a podepsané atributy a EPO ho přijme (dříve chyba ověření podpisu, kód 114).

Opravena chyba „Duplicates not allowed“, kvůli které se neotevřel editor, pokud definice statických polí obsahovala systémové názvy lišící se jen velikostí písmen. Definice statických polí nově takové názvy nedovolí uložit.

HELIOS API: Opravena chyba SQL při stránkovaném čtení přehledu (parametr skip) nad sestavou s pevně nastaveným TOP, pokud byl přehled řazen podle počítaného (definovaného) sloupce.

Opraveno zjišťování změny hodnoty binárních údajů (např. dokumentů a obrázků) při ukládání záznamu v editorech i přes REST API. Při prázdném binárním údaji mohlo uložení skončit chybou a v některých případech se údaj považoval za změněný, i když změněný nebyl.

Opraveno: pokud HELIOS při odhlašování nebo vypínání Windows neměl spojení s databází (např. po výpadku SQL serveru), zobrazil dotaz na ukončení programu a dokud uživatel neodpověděl Ano, vypnutí Windows blokoval. Program se nyní při ukončování Windows ukončí bez dotazu.

Opravena sumace v přehledech seskupená podle více sloupců: pokud měl některý záznam v grupovacích sloupcích prázdnou hodnotu, sumace mohla skončit chybou „Duplicates not allowed“ nebo započítat hodnoty do jiné skupiny.

REST API: Nový parametr CommandTimeout v sekci [Kernel] souboru HELIOS.INI omezuje dobu SQL dotazu v sekundách (výchozí 0 = bez omezení). Dotaz, který limit překročí, vrátí chybu 504 „Vypršel časový limit dotazu“. Po výpadku sítě, kdy spojení se SQL serverem zůstane v nepoužitelném stavu (chyba „Object was open…“), vrací API chybu 500 ConnectionLost#999 a HELIOS Dispatcher (Inuvio Server) jádro nahradí novým; dříve mohlo API dlouhodobě vracet chybu 400.

Odpověď 429 při zaneprázdněném jádře nově obsahuje odkaz na RFC 6585.

REST API: Po ztrátě spojení se SQL serverem (výpadek sítě nebo SQL serveru) vrací API na tento i všechny další požadavky chybu 500 s kódem ConnectionLost#999 a textem „Spojení se SQL-serverem bylo přerušeno. Příčinou může být výpadek sítě nebo SQL-serveru.“ Dříve mohlo API po krátkém výpadku dlouhodobě vracet chybu 400 „Object was open…“. HELIOS Dispatcher (Inuvio Server) takové jádro ukončí a další požadavek obslouží nové jádro s novým spojením.

REST API: Opraveno načítání změněných záznamů parametrem rowVersion (browses/data, browses/snapshot) u přehledů s externími atributy. Dříve se vrátily jen záznamy s vyplněnými externími atributy změněné zároveň v hlavní tabulce i v externích atributech; nově se vrátí každý záznam změněný v kterékoli z nich. Hodnota rowVersionMax v odpovědi nově zahrnuje i změny externích atributů.

REST API – položky dokladů obchodního zboží: blokované umístění na příjemce či výdejce už zápis položky neodmítne, položka se uloží a API vrátí varování, stejně jako editor. Novou položku nelze přes API založit na realizovaném dokladu (u vydané objednávky a expedičního příkazu také na schváleném či splněném) ani na dokladu, ze kterého už byl vytvořen převod – editor dokladu to také neumožňuje.

REST API – položky vydané objednávky: založí-li se položka bez zadaného množství a výchozí množství karty je nižší než minimální množství dodavatele, množství se nyní zvýší na minimum (včetně zaokrouhlení na balení) a API vrátí varování, stejně jako editor po potvrzení navýšení. Dříve se zápis odmítl. Kontrola minima navíc už falešně neodmítne množství, které se od minima liší jen zaokrouhlením při převodu měrných jednotek.

REST API – položky dokladů obchodního zboží: chybové kódy jsou nyní jednoznačné – nesprávná výše zádržného vrací Validation#022 (dříve Validation#015, který zůstává zakázané slevě) a neexistující skladová karta při založení položky RecordNotFound#702 (dříve RecordNotFound#701). Omezení slevy na 999 % se kontroluje u všech slev položky, nejen u slevy zadané v požadavku, stejně jako v editoru položky.

REST API – položky dokladů obchodního zboží: po zadání sazby spotřební daně se nyní doplní údaje o spotřební dani položky z kmenové karty, zadáním daňového klíče bez sazby DPH se sazba doplní podle klíče a zadáním vozidla na přijaté faktuře či dobropisu se dotáhne poměrný koeficient – stejně jako v editoru položky.

REST API – položky dokladů obchodního zboží: umístění, kód pro přenesenou daňovou povinnost, akce a čárový kód zadané přes API se nyní kontrolují stejně jako výběr v editoru položky: umístění musí patřit ke skladové kartě položky, kód PDP k zemi DPH dokladu a být platný k datu zdanitelného plnění, akce musí být akcí skladové karty a čárový kód musí patřit tomuto zboží. Ceníkovou akci dotaženou z ceníku již nelze přes API změnit.

REST API – položky dokladů obchodního zboží: splněnou položku vydané objednávky a expedičního příkazu již nelze přes API upravovat a na zaúčtovaném dokladu nelze měnit účet zálohy pro základ. Položku nelze přes API smazat, je-li převedená, je-li doklad zdrojem převodu nebo je realizovaný; u vydané objednávky a expedičního příkazu také je-li schválený či splněný. Chování odpovídá editorům dokladu a položky.

REST API – položky dokladů obchodního zboží: při změně množství na stornu výdejky nebo příjemky se celková požadovaná evidenční cena již nenuluje, ale přepočítá se poměrem k množství, takže storno výdejky lze následně realizovat. Množství, měrnou jednotku a hmotnost již nelze přes API měnit u převedené položky, u zaúčtovaného či realizovaného dokladu a u dokladu, který je zdrojem převodu; u zboží s evidenční cenou dle výrobních čísel nelze na položce zadat požadovanou evidenční cenu.

Chování odpovídá editoru položky. Realizace storna výdejky: chybová hláška o nulové požadované evidenční ceně na výrobním čísle nyní uvádí správnou položku.

REST API – položky vydané objednávky a expedičního příkazu: u schváleného nebo splněného dokladu již nelze přes API měnit množství, měrnou jednotku, ceny, sazby DPH, slevy ani umístění položek; chování odpovídá editoru dokladu. Změna příznaku Splněno v jednom požadavku s hlavičkou úpravu položek uvolní. Chybová hláška o minimálním množství dodavatele nově uvádí požadované množství včetně zaokrouhlení na násobek balení.

REST API – položky dokladu obchodního zboží: kontrola zadaného daňového klíče nyní správně zohledňuje, zda jde o vstupní, nebo výstupní doklad. Dříve mohlo API u položek v režimu samovyměření nebo přenesené daňové povinnosti odmítnout platný daňový klíč, případně přijmout klíč, který k sazbě DPH nepatří.

REST API: Při založení dokladu oběhu zboží s organizací (zadanou přímo nebo dotaženou ze zakázky či kontaktní osoby) se nově dotáhnou údaje z organizace stejně jako v editoru – měna a kurz, místo určení, příjemce, kontaktní osoba, forma dopravy a DIČ DPH; hodnoty zadané v požadavku se nepřepisují.

REST API: Parametr filter přehledů nově odmítá komentáře, středník, neukončené řetězce, nevyvážené závorky a výraz končící na AND, OR nebo NOT (chyba 400, kódy BadFilter#004 až BadFilter#007). Takto zadaným filtrem bylo možné získat i řádky, ke kterým uživatel nemá právo.

REST API: Při opravě dokladu oběhu zboží se po změně organizace nově přepočítají navázané údaje (DIČ DPH, místo určení, příjemce, měna a kurz, forma úhrady, splatnost, forma dopravy, kontaktní osoba, tiskový formulář) stejně jako v editoru; hodnoty zadané v požadavku se nepřepisují. Měna se po změně organizace mění jen za stejných podmínek jako v editoru.

REST API: Vnitřní úprava zpracování režimu kurzu DPH pro faktury při zakládání dokladu oběhu zboží – hodnota se použije až po kontrole platnosti. Chování API se nemění.

REST API: Chyby dokladu oběhu zboží mají jedinečné kódy. Pokus nastavit doklad současně jako realizační i zálohovou fakturu vrací nově kód BadValue#863 (dříve BadValue#850, který zůstává nepovolenému režimu OSS). Chybějící právo na akci Aktualizace cen podle cenotvorby vrací nově NoRights#103 (dříve NoRights#102).

REST API: Doklady oběhu zboží vracejí v odpovědi varování (warnings) ve stejných situacích, ve kterých se editor dokladu ptá nebo upozorňuje: nevyplněná dimenze se zadáváním „Upozornění“ na řadě, rozdíl DUZP a data vystavení vydané faktury nad nastavený limit, nepřiřazená zaplacená záloha k realizační faktuře, duplicitní druhý párovací znak a příliš dlouhé evidenční číslo daňového dokladu na Slovensku. Doklad se uloží jako dosud.

REST API: Doklady oběhu zboží nově kontrolují zajištění DPH stejně jako editor dokladu – doklad nelze uložit pro nespolehlivého plátce, organizaci s jiným důvodem ručení nebo slovenského plátce DPH ke zrušení ani s nezveřejněným bankovním účtem nad limitem úplaty (pokud je kontrola zapnutá na řadě dokladu). Kontroluje se podle údajů uložených v databázi, bez online ověření. Úpravu cen (slevu) na hlavičce lze zadat jen v rozsahu −100 až 100 %.

REST API: Při založení faktury nebo dobropisu s organizací a při prvním doplnění organizace do dokladu se z organizace dotáhne účet zálohy pro základ daně a u zálohové faktury i účet zálohy, stejně jako v editoru dokladu. Účty zadané v požadavku mají přednost.

REST API: Při zakládání dokladu oběhu zboží s režimem OSS se země DPH určí podle místa určení nebo organizace, stejně jako v editoru dokladu. Nelze-li zemi určit (doklad bez organizace a místa určení), musí ji požadavek obsahovat – API jinak vrátí chybu, že země DPH není zadána.

REST API: Datum doručení lze u vydané faktury zadat jen u opravného daňového dokladu, když řada dokladů potvrzuje doručení a země DPH je CZ – stejně jako v editoru dokladu.

REST API: Na zaúčtovaném dokladu oběhu zboží už nelze měnit účet zálohy, účet zálohy pro základ daně, druhý párovací znak ani poměrný koeficient DPH, stejně jako v editoru dokladu.

REST API: Na realizovaném dokladu oběhu zboží už nelze měnit údaje e-faktury (příznak e-faktury, text e-faktury a typ dokladu e-faktury), stejně jako v editoru dokladu.

REST API: Je-li na řadě dokladů zadávání zaměstnance zakázané, API zaměstnance podle fakturačního zaměstnance doplní a doklad uloží s varováním (stejně jako editor, který se zeptá). Zaměstnance zadaného v požadavku už neodmítne, ale vrátí varování.

REST API: Při zakládání dokladu oběhu zboží se zadaným plněním DPH se sazba DPH a daňový režim hlavičky nastaví podle plnění stejně jako v editoru dokladu (osvobozené plnění bez sazby a režimu, plnění s nulovou sazbou se sazbou 0). Sazbu DPH, která plnění odporuje, API odmítne.

REST API: Při zadání fakturačního zaměstnance na dokladu oběhu zboží se zaměstnanec v účetních vazbách doplní ještě před kontrolou povinnosti podle řady dokladů, takže uložení už nekončí chybou „Zaměstnanec je povinný“.

REST API: Při zakládání dokladu oběhu zboží se povolení zadaného režimu OSS kontroluje nad hodnotami z požadavku (datum uskutečnění zdanitelného plnění, organizace), ne nad přednastavenými hodnotami řady.

REST API: Při uložení vydané faktury nebo dobropisu s režimem OSS, jehož konečný příjemce je plátcem DPH v zemi DPH dokladu, vrací API varování – stejně jako se editor dokladu ptá, zda doklad uložit. Doklad se uloží. Dosud se tato kontrola na API neprováděla.

REST API: U schválené a dosud nesplněné vydané objednávky a expedičního příkazu lze přes API měnit datum splnění, termín dodávky a příznak Splněno, stejně jako v editoru dokladu. Dosud API tyto změny odmítalo.

Opraveno chybné zařazení přehledů do skupin tiskových formulářů. Sedm přehledů nabízelo při tisku formuláře patřící jinému přehledu: Kategorie organizace, Variabilní symboly, Kurzy mzdových měn, Vstupní doklady dodatečných souvisejících nákladů, Obaly, Významné opravy a Filtrace tabulek. Každý z nich má nyní vlastní skupinu formulářů. Pozor: formuláře, které si uživatel u těchto přehledů dříve definoval nebo viděl, jsou nadále ve své původní skupině, tedy u původního přehledu.

Pokud mají platit i pro tyto přehledy, je třeba je přiřadit do nové skupiny.

Opravena chyba, která mohla v uživatelských editorech s obrázkovým infopolíčkem nebo statickým políčkem způsobit chybu Access Violation, např. při opakované aplikaci definice editoru nebo při vypnutí či změně infopolíček a statických políček.

Dokumenty ze vzoru - hodnoty se nyní doplní na všech stránkách dokumentu. Při generování dokumentu ze vzoru se u delších vzorů vyplnila jen pole v úvodní části dokumentu a pole na dalších stránkách zůstala prázdná. Výsledek se navíc mezi jednotlivými spuštěními lišil, takže opakované generování téhož vzoru mohlo poprvé dopadnout dobře a podruhé ne. Obejít to šlo jedině zkrácením vzoru na jednu stránku. Nyní se doplní všechna pole bez ohledu na délku vzoru a výsledek je při každém spuštění stejný.

Stejná závada se projevovala u atributů typu obrázek, kdy se obrázek vložil jen v úvodní části dokumentu. I to je opraveno.

Editor otevřený v režimu jen pro čtení nyní zašedne všechna pole i tehdy, když se tento režim nastaví až při načtení záznamu. Týká se to uživatelských tabulek s nastavením akce Oprava na hodnotu Editor RO nebo Podle nadeditoru, otevření záznamu zablokovaného jinou instancí aplikace, editace externích informací a také obslužného pluginu aktivního editoru, který nastavuje vlastnost KompletniReadOnly v proceduře OpenAllQueries. Dosud v těchto případech pole zůstávala na pohled editovatelná, i když do nich zapsat nešlo.

Poznámka pro autory pluginů: vlastnost KompletniReadOnly nadále platí pouze jedním směrem — jakmile je editor přepnut do režimu jen pro čtení, nelze ho zpět zpřístupnit k editaci.

V editoru s vnořeným přehledem mohlo po stisku tlačítka Storno dojít k chybovým hláškám a následně k chybě Access Violation Error, pokud byl předtím v info panelu na záložce Detail posunutý posuvník. Opraveno.

Opravena chyba, kdy nebylo možné přes REST API (HELIOS API) načíst data z přehledu Uživatelé, pokud se použilo výchozí nastavení sloupců přehledu (parametr defaultData). Přehled Uživatelé je nyní přes API dostupný pro čtení.

Opravena chyba „A component named … already exists“, která se mohla objevit v uživatelském editoru s infopolíčky nebo statickými políčky při aplikaci definice editoru. Rušení a opětovné vytvoření políček je nyní odolné vůči chybě jednotlivého prvku.

Opravena chyba při tisku dokladu do souboru nebo odeslání e-mailem, které vyvolá doplněk (plugin) nad přehledem s ručně vybranými více obdobími. Pokud doklad nepatřil do hlavního období, tisk skončil chybou a uživatelská procedura před tiskem formuláře nedostala identifikaci dokladu. Doklady z vedlejších období se nyní vytisknou stejně jako doklady z hlavního období. Nemá-li tisk do souboru k dispozici žádný záznam, ze kterého by sestavil název souboru, zobrazí se místo chyby databáze hláška „Přehled neobsahuje žádné záznamy.“.

Tiskové sestavy a formuláře: opravena chyba, kdy se tisk nebo náhled formuláře se stránkovým zlomem nedokončil a program místo toho napočítával desítky tisíc stran. Chyba nastávala, když byl stránkový zlom umístěn na nově vytvořené (stránkové) vrstvě místo na vrstvě Foreground.

Akce Zaměstnej uchazeče – přednastavené kontakty Po použití akce Zaměstnej uchazeče se nově všechny kontakty automaticky označí jako Přednastavené .

Personální organizační struktura - foto Personální organizační struktura zobrazí fotky zaměstnanců ve všech formátech, které jde nahrát v číselníku Zaměstnanci (BMP, GIF, JPEG, PNG, WEBP, SVG, TIFF, JPEG2000).

ÚPRAVA - Akcia Zamestnaj uchádzača - prednastavené kontakty Po použití akcie Zamestnaj uchádzača sa odteraz všetky kontakty označia ako Prednastavené.

NOVINKA - Personálna organizačná štruktúra - formáty fotiek Doteraz bolo možné v Personálnej organizačnej štruktúre zobrazovať fotografie zamestnancov, len ak mali príponu *.jpg/*.jpeg. Zobrazenie bolo rozšírené o prípony povolené v karte zamestnanca.

Upraveno dohledávání daňového režimu na hlavičce pokladního dokladu. Pokud pro přednastavený typ dokladu nebyl na řadě pokladních dokladů navázán daňový režim, pak změna typu pokladního dokladu na opačný typ (pro který existuje navázaný daňový režim), daňový režim nedoplnila. Opraveno.

Pokladní doklad, na kterém je zadaná jen záloha (záložka Zálohy, „Zúčt. zálohy přijaté“), se chybně vyhodnocoval jako nulový a při zaúčtování hlásil „Účetní doklad neobsahuje řádky“. Nyní jde zaúčtovat a ve sloupci „Nulový doklad“ se už neoznačuje.

V souvislosti se implementací legislativy EET 2.0 byly upraveny tyto distribuční tiskové formuláře v účtenkách pokladního prodeje: -64 Doklad -63 Účtenka 108 mm -60 Účtenka 60 mm -61 Účtenka 70 mm -62 Účtenka 80 mm v pokladních dokladech: -1537 Pokladní doklad s kontací CM -1536 Pokladní doklad CM -1450 Pokladní doklad STVRZENKA -1449 Pokladní doklad s kontací -1448 Pokladní doklad v úhradách faktur: -1303 Úhrada faktury vydané.

Pokladní prodej: nová evidence pokladních zařízení pro mobilní pokladnu. Správce v ní povoluje zařízení, přiřazuje řadu účtenek a nastavuje vyžadování podpisu zákazníka a tiskovou šablonu účtenky. Mobilní pokladna nepotřebuje certifikát EET nastavený v Heliosu.

Strom projektu a strom vzorového projektu: uživatelské sloupce teď zobrazují přeložený veřejný název v jazyce uživatele a používají konverzi zadanou u sloupce, včetně přeložené konverze a konverze definované SQL skriptem.

Projektové řízení: opraveny chybné a nejednotné anglické, německé a slovenské překlady hlášek a překlep v hlášce o právu zápisu pro řadu projektů.

Ganttův diagram V3: podpora uživatelského obarvování projektů, etap a úloh.

Vzory projektů: u závislosti úloh ve vzoru lze zadat prodlevu, tedy čekání nebo předstih v pracovních dnech. Prodleva se přenese při založení projektu nebo úlohy ze vzoru. Při převodu projektu do vzoru se nově přenášejí i závislosti úloh, včetně typu vazby a prodlevy.

Akce Ganttův diagram V3 (dříve Ganttův diagram V2) otevírá nový, rychlejší Ganttův diagram projektů a etap. Gantt V1 zůstává beze změny.

Závislost úloh má nové pole Prodleva (ve dnech). Kladná hodnota znamená čekání následníka, záporná předstih, kdy se úlohy překrývají. Prodleva se zadává v tabulce závislostí i v editoru a přepočet závislostí ji zohledňuje; zároveň byl opraven nesprávný výpočet termínů.

Strom projektů a vzorů projektů má nově ribbon s akcemi.

Definici editoru (projekt/etapa a úloha) lze nově nastavit na řadě projektů.

Aktualizace skutečných výrobních nákladů úlohy nově započítává i náklady podřízených výrobních příkazů. U víceúrovňové výroby se tak skutečné náklady úlohy zobrazují průběžně už během výroby polotovarů, ne až po jejich výdeji do vrcholového příkazu.

Přehled rozpracovanosti: nová akce Zrušit odvedení do úbytku. Smaže označené řádky s druhem pohybu 66 (odvedení do úbytku), které ještě nejsou zaúčtované, a zobrazí přehled provedených změn s důvodem, proč se případně některý řádek smazat nepodařilo.

Nový grafický přehled zdrojů (V2) pro personální i nepersonální zdroje. Ukazuje práci zdrojů v čase seskupenou podle profesí (skupin) nebo jen podle zdrojů, včetně práce zadané jen na profesi a denní vytížení proti kapacitě z plánovacího kalendáře.

Při výběru archivního nepersonálního zdroje se nově zobrazí upozornění s dotazem, zda ho přesto vybrat.

Strom projektů se načítá rychleji a zvládá i stovky projektů a úloh.

Při založení projektu, etapy nebo úlohy ze vzoru se termíny úloh doplní podle závislostí: úloha začne až po svém předchůdci podle typu vazby a prodlevy, konec se dopočítá z počtu dní ze vzoru. Etapy a projekt založené ze vzoru začínají první a končí poslední svou úlohou. U úloh, které mají předchůdce, se na datum nedotazuje. Ve vzorech se délka trvání nově jmenuje Dny do ukončení.

Změna uzavřeno na úloze uzavře/otevře i podřízené zdroje.

Dodatečné související náklady (DSN), které zatíží výdejku materiálového zdroje, se nově promítnou do rozpracovanosti projektu i do skutečných nákladů úlohy a výkazu materiálu. Změna ceny u již fakturovaného množství se odvede automaticky.

Kontrolní plány – opravena chyba access violation v editoru parametrů kontrolního plánu po zadání požadované hodnoty nebo tolerancí.

Akce Generuj reklamaci vydanou v přehledech Evidence kooperací a Rozpis kusů evidence kooperací generovala interní neshodu místo reklamace vydané, pokud byla v QMS definována jen jedna kategorie interních neshod. Opraveno, akce teď vždy zakládá reklamaci vydanou v kategorii reklamací vydaných. Není-li na řádku žádné nepoužité množství, akce nyní hlásí „Reklamace nebyla vygenerována, není žádné nepoužité množství.“ místo matoucí hlášky o interní neshodě.

Analýza FMEA – v editoru “Verze FMEA” je v přehledu “Analyzované procesy FMEA” nová akce “Nahrát procesy z jiné verze”. Akce je k dispozici, jen když je verze ve stavu “Zpracovává se”. Po spuštění akce se nabídnou verze všech analýz FMEA kromě aktuální verze. Z vybrané verze se nabídnou její procesy, z nichž je třeba označit ty, které se mají přenést, a na dotaz se zvolí, zda se má zkopírovat i vyhodnocení vad a příčin (Význam, Výskyt, Detekce, Priorita opatření).

Procesy se zkopírují na konec přehledu včetně vad a příčin vad a vazeb na úkoly a opatření. Vyhodnocení se přenese, jen když má zdrojová i cílová verze stejné číselníky pro hodnocení FMEA. Pokud je cílová verze nemá nastavené, nabídne se jejich převzetí ze zdrojové verze. Pokud se číselníky liší, nabídne se zkopírování procesů bez vyhodnocení. Vazby na operace výroby a kontroly se přenesou, jen když mají zdrojová i cílová analýza FMEA přiřazenu stejnou kmenovou kartu.

Reklamace přijaté - v akci Náklady na opravu byl parametrizován standardní výpočet ze skutečných nákladů evidovaných na výrobním plánu na opravu přiřazeném k dané reklamaci. Výpočet se řídí parametrem “Výpočet nákladů na reklamaci” v nastavení Parametry QMS na záložce Reklamace - Reklamace přijaté. Lze zvolit z těchto možností: Z přímých nákladů výrobních příkazů výrobního plánu na opravu (výchozí nastavení - odpovídá původní verzi výpočtu před parametrizací) - jde o poměrnou část součtu celkových přímých nákladů z výrobních příkazů z daného výrobního plánu Z celkových nákladů řídicího příkazu výrobního plánu na opravu - jde o poměrnou část celkových nákladů na řídicích příkazech z daného výrobního plánu Dotázat se na začátku akce - po spuštění akce si může vybrat jednu z výše uvedených možností (výběr se dále pamatuje na uživatele) Výpočet lze podle potřeby externě upravit aplikací nové slepé procedury ep_VypocitejNakladyReklamaceNew (volá se přednostně před první variantou ep_VypocitejNakladyReklamace), která poskytne dle výše uvedeného principu spočtené dílčí hodnoty skutečných celkových, přímých a nepřímých nákladů zahrnutých do Nákladů na opravy (z výrobních příkazů ve složkách kalkulačního vzorce), což umožňuje např.

jednotlivé složky upravit a z upravených hodnot vypočítat a vrátit novou hodnotu pro Náklady na opravu.

Při změně kontroly výrobních čísel (VČ) na kmenové nebo skladové kartě se nyní kontroluje, zda stav skladu odpovídá stavům VČ. Dříve mohla nepovedená změna zanechat skladovou kartu v nekonzistentním stavu, ze kterého pak nešlo vydávat, nebo převést kartu do evidenčních cen dle VČ i se zásobou bez VČ. Pokud se finanční stav skladu liší od součtu finančních stavů VČ, rozpočítá se automaticky na jednotlivá VČ podle množství. Pokud množství na skladové kartě neodpovídá součtu množství VČ, některé VČ má záporné množství, karta má nulové množství a nenulový finanční stav nebo je na ní nastaveno přeskočení výpočtu skladových příjmů, změna kontroly VČ se neprovede a zobrazí se hláška se skladovou kartou a příčinou.

Stejně se neprovede ani změna druhu skladu (FIFO / průměry) na kmenové kartě, pokud výpočet skladových příjmů skončí chybou.

Opravena realizace dokladu DSN, která za určitých okolností skončila nesrozumitelnou chybou „Dělení nulou“. Nastávalo to, když měly všechny výdeje zboží z příjemky zatížené dokladem DSN nulovou evidenční cenu (u skladové karty s evidenční cenou dle VČ výdeje daného VČ), takže mezi ně nebylo možné rozpočítat dodatečné související náklady. Realizace dokladu DSN nyní v takovém případě skončí srozumitelnou hláškou, která uvádí doklad DSN, příjemku, skladovou kartu, VČ a seznam výdejů s nulovou evidenční cenou (druh pohybu, řada a pořadové číslo dokladu).

Na řadě výrobních příkazů, na záložce Evidence operací / Zmetky, je nová volba Kontrolovat cenu příjemky zmetku při realizaci. Ve výchozím stavu je vypnutá. Když volbu zapnete, příjemku zmetku na sklad neshod nepůjde realizovat, pokud se cena na její položce liší o více než 0,10 Kč od aktuální ceny zmetku z evidence operací. To se stává hlavně tehdy, když se náklady zmetku po vygenerování příjemky změnily. Helios následně zobrazí hlášku s číslem příkazu, záznamem evidence operací a položkou.

Cenu na položce srovnáte pomocí funkce Aktualizace ceny a příjemku pak zrealizujete. Kontrola zajistí, že na sklad neshod přijde zmetek ve stejné ceně, jakou má ve výrobě.

Při importu ceníku ze schránky (prodejní ceny do cenových úrovní) jsme, při použití ID kmenové karty jako identifikátoru, provedli optimalizaci rychlosti importu.

Při uložení dokladu DSN správně zobrazené datum skladové uzávěrky - kontrola, že datum případu dokladu DSN nesmí ležet v uzavřeném období skladové uzávěrky. Pokud už ale doklad DSN existuje, stejná kontrola při realizaci nezobrazila datum vůbec… Opraveno.

Nad přehled 76 Přehled pohybů výrobních čísel (aktivuje se akcí F9 nad přehledem 74 Přehled položek) bylo doplněno právo na akci "Vč/šarže k prověření".

Ve výrobních přehledech z kmenových karet: Vyráběné dílce, Nakupované materiály, Nářadí a Vedlejší produkty nebylo možné v akci Návazné skupiny přiřadit kartě akcí Nový záznam návaznou skupinu karet. Opraveno.

Při zadávání hodnoty sumační slevy v editoru Sumace a sumační slevy na hlavičce došlé objednávky se od verze 3.0.2026.0900 systematicky objevovala chyba Access violation. Opraveno.

Doklady oběhu zboží – rychlá změna množství na stornu výdejky a na příjemce převodky Při změně množství v poli pro rychlé zadání množství pod seznamem položek (bez otevření editoru položky) se celková požadovaná evidenční cena (CC evid. požadovaná) nově přepočte poměrem podle nového množství, stejně jako v editoru položky. Dosud se nulovala a doklad nešlo zrealizovat, dokud uživatel cenu znovu ručně nezadal. Pokud bylo původní množství na položce nulové, cenu stanovit nelze a nadále se vynuluje.

Doklady oběhu zboží – změna měrné jednotky v editoru položky a CC evid. požadovaná Změna měrné jednotky v editoru položky přepočte množství tak, aby zůstalo zachováno množství v evidenční MJ (např. 20 ks → 1 basa). Celková požadovaná evidenční cena (CC evid. požadovaná) se nově při změně MJ nemění. Dosud se chybně přepočetla podle číselné změny množství a chybně pak vycházely i další změny množství na položce. Týká se zejména storen výdejek a cílových příjemek meziskladových převodek.

Realizace dokladu DSN nezafungovala v případech opakovaného použití (2x, 3x atd.) funkce Zruš storno a původní doklad. Mohl tak vzniknout realizovaný, nekonzistentní doklad DSN. Opraveno.

Realizace dokladu DSN při metodě stanovení evidenční ceny samostatně pro jednotlivá VČ nově rozpustí související náklady i na výdejky bez výrobních čísel; pokud náklad nelze rozpustit do žádného výdeje ani zapsat na skladovou kartu s nulovým stavem, realizace skončí chybou a nevznikne nekonzistentní doklad DSN.

NZB - V akci Generování zajištění materiálových požadavků z výroby a materiálových zdrojů pro projekty vydanou objednávkou byla pro případ pokrytí existující vydanou objednávkou vyžadována shoda měny a dodavatele. Tato shoda se nově nevyžaduje (toto chování nelze uživatelsky změnit, pro stejnou akci v došlých objednávkách jsou na to parametry na řadě došlé objednávky).

Byla opravena funkcionalita opakovaných plateb. Pole poslední den měsíce je nově přístupné vždy. Nastavení Poslední den měsíce se uplatní se pouze v případě, že Datum následující splátky, pokud nezadáno, tak Datum pohybu na posledním pohybu, je 28.2. (u přestupného roku 29.2.), 30.4., 30.6., 30.9. nebo 30.11. Když nebude pole Poslední den měsíce zaškrtnuto, budou nově generované pohyby držet číslo dne v měsíci. Např. pro 30.4. → 30.5., 30.6., 30.7., atd.

Když bude pole Poslední den měsíce zaškrtnuto, budou mít nově generované pohyby datum posledního dne v měsíci. Např. pro 30.4. → 31.5., 30.6., 31.7., atd.

Import daňových klíčů a daňových režimů v přehledu daňového režimu už nepřepisuje poznámky, které si k nim uživatel zapsal. Poznámka z distribuce se vloží jen do prázdné poznámky. Pokud poznámka uživatele text z distribuce ještě neobsahuje, připojí se na nový řádek za něj. Je-li poznámka v distribuci prázdná, poznámka uživatele se nemění.

Aby bylo zřejmé, že se jedná o limit pro slovenské DPH a v jaké měně je tento limit uveden, v editoru Globálních konstant, Účetnictví, Účetnictví - další byl původní název pole Limit pro povinný režim PDP upraven na: Limit pro povinný režim PDP - SK DPH (EUR).

Byl upraven text účetního dokladu pro účtování “Zrušení kurzového rozdílu k bilančnímu dni”, a to jak při účtování z úhrad ve fakturaci, tak při účtování ze saldokonta. Nově je text účetního dokladu rozšířen o slovo “STORNO”.

Byl upraven vzhled editoru Organizace, záložka 6 - Účtování: Název pole “Účet zálohy přijaté:” je doplněn na “Účet zálohy přijaté (FV):” Název pole “Účet zálohy vydané:” je doplněn na “Účet zálohy vydané (FP):” Pole “Účet zálohy základu (FV):” a “Účet zálohy základu (FP):” jsou v editoru vyměněny. “Účet zálohy základu (FV):” nahoře, “Účet zálohy základu (FP):” dole.

Ve Vzájemných zápočtech (saldokonta) se při Nový nebo Oprava na záložce 2 – Zápočty již neukazuje dotaz „Došlo ke změně hodnot na hlavičce zápočtu… Pokračovat?“. Hlavička se uloží automaticky bez hlášky. Týká se nového zápočtu i opravy existujícího, když se na hlavičce změní některý z údajů.

Saldokonta - Účtování → Dorovnání .. Pokud účet Vyrovnání zisk/ Vyrovnání ztráta není vyplněn na řádku kontace, pak se jej systém pokusí dohledat v globální konfiguraci v nastavení pro modul Účetnictví, záložka Účetnictví - další. Pro řádek kontace Vyrovnání zisk použije účetní účet nastavený v atributu Číslo účtu zaokrouhlení - výnos. Pro řádek kontace Vyrovnání ztráta použije účetní účet nastavený v atributu Číslo účtu zaokrouhlení - náklad.

Účetnictví – import deníku: po převodu importu s externími sloupci (dokončení převodu s prázdnou importní tabulkou) se nově promaže i struktura externích sloupců. Další převod importu deníku naplněného jinou cestou (např. externím nebo distribučním řešením) už nekončí chybou „Invalid column name“.

Do přehledu “Druhy účetních dokladů” jsou doplněny nové sloupce: ”Počet dokladů” - zobrazí počet účetních dokladů v dané řadě v daném roce (počet dokladů, nikoli počet řádků dokladů). ”První doklad” - zobrazí minimální číslo účetního dokladu v dané řadě v daném roce ”Poslední doklad” - zobrazí maximální číslo účetního dokladu v dané řadě v daném roce.

Upraven algoritmus účtování položek záloh v rámci účtování faktur. Řádky účetního kódu, které mají nastaven jiný daňový klíč než je na položkách záloh, se neuplatňují. Platí jen při účtování s použitím daňových klíčů.

Do podmínky vyhodnocení, že se jedná o nulový doklad , je doplněno: “a zároveň neexistují přiřazené zálohové faktury na kterých je částka zálohy (TabZalFak.Castka) je nenulová.” Jinými slovy, a zároveň neexistuje navázaná záloha. Poznámka: Týká se i záloh navázaných akcí Nový bez vazby).

Upraven algoritmus účtování faktur se zálohami v přípravném režimu daňových klíčů v případě, je jsou v účetním kódu řádky se zadaným daňovým klíčem i řádky bez daňového klíče a příslušné období DPH je v režimu daňových klíčů. Daňové klíče jsou zapsány do účetního dokladu.

Byla opravena chyba při hromadném generování upomínek (k jednomu odběrateli), kdy se generovaly detaily upomínky pouze j jediné.

Od verze 3.0.2026.0901 se pro vystavení upomínek automatem bral z konfigurace atribut Penalizovat po splatnosti (dny) místo Upomínat po splatnosti (dny). Opraveno.

Účetnictví, akce Vystavení upomínek. Od verze 3.0.2026.0901 se při ručním vystavení upomínek a úroků z prodlení nebral počet Dnů tolerance nastavený u stupňů upomínek. Místo něj se použil počet dní z globálních konstant nebo z organizace, které platí jen pro automatické vystavování. Upomínka se proto mohla vystavit dříve, než měla, nebo vůbec. Opraveno. Při ručním vystavení se tolerance opět bere z textu penalizace přiřazeného organizaci, jinak ze stupně upomínky.

Automatické vystavování upomínek se nemění.

Bylo opraveno chování pole - zaškrtávátka - “KH do limitu”. Toto zaškrtávátko se na editoru faktury, záložka 1 - Hlavička nachází napravo od pole “Nastavení pro limit KH”. Ve speciálních případech (externí importy faktur) mohlo být pole “KH do limitu” označeno nesprávně.

V editoru faktur se po výběru organizace na hlavičce dokladu aktualizovalo pouze pole "Účet zálohy základu" podle organizace. Pole "Účet zálohy" se nezměnilo a zůstává naplněné z účtu zálohy nastaveného na řadě faktury, nikoli z organizace. Opraveno, po výběru organizace na hlavičce dokladu v řadě zálohy se "Účet zálohy" plní z analogického zdroje (organizace) jako "Účet zálohy základu". Tedy: Faktura / dobropis přijatá: z pole “Účet zálohy vydané” Faktura / dobropis vydaná: z pole “Účet zálohy přijaté”.

Byla opravena chyba, která se projevovala takto: Pokud byla vytvořena pouze účetní opravná položka (ovšem nikoli na 100%) a později vytvořena opravná položka podle §8 – Opravné položky k pohledávkám za dlužníky v insolvenčním řízení, účetní opravná položka se vytvořila chybně na zrušení ve výši 100%, místo toho, aby se zrušila ve výši původního %.

Evidencia DPH - Kontrolný výkaz DPH SK – oprava generovania XML súboru: Od verzie 3.0.2026.0911 sa pri generovaní XML súboru z Kontrolného výkazu DPH SK ( Generovanie správ – KV DPH ) zapisoval k elementom Identifikacia a Transakcie prázdny menný priestor xmlns="". Elementy tým vypadli z menného priestoru schémy Finančnej správy SR, takže XML súbor neprešiel validáciou voči XSD a nedal sa načítať do formulára na portáli FS SR. Doteraz ste museli xmlns="" z oboch elementov odstraňovať manuálne.

Po oprave sa všetky elementy XML súboru generujú v mennom priestore koreňového elementu (napr. KVDPH_2025 ) bez xmlns="". XML súbor je validný a na portáli FS SR sa načíta do formulára správne, do správnych oddielov a riadkov a so správnou diakritikou. Manuálna úprava súboru už nie je potrebná. Oprava platí pre všetky verzie výkazu, od kv_dph_2014 po kv_dph_2025 , teda aj pri generovaní dodatočných a opravných kontrolných výkazov za skoršie obdobia.

Fakturácia - e-Faktúra (SK) a Daňové kľúče DPH na vstupe: e-Faktúra SK – daňové kľúče DPH na vstupe s kódmi DPH pre import XML Peppol BIS 3.0: Na Daňových kľúčoch DPH (DK DPH) na vstupe pre krajinu Slovensko (SK) je teraz prednastavený “ Kód DPH” (podľa číselníka UNCL 5305 pre BT-118, BT-151). DK DPH majú doplnenú aj “ Poznámku” s popisom použitia pre e-Faktúru SK z pohľadu legislatívy. Kód DPH sa prednastavil len na DK DPH, ktoré sa týkajú e-Fakturácie Peppol BIS 3.0 na vstupe tuzemské dodania a aj dodania do EÚ, 3.krajín.

Ostatné daňové kľúče zostávajú bez zmeny. Prevzatie zmeny: Existujúce databázy: pri prechode na novú verziu Helios Inuvio sa Kódy DPH a poznámky na dotknutých daňových kľúčoch nastavia automaticky. Daňové kľúče netreba importovať zo vzorového súboru ani z Helios Store. Ak bol na DK DPH už nastavený Kód DPH, zostane pôvodný (neprepíše sa). Ak si používateľ na DK DPH zadal vlastnú poznámku, tak sa legislatívna poznámka z distribučnej verzie doplní za poznámku užívateľa t.j.

zostane aj pôvodná poznámka. Nové databázy: na prvotné nastavenie DK DPH sú k dispozícii nové vzorové súbory verzie 202604: DANKLICE_202604.TXT a DANKLICE_202604.zip pre Helios Store. Editor DK DPH: Pri slovenských DK DPH so smerom plnenia Vstup alebo Samovymerenie sa polia VATEX kód a Text oslobodenia DPH už nezobrazujú. Odporúčanie: Ak ste si pred prechodom na verziu Kód DPH na niektorých kľúčoch nastavili sami, skontrolujte, či zodpovedá kategórii DPH, ktorú dodávatelia uvádzajú v e-Faktúre SK.

Prechod na verziu ho neopraví. Ak používate vlastné DK DPH na vstupe mimo vzorovej sady, doplňte na nich Kód DPH. Inak import prijatej e-Faktúry nedokáže priradiť daňový kľúč k riadku dokladu.

V přehledech Změnové řízení, Zakázkové modifikace a Odchylkové řízení byl vytvořen nový počítaný sloupec Stav schvalovacího řízení (Pořízeno, Převzato, Schváleno, Neschváleno). Stav schvalování je tak vidět přímo v přehledu, bez nutnosti otevírání detailu Schvalovacího řízení. Stav Schváleno se zobrazí, až po schválení všech úrovní schvalovacího řízení.

Výrobní příkazy – funkce Změna zadaného množství s volbou Přepočítat podřízené výrobní příkazy dosud nepodporovala změnu zadaného množství u výrobních příkazů ve stavu Pořízeno. Nově proběhne přepočet podřízených výrobních příkazů i ve stavu Pořízeno.

Převod výrobních mezd z Evidence výrobních operací do předzpracování mezd Nová externí SQL vsuvka dbo.ep_PrevodMezdDoPredzpracovani1 - umožňuje zkontrolovat připravené záznamy každé převáděné mzdy a vyvoláním chyby záznam z převodu vyřadit.

Aktualizace ceny zmetku na příjemce na sklad Na přehledu Položky pohybových dokladů s vazbou na výrobní příkaz existuje funkce Aktualizace ceny na položce výrobní příjemky. Dosud tato funkce umožnila pouze aktualizaci ceny za shodné (dobré) odváděné kusy. Nově funkce aktualizuje i cenu na příjemce neshodných (zmetkových) kusů.

Sledování opotřebení jednotlivých kusů nářadí podle výrobního čísla Evidence nářadí byla rozšířena o podporu sledování životnosti a počtu užití po výrobních číslech. Byla vytvořena nová tabulka parametrů výrobních čísel nářadí, která je napojená na kmenovou kartu výrobního čísla nářadí. Zobrazuje Typ životnosti, Životnost, Aktuální a Celkové použití, Datum vynulování počítadla. Nad Nářadím je nová akce Výrobní čísla nářadí , kde je možné nové parametry sledovat a pomocí akce Vynulovat počítadlo resetovat atribut Aktuální použití daného nářadí.

V číselníku nářadí byl doplněn nový parametr Vyžadovat VČ (výchozí hodnota je definovaná ve skupině karet). Evidence nářadí je nově rozšířena o možnost zadání konkrétního výr. čísla nářadí. Uložením záznamu dochází k nápočtu Aktualního použití a Celkového použití nářadí.