Úvodní poznámky k novému saldokontu

Sepsal jsem několik úvodních poznámek k novému saldokontu, které by mělo řešit několik věcí:

  • Lepší práce s cizí měnou a kurzovými rozdíly
  • Lepší uživatelské rozhraní (přechod od sestavy k prohlížeči)
  • Možnost definice saldokont uživatelem
  • Konzistentní práce se saldem na úrovni řádku dokladu - dnes je to chování místy nejasné až chaotické.
  • Vylepšit zpracování párování došlých plateb.

Co bude potřeba udělat:

  1. Do účetního deníku přidat cizí měnu. To je největší problém celé operace; samotné přidání a naplňování je snadné, otázka je, jak se postavit k historickým datům.
  2. Saldokonta se musí dát uživatelsky definovat - zároveň by měla existovat “systémová” saldokonta (závazky, pohledávky), která se automaticky “objeví” v definici saldokont. Součástí definice saldokonta musí být:
    • Složení párovacího symbolu
    • Teoreticky by se mohlo dát ovlivnit, jak se bude grupovat účetní deník - zásobová saldokonta typu nevyfakturované výdejky budou asi potřebovat účetní deník s Položkou. Možná by to mohlo být na účtu - ale to by bylo hodně náročné na nastavení. Asi by stačilo, když by součástí grupování byly automaticky všechny údaje z párovacího symbolu.
  3. Na účtu se musí dát nastavit, do kterého saldokonta patří. Je otázka, jestli může mít účet více saldokont. Myšlenka je to lákavá, ale není jasné, jestli to má vůbec nějaký smysl.
  4. Je otázka, jestli by se saldokonto na účtu nemělo brát hierarchicky z třídy nebo syntetiky. Výrazně by to zjednodušilo [nejen] úvodní nastavení.
  5. Saldokonto se musí generovat pouze z účetního deníku. Případná potřeba dělání saldokonta z “neúčetních” dokladů by se řešila účtováním těchto dokladů na podrozvahových účtech.
  6. Účetní deník musí projít revizí a možná bude potřeba doplnit některé sloupce pro analytické členění a naturální účetnictví (množství, jednotka). Je otázka, jestli by jednotka měla být součástí “grupování” účetního deníku.
  7. Saldokonto by mělo mít hlavičky (v podstatě pouze párovací symbol) a řádky. Vyřeší se tím několik věcí:
    • Saldokonto půjde udělat jako prohlížeč. Současná podoba tiskové sestavy je hodně omezující.
    • K saldokontním případům půjde dělat něco jako poznámy nebo dokonce přímo issues. Je to trochu nejasné, jak by to fungovalo, protože místo vazby přes primární klíč se bude muset použít párovací symbol - ale asi je to řešitelné.
  8. Saldokonta by měla mít nějaká upozornění nebo notifikace. Např. saldokonto Příjemky bez faktury spousta lidí totálně ignoruje a na konci roku jsou překvapení, co tam všechno visí. Kdyby tam byla nějaká “bublina”, tak by se to dalo řešit dřív.
  9. Je potřeba vylepšit uživatelské rozhraní související se saldem:
    • Umožnit jednoduše zobrazit “rozpad” saldokontního případu
    • Zrevidovat zobrazení stavu úhrady dokladu (v detailu dokladu a na některých jiných místech) - v současné době je to zmatené.
    • Zvážit možnost generování převodních příkazů přímo ze salda.
    • Zobrazovat nejen převodní příkazy, ale i transakce z banky.
    • Upozorňovat na potřebu úhrady závazků, u kterých se blíží splatnost.

Největší problém je, jak se postavit k nějakému “verzování”, respektive nastavování platnosti od - do.
V současné době se to nijak neřeší a pokud se vypne/zapne saldokontnost během účetního období, tak z toho vznikají problémy.
Asi jako první by se mělo dořešit přegenerování saldokonta:

  • Pokud by to dobře fungovalo, tak by to řešilo spoustu problémů - po úpravě nastavení by se saldokonto “opravilo”.
  • Není úplně jasné, která účetní období by se měla přegenerovávat.
  • Existuje názor, že uzavřené období musí zůstat tak, jak jsou.
  • Na druhou stranu je tu otázka, proč by to tak mělo být. Držet v čase více nastavení saldokonta v podstatě nedává žádný smysl a způsobí to nakonec víc škody než užitku.
  • Je jasné, že to má určité důsledky (otevření období apod.) - ale pokud bude saldokonto správně nastavené, tak přegenerování nemůže způsobit nic špatného.
1 Like

Možná by neškodilo vyjmenovat jaké funkce SALDOKONTO má:

  • Evidovat saldokontní případy, které tvoří většinou zaúčtované zápisy z primárních dokladů
  • Evidence by měla v podstatě obsahovat všechny atributy saldokontní transakce z primárního dokladu, proúčtované a evidované také v účetním deníku
  • Vytvářet podklady pro dokladové inventarizace účtů ke dni
  • Evidovat údaje pro platební styk
  • Poskytovat podklady a nástroje pro Párování transakcí i nesouvisející s platebním stykem pro agendy: Peníze na cestě, Časové rozlišení, Pořízení majetku a zásob
  • Poskytovat podklady pro hromadné automatické operace a agendy typu: Kurzovní rozdíly, Haléřové rozdíly, Odpisy pohledávek a závazků

POJMY a TERMINOLOGIE

  • Saldokontní případ je jedinečně identifikován Párovacím symbolem a doplněn o popisné, sumační, časové a stavové údaje;

  • Párovací symbol by se měl ideálně skládat ze zřetězení alespoň: Analytický účet_Osoba_BankovniSpojení_VS_SS_KS

  • Zápisy se dají rozdělit na dva základní typy Předpis a Vyrovnání a ty je možno odvozovat od povahy analytického účtu (Aktivní mají předpis na MD, Pasivní na DAL) ale uživatel by si v transakci měl mít možnost vybrat, za co se transakce považuje

Add 1) Měnu včetně obratů v CM včetně použitého kurzu

Add 2) Deník s položkou to jsou pohyby na skladových kartách, To bych do účetního deníku primárně netahal pro potřeby zásobového saldokonta se většinou páruje tzv. účet pořízení a saldokonto hlavně pak jako saldokotní případy, kdy se párují nákupní a prodejní doklady s pohybovými doklady zásob. Možná by zde měla být také řešena otázka skladů na hlavičce a řádku dokladu;

Add 3) Osobně bych vždy volil zásadu Jeden účet - právě jedno saldokonto, raději víc účtů pro různé účely

Add 4) Obecně bych uvítal mít možnost na syntetickém účtě (resp. nařízené TR, SK, SU) ne jen výchozí saldo, ale i jiné povinnosti, restrikce a přednastavení třeba dimenzí, Často je tam i výchozí jediná Osoba nebo Skupina Osob. Už by jsme mohli i doplnit ty Naturální ukazatele. A tyto dědit do Účto-položek

Add 5) 100% souhlas, tedy máme vyřešeno, že se vždy jedná o účetní saldokonto ke konkrétnímu účtu

Add 6) Ty NATURÁLNÍ UKAZATELE jsou potřebné (z mé zkušenosti) pro účely statistických výkazů, evidence provozu strojů (Položek majetku), kde např. z evidovaných KM a spotřebovaných Litrů PHM je možno odvozovat skutečnou spotřebu; Pro výkazy energií jsou potřeba MWh přepočítávat na KWh, GJ, m3; Pro výkazy PRUM zase produkty (Položky) přepočítávat z našich MJ na Statistické

  • S tím souvisí i možnost zadávat tyto údaje na řádcích dokladů, ideálně v tzv. rozúčtovacím účetním okruhu, kde se to nebude komplikovat s DPH.

Add 7) Hlavička Saldokontního případu by měla mít vedle párovacího symbolu, i ty atributy, které párovací symbol tvoří z důvodu řazení a filtrování a také by měla mít možnost sumace za saldokontní případ ve struktuře Předpis, Vyrovnání a Zůstatek v Cizí i Domácí měně a pak nějaké saldokontní (workflow) stavy, které umožní vidět a vyčíslit:

  • Vidět rozpad v účetním pohledu MD, DAL, BILANCE
  • Nevyrovnaný zůstatek v obou měnách
  • Haléřový rozdíl
  • Kurzovní rozdíl
  • Počet dní po splatnosti u platebních saldokont
  • Návrh na započtení nebo odpis (možná štítky ?)
  • Schvalovací procesy pro: Platební styk, Odpisy, Odsouhlasení s Dlužníky a Věřiteli
  • Odkazy do Upomínek a Penalizace
  • Poznámky k saldokontnímu případu (zprávy)

Add 8) Všemi deseti

Add 9) Asi nosné bych viděl kompletní možnost fitrování a řazení a zejména výběr pro hromadné akce

Napadlo mne že by možná šlo na účtech tř. 6 sledovat úhrný obrat za posledních 12 měsíců pro povinné přihlášení k DPH které by upozornilo notifikací

Náhodou jsem zjistil, že neumíme udělat doklady vyúčtování kurzového rozdílu zálohy v cizí měně …

Ano obecně nestačí dělat kurzovní rozdíly jen u pohledávek a závazků, ale u všech transakcí v cizí měně. Tedy i u peněz na cestě. Pokud se pracuje s bankovními účty v CM a dělají se převody na účet v jiné měně je to v Shipardu neřešitelné

  1. Pořád ještě nedovedu pochopit, proč součástí párování v SHIPARDU není bankovní spojení Osoby. Nebo aspoň jeho předčíslí. Pokud by to šlo, určitě bych si udělala pro účty 34x a 336 speciální saldokonto, kde bych do párovacího symbolu dala bankovní spojení, nebo to předčíslí, které vždy znamená konkrétní dan nebo pojištění u pořád stejného základu a směrového kódu banky.

  2. Asi je chybou, že národní číslo bankovního účtu, není rozděleno na ty samostatné části jako je: Předčíslí-Číslo/SKB teoreticky ještě i SS aby se z nich dalo pro to párování použít jen třeba to Předčíslí. Ta současná metodika, kterou mi nutí Karel, že se dává Předčíslí do SS na začátek je docela nevkusná.

  3. Pokud už jsme u párování v saldokontě, vůbec mi zatím nedošlo, proč se vyrovnání, když je prázdný VS a SS nebo je tam třeba IČ, které používají instituce, napáruje na první předpis s tímto VS, i když záznam má jasného Partnera daného již zaevidovaným jedinečným bankovním spojením.

  4. Připadá mi to jako ten začátečnický princip programů jako POHODA, kdy primárně se páruje podle VS a ne kombinace Osoba (zjištěná z bankovního spojení) v kombinací s VS-SS-KS.

  5. Osobně bych raději viděla označení těchto transakcí v bance jako chybných bez VS nebo Bankovního spojení. A nabídla bych doplnění nového bankovního spojení do Osob, případně s podporou načtení banky z Registru plátců DPH včetně Osoby.

  6. Ostatně, proč Shipard, ještě nezakládá Osobu včetně možnosti vybrat zveřejněné účty v registru plátců DPH, včetně kontroly jejich platnosti tamtéž

1 Like

Souhlasím, to párování je smutný příběh. Asi není velký problém to vylepšit.

Zatím jsem to neudělal ze zbabělosti - nechtělo se mi řešit telefonáty lidí, kteří si budou stěžovat, že jim to začalo fungovat jinak.

Bude se to řešit.

Pořád ještě nedovedu pochopit, proč součástí párování v SHIPARDU není bankovní spojení Osoby. Nebo aspoň jeho předčíslí. Pokud by to šlo, určitě bych si udělala pro účty 34x a 336 speciální saldokonto, kde bych do párovacího symbolu dala bankovní spojení, nebo to předčíslí, které vždy znamená konkrétní dan nebo pojištění u pořád stejného základu a směrového kódu banky.

Já se to pokusím vysvětlit:

  1. momentálně existuje v aplikaci několik málo saldokont s tím, že platby na FÚ jsou součástí závazků. U závazků je zadrátované, že se páruje na základě Osoby, VS a SS. Pokud by se tam přidělalo jako párovací znak i bankovní spojení, tak to strašně zkomplikuje život pro normální párování běžných závazků. (Původní myšlenka před 10 lety byla, že saldokonto musí fungovat i bez účetnictví a účetního deníku, tato myšlenka je dnes již překonaná).
  2. úprava stávajícího systému je tedy komlikovaná a navíc s rizikem, že se něco pokazí na stávající funkčnosti.
  3. jestliže se nyní udělá úplně diametrálně odlišný systém saldokont, tak to půjde vyřešit a dokonce by si to podle mého názoru uživatel měl sám parametrizovat.
  4. já jen doplním, že problém s různými daněmi řeším osobně metodikou, že si naplňuji SS tak, že obsahuje předčíslí účtu daně a následuje rokem a měsícem, za který je předpis daně účtovaný…

Add 3) je ok
Add 4) hodně ruční zbytečné práce, když to řeší to předčíslí univerzálně. Tak by možná ještě pomohlo mít ho jako samostatný sloupec v evidenci bankovního spojení partnera, čímž neříkám aby tam nebyl i komplexně jako:

Predcisli-Cislo/Banka

Už nějak pokračuješ na těch nových saldech?

Ještě jsem si vzpomenul na dříve diskutované požadavky:

  1. umět v saldu přepínačem zobrazovat i spárované saldokontní případy
  2. mít možnost si k saldokontnímu případu napsat poznámku, která se bude třeba kliknutím na ikonu zobrazovat (např. poznámka typu, volal jsem si s ním a slíbil že brzy zaplatí :slight_smile: )
1 Like

Predunuto do noveho tematu

Pokud plán na Nové saldokonto zatím asi v nedohlednu, nebylo by možno se pokusit opravit práci se saldokontem na řádku dokladu.

Dnes jsem poprvé udělal to, že jsem si účtu časového rozlišení 381 založil nesaldokontní analytiku na konkrétní pojistnou smlouvu, kterou budu muset bez salda hlídat jen zůstatkem.