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

Výuka SQL v praxi. Díky za noticku o indexování
PS

vice informaci na www.oldoz-priznani.cz

Skvělý článek. Špatný název. Tento seriál by se měl jmenovat "SQL a integrita dat v praxi krok za krokem". Přečetlo by si ho mnohem víc lidí.

Díky za tento výborný článek!

Jo ! Čteš mi myšlenky . :)

Opravdu jste mě přesvědčili - v tom že Linux je prostě v této oblasti úplně k ničemu. Od účetního programu očekávám snadnou ovladatelnost a upgrade dle novych zakonu. Ne že si budu něco smolit v SQL... to můžu ve windows taky. Prostě je to jednoduché ... linux je málo rozšířen a tak se mu firmy nevěnují. Ani se jim nedivím. Je to škoda ale nedá se stím nic dělat.

Pozor to je navod pre toho kto by chcel nieco take robit a pripadne naprogramovat aplikaciu pre end-usera. To nie je navod ako viest firemne uctovnictvo. Aspon tak som to pochopil.

mozno mate zli den skustre si to precitaty v lepsom psichickom rozpolozeni ;) totiz ten clanok je urceny pre tych co si chcu nieco take naprogramovat a navyse je univerzalny lebo sa da pouzit na akejkolvek platforme kde sa rozhodnete si uctovnictvo zbuchat. Keby sa malo jednat o uctovne programy tak bi sa hovorilo o niecom inom nie o SQL tabulkach ...

hmm, myslim ze tenhle clanek byl urcen spis nam programatorum, kteri se ucetni programy snazime smolit (treba jen pro vlastni potrebu), abychom uz konecne sesmolili neco pouzitelneho. Urcite to nebyl clanek urceny pro uzivatele - spis pro programatory.

Porad tvrdim, ze na jednoduche ucetnictvi staci dve tri tabulky v MySQL - jak to mam udelane tedka. Ale zaroven nepopiram, ze by mozna stalo za to se naucit "opravdove" SQL, a ze na podvojne ucetnictvi mozna MySQL uz nejjednodusim resenim nebude... je fakt, ze diskuze, co vsechno umi PostgresQL navic proti MySQL by byla zajimava. Treba s "CREATE VIEW" jsem se v tomhle clanku setkal poprve.

Mno, myslím si , že ta diskuze by byla zatraceně velká. :)) PostgreSQL na to, že je opensource a pokud sem pochopil správně jeho licenci tak zcela free je to, čemu se říká databázový server. Viz. dokumentace na postgresql.org. Těch užitečných fíčur má zatraceně požehnaně :)

Pravda je, že úloha typu jednod.úč. se taky dá řešit tak jak popisuješ , ale přidání referenční integrity, pohledů, ev. procedur , to bych přirovnal přidání správné směsi koření do dlabance, aby to mělo šmak :))

Ale myslím, že by stálo za to, kdyby o tom někdo napsal seriál . K tomu komentáře čtenářů, myslím, že by to nebylo marný. Domnívám se, že by po přečtení takového seriálu hodně lidí fofrem zapomělo na MySQL :))

Faktem je, že při rutinní praxi člověk kolikrát na řadu přijemných věcí a technik nenanarazí, takže takovej seriál by byl myslím pro řadu lidí dobrou inspirací. Za boha se nepovažuju, takže bych se rád třeba přiučil věcem které opomíjím :)

To: Petr Bravenec: Co ty na to ? :))

:-) člověče, že ty si děláš legraci a chceš jen tak z legrace rozpoutat flamewar ? :)) že sem uhádl smysl tvého přizpěvku, viď ? :))

Jinak viz. moje předchozí přízpěvky -taky bych ten seriál spíše nazval "datová integrita v SQL" s názornou ukázkou na modelování účetnictví ... koneckonců jak už tady někdo psal tuhle myšlenku ... asi by si to pak přečetlo víc lidí... jinak ten seriál je fajn opakování o technikách v SQL ....

To já i jsem blázen --- mám totiž poruchu osobnosti.

Tento-krat by som mozno chcel otvorit diskusiu trochu inym smerom. Ze by sa tykala toho o com pisal serial.

Mam voci ukazanemu db modelu jednu vyhradu. Vela udajov je tam duplicitne, co je pri referecnych databazach podla mna zbytocne. Uz len napr to ze do tabulky musim zadavat nejaku operaciu 2-krat a vyuzivat transakciu. Ono ked sa to v PU robi tak ze to pisem do dvoch roznych tabuliek, neznamena to ze sa db-model toho musi drzat.

Moje riesenie spociva v tom ze by sa to insertovalo ako jeden riadok, s odvolanim sa na dva rozne ucty. Tym padom nemusim dvakrat zadavat tu istu sumu.

Ten datový návrh skutečně není zcela optimální. V deníku jsou některé věcí duplicitně (datum, doklad). Tohle mi trochu uteklo. Cekal jsem, že se někdo ozve.
Ale dát deník do do jedné tabulky, ukládat transakci jako jeden řádek, není schůdná cesta. Obecná transakce má řádků více, než jen dva.

Dobry den,

ja bych se taky primlouval o to, aby byla veta o obsahu: MD, DAL, castka. Pak se smazanim jedne vety nezbori integrita celeho uctovani... Proste mam dojem, ze psat jeden zapis na dva radky je nesikovne a hlida se to daleko hure, nez druha moznost.

Je mi jasne, ze jde o toto:

jeden ucet MD: celkova castka faktury
-jeden ucet D: cast z teto castky
-druhy ucet D: dalsi cast z teto castky

V mem pripade by to proste bylo takto:
ucet MD, jeden ucet D, cast z teto castky
ucet MD, druhy ucet D, druha cast z teto castky

Pokud z toho chci ziskat predchozi pripad, proste si nascitam stejne MD pres jeden doklad (klauzule group by) a jeste k tomu usetrim jeden radek v tabulce.

Zdravi
Honza Marek

Prave pracujem na datovom modeli pre nas projekt tucniak.sk. No a narazil som pri tomto mojom rieseni na problem. A tou je uz ta spominana DPH, kde sa suma z jedneho uctu rozdeluje na dve dalsie sumy na dvoch inych uctoch. Takuto operaciu by som jednym insertom nezvladol, jedine ze by ten dennik obsahoval viac stlpcov pre taketo rozdelenie sumu na viac uctov.

Taketo riesenie vsak odporuje vsetkej normalizacii atd, takze sa asi priklonim k navrhu podobnemu tomu co tu bol opisovany. Ale chcel by som sa spytat ci vobec existuju este ine uctovne operacie kde sa sumy podobne rozdeluju a ak ano ci to moze byt na viac ako dva rozne ucty. Prehrabavam sa teraz roznymi knizkami a nenasiel som inu operaciu ako DPH.

opravdu mohu jedine doporucit jednoduche ucetnictvi kazdemu, kdo na nej podle zakona ma narok - a pokud takovych lidi bude hodne, treba se nam podari vyvinout urcity natlak, aby moznost uctovani v jednoduchem ucetnictvi zustala zachovana. Je totiz poctivejsi - napr. dane platim jen z toho, co doopravdy dostanu do ruky (Prijmy zahrnute do zakladu dane), a ne ze vsech faktur, ktere vystavim. Navic si myslim, ze musi existovat zpusob, jak z jednoducheho ucetnictvi v libovolnem okamziku "nasimulovat" podvojne ucetnictvi" - je to podle me normalni zobrazeni z N- do M-rozmerneho prostoru, ne ? ;-)

V jednoduchem ucetnictvi rozhodne vystacim s jedinou tabulkou pro penezni denik, a s druhou pro fakturaci. Vtip je ten, ze vystaveni faktury v jednoduchem ucetnictvi neni event pro penezni denik - veta se vklada v okamziku zaplaceni faktury. Take prevody penez mezi bankou a hotovosti se resi elegantne jedinou vetou. Platce DPH nejsem, ale mam pocit, ze by zaplacenim faktury u ktere jsem platce DPH vznikly v jednoduchem peneznim deniku dve vety.

Penezni denik pro jednoduche ucetnictvi ma samozrejme taky analyticke moznosti - vety si oznacuji nejakymi textovymi poznamkami, takze samozrejme muzu vypsat bud vsechny vydaje, nebo treba jen kolik jsem zaplatil tenhle rok ci mesic za mobilni telefon. Hlavni rozdil proti podvojnemu (podvodnemu) ucetnictvi bych spatroval v tom, ze operuji pouze s kladnymi financnimi operacemi - resp. ve vysledovce se muzu dostat "do minusu", ale je jasne, ze treba zaporny zustatek v pokladne je nesmysl, a ze znamena, ze jsem zapomel do deniku napsat, ze jsem do pokladny vlozil svoje penize. Do jednoduche ucetnictvi se zkratka nepisi zavazky - predpoklada penize tak nejak jako nejakou absolutni hodnotu, ne neco, co si muzu jednoduse vycucat z prstu na nejakem uctu. Penize jdou bud z banky, nebo v hotovosti - nic jineho. Zavazky a pohledavky se nezjistuji z penezniho deniku, ale z knihy faktur. Analyticka sila jednoducheho ucetnictvi je podle me stejna, jako u podvojneho - s jedinym rozdilem, ze faktury, ktere jsem dosud nezaplatil (zavazky) se taky nedaji zjistit, protoze se do ucetnictvi zapisuji az ve chvili, kdy na ne mam penize. Takze jednoduche ucetnictvi neni skutecne vhodne pro firmu, ktera by poctive evidovala kazdou doslou fakturu, hned jak se ocitne na stole - v jednoduche ucetnictvi konci v supliku, a ucetni nebo podnikatel se tim suplikem rucne probiraji, a sami rozhoduji, kterou zaplati, a kterou ne. To je podle me daleko prirozenejsi a operativnejsi pristup, ktery taky umoznuje daleko jednoduseji zruseni objednavky a vraceni faktury, a podle me by takhle mela fungovat cela ekonomika...

Zauctovani kazde slozitejsi prijate faktury ma obvykle jeden "zaznam" na ucet zavazku o n "zaznamu" na ucty nakladu. K tomu jeste DPH.
Lze se celkem spolehlive tvrdit, ze ucetnictvi vybudovane nad modelem "doklad;ucet;castka;...(dalsi identifikatory)" je schopne prirozene absorbovat vsechny modelove ucetni pripady efektivneji. Az se dostanete k reportingu nad "hlavni knihou" a "ucetnim denikem", ocenite vyhody, ktere tento model prinasi.
Obecne lze, v pripade ucetnictvi, doporucit vcasnou analysu pozadovanych vystupu. Ve finale by mohly tvorit az 90% vysledneho produktu.

Zdravim,
hledal jsem nejake reseni ucetnictvi na linuxu a rekl jsem si, ze se mrknu na roota, co najdu. Nazev clanku me navnadil, protoze jsem si myslel, ze autor najde nejaky open-source program (samozrejme v anglictine) a poradi, kde sehnat nejake aktualni defaultni ciselniky platne pro CR (uctova osnova, zaverka, DPH, nejake dalsi standardni vypisy, atd. atd.). Misto toho vsak je zde jakysi navod na vyrobu ucetnictvi na kolene. To je, jako kdybych si nekde precetl, jak sestrojit notebook. Kdyby se mi to cirou nahodou vubec podarilo tak, ze by to bylo funkcni, tak by to urcite byl paskvil, ze ktereho budou couhat draty a pravdepodobne to bude umet bootovat pouze z diskety do hole prikazove radky. A obdobne bude vypadat takto vyrobene ucetnictvi - funkcni, ale zcela nepouzitelne. Kde je parovani dokladu, evidence DPH, zaverka, uzaverka atd. atd. ? Kdyby vyroba ucetniho software znamenala pouze takovouto drobnou namahu, tak se zadne firmy, produkujici ucetni programy pro male firmy, vubec neuzivi.

Clanek to nebyl spatny, ale rozhodne nepojednava o tom, jak na ucetnictvi na linuxu. Spise popisuje, jak si vytvorit databazi, ktera vzdalene pripomina neco jako databazi programu pro ucetni agendu.

Karel