zivnostnici ovsem pouzivaji jednoduche ucetnictvi. v Arachne Labs interne uz dva roky pouzivame pro fakturaci jednoduche ucetnictvi nas proprietarni system Moloch na bazi PHP a MySQL, ktery je bohuzel natolik zmateny, ze ho nejde jakkoliv zverejnit. V soucasnosti se ale intenzivne pracuje na systemu Moloch 2, ktery bude open source, "ciste" napsany (pokud neco takoveho v PHP jde ;-), a zahrne v prvni fazi moduly pro elektronicky obchod, fakturaci, evidenci zakazniku a prave jednoduche ucetnictvi... release planujeme tak do mesice (snad o nem pak da root.cz vedet ;-) podvojne ucetnictvi by do toho pak casem taky nemel byt problem zamontovat.
Ona jedna vec je zridit patricne tabulky v MySQL, a druha udelat k nim nejaky dostatecne intuitivni a reprezentativni frontend...
no modul na prodej realneho zbozi, ten bude asi propojen s modulem "cenik", ktery tam uz je (pro elektronicke shopy a objednavky), a s modulem sklad (ktery teda rozhodne zatim neni - moje firma nic neskladuje, delame software a webhosting ;-)
prodej za hotove - to jako ze se nebude vystavovat faktura, ale rovnou jen veta do penezniho deniku ? protoze u faktur v nasem systemu se nastavuje splatnost hotove/prevodem/jinak (jinak=napr. smluvni barter...), a samozrejme, faktury neni povinne tisknout - staci kdyz jsou v archivu. ale penezni denik pro jednoduche ucetnictvi sam o sobe samozrejme muze obsahovat prijmy, ke kterym jako doklad nebyla vystavovana faktura, ale prave jen prijmovy doklad... takze by nebylo od veci fakturaci vynechat. Ja to zatim pochopitelne siju na miru hlavne webovym sluzbam, kde je celkem typicke, ze si vsichni zridili zivnostak, maji obrat do 250000 mesicne (tzn. neplati DPH), a pochopitelne si vedou jednoduche ucetnictvi. Ja jsem ostatne z podvojnyho na VSE propadl, takze je logicke, ze se orientuju na to jednoduche... ale suma sumarum, aby byl muj penezni denik pouzitelny pro podvojne ucetnictvi, na to je v podstate potreba jen zmenit kodove oznaceni vet - ty trimistny cisla misto kodu typu PS - prodej sluzeb, apod., a potom vkladat pro kazdou transakci dve vety, misto stavajici jedine...
Odloucene pracoviste - to nevim co se tim mysli. Vsechny pracoviste systemu Moloch 2 jsou "odloucena" - je to webova aplikace, ktera bezi na linuxovem serveru, a pracovistem je libovolny webovy browser, kdykoliv a kdekoliv. I faktury se tisknou z browseru, jako HTML, a na tehle zakladni koncepci nehodlam nic menit.
Zatim se to pouziva v ramci firmy jakozto system Moloch 1, ale protoze vetsina zakazniku a obchodnich partneru potrebuje zhruba to same, prave to prepisuju aby to bylo modularni, a jaksi designove i jinak ciste (CSS, ...). Psat nove moduly by melo byt trivialni, takze pocitam, ze az to relasnu, tak se najde nekdo, kdo k tomu dobastli veci jako sklad, pokladnu (nesouvisi s hotovosti jako takovou - ta je ve fakturaci i v peneznim deniku zcela samozrejma), zamestnance, a casem treba podvojne ucetnictvi. Az to releasnu, tak bude Moloch 2 urcite zahrnovat cenik zbozi, shopy, objednavky, fakturaci, penezni denik, e-ziny, bannery, ankety a podobne webove harampadi. Nevim jak to udelam s moduly pro spravu webhostingu - ovsem protoze interface pro interakci s linuxovym serverem jsou a budou natolik specificke a zmatene shellove skripty, tak ten modul bude asi stejne vyuzitelny jen pro toho, kdo si necha nainstalovat Linux od nas, nebo si to bude schopen sam prepsat. Nad RedHatem nebo Suse z krabice se to nechytne...
Ze strany statu je zde dlouhodoba snaha jednoduche ucetnictictvi zatrhnout. Jednou se jim to povede. Doufejme, ze pred tim projdou zmeny zakona, ktere zprijemni pouzivani podvojneho ucetnictvi malym
zivnostikum. Jde to i dnes, ale musite si davat pozor, aby Vam zaplatili faktury co vydate a prodali jste to co koupite (na sklad). Zhruba receno. (kdyz tak mne prosim doplnte).
Ne ze by vyse zminene duvody byly jedinymi rozdily. Jedna se o zcela rozdilne veci (pridelani podvojenho ucetnictvi do jednoducheho si neumim dost dobre predstavit), ale tyto rozdily jsou neprijemne z danovych duvodu.
Podvojne ucetnictvi je mozna rozsahlejsi (a komplexnejsi) nez jednoduche, ale osobne mi prijde logictejsi a diky tomu svym zpusobem jednodussi...
Jeho pochopeni "laikem" je mozna problematictejsi, ale pokud do nej jednou proniknete, tak jste za vodou a naprostou vetsinu operaci si logicky odvodite. A detaily najdete v postupech...
Takze pripadne (temer jiste) zruseni jednoducheho ucetnictvi bych nevidel tak tragicky...
Mazelka je ucetni a na podvojne ucetnictvi neda dopustit. Na podvojne pry koukne a hned vidi, jak na tom hospodarsky je, z jednoducheho nevidi nic.
Moc tomu nerozumuim, ale velky rozdil je pry hlavne v casovem zarazeni plateb. V podvojnem zauctujete (a zdanite) fakturu hned, kdyz ji vydate, v jednoduchem, az vam ji zaplati, nebo tak nejak?
Vidim preci jen jeden veliky problem s podvojnym ucetnictvim a to: pokud vam odberatel nezaplati fakturu, tak vy i presto musite odvest dan z penez ktere jste nikdy nedostal a mozna ani nedostanete a na druhe strane si neplatic s podvojnym ucetnictvim nezaplacenou fakturu muze klidne dat do nakladu - to je velika svinarna ktera v jednoduchem ucetnictvi nejde.
No, nejde ani tak o PostgreSQL, jako o to, ze MySQL se na neco takoveho absolutne nehodi. MySQL je skvela rychla databaze na web, je dobra jako datovy sklad, ale na financni operace, kde je potreba predevsim spolehlivost, zarucene zachovani integrity dat a pod. to proste neni. PostgreSQL je na tohle naopak vyborna, jako i dalsi databaze. Jeji vyhodou je, ze je free a ze se nachazi v kazde vetsi distribuci linuxu, takze jeji zprovozneni neni zadny problem. Proto se i me zda jako optimalni.
Osobně bych se příkláněl taky spíš k Postgres. Nečím takovým jako prodejním - účetním systémem s evidencí zboží na skladě jsem se začal zabývat teprve asi před měsícem, ale ....
Představte si klasickou situaci, dvě a více prodejních míst (prostě jen více terminálů) u každého stojí zákazník a vybírá si zboží, které prodejce zadává do faktury. Některé položky nejsou skladem, jiné může okamžitě prodat. V okamžiku, kdy položku umístí do faktury, musí být tato položka blokována pro všechny ostatní prodejce. Občas se taky stane, že zákazník nakonec nekoupí nic a fakturu je třeba zrušit. To vše mi připadá jako zcela ideální situace pro využití transakcí a jiných funkcí, které MySQL neumí.
To je opravdu nemozne. Zaprve to nejde tak jednoduse, zkuste si to prostudovat, zjistite ze ty funkce se lisi nejen nazvy, ale predevsim jsou zasadni rozdily v tech databazich. MySQL neumi cizi klice, transakce, trigery, vlozene procedury a prinejmensim prvni dve funkce jsou nezbytne pro financni databazovy system, ma-li byt na nej spoleh. Ona se MySQL vubec moc nezabyva integritnim omezenim, diky tomu je rychla, ale to je tak vsechno.
tento nazor je mozno porad slyset - zrovna tak jako trigery, vnoreny select apod. Takove diskuze je mozno 1/4-letne sledovat v kazdem databazovem foru. Zatim to vzdy skoncilo tak, ze ti, kteri slabikuji prodejni letacky vyrobcu databazi museli priznat, ze integritu softwaroveho reseni muze zrovna tak zaridit aplikace sama.
Existuji ale i jina kriteria. Native-Windows podpora pro mysql a embeded server.
Integritu dat jiste muze zajistit aplikace sama, ale to muze zajistit i ukladani dat do sveho vlastniho datoveho formatu, uzivatelska prava k nim etc.
Otazka stoji ve ktere vrstve databazova aplikace (resp. aplikace pouzivajici databazi) se maji tyto veci resit - a ja bych rekl, ze na urovni databaze, kdyz uz ji pouzivam. Jinak musim stale znovu v aplikacni vrstve programovat veci ktere by mnohem efektivneji mohla/mela zvladnout databaze sama, a ktere vetsinou, alespon podle meho, patri k datum.
Aha, asi jste nikdy neviděl db jak vypadá po několika letech provozu, pokud se o integritu dat stará aplikace. Já už bych do toho nešel nikdy více! A u účetního softu je mi jedno, jestli do db jsem schopný z aplikace dostat 780 nebo 1000 záznamů za sekundu :-), zálohovací/ obnovovací mechanismy jsou dostatečně rychlé.
To znamena, ze se databazi rekne neco jako "Ted si pamatuj aktualni stav", potom nasleduji bezne operace s databazi (mazani, vkladani apod.).
Jestlize se stane, ze nejaka z techto naslednych operaci selze, databaze se muze vratit do stavu v bode "Ted si pamatuj aktualni stav", takze se nemuze stat treba toto z nasledujiciho prikladu:
1. udela se zapis faktury vydane do tabulky FAV
2. zapisou se polozky teto faktury do tabulky FAVPOL
3. zauctuje se faktura do ucetniho deniku
Pokud by bod 2 nebo 3 selhal, bude v databazi bordel, protoze bude veden zaznam o neexistujici fakture (vytvoren v bode 1), ale nebude mit k sobe zadne polozky (pokud selze bod 2) a nebude zauctovana v deniku (pokud selze bod 3). Ciste teoreticky by si aplikace mohla pamatovat, co kde delala, a v pripade neuspechu by to vratila zpet, ale to je teorie, bylo by to silene pracne a ne vzdy implementovatelne.
Zatimco takto zavola Rollback a v tu ranu je ve stavu pred bodem 1, cili data jsou plne integritni.
To sice jde, ale musite pouzivat infimum funkci akceptovane obema databazemi.
MySQL transakce umi, ale pg ma sirsi podporu SQL, nepriklad mysql nema zatim stabilni (tj. zatim je to v beta verzi) podporu foreign klicu, coz je dost dulezita vec pro udrzeni konzistence dat v tak narocnem programu jakym ucetnictvi je.
Hele, kdyz uz se bavite o prenositelnosti a zamene typu SQL databaze, co takhle ODBC (resp. UNIX ODBC)? Kdyz se to napise s ODBC, tak se pak muze docela klidne prohodit databaze pod nim s docela minimalni zmenou kodu (snad se jen natahne "driver" pro danou DB). Myslim, ze to ma i transakce a vnorene dotazy. Rychlost je snad prijatelna (alespon to tvrdi lidi co by tomu meli rozumet). Jedina nevyhoda co me napada, je mozna nedostupnost nekterych specialnich "feature-k" konkretni databaze... Jo a Java mi zni taky docela rozumne ;)
Nehodlam se pripojit do zde probyhajiciho kydani DB hnoje.. ale k te prenositelnosti: neni vzdy snadne napsat dotaz pracujici na vsech DB. U definic DB (tabulky a spol.) je to temer nemozne. V pripade MySQL je mim oblibenym "SELECT a || b". IMHO resenim je mit definice DB a dotazu v nejakem abstraktnim formatu (XML) a pro ucel dane DB nasledne SQL vygenerovat. Jinak MySQL jiz vetsinu veci co zde zaznelo umi, k rychlosti PostgreSQL: ten kdo pouziva na firemni system treba Oracle cini tak vetsinou z jinych duvodu nez je rychlost, ta se vetsinou resi HW.
Michale, Michale, uz na teckacz jsem si vziml, ze
se s tebe stava vetsi a vetsi zaslepenec. To ze xchaos a jeho parta hic alias arachne pouziva jednoduche ucetnictvi, neznamena, ze se tomu cely svet podridi.
Nekde nize je napsano ze "existuje dlouhodoba snaha
vlady jednoduche ucto zatrhnout", pokud se neco zasadniho nezmenilo, tak zruseni jednoducheho ucetnictvi je jednou z mnoha podminek pro vstup do EU . A nekdy v roce 96 (kdy jsem tento obor jeste sledoval) nebylo moc ucetnich, kteri by o tom nevedeli.
Dalsi duvod pro podvojne ucetnictvi je, ze jej
pouzivaji vsechny vetsi firmy, at uz dobrovolne,
nebo kvuli povinnosti dane zakonem
(Neopakuji duvody v dalsich prispevcich).
Je zrejme, ze pokud chceme pokorit dalsi linuxovy
milnik, tak "podvojne" je jasna cesta.
Napada me jeste pomerne mnoho FLAME a OT pripominek, na pozadani je zaslu mailem.
V jednoduchem ucetnictvi jsem nikdy poradne neuctoval, ale jednoduche ucetnictvi v CR ma do jednoducheho ponekud daleko. Spis se jedna o podvojne bez casoveho rozliseni. Po pravde receno, jednoduche uetnictvi se da vest v ucetnich programech pro podvojne taky - staci si k tem ucetnim zapisum, ktere nemaji druhou stranu (vetsina jich kupodivu podvojna je) vymyslet nejaky ucet 'Ostatni' - a hle, mame tu podvojne ucetnictvi ;-)
Je velmi hezké, že zde konkrétně zmiňujete direktivy EU, které by měli české jednoduché účetnictví "odstřelit". Musím Vás ale ujistit, že to je BLUD. Zabývám se touto problematikou již cca 3 roky a na internetu ani v tisku jsem nenarazil na jediné skutečně odborné stanovisko, které by podkládalo spekulace o zániku soustavy jednoduchého účetnictví. Direktivy se týkají především výkaznictví - tedy výsledných dokumentů, které by měli dodržovat takové standardy, kterým budou rozumět analytici v celé unii. Takže, prosím, nešiřte fámy. Pokud máte věrohodný zdroj, rád si jej prostuduji.
Od EU nám hrozí (a to skutečně po vstupu ČR do EU nastane) snížení hranice pro vedení jednoduchého účetnictví až na jednu třetinu současné hranice, což nejspíš vytlačí většinu účetních jednotek k účetnictví podvojnému. Toto jsem si nevymyslel, ale kontaktoval jsem odborníky z EUROSKOPu.
Takže zánik se konat nebude ale výrazně se omezí počet účetních jednotek s JÚ.
problem je, ze pokud se chce clovek o direktivach neco dozvedet a zacne hledat v podneli rano, tak neco konkretniho najde v nedeli vecer, ovsem o rok pozdeji :-), uprimne, pokud se na ne zeptate lidi na ministerstvech nebo komory auditoru, vzdy dojdete k zaveru, ze nikdo nic nevi, muj prispevek jsem myslel spis tak, ze pokud bude stat chtit nejakym rozumnym zpusobem kontrolovat podnikatele (a to bude po vstupu do unie zrejme muset zlepsit), je k tomuto ucelu daleko lepsi naridit podvojne ucetnictvi vsem a obavam se, ze k tomu to presne smeruje
Nejspíš jsem nebyl úplně pochopen. To, co uvádíte, jsou jen Vaše doměnky a navíc zcela nepodložené.
Jedna nejmenovaná firma distribuující účetní soft. má dokonce na svých stránkách uvedeno, že jednoduché účetnictví by se mělo přestat používat do konce roku 2004. Kde k tomu přišli skutečně nevím. Třeba jste čerpal ze stejného zdroje: JPP ;-)
necerpam ze stejneho zdroje, snazili jsme se na seminari na fakulte dostat k nejakemu zaveru a byly a budou predneseny jeste podklady souvisejici s direktivami, vsem nam je ovsem jasne, ze jednoduche ucetnictvi tu dlouho nebude a to je fakt, prezit proste nemuze uz jen s toho titulu, ze je mnohem "mlhavejsi" nez podvojne a tato "mlhavost" se vlade nelibi a bude smerovat k vetsi transparentnosti (ne ze by se v podvojnem nejake cachry nenasli), ale videl jsem uz dost podnikatelu, co byli presvedceni jak dobre si ucetnictvi samy vedou a pri pohledu do penezniho deniku a ostatnich vykazu mi malem vypadaly vlasy, nevim jak vam, ale me pripada jednoduche ucetnictvi jako s prominutim "prasarna", ktera tu nema co delat