Názory k článku Jak na účetnictví na Linuxu (2)

Pokud si to jeste dobre pamatuji ze skoly - ucty se nedeli na aktivni a pasivni, ale na:
rozvahove - ty se pak deli na aktivni a pasivni
vysledkove - ty se pak deli na nakladove a vynosove
uzaverkove - KUR, PUR a UZZ

Velky rozdil mezi vysledkovymi a rozvahovymi ucty, ktery myslim je treba zohlednit je ten, ze na vysledkove ucty se neuctuje na obe strany uctu, ale
u nakladovych se uctuje jen na stranu MD a u vynosovych na stranu D. Zapis na opacne strany se defacto (i kdyz jsou i vyjimky) dela pouze pri prevodu na UZZ.

Rozhodne bych tedy u uctove osnovy drzel i priznak toho, jaky o jaky typ uctu se jedna, protoze pak lze zajistit i to, aby se treba pri ucetni uzaverce prevadely zustatky bud na konecny ucet rozvazny (u rozvahovych) nebo na ucet zisku a ztrat (u vysledkovych)

Jeste poznamka - v realnem provozu se velmi casto stava, ze jeden ucetni pripad, tvori vice zapisu na
ucty nez jeden zapis na stranu MD a jeden na stranu D.
To neni v navrhu struktury take zohledneno - typickym pripadem je uctovani DPH, kdy se u trzeb uctuje na ucet 311 na stranu MD a 343 a 60x na stranu D.

Nejsem si jisty, do jake miry ma byt tento serial
seriozni, takze nechci zbytecne remcat, ale tuto vec bych rozhodne take zohlednil.

Zohledněno to tam je. Není přeci problém zapsat do deníku k jednomu účetnímu případu obecný počet vět :-)

Tento přístup k vytváření účetních záznamů
by měl být standardem. Účetní zápisy, které
tvoří jako celem jedn účetní doklad mohou
mít v zásadě libovolný počet zápisů na straně
MD nebo na straně DAL, takovými komplikovanými
zápisy jsou například rozúčtování přijatých
faktur na stovky středisek, rozúčtování mezd
na zakázky, vzájemné zápočty pohledávek a
závazků, našlo by se stovky příkladů. je tedy
vhodné mít pro tuto koncepsi datovou strukturu
deniku takovou, že každý doklad je možno mít
neomezený počet záznamů. V rámci jednoho
účetního dokladu je třeba kontrolovat především
rovnost součtu stran MD a DAL.

Přijde mi, že jednou z výhod open-source sw je, že není třeba znovu a stále objevovat a tvořit věci, které už někdo vytvořil :(

Například docela zajímavé účetnictví - prakticky použitelné je sql-ledger (viz http://www.sql-ledger.com), které má už základní tabulky navržené.

Díky tristnímu stavu účetnictví v linuxu jsem si hrál s jeho počeštěním a musím říct, že v běžných věcech je naprosto postačující i pro vedení českého účetnictví. Leč nemám čas ani síly na nějaké jeho doplňování a rozšiřování (byť bych měl i myšlenky - jsem spíš účetní, než programátor)

Co tomuto účetnictví chybí jsou doplňkové moduly typu hmotný majetek etc. Nicméně, jak vidím snahy kolem účto-for-linux asi budou ještě nějakou dobu chybět, protože všem hodně času zabere znovuobjevení již objeveného, místo toho, aby někdo sedl a napsal k již existujícímu programu nějaké, byť i ryze národní, rozšíření.

Nelze nějakym zpusobem rozjet některé ze současných účetnictví pod emulátorem Wine? Mě se to teda nepodařilo. Testoval jsem Abru classsic,která mě postačuje svými parametry i ve Free verzi.

Pod wine jsem jednu dobu provozoval Money2000 - dnes je to jiz stara verze, ale IMHO z hlediska uctovani asi porad pouzitelna, ne?
Poznamka: Provozoval jsem verzi START bez hw klice...

Myslim, ze je velkou chybou vazat ucetnictvi na jednu databazi. Uvaha v clanku, ze neni vhodne resit logiku v aplikacni vrstve je chybna. Naopak, pak, pri trose snahy, to zajistuje moznost pouzit vice databazi, napr. v Jave pomoci JDBC.

Prevazna vetsina soucasnych SQL databazi podporuje integritni omezeni a transakce. A je opravdu zbytecne zabyvat se transakcemi v kodu vlastni aplikace, kdyz je podle SQL standardu ma databaze podporovat. Co me spis neni jasne, jak zajistit nejakym rozumnym integritnim omezenim, aby se u slozeneho ucetniho zaznamu rovnalo MD=D. Obavam se, ze to asi mozne neni.

Urcite by sa to dalo (MD=D). Predpokladam ze na vkladanie zaznamov bude pouzita ulozena procedura a ta by to riesila.

Teraz si nasypem popol nahlavu: neviem kedy (v ramci transakcie) sa vyhodnocuju integritne obmedzenia. Ale v pripade ze sa vyhodnocuju (pred) kazdym insertom tak MD=D sa neda zabezpecit klasickymi integritnymi obedzeniami. (najprv insertnu riadky pre MD a az potom D, teda chvilu je to ,,integritne'' nekorektne).

Pokud ve výsledné aplikaci předpokládáte, že
účetní bude pořízovat účetní případy
prostřednictví tzv. účetního dokladu, který
bude bude členěn na záhlaví a řádky (doporučuji)
bývá v našich účetních krajích zvykem, že při
editaci takovéhoto případu se kontroluje po
ukončení posledního záznamu a pokusu o uložení
celého dokladu vyváženost stran MD a DAL.
Dokonce se vžil pojem pro parametrizaci tohoto
procesu (kontrolvoat: Měkce|Tvrdě|Nekontrolovat).
Na to je možno s výhodou využít triggerů v SQL
databázi pokud je podporuje.

Dále bývá zvykem, že účetní doklad, který neobsahuje
vyrovnané účetní zápisy nelze uzavřít, pokud se
s takovými stavy jako doklad Pořízen | Uzavřen|
Schválen|Uzavřen pro DPH|Stornován|Opraven
ve Vašem systému počítá. Na to většinou navazuje
i tzv. institut uzavření účetního období, kdy se
předpokládá, že není možno uzavřít účetní období,
které obsahuje neuzavřené účetní doklady.

Některé systémy nebo jejich agendy (přijaté
faktury) umožňují automaticky generovat vyrovnávací
účetní záznam na k tomu předem určený účet k roz-
účtování (v nastavení účetního deníku implicitní
účet), jehož nenulový zůstatek na dokladě generuje
stav, že doklad je určen k rozúčtování (na střediska, zakázky, nositele nákladů) s velkou
tradicí v českém účetnictví se k takovémuto
účelu používají analytické účty 395.

Cas kontroly RF lze urcit dle definice ciziho klice. Napriklad u PostgreSQL se podivejte na definici REFERENCES a zazracna slovicka: DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE.

Kdyz uz se tu zminuji ruzne existujici systemy, mozna stoji za zminku i gnucash - je sice urcen pro domaci uzivatele spise nez pro firmy, ale umi docela dost.

www.gnucash.org

Me GNUcash trosku zklamal, zda se mi to strasne slozite. Existuje nejaka alternativa k MicrosoftMoney? To je software ktery se MS docela povedl, snad mi tam jen chybi moznosot mit jednotlive ucty v jinych menach (jak to umi GNUcash). Dik za pripadny tip.

Chcem sa trosku pridat do diskusie. Mnoho ludi zavrhuje MySQL kvoli tomu ze nema transakcie. Lenze tie nedokazu riesit vsetko.

V nasom projekte TUCNIAK sa chystame implementovat nieco, co by dokazalo zamykat jednotlive riadky tabuliek. Zatial neviem o ziadnom DB serveri ktory by to mal v sebe implementovane a tak ci tak by bolo potom potrebne previest tuto operaciu na stranu aplikacie. Ak to vyriesime, tak nam transakcie nebudu potrebne a kludne mozeme behat "kompaktne" aj nad MySQL.

Teraz naco je to dobre. Predstavte si priklad kedy mam obchodnu firmu a 5 obchodnikov, ktori aktivne pracuju so skladom firmy. Povedzme ze kazdy z nich obsluhuje v realnom case nejakeho zakaznika co znamena ze asi pol hodinu s nim diskutuje co chce nakupit a co nie a postupne tieto polozky pridava na vydajku resp. fakturu. Ak by som JEDNOU transakciou "zamkol" tabulku skladu, z ktorej zaroven vyskladnuju ostatni 4 obchodnici, mohlo by sa stat ze po pol hodine roboty, by mi aplikacia vratila hlasku ze transakcia vyskladnenia neprebehla uspesne pretoze jednoducho na sklade uz dane polozky nie su. Obchodnika by asi trafil slak, ak by ho medzi casom nezaskrtil zakaznik. Zaroven keby obchodnik nemohol pracovat so skladom len kvoli tomu ze v tom case s nim pracuje niekto iny tak by tych obchodnikov nemuselo byt 5 ale stacil by jeden.

Co sme navrhli my, je ze existuje nejaka tabulka, ktora si pamata nazov tabulky, ID riadku a usera ktory riadok zamkol. Takto dosiahneme to ze tabulka skladu bude pristupna cela a zamknuta bude vzdy len nejaka polozka s ktorou prave nejaky obchodnik pracuje. Samozrejme ostatni obchodnici tu polozku tiez vidia, ale keby s nou chceli pracovat tak sa im ukaze hlaska typu "momentalne s polozkou XY pracuje USER_YX, jej posledny aktualnuy stav bol Z-kusov". Takze uzivatel bude aspon tusit kolko toho je na sklade a ci je realne ze to USER_YX vsetko vyskladni. Povedzme pocka 3 min alebo posle USER_YX spravu "kedy uz skoncis zadavanie polozky XY:-)"
Atd.

Ak by niekto vedel nieco taketo urobit na strane servera tak uznam ze db-servery a jazyk SQL s transakciami su dobra vec. Ale zatial si take nieco fakt neviem predstavit na strane db-servera. Uznavam ze niekto by sa kludne mohol napojit na db aj inym klientom a robit sarapatu. Ale to by mohol aj tam kde su transakcie, takze kompaktnost db je podla mna vzdy tak trochu zavisla aj na samotnej Api

A este maly odkaz pre tych, ktorym sa nepaci management projektu TUCNIAK. Projekt som prezentoval prvy krat zaciatkom roka ako sucast mojej diplomovky a cely som ho postavil na GPL. Je lahke viest projekt ked ma na to clovek financie a cas. Omnoho tazsie je zhanat ludi ktori nieco vyvijaju na zaciatku zadarmo pod GPL. Takze uznavam ze preluskat sa jeho kodom a zacat implementovat vlastne moduly je momentalne fakt fuska. Ale na druhu stranu sa mozeme pochvalit resp. mozem pochvalit momentalne nasho hlavneho programatora
http://yenar.host.sk
za vytvorenie kniznic libco a libcwe, na ktorych je momentalne tucniak postaveny a ktore mozno v buducnosti najdu vyuzitie aj v inych GPL projektoch. A celkovo je navrh robeny tak ze az vyjde prvy funkcny release a dokumentacia ku kodu zakladnych modulov tak sa to cele rozbehne trosku rychlejsie.

http://www.postgresql.org/idocs/index.php?mvcc.html

http://www.google.com/search?q=row+level+locking

Prosim neobjavuj koleso.

Neobjavujem koleso. A citujem z:
http://www.postgresql.org/idocs/index.php?locking-indexes.html

Though PostgreSQL provides nonblocking read/write access to table data, nonblocking read/write access is not currently offered for every index access method implemented in PostgreSQL.

Co jasne hovori o tom ze zamykanie riadkov nie je implementovane.

Cele si to precitaj.

Oj, oj. Precti si to jeste jednou.

Nejen, ze PG ma row level lock, ale ma i multi-version system pro data v radcich coz je hodne advance :-) Pokud chcete neco o transakcich podivejte se na www.dbsvet.cz je tam informativni a prehledny serial prave na toto tema.

IMHO row level lock by mala mit i nejnovejsi MySQL v tabulkach InnoDB. Nezkousel jsem...

Pohybuju se v oblasti ucetnictvi pomerne dost dlouho a jiz znam nekolik systemu (teda mysleno programu). Tyto problemy se vsak nechaji pomerne jednoduse obejit pouze kratkodobym uzavrenim databaze - treba jen onoho skladu - kdy je do patricne radky skladove karty do kolonky nazvane treba "rezervace" zapsane odpovidajici mnozstvi objednanych jednotek. K jejich odpisu dojde az v okamziku vystaveni vydejky/prodejky/dodaciho listu. A pokud nekdo (jiny obchodnik) vstoupi do databaze, tak je mozne softwarove!!!! osetrit, ze sice vidi, ze je na sklade tolik atolik mnozstevnich jednotek, ale jsou rezervovane a muze kontaktovat druheho obchodnika pro blizsi informace.
A jeste jedna poznamka - vetsina ucetnich se zuby nehty drzi DOS-verzi ucetnictvi. Dost dlouho jsem se tomu divil, ale po zkusenost s verzemi pro WIN uz ne - mnoho policek neprehledne na pomerne velke plose, vetsinou barevne preplacane, odlisne ovladani od DOS-verzi a predevsim jista svazanost a omezeni moznych oprav.

Je pravda, že transakce nevyřeší všechno, ale tenhle problém si myslím dá vhodným datovým návrhem řešit.

Navíc jak je níže psáno, existuje row level locking

Co se mi ale na článku ze všeho nejvíce líbí je, že působí jako lehce pochopitelný tutoriál o tom, jak neuvěřitelně elegantně a jednoduše se dá zajistit integrita dat v případě, že DBMS k tomu dává k dispozici nástroje.

Tak jak byl tenhle díl pojat a s jak jednoduchým návrhem báze dat pracuje je taky krásně vidět, že i při řešení relativně jednoduché datové úlohy lze využít nástrojů pro zajištění datové integrity.

Já osobně tvrdím a stojím si zatím, že psát něco rozumnýho na DBMS bez těchto nástrojů je silně kontraproduktivní a neelegantní.

To, že PostgreSQL tyto nástroje má a zároveň je free bylo důvodem, že sem ABSOLUTNĚ vyloučil používání MySQL ... proč se ochuzovat o tyhle features, když se skoro u čehokoli, co časem roste může stát, že i když tenhle aparát z počátku nepotřebuji, tak při update funkcionality se najednou může stát, že referenční integritu potřebovat budu .. Oprogramovávat to všelijakejma brigulema a psaním tuny kódu? to mi připadne trochu divný...

Ale je to jen můj skromnej názor, nic víc - nic míň

>> Co se mi ale na článku ze všeho nejvíce líbí je, že působí jako lehce pochopitelný tutoriál o tom, jak neuvěřitelně elegantně a jednoduše se dá zajistit integrita dat v případě, že DBMS k tomu dává k dispozici nástroje.

Marku, myslím, že jsi první, kdo skutečně kápnul na to, proč jsem se do psaní tohoto seriálu pustil.

>Marku, myslím, že jsi první, kdo skutečně kápnul na >to, proč jsem se do psaní tohoto seriálu pustil.

Fakt ? :-) No sdělil jsem jen to, jak na mě ten seriál působí ...

... jde o to, že ale bohužel hodně lidí co pracuje v IT se na problematiku nedovedou podívat z abstraktního úhlu pohledu, což je myslím zásadní chyba...
Ale faktem je, že moje zkušenost je ta, že zpočátku na to čovek MUSÍ neustále upozorňovat, protože jinak se stává, že dojde k nedorozumění a začnou se jako "pointa" řešit detaily typu jestli má něco bejt ve dvou polích, nebo jednom :)

Já v rámci své profese na to narážím velmi často. Do mojeho jobu spadá mj. koncepce vývoje v našem podniku.

Zdravim, taky pridam par slov do diskuse:

myslim, ze Vas clanek mluvi o uplne jinem problemu nez o trasnakcich a integritnich omezenich.
Pokud jsem to dobre pochopil (a chapu to jako zpet na stromy se zamykanim radku v souborovych tabulkach), je cele reseni zalozene na "atomicke" operaci "vlozeni zaznamu do tabulky zamku", ze?
Slouzi ale pouze jako informativni charakter pro vasi aplikacni logiku. co se stane, kdyz jiny klient tyto pravidla dodrzovat nebude (jako ze v olbasit open-source software se to muze velmi jednoduse stat) ??? A k tomu prave slouzi ony transkace a integritni omezeni, ktere jsou tu od toho aby zajistily ze nemuze existovat hlavicka dokladu bez polozek nebo polozky bez hlavicky, ze nedojde k pripadu, ze uzivatel XXX cte data zrovna ve chvili, kdy uzivatel YYY uz zapsat hlavicku dokladu, ale jeste nezapsal jeho polozky, atd...

A muzu mit jeden dotaz: ja vyresite, ze se "z jakehokoliv duvodu" neco nepovede pri insert/update editovanych zaznamu tabulky polozek, tabulky hlavicky, a odstraneni zamku? To jsou minimalne 3 operace, ktere se musi chovat "jako jedna" a hlavne, pokud se neco nepovede, stale musi by data v konzistentnim stavu?... pro tento pripad reseni bez transakci neexistuje... prominte, existuje, mozna pro 5-ti uzivatelsky system, kdy kazdy uzivatel pracuje na jine casti systemu(datech) :-(

Adam.

K tomu dotazu:
1) vycerpani pameti, nejaka vyjimka, atd. pocas transakce: Tucniak obsahuje implementaci CSEH (cleanup stack structured exception handling), takze kdyz mam otevrenou transakci a neco se stane, mam handler, ktery ji uzavre (teda zatim ne, ale budu, kdyz bude hotov aspon zakladni libtucniak a budu mit trochu casu se na to podivat).

2) segfault uprostred transakce
No, tohle nevim. V prvni rade by se nic takoveho stat nemelo. Kdyz se stane, mame nasledujici stav: Zamknuty radek, mozna neuplna data. Ten zamknuty radek je problem, ale tucniak by mel bez vetsich problemu akceptovat mirne rozsypanou db (myslim neexistujici reference a podobne, a nic horsiho by se nejspis pri padu stat nemelo). Krom toho ten sigsegv muze dostat i db server, a to je ponekud horsi situace :).
Mozne reseni by bylo pouzit transakci (MySQL-max, PostgreSQL, ...) nebo timestamp a expiraci zamku.

Minimalne ja chci, aby tucniak umoznoval beh i s netransakcni databazi, pripadna podpora transakci by mela byt v databazove zavislem modulu. Neco jako M (cnt, lock, ...) by zamklo radek a otevrelo transakci, M (cnt, unlock, ...) by radek odemklo a zavrelo transakci. Jenze to znamena i nekolik hodin otevrenou transakci, co nepovazuji za prave dobry napad. Jine navrhy? Rad se necham poucit...

>>> Jine navrhy? Rad se necham poucit...

Ahoj,
asi už mě někdo brzo napadne, že sem nějakej PR agent fy. SUN :)))) ale:

nějak mi připadne, že se trápíte low-level řešením věcí, které se dají elegantně a průhledně řešit. A to řešit tak, že využijete J2EE.

J2EE = Java 2 Enterprise Edition, EJB = Enterprise Java Beans

Doporučuji se mrknout lehce na nějakej tutoriál kolem tohoto fenoménu a myslím, že budete docela v šoku, jak je tahle technologie mocná a zároveň průhledná a kolik věcí je pro podporu psaní rozumných aplikací k dispozici a to zcela FREE a OpenSource ...

A co se týká rychlosti, na Linuxu doporučuju prubnout JSDK 1.4.1 od SUNu, nebo JSDK od blackdown.org .. nedá se říct, že by procesní rychlost byla zrovna malá ...

Co se týče IDE doporučuju se mrknout na www.netbeans.org ... žravé co do prostředků, ale geniální ...

Co se týče aplikačního SW, doporučuji se mrknout třeba na www.jboss.org .. tahle potvora toho umí proklatě moc a nároky na HW nejsou nijak kritické

... možná to beru trochu oklikou, ale dávám to jako tip.

HLAVNĚ co se mi hrozně líbí je filozofie J2EE. Tohle když někdo vymejšlel, tak při tom přemejšlel .. v kostce: do rukou vám tahle technologie dává nástroj, ve kterém v podstatě designujete řešení blíže k lidskému stylu myšlení oproti klasickému stylu programování. Komunikaci mezi komponentami vám řeší aplikační server a to jak se k komponentám přistupuje je vám putna - to řeší též aplikační server ...

1.
problem, o ktery se zde jedny se jmenuje rezervovani zdroju a timestamping. Je to reseno v kazdem software. S transakcemi to nema nic spolecneho.

2.
Transakce tady nejsou kvuli tomu aby liny programator s mizernym designem mohl pri nesplneni logickych podminek provest cancel - nybrz proto, kdyz se program odporouci s memory fault. Bez transakce by doslo k nekonsistenci i na 1-user systemu.

3.
doporucuji vratit diplom

obavam se, ze na tohle transakce opravdu urceny nejsou. tim nerikam, ze se nedaji pouzit. problem vidim v tom, ze tahle transakce by trvala az pul hodiny, coz vidim jako naprosto zasadni problem - takhle ten system rozumne konkurentne fungovat nemuze (i kdyby se pouzival row-level locking, pripadne mvcc - "better than row-level locking..." pouzivat takhle dlouhe transakce (v tomto pripade), povazuju za spatny db design.

Ospravedlnujem sa panu Brabencovi ze som zneuzil jeho clanok na trosku odlisnu temu. Chapem jeho pohnutky vysvetlit ze PU naozaj nie je ziadna veda. Jeho "Strucny uvod do podvojneho ucetnictvi" bol jeden z prvych dokumentov ktore som v oblasti uctovnictva na linuxe cital.

Problem je len jeden, ze je hromada teorie a na prakticke aplikacie nikto nema cas. Co som chcel ukazat tymi transakciami je asi tolko, ze vela ludi zacne teoretizovat o novom projekte (ucto pod linux) a dalej jak s teoriou sa nedostanu a len vymyslaju nad akym db serverom to postavit.

My sme zacali stavat, a zistili sme ze transakcie su len relativne malym problemom ktory sa da pomerne rychlo odstranit nad db serverom ktory transakcie podporuje. A pri db serveri ktory nepodporuje sa jednoducho treba spolahnut na to ze to dokaze api. Mozno ma za tento nazor mnohi budu zatracovat, ale ide o to ze na jednej strane je implementacia transakci a na druhej strane interakcia s Api v pripade ze transakcia neprebehla uspesne. A prave toto je casto dost tazko rozlusknutelny oriesok, ktory je niekedy lepsie nechat luskat len samotnej api ako db-serveru

Ospravedlnujem sa panu Brabencovi ze som zneuzil jeho clanok na trosku odlisnu temu. Chapem jeho pohnutky vysvetlit ze PU naozaj nie je ziadna veda. Jeho "Strucny uvod do podvojneho ucetnictvi" bol jeden z prvych dokumentov ktore som v oblasti uctovnictva na linuxe cital.

Problem je len jeden, ze je hromada teorie a na prakticke aplikacie nikto nema cas. Co som chcel ukazat tymi transakciami je asi tolko, ze vela ludi zacne teoretizovat o novom projekte (ucto pod linux) a dalej jak s teoriou sa nedostanu a len vymyslaju nad akym db serverom to postavit.

My sme zacali stavat, a zistili sme ze transakcie su len relativne malym problemom ktory sa da pomerne rychlo odstranit nad db serverom ktory transakcie podporuje. A pri db serveri ktory nepodporuje sa jednoducho treba spolahnut na to ze to dokaze api. Mozno ma za tento nazor mnohi budu zatracovat, ale ide o to ze na jednej strane je implementacia transakci a na druhej strane interakcia s Api v pripade ze transakcia neprebehla uspesne. A prave toto je casto dost tazko rozlusknutelny oriesok, ktory je niekedy lepsie nechat luskat len samotnej api ako db-serveru

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.

Teda pánové a dámy, obdivuji Vaši snahu zaobírat se účetnictvím v linuxu, potažmo v MySQL. Ale měl bych pro Vás super rychlé a zcela spolehlivé řešení. Doporučuji smazat Vaše slavné distribuce linuxu, přestat tu s nima machrovat a konečně si nainstalovat Windows XP, které vyřeší všechny Vaše problémy. Nejen, že se zbavíte žravého systému s odpornou napodobeninou Windows, ale i Vám ubyde starostí a potřeby čtení dlouhých nudných manuálů. Windows XP nejne že můžu všem doporučit, ale můžu všechny ujistit o jejich perfektní stabilnosti a bezpečnosti. Nehledě na to, že se nebudete muset trápit s nějakou napodobeninou účetnictví v ubohé MySQL. Existuje přece spousta tak skvělých účetních programů a vy tu ztrácíte čas. Prosím Vás vezměte rozum do pinzety a nechte si poradit. Aromeo

Ano, toto je vicemene pravda.
Proc se zabyvat pomerne zlouhavym a slozitym procesem vytvareni jakehosi "podivneho" systemu ucetnictvi na linuxu (kde je mimochodem temer jakykoliv proces vytvareni cehokoliv zlouhavy), kdyz zde mame uz dlouhou dobu vyvijene, existujici, a tedy i fungujici programy do Windows. A nakonec ani snad neni nutne pouzit primo posledni verzi tohoto operacniho systemu (ano, ikdyz mnozi z vas o tom mohou pochybovat: Windows je operacni system), Windows XP. I starsi verze Windows vyhovi pro pouziti v ucetnictvi, zvlaste pak na pomalejsich strojich je vhodnou volbou. Jde predevsim o to ze pro Windows jiz existuje siroka rada programu pro ucetnictvi jejichz obsluhu a pouzivani navic kazdy jiste hrave zvladne (coz opet nelze zcela spolehlive rici o Linuxu), staci si jen z techto programu vybrat, jaky je Vam libo. Proc se tedy skrabat za levym uchem pravou rukou?

Děkuji oběma věci znalým pánům za velmi hodnotné příspěvky k tématu "účetnictví na Linuxu". Jen bych si neodpustil drobnou poznámečku: příště než odešlete podobné diskuzní příspěvky (které se ať již náhodou, nebo snad možná účelově snažily vyvolat flame -- aslespoň v kontextu tak vyzněly), aby si uvědomili, že se tento server zabývá Linuxem a ne produkty Microsoftu.

Poněkud vulgárněji: Jděte se svými radami do Živě!

EOF

I já Vám děkuji za pochvalu. Samozřejmě jsem si vědom mých hodnotných příspěvků a proto zde napíšu jeden další. Není pravda, že se můj příspěvek účelově snažil vyvolat flamewar. Zřjmě jste to tak pochopil pouze vy a další jeden slaboduchý kolega, který se z toho, že má na svém počítači nainstalován linux a nemá rád windows, málem udělal. Je mi ho hrozně moc líto, jestli jsem ho rozčílil. Zřejmě ho při vyslovení slova Microsoft začíná brát neutuchající zlostná křeč. Opravdu je mi ho líto a mohu mu jedině doporučit nějakého ochotného doktora který mu jistě bude nápomocen.
Abysme se vrátili k tématu - ano toto je server zabývající se linuxem, ale to neznamená, že by tu byl zákaz psát o windows. Naopak - přímo k tomu vyzývá. A já jsem právě chtěl připomenout, že proč je nutné zabývat se takovou "kravinou" jako je výroba účta na linux, když zde máme spoustu kvalitních programů pro platformu windows.
Jinak Vás musím překvapit, ale na Živě jsem opravdu zašel poradit ohledně Internet Exploreru a jeho chybám. Bohužel jsem byl shodou okolností opět označen za vyvrhela. Bude to zřejmě tím, že zmiňovaný slaboduchý kolega zřejmě má své útočiště i na Živě.cz kde si léčí své mindráky. Je mi ho velice líto a tímto bych mu chtěl popřát brzké uzdravení. A

Nevím proč Vám kolega příjde slaboduchý (že by proto, že je linuxák?), možná je to proto, že použil několik, ne zrovna košer slušných slov. Kupodivu ani Vaše reakce, nebyla zrovna slušná. Budiž.
Myslím, že příspěvek byl skutečně poněkud flameový, ale i to nechme stranou.

Ürčitě by mě (a tuším, že nejenom mě) docela zajimalo, proč Vám příjde psát účto na Linuxu jako "kravina". Pokud za odůvodnění považujete existenci podobných programů na jiné platformě (potažmo komerční platformě), pak se přímo nabízí označit za slaboduchého Vás (prosím neberte to osobně, je to pouze úvaha).

S Živě.cz jste mě nepřekvapil a dokonce bych (vzhledem k tomu, že jsem onen server kdysi rovněž navštěvoval, dnes už pouze příležitostně) něco takového čekal. Co se jiných útočišť mého ("slaboduchého") kolegy týká -- nic o nich nevím, ale obávám se, že na Živě.cz má útočiště mnoho jiných velmi, velmi slaboduchých lidí (dokonce bych mohl i jmenovat a to nejen mezi autory). Je až s podivem, že se tam vyskytují i lidé jako Hynek Hanke.

Nezbývá, než Vám popřát hodně úspěchů na Živě.cz, a do budoucna snad i na Root.cz.

Na další zajisté užitečné příspěvky k tématu se těší
~the

Predem, jako slaboduchy se rozhodne necitim (myslim, ze bych se to prinejmensim od sveho okoli dozvedel)


Datum:
27.10.2002 01:03:28, jo a o tom, ze existuje nejake zive.cz jsem se dozvedel az zde, nemam cas se na internetu zabyvat kravinami. Nejsem zastance ciste Linuxu, ale funkcnich a kvalitnich systemu a to se diky bohu netyka jen jeho (tim myslim, ze proste mame na vyber). Co se tyce "vaseho" windowsu a jeho exploderu opet bych vas odkazal na http://www.ha.cz . Co se tyce vasich kecu k Linuxu a lidem zabyvajicich se jim dovolte abych vas poucil o historii a soucastnosti pocitacu a zaroven o soucastnosti systemu a to hlavne v "extremnim nasazeni". Prvni graficky operacni system vznikl, nebyl to windows 3.11, vznikl v USA cca pred 25 lety a jmenoval (jmenuje) se Unix, graficky byl pochopitelne jeho window (ne windows !!!) manager, unix uz existoval o neco drive, tento system vypadal a umel toho asi tolik co Windows 95,98 a mel 64 kb.Pocitace se vyvijely dale, a tak vznikaly i napriklad podnikove IS a podobne, nebo taky na zacatku 80. let byl vyvinut dosud jeden z nejlepsich CAD, CAM,.. system Catija, je take (jeho nove verze) dosud pouzivany napr. v automobilovem prumyslu.V roce 1985 Linus Torvalds, student z Finska, v ramci nejake sve prace na fakulte informatiky a vypocetni techniky vytvoril program, podobny jadru systemu Unix pozdeji pojmenovany jako Linux, nekdy v tomto roce se ho ujal vznikajici projekt GNU. Vyvoj sel opet dal a napr. v roce 1986 spolecnost Apple jeste s dalsimi, opet z USA, vyvinula svuj Mac OS2,jako vubec prvni komercne uspesny graficky OS a to i mezi domacimi uzivateli, i kdyz je 16 let stary umi toho mnohem vice nez windows. Jako reakci na tento system tehdy jiz pomerne pocetna komunita vyvojaru kolem GNU a dalsi spolecne vyvinuli, take prekvapive graficky window manager pro Linux. Tak sla leta dal uplatnily se pomerne dobre a neustale se zlepsujici standarty vychazejici z Unixu. Site a internet (v te dobe uz skutecne!!! existoval, nikoliv od roku 98) byly pomerne bezpecne, bylo par elitnich hackeru, kteri se sem tam nekde nabourali (P.S: tehdy to 12-ti leti kluci nezvladli). V roce 95 vsak zacala doba temna pocitacu, prisel jakysi Bill Gates se svymi Windows 95, pochopitelne jak Microsoft, tak jeho system nemeli o existenci nejakych siti, nebo dokonce internetu poneti, presto se nejakym zahadnym zpusobem rozsirili (na to ma zajimavou teorii hra XBill -:)) ). S 98-ickami SE!!! prislo jakesi """sitove""" rozhrani, ktere bylo bezpecne asi jako cednik neni diravy. Od te doby nastala faze 2, pocitacove doby temna, doba tisicovek uspesnych 12-ti a vice (i mene) letych hackeru, tisicovky viru, trojskych koni explo-itu a podobne. Diky uplatkum Microsoftu a naslednem nasazeni Windowsu napr. v nekterych (mimo jine dosud i v tom ceskem) IZS bylo ztraceno nemam odvahu si ani typovat kolik lidskych zivotu (k tomuto existuji i podlozene analysy) a prevazne v soukromem sektoru take mnoho jiz mene dulezitych penez. Deti jsou niceny stovkami nelidskych her tezce dotovanych Microsoftem, v kterych behem nekolika mesicu ci let vidi vice krve, nasili, brutality, zlomenych kosti a podobne nez vojak v prvni linii za celou svou karieru (to je podlozeno vyzkumy), diky nedokonalosti vaseho oblibeneho Exploderu maji take pristup k strankam s pornografii, nasilim a podobne, krome Exploderu jsem jeste nevidel prohlizec, ktery by toto pomoci systemu klicovych slov, nerikam, ze naprosto dokonale, nedokazal zakazat. Jako zarici hvezda se vsak na pocitacovem nebi objevily ruzne distribuce uz ne ciste akademickeho OS Linux, ktere jako vubec prvni byly a jsou schopny (cim dal vice, nastesti) konkurovat Windowsum a to hlavne mezi beznymi uzivateli a mensimi a dosud spatne technicky vybavenymi spolecnostmi. Nektere distribuce zacaly pouzivat i obri spolecnosti. Linux se uplatnil take v oblasti vedy, pomoci nej bylo vyvinuto spousta leku, lecebnych metod a podobne, vedci diky nemu mohli provest jinak neproveditelne virtualni pokusy ci vypocty, napr. na nejvykonejsim, Japonskem, pocitaci sveta zkouma Linux zmeny klimatu a jev globalniho oteplovani viz: http://sillicon.com . Pomaha take pri vyzkumu rakoviny a mnoheho dalsiho, na takove veci Windows pouzit nejde. Po utocich 11. zari po celem svete nastala hospodarska recese dnes levny, stabilni, bezpecny a vykonny Linux a jeho systemy a programove vybaveni setri a vydelava vsemoznym spolecnostem obrovske penize, ridi prumyslove vyroby, chrani rozsahle a dulezite site a data po celem svete a mnoho dalsiho. Zatimco "novy" Windows XP prinesl jen absolutni ztratu soukromi a svobody co se dat, pohybu na internetu a podobne tyce.

K VYUZITI V UCETNICTVI A PODOBNE: Nekdo muze tvrdit, ze kvalita napriklad ucetniho a podnikoveho systemu neni zavisla na OS, ale na kvalite jeho zpracovani, jiste kvalita zpracovani je pro dobry jakykoliv system ci program nutna, ale co rychlost, stabilita, cena a bezpecnost toho na cem tento system potazmo program stoji, to s ucetnictvim, podnikovym rizenim a nejen s tim, zvlaste co se tematu "bezpecnost dat vs. internet a spol.", tyce nesouvisi? A co se kvality, logiky a rychlosti uzivatelskeho prostredi systemu a v neposledni rade dnes take, tak dulezite snadnosti a rychlosti pristupu na internet (urcite naprosta vetsina lidi nebude pouzivat jediny program) tyce to snad taky ne?

TED K DISKUZI (UZ JEN PRO LIDI ZABYVAJICI SE OPRAVDU TOUTO DISKUZI!!!):Myslite si, ze v praxi je mozne uplatnit modelovani a napr sledovani a podobne prace (mysleno analyticke modelovani apod.) v systemu podnikoveho rizeni, ucetnictvi, logistiky a podobne v 3D rozhrani? 3D WM na http://www.3dwm.org .

P.S: Predeslymi dvema prispevky jsou mysleny prispevky dvou Windows maniaku (Danny+Aromeo, viz predesly prispevek)

Jeste jednou se omlouvam za vulgarni vyrazy v predeslem prispevku, uznavam, ze jsem se nechal unest.
nautilus

Tato konference je konference prevazne systemovych specialistu, programatoru a podobne, podle me se zabyva diskuzi o moznem vylepseni a jeste vetsim zlevneni vsech techto nejen zjednodusene receno ucetnich systemu pod systemem Linux. Pro Micro and Soft brains zduraznuji, ze na Linuxu a spol. existuji spickove systemy ekonomickeho a podnikoveho rizeni, ucetnictvi a podobne. Jenze za a) vzhledem k tomu, ze jsou urceny pro velke spolecnosti jsou velmi drahe b)nedaji se absolutne srovnavat s Shitdowsovymi produkty, jsou podstatne lepsi a to vcetne uzivatelskeho rozhrani pro stanice.
P.S: Videli jste uz pod Shitdowsama napriklad 3D WM pomoci , ktereho je a hlavne bude mozne modelovat vztahy jednotlivych modulu a podobne, to neni fantazie, to je http://www.3dwm.org.

Poznamka pro debily (ano, je to pro ty, kterym odpovidam): Lituji lidi, kteri si toto "mysli", ti nebudou trpet asi jen debilitou, slepotou, hluchotou, apatii,... .
Vsadim se, ze pouzivate Exploder podivejte se tedy sem http://www.ha.cz.
Windows vyjma jeho ohromnych der je ucelove udelan ,tak a to zvlaste XP, tedy tak aby si spolecnost Microsoft mohla prohlizet ci pouzivat jak se jim libi vase data (preji hodne obchodnich uspechu s Windowsem, zvlaste pokud se zabyvate napr. vyvojem neceho...).
Dovolte abych uvedl jednu ze svych vlastnich zkusenosti: jiste firme jsme delali sit natukli otazku Linuxu, ale chteli Windows, tak jsme posadili pred stanici asi 12-ti leteho kluka, kteremu jsme par veci vysvetlili -:)). Udelali jsme malickou NT sit "server"+2 stanice zkonfiguroval ji clovek s NT Professionalem a pracne pouzil vsechny servis packy. Tak k veci, tomuto cca 12-ti letemu klukovi se povedlo do teto podle vas super zabezpecene site dostat asi behem dvou hodin, s tim, ze mel pristup na internet (a kdo dneska nema).
P.S: Testovali jsme Linuxove servery myslim, ze i pro ty mene inteligentni bude stacit kdyz reknu 17 elitnich hackeru, bez uspechu ze strany hackeru.

P.S: Omlouvam se slusnym a inteligentnim lidem za nektere vulgarni vyrazy, ale po precteni predeslych dvou "prispevku" pochopite.

a co jako melo byt na te strance "http://www.ha.cz." ? (mam IE)

No, pokud nesedite za nejakym hodne dobrym firewallem, tak by se v okne takoveho maleho Javascriptu mel zobrazit obsah vaseho disku C. POZOR! Pokud za necim takovym nesedite radsi bych vseobecne na tyto stranky nelezl.

Jo? A jaktoze teda Microsoftu trva vyvoj systemu ovladani pocitace pomoci gest. mimiky a hlasu pekne dlouho(podle jeho vlastnich slov uz nekolik let, planuji jeho uvedeni na trh kolem roku 2006,coz u Microsoftu znamena tak rok 2060, taky ma byt pekne drahy), kdyz pod Linuxem uz tento system nejakou dobu bezi (co se tyce gest a mimiky, jeste jsou ve vyvoji HW zarizeni, ktera maji byt dostupna i pro uplne normalni uzivatele za udajne velmi dobrou cenu, s jejich dokoncenim se pocita snad za par mesicu a zatim je je castecne schopna nahradit obycejna webkamera).
K tomu skrabani se za levym uchem pravou rukou opravdu nevim proc to jeste delate -:)) . A k prostredim a ovladani Linuxu, tam je na tom taky daleko lepe.
P.S: Uz jste nekdy zkousel vyjma KDE wm jako jsou GNOME a ENLIGHTENMENT a treba prohlizec jako je KONQUEROR, OPERA ci MOZIllA, nebo taky jeste "komplexní" balíky StarOffice a KOFFICE, studia jako je AYAM, ARTOFILLUSION a mnoho dalsich? Az je vyzkousite pak mluvte o "nesnadnosti" ovladani Linuxu potazmo jeho wm. -:))

KDE neni napodobeninou Windowsu a Linux sam o sobe, jak uvadim v komentari nize, je mnohem starsi nez Windows. K tomu KDE, vyslo z principu, jak taky uvadim nize, Mac OS2 takze napodobeninou je Windows, nevyjmaje to, ze temer vsechny technologie pouzivane pod Windows byly nekde ukradeny nekde jinde a pred jejich implementaci jeste obvykle radne zmrseny. A k tem manualum reknu jen jedno http://www.suse.cz .

Je ucetnictvi na Linuxu? Neni - je diskuze o ucetnictvi na Linuxu.

Ba, kdyz vidim debatu o ciselnych radach, je mi smutno. Panove sice budou garantovat ciselnou radu, ale to obrovske, co je nad ni, o tom radsi nemluvi. Takze slova do pranice:

1. Panove (vsichni), na jak velke objemy dat chcete ucetni system stavet? Nema smysl davat motor z Audi do Trabanta a naopak.

2. Opravdu chcete jen ucetnictvi? Co personalistika, logistika, vyroba, atd atd?

3. Zacne se uz nekdo bavit o logickych vazbach tabulek a vizualizaci pro zpracovani, nebo jsou tady jen programatori, kteri nevi, co bude nasledovat po MD a D a o prumerne cene nemaji ani paru? To pak vznikne jen nedomrly bastard...

Jedna poznamka pro zastance tvrzeni, ze MD se vzdy musi rovnat D: az budete mit nabouchany slozity pripad o 50 polozkach a nebudete si vedet rady s jednou z nich, radi rozpracovany dokument predbezne ulozite (aneb zaparkujete - pro ty, co o oboru neco vi) a v prubehu nekolika dni se poradite se svym danovym poradcem, nacez zbytek do dokladu dokoncite, ulozite a definitivne zauctujete.

Tahle debata mi pripomina Cimrmanovskou Svestku. Pokud ma nekdo zajem tvorit system pro stredne velke az velke firmy (nebranim se prebirani jiz vytvoreneho, pokud to bude rozumne napsane), rad navazu diskuzi. Jsem pod systemem SAP spoluautor reseni pro Kaufland, Wrigley, anglicke B&Q atd.

Doufam ze timto tonem primeji diskuzi smerovat k otazce ucetnictvi a dale, nez se zabyvat databazi apod. Prvne preci musite vedet co chcete a pak urcit prostredky, kterymi toho dosahnete. Zatim mam jen hodne kusy a nedomrly koncept, jak rozsahle to vlastne je a postupne se vrham do toho, co ucetnictvi musi umet (ucetnictvi je holt prvni modul, ktery musi jakz takz fungovat, aby se daly delat moduly dalsi) a budu i rad, kdyz najdu lidi, kteri by mi s tim pomohli. A neni toho malo...

Motto: Ekonomicky software, to neni jen MD a D...

1.
Petr Bravenec oslovuje svym clankem linuxove orientovane ctenarstvo, ktere se zabyva vsim okolo linuxu a v sekci RUZNE je obvykle povrchne hovoreno o okrajovych tematech. Hloubka, do ktere momentalne Bravenec jde je v tomto kontextu OK.

2.
Diskuzni prispevky odpovidaji take vyse uvedenemu okruhu ctenaru, pan Bravenec take nikde nerika, ze by rad zasadil svym jednoduse napsanym clankem firme SAP a konsortum smrtelnou ranu.

3.
Diskuznich moznosti je nekonecne mnoho. Lide se zkusenostmi s SAP jsou jiste vsude vitani.
Napr:

www.gnue.org - podle stavu projektu a jak je to navrzene pocitam, ze to SAP zabali tak do 4 let - samozrejme jestli se najde nekdo, kdo take krome te diskuze napise nejake software

4.
....Pokud ma nekdo zajem tvorit system pro stredne velke az velke firmy ....
Definice ?? stredni, velka ??

5.
...(nebranim se prebirani jiz vytvoreneho, pokud to bude ...

tucniak.sk ??
gnue.org ?? - viz vyse
www.linux-kontror.de stejnojmenny paket
www.bemme.de - paket tudo
www.compiere.org - jedine IS-economy muze konkurovat

Ktery z tech paketu ma jake nevyhody - jaka je Vase analyza - nebo ze by jste jeste zadnou neprovedl - ne to si nedovedu predstavit s tim tonem, s jakym do toho jdete

6.
.... (ucetnictvi je holt prvni modul, ktery musi jakz takz fungovat, aby se daly delat moduly dalsi)....
To je vtip? Nebo to rekl Hasso Plattner?
A jak vlastne definujete modul?

7.
doporucuji precist nejdrive archiv konference ucto.linux.cz ... 90% otazek se tam jiz diskutovalo - samozrejme jako vzdy s zadnym vysledkem - ale nazory tu byly :-)

8.
kde je mozno Vas navrh nakouknout a kam je mozno zaslat vecne pripominky

Jen několik poznámek:
a) Seriál ještě nebyl uveřejněn celý, taže poznámka o nedomrlosti je IMO poněkud zcestná.

b) V žádném případě se nejedná o kompletní návrh databáze, nad kterým by se mělo provozovat účetnictví, vidím to spíše jako snahu o ukázání směru, prostředků a možností.
Malé úvaha: celá diskuze mi příjde poněkud zvláštní. Všichni jakoby čekali, že zde najdou kompletní popis již hotového a dokonalého systému pokud možno prověřeného pokud možno 20ti letou praxí i se zdrojákama a nejlépe i s podrobným návodem na použití :-) O tom to ale vůbec není!

c) Ostatní součásti systému lze postupně doplňovat, pokud se dobře pamatuji, tak se obvykle říká (a něco pravdy na tom bude), že dobře navržený datový model je poměrně snadno rozšířitelný.

d) Vaše snaha o směrování diskuze směrem k účetnictví je sice zajímavá, nicméně se obávám, že zde s ní příliš neuspějete. Tato diskuze je spíše právě o oněch technických stránkách. Petr zde totiž IMHO nemá za cíl vymyslet a navrhnout dokonalý datový model i s tabulkama pro mamutí podniková řešení, ale ukázat cestu, kterou by se možná mělo/mohlo jít.

A ještě jedna: Teď si do Vás možná malinko rýpnu -- co jsem slyšel o SAPu, tak ten zrovna dobrým navrhem datového modelu nevyniká -- databázi (prý) používá pouze jako datový sklad. Toto jsem ovšem pouze slyšel a v žádném případě se nejdná o tvrzení, protože o SAPu toho vím skutečně velmi, velmi málo (pro jednoduchost řekněme, že téměř nic).

Jeden, pravda ne s dvacetiletou historii, se v cesku rodi, podle toho co o nem vim by mel byt velmi dobry,podpora mnoha platforem, jak otevrenych, tak komercnich standartu at uz databazi ci OS a "komunikace" mezi nimi. Upozornoval na nej a psal onem v diskuzi k predeslemu clanku pan Karel Jacko, jeden z clenu jeho vyvojoveho tymu a predtim jsem o nem jen velmi kuse informoval i ja.

Na takovychto a obdobnych diskuzich potazmo "otevrenem reseni problemu" je snad zalozena kvalita a existence Linuxu. samotneho, ne?
P.S: Doufam, ze tato diskuze bude dalsim hodnotnym prispevkem do vyvoje techto systemu na Linux a tim zaroven i jejich masovejsiho nasazeni nez dosud.
nautilus

Nepripada mi to tu jako "Vse pri starem" ale jako
"ZABETONOVANE". Vyvoj IS dnes jiz není o handrkovani
jaky OS je lepsi, ale jak umoznit uzivateli pracovat
nezavisle na OS pri respekovani tradic zvyklosti, ktere jsou osvedcene casem, vyuziti novych technologii, ktere mohou usnadnit a zrychlit neefektivni cinnosti.

Jiz zde zminovany SAP se pro neinformovane vyprofiloval do reseni jehoz nejvetsi
silou je predevsim pri samozrejme robusnosti a propracovanosti do vsech detailu predevsim poskytnuti know-how, ktere dava uzivateli konkurencni vyhody, ktere mu mohou dat sanci udrzet
krok s ostatnimi. Takoveto know-how ovsem muze nepripravene zabit. Proto ze vestsina podniku v CR je nepripravena, a to ne jen financne, je pro
ne existence jinych IS reseni nutnosti. Tim neni
ovsem receno, ze takovato reseni a to i pro Linux
maji byt zmetky. Mohlo by skutecne dojit k tomu,
ze nez se potencial teto komunity zmobilizuje, prijdou panove od Microsoftu (jiz koupili NAVISION)
nebo jim podobni a prinesou IS na "urovni", ktery
bude zdarma soucasti IE 7.2 a vy budete jeste u toho, co tvori primarni klic ucetniho zaznamu v deniku nebo napr. co je to ten "rezim docasneho plněni u DPH".

Pravda, zapomnel jsem poznamenat, ze by mela byt na urovni a nemeli by se sem michat lide, kteri chteji jen vyvolavat flamewar. Ale take si myslim, ze tady urcite neni mozne vyvinout spickovy, do detailu propracovany, uniplatformni IS, ale myslim ze tato konference muze byt dobra napr. k tady a ted asi nejdiskutovanejsi veci a to jsou databaze, potazmo jejich implementace, atd.

tak jsem na to hned kliknul a hle:

http://thunder1.cz (jeťże ve vývoji)/
failed because
Cannot open the HTTP connection to %74%68%75%6e%64%65%72%31%2e%63%7a%20%28%6a%65%c5%a1%c5%a5%65%20%76%65%20%76%c3%bd%76%6f%6a%69%29 port 80; [Name Lookup Non recoverable error].

Jako autor funkčního účetního a skladového systému, tedy 'databázový' programátor, jsem vždy s úctou a tichým obdivem vzhlížel ke včem systémákům, céčkařům, síťařům a podobným 'guru'. Od svých tabulek jsem vždy zhlížel k tajemným názvům jako TCP/IP či kernel; přinášeli ke mně vůni tajemných dálek a neznáma. Svůj Linuxový server si v naší firmičce administruji již třetím rokem, stále se však rdím, mám-li napsat dotaz do nějaké konference. Dnes poprvé je tomu naopak. Dnes poprvé se usmívám, ba co dím, místy i pochechtávám. A na nakonec dám taky jeden odkaz; bude to na naše předky, kteří tvrdili ŠEVČE, DRŽ SE SVÉHO KOPYTA!

programator at uz frotendovy nebo "nizkourovnovy" apliakce ktery 3roky, mozna i dele obdivne vzhlizi ke vsem guru se znalosti TCP, kernelu nemuze byt dobrym programatorem, resp. je omezenym programatorem, radsi napiste produkt ktery tvorite....

Hlavní brzdou masivního rozšíření Linuxu je trvalá absence PROFESIONÁLNÍHO účetního software s patřičnou uživatelskou podporou typu ABRAGOLD, či něčeho podobného. Co je mi platný kancelářský balík OO, když moje účetní - jinak naprosto klíčový hráč v každé firmě - mi Linux definuje jako zajímavou hračku se kterou "nejde dělat".
K čemu je mi pak Linux doma, když v práci jsem z téhož důvodu nucen pracovat na paltformě MS a krom dopisu ve Wordu si doma skoro nic neotevřu.
Všichni tu "meditujete" o datových strukturách a jediné, co je třeba udělat, je založit SW firmičku, která se bude zabývat seriozně ekonomickým softwarem (se všemi udělátky a tiskovými sestavami, co si jen může ta baba účetní zamanout). Věřte, že si taková firma "přijde na své", byť to už nebude Open Source (ale všechno ostatní v té bedně ano).