Je to trochu nemilé, ale opravdu jsem kontrolu duplicity variabilních symbolů u přijatých faktur nedělal. Ani u vydaných. Ovšem tady to asi není úplně až tak závažný problém.
Systém prostě dovoloval zaregistrovat do knihy závazků jednu fakturu dodavatele dvakrát. Což může vést k dvojí úhradě jedné faktury.

Od této verze to už bez souhlasu uživatele nebude možné. Systém zkontroluje, zda záznam faktury v knihách závazků se shodným variabilním symbolem a shodným partnerem neexistuje. A protože život je pestrý a v některých případech mohou existovat závazky se shodným VS, systém se dotáže, zda je to překlep, nebo opravdu je ten variabilní symbol u partnera účelně použit dvakrát i vícekrát. Jako příklad takové situace si můžeme uvést splátkový kalendář, nebo faktury T-mobile, které se uhrazují se shodným VS. V takovém případě je každá rada drahá a nezbývá než zkontrolovat duplicitní záznamy, zda ten duplicitní záznam je zapisován oprávněně.

Standardně se při prodeji v restauraci používá aktuální ceník, který obsahuje všechny ceny nápojů a jídel podávaných v restauraci. Toto je standardní situace. Ovšem mohou existovat případy, kdy pro určitá zboží v určitých situacích má být použita upravená cena. Co s tím, když číšník nemá kompetenci stanovovat cenu při prodeji? Používá předepsaný ceník a nesmí se od něj odchýlit jakýmkoliv směrem.

Tak jsem "vymyslel" individuální ceník pro daný stůl a podle tohoto ceníku se odnáší nápoje či jídla k danému stolu a za takto definované ceny se prodává.

Samozřejmě není nutné vytvářet celý nový ceník. Protože určitě se upravené ceny netýkají veškerého sortimentu, ale jenom určitého výseku, který je k danému stolu dodáván s jinými cenami. Takže stačí vytvořit ceník s podřízeným ceníkem a do něj uvést ty ceny, které jsou odlišné od standardního ceníku. Pokud v něm systém položku nenajde, sáhne si do "podřízeného" ceníku pro standardní cenu.

Z dat prodejů na zařízení "Markeeta" jsou promítnuta do dodacích listů. Excelovský formát z portálu Markeeety přenesen v podobě denních prodejů do jednotlivých DL dnů v měsíci.
UniCredit měnila nějaké SW pro import souborů s příkazy k úhradě a dosud přijímaný formát ze systému LogisTIS vykázal chybu formátu. Chvíli trvalo, než jsme spolu s lidmi z jejich supportu přišli na to, že jejich nový SW očekává za posledním hodnotovým řádkem ještě jeden úplně prázdný řádek.

Nějak jsem si neuvědomil, že DPH je živý proces a mohou být prováděny doplňky do konstrukce DPH. Konstrukce KH jsem vytvářel jenom jednou a už ji nechával neměnnou, což není úplně v pořádku, když si jeden uvědomí, že vazba evidence DPH na KH je dost zásadní.

Takže jsem doplnil do tvorby konstrukce KH automatické doplnění nezařazených (nových) prvků z konstrukce DPH.