Vlákno názorů k článku Jak na účetnictví na Linuxu (2) od Pajosh - Zajištění číslování účetních záznamů je možno na postgresql...

Zajištění číslování účetních záznamů je možno na postgresql řešit pomocí sequence namísto zamykání tabulky ei_poradi a blokování ostatních konekcí:

CREATE SEQUENCE ei_poradi START 1 INCREMENT 1;

Potom by účetní transakce mohla být zapsána následovně za pomocí nextval() a currval():

-- začátek účetní transakce
begin;
insert into ei_popis (cislo, popis)
values (nextval('ei_poradi'), 'Zkouška');
insert into ei_denik (cislo, mdd, ucet, anal, castka)
values (currval('ei_poradi'),
'M', 221, 100, 24000);
insert into ei_denik (cislo, mdd, ucet, anal, castka)
values (currval('ei_poradi'),
'D', 600, 100, 24000);
update ei_hlkniha set zustatek_md=zustatek_md+24000
where ucet=221 and anal=100;
update ei_hlkniha set zustatek_dal=zustatek_dal+24000
where ucet=600 and anal=100;
commit;

POZOR!
Má to však jeden vedlejší nepříjemný efekt, kvůli kterému autor tento mechanismus pravděpodobně nepoužil. Rollback transakce nezruší povýšení hodnoty sequence a v číselné řadě proto mohou vznikat mezery. Protože neznám zákon o účetnictví, nevím, jestli je to přípustné, nicméně mechanismus je dobře využitelný obecně, např. při automatickém číslování záznamů za použití DEFAULT.

Postgres tuším přiděluje jedné transakci dokonce celý blok čísel v sekvenci. Takže přistupovalo by se k sekvenci najednou vícenásobně, mohla by databáze vygenerovat číselnou řadu 100, 200, 300, 400... tedy nic, co by se nám líbilo. Přesné detaily už si nepamatuji. Také proto je použitá tabulka, nikoli sekvence.

Jen doplnění:

velikost alokovaného bloku je určována při vytváření sekvence parametrem CACHE, defaultně CACHE 1, což zaručuje časovou souslednost v přidělování pořadí jednotlivým procesům (nemůže např. vznikat pořadí 100,200,201,101,... dle časové posloupnosti), nicméně zamezení mezer v pořadí zabráněno není.

Je také pravda, že sekvence jsou specifickou věcí postgresql, oproti navrženému řešení, které je implementovatelné všude.

Co sa tyka cislovania dokladov podla Slovenskeho zakona (neviem ako je na tom cesky ale myslim ze este stale rovnako)staci aby nasledovali cisla v nejakej postupnosti, akej to myslim nikde nie je definovane takze by tam kludne mohli byt aj medzery. Na druhej strane sa danova kontrola(mam vlastne skusenosti) vzdycky pozera tam kde su podozrive medzery, ktore sa daju casto velmi dobre vyuzit.

Vid kto niekedy programoval na 8-bitoch v Basicu bolo dobre si vynechavat cislovanie riadkov aspon po desiatkach ak nie stovkach aby sa tam neskor dalo nieco vlozit. Uctovnictvo funguje rovnako a skusene oko vidi v postupnosti ci tam nieco bolo pridavane po desiatkach alebo po jednotkach takze dokaze odhalit skutocnu casovu naslednost toho ako a kedy bolo co pridavane.

Ale neodpustim si este jeden malicky detail. Pokial ide o PU jedna sa takmer vzdy o nejaky insert dvoch rovnakych hodnot na nejake dva rozne ucty ktore mozu byt kludne v jednej datovej tabulke. Je zrejme ze keby doslo iba k jednemu insertu dost by to narusilo integritu celeho uctovnictva. Uznavam ze tu maju transakcie svoje opravnenie.

A preco stale o tych transakciach? PU ide po jednotlivych polozkach, resp. po riadkoch. Lenze mnohe ine veci napr. sklad ide po celych davkach udajov. Teda napr na jednej prijemke alebo vydajke mam 20 roznych tovarov. Ak si pozriete ako vyzeraju mnohe ine ucto softy tak je tam dost casto oddeleny sklad od ucta. A implementacia napr skladu pre multiuser je preto o dost narocnejsia a casto velmi neefektivne prevedena. V skutocnosti je vo firmach casto len jeden uctovnik, ktory robi uctovnictvo, teda jednotlive prevody na ucty. Ostatny potrebuju len vystupy (cash flow, zisk, pohladavky,...). Pre jednoho cloveka multiuser interface netreba. Pre celu firmu a ich informacny system uz ano. Bohuzial zatial som sa nikde nedocital o tom ako to IS za miliony korun riesia, lebo tie male a cenovo alebo "demo" dostupne to jednoducho neriesia a tie drahe to strazia ako firemne tajomstvo alebo autorskym zakanom.

To co sa vacsinou opisuje je nieco o tom ako funguje PU. Na zaklade tychto popisov by si vela pocitacovo gramotnych ludi vedelo narobit par tabuliek a uctovat v lubovolnom tabulkovom procesore alebo pomocou SQL nad hociakym DB-serverom. Vtip je v tom ze firmy nechcu uctovnictvo ale Informacny System postaveny na uctovnictve.

Analyza pripadne riesenie je vec dost zlozita. Kto neskusil neuveri. Kto skusa bol by som rad aby sa mne alebo nam z tucniak developer teamu ozval a podelil sa s nami o svoje skusenosti. Viem ze bolo pod GPL zacatych mnoho projektov ale neviem o ziadnom ktory by momentalne stale napredoval. Dufam ze ten nas to dotiahne trosku dalej.

Cisla ze sekvenci by se (i z uvedeneho duvodu) nemela pouzivat pro id "viditelna" uzivatelem systemu, ale vyhradne pro vnitrni identifikaci zaznamu s tim, ze viditelne cislo se dopocte a jeho jedinecnost zajisti jinak (napr. ulozenou procedurou) na konci transakce.

Číslování dokladů ani v IS za milióny není v zásadě
věcně nic složitého. Takových mi prošlo rukama
poměrně hodně a ty vyspělé dávají uživateli
v podstatě shodný konfort v tomto duchu.

- Většinou se jedná o rozdělení jednoznačného
identifikátoru dokladu, pro zajištění jeho
relačních vazeb zejména vazby mezi hlavičkjovými
a řádkovými záznamy do doby jeho potvrzení
a přidělení finálního uživatelského čísla
podle metody nastavené většinou v uživateslkých
definicích dokladových řad. Tyto dokladové řady
bývají většinou mocné definiční nástroje, které
umožňují podnikovému metodikovi určit vlastní
systém číslování dokladů dle těchto kritérií,

- samostatné dokladové řady podle:
- druhů dokladů
- organizační útvarů
- Metody generování dokladů, které umožňují
maskovat:
- roky vzniku dokladu např. masky RRRR , RR, R
- Měsíce vzniku dokladu MM , M
- Kódy středisek,
- Kódy druhů dokladů, DD
- výplňové znaky nejčastěji pevný počet nul zleva
do ikrementu,
- Kroky ve kterém kráčí inkrementy dokladů

- Metody implicitních vlastností dokladových řad
jako:
- možnost mazání dokumentu uvnitř řady
- podpora vyplňování děr
- podpora dokumentování děr v číselných řadách
- Inicializace dokladové řady na počáku měsíce
- Inicializace dokladové řady na počáku roku
- Nastavení implicitních hodnot pro údaje
v dokladech, které jsou pro doklady v řadě
chrakteristické
- přítupová práva uživatelů k řadám a další.

Z hlediska národní legislativy, je třeba říci,
že ač se to nezdá používání souvislých řad je
v zásadě jednou ze základních technik jak účetní
jednotka (to je zákonem o účetnictví definovaná
kategorii označující osobu povinnou vést
účetnictví) může naplnit zásadu průkaznosti.
Je základních metod účetní kontroly (auditu)
a daňové kontroly dle zákona o správě daní
a poplatků je tato technika nosná. Ze zákona
o účetnictví tato povinnost vyplývá pro účetní
jednotku nepřímo tím, že je povinna průkaznost
zajistit a to vydáním interní normy. Zde se
většinou jedná o interní směrnici typu
"Oběh Dokladů". Pokud takovéto řešení neexistuje
(velmi často) může nezávislá kontrola z tohoto
důvodu považovat evidence za neprůkazné s pokutou
ve výši miliónů korun.

Z hlediska samotné SQL databáze osobně očekávám
pro uživatelské číslování pouze to, že mi robusně
zajišťuje nemožnost založení dvou dokladů se
stejným primárním klíčem. Je na tvůrci nástroje
aby dovedl správně oštřit stavy, kdy do stejné
dokladové řady pořizuje najednou libovolný
počet uživatelů, což souvisí se správně zvolenou
politikou uzamykání záznamů a dalšími souvisejícími
okruhy otázek. V IS Economy je definice dokladových
řad, ale i jiných číslených řad napříkald
přidělujících pořadové nebo systémové klíče,
partnerům, výkonům, výrobkům a položkám zásob
jeden z nejsilnějších rysů definice systému.
Karel

Len taka otazka. Vystavim fakturu, niekto ju nechce uhradit tak ju stornujem a vymazem. Videl som to dost casto v praxi. Nasledne tak vznikne diera v cislovani faktur, pretoze som samozrejme medzi casom vystavil dalsie.

Co potom? Je stornovanie a vymazanie protizakonne. Vela uctovniciek mi povedalo ze nie. Ma niekto opacny nazor. Myslim, ze prave toto je dost casty argument na obhajenie nesuvislej rady.

Inak urcite som za to aby DB cislovanie bolo oddelene od ucto-cislovania dokladov.