ESO9 wiki

ESO 9 změny ve verzi 6.1 z 30.06.2020

Obecný klient

Změny v technologii .NET

• Obecný klient
  Doplněna možnost exportu STI do XLS s volbou "Jen Data".
  
  
• Obecný klient - Zobrazování menu
  Úprava zobrazování kontextových menu
  
  
• Obecný klient - Tooltip ikony konfigurace
  Nad ikonou konfigurace je v tooltipu zobrazován i název aktuální konfigurace (je-li nějaká)
  
  
• Obecný klient - Zakázané akce
  Zakázané akce se nezobrazují v kontextovém menu ani v toolbaru nového designu
  
  
• Obecný klient
  Opraveno zobrazování tlačítek ve filtru na záložce Rozšířený.
  
  
• Obecný klient
  Opraveno zobrazování logického operátoru na záložce Rozšířený při přepnutí ze Základního.
  
  
• Obecný klient - Upravená funkčnost vyhledávání
  Dialog vyhledávání po opakovaném spuštění udrží hodnotu. Dá se tak využít talčítko "Další"
  
  
• Obecný klient
  Opravena práce s tlačítky na záložce ruční filtr při výběru položek.
  
  
• Obecný klient - Položky akcí
  Přejmenování dialogu výběru položek / viditelnosti položek na výběr položek a akcí, viditelnost položek a akcí. Do dialogu v novém designu doplněna nová sekce umožŘující nastavit pořadí a viditelnost tlačítek na liště
  
  
• Obecný klient
  Do Stimulsoft sestav doplněna informace o sestavě. Klávesová zkratka CTRL+I nebo ikona "?" vpravo v toolbaru.
  
  
• Obecný klient
  Doplněno zobrazování kalendáře de jazyka uživatele.
  
  
• Obecný klient
  Informační hlášení důležitých událostí "barevné bubliny" se nyní zobrazují vpravo dole. Při práci s formulářem překrývali ovládací prvky formy na nedalo se s formulářem plnohodnotně pracovat.
  
  
• Obecný klient
  Opraveno zobrazování Labelu pole ve filtru, pokud Label obsahoval více url adres.
  
  
• Obecný klient
  Upraveno generování navigace ESO9. Při přihlášení se vynutí opětovné stažení menu a činností. Tím se dosadí aktuální pracovní období.
  
  
• Obecný klient
  Doplněna nová evidence Widgetů a dashbordů. Nyní je možné definovat widgety a dashbordy podobně jako sestavy v databázové struktuře. Je možný jejich export a import nebo kopie. přímo v evidenci je možné provádět jejich náhled, pro kontrolu správnosti vyplněných parametrů. Při distribuci verze se prování jejich synchronizace s DB eso9start stejně jako u sestav.
  
  
• Obecný klient
  Doplněno ukládání stromu činností při kliknutí na činnost. po otevření činnosti se strom "odroloval" k první činnosti. Nyní zůstává v pozici, kde byl naposled.
  
  
• Obecný klient
  Doplněno zobrazení navigace (menu a strom činností) při tisku sestavy PrintDest=STIPDF
  
  

Mobilní aplikace ESO9 Start - čtečky

Změna činnosti

• Prodej - Přímý prodej
  Nová činnost "Prodej": podpora přímého prodeje. Činnost umožŘuje postupné zakládání složek prodejky dle čárkového kódu a množství zboží. Hlavička dokladu buďto již existuje (pořízena v ESO9) nebo se založí přímo v této činnosti. Doklad lze uzavřít akcí "Vše prodáno"
  
  Spolu s tím byly provedeny toto úpravy:
  - SQL:
  - upraven "ESO9Sklad\SQL\NEWSQL.BAT": vytváří celkový skript "ESO9SKLAD_CTECKY.sql"
  - nový parametr "PRIMYPRODEJ_SKLADY": seznam skladů přímého prodeje
  - nový parametr "PRIMYPRODEJ_TYPDOK": Typ dokladu přímého prodeje
  - nový parametr "PRIMYPRODEJ_VZORY": seznam vzorů dokladů přímého prodeje
  - nový parametr "PRIMYPRODEJ_STAVEND": stav dokladu přímého prodeje který se nastaví po ukončení prodeje
  - nová provedura spTCTECKY_Param: obsahuje původní a výše uedené nové parametry
  - nová obecná funkce "fnTOBECNE_GetVZOR"
  - nová obecná funkce "fnTOBECNE_GetSUBJEKT"
  - nová obecná funkce "fnTOBECNE_GetSKLAD"
  - nová obecná funkce "fnTOBECNE_GetZBOZSKL"
  - nová funkce "fnTPRIMYPRODEJ_GetSKLAD"
  - nová provedura "spTPRIMYPRODEJ_GetSKLAD"
  - nová provedura "spTPRIMYPRODEJ_GetVZOR"
  - nová provedura "spTPRIMYPRODEJ_GetHDOK"
  - nová provedura "spTPRIMYPRODEJ_GetSUBJEKT"
  - nová provedura "spTPRIMYPRODEJ_SetHDOK"
  - nová provedura "spTPRIMYPRODEJ_GetZBOZSKL"
  - nová provedura "spTPRIMYPRODEJ_SetSDOK"
  - nová provedura "spTPRIMYPRODEJ_SetVSEPRODANO"
  
  - WEB:
  - oprava formy "ESO9Sklad\Uvod": doplněna nová činnost
  - oprava formy "ESO9Sklad\esoframe": doplněna nová činnost
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\01PRIMYPRODEJ_SKLAD"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\01PRIMYPRODEJ_SKLAD"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\01PRIMYPRODEJ_SKLAD"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\05PRIMYPRODEJ_VZOR"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\05PRIMYPRODEJ_VZOR"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\10PRIMYPRODEJ_CISDOK"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\10PRIMYPRODEJ_CISDOK"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\10PRIMYPRODEJ_CISDOK"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\15PRIMYPRODEJ_SUBJEKT"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\15PRIMYPRODEJ_SUBJEKT"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\15PRIMYPRODEJ_SUBJEKT"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\20PRIMYPRODEJ_SETHDOK"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\20PRIMYPRODEJ_SETHDOK"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\50PRIMYPRODEJ_EAN"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\50PRIMYPRODEJ_EAN"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\50PRIMYPRODEJ_EAN"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\60PRIMYPRODEJ_MN"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\60PRIMYPRODEJ_MN"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\60PRIMYPRODEJ_MN"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\70PRIMYPRODEJ_VSEPRODANO"
  - nová forma "ESO9Sklad\prodej\PRIMYPRODEJ\70PRIMYPRODEJ_VSEPRODANO"
  
  

Aplikace ESO9 Start

Změna činnosti

• Obecné - Práce s " DB"
  Doposud byla definována " DB" pouze parametrem "DB_START". To vyžadovalo, že " DB" musela ležet na stejném SQL serveru jako "produkční" databáze. Nově může ležet " DB" i na jiném SQL serveru. Podmínkou je existence "Linked Serveru" na SQL server kde leží " DB". Jméno "Linked Serveru" je zapsáno v novém parametru "lnkDB_START". Spolu s tím byly přepsány / vytvořeny následující objekty:
  - nový parametr "lnkDB_START": Název lnk serveru (Linked Serveru), kde leží DB. Standardně je prázdný.
  - nová funkce "fnJmeno_lnkStartDB": vrací hodnotu parametru "lnkDB_START"
  - nová funkce "fnJmenoAll_StartDB": ze vstupních parametrů sestavuje "cestu" [].[] k " DB" tak, aby se mohly volat objekty " DB" databáze
  - nová procedura "spLNKStartDB_CreateObjects": vytváří objekty na základě parametrů "lnkDB_START", "DB_START". Procedura se standardně volá při spuštění verzového skriptu.
  Vytváří se tyto objekty:
  - funkce fnLNK_DBID
  - nová funkce "fnLNK_DBID": obdoba funkce DB_ID(). Vrací id databáze umístěné na LINKED Serveru definovaném parametrem "lnkDB_START". Vytváří se při spuštění verzového skriptu v rámci procedury spLNKStartDB_CreateObjects.
  - skript pro tvorbu pohledu "qslovnik_eso9start": volá se při spuštění verzového skriptu
  - skript pro tvorbu pohledu "QNazevUO_Eso9Start": volá se při spuštění verzového skriptu
  - procedura "spAktualizujQDatovyModelStart"
  - procedura "spAktualizujDatovyModel"
  - procedura "spSestava_PohledyDoStart"
  - procedura "spSestava_ZalozDleStart"
  - procedura "spSestava_UpdateDleStart"
  - funkce "fnSestava_PorovnejDleStart"
  - procedura "spSestava_AllPodleEso9Start"
  - procedura "spUZIVOBJ_KontrolaDB"
  - procedura "spUZIVOBJ_VypisStdView"
  - procedura "spVerze_AkcePredSpustenim"
  - procedura "spCINNOST_Kontrola"
  - procedura "spCINNOST_KontrolaAktPriloh"
  - procedura "spCINNOST_KontrolaOznProProp"
  - procedura "spCinnost_KontrolaAutProp"
  - procedura "spCinnost_KontrolaOznNove"
  - procedura "spCinnost_KontrolaZalozNove"
  - procedura "spCinnost_KontrolaAktOzn"
  - procedura "spMIS_PohledyDoStart"
  - procedura "spMIS_ZalozDleStart"
  - procedura "spMIS_UpdateDleStart"
  - procedura "fnMisUkazatel_PorovnejDleStart"
  - procedura "spMIS_AllPodleEso9Start"
  - procedura "spMIS_OznPodleEso9Start"
  - procedura "spNazevUO_AktDleEso9Start"
  - procedura "spSestavy_Legislativni"
  - procedura "spUcetniVykaz_PodleStart"
  
  

Účetnictví

• 1. 1. 1. 2 - Účetní operace
  Do formuláře účetního zápisu doplněna položka "Pořadí účetního zápisu".
  Upraveny stránky :
  - ESO9Start\ucet\QUcZa_IncPKP.htm
  - ESO9Start\ucet\QUcZa_Inc.htm
  - ESO9Start\saldo\DokladZapoctu.htm
  - ESO9Start\majetek\MajPoh.htm
  - ESO9Start\nakup\SplKalFaP.htm
  - ESO9Start\prodej\SplKalFav.htm
  
  Na těchto formulářích bylo provedeno doplnění položky Por_Ucet_Zapisu do datového zdroje formy :
  - ESO9Start\finance\Pd_Vyd_val.htm
  - ESO9Start\finance\Pd_Vyd.htm
  - ESO9Start\finance\Pd_Vse.htm
  - ESO9Start\finance\Pd_Prij_Val.htm
  - ESO9Start\finance\Pd_Prij.htm
  - ESO9Start\finance\BaV_Radek.htm
  - ESO9Start\finance\BaV.htm
  - ESO9Start\nakup\FapHlav.htm
  - ESO9Start\ucet\Ucet_dokl.htm
  - ESO9Start\ucet\QUcZa.htm
  - ESO9Start\ucet\PreuctVynosu.htm
  - ESO9Start\ucet\Inter_dokl_DPH.htm
  - ESO9Start\ucet\Inter_dokl.htm
  - ESO9Start\ucet\DoklHlav.htm
  - ESO9Start\ucet\QUcZa_KR.htm
  - ESO9Start\saldo\DokladZapoctu.htm
  
  - ESO9StartPL\Finance\BaV.htm
  - ESO9StartPL\Nakup\FapHlav.htm
  
  - ESO9StartSK\Finance\Pd_Vyd.htm
  - ESO9StartSK\Finance\Pd_Prij.htm
  
  
• 1. 1. 2. 3 - Výkaz DPH (legislativa PL)
  Ve formuláři výkazu DPH (ESO9StartPL\DPH\OdvodDPH.htm) doplněna možnost zadání hodnoty vratky DPH a volba řádku 58-61.
  Pokud je zadána částka vratky DPH, pak se ve výkaze uvede do zvoleného řádku a v řádku 62 bude rozdíl mezi řádky 56-57. Pokud by zadaná částka vratky byla vyšší než hodnota v řádku 56 (daŘová povinnost), vezme se hodnota z řádku 56.
  
  Provedené změny v SQL :
  - Tabulka ODVODDPH byla doplněna o položky HDVRATKADPH a VLVRATKADPH,
  - Upravena funkce pro tisk výkazu DPH fnDphVykaz_PL_2017_01,
  - Doplněn FCHANGE a procedura spOdvodDPH_FC_hdVratkaDPH
  - Upraven trigger trOdvodDPH_Upd
  
  
  Do číselníku kódů pro výkaz DPH byl doplněn nový kód 84 - Mechanizm podzielonej płatności (poz. 69).
  Pokud je na některém dokladu vstupujícím do výkazu DPH použit tento kód 84, pak bude ve výkaze DPH zaškrtnut řádek 69.
  
  
• 1. 1. 2. 3 - Výkaz DPH - souhrnné hlášení pro legislativu PL
  Doplněno "Souhrnné hlášení". Zde je možno provádět tyto hlavní akce:
  - "Proveď odvod SH"
  - "Zruš odvod SH"
  - "Vytvoř export XML" s uložením XML na disk "Vytvoř export XML"
  Spolu s tím provedeno:
  - nová funkce fnODVODDPH_SH_PL
  - nová funkce fnSH_TestovaniChybPL
  - nová funkce fnSH_STI_HlavickaPL2020_RADKYDPH
  - nová funkce fnSH_STI_RadkyPL2020_RADKYDPH
  - nová procedura spExport_SH_XML_PL2020
  - nová sestava SH_PL2020_RADKYDPH
  - nová IDC/HTX sestava DPH\Vykaz_SH_TiskPL.idc/htx
  - nová forma "DPH\OdvodSH_Detail.htm": detail SH s těmito odkazy
  - odkaz "Dokumenty"odkaz na formu "DPH\OdvodSH_Doc.htm"
  - sestava "Pracovní sestava": zde se volá nová IDC/HTX sestava DPH\Vykaz_SH_TiskPL.idc/htx
  - sestava "Kontrolní sestava": zde se nová sestava SH_PL2020_RADKYDPH
  - forma "DPH\OdvodDPH.htm": doplněna sekce "Souhrnné hlášení" s těmito odkazy
  - odkaz "Detail": odkaz na novou formu "DPH\OdvodSH_Detail.htm"
  - odkaz "Dokumenty"odkaz na formu "DPH\OdvodSH_Doc.htm"
  - sestava "Pracovní sestava": zde se volá nová IDC/HTX sestava DPH\Vykaz_SH_TiskPL.idc/htx
  - sestava "Kontrolní sestava": zde se nová sestava SH_PL2020_RADKYDPH
  
  
• 1. 1. 2. 3 - Výkaz DPH - souhrnné hlášení pro legislativu PL
  Upraveny procedury a funkce pro tvorbu podkladů pro výkaz DPH a souhrnné hlášení.
  NaplŘování kódu SH v tabulce KHDPH se provádí na základě řádku výkazu DPH a kódu pro výkaz DPH takto :
  - řádek výkazu DPH 21, kód DPH 40 --> 0 (dodání zboží do EU)
  - řádek výkazu DPH 21, kód DPH 41 --> 1 (dodání zboží do EU třístranným obchodem)
  - řádek výkazu DPH 23, kód DPH 60, 62, 621 --> 2 (pořízení zboží z EU)
  - řádek výkazu DPH 23, kód DPH 61 --> 3 (pořízení zboží z EU třístranným obchodem)
  - řádek výkazu DPH 12, kód DPH 21 --> 4 (dodání služby do EU)
  
  Upravené funkce a procedury :
  - fnHDOK_DetailVykazuDPH_PL_std
  - fnHDOK_DetailVykazuDPH_PL
  - spODVODDPH_ZalozHlavicky
  - spHdok_VytvorDetailDPH_PL
  - fnDPH_STI_HlavickaPL2019
  - spOdvodDPH_XML
  - fnRejestrVAT
  
  Do stránky ESO9StartPL\DPH\OdvodDPH.htm doplněn odkaz "Dodání služeb" na sestavu RejestrVAT s parametrem Rejestr=6, upravena sestava RejestrVAT.
  
  
• 1. 1. 2. 3 - Výkaz DPH - souhrnné hlášení (legislativa CZ)
  Úpravy spojené s novým režimem v DPH - call-off stock
  - úprava objektů které zohledŘují nové Kódy SH (C - call-of stock; D - call-of stock - vrácení zboží)
  - funkce fnODVODDPH_SH
  - funkce fnSH_STI_RadkyCZ2018_RADKYDPH
  
  - procedura spExport_SH_XML_CZ201701: zajišťuje tvorbu XML v novém formátu do období 2019.12 včetně. Vybírá záznamy, které NEMAJÍ Kódy SH (C - call-of stock; D - call-of stock - vrácení zboží)
  
  - nová procedura spExport_SH_XML_CZ202001: zajišťuje tvorbu XML v novém formátu od období 2020.01 včetně. Volá se tlačítkem "Vytvořit export XML"
  
  - procedura spOdvodDPH_XML: doplněno volání spExport_SH_XML_CZ202001 od období 2020.01 včetně.
  
  
• 1. 1. 2. 3 - Výkaz DPH - souhrnné hlášení (legislativa CZ)
  Úpravy pro "Call-off stock":
  - upravena funkce fnHDOK_DetailVykazuDPH_std pro tvorbu podkladů pro souhrnné hlášení.
  - upravena procedura spOdvodDPH_XML - doplněno volání procedury spExport_SH_XML_CZ202001 pro export SH od období 2020.01
  
  
• 1. 1. 2. 1 - Hlavní kniha
  U sestav, které se tisknou ve formátu nekonečné stránky (STIMHT), bylo u číslování stránek nastaveno, že se nebude tisknout.
  V událostech před tiskem položky doplněno např :
  if (Page1.UnlimitedHeight)
  Text36.Enabled = false;
  else
  Text36.Enabled = true;
  
  Upraveny sestavy :
  Eso9Start (CZ) : RozpisDPH_CZ_2016, Hl_kniha_Str_syn.idc, Hl_kniha_ob_det, Hl_kniha_ks_det
  Eso9StartSK : RozpisDPH_SK_2018, Hl_kniha_Str_syn.idc, Hl_kniha_ob_det, Hl_kniha_ks_det
  Eso9StartHU : Hl_kniha_ks_det, Hl_kniha_ob_det, Hl_kniha_ob_det_protiucty, Hl_kniha_Str_syn.idc
  Eso9StartPL : RozpisDPH_PL_2016, Hl_kniha_ks_det, Hl_kniha_ob_det, Hl_kniha_Str_syn.idc,
  Eso9StartDE : Hl_kniha_ks_det, Hl_kniha_ob_det, Hl_kniha_Str_syn.idc
  
  
• 1. 1.10. 1 - Generowanie JPK FA (PL)
  Doplněno generování tagu P_12, kam se uvádí procento DPH. V případě "Mimo daŘ" nebo kódů 40, 41, 50, 21 se uvádí "np" - niepodlegające opodatkowaniu, v případě kódu 83 se uvádí "oo" - odwrotne obciążenie.
  Upravena funkce fnGetXML_JPKFA
  
  
• 1. 1. 2. 3 - Výkaz DPH
  Pokud se provedla změna cyklu vykazování výkazu DPH (KH DPH, SH) z čtvrtletního na měsíční cyklus (nebo naopak), a již existovaly hlavičky výkazu DPH (KH, SH) pro období, kde nastala změna, pak se tato změna nepromítla do již dříve založených hlaviček výkazů.
  Nyní byla provedena taková úprava, že pokud se při přípravě výkazu zjistí tato skutečnost, pak se provede aktualizace neuzavřených výkazů. Pokud dojde ke změně z měsíčního na kvartální, tak se "nepotřebné" hlavičky výkazu (prvního a druhého měsíce kvartálu) zruší, případné existující doklady přiřazené pod tyto rušené hlavičky přesune pod hlavičku posledního měsíce kvartálu. Při změně z kvartálního na měsíční se pro všechny záznamy původně patřící do kvartálního výkazu vazba na původní (kvartální) hlavičku výkazu zruší a provede se nové přiřazení pod příslušný měsíc.
  Tato kontrola a případná změna se provádí pouze pro období, která jsou vyšší než nejvyšší uzavřené období výkazu DPH (KH DPH, SH),
  Upravena procedura spODVODDPH_ZalozHlavicky.
  
  
• 1. 1. 2. 3 - Výkaz DPH (legislativa PL)
  Do číselníku kódů pro výkaz DPH doplněn nový kód 84 - Mechanizm podzielonej płatności (poz. 69)
  Na základě existence tohoto kódu v některém dokladu (případně složce vstupujícího do DPH), se ve výkazu DPH nastaví příznak v řádku 69.
  Upravena procedura spProVykazDPH_PL, fnDPH_STI_HlavickaPL2019, sestava VykazDPH_PL_2019_11
  
  
• 1. 1. 2. 3 - Výkaz DPH
  Upravena sestava VykazDPH_JineObd - doplněn výpis účetních zápisů dodatečných daŘových přiznání, které jsou účtovány na interních dokladech odvodu DPH v následujících obdobích.
  
  
• 1. 1. 4. 5 - Výsledovka (PL)
  V Eso9StartPL chyběla sestava Vysl_Str_Obdobi (Výsledovka dle období)
  Sestava Vysl_Str_Obdobi zkopírována z CZ verze, proveden překlad sestavy.
  
  
• 1. 1. 2. 3 - Výkaz DPH
  Pokud se provede zrušení hlavičky výkazu DPH (kontrolního hlášení, souhrnného hlášení), provede se současně i zrušení hlaviček ostatních výkazů (DPH / Kontrolní hlášení / Souhrnné hlášení) pro stejné období a pořadí výkazu.
  Upravena procedura spODVODDPH_DelRec,
  Upravena stránka DPH\OdvodDPH.htm - doplněn refresh ostatních forem při zrušení záznamu
  
  
• 1. 1. 4. 5 - Výsledovka
  Upravena sestava výsledovky - původní datový zdroj vytvářený pomocí funkce byl nahrazen procedurou.
  Upravena STI sestava Vysl_str.idc, nová procedura spVysledovka.
  
  
• 1. 1. 2. 1 - Hlavní kniha
  Upraven datový zdroj ve stránce ucet\Hl_kniha_Str_syn.htm - jako jazyk pro tisk sestavy se nyní nabízí defaultní jazyk uživatele.
  
  

Finance

• 1. 2. 2. 1 - Pokladní příjmy
  Odkaz Doklady k úhradě - výsledná hodnota pokladního dokladu ve valutě odpovídala přesné hodnotě připárovaných dokladů. V případě, že tyto doklady byly například na haléře, tak vzniklý pokladní doklad byl rovněž zaokrouhlen na haléře bez ohledu na to, jak bylo nastaveno zaokrouhlení příslušného typu dokladu.
  Nyní se pro připárování provede zaokrouhlení výsledného pokladního dokladu dle aktuálního nastavení (dle typu, vzoru, měny apod).
  Upozornění - zaokrouhlení se provádí na konci akce "Uhradit označené doklady". V případě, že by se k pokladnímu dokladu opakovaně přidával vždy jen jeden označený doklad, může dojít k nežádoucí kumulaci zaokrouhlovacích rozdílů - je tedy vhodné označit všechny požadované doklady a akci "Uhradit označené doklady" provést pouze 1x nad několika současně označenými doklady (součet jednotlivých zaokrouhlených částek může být jiný než zaokrouhlený součet přesných částek).
  Upravena procedura spHDok_PoklDleUZap_Ozn.
  
  
• 1. 2. 1.13 - Tvorba inkasního příkazu
  Vytvořena nová definice pro export inkasních příkazů dle XSD schématu pain.008.001.02.
  V bance je třeba nastavit definiční soubor pro inkaso na InkSepaDD - Inkaso XML SEPA Direct Debit (SDD), nebo ho zvolit před exportem inkasních příkazů.
  Nová procedura : spDFNBanka_InkSepaDD pro založení definičního souboru InkSepaDD (SDD)
  
  
• 1. 2. 1. 9 - Tvorba bankovní zástavy
  Při exportu bankovní zástavy pro KB (0100) se chybně exportovaly částky u dokladů s připojenou zálohou.
  Chyba byla v proceduře spBAVZastavaExport_0100, kde se do detailních řádků uváděla hodnota hdKuhradeVal+hdZalohaVal, ale do součtového se bralo pouze hdKuhradeVal.
  Procedura opravena.
  
  
• 1. 2. 1. 2 - Automatické vystavení platebního příkazu
  Tvorba PP se prováděla pomocí procedury spBaV_VytvorPP, kterou aplikační server volal opakovaně pro každý označený záznam a po jeho zpracování vždy provedl jeho odznačení. Pokud však došlo k chybě, nebyla možnost zpětně provést označení původních záznamů.
  Nyní byla vytvořena nová procedura spBaV_VytvorPP_XMLParams, která je volána aplikačním serverem pouze jednou, a pracuje s celou množinou označených záznamů současně. Odznačení zpracovaných záznamů se tak provádí pouze 1x a pouze v případě, že se neskončí chybou. V případě chyby tak zůstanou označeny všechny dříve označené záznamy.
  
  

Saldokonto

• 1. 3. 4. 7 - Přehled pohledávek podle zpoždění platby (doplněk č. 2 předchozí verze)
  V nové činnosti, která provádí zobrazení závazků a pohledávek dle spočtených hodnot v tabulkách HdokUhrada a HdokUhrDet, nebyl zohledněn zadaný filtr na středisko.
  Opravena procedura spSTI_ZavPohlDleSplatnosti_Data60.
  
  
• 1. 3. 1. 2 - Párování všech saldokont
  V případě, že spuštění automatického párování skončilo např. na TimeOut, mohlo dojít k tomu, že nastavení parametru HDOKUhrada_Online se změnilo z hodnoty 2 na hodnotu 1.
  Opraveny porocedury spPar_PriprUZapPar, spParovani_Auto, spParovani_AutoAll, spHdokUhrada_Prepocet_Online
  
  
• 1. 3. 4. 6 - Přehled závazků podle zpoždění platby (doplněk č. 2 předchozí verze)
  Do slovenské verze se nedostala SK verze sestavy ZavPohlDleZpozdeni2020 - doplněno.
  Sestava již byla součástí doplŘku č.2 (28.2.2020)
  
  
• 1. 3. 4 - Sledování závazků a pohledávek
  Do číselníku saldokont (tabulka Parovani) doplněna položka "Vstupuje do sestav závazků a pohledávek" (vlSestZavPohl), pomocí které je možno definovat, zda se mají účty zařazené do tohoto saldokonta zahrnout do sestav závazků a pohledávek. Standardně byla nastavena na ANO u všech saldokont s typem párování "dodavatelsko-odběratelské"(vlTypParovani=1).
  Je možno využít v případě, že je třeba zobrazit sestavy závazků a pohledávek bez některého konkrétního saldokonta (například je potřeba nezobrazovat platby z mezd apod.)
  Vlastnost "Vstupuje do sestav závazků a pohledávek" lze nastavit na ANO pouze u saldokont označených jako dodavatelsko-odběratelské, v opačném případě se vždy nastaví na hodnotu NE.
  
  Upraven pohled QParovani, procedury spParovani_NewRec, spParovani_CalRec
  Upravena stránka Nastaveni\Saldo.htm
  Upraveny datové zdroje (pohledy, funkce a procedury) pro sestavy v činnostech 1.3.4 (Sledování závazků a pohledávek) tak, aby do těchto sestav vstupovaly pouze saldokonta s nastavenou vlastností "Vstupuje do sestav závazků a pohledávek" :
  - QUcetZap_ZavPohl
  - fnZavPohl_Zakladni
  - fnPrn_ZavPohlKDatu
  - fnZavPohl60_SumDleSubj
  - spSTI_ZavPohlDleSplatnosti_Data60
  
  
• 1. 3. 2. 4 - Postoupení pohledávek
  Doplněna možnost tisku smlouvy a oznámení o postoupení pohledávky v jiném jazyce.
  Upraveny tiskové sestavy PostoupeniPohlSml a PostoupeniPohlOzn, doplnění nepřeložených frází do slovníku SK, DE a EN.
  
  Upraveny funkce (datové zdroje) :
  - fn_DZ_HdokPostPohledavky
  - fn_DZ_HdokPostPohledavkyOzn
  
  Upraveny stránky :
  - saldo\DoklObchPohl.htm
  - nastaveni\VyberLegFormSTI.idc
  
  
• 1. 3. 4 - Sledování závazků a pohledávek
  Činnosti 1.3.4.x, které měly v názvu "původní", byly ve START aplikacích všech legislativ nastaveny do stavu 10=zakázaná.
  V aplikacích zákazníků se toto automaticky nenastavuje.
  
  

Nákup

• 2. 1. 3. 6 - Složky skladové příjemky do faktury přijaté
  Přepracovaný datový zdroj i design tak, aby bylo vidět jaký typ a vzor příjemky a faktury přijaté se zpracovává. Upravena předloha "nakup\SpuDoFaP.htm".
  
  
• 2. 1. 3. 7 - Složky nákupní objednávky do faktury přijaté
  Přepracovaný datový zdroj i design tak, aby bylo vidět jaký typ a vzor objednávky a faktury přijaté se zpracovává. . Upravena předloha "nakup\NobDoFaP.htm".
  
  
• 2. 1. 3 - Faktury přijaté
  Zobrazení uhrazené částky bylo řešeno tak, že v pohledu QHDOK_FAP byla položka HdokUhrada.hdUhrazenoVal a ve formuláři faktury přijatých pak byl použit TVIEW, ve kterém bylo "-hdUhrazenoVal as hdUhrazenoVal".
  V případě zobrazení dokladu přes historii se však používá pouze TVIEW=select * from QHDOK_FAP, a proto tam byla tato hodnota úhrady zobrazována s opačným znaménkem.
  
  Nyní byl pohled QHDOK_FAP upraven tak, že je v něm již položka s opačným znaménkem :
  -HdokUhrada.hdUhrazenoVal as hdUhrazenoVal
  a ve formuláři nakup\FapHlav.htm je pak už použita pouze položka hdUhrazenoVal (místo původního -hdUhrazenoVal as hdUhrazenoVal).
  
  
• 2. 1. 3. 1 - Faktury přijaté účetní - import z ISDOC
  Vytvořeny procedury spISDOC_HDOK_BEFOREINSERT, spISDOC_HDOK_AFTERINSERT, spISDOC_SDOK_BEFOREINSERT, spISDOC_SDOK_AFTERINSERT, které jsou standardně prázdné a lze je uživatelsky přepsat.
  Tyto procedury se mohou volat při importu z ISDOC při zakládání hlaviček a složek procedurami spISDOC_HDOKimport a spISDOC_SDOKimport - názvy volaných procedur musí být uvedeny v nových parametrech (@mf_HDokBeforeInsert, @mf_HDokAfterInsert / @mf_SDokBeforeInsert, @mf_SDokAfterInsert) těchto procedur.
  Procedury "before" se volají na začátku procedury a mají parametry shodné jako spISDOC_HDOKimport / spISDOC_SDOKimport. Parametry musí mít vlastnost "OUT" (kromě @idHdok v proceduře spISDOC_SDOK_BEFOREINSERT).
  Procedury "after" se volají na konci procedury (po založení HDOKu/SDOKu) a jejich parametrem je pouze @idHdok/@idSdok nově založené hlavičky/složky dokladu.
  
  Upravena stránka Nastaveni\ImportISDOC.htm - doplněny mf-položky s názvy volaných procedur.
  
  
• 2. 1. 3. 2 - Faktury přijaté zálohové
  Na stránce FPZ (zkrácené hlavičce) doplněno "Jejich číslo faktury" (na 2. řádek pod číslo dokladu), položka VS posunuta hned za tuto položku.
  Upraven formulář nakup\ZFap.htm.
  
  
• 2. 1. 3. 1 - Faktury přijaté účetní - samovyměření DPH (legislativa PL)
  Legislativa PL - upraven výpočet DPH prováděný na tlačítko „Provést samovyměření DPH“.
  Výpočet kursu se provádí buď dle data vystavení (včerejší) nebo data zdanitelného plnění (včerejší) v závislosti na tom, zda se jedná o zahraniční subjekt (za zahraniční se považuje, pokud má subjekt vyplněn kód státu a ten není „PL“) a zda se jedná o zboží nebo službu :
  - pro domácí subjekt se použije kurs předcházející datu (=včerejší) nižšího z dat (zdanitelné plnění / datum vystavení)
  - pro zahraniční subjekt se v případě zboží použije kurs předcházející datu vystavení a v případě služby kurs předcházející datu nižšího z dat (zdanitelné plnění / datum vystavení)
  
  Výše uvedené se použije pouze v případě, že bylo zvoleno „ze složek“. Pokud se provádí při volbě „z hlavičky základní/snížená …“, pak se předpokládá, že je o fakturu za zboží.
  
  

Prodej

• 2. 2. 3 - Faktury vydané (legislativa PL)
  Na fakturách vydaných není položka MF_NEANODUPLIKAT v datovém zdroji, takže pokud se nenastavila hodnota ANO, tak se při tisku se použila hodnota NULL, na faktuře se tiskla informace, že se jedná o duplikát.
  Upravena stránka Include\Duplikat_inc.htm, u hodnoty 0 (Ne) nastavena vlastnost "selected".
  
  
• 2. 2. 3. 2 - Faktury vydané zálohové
  Pokus se při tvorbě daŘového dokladu z FVZ použilo tlačítko "dle označených účetních zápisů", do složky FVZD se doplnil informativní text obsahující číslo zálohového dokladu (FVZ) a informace o tom, jakými doklady byla úhrada provedena (což se následně tisklo na tiskovém formuláři FVZD).
  
  Pokud však FVZD vznikala "dle složek dokladů", tato informace se do vznikajících složek nezapisovala a tedy ani netiskla.
  
  Upravena procedura spHDok_FVZ_FVZD - do složky vytvářené faktury (FVZD) se doplní text obdobně jako v případě, když FVZD vzniká na základě účetních zápisů , např :
  Záloha 0820030003, úhrada zálohy byla provedena :
  10.03.2020 PDP 1P200009 17000.00 CZK
  15.03.2020 PDP 1P200010 13000.00 CZK
  
  V případě, že vznikající FVZD má právě jednu složku, pak se text doplní přímo do této složku. Pokud by neměla žádnou složku, nebo naopak více než jednu složku (závisí na původní FVZ a na zvolených parametrech), pak se založí nová složka typu "ostatní", která bude obsahovat tento text o provedených úhradách.
  
  
• 2. 2. 3. 2 - Faktury vydané zálohové
  Do stránek přijatých a vydaných zálohových faktur doplněna informace o provedené úhradě (příznak "Je uhrazeno", částka úhrady, datum poslední úhrady).
  Upraveny stránky nakup\ZFap.htm, prodej\ZFaV.htm.
  
  

Sklad

• 2. 3. 1. 6 - Vedlejší náklady vztažné
  Pokud se "Rozpouštění se provádí na základě váhy" provádí dle Množství / Hmotnosti a hodnota složek dokladů (SDOK.HDCCENASPOCT) = 0, pak se nic nerozpustí. Důvodem bylo to, že rozpuštění VN se zúčastnily pouze složky (SDOK), které měly hodnotu SDOK.HDCCENASPOCT <> 0.
  Nově se rozpuštění zúčastní složky (SDOK) podle "Rozpouštění se provádí na základě váhy":
  - "Rozpouštění se provádí na základě váhy = Skladová hodnota": SDOK.HDCCENASPOCT <> 0
  - "Rozpouštění se provádí na základě váhy = Množství v základní MJ": SDOK.MNCELKEMPOCET <> 0
  - "Rozpouštění se provádí na základě váhy = Množství v MJ složky": SDOK.MNPOCETMJ <> 0
  - "Rozpouštění se provádí na základě váhy = Hmotnost": SDOK.MNCELKEMHMOTNOST <> 0
  
  Výše uvedené úpravy provedeny v procedurách spHDok_btMarkRozpustiVN, spSDok_btMarkRozpustiVN
  
  
• 2. 3. 3. 4 - Generování inventurních dokladů
  Sjednocena práce při Inventuře skladových zásob mezi šaržovým a ne-šaržovým skladem. Nový sloupec ZBOZSKL.VLINVSDOK tabulky "Zboží na skladě" je obdobou sloupce ZBOZSKLINV.VLINVSDOK tabulky "Zboží na skladě - inventura šarží".
  Oba sloupce se nastavují takto:
  - při akci "Příprava inventury - naplnění stavů" (činnost "2. 3. 3. 3 Zadání zjištěných inventurních stavů") na hodnotu VLINVSDOK = 0-Inventurní doklad NEZALOŽEN.
  - při akci "Vytvoření opravného dokladu" (činnost "2. 3. 3. 4 Generování inventurních dokladů") na hodnotu VLINVSDOK = 1-Inventurní doklad ZALOŽEN.
  
  Tím je zajištěno, že pokud se neprovede "Příprava inventury", nebo se již "Vygenerovaly inventurní doklady", pak se zboží na skladě / šarže nenabídne znovu k vytvoření inventurních dokladů i přesto, že je rozdíl mezi stavem a inventurním stavem (třeba smazáním již vytvořených inventurních dokladů, nebo ruční úpravou inventurních stavů).
  
  V případě, že byla inventura již provedena (Příprava inventury, Zadání inventurních stavů, Generování inventurních dokladů) je u zboží na skladu a šaržích nastaven stav "Doklad inventury = Založen". Pokud se zjistí, že je potřeba ještě dalších korekcí, je možno u zboží na skladě a šaržích nastavit stav "Doklad inventury = Nezaložen" tlačítkem "Nastavení stavu dokladu inventury". To umožŘuje "pokračovat" v inventuře tak, jako by nebyly vygenerované inventurní doklady.
  
  Spolu s tím upraveny následující objekty:
  - nová procedura spZBOZSKL_INVENTURA_SETVLINVSDOK: na všech zboží na skladě / šaržích daného skladu nastaví příznak ZBOZSKL.VLINVSDOK / ZBOZSKLINV.VLINVSDOK, zda byly/nebyly již založeny inventurní doklady.
  - procedura spZBOZSKL_INITINVENTURA: nastavuje hodnotu ZBOZSKL.VLINVSDOK = 0-inventurní doklad Nezaložen
  - procedura spZBOZSKL_RUNINVENTURA: nastavuje hodnotu ZBOZSKL.VLINVSDOK = 1-inventurní doklad Založen
  - činnost 2. 3. 3. 3 Zadání zjištěných inventurních stavů: upravena forma "sklad\InvPriprava.htm"
  - horní forma "Sklad - inventura":
  - nová akce-tlačítko "Nastavení stavu dokladu inventury": volá se nová procedura spZBOZSKL_INVENTURA_SETVLINVSDOK
  - doplněny informace o datumu a uživateli, který akci "Nastavení stavu dokladu inventury" naposledy spustil
  - prostřední forma "Zboží na skladě - zadání zjištěných inventurních stavů":
  - nová položka "Doklad inventury" 0-Nezaložen / 1-Založen: hodnota nového sloupce ZBOZSKL.VLINVSDOK
  - činnost 2. 3. 3. 4 Generování inventurních dokladů: upravena forma "sklad\InvDoklad.htm"
  - prostřední forma "Zboží na skladě s inventurním rozdílem":
  - nová položka "Doklad inventury" 0-Nezaložen / 1-Založen: hodnota nového sloupce ZBOZSKL.VLINVSDOK
  
  
• 2. 3. 1. 6 - Vedlejší náklady vztažné
  Provedeny následující úpravy
  - doplněna možnost zadat dodavatele vztažných vedlejších nákladů. Pokud je dodavatel zadán, pak se automaticky nastaví položka "Nový doklad = Ano"
  - ve druhé formy "Příjemka - účetní" zrušena kontrola, zda již existuje k příjemce doklad vztažných vedlejších nákladů. Tím je umožněno rozpouštět více vztažných vedlejších nákladů např. doprava, clo, kooperace..
  
  Spolu s tím upraveny tyto objekty:
  - nová funkce fnVzorHDok: vrací ID hlavičky vzoru. Obdoba procedury spVzorHDok
  - nová funkce fnVzorSDok: vrací ID složky vzoru. Obdoba procedury spVzorSDok
  - procedura spHDok_btMarkRozpustiVN: doplněn nepovinný parametr @MF_KOD_SUBJNEW VARCHAR(15) - dodavatel pro nově zakládaný doklad vztažných vedlejších nákladů
  - procedura spSDok_btMarkRozpustiVN: doplněn nepovinný parametr @MF_KOD_SUBJNEW VARCHAR(15) - dodavatel pro nově zakládaný doklad vztažných vedlejších nákladů
  - předloha sklad\VztazneVN.htm: zrušena kontrola, zda již existuje k příjemce doklad vztažných vedlejších nákladů. Upraveny datové zdroje tak, aby se předloha mohla, v případě potřeby, volat přímo z příjemky (např, profi-úprava v činnost 2. 3. 1. 1 Účetní příjemky)
  - předloha sklad\VztazneVNSDok.htm: zrušena kontrola, zda již existuje k příjemce doklad vztažných vedlejších nákladů. Upraveny datové zdroje tak, aby se předloha mohla volat přímo z příjemky (činnost 2. 3. 1. 1 Účetní příjemky)
  - předloha sklad\prijemkas.htm (činnost 2. 3. 1. 1 Účetní příjemky): do horní formy doplněn odkaz "Rozpouštění vedlejších nákladů"
  
  
• 2. 3. 1. 1 - Účetní příjemky
  Do horní formy doplněn odkaz "Rozpouštění vedlejších nákladů", který volá předlohu sklad\VztazneVNSDok.htm vyfiltrovaný pouze pro účetní příjemku.
  
  

Majetek

• 3. 5. 3 - Měsíční změny majetku (doplněk č. 1 předchozí verze)
  Při tisku do XLS došlo k chybě "Invalid column name ..."
  Upravena sestava MAJ353 - zrušeny sloupce, které již nejsou v datovém zdroji sestavy, ale zůstaly definovány ve sloupcích datového zdroje sestavy.
  Jednalo se o sloupce 'Filtr_Obdobi', 'Skupina', 'STREDISKO', 'UMISTENI', 'Filtr_CisSklad', 'Pohyby', 'vlSkupinovat', 'mf_PrintDest'.
  
  
• 3. 1 - Evidence majetku
  Upraveny stránky, ve kterých se volá číselník daŘových odpisů, aby se zobrazoval pouze k zobrazení a ne k editaci (ReadOnly) :
  - majetek\MajPoh.htm
  - majetek\Majetek.htm
  - majetek\ZustatekDanUcetRokF.htm
  - majetek\OdpisyDanUcetRokF.htm
  - majetek\ZmenaOdpSkup.htm
  - majetek\Vyrazeni_Hrct.htm
  - majetek\Vyrazeni_Hr.htm
  - majetek\Majetekctexp.htm
  - majetek\Majetekct.htm
  - majetek\ZalozDleSVU.htm
  - nastaveni\OdpSkup.htm
  - nastaveni\SKP.htm
  
  
• 3. 1 - Evidence majetku
  Založení majetku dle skladové výdejky nebo faktury
  Upravena stránka majetek\ZalozDleSVU.htm - do odkazu na kartu majetku doplněn NavBar=Insert,
  aby uživatel nemohl na zobrazeném formuláři majetku zakládat další kartu.
  
  
• 3. 1 - Evidence majetku
  Při pokusu o vyřazení již dříve vyřazeného majetku je nyní hlášena chyba, vyřazení v takovém případě již nelze provést.
  Upravena procedura spMajetek_Vyrad
  
  
• 3. 5. 6 - Inventurní soupis s výběrem
  Upravena vstupní stránka Filtrovacích podmínek pro sestavu Inventurní soupis majetku - doplněna možnost volby "Tisk počtu kusů v sestavě".
  Pokud je tato možnost zvolena (zaškrtávací checkbox) - standardně je nastaveno (zaškrtnuto), pak se tiskne sestava jako dosud, pokud není zaškrtnuto, netiskne se počet kusů, ale pouze je tam místo pro jeho vyplnění.
  Upravena sestava MAJ356 (v legislativách CZ, SK, HU, PL, DE), formulář Majetek\InvSoupis.htm
  
  
• 3. 1 - Evidence majetku
  Rozdělení majetku bylo upraveno tak, že se nyní standardně zobrazuje nová stránka pro rozdělení majetku, kde se rozdělení provádí ve dvou krocích - nejprve je nutno vytvořit návrh rozdělení majetku - to se provede dle stejných pravidel jako dosud (dle počtu kusů nebo částky, nastaveného způsobu zaokrouhlení apod.), uživatel však má možnost vidět konkrétní částky na jednotlivých pohybech původního i nového majetku, jak budou vypadat po rozdělení. Vlastní rozdělení se pak provede po stisku tlačítka "Proveď rozdělení majetku".
  Případně je možno navrhované částky předtím ručně upravit - v tom případě se po úpravě hodnoty pro původní/nový majetek dopočte druhá hodnota. Je nutno upravit částky tak, aby například výsledná zůstatková hodnota nebyla záporná.
  Návrh rozdělení i vlastní rozdělení se provádí do uvedeného data rozdělení majetku, po provedení rozdělení se pak volá procedura pro přepočet odpisů, která provede výpočet odpisů do období, pro které byly vytvořeny odpisy před rozdělením majetku.
  Pokud pohyby s datem menším nebo rovným zadanému datu rozdělení majetku neměly nastaven stav "zaúčtováno", tak se jim při provedení rozdělení tento stav nastaví.
  Pokud by existovaly pohyby s datem vyšším něž zadané datum rozdělení majetku a stavem "zaúčtováno" nebo "bez přepočtu", rozdělení nelze provést.
  
  Nově bylo také doplněno tlačítko pro vygenerování čísla majetku dle aktuální číselné řady, je možno zadat název nového majetku (nabízí se původní, který je možno změnit). Dále je možno zadat kód pohybu pro rozdělení majetku (nabízí se kód "MROZ" uvedený v novém parametru MAJ_Rozd_MROZ). Pohyb musí mít vlastnost Typ pohybu = "nedefinovaný", aby neovlivŘoval výpočet odpisů.
  Pokud kód pohybu není zadán, provádí se rozdělení tak jako dosud, to znamená, že složky na původní kartě majetku se rozdělí včetně rozdělení účetních zápisů.
  Pokud je pohyb zadán, tak se při rozdělení majetku nemění původní složky pohybů majetku (ani jejich zaúčtování), ale u původního majetku se založí nové pohyby se zápornou hodnotou a u nového majetku s kladnou hodnotou - tyto pohyby budou mít jiné kódy pohybu (MZ-ROZ = zařazení před rozdělením, MO-ROZ = odpis před rozdělením, ...). Odpovídající kódy nově vznikajících pohybů se definují v novém parametru MAJ_Rozd_DefPohyb.
  Navíc se k původnímu i novému majetku založí nová složka dokladu s nulovými hodnotami a kódem pohybu "MROZ". Tato složka slouží jednak k tomu, aby při zobrazení pohybů bylo na první pohled zřejmé, že na majetku došlo k rozdělení. A dále slouží k tomu, aby byla jednoznačně definována vazba mezi rozdělovaným složkami - tyto dvě složky s pohybem "MROZ" jsou propojeny vazbou přes historii složek dokladů (mezi původním a novým majetkem), historií jsou v rámci každého majetku k této složce "MROZ" rovněž provázány všechny nově vzniklé pohyby "před rozdělením".
  V případě potřeby sloučení rozdělených majetků lze nad složkou s kódem pohybu "MROZ" použít tlačítko "Sloučení rozděleného majetku".
  
  Odkaz "Rozdělení bez návrhu částek" umožŘuje použití původní stránky pro rozdělení majetku, která ale rovněž byla upravena :
  - doplněno tlačítko pro možnost vygenerování nového čísla majetku
  - možnost zadat název nového majetku
  - možnost zadat kód pohybu pro rozdělení majetku (s výše popsanou funkčností)
  
  Upraveny nebo doplněny stránky :
  - majetek/Maj_Rozdel.htm
  - majetek/Maj_Rozdel2.htm
  - majetek/MajPoh.htm
  - majetek/Majetek.htm
  
  Upraveny nebo doplněny procedury :
  - spMajetek_Rozdel
  - spMajetek_Rozdel_Navrh
  - spMajetek_Rozdel_DleNavrhu
  - spMajetek_ZrusRozdeleni
  
  Upraveny nebo doplněny funkce :
  - fnMaj_KartaMaj_Det_KDatu
  - fnDefPohybRozdelMaj
  - fnMajZauctovatPohyb
  
  
• 3. 1 - Evidence majetku - zařazení vložením
  Aby bylo možno (například v případě fúze společností) pořídit pohyby majetku, tak jak byly historicky v zaniklé společnosti (několik roků zpětně), a nebylo nutno otvírat již uzavřená období, je možno nyní pořídit pohyb MZV (zařazení vložením - viz parametr MAJ_KodPohybuMZV) s nulovou částkou. Při založení tohoto pohybu se na kartě majetku nastaví datum "Účtovat od data" (=Zbozi.dtKalkulace), čímž je následně umožněno zakládání pohybů s nižším datem než datum vložení bez ohledu na uzavřené období.
  O těchto pohybech se neúčtuje - POZOR, je nutno mít ošetřeno v účetních předpisech ! Standardní předpisy v ESO9Start toto mají nastaveno, ale v případě použití starších účetních předpisů to tak být nemusí !
  
  Upraveny procedury a funkce :
  fnMaj_HodnotyVObdobi, fnMaj_OdpisVObd, fnMajZustHodn
  
  Upravena procedura spSDok_TestObdobi a trigger trSDOK_TestUzav - pro pohyby majetku : pokud datum pohybu nižší než datum kalkulace (="účtovat od"), je povolena editace složek i v uzavřeném období
  
  Upravena sestava Maj3512 - do daŘových odpisů se pro účely této sestavy berou hodnoty dle stejné podmínky jako účetní odpisy – tedy pouze odpisy s datem >= MZV (datum zařazení vložením)
  
  

Procesy a workflow

• 6. 3. 1 - Procesy a workflow
  Vytvořena podpora pro přenos procesů a definici workflow mezi různými aplikacemi.
  Pomocí takto vytvořeného exportního souboru je možno například zajistit přenos definic procesů mezi různými aplikacemi.
  Při exportu je možno zatržením možnosti "Včetně podřízených procesů" se exportovat i všechny podřízené procesy (všech úrovní - rekurzivně). Zatržením možnosti "Včetně uživatelských objektů" se budou exportovat i procedury, které jsou uvedeny v exec proceduře exportovaných procesů (Proces.ExecProc_Proces).
  
  Nové stránky a procedury pro možnost exportu a importu :
  - ESO9Start\Obeh\podprocesy.htm - doplněn odkaz na stránku exportu a importu procesů
  - ESO9Start\Obeh\ProcesImpXML.htm
  - ESO9Start\Obeh\ProcesExpXML.htm
  
  - spProces_ExpXML, spProces_ImpXML
  
  

DMS

• 6. 4. 1. 1 - Dokument
  Při rušení dokumentu doplněna nová kontrola. Dokument nelze zrušit pokud má více než jednu Vazbu na tabulky ESO9. Kontrola doplněna do objektu spDokument_DelRec. Doplněna i nová chyba "52312 - Dokument nelze zrušit - má více než jednu Vazbu na tabulky ESO9".
  
  

CRM

• 6. 7. 1 - Aktivity
  Pro založení / transformaci E-Mailu(Outlook...) do ESO9 Aktivit lze použít sadu procedur
  - procedura spAktivitaEmail_Insert: zakládá tělo e-mailu
  - procedura spAktivitaEmail_InsertAttachment: zakládá přílohu do dokumentové databáze a provazuje dokument se všemi e-maily(AKTIVITAMI) které mají stejný Identifikátor e-mailu (AKTIVITA.IDEXCHITEM)
  - procedura spAktivitaEmail_SetSTAV: nastavuje stav všech e-malů(AKTIVIT) které mají stejný Identifikátor e-mailu (AKTIVITA.IDEXCHITEM)
  
  

Základní číselníky

• 9. 1.11 - Regiony
  Z Eso9StartPL přeneseny PL REGIONy do ostatních Eso9Start(CZ, SK, HU, DE).
  
  
• 9. 1. 4 - PSČ
  Provedeno:
  Z dodaného xls souboru obsahující PSČ pro PL proveden import PSČ do Eso9StartPL
  Poté z Eso9StartPL přeneseny PL PSČ do ostatních Eso9Start(CZ, SK, HU, DE).
  
  
• 9. 1. 7 - Sazby DPH
  Naplnění tabulky sazeb DPH pro německou legislativu - doplněna sazba 16% a 5% platná od 1.7.2020 a 19% a 7% platná od 1.1.2020.
  Upraveny procedura spSazbaDPH_Napln, spSazbaDPHStat_Napln.
  
  
• 9. 1. 9 - Celní sazebník (legislativa PL)
  Rozšířena předloha (stejně jako je v CZ legislativě) o položky "Kód plnění přenesené DPH" , "Režim přenesené DPH". Položky se využijí ve výkazu JPK VAT7.
  
  

Subjekty

• 9. 3. 3. 2 - Adresy subjektů - Volání číselníku region (kraj)
  Při volání číselníku se nesprávně předávala hodnota NULL položky VLTYP_SLOZ a VLPODTYP_SLOZ.
  
  Upraven datový zdroj ve formě pro číselník regionů: nastaveni\region.htm
  
  

Parametrizace systému

• 9. 6.11 - Události \ skupina SU \ událost "Joby ukončené s chybou"
  Tato událost je ve skupině "SU - Systémová událost". Doposud se chyby zkoumaly ve všech JOBech. Nově se chyby zkoumají pouze v JOBech, které jsou zahrnuty ve skupinách vyjmenovaných v parametru "Job_Kategorie".
  
  

Komplexní editory

• 9. 9. 4 - Fulltextové vyhledávání
  Doplněny informace o subjektu (kód, název).
  
  Spolu s tím upraveny následující objekty:
  Funkce
  - funkce fnFullTextEso9: doplněno hledání subjektu na dokladech
  - funkce fnFullTextEso9_Master: tabulka nově obsahuje sloupce pro subjekt (kód, název)
  
  Předlohy: do formy "Vyhledané záznamy" doplněn subjekt (kód, název)
  - předloha "nastaveni\FullText.htm"
  - předloha "nastaveni\FullText2.htm"
  
  

Změny funkcí

• fnZavPohlSubjektu - Funkce pro zobrazení závazků a pohledávek
  Upravena funkce fnZavPohlSubjektu - do výsledného recordsetu doplněna položka idTabulka Int identity(1,1).
  Funkce se používá pro zobrazení závazků a pohledávek a v případě, že pro jeden doklad existovalo více účetních zápisů závazků/pohledávek (například z důvodu splátkového kalendáře), mohlo při zobrazování dokladů dojít k problémům z důvodu nejednoznačného ID řádku (IDHDOK).
  
  
• fnDZISDOC_HDOK
  Do resultsetu funkce fnDZISDOC_HDOK doplněna položka SEZNAMDL (seznam dodacích listů včetně data vystavení).
  Upraveny funkce fnHdok_SeznamPredchudcu a fnDZISDOC_HDOK.
  
  
• fnDoprava_Sestava_SilnicniDan_One
  Změny ve funkci fnDoprava_Sestava_SilnicniDan_One použité při výpočtu silniční daně
  1) Nahrazení názvů tabulek HDOK, HDOKADDSYS, SDOK, SDOKADDSYS pohledy s prefixem QSilDan (tj. QSilDanHDOK, QSilDanHDOKADDSYS, QSilDanSDOK, QSilDanSDOKADDSYS). Redefinicí těchto pohledů se může vytvořit rozhraní mezi startkovým a profi řešením, v případě změny datového modelu v profi řešení, kdy jsou vozidla vyjmuty z tabulek HDOK/SDOK.
  2) Změna výpočtu zvýšení sazby u starých vozidel vlivem změny v Zákonu o dani silniční v § 6 Sazby daně, odstavec 8. V odstavci 8 bylo doplněno "nebo v zahraničí":
  odstavec (8) U vozidel registrovaných poprvé v České republice nebo v zahraničí do 31. prosince 1989 se sazba daně podle odstavců 1 a 2 zvyšuje o 25 %.
  Tím není potřeba definovat typ vlastnosti ZBOZI.VLPODTYP_SLOZ = 40 - "Datum registrace v ČR" a test na stáří vozidla se dá dělat jednoduše na "Datum první registrace" (ZBOZI.VLPODTYP_SLOZ = 39).
  3) Doplnění Osvobození od daně dle § 3 o odstavec g a h (od 1.1.2014):
  g) vozidla požární ochrany používaná jednotkou hasičského záchranného sboru podniku podle zákona upravujícího požární ochranu vybavená zvláštním zvukovým výstražným zařízením doplněným zvláštním výstražným světlem modré barvy zapsanými v technickém průkazu vozidla,
  h) vozidla, která jsou mobilizační rezervou nebo pohotovostní zásobou, pokud nejsou používána k podnikání.
  4) Opravena chyba s nenalezením roční sazby silniční daně u vozidel s maximální sazbou.
  5) Oprava chyby ve výpočtu počtu měsíců vyjmutí z daŘové povinnosti. Nyní se vyjmou z daŘové povinnosti jen celé vyjmuté kalendářní měsíce a započaté ne.
  
  
• fnDoprava_Sestava_SilnicniDan
  Změny ve funkci fnDoprava_Sestava_SilnicniDan použité při výpočtu silniční daně.
  Nahrazení názvů tabulek HDOK a HDOKADDSYS pohledy s prefixem QSilDan (tj. QSilDanHDOK, QSilDanHDOKADDSYS). Redefinicí těchto pohledů se může vytvořit rozhraní mezi startkovým a profi řešením, v případě změny datového modelu v profi řešení, kdy jsou vozidla vyjmuty z tabulky HDOK (SDOK,...).
  
  
• fnDoprava_Sestava_Stazka_DenOdDoKontrola
  Přepsání funkce fnDoprava_Sestava_Stazka_DenOdDoKontrola
  Na základě reklamace zákazníka s rychlostí sestavy Doprava_Stazka_CerpaniAKmKon (Kontrola ujetých Km dle vozidel) byla přepsána startková funkce v datovém zdroji sestavy fnDoprava_Sestava_Stazka_DenOdDoKontrola.
  
  
• fnTestNaSynchronizaci
  Nová funkce poskytující informaci, zda a jak je aktuální databáze zapojená do synchronizace. Test je založen na testování existence synchronizačních triggerů tabulek (u master databáze) a testu existence ReadOnly triggerů (u slave databáze).
  
  

Změny procedur

• spMajetek_ZmenaUmist - Procedura pro změnu umístění majetku
  Chybová hláška 51362 v proceduře spMajetek_ZmenaUmist byla doplněna o informaci, o jaké umístění a majetek se jedná :
  "Zadané umístění "%s" pro majetek %s nebylo nalezeno"
  (Má význam např. při inventuře majetku, kde se tato procedura volá a v tomto případě se nevědělo, o které umístění se jedná)
  
  
• spAkcePoObnoveniDB - Procedura spAkcePoObnoveniDB
  Upravena procedura spAkcePoObnoveniDB, doplněn vstupní parametr @LoginName.
  Pokud není parametr zadán nebo je prázdný, pak se procedura sp_changedbowner volá s parametrem @LoginName = 'sa', jinak se volá se zadaným @LoginName.
  
  
• spImportFPU_OCR - Procedura pro import přijaté faktury z OCR
  Úprava procedury pro načítání FPU z OCR :
  Bylo upraveno naplŘování data zdanitelného plnění (a následně i účetního období) při zakládání FPU v proceduře "spImportFPU_OCR" :
  - Pokud je zjištěné datum zdanitelného plnění vyšší než dnešní datum, použije se dnešní datum.
  - V případě zjištění problému (datum zdanitelného plnění, neexistence IČO, DIČ, údaje v adrese, čísle účtu, měně) se do poznámky zapíše v čísle hodnota 1 (pokud nebyl nalezen žádný problém, je tam 0) - dle existence poznámky s hodnotou 1 je pak možno snadněji dohledat doklady, u kterých byl při importu zjištěn nějaký z výše uvedených problémů.
  
  
• spHdok_TestDuplVSYM - Kontrola duplicity variabilního symbolu
  Na rozhraní procedury spHdok_TestDuplVSYM doplněny parametry @idHdok_Vzor, @idUctObd a @dtZdanitPln.
  Upravena procedura spHdok_TestDuplVSYM a spHDok_ValRec
  
  
• spTXT_SUBJVTSUBJ - Procedura pro založení nebo aktualizaci věty do tabulky SUBJVTSUBJ
  Rozdíly oproti standardní proceduře:
  - platební, dodací, přepravní a mezinárodní podmínky se zakládají jen když je zadán kód i typ příslušné
  podmínky (jinak končí pokus o založení chybou v proceduře spTXT_PODMINKY)
  původně:
  if (@IDPODMINKY_??? IS NULL)
  BEGIN
  ..
  END
  
  nově:
  if (@IDPODMINKY_??? IS NULL) AND (@VLDRUHPODMINKY_??? IS NOT NULL) AND (@KOD_PODMINKY_??? IS NOT NULL)
  BEGIN
  ..
  END
  
  - při vložení následujících položek se vkládá skutečná hodnota a ne ISNULL(xxx, 0) (jinak se například při @DNUSPLATNOSTI = NULL na vstupu udělá insert DNUSPLATNOSTI = 0). Je rozdíl, jestli není spatnost zadaná, nebo je 0 dní. Podobně je to i u ostatních polí: @DNUSPLATNOSTI, @DODACILHUTA, @HDUVEROVYLIMIT, @MNPROCPRIRAZKAST, @HDODBEROVYLIMIT, @VLDUVOD_OSVOB
  původně:
  Insert Into SUBJVTSUBJ Values(
  ...
  ISNULL(@DNUSPLATNOSTI, 0),
  ISNULL(@DODACILHUTA, 0),
  ISNULL(@HDUVEROVYLIMIT, 0.0),
  ISNULL(@MNPROCPRIRAZKAST, 0.0),
  ISNULL(@HDODBEROVYLIMIT, 0.0),
  ISNULL(@VLDUVOD_OSVOB, 0),
  ....)
  
  nově:
  Insert Into SUBJVTSUBJ Values(
  ...
  @DNUSPLATNOSTI,
  @DODACILHUTA,
  @HDUVEROVYLIMIT,
  @MNPROCPRIRAZKAST,
  @HDODBEROVYLIMIT,
  @VLDUVOD_OSVOB,
  ....)
  
  
• spDoprava_XML_Export_SD
  Změny v proceduře spDoprava_XML_Export_SD použité při výpočtu silniční daně.
  1) Doplnění parametrů aplikace SD_naz_obce a SD_PSC
  Doplnění algoritmu o nové parametry aplikace - SD_naz_obce a SD_PSC ze skupiny Doprava. Nové parametry řeší možné zobrazení propustné chyby při kontrole podání silniční daně přes daŘový portál. Kdy se v I. oddílu u názvu obce/městské části a PSČ objevuje chyba z důvodu odlišného číselníku obcí Finanční správy ČR a číselníku PSČ České pošty (hláška: obec, která je vyplněna ve formuláři, není obsažena v číselníku obcí). Tzv. propustné chyby, sice umožní odeslání podání i bez opravy, ale pokud chceme mít podání i bez těchto drobných chyb a nechceme je, popř. dokola opravovat, stačí nové parametry (či jen ten, u kterého se chyba objeví) vyplnit dle hodnot číselníku Finanční správy ČR, který se nabízí na daŘovém portálu. Pokud parametry budou vyplněny, použijí se tyto hodnoty přednostně ve funkci pro výpočet silniční daně, namísto názvu obce a PSČ získaného z adresy subjektu firmy.
  2) Změna položky c_pracufo (Územní pracoviště) při hodnotě 0 na ''
  DaŘový portál vyžaduje nastavit číslo Územního pracoviště c_pracufo v XML na '' (prázdný řetězec) a ne na '0', pokud není hodnota zadána, např. u Specializovaného finančního úřadu není žádný číselník pro c_pracufo a musí být vyplněna hodnota ''.
  
  
• spSDRocniSazbaAzalohy
  Nová procedura pro výpočet roční sazby a záloh silniční daně pro jedno vozidlo spSDRocniSazbaAzalohy.
  
  
• spTestNaSynchronizaci
  Nová procedura poskytující informaci, zda a jak je databáze zapojená do synchronizace. Test je založen na testování existence synchronizačních triggerů tabulek (u master databáze) a testu existence ReadOnly triggerů (u slave databáze).
  
  

Změny předpisů sestav

• Hl_kniha_Str_syn.idc - Hlavní kniha
  Při tisku hlavní knihy se na druhé a další stránce nezobrazovalo záhlaví : Kód účtu Název účtu atd.
  Upravena sestava Hl_kniha_Str_syn.idc - prvku HeaderBand1 byla nastavena vlastnost "Tisknout na" na hodnotu "Všechny stránky" (byla jen 1. stránka).
  
  

Změny datových struktur

• ZBOZI - Zboží
  Změna sloupce JAKOST_NORMA z VARCHAR(12) --> VARCHAR(14).
  Spolu s tím provedeny změny v těchto objektech:
  - funkce fnZboziVCase
  - procedura spZbozi_NewRec
  - procedura spZbozi_CalRec
  - procedura spZbozi_BeforeInsert
  - procedura spZbozi_ValRec
  - procedura spZbozi_CopyRec
  - procedura spTXT_ZBOZICalRec
  - procedura spTXT_ZBOZI
  
  
• ZBOZSKL - Zboží na skladě
  Tabulka ZBOZSKL (zboží na skladě) rozšířena o sloupec ZBOZSKL.VLINVSDOK SMALLINT - indikace stavu, zda 0-Ne/1-Ano byl z inventurního stavu vytvořen inventurní doklad (manko, přebytek).
  
  
• REGION
  Provedeny následující změny struktur indexů:
  - doposud měl unikátní klíč REGION_Key1 tuto strukturu: KOD_REGIONU, VLTYP_SLOZ, VLPODTYP_SLOZ
  - nově bude mít unikátní klíč REGION_Key1 tuto strukturu: KOD_REGIONU, VLTYP_SLOZ, VLPODTYP_SLOZ, IDSTAT
  
  
• PSC - PSČ
  Provedeny následující změny struktur a množství klíčů:
  Doposud byly klíče:
  - primární PSC_PK = PSC
  Nově budou tyto klíče:
  - primární PSC_PK = IDPSC
  - unikátní PSC_Key1 = PSC, IDSTAT
  
  
• PARAM - Parametr
  Strukturální změny
  - sloupec "KODPARAM": změna z VARCHAR(20) --> VARCHAR(30)
  
  Spolu s tím upraveny:
  Funkce:
  - fnDZFAP_DPHEU
  - fnDPH_DE_KontrolaZauctovani_Detail
  - fnDPH_DE_KontrolaZauctovani
  - fnidUctOsn_DPH_DleParam
  
  Procedury:
  - sp_VratParUziv_varchar
  - sp_VratParUziv_Int
  - sp_VratParUziv_Float
  - sp_VratParUziv_DT
  - sp_NastavParUziv
  - sp_NastavParUziv_Float
  - sp_NastavParUziv_Int
  - sp_NastavParUziv_DT
  - spParam_ValRec
  - spHDok_PreuctujDph_1
  - spGOBD_ExpCSV_File1
  - spMajetek_NastavRaduUziv
  - spParam_OmezitPlatnost
  - spParam_BeforeUpdate
  - spParam_BeforeInsert
  - spParam_AfterUpdate
  - spParam_AfterInsert
  - spTestEso9
  - spUCTYPROVYKAZDPH_Napln
  - spINTRASTAT_Export
  
  Předlohy:
  - nastaveni\Param.htm
  - subjekt\Param_NastavRaduSubj.htm
  - zasilky\PPL_Param.htm
  
  
• TYPDOK - Typ dokladu
  S doplněním možnosti ročního kurzu (10=zdan. plnění - roční; 11=odesláno/přijato roční; 12=vystaveno - roční) do typu dokladu upraveny následující objekty:
  - parametr "IDES_VLDATUMKURSU" ze skupiny parametrů "INTRASTAT".
  - procedura spHDok_DTZDANITPLN
  - procedura spDATUM_DATUMKURSU
  
  
• TYPDOK - Typy dokladů
  Do položek "Datum pro výpočet kurzu" (v tabulkách HDOK, TYPDOK, TDVCASE) doplněna možnost zadání ročního kursu.
  
  Upraveny stránky (doplnění možností do výčtu : zdan. plnění - roční / odesláno/přijato - roční / vystaveno - roční) :
  - nastaveni\TDvCase.htm
  - nastaveni\TDVCase_HromZmena.htm
  - nastaveni\TypDok.htm
  - priklady\HDok.htm
  
  
  Upravené procedury a funkce :
  - fnKursl_txtDatum
  - spHDok_FVZ_FVZD
  - spHDok_FapEU_vlDatumKurzu
  - spHdok_FC_dtVystaveno
  - spHdok_FC_dtOdeslano
  - fnKursL_VratEuro
  - spKursL_VratEuro
  - fnVratKurs
  - spVratKurs
  - spTestKurs
  - spVratKoefKursu
  
  U parametrů FAPEU_Kurz_Dat_23, FAPEU_Kurz_Dat_Sl, FAPEU_Kurz_Dat doplněna možnost zadat hodnoty 10,11 a 12.
  
  
• SPOTRDAN - Spotřební / ekologicka daŘ
  Rozšířena struktura o tyto sloupce
  - KODADD_SD: DoplŘkový kód spotřební. Jedná se o situace, kdy kód spotřební daně má být stejný, ale je různá "Jednotková sazba daně" pro stejnou měrnou jednotku. Příkladem je pivo s kódem 220301, který má základní sazbu 16Kč/hl vynásobené hmotnostním procentem extraktu původní mladiny.
  Např. kód spotřební daně je pořád stejný 220301
  - 7° pivo má sazbu 16*7 = 112Kč/hl ---> doplŘkový kód "P07"
  - 10° pivo má sazbu 16*10 = 160Kč/hl ---> doplŘkový kód "P10"
  - 12° pivo má sazbu 16*12 = 192Kč/hl ---> doplŘkový kód "P12"
  
  - VLDRUHDANE_SD: Druh daně v rámci typu daně. V současnosti má tyto hodnoty 0-Neurčeno; 1-Minerální oleje; 2-Líh; 3-Pivo; 4-Víno a meziprodukty
  
  - POPISADD_SD: Popis doplŘkového kódu.
  Např. u piva to bude
  - Obsahuje 7° hmotnostních procent extraktu původní mladiny.
  - Obsahuje 10° hmotnostních procent extraktu původní mladiny.
  - Obsahuje 12° hmotnostních procent extraktu původní mladiny.
  
  Spolu s tím provedeny následující úpravy:
  - procedura spSPOTRDAN_NewRec: doplněny na rozhraní povinné parametry:
  - @KODADD_SD Varchar(5) OUT,
  - @VLDRUHDANE_SD SmallInt OUT,
  - @POPISADD_SD Varchar(100) OUT,
  
  - činnost 9. 1. 8 Spotřební / ekologická daŘ: předloha "nastaveni\spotrdan.htm" doplněna o nové položky
  - DoplŘkový kód (SPOTRDAN.KODADD_SD)
  - Druh daně (SPOTRDAN.VLDRUHDANE_SD)
  - Popis k doplŘkovému kódu (SPOTRDAN.POPISADD_SD)
  
  - činnost 9. 5. 9 Zboží: předloha "" doplněna o následující:
  - do kódu spotřební daně lze zadávat jak kód (např.2203), tak doplŘkový kód spotřební / ekologické daně (např. P10)
  - doplněny jako readonly položky "DoplŘkový kód" a "Popis doplŘkového kódu"
  
  
• PRIZNANISD - Přiznání ke spotřební / ekologické dani
  Rozšířena struktura o tyto sloupce
  - VYROBEKADD_SD: DoplŘkové označení výrobku, které obsahuje hodnotu nového sloupce SPOTRDAN.KODADD_SD
  
  Spolu s tím provedeny následující úpravy:
  - funkce fnVLPriznaniSD_SDOK: nově obsahuje sloupec VYROBEKADD_SD
  - procedura spPriznaniSD_Vytvor: tvorba přiznání spotřební/ekologické daně pracuje s "DoplŘkovým označením výrobku" (VYROBEKADD_SD) jako součást skupiny za kterou vzniká řádek přiznání
  - procedura spPriznaniSD_ExportCZ_XMLeDAP18: tvorba XML pracuje s "DoplŘkovým označením výrobku" (VYROBEKADD_SD) jako součást skupiny za kterou XML vzniká.
  - činnost 1. 1. 2. 6-10 Přiznání spotřební / ekologické daně:
  - forma ucet\PriznaniSD.htm: doplněna položka "DoplŘkové označení výrobku"
  - forma ucet\PriznaniSD_Detail.htm: doplněna položka "DoplŘkové označení výrobku"
  - sestava IDC/HTX ucet\Priznani_SD_Tisk:: doplněna položka "DoplŘkové označení výrobku"
  
  

Změny triggerů

• trHDok_Upd - Trigger nad tabulkou HDOK
  Upraven trigger trHDok_Upd, do chybové (informativní) hlášky č. 51710 doplněna informace o čísle dokladu : "Měníte částku k úhradě, ale doklad %s je již spárován nebo částečně spárován."
  
  

Změny pohledů

• QESO9Log - Pohled do LOG databáze
  Pohled QESO9Log doplněn o tyto nové sloupce: ochrana proti "sql injection"
  - TIME AS DTAKCE
  - SQL AS SQLAKCE
  
  Spolu s tím upraveny následující činnosti:
  - 9. 8. 4 Logovací databáze: zde upraveny stránky tak, aby se pracoval s novými sloupci DTAKCE, SQLAKCE a byly potlačeny původní sloupce "TIME", "SQL". Upraveny předlohy "Nastaveni\Eso9Log.htm", "Nastaveni\Eso9LogFull.htm"
  
  
• QSilDanHDOK
  Nový pohled QSilDanHDOK pro silniční daŘ.
  Použit ve funkci fnDoprava_Sestava_SilnicniDan
  Redefinice pohledu vytvoří rozhraní mezi startkovým a profi řešením, v případě změny datového modelu v profi řešení, kdy jsou vozidla vyjmuty z tabulky HDOK (SDOK,...).
  
  
• QSilDanHDOKADDSYS
  Nový pohled QSilDanHDOKADDSYS pro silniční daŘ
  Použit ve funkci fnDoprava_Sestava_SilnicniDan_One
  Redefinice pohledu vytvoří rozhraní mezi startkovým a profi řešením, v případě změny datového modelu v profi řešení, kdy jsou vozidla vyjmuty z tabulky HDOK (SDOK,...).
  
  
• QSilDanSDOK
  Nový pohled QSilDanSDOK pro silniční daŘ
  Použit ve funkci fnDoprava_Sestava_SilnicniDan_One
  Redefinice pohledu vytvoří rozhraní mezi startkovým a profi řešením, v případě změny datového modelu v profi řešení, kdy jsou vozidla vyjmuty z tabulky HDOK (SDOK,...).
  
  
• QSilDanSDOKADDSYS
  Nový pohled QSilDanSDOKADDSYS pro silniční daŘ
  Použit ve funkci fnDoprava_Sestava_SilnicniDan_One
  Redefinice pohledu vytvoří rozhraní mezi startkovým a profi řešením, v případě změny datového modelu v profi řešení, kdy jsou vozidla vyjmuty z tabulky HDOK (SDOK,...).
  
  

Změny webových stránek

• include\PrefVetaCZ_inc.htm - Nefunkční tisk sestavy FAV při vstupu do stránky přes historii
  Při vstupu do faktury vydané přes historii (tj. ne ze stromu činností) nefungoval tisk faktury.
  Problém byl při plnění hodnoty parametru sestavy MF_NEANOPREFVETA, který měl ve zdrojové stránce prodej\FaV.htm (resp. include\PrefVetaCZ_inc.htm) nedefinovanou hodnotu (tj. NULL). Při doplnění této hodnoty do datového zdroje sestavy došlo k syntaktické chybě.
  Nejbezpečnějším řešením byla úprava POUZE includované stránky (include\PrefVetaCZ_inc.htm), konkrétně označení výchozí hodnoty 0 (pro MF_NEANOPREFVETA) jako SELECTED, tedy: <option selected value="0">Ne</option>.
  
  
• include\Dokument_INC.htm - Ne-zobrazení odkazu na dokument v Internet Exploreru
  Upravil jsem stránku include\Dokument_INC.htm pouze pro starého klienta (IE) tak, aby položku s odkazem neobsahovala. Vzhledem k tomu, že se jedná o include, nelze v něm již použít další include (syntaxi $INCLUDEHTML); z tohoto důvodu jsem verzi stejné stránky pro obecného klienta (obsahující odkaz) vložil do složky .OK\Include\Dokument_INC.htm.
  
  
• KartaVozidla_MimoDan.htm
  Doplnění nových typů Osvobození od daně – vyjmutí z daŘové povinnosti do combo boxu Typ:
  Osvobození od daně dle § 3 odst. 1 g (podniková hasičská vozidla,...)
  Osvobození od daně dle § 3 odst. 1 h (mobilizační rezerva,...)
  
  

Výroba pro ESO9

Výroba

• 5. 7. 1 - Montážní příkaz z prodejní objednávky - Vytvoření montážního příkazu
  Upravena činnost tlačítka "Vytvoření montážního příkazu", která připravuje MPR ze složky prodejní objednávky. Volaná procedura nyní zohledŘuje platné pozice podle nastaveného datumu ESODATUM.
  
  Provedena úprava v proceduře spZBOZIROZPAD_NaplnKumulaci
  
  
• 5. 1. 2 - Kalkulace - Kalkulace fázových polotovarů
  Upraven mechanizmus kalkulace pro výpočet ceny za použití fázové kalkulace.
  
  Pokud je kalkulovaný výrobek označen pro způsob výpočtu kalkulace „FØZOVØ“, tak se provádí výběr množiny jen z první úrovně rozpadu, bez ohledu na to, zda se pozice dále rozpadá či nikoliv. Položky označené „fázové“ jsou vybírány do skupiny polotovarů.
  
  V případech, kdy se nejedná o fázovou kalkulaci, výběr množiny položek do výpočtu se provede standardně podle původních pravidel a podle nastavení rozpadu jednotlivých pozic celého stromu) bez ohledu na nastavení fázové/běžné kalkulace na pozicích.
  
  Fázová kalkulace předpokládá vtahování nákladů z předchozích úrovní jako jeden cenový balík – cena polotovarů z předchozí fáze. Cena je standardně napočítána do výsledného kalkulačního členu CPv. Nápočet se provádí pro všechny kalkulační členy se zvolenou oblastí výběru hodnot „Polotovary - cena“.
  
  Cena polotovarů předchozí fáze se standardně vyhledá v položce „Kalkulovaná cena“ na kartě zboží. Cena těchto polotovarů nižších úrovní (předchozích fází) se při výpočtu vyšších celků automaticky nevypočítává, musí být připravena kalkulací samostatně. Položka se naplŘuje výpočtem vlastní kalkulace podsestavy (polotovaru).
  
  POZNØMKA:
  Fázová kalkulace polotovarů znamená výpočet přímých výrobních nákladů výrobku/sestavy plus zařazení kalkulované ceny vstupujících polotovarů/podsestav z předchozí fáze.
  
  
  V souvislosti s úpravami byly provedeny změny procedur:
  - spKALKCLEN_UrciHodnotu
  - spZBOZIROZPAD_PriprKalk
  
  
• 5. 6. 2 - Odvádění výroby - Automatické vtahování polotovarů při odvádění
  Provedena revize a rozšíření procesů závisejících na parametru pro automatické vtahování vstupujících podsestav (polotovarů) při odvádění výroby.
  
  Parametr „VYROBA_AUTOVTAZENI“ byl rozšířen a nastaven takto:
  - 0 (defaultně) předpokládá se ruční vtažení polotovarů, automatická činnost je potlačena,
  - 1 = automatické vtažení daného polotovaru v rámci daného VP tj. vtahují se jen vlastní polotovary,
  - 2 = automatické vtažení daného polotovaru z DZ v rámci vlastní výrobní zakázky,
  - 3 = automatické vtažení daného polotovaru z DZ LIFO (nejnovější datum výroby a pořadí dávky),
  - 4 = automatické vtažení daného polotovaru z DZ FIFO (nejstarší datum výroby a pořadí dávky)
  
  
  
  Důležitá informace:
  • K automatickému vtahování polotovarů z DZ dle parametru dochází jen při standardním odvádění operace. Ruční a ruční poměrové odvádění automatické vtahování a navazování z DZ při odvádění neprovádí.
  • Při vrácení odvedení zůstávají původně automaticky navezené komponenty vtažením z DZ stále navázané. (samozřejmě je lze vtáhnout jinam)
  • Nastavení parametru „1“ – vtahovat polotovary jen z vlastního VP. Týká se případu vícesložkového VP, tj., že jsou polotovary vyráběny v rámci složek vlastního VP. Tyto jsou pak automaticky vtahovány.
  
  Poznámka:
  Tvorba VP s více než jedním výrobkem/polotovarem se od verze 4.0 (kdy došlo ke změnám datového modelu) nedoporučuje. Nový datový model vícesložkové VP stále umožŘuje, nebude však umožněno využít plnou funkčnost sledování šarží na odvedení dopravních dávek – ta je podporovaná až v novém datovém modelu (při vracení odvedení operace může dojít k nejednoznačné rekonstrukci šarží odvedených plovoucích komponent na operacích, které byly odváděny více dopravními dávkami).
  
  Vytvořena nová procedura pro rušení vazby u navezených POL: spSTART_ZRUSITNAVAZANI_SLOZPKDET. Tato se nyní volá ve formuláři zobrazených detailních navázaných složek zadavani/START_SlozkyPKDetail.htm.
  
  Vytvořena nová funkce, která vrací informaci o množství polotovaru k teoretickému vtažení z DZ:
  fnMNPOCETMJ_KEVTAZENI_POL
  
  
• 5. 6. 2. 1 - Odvádění podle výrobního příkazu - Zobrazení kódu MJ na formuláři
  Na formuláři se nyní zobrazuje kód MJ výrobku, který je operací vyráběn. Původně byla zobrazována měrná jednotka z operace, která nemá pro odváděním výrobku relevantní význam.
  Tato změna je provedena i na formuláři odvedených operací.
  
  Změněné formuláře v katalogu ../zadavani:
  START_VPOdvOperMat_inc.htm
  START_VPOdvOper_inc.htm
  START_VPOperace.htm
  START_VPOperMat.htm
  
  
• 5. 7 - Montáže - Volání číselníku vzorů z formulářů - datové zdroje formy
  Na formuláři:
  
  - prodej\TvorbaMonPrik.htm
  - sklad\PrijemHVMPR.htm
  
  bylo nesprávně uvedeno číslo uživatele 313. Správně má být %IDLOGUSER%.
  Opraveno.
  
  

• 6.9 - PLM (product lifecycle management) - Změnové řízení (v rámci PLM)
  Agenda „Změnové řízení“ byla implementována jako podúloha oborového řešení 6.9 PLM (product lifecycle management). Jedná se o činnosti změnového řízení (počínaje náměty na změnu, zadáním požadavku na změnu a s tím souvisejícím vydáním řízených verzí pro jednotlivé položky technické dokumentace). Plná funkčnost je přístupná v uvedeném oborovém řešení 6.9 - PLM.
  
  V základním řešení (ESO9-Výroba) je umožněno evidovat čísla revizí a datumy vydání na položkách výrobků, kusovníku a operací. V agendě výroba v souvislosti s tímto došlo k rozšíření o následující standardní funkčnosti:
  - Na kartách výrobků přidána možnost zápisu aktuálního platného čísla revize, verze a data platnosti
  - Na jednotlivých pozicích kusovníku a technologického postupu přidána možnost zápisu čísla revize a verze, pod kterým byla pozice naposledy, včetně evidence aktuální platné revize podsestavy – je li tato pozice podsestavou.
  
  6.9 – PLM
  6.9.1 – Změnové řízení
  o 6.9.1.1 – Náměty na změny
  o 6.9.1.2 – Evidence změn
  o 6.9.1.3 – Správa revizí a verzí
  
  K rozšíření datového modelu:
  ? ZBOZICAM
  Je systémová addtabulka pro tabulku ZBOZI. Tuto rozšiřuje o tématickou oblast „výroba - CAM“.
  
  ? IDZBOZICAM Integer identifikátor věty
  ? IDZBOZI Integer vazba do tabulky ZBOZI
  ? IDREVIZE Integer vazba do tabulky REVIZE
  ? REVIZE Varchar(12) pro evidenci aktuální revize dokumentace
  ? VERZE Integer pro evidenci verzí v rámci revize
  ? DATUMVYDANI DATETIME platnost datumu změny
  ? VLDRUH_POLOZKY smallint použitá pro exporty do AutoCAD
  
  
  
  Tabulka je kaskádově závislá na master větě (ZBOZI), tedy při rušení věty z tabulky ZBOZI bude automaticky smazán i příslušný řádek tabulky ZBOZICAM
  
  
  ? ZBOZIMNSPOTRCAM
  Je systémová addtabulka pro tabulku ZBOZIMNSPOTR. Tuto rozšiřuje o tématickou oblast „výroba - CAM“.
  
  ? IDZBOZIMNSPOTRCAM Integer identifikátor věty
  ? IDZBOZIMNSPOTR Integer vazba do tabulky ZBOZI
  ? IDREVIZE Integer vazba do tabulky REVIZE
  ? REVIZE Varchar(12) pro evidenci aktuální revize dokumentace
  ? VERZE Integer pro evidenci verzí v rámci revize
  ? IDREVIZEsub Integer vazba do tabulky REVIZE (podsestava)
  ? REVIZEsub Varchar(12) pro evidenci aktuální revize dokumentace (podsestava)
  ? VERZEsub Integer pro evidenci verzí v rámci revize (podsestava)
  ? DATUMVYDANI DATETIME platnost datumu změny
  
  
  
  Tabulka je kaskádově závislá na master větě (ZBOZIMNSPOTR), tedy při rušení věty z tabulky ZBOZI bude automaticky smazán i příslušný řádek tabulky ZBOZIMNSPOTRCAM
  
  ? ZMENA
  Je systémová tabulka, určená pro evidenci změnových řízení.
  ? IDZMENA Integer Jednoznačný identifikátor věty - primární klíč
  ? CISKOD_ZMENA Varchar(20) Číselné označení změny
  ? VLTYP_ZMENA SmallInt Označení typu změny
  ? VLSTAVZMENA SmallInt Stav zpracování věty
  ? DATUMPLAT DateTime Datum platnosti změny (od)
  ? IDUSERVAZBA Integer Uživatelská vazba na obecnou tabulku (důvod změny)
  ? VLTYPVAZBY SmallInt Specifikace uživatelské vazby
  • NULL,
  • 0 = uživatelská vazba
  • 1 = HDOK
  • 2 = SDOK
  • 3 = ZBOZI
  • 4 = VYROBA
  
  ? NAZEV_ZMENA Varchar(100) Název změnového záznamu
  ? POPIS Varchar(MAX) Podrobný popis změny
  ? ZAK_HDOK Varchar(20) Odkaz na číslo zakázky/projektu, v rámci níž je změna prováděna
  ? IDUZIVATEL Integer ID uživatele
  ? IDUZIVATEL_INSERT Integer id uživatele, který větu založil
  ? DTINSERT DateTime Datum založení věty
  ? IDUZIVATEL_UPDATE Integer ID uživatele, který větu záznamu aktualizoval
  ? DTUPDATE DateTime Datum aktualizace záznamu
  
  ? REVIZE
  Je systémová tabulka, určená pro evidenci revizí pro jednotlivé výrobky.
  ? IDREVIZE Integer Jednoznačný identifikátor věty - primární klíč
  ? IDZMENA Integer Vazba na větu změnového řízení
  ? IDZBOZI Integer Vazba na konkrétní položku (výrobek, sestavu, díl...)
  ? REVIZE Varchar(12) Označení revize
  ? VERZE Integer Pořadové číslo úpravy v rámci revize - pomocná položka
  ? VLSTAVREVIZE SmallInt Stav zpracování revize
  • 0=neuvolněno
  • 1=uvolněno
  ? DATUMUVOLNENI datetime
  ? POPIS Varchar(MAX) Podrobný popis
  ? IDUZIVATEL Integer id uživatele, který je zodpovědný za zpracování revize!!!
  ? IDUZIVATEL_INSERT Integer id uživatele, který větu založil
  ? DTINSERT DateTime DT založení věty
  ? IDUZIVATEL_UPDATE Integer id uživatele, který větu aktualizoval
  ? DTUPDATE DateTime Datum aktualizace věty
  
  
  ? REVIZEVAZBA
  Je systémová tabulka, která udržuje vazby mezi závislými revizemi
  ? IDREVIZEVAZBA Varchar(12) Označení revize
  ? IDREVIZEP Integer Vazba na předchůdce
  ? IDREVIZEN Integer Vazba na následníka
  ? VLTYPVAZBY SmallInt Typ vazby (0=přímý následník, 1=vzdálený následník: předchůdce je první v kaskádě vazeb)
  0=Blízký následník (předchůdce způsobil přímo změnu revize následníka);
  1=Vzdálený následník (typ revize předchůdce je primární, jeho změna způsobila změnu u následníka nepřímo v rámci kaskády změn); -
  
  
  
  Změny na webu:
  
  - Nový adresář PLM
  o Revize.htm
  o RevizeN.htm
  o RevizePN.htm
  o Zmena.htm
  o DokumentaceZMENA.htm
  
  Dále došlo ke změně formuláře „díl“: priprava\dil.htm
  
  Rozšíření parametrů úlohy o skupinu parametrů „PLM“:
  - PLM_REVIZECISLOVANI (volba způsobu číslování revizí technologické dokumentace)
  
  Programové změny:
  - fnREVIZE_Next
  - spQREVIZE_NEXTVRADE
  - spQZBOZIMNSPVYR_OPER_GETREVIZE
  - spQZBOZIMNSPVYR_OVVAR_GETREVIZE
  - spQZBOZIPROVYR_GETREVIZE
  - spREVIZE_NewRec
  - spZMENA_NewRec
  
  

Zboží, služby, majetek..

• 9. 5. 9 - Zboží - Odkaz "Výroba zboží"
  Na stránku (formulář nastaveni\ZbozVyroba.htm) bylo přidáno tlačítko KALKULACE CENY pro výpočet kalkulované ceny.
  
  Procedura spVYROBAZBOZI_KalkulaceCeny sečte násobky množství hrubých spotřeb s kalkulovanou cenou každé položky uvedené na rozpisce. Výslednou hodnotu následně uloží do pole „Kalkulovaná cena“ (HDCENAKALK). Je-li do rozpisu zařazena podsestava (která má svůj vlastní rozpis) je využita hodnota z pole kalkulovaná cena. Procedura kalkulace nepřepočítává ceny do hlubších úrovní. Pro výpočet správné ceny je potřebné mít aktuálně zkalkulovány všechny jednotlivé podsestavy, které do rozpisu vstupují.
  Způsob výpočtu lze ovlivnit ze stránky volbou komba:
  - Součet kalkulovaných cen (není-li vyplněno: jinak nákupní)
  - Součet kalkulovaných cen (není-li vyplněno: jinak skladová)
  - Součet kalkulovaných cen (není-li vyplněno: jinak prodejní)
  
  Dále je způsob výpočtu ovlivněn parametry aplikace:
  - VYRZBOZI_TYPSLOZKALK
  Parametr udává, které typy složek se zahrnou do výpočtu kalkulace. Výsledné číslo zadávané do parametru představuje součet hodnot představující jednotlivé typy (například defaultní mat(2)+sluz(4): 6=2+4) jednotlivých požadovaných typů'. Pro všechny typy do výběru je hodnota parametru spočtena jako 1+2+4+8+16 = 31
  
  0 - žádný výběr...
  1 - ostatní "0"
  2 - materiál "1"
  4 - služba "2"
  8 - pomůcka "3"
  16 - operace "4"
  
  - VYRZBOZI_PREPSATKALK
  Standardně je nastaveno „0“ - je zakázáno přepsat kalkulovanou cenu, pokud je již počítána v agendě ESO9-Výroba (podle kalkulačního vzorce)
  Pokud „1“, přepsání bude provedeno, i když je zřejmé, že hodnota kalkulované ceny vznikla výpočtem ve „velké výrobě“
  
  Poznámka:
  V položce „Kalkulovaná cena (HDKALKCEN) je standardně udržována aktuální zkalkulovaná cena výrobku v případech, kdy uživatel používá agendu ESO9 – Výroba. Cena je naplŘována mechanismem kalkulace podle stanoveného kalkulačního vzorce z činnosti 5.1.2 – Kalkulace.
  
  

Změny procedur

• Sezman změněných objektů - Funkce a procedury
  fnMNPOCETMJ_KEVTAZENI_POL
  fnREVIZE_Next
  fnVYROBA_PKKK_MNNAVEZENO_POL
  spKALKCLEN_UrciHodnotu
  spPLM_InsertAffectedItems
  spPLM_ZMENA_New
  spQDILKOPIE_GetRecRevizeNew
  spQDILKOPIE_GetRecRevizeOld
  spQDILKOPIE_GetRecZboziNew
  spQDILKOPIE_GetRecZboziOld
  spQNamet_NewRec
  spQREVIZE_NEXTVRADE
  spQZBOZIMNSPVYR_OPER_GETREVIZE
  spQZBOZIMNSPVYR_OVVAR_GETREVIZE
  spQZBOZIMNSPVYR_OVVAR_REVIZESUB
  spQZBOZIMNSPVYR_OVVAR_ZBOZICAMREVIZESUB
  spQZBOZIPROVYR_GETREVIZE
  spQZBOZIPROVYR_NastavSledovaniZmen
  spREVIZE_DelRec
  spREVIZE_NewRec
  spREVIZE_ValRec
  spSTART_VtazenizDZDetailAuto
  spSTART_VtazeniZDZDetailPol
  spSTART_VYROBA_BTMARKKOPIE
  spSTART_ZRUSITNAVAZANI_SLOZPKDET
  spVYROBAZBOZI_KalkulaceCeny
  spZBOZICAM_InsUpdRec
  spZBOZICAM_ValRec
  spZBOZIMNSPOTRCAM_InsUpdRec
  spZBOZIMNSPOTRCAM_NewRec
  spZBOZIMNSPOTR_DelRec
  spZBOZIMNSPOTR_NewRec
  spZBOZIMNSPOTR_Ukonceni
  spZBOZIMNSPOTR_Zmena
  spZBOZIROZPAD_NaplnKumulaci
  spZBOZIROZPAD_PriprKalk
  spZMENA_AfterInsert
  spZMENA_NewRec
  
  

Změny webových stránek

• nastaveni/ZbozVyrobaKopie.htm - Formulář pro kopii výrobního postupu
  Společný formulář pro kopii výrobního postupu volaný odkazem "Kopie výrobního postupu" z činnosti:
  - 5.6.7. – Technická dokumentace (MPR)
  - 2.3.4.2. - Zboží (odkaz Výroba zboží)
  
  Na formuláři nebylo možné zapsat kód výrobku větší než 14 znaků. Maximální délka je však 30. Opravena délka vstupního pole i předpis MF položky v datovém zdroji formy.
  
  

ESO9 podpůrné nástroje

Změny procedur

• spSelfTunningFillFactor - Defragmentace indexů
  Byl vytvořen nástroj umožŘující optimalizaci nastavení fill-faktoru indexů a tím pádem snížení defragmentace indexů.
  Podrobnější popis problému a návod je popsán v dokumentu "Defragmentace indexů".
  Nové tabulky AgentIndexRebuilds, DefragLog, procedury spSelfTunningFillFactor, spServer_SelfTunningFillFactor, spResetTrackPageSplits, spLogDefrag.
  
  

Technologie ESO9 - server + klient

Změny v technologii .NET

• Aplikační server - Změna chování Rowfilteru
  Ve výchozím nastavení používá RowFilter pro filtrovací podmínky výchozí hodnoty INPUTů z HTML předlohy (tj. atribut VALUE=xx). Pro položky typu SELECT (combo box) jako výchozí hodnota použije vybraná položka (tj. atribut SELECTED). Při inicializaci RowFilteru pak použily takto získané výchozí hodnoty jako výchozí hodnoty pro filtr; ten byl pak nastaven především podle hodnot combo boxů ve stránce. Při použití ve StartFilteru se však jako výchozí hodnota combo boxu vždy použije hodnota "Nefiltrovat".
  Tento nesoulad mezi výchozím chováním StartFilteru a RowFilteru byl vyřešen podle chování StartFilteru, které bylo intuitivnější. Výchozí hodnota položek typu SELECT v RowFilteru bude tedy "Nefiltrovat" stejně, jako ve StartFilteru.
  
  
• Aplikační server - Sestavy typu EXPORT
  Do technologie byl vrácen původní typ sestavy EXPORT, pro který byl použit generátor sestav Sinea (cca rok 2003). Fungovat bude - stejně jako dříve - pouze v Internet Exploreru a to za předpokladu instalace nejstarší verze klientské komponenty určené pro IE6 a nižší.
  Pro export do CSV z obecného klienta je určen typ výstupu CSV (resp. tento typ je dostupný z obou klientů).
  
  
• Aplikační server - Odesílání sestav e-mailem z obecného klienta
  Při odesílání sestav z obecného klienta e-mailem musela být nastavena adresa odesílatele (v parametru SMTP_FROM). Nově tato povinnost odpadá, v případě, že parametr vyplněn není, se použije fiktivní adresa, která se následně z vygenerovaného e-mailu smaže.
  Dostupné v technologii od 29.1.2020.
  
  
• Aplikační server - Přechod mezi formami ve vazbě SAME
  Při přechodu mezi formami ve vazbě SAME, které obě používaly RowFilter, nedocházelo správně k nastavování filtrovacích podmínek, tj. cílová forma nepřebírala správně vyplněné hodnoty z RowFilteru zdrojové formy.
  Opraveno v technologii z 29.1.2020.
  
  
• Aplikační server - Možnosti výstupu do CSV
  Pro sestavy s typem výstupu CSV byla doplněna možnost parametrizace formátu na odkazu:
  * NOQUOT=1 - položky nebudou uzavřeny v uvozovkách
  * DELIMITER=1/2/3 - volba oddělovače: 1=čárka, 2=středník nebo 3=tabulátor.
  * NOZIP=1 - výsledek exportu se nebude zaZIPovávat, ale pošle se přímo jako CSV soubor. V případě, že má export více datových zdrojů, pošle se tímto způsobem pouze první. Pro větší počet vět (1+ mil.) může mít CSV soubor řádově stovky MB.
  Bez uvedení parametrů bude formát výchozí, tj. položky uzavřeny do uvozovek a oddělovač čárka.
  
  
• Aplikační server - Použití parametru Refresh_All_Forms v kombinaci s vazbou Master-Slave
  Pokud byl použit parametr Refresh_All_Forms (obnova všech forem ve stránce po vybraném typu akcí) ve Slave formě ve stránce s více formami, nedošlo k obnově celé Master formy, ale pouze aktuálního řádku (výchozí chování použité např. pro nápočet hodnot ze složek do hlavičky). Nové chování bude takové, že bude-li použit parametr Refresh_All_Forms i v Master formě, dojde k obnově všech řádků formy.
  Dostupné v technologii od 18.2.2020.
  
  
• Aplikační server - Generovaný HTML kód
  Došlo k úpravě generovaného HTML kódu pro obecného klienta (již pouze nový nový design) tak, aby výsledné kód byl validní z hlediska struktury i z hlediska W3C norem.
  
  
• Aplikační server - Přidávání uživatelských akcí
  Při přidávání uživatelských akcí do formuláře (i v jejich kontrole) se počítalo s tím, že forma bude mít další vlastnosti (jméno, akci, …). V některých formulářích je však HTML forma uvedena bez dalších atributů a do těchto stránek se uživatelské akce nepřidávaly.
  Opraveno v technologii z 21.2.2020.
  
  
• Klientská komponenta - Ověření digitálního podpisu importovaného ISDOC dokumentu
  Při importu ISDOC(X) souborů od některých dodavatelů docházelo k chybě při ověření digitálního certifikátu, jímž byl dokument podepsán. Nepomohla ani instalace kořenového certifikátu dané certifikační autority, která certifikát vydala.
  Na vině byla změna implementace kanonické transformace při práci s klíčem digitálního certifikátu, ke které došlo v Microsoft .NET Fw mezi verzí 3.5 a 4.0. Uvedená změna si vyžádala změnu způsobu inicializace signatury XML dokumentu.
  Dalším prvkem opravy je instalace opravy bezpečnostní záplaty, viz https://support.microsoft.com/en-us/help/3148821/after-you-apply-security-update-3141780-net-framework-applications-enc.
  Oprava bude dostupná v příští verzi klientské komponenty pro Internet Explorer.
  
  
• Aplikační server - Akce ze záhlaví formy lze ukládat do konfigurace
  Akce ze záhlaví formuláře (obecně vše z Caption HTML předlohy) lze nyní uživatelsky vybrat, přeskládat a výsledek uložit do konfigurace.
  Dialog pro konfiguraci lze najít v menu - konfigurace - výběr položek a akcí. Výběr akcí je konzistentní se stávajícími konfiguracemi zakázaných akcí, tj. je-li daná akce ve formuláři zakázaná, nenabízí se k zobrazení v záhlaví formuláře. V akcích v záhlaví formuláře lze libovolně kombinovat akce typu odkaz i tlačítko. Pokud je ve formuláři uloženo pořadí akcí, má přednost před akcemi definovanými v HTML předloze.
  Tato konfigurace je dostupná pouze v novém designu obecného klienta. V původním designu a ve starém klientovi (Internet Explorer) tento typ konfigurace uveden není a případně uložená konfigurace nemá na zobrazení akcí v záhlaví formuláře žádný vliv.
  Dostupné v technologii od 5.3.2020.
  
  
• Klientská komponenta - Komunikační protokol HTTP ve starém klientovi
  Klientská komponenta pro Internet Explorer (tj. starý klient) používal při HTTPS komunikaci protokol TLS1.0 (netýká se komunikačního protokolu REMOTE, pouze HTTP). Pokud se protokol TLS1.0 vypnul, komunikace klientským protokolem HTTP(S) nefungovala a bylo třeba použít protokol REMOTE.
  Vyřešeno ve verzi klienta 6.0.2 explicitním přepnutím na protokol TLS1.2. Na seznamu podporovaných klientských OS se nic nemění, na klientské stanici pouze musí být nainstalován i .NET Framework v4.6 nebo novější.
  
  
• Aplikační server - Hromadný tisk sestav z obecného klienta
  Při hromadném tisku sestav s parametrem RepeatFor=Query/All docházelo v sestavách s datovým zdrojem typu akce k provedení této akce (resp. jejího SQL příkazu) i na řádku, ze kterého se tisk volal. Tento řádek přitom nemusel být označený, tj. akce se provedla i pro větu, pro níž se provést neměla.
  Opraveno dostupná v technologii od 7.3.2020.
  
  
• Aplikační server - Include v uživatelských akcích
  Pokud se uživatelskou akcí vložila do formuláře sekce s includem (tj. <%$INCLUDE:stránka.htm%> ), neprovedlo se již vyhodnocení tohoto include a nahrazení příslušným HTML kódem. Nově se i v uživatelských akcích include vyhodnocuje a nahrazuje.
  Dostupné v technologii od 11.3.2020.
  
  
• Reporting Server - Datové zdroje typu "Akce"
  Do Reporting Serveru bylo doplněno zpracování datových zdrojů typu "Akce" u generátorových sestav.
  Dostupné od verze 6.0.0.5.
  
  
• ESO9lib.dll
  Přidána možnost stažení informací o subjektech z rejstříku BIR. Jde o název subjektu, adresu, obory činností.
  Informace lze rovnou aktualizovat nebo si je nechat jen vypsat.
  
  
• Aplikační server - Tisk sestav do JPG
  Pokud se z obecného klienta tiskla sestava do formátu obrázku JPG a obsahovala více stránek, uložil si je Stimulsoft do několika souborů namísto do jednoho. Názvy souborů si sám čísloval od 1 do počtu stránek. Důsledkem bylo, že se sestava nevytiskla do souboru s očekávaným jménem a při odeslání výsledku na klienta tento soubor nebyl nalezen a tisk skončil chybou.
  Opraveno v technologii ze 7.4.2020.
  
  
• Aplikační server - Odesílání e-mailů z obecného klienta
  Ve vygenerovaném EML souboru s e-mailem z obecného klienta nebyly vidět adresy uvedené jako slapá kopie (BCC). Na vině byla chyba mezi .NET Frameworkem, v němž se EML soubor vygeneroval, a MS Outlookem, který ignoroval část takto vygenerovaných příjemců. Výsledný soubor tak bylo třeba dále upravit tak, aby syntaxe vyhovovala MS Outlooku.
  Dostupné v technologii od 23.4.2020.
  
  
• Aplikační server - Optimalizace rychlosti
  Došlo k mírné optimalizaci rychlosti technologie. Běžné klientské operace (v obou klientech) se zrychlily cca o 5-7%, tisky sestav z obecného klienta pak zhruba o 15%.
  Dostupné v technologii z 24.4.2020.
  
  
• Aplikační server
  Do obecného klienta byla doplněna další práce s IDC/HTX sestavami, která je dostupné ve starém klientovi.
  Jedná se o tisk sestav a jejich odesílání e-mailem.
  Tisk sestav je realizovaný náhledem v prohlížeči, který si sám naformátuje HTML sestavu a nabídne jí k tisku.
  Odesílání sestav je realizováno stejně, jako v případě generátorových sestav typu Stimulsoft. Parametry pro práci s e-mailem se tedy nastavují v aplikačních parametrech ve skupině EMAIL, povinný je pouze parametr s názvem SMTP serveru. Sestava se vygeneruje jako příloha e-mailu, který se nabídne uživateli k otevření v jeho mailovém klientovi. Parametry mf_SendMailTo, mf_SendMailSubject a mf_SendMailBody lze vyplnit jednotlivé části mailu stejně, jako v případě Stimulsoft sestav.
  Výhodou oproti starému klientovi je:
  * možnost kompletně parametrizovat e-mail z odkazu,
  * fakt, že příjemce dostane sestavu naformátovanou stejné, jako ji odesilatel vidí na monitoru (styly jsou přilinkované v HTML sestavě a odkazují na vnější web Podpory, který je dostupný odevšad),
  * sestavu lze odeslat buď jako přílohu, nebo jako tělo mailu (řídí se parametrem SendByMail=1/2 na odkazu). Jedná se o rychlejší variantu odesílání mailů z ESO9, než při použití Stimusoft sestav, které se generují déle.
  Dostupné v technologii od 30.4.2020.
  
  
• Aplikační server - Tisk sestav s obrázky z obecného klienta
  Při tisku Stimulsoft sestav s obrázky v datových zdrojích z obecného klienta mohlo dojít k duplikaci obrázku i do řádků, kde žádný obrázek (resp. jeho GUID) nebyl nebo byl chybný.
  Opraveno v technologii z 12.5.2020.
  
  
• Aplikační server - Pojmenování souboru se sestavou
  Do obecného klienta přibyla možnost pojmenovat soubor se sestavou (např. XLS) při jejím nahrání (uploadu) na klienta.
  Pokud se do parametrů sestavy (nebo na její URL) přidá mf_FileName, uloží se výsledek do takto pojmenovaného souboru na serveru. To funguje stejně v obou klientech už léta. Ve starém klientovi to byl jediný způsob, jak uložit sestavu do pojmenovaného souboru.
  V obecném klientovi ale chyběla možnost jen nahrát soubor na klienta a pojmenovat jej (tato možnost ve starém klientovi neexistovala). Pokud bude v parametru mf_FileName jméno souboru se sestavou a zároveŘ bude na odkazu uveden parametr ClientPrint=1, pojmenuje se soubor nahrávaný na klienta požadovaným způsobem.
  Dostupné v technologii od 16.5.2020.
  
  
• Aplikační server - Tisk sestav do PDF
  Při tisku sestav z obecného klienta do formátu PDF (PrintDest = STIPDF) se tisk realizoval do celé záložky prohlížeče. Pokud si to uživatel neuvědomil a po vytištění záložku zavřel, zavřel vlastně celou aplikaci ESO9.
  Nově se tisk do PDF provádí pouze do hlavního pracovního okna/panelu v aplikaci ESO9 a uživateli tak zůstává k dispozici celá navigace. Tisk do PDF je žádoucí pro sestavy typu "výstupní doklad", které se posílají na tiskárnu; sestavení PDF formátu je zhruba 2x rychlejší, než tisk do standardního HTML formátu.
  Dostupné v technologii od 22.5.2020.
  
  
• Aplikační server - Automat pro synchronizaci obsahu Google Drive s DMS ESO9
  Do technologie ESO9 byl doplněn automat pro synchronizaci obsahu Google Drive s DMS ESO9.
  Vybrané dokumenty z DMS ESO9 lze automaticky (a oboustranně) synchronizovat s vybranými složkami na Google Drive. Otvírá se tím možnost hromadných exportů a importů v obecném klientovi i pro uživatele, kteří nemají přímá přístup k databázi (typicky provoz v cloudu).
  Import i export obsahuje možnost spouštění uživatelských procedur, jimiž lze ovlivŘovat či definovat další akce prováděné během nahrávání souboru na Google Drive či jeho stanování do DMS ESO9. Např. po uvedení dokladu do příslušného stavu jej lze na pozadí automaticky vyexportovat do požadovaného formátu a ten uložit na sdíleném Google Drive, nebo naopak soubor z Google Drive automaticky přenést do DMS ESO9 a spustit nad ním např. import přijatých dokladů, jehož výsledkem bude rozúčtovaná přijatá faktura.
  Práce se soubory nemusí probíhat na Gogle Drive, synchronizované složky si lze namapovat na vlastní lokální disk.
  Podrobnější informace a vlastní automat jsou k dispozici na vyžádání.
  
  
• Aplikační server - Obarvení při editaci
  Pro obarvení tlačítka a nadpisu formy při editaci dat byl použit odstín oranžové namísto původní červené.
  
  
• Aplikační server - Předávání parametrů typu datum
  V technologii došlo ke změně způsobu reprezentace a předávání datumových parametrů mezi formuláři a sestavami.
  Dosud se datumy předávaly několika různými způsoby, přičemž v jednom scénáři to způsobovalo v CZ legislativě otočení měsíce a dne. Sjednotil jsem proto formáty všech datumových parametrů dle aktuálně nastaveného jazyka uživatele. Předává-li se tedy někde datum textově (vhodnější je samozřejmě předávat jej jako datový typ DateTime, kdy k žádné konverzi nedochází), konvertuje se do/z formátu dle aktuálního jazyka uživatele. V češtině je bohužel historická výjimka, kdy se pro připojení k SQL serveru v CZ legislativě používá angličtina a z toho vyplývající formát datumu „MM.dd.yyyy" nebo "MM/dd/yyyy" (obojí je platné).
  Změna je dostupná od 22.6.2020.
  
  
• Aplikační server - Výkonové logování
  Do výkonového logování byla přidána celková doba generování Stimulsoft sestav pro obecného klienta. Jednotlivé datové zdroje sestavy + servisní procedury pro obsluhu generátoru sestav se již do výkonového logování zapisují, chyběla však informace o celkové době serverového renderování sestavy.
  Tento záznam nezahrnuje dobu nutnou k vyrenderování sestavy na klientovi (doba potřebná k vykreslení HTML kódu sestavy na klientovi je velmi závislá na aktuálním výkonu klientské stanice).
  Dostupné v technologii od 25.6.2020.
  
  

Technologie ESO9 - server

Změny v ESO9 Správce

• Nová aplikace
  Při vytvoření nové aplikace ve Správci ESO9 se již nekopíruje stránka "defaultIE10.htm" do aplikačního webu.
  
  
• Stahování doplŘků
  ESO9 Správce, verze 6.0.3
  V Nástroje / Nastavení programu / doplněno nastavení proxy serveru pro stahování doplŘků. Ukládá se do lokální konfigurace programu, heslo se šifruje.
  
  
• Spouštění skriptů
  ESO9 Správce, verze 6.0.3
  Při souběžném spouštění skriptů se skryje panel s protokolem. Dojde ke zrychlení spouštění, zamezí se chybám zápisu do protokolu. Po skončení se panel s protokolem zobrazí.
  
  
• Statistika přihlášení
  ESO9 Správce, verze 6.0.5
  Do statistiky přihlášení doplněn sloupec OK, s hodnotou 1 = uživatel se přihlásil přes obecného klienta, 0 = uživatel se přihlásil klient pro Internet Explorer, nic = informace není známa nebo ještě nebyla logována