Volba profilu
Vyhledat objekt
Úpravy Kaskády dle verzí
Úpravy Kaskády dle oblastí
Ceník služeb
Odkazy

17.01.04, Úpravy v této verzi, 7.3.2017

Vyřešené úpravy dle verzí / V17 / 17.01.04, Úpravy v této verzi, 7.3.2017
  • Změny v oblasti EET, tisk účtenek a faktur, datum vystavení u dokladů ...  >>>

    Stanovení data vystavení

    U účtenek z VEGY (dodací listy) a souvisejících individuálních faktur vydaných (s úhradou v hotovosti nebo platební kartou) nyní program za datum vystavení považuje vždy aktuální systémové datum bez ohledu na nastavenízpůsobu stanovení datumu vystavení v konfiguraci účetnictví.
    Platí, že stejné datum a čas jsou použity v

    • hlášení EET
    • u dokladů (a to jak u datumu vystavení, tak v názvu)
    • v tisku účtenek z VEGY i ve faktuře vydané související s danou účtenkou

    U ostatních dokladů je datum vystavení stanoven jako doposud, tedy s přihlédnutím na nastavenou konfiguraci.

    Nová kontrola - prodejní den v nesouladu s aktuálním datem

    Při otevření pokladny VEGA program nově kontroluje datum prodeje s aktuálním systémovým datem a pokud jsou tyto datumy rozdílné (např. proto, že předchozí den neproběhla řádně uzávěrka dne) a zároveň prodejní den spadá do předchozího měsíce, program zobrazí upozornění.

  • Bylo upraveno chování Kaskády při platbách kartou v pokladně VEGA  >>>

    V rámci pokladního systému VEGA nastává dilema u účtenek placených platební kartou.

    • Kvůli pozdějšímu zpracování bankovního výpisu musí jít o adresný prodej (obsluha vybírá určitý kontakt, byť by to byl jakýsi "pseudokontakt") a program vytváří vydanou fakturu.

    • Tisk může uživatel provádět jak formou běžné účtenky VEGY, tak i formou faktury - stačí otevřít její prohlížeč a spustit tisk.

    • Z hlediska EET však musí existovat pouze jeden objekt, který je do EET-systému ohlašován.

    Proto jsou zavedeny následující principy.

    • Objektem, který Kaskáda do EET-systému ohlašuje, bude v uvedených případech vždy a pouze účtenka VEGY, technicky je to dodací list speciálního druhu.

    • Odeslání záznamu do EET-systému bude vázáno pouze a jedině na manipulaci s účtenkou, zatímco manipulace se související fakturou bude z hlediska EET zcela "mimo hru".

    V uživatelském rozhraní Kaskády se to projeví následovně

    • Dialog pro pohled na EET-zprávy otevíraný z prohlížeče dokladu bude v případě "Vega-faktury" automaticky přesměrován na záznamy příslušné účtenky (dodacího listu).

    • V tiskové podobě "Vega-faktury" bude z hlediska EET uveden FIK příslušné účtenky, zároveň zde bude uvedeno i číslo této účtenky (což je samozřejmě jiné, než číslo samotné faktury).

  • Při tvorbě nového párovaného dokladu z řádku bank.výpisu se přednastaví DUZP  >>>

    Jedná se o ad-hoc vytváření dokladu, ovlivňujícího agendu DPH, z dialogu pro zadání atributů určitého řádku bankovního výpisu.
    V tomto režimu uživatel zvolí šablonu a program podle ní vytvoří hlavičku dokladu do níž předvyplní některé údaje převzaté z rozpracovaného řádku bankovního výpisu.

    V dosavadní verzi vznikal problém s datem uskutečnění zdanitelného plnění, které program automaticky nepředvyplnil, přitom ale pro uložení dat je to nutná podmínka, došlo k patové situaci.

    Nyní program datum peněžní operace použije nejen pro přednastavení data uskutečnění operace, ale i pro přednastavení DUZP.

  • Při zdanění zálohy může nyní uživatel lépe ovlivnit období DPH ve kterém bude DPH vykázána  >>>

    Dosud se datum uplatnění DPH automaticky nastavilo podle data platby, které uživatel nastavil v dialogu pro zdanění.

    Nyní program také podle datumu určí období uplatnění DPH, ale zobrazí jej v comboboxu v dialogu a uživatel jej může v případě potřeby změnit.
    Hlavní význam to má u poskytnutých plateb (přijatých ZL), když je např. datum platby v posledních dnech měsíce (DUZP), ale odpočet DPH je potřeba provést až v následujícím měsíci, kvůli datu vystavení nebo obdržení daňového dokladu o přijaté platbě. Nebo prostě jen proto, že chcete a máte tu možnost ze zákona.

  • Vytvořena podpora automatické tvorby ZL na nezaplacenou část ZL během jeho zdanění  >>>

    V praxi nastávají situace, kdy je ZL zaplacen pouze částečně, ale je potřeba ho zdanit dřív, než bude doplacen zbytek, přičemž se očekává, že k doplacení později skutečně dojde.
    V tom případě je potřeba na nedoplacenou částku vytvořit nový ZL, protože ZL je možné zdanit pouze 1x.
    Aby vytvoření nového ZL (na neuhrazenou částku) nemusel uživatel provádět ručně, bylo upraveno chování Kaskády během zdaňování zálohových listů.

    V dialogu Zdanění zálohy program porovná požadovanou a zaplacenou částku a pokud je zaplacená menší, tak uživateli zobrazí zaškrtávací pole, které umožní uživateli říci, zda program má nebo nemá během zdanění odštípnout nezaplacenou částku do nového ZL.

    Pokud je odštěpení požadováno, pak po úspěšném zdanění je nově vytvořený ZL, který vznikl kopií zdaňovaného ZL jen s částkou rovnající se nedoplatku, uživateli zobrazen aby ho mohl prověřit a případně upravit a pak samozřejmě vystavit.

  • Administrátor mail-systému může umožnit komukoliv odpovídat na kteroukoliv zásilku (e-Mail) Detail

    Kaskáda pro povolení/zakázání činnosti Odpovědět na zásilku provádí kontextovou kontrolu a (zjednodušeně řečeno) umožňuje odpovídat na příchozí zásilku pouze tomu uživateli, kterého lze považovat za příjemce příslušné zásilky.

    Nyní lze v rámci firemní kultury a pravidel komunikace nastavit v konfiguraci mail-systému, že pro výše uvedenou kontrolu má program za "příjemce" považovat každého, kdo má k zásilce přístup (např. díky skupinovému vlastnictví zásilky).

    Pokud tuto možnost využijete, pak může prakticky každý uživatel odpovídat na každou zásilku, která je mu dostupná.

  • Pro automatické mazání "volných" zásilek lze rozhodnout, zda propojení s přílohou způsobí NEsmazání Detail

    Celá tato záležitost se týká automatického mazání zásilek při nočním úklidu, a to takových, které okolo sebe nemají žádné aktuální (platné v tomto čase) propojení.

    Dosud

    • Existoval jediný typ propojení, který se z hlediska rozhodnutí o mazání ignoroval, a to Zásilka je odpovědí na jinou zásilku.
      Důvodem je samozřejmě to, aby se zásilky vzájemně neblokovaly proti automatickému smazání po vypršení expiračních časů propojení na odesílatele a příjemce.

    • Propojení Objekt je přílohou zásilky je považováno za stejné jako ostatní, tedy brání automatickému smazání.
      Projevuje se to tak, že např. zásilka, prostřednictvím které odešlete fakturu, se nikdy automaticky nesmaže, protože propojení s fakturou tomu brání.

    Nyní

    • Chování lze konfigurovat, výchozí stav je takový, jak odpovídá dosavadnímu chování.

    • Pokud v konfiguraci mail-systému určíte, že toto propojení nemá bránit automatickému smazání, uvolníte tím více prostoru v databázi, protože určitá část zásilek, které nyní zůstávaly, bude smazána.

  • Při tvorbě hromadné zásilky je umožněno propojení kontaktů bez e-mailové adresy s papírovým dopisem jako adresáty  >>>

    Doposud

    Při vzniku nové "hromadné zásilky" např. z plovoucího menu nad složkou, program doplnil takové adresáty, které

    • měli výchozí e-mailovou adresu,

    • jinak se použilo faxové číslo, pokud to uživatel v dialogu "Způsob adresace" na počátku činnosti povolil a daný kontakt měl zadané faxové číslo.

    ALE pokud nebyl faxový systém používán nebo kontakty neměly faxové číslo nebo uživatel nechtěl fax použít, pak kontakty bez e-mailové adresy zůstali "mimo hru".

    Nyní

    Pokud není v systému provozována faxová kumunikace, pak

    • v dialogu "Způsob adresace" při spuštění činnosti je umožněno zaškrtnutím pole "Bez eMail-adresy propojit s papír. dopisem" požadovat propojení kontaktů bez e-mailové adresy s papírovým dopisem,

    • pokud je výše zmíněná volba zaškrtnuta, pak při plnění adresátů program v okamžiku, kdy poprvé vznikne taková potřeba, zobrazí dialog pro zvolení papírového dopisu (s nímž se budou propojovat).

  • Jsou vylepšeny tiskové sestavy s daty pro roční vyúčtování DZP  >>>

    Jde o tiskové sestavy v modulu MZDY

    • Rekapitulace / Sumáře podle měsíců / Podklady pro daň z příjmů
    • Rekapitulace / Sumáře podle zaměstnanců / Podklady pro daň z příjmů

    I v dosavadní verzi Kaskády zde byly potřebné informace, ale nebyly uspořádány optimálně a zřetelně tak, aby se podle nich dal co nejsnáze vyplnit formulář na webu finanční správy, kterým organizace realizuje vyúčtování daně z příjmu ze závislé činnosti svých zaměstnanců za uplynulý rok.

    V aktuální verzi Kaskády jsou informace přeuspořádány, některé nadbytečné sloupce jsou vypuštěny a místo nich jsou zde takové sloupce (vyznačené barevným podkladem), které vedou přímočaře k vyplnění formuláře na webu finanční správy.

  • Roční vyúčtování DZP 2016 - načtení daňových zvýhodnění za druhé a další dítě  >>>

    Ve funkci, která inicializuje data ročního vyúčtování DZP u jednotlivých zaměstnanců, se nenačítaly údaje o daňových zvýhodněních za druhé a další dítě.
    Důvodem byla atypická situace v roce 2016, kdy se sazby měnily během roku a data tedy neodpovídala původním předpokladům.

    Pokud tedy chcete navýšení zpětně uplatnit, je potřeba v ročním vyúčtování daně u druhého, třetího a dalšího dítěte doplnit do sloupečku "Doplněno" patřičnou částku, která slevu na dani povýší.
    Hodnota slevy na 2. dítě za rok 2016, pokud je řádně uplatněna ve všech měsících, musí dát v součtu sloupců "Vypočteno" a "Doplněno" 17.004,- Kč a na 3. a další dítě 20.604,- Kč.
    Pokud jsou děti držiteli průkazu ZTP tak je potřeba částky násobit dvěma.

    Příklad 2. dítě:
    Vypočteno bude 16.604,- Kč a Doplněno 400,- Kč což je v součtu 17.004,- Kč

    Pokud jste již data ročního vyúčtování inicializovali a příslušná zvýhodnění v nich chybí, nestalo se nic fatálního. Stačí po instalaci nové verze znovu spustit nad příslušným zaměstnancem inicializaci dat a provést výše zmíněné.

  • MZDY - Změny od roku 2017  >>>

    S rokem 2017 nenastávají žádné systémové změny v oblasti mezd, pouze se jako každý rok mění hodnoty některých parametrů.
    Pro uživatele z toho nevyplývá žádná práce, hodnoty nových parametrů se v systému automaticky nastaví při aktualizaci na tuto verzi Kaskády ( 17.01 ).

    Název parametru Kód parametru 2016 2017
    DPN - první redukční hranice vym.zákl DPN_PRV_RED_HR 157.68 164.85
    DPN - druhá redukční hranice vym.zákl DPN_DRU_RED_HR 236.43 247.10
    DPN - třetí redukční hranice vym.zákl DPN_TRE_RED_HR 472.68 494.20
    Max.vyměřovací základ SP za rok MVZ_LIMIT_ROK_SP 1 296 288.00 1 355 136.00
    Průměrný výdělek v nár.hosp. v 1-3 Q min.r. ZPS_PRUM_VYD_NH 25 903.00 27 000.00

    Minimální mzda k 1.1.2017:

    Název parametru Kód parametru 2016 2017
    Minimální mzda měsíční MIN_MZDA_MES 9 900.00 11 000.00
    Minimální mzda měsíční - invalidé MIN_MZDA_MES_INV 9 300.00 11 000.00
    Minimální mzda hodinová MIN_MZDA_HOD 58.70 66.00
    Minimální mzda hodinová - invalidé MIN_MZDA_HOD_INV 55.10 66.00
  • Byl vylepšen mechanismus exportu dat pro Intrastat  >>>

    Kaskáda umožňuje zadávat k produktům kódy celního sazebníku resp. kódy z číselníku kombinované nomenklatury, které jsou m.j. obsaženy v hlášení pro Český statistický úřad, tzv. Intrastat.
    Kódy v uvedeném číselníku i hlášení jsou dlouhé 8 míst.

    V Kaskádě je však možné zadat tyto kódy s délkou až 10 znaků. Toho lze využít různými způsoby. Např. rozdělením kódu na 3 lépe čitelné části ( "1234 56 78" ), což není zcela dobré řešení, protože do hlášení tento kód vstupuje bez mezer.
    Další možností je využít toto pole pro zadání kódů podle mezinárodního systému TARIC. Zde jde obvykle o 10 znaků dlouhé kódy. Prvních 8 znaků z tohoto kódu odpovídá kódu kombinované nomenklatury používané pro výkaz Intrastat. Lze tak výhodně jeden kód využít ke dvěma účelům.

    Aby bylo možné vytvořit řádný export s uvedenými daty ( kód rozdělený mezerami i kód delší než 8 znaků ), byla provedena tato úprava.
    Nově Kaskáda při provádění exportu dat do CSV souboru zbaví zadaný kód o mezery a z výsledného kódu použije maximálně prvních 8 znaků.

  • Bylo opraveno duplicitní zařazení některých účtů do rozvahy  >>>

    Během otevírání nového roku v Kaskádě dochází mimo jiné k vytvoření definic výkazů pro nově vytvářený rok a také k zařazení účtů z účtového rozvrhu nového roku do řádků těchto výkazů.

    Díky chybě v programu byly některé účty v rozvaze zařazeny na jeden a tentýž řádek 2x.
    Šlo o takové účty, které byly zařazeny do rozvahy proměnlivě - v závislosti na koncovém zůstatku. Typicky jde o účty účtové skupiny 34, ale i o některé další, které mají zařazení do výkazu závislé na svém zůstatku.
    V důsledku této chyby nebylo možné vygenerovat data rozvahy, protože HV zjištěný z řádků rozvahy nekorespondoval s HV zjištěným z výsledkových účtů.

    Tato úprava během aktualizace opravuje chyby v zařazení účtů do výkazů - duplicity v zařazení jsou odstraněny.
    Je také provedena úprava funkce, která toto chybné (zdvojené) zařazení účtů do výkazu způsobila. Příští otevírání nového období v Kaskádě již bude v pořádku.

  • Do znakového tisku účtenky byly doplněny informace týkající se EET  >>>

    Doposud byly informace o EET doplněny v rámci úpravy UPK-15-0056 pouze do tisku účtenky pro formát A4 a A5. Znakový tisk účtenky tyto informace postrádal.

    Nyní již figurují i v tisku účtenky VEGA ve znakovém režimu.

Javascript je neaktivní. (?)
Návštěv webu: 1626271.