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.
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.
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...
Ked si vo firme sam tak ti penazny dennik staci a vyznas sa v nom. Ale akonahle sa rozrasties tak Ti takato analytika uz stacit nebude. Podvojne ucto sa vyvijalo storocia a ma svoje dvovody preco funguje ako funguje.
Zaujimave v dnesnej dobe je len to ze na papiery moze byt sposob zaznamenavania udajov efektivny inym sposobom ako v datovom modeli relacnej databaze. Cize otazka nezie JU vs. PU ale ako PU co najeefektivnejsie previest na relacnu db.
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.
