Volba profilu
Aktuality
eShop pokusný
Naše produkty
Vyhledat objekt
Odkazy
Úpravy Kaskády dle verzí
Úpravy Kaskády dle oblastí

16.07, Úpravy v této verzi, 22.12.2016

Vyřešené úpravy dle verzí / V16 / 16.07, Úpravy v této verzi, 22.12.2016
  • V Kaskádě byla zprovozněna Elektronická evidence tržeb  >>>

    V Kaskádě je od verze 16.07 zavedena podpora Elektronické evidence tržeb, kterou upravuje zákon č. 112/2016 Sb..

    Veškeré informace týkající se problematiky EET jsou k dispozici v samostatné kapitole helpu Elektronické evidence tržeb - EET

    POZOR: V této verzi Kaskády není provedena úprava znakového tisku účtenky, ale pouze tisk účtenky ve formátu A4 a A5. Znakový tisk účtenky s EET bude k dispozici v příští verzi Kaskády.

  • Byla vylepšena práce s řádkem faktury přijaté s účelem dodávky Nákup na obj.zák.-spotřeba / prodej napojené na objednávku od zákazníka  >>>

    Dosud

    • Takovýto řádek neměl pro prodej z objednávky specifikovaný způsob zdanění.
      Při jakékoliv pozdější editaci řádku v obsahu objednávky k zákazníkovi byl způsob zdanění inicializován základní sazbou a při ukládání jakékoliv jiné změny, byla vyvolána chybová hláška, která uložení změn neumožnila.

    • Při mazání takového řádku ve faktuře v kartě Obsah, došlo ke smazání řádku pouze ve faktuře. V obsahu objednávky zůstával řádek do té doby, dokud ho někdo ručně nesmazal. Nic jiného s ním ani nešlo udělat. Dokud tak někdo v objednávce neučinil, řádek tu "visel" a bránil vypořádání obejdnávky.

    Nově je program upraven tak, aby:

    • Při vytváření řádku v obsahu ve faktuře přijaté napojeného na objednávku od zákazníka s účelem dodávky Nákup na obj.zák. - prodej byl převzat způsob zdanění pro objednávku ze způsobu zdanění ve faktuře přijaté.
      Pro možnost vyřešení problémů s již pořízenými daty byla povolena změna způsobu zdanění z "nezadáno" na způsob zdanění, který figuruje v dokladu, ve kterém je řádek objednávky použit.

    • Při mazání řádku v obsahu faktury přijaté navázaného na objednávku od zákazníka s účelem dodávky

      • Nákup na obj.zák.-spotřeba, došlo ke smazání řádku v příslušné objednávce od zákazníka

      • Nákup na obj.zák.-prodej, došlo ke smazání řádku v příslušné objednávce od zákazníka v situaci, kdy daný řádek objednávky ještě nefiguruje v žádné faktuře vydané.
        Pokud již řádek objednávky figuruje v obsahu faktury vydané, dojde pouze ke smazání řádku z obsahu faktury přijaté. Obsah objednávky, případně faktury vydané je nutné dořešit ručně.

  • Nové možnosti v oblasti automatického párování plateb v bankovních výpisech  >>>

    Tato úprava přináší dvě hlavní novinky

    Variabilní symbol na úrovni Objednávky od zákazníka

    Dosud takovýto údaj neexistoval.

    Smyslem jeho zavedení je umožnit odběrateli provádění opakovaných plateb přes jeden stálý VS, například při platbě pravidelných konstantních záloh prostřednictvím trvalého příkazu v bance.

    I nadále samozřejmě zůstávají k dispozici veškeré mechanismy individuálních dokladů, jejich individuální a unikátní generované variabilní symboly. Zde popisovaný mechanismus je pouze další možností, stojí na následujících konceptech:

    • V prohlížeči objednávky k zákazníkovi na kartě Platby lze zadat variabilní symbol (pokud je u příslušné číselné řady zadána předpona, pak se bude VS tvořit automaticky).

    • Doklady vznikající v souvislosti s objednávkou se na takovou objednávku odkazují, což je u nich vidět jak v kartě Souvisí (typ propojení Pro doklad je výchozí objednávkou), tak v kartě Rekapitulace, údaj "Objednávka".

    • Pokud budou přicházet platby na konto takových dokladů, bude program při automatickém párování akceptovat jak jejich individuální VS, tak (pokud nic nenalezne) i "alternativní" VS u objednávek.

    • V kartě Importovaná data / Pracovní tabulka je k dispozici m.j. informace o tom, který VS program při párování nalezl a použil pro spárování.

    Přepracování algoritmu automatického párování

    Přepracování souvisí s problematikou z minulého odstavce, řeší toho však více.

    Vnějším projevem této úpravy jsou především nové sloupce v bankovním výpise na kartě Importovaná data / Pracovní tabulka:

    • Zdroj VS
      Tento sloupec informuje o tom, kde program nalezl shodný VS. Možná místa jsou:

      • Plat. kalendář
      • Doklad (hlava)
      • Smlouva
    • Způs.urč.aktéra
      Tento sloupec informuje o tom, podle kterého údaje byl rozpoznán aktér. Může to být:

      • Bankovní účet
      • VS u kontaktu
      • Název
      • Doklad (zpětně)
    • Záznam v pl.kal.
      Záznam v platebním kalendáři, podle kterého došlo k automatickému spárování, pokud párování proběhlo skutečně dle platebního kalendáře.

    • Posl
      Tento údaj informuje o tom, jaký krok při automatickém párování program provedl naposledy.

  • Změna pojetí data vystavení u dokladů  >>>

    Pro údaj Datum vystavení u dokladů dosud platilo

    Výše uvedené principy jsou zcela v pořádku pro "odchozí doklady", t.j. takové, kde uživatel Kaskády tvoří doklad určený pro druhou stranu, typicky vydané faktury a vydané dodací listy.

    Výše uvedené principy se ukázaly jako omezující pro příchozí doklady (přijaté faktury, přijaté ZL a přijaté DL), neboť

    • u nich je "vystavujícím" někdo mimo Kaskádu, datum vystavení je v jeho režii, může a nemusí splňovat různé předpoklady,

    • z hlediska "informačních potřeb" je žádoucí zaznamenat správně a přesně tento údaj "opsaný" z přijatého dokladu.

    Tato úprava uvádí pojetí data vystavení do stavu, lépe odpovídajícímu reálnému životu a informačním potřebám, týká se to pouze přijatých faktur, přijatých ZL a přijatých DL, u ostatních dokladů se nic nemění.

    Postup stanovení datumu vystavení je uveden v kapitole Datumy a období.


    U přijatých zálohových listů je navíc k dispozici činnost zdanění zálohy, při níž je také nutno pracovat s datumy.
    Proto byl upraven i dialog pro tuto činnost a je zde kromě polí pro určení DUZP a DUÚO nově i pole pro zadání data vystavení (míněno vystavení příjemcem zálohové platby).

    Další "malou změnou" je odstranění dosavadní kontroly, která u dokladů ovlivňujících agendu DPH nepřipustila, aby datum vystavení bylo menší než DUZP.
    V praxi totiž nastávají situace, kdy realita neodpovídá "obvyklým situacím", taková restrikce pak brání korektnímu záznamu dokladu. Proto byla restrikce odstraněna a je ponecháno na uživateli, aby datumy zadal korektně.

    Pokud by vznikl dojem, že uvedená změna logiky uživatele Kaskády ochuzuje (u přijatých dokladů) o informaci, kdy byl doklad vystaven na straně Kaskády, není to pravda. Kaskáda zaznamenává do tabulky historie objektu mnoho detailních informací, m.j. i okamžik nastavení různých vlastností (schválení platby, vystavení, zaúčtování, .... ), takže pro interní potřebu je informací dostatek.

  • Byla provedena změna v tisku zápatí externích sestav párovatelných dokladů - bankovní účet  >>>

    Tato úprava se týká pouze uživatelů, kteří nemají do Kaskády naimportovaný obrázek zápatí pro externí tiskové výstupy.

    Dosud mohl nastávat problém s platbou vašeho odběratele na váš bankovní účet uvedený ve vydané faktuře (nebo ZL), pokud tento požadovaný cílový účet byl jiný, než výchozí bankovní účet určený v globální konfiguraci.
    Důvodem bylo to, že bez ohledu na data konkrétní faktury, standardní zápatí vždy zobrazovalo právě a pouze bankovní účet určený v globální konfiguraci. Při nepozornosti toho, kdo fakturu "na druhé straně" zpracovával, došlo snadno k situacím, kdy zákazník zaplatil na účet uvedený v zápatí dokladu, protože na tento účet "narazil" jako na první. Přitom to mohl být třeba i účet vedený v jiné měně.

    Nově se program pokusí zjistit číslo účtu uvedeného v dokladu a pokud se mu to podaří, bude vytištěno jak v zápatí, tak i v hlavičkových údajích faktury / zálohového listu.
    Pokud se programu nepodaří zjistit číslo účtu zadané u dokladu, např. z důvodu, že jde o hotovostní úhradu, je v zápatí vytištěn výchozí bankovní účet vytěžený z globální konfigurace, stejně jako tomu bylo dosud.

    Změna se týká především tisku faktury vydané a zálohového listu vydaného, ale může se projevit i u některých jiných tiskových sestav párovatelných dokladů.

  • Byla upravena tisková podoba "Daňového dokladu o přijaté platbě"  >>>

    V tisku zdaněného zálohového listu, tedy "Daňového dokladu o přijaté platbě" byly provedeny změny tak, že:

    V souvislosti s výše uvedenou úpravou tisku zdaněného zálohového listu vydaného jsme ve stejném duchu provedli drobné úpravy i v jiných tiskových sestavách, ve kterých je zobrazen přehled párovacích položek na daný doklad.
    Jde o tiskové sestavy

    • Faktura vydaná - sekce "Úhrada faktury hotově"
    • Faktura přijatá - sekce "Úhrada faktury hotově"
    • Účetní doklad - sekce "Párovací položky"

    I v těchto sestavách nyní figuruje "Datum uskutečnění účetního případu" dokladu, který na právě tištěný doklad páruje, místo jeho "Datumu vystavení".

  • V prohlížeči propojení typu "Smluvní partner" lze nyní zadat k osobám zastupujícím společnost i doplňkový text  >>>

    Tato úprava se týká grafické úpravy záhlaví v tisku smlouvy (běžná smlouva nebo objednávka od zákazníka, pracující s mechanismem tvorby smlouvy).
    Konkrétně jde o vymezení osob, zastupujících společnost aktéra, t.j. protistranu.

    Kaskáda umožňuje zadání jedné nebo dvou osob z těch, které souvisí s danou organizací, tyto osoby pak budou figurovat v záhlaví smlouvy.

    • Dosud nebylo možno kromě určení osob přidat nějaký volný text.

    • Nyní lze kromě určení osob přidat volný text v délce 30 znaků ke každé z těchto dvou osob. Text bude při tisku smlouvy připojen ke jménům příslušných osob.

  • Bylo umožněno účtování účetních operací korigujících odpočty DPH v přiznání k DPH a vrácení daně cizinci v přímé návaznosti na přiznání k DPH  >>>

    Dosud nebylo možné v Kaskádě zaúčtovat doklad, který by ovlivnil daňovou povinnost a zároveň stavy na příslušných účtech v případě

    • Korekce odpočtů daně dle § 75 odst. 4, § 77, § 79 až § 79c - řádek přiznání 45
    • Úpravy odpočtu daně dle § 78 až § 78d - řádek přiznání 60
    • Vrácení daně podle § 84 - řádek přiznání 61

    Vždy bylo nutné zaúčtovat doklad bez vazby na přiznání k DPH a před tiskem či exportem daňového přiznání dopsat ručně příslušné částky do příslušných polí v dialogu Výkazy agendy DPH na kartě Přiznání k DPH.

    Nově jsou atributy příslušných druhů DPH upraveny tak, aby na ně bylo možné požadovanou operaci zaúčtovat a tím automaticky promítnout do přiznání k DPH bez nutnosti nějakých ručních zásahů při generování dat přiznání k DPH.

    Kromě úpravy atributů druhů DPH, které jako uživatelé nemáte možnost ovlivnit, je také u zmíněných druhů nastaven účet DPH, na kterém má být příslušná operace evidována. Jako výchozí stav jsou použity účty od druhů DPH, které jsou nejběžněji používané, to jsou druhy prezentující řádek 01 a 40a v přiznání k DPH. Pokud cítíte potřebu tyto účty změnit, můžete tuto změnu provést v konfiguraci účetnictví na kartě DPH / Druhy DPH.

    K zaúčtování uvedených operací je nutné použít interní doklad, u kterého, kromě jiných atributů, je potřeba nastavit

    Název atributu Korekce a úpravy daně Vrácení daně cizinci
    Aktér Není nutný, nemusí být tedy plátce DPH Není nutný, nesmí však jít o plátce DPH
    Ovlivňuje agendu DPH zaškrtnout
    Typ plnění Změna režimu, korekce, úpravy daně Vrácení daně cizinci
    Oblast určení Tuzemsko Zahraničí
    Karta Rekapitulace / Výchozí druh DPH Úprava odpočtu daně (§ 78 až § 78d)
    Korekce odpočtů daně - plný nárok na odp.
    Korekce odpočtů daně - krátí nárok na odp.
    Vrácení daně (§ 84)

    V řádku obsahu dokladu pak Kaskáda připraví příslušnou DPH předkontaci (pokud jde o párovatelný doklad) a připojí ji k vytvářenému řádku. V něm pak postačí zadat výši DPH, o které si přejete korigovat odpočet DPH.

  • Byl vylepšen režim pro plnění adresátů do hromadné zásilky  >>>

    Dosud

    • Činnost Odeslat zásilku kontaktům byla k dispozici nad složkami kontaktů a databoxů.
    • Z obsahu složek se využily pouze objekty druhu kontakt.
    • Při pokynu k použití faxových čísel (kromě e-mail adres) mohlo za určitých okolností docházet ke zmatečnému chování programu.

    Nyní

    • Činnost je k dispozici nad všemi druhy složek.
    • Z obsahu složek lze využít (na pokyn uživatele) jakékoliv druhy objektů - v tom případě se použijí elektronické adresy aktérů takových objektů.
    • Při pokynu k použití faxových čísel (kromě e-mail adres) již probíhá vše korektně.
  • Oprava stanovování vlastnické skupiny u zásilek přicházejících do Kaskády zvenku  >>>

    Za určitých okolností systém neakceptoval specifický požadavek na nastavení vlastnící skupiny u příchozích zásilek, namísto specifické skupiny definované pro odesílatele, použila se výchozí skupina.

    Výše uvedený problém bylo možno eliminovat tak, že správce uživatelů a skupin nastavil u uživatele "Mailer" atribut Sdílení zásilek na hodnotu "Smí neveřejné - výchozí stav dle šablony".

    Nyní je program upraven tak, že bez ohledu na výše uvedené nastavení uživatele "Mailer", funguje inicializace vlastnické skupiny korektně.

  • V nabídce modulů se nyní nebudou nabízet moduly, které z hlediska dané varianty nejsou dostupné Detail

    Dosud se v nabídce modulů nabízely veškeré existující moduly.
    Když uživatel položku menu zvolil, buďto se modul otevřel, nebo se zobrazilo hlášení, že v dané variantě (např. Finance) není modul dostupný.

    Nyní se v menu zobrazí pouze dostupné moduly, takže se pro uživatele zjednoduší a zpřehlední nabídka.

  • Podpora tisku čarových kódů přímo z Kaskády  >>>

    Po instalaci verze Kaskády 16.06 s úpravou č. UPK-16-0087, která zavádí možnost tisku čarových na dodacích listech, bylo zjištěno, že na stanicích, kde nebyl nainstalován klient 602SQL, nebylo možné tyto čarové kódy vytisknout. Chyba je způsobena absencí knihoven DLL potřebných pro sestavení čarového kódu.

    V rámci této úpravy je zajištěno, aby při běžné instalaci Kaskády došlo také k dodání příslušných knihoven do instalačního adresáře Kaskády, což zabezpečí tisk i na stanicích, kde není 602SQL klient nainstalován.

  • Lépe byla ošetřena změna oprávkového účtu u majetku  >>>

    Dosavadní chování

    Pokud není majetek předán do užívání, bylo a stále je možné změnit oprávkový účet na kartě Účetní evidence / Základní parametry.
    Zde provedená změna však nebyla promítnuta do již existujících záznamů o pořízení na kartě Protokol.

    Při předání majetku do užívání program vygeneruje záznam do karty Protokol, kde jako oprávkový účet použil účet uvedený v protokolu u posledního řádku s "pořízením / změnou ceny". Tento účet však mohl být jiný, než je uvedený na kartě Účetní evidence / Základní parametry.
    Při generování plánu odpisů je u těchto záznamů opět použit oprávkový účet z posledního platného (zaúčtovaného) záznamu v Protokolu. Tím je v tomto případě záznam o předání majetku do užívání.

    Při plnění interního dokladu byl jako oprávkový účet použit účet z karty Protokol, tedy to mohl být jiný účet, než je v kartě Účetní evidence / Základní parametry.
    Při zaúčtování dokladu o odpisech však program zobrazil chybovou hlášku, že oprávkový účet použitý v předkontaci nesouhlasí s oprávkovým účtem zadaným v prohlížeči majetku na kartě Účetní evidence / Základní parametry. Šlo tu o rozpor, kdy program porovnával účet v předkontaci převzatý z karty Protokol s původním účtem, zadaným na kartě Účetní evidence / Základní parametry.

    Nové chování

    Pokud není majetek předán do užívání, bylo a stále je možné změnit oprávkový účet na kartě Účetní evidence / Základní parametry.
    Zde provedená změna je ihned promítnuta do již existujících záznamů o pořízení na kartě Protokol, ale pouze v situaci, kdy je majetek opravdu ve stavu "Pořizuje se" a v kartě Protokol neexistuje žádný zaúčtovaný záznam o účetních odpisech.

    Při předání majetku do užívání program vygeneruje záznam do karty Protokol, kde jako oprávkový účet nově použije účet uvedený na kartě Účetní evidence / Základní parametry.
    Při vygenerování plánu odpisů je u těchto záznamů opět použit oprávkový účet z posledního platného (zaúčtovaného) záznamu v Protokolu. Tím je v tomto případě záznam o předání majetku do užívání, který je již v souladu s údajem v kartě Účetní evidence / Základní parametry.

    Při plnění interního dokladu je stále jako oprávkový účet použit účet z karty Protokol, tedy to mohl být jiný účet, než je v kartě Účetní evidence / Základní parametry. Při zaúčtování dokladu o odpisech program nově porovnává účet v předkontaci převzatý z karty Protokol s oprávkovým účtem platným pro dílčí účetní období odpovídající datumu uskutečnění účetní operace v interním dokladu. Toto datum je těženo funkcí, mimo jiné také z údajů v kartě Protokol.

    Navíc bylo doplněno mazání plánu daňových odpisů v situacích kdy majetek:

    • mění formu evidence na evidenci "Věcná evidence", nebo
    • mění stav z "Užíván" zpět na "Pořizuje se"

    Tímto opatřením předcházíme některým patovým situacím, které mohly nastat a k jejich vyřešení bylo nutné objednávat služby našeho technika.

  • Byla vytvořena podpora výpočtu a nastavení minimálních stavů u produktů  >>>

    V Kaskádě je nyní k dispozici funkčnost, která na základě realizovaných pohybů produktů navrhne minimální stav produktu. Pokud s tímto návrhem programu souhlasíte, máte možnost tento navrhovaný minimální stav zapsat k produktu.

    Zapnutí funkcionality provedete v Globální konfiguraci na kartě Produkty / Základní parametry zadáním nenulového počtu dní, za které má Kaskáda zjišťovat spotřebu produktů a navrhovat minimální stav.
    K vymezení účelů dodávky, které mají být považovány za spotřebu produktu (nejen nějakou vnitrofiremní manipulaci), je možné využít nově doplněný údaj "Spotř.mat." v Konfiguraci účetnictví na kartě Účely dodávky / Účely dodávky .

    Vzhledem k tomu, že výpočet spotřeby i navrhovaného minimálního stavu, řeší uživatelsky modifikovatelné funkce na SQL serveru, nelze tu popisovat přesnou logiku výpočtu. Ta může být v každé firmě jiná, naprogramována technickými pracovníky firmy Černý dle konkrétních požadavků na míru.
    Pokud máte o úpravu výpočtu minimálních stavů produktů zájem, kontaktujte HotLine oddělení firmy Černý s poptávkou po této úpravě.

  • Byl upraven režim zadávání a editace množství v kusovníku výrobku  >>>

    Dosud program neakceptoval počet desetinných míst pro množství nastavené v prohlížeči příslušného produktu a stále pracoval pouze se dvěmi desetinnými místy.

    Nyní je program upraven tak, aby při vkládání nového produktu do kusovníku i při editaci množství existujícího produktu v kusovníku, pracoval s takovým počtem desetinných míst, které je zadáno v prohlížeči vkládaného/editovaného produktu do/v kusovníku.

Detekce Javascriptu proběhla. (?)
Návštěv webu: 113627.