16.06, Úpravy v této verzi, 13.9.2016
-
V kartě Obsah u bankovního výpisu je nová volba "Vytvořit řádky dle K-schránky" >>>
Typický případ, kdy lze tuto volbu použít, je např.zpracování výpisu s došlou souhrnnou platbou za úhrady vydaných faktur při platbách kartou.
-
Ve výpisu figuruje jeden řádek se souhrnnou platbou za více faktur, obvykle to budou faktury hrazené kartou v některém z minulých dní.
-
Uživatel vyhledá příslušné faktury, třeba ve vyhledávači nebo v modulu Doklady nebo v nějaké vyhledávací složce, použitím klávesy <Ctrl+K> je vloží do K-schránky.
-
V obsahu bankovního výpisu vyvolá z plovoucího menu funkci .
-
Zobrazí se dialog, informující o počtu dokladů v K-schránce a o celkové částce "k úhradě".
-
Po ověření těchto údajů uživatel dialog potvrdí a program automaticky vytvoří řádky, párované na jednotlivé doklady, uhrazující je "na nulu".
Uvedená funkčnost má svá omezení:
-
činnost v plovoucím menu je dostupná pouze v prohlížeči bankovního výpisu v národní měně,
-
z K-schránky jsou zpracovány pouze faktury vydané a faktury přijaté,
-
z K-schránky jsou zpracovány pouze doklady v národní měně,
-
ostatní druhy dokladů a doklady v jiných měnách, než v národní, jsou ignorovány.
-
-
Kaskáda nyní podporuje tisk čarového kódu na dodacím listu vydaném a expedičním příkazu >>>
Nově je možné v globální konfiguraci na kartě Produkty zapnout tisk čarových kódů.
Zapnutí se provede výběrem typu čarového kódu, kterým bude kód produktu na dokladu prezentován, v combu "Druh čárového kódu pro prezentaci kódu produktu v DLV".Ve vedlejším combu "Způsob tisku čárového kódu v expedičním příkazu" pak můžete zvolit režim tisku čarového kódu v expedičním příkazu.
V prohlížeči kontaktu na kartě Další / Další parametry je možné u konkrétního kontaktu zapnout požadované chování tisku.
Toto nastavení pak bude přeneseno do doadcího listu vydaného jako výchozí hodnota.V prohlížeči dodacího listu vydaného je možné změnit chování tisku konkrétního dokladu.
-
Byl zrušen číselník účetních souvztažností >>>
Při prvotním vývoji Kaskády se zdálo, že pro uživatele bude praktické definovat si univerzální číselník různých operací, t.j. účetní souvztažnosti, které potom budou používat jako "mustr" při tvorbě předkontací v reálných dokladech.
V praxi se ukázalo, že je to jinak. Na jednu stranu usnadňuje tvorbu předkontací důsledné využívání šablon dokladů (což má i řadu dalších pozitivních dopadů) a na druhou stranu se mnoho předkontací vytváří automaticky, v rámci určitého kontextu, hlavně v peněžních a skladových dokladech, párovatelných dokladech apod. Definice účtů na úrovni skladů, účelů dodávky, u produktů ... to vše osvobozuje uživatele od nutnosti rozhodování o účetních předkontacích v dokladech.
Rozeslali jsme všem uživatelům dotaz, zda používáte při tvorbě předkontace účetní souvztažnosti.
Všechny odpovědi byly záporné.
Na základě toho jsme číselník účetních souvztažností zrušili a upravili všechna místa, kde byl k dispozici.Pro jistotu opakujeme, že tato úprava nijak nebrání tvorbě předkontací v konkrétních dokladech (nebo šablonách).
-
U položek Celního sazebníku lze nyní určit, zda se mají/nemají tisknout v řádcích vydaných faktur >>>
Do číselníku celního sazebníku byl doplněn údaj (zaškrtávací pole), který rozhoduje o tom, zda se daný kód CS bude tisknout na dokladech jako součást názvu produktu, je-li to v dokladu požadováno. Jde tak rozlišit skutečné kódy celního sazebníku od "pomocných" kódů, které zde jsou zadány jen kvůli produktům, které se zdaňují v režimu přenesené daňové povinnosti a nějaký, byť fiktivní kód u nich musí být zadán.
Ve výchozím stavu je toto zaškrtávací pole zaškrtnuté, kód se na dokladech může tisknout.
Během aktualizace dojde k odškrtnutí u kódů, které začínají "PR.DA.PO.". Jde o strojně generované kódy využívané a vytvářené během automatického vytváření řádků s povinností přiznat daň při zpracování faktury přijaté v režimu přenesení daňové povinnosti. -
Byl upraven výpočet celkové částky dokladu ve stavu rozpracovanosti >>>
Dosud byla celková částka dokladu ve fázi rozpracovanosti (před vystavením dokladu) vypočítávána jako prostý součet částek z obsahu dokladu, což za určitých okolností mohlo působit poněkud nesmyslně.
Při vystavení dokladu pak byla tato celková částka velice často přepsána částkou jinou, vyplývající z výpočtu s přidanou logikou. To se stalo především u párovatelných dokladů s párovacími položkami (vyrovnání záloh apod.), u přijatých faktur v režimu přenesené daňové povinnosti apod.
Svojí roli v tom také sehrává nastavení konfigurace účetnictví, zda Do celk.částky u faktur započítávat i párovací položky (zálohy...).
Kromě vystavení dokladu, změnila tuto částku i funkce pro Kontrolu integrity objektu.Nově byl program upraven tak, aby Kaskáda průběžně počítala celkovou částku dokladu tak, jak bude vypočtena při vystavení.
Pro jistotu uveďme, že nejde o částku, která má něco společného se zůstatky párovatelných dokladů, inventarizací účtů, apod. V této úpravě jde o zcela jiné částky, spíše informativní.
-
Byla upravena kontrola duplicitního zadání variabilního symbolu v dokladu >>>
Dosud program kontroloval duplicitu zadání variabilního symbolu v dokladech striktně vždy, bez ohledu na jeho hodnotu.
Nově je program upraven tak, aby v případě, kdy je variabilním symbolem dokladu IČO nebo DIČ vlastní firmy, nebyla tato kontrola prováděna.
Pokud je variabilním symbolem IČO nebo DIČ vlastní firmy, obvykle těchto dokladů je v systému více a je celkem zbytečné na toto upozorňovat. Varování bylo zbytečně zdržující. -
Bylo vylepšeno chování programu při zobrazování PDF dokumentů >>>
Doposud program pro zobrazení PDF dokumentů používal technologii, která využívala aktuálně nainstalovaný Acrobat Reader na stanici. Problém však nastal v situaci, kdy uživatel na stanici nainstaloval jinou než doporučenou verzi Acrobat Readeru, protože komponenty zobrazující PDF dokumenty dokázaly pracovat pouze s určitou verzí AR.
Součástí distribuce Kaskády je nyní nová externí aplikace Sumatra PDF.
Pro zobrazení PDF dokumentů program nyní nejdříve zjistí verzi operačního systému a verzi nainstalovaného Acrobat Readeru a podle toho se zachová (buď použije AR nebo Sumatru).
Bližší informace najdete v kapitole helpu Aplikace třetích stran pro práci se soubory ve formátu PDF.
-
V souladu se změnou Celního zákona Kaskáda akceptuje změny v celním zákonu při tisku přílohy pro celní řízení a při generování dat pro Intrastat >>>
Dosud se v příloze pro celní řízení tiskl kurz získávaný od kontaktu, který byl v globální konfiguraci uveden jako Celní úřad, který vydává svůj vlastní kurzovní lístek. Stejný kurz byl použit i pro generování dat pro Intrastat.
V souvislosti se změnou Celního zákona byla Kaskáda upravena tak, že jak pro přílohu pro celní řízení (jejíž tisk je k dispozici v prohlížeči faktury vydané), tak pro generování dat pro Intrastat, se nově používá kurz z hlavičky dokladu (zadán v kartě Rekapitulace), tzn. tentýž kurz, který byl použit pro výpočet částek v národní měně, které se nadále promítly do účetnictví, agendy DPH, atd.
-
Bylo upraveno zadávání nových a oprava existujících chybných DIČ >>>
V předchozích verzích jsme nově zavedli blokaci změn DIČ v dokladech, které patří do již uzavřených DPH období a začali jsme přebírat kód státu přímo z DIČ, namísto používání údaje "Stát". Tím se neúmyslně v některých případech zamezilo opravě vadného DIČ na nějaké regulérní DIČ a někdy nešlo ani platnost tohoto chybného DIČ ukončit a vytvořit nové.
Nyní, v této úpravě, tato přísná pravidla trochu uvolňujeme. Půjde tak provést změnu DIČ zřejmě ve většině případů, které dosud provést nešly a přitom šlo o "pouhou" kosmetickou změnu.
Při zadávání i změně DIČ jsou prováděny následující kontroly a činnosti
- ze zadávaného DIČ jsou odstraněny všechny mezery,
- ze zadávaného DIČ jsou první 2 znaky použity jako kód země,
- tyto první 2 znaky jsou prověřeny na to, zda jde o písmenka a
- zda tato písmenka tvoří prefix DIČ u nějakého existujícícho státu v číselníku států.
Pokud některá z uvedených podmínek není splněna, zobrazí se příslušné chybové hlášení.
Kontrola výskytu opravovaného DIČ v dokladech v uzavřených DPH období byla změkčena tak, že za nepovolenou změnu DIČ není považováno
- vypuštění mezer z původního DIČ, pokud se jinak nově zadávané DIČ nemění,
- doplnění prefixu DIČ (kódu státu) u DIČ, které tento údaj dříve neobsahovalo,
- změna DIČ pouze v dokladech, které patří do DPH období před 1.1.2016, tedy před platností kontrolního hlášení,
- změna DIČ pouze v dokladech, které NEpatří do žádné detailní věty kontrolního hlášení v uzavřeném DPH období
-
Při použití funkce "Odeslat prostřednictvím zásilky" se nyní předvyplní e-mailová adresa příjemce Detail
Dosud, pokud byla pro "odeslání objektu" použita volba v menu prohlížeči zásilky prázdné, nevyplnila se do něj e-mailová adresa příjemce.
, bylo pole "Komu:" v
Při použití volby "Nový související" byl(i) adresát(i) řádně vyplněn(i).Toto chování bylo upraveno a nyní se e-mailová adresa příjemce předvyplní.
-
Technologická úprava inicializace skupinového vlastnictví při tvorbě nových objektů >>>
Jde o úpravu, jejímž cílem je oprava některých "ošklivostí" při vytváření nových objektů, např. při tvorbě konceptu zásilky a při přepínání soukromého / veřejného vlastnictví.
-
Bylo umožněno naplánovat počátek i konec odesílání automatické odpovědi v době nepřítomnosti >>>
V menu
je nyní možné kromě textu této odpovědi také nastavit datum počátku a konce zasílání této automatické odpovědi.
Dosud zde bylo možné pouze zaškrtnout (zapnout) nebo odškrtnout (vypnout) tuto funkčnost.Nové řešení umožní v předstihu tuto odpověď zapnout a zároveň definovat začátek i konec platnosti.
-
Byl upraven režim načítání informací o organizaci ze systému ARES pokud je firma hledána podle jejího názvu >>>
Pokud byla firma v systému ARES hledána podle zadaného vzorku názvu, nedošlo k načtení informace o DIČ vyhledaného kontaktu.
Po dosazení získaných informací do prohlížeče kontaktu, bylo nutné spustit vyhledání znovu - nyní již podle IČO. V tomto případě se již DIČ ze systému ARES přebralo a doplnilo do prohlížeče kontaktu.Podobně se program choval i při využití volby v menu
.Uvedené chování bylo napraveno tak, aby hned na první pokus byly načteny všechny dostupné a využitelné informace.
-
Bylo zamezeno uložení DIČ načteného ze systému ARES ve tvaru "Skupinove_DPH" >>>
Pokud během zadávání nové organizace (nebo editace existující) necháváte Kaskádu načíst všechny potřebné informace ze systému ARES, pak u organizací, které mají skupinovou registraci k DPH, je do pole pro zadání DIČ vyplněn z ARESu text "Skupinove_DPH". Tento text samozřejmě nepředstavuje žádné reálné DIČ, je to pouze upozornění, že DIČ je potřeba zjistit jinde a jinak.
Aby nedocházelo ke zbytečným chybám a problémům, Kaskáda se nyní brání DIČ v takovémto tvaru uložit. Při pokusu o uložení tohoto DIČ se zobrazí chybová hláška upozorňující na tuto skutečnost, DIČ je potřeba zadat ručně, nejspíše podle daňového dokladu, nebo si ho vyhledat pomocí webového přístupu do systému ARES, kde se k němu dá "proklikat". Následně je potřeba v dialogu pro zadání DIČ ručně zaškrtnout, že se jedná o skupinové DIČ.
-
Program neumožní potenciální chybné chování uživatele při zadávání čísla bankovního účtu ( lomítko a směrový kód ) >>>
Číslo bankovního účtu a swift (resp. směrový kód banky) se v Kaskádě zadávají do dvou samostatných editačních polí, jsou to dva samostatné údaje v databázi.
Mohlo se ale stát, že uživatel zadal číslo účtu včetně lomítka a směrového kódu do pole pro zadání samotného čísla bankovního účtu, to následně působilo komplikace.Nyní program neumožní do pole pro číslo zapsat lomítko, to je pro uživatele jasný signál, že se směrový kód neuvádí zde, ale ve vedlejším zadávacím poli.
-
Je vytvořeno rozhraní pro pohodlný přístup k metodikám souvisejícím s určitým uživatelem >>>
V organizacích, které využívají funkčnost dokumentů typu Metodika, najde uplatnění tato úprava, v rámci níž v uživatelském rozhraní přibyly dvě karty
-
v uzlu Start, zde se zobrazí metodiky, ke kterým má nějaký vztah přihlášený uživatel
-
v prohlížeči kontaktu, zde se zobrazí metodiky, ke kterým má nějaký vztah uživatel zobrazený právě v prohlížeči
-
-
Byla odstraněna chyba, která se za velmi specifických okolností zobrazovala při tisku mzdového listu >>>
V situaci, kdy v dané datové větvi neexistovala žádná nepřítomnost (což je velmi atypická situace), tisková sestava zbytečně hlásila chybu "Záznam nenalezen". Mzdový list se však vytiskl zcela správně.
Uvedená chyba v popsané situaci byla odstraněna.
-
Byla upravena tisková sestava Přílohy k žádosti o dávky a také odpovídající definice pro export dat v XML formátu >>>
Formulář pro tisk i definice exportu je nyní v souladu se vzorem dostupným v 7 / 2016.
Původní XML export je platný do 6 / 2016 a nový je platný od 7 / 2016.
Formulář pro tisk byl pouze upraven a ponechán platným pro předchozí i budoucí období. -
Byl upraven režim kopírování položek obsahu objednávky (nebo dodacího listu) z předlohy (nová objednávka/DL kopií existující) Detail
U Objednávky od zákazníka, Objednávky k dodavateli, Dodacího listu vydaného a Dodacího listu přijatého bylo upraveno kopírování Prodejce/Nákupčího a/nebo Realizátora uvedených v řádcích obsahu zdrojové objednávky / dodacího listu.
Dosud program oba údaje prostě zkopíroval ze zdroje bez ohledu na to, zda byly/nebyly provedeny změny příslušných osob v hlavičce objednávky (nebo dodacího listu).
Nyní je program upraven tak, že pokud je před prvním uložením hlavičky objednávky / dodacího listu provedena změna Prodejce/Nákupčího a/nebo Realizátora, jsou ve stejném duchu promítnuty tyto změny i v obsahu u všech příslušných řádků nově vzniklé objednávky (nebo dodacího listu), které vznikly kopií z předlohy.
-
Byla vylepšena univerzální funkce pro export dat z tabulek >>>
Jde o technické prvky, vedoucí k odstranění problémů v některých specifických situacích.
Tyto specifické situace se týkaly např. tisku určitých konkrétních sloupců s vypočtenými daty, setřídění podle některých údajů apod.