Uvod
 Stav vývoje

 Konference

    Pravidla
    IRC

 Vývoj
 Download
 Dokumentace
 CVS
 Odkazy

UCTO.LINUX.CZ

Konference - IRC - Session 4

Tato session se uskutecnila dne 14. 10 2001:

<jmarek> logovani jsem zapnul az ted :-(
<roman> takze napriklad faktura vydana cislo 10 z roku 2001 by mohla byt jako FV-10/2001 - to je jen prikald
<roman> umim cist png
<jmarek> jete by tam mela byt moznost odlisit radu tech faktur -> moznost pro pobocky/oddeleni vydavat vlastni doklady...
<roman> jasne, na dokladu by byly 3 udaje (mimo jine) rada, cislo, obdobi; muzu mit vice rad jednotlivych dokladu, s tim se pocita
<roman> ty 3 udaje bych dal jako 3 polozky a ne jako jednu textovou, spatne se v tom hleda (programove) a program to muze uzivateli slozit do jedne polouzky
<jmarek> jasne, s tim souhlasim...
<jmarek> tak jsem udelal update CVS a je to tam...
<jmarek> je to v modulu contrib
<jmarek> users/jmarek/datModelUcetnictvi.{png,dia}
<jmarek> je tam jeste par otazniku, ale to snad doresime casem...
<roman> diky, je to parada, ale .....
<jmarek> teda urcite ;-))
<jmarek> no...
<roman> to je o te interni identifikaci vsech zaznamu/objektu
<jmarek> ano...
<jmarek> v podstate jsme se zatim bavili o datovem modelu...
<roman> pradstavoval bych si, ze vsude budou jen odkazy na objekty asi takto:
<roman> ID uctu a na nej se bude odkazovat MD,D
<roman> ID uctu bude jine nez cislo uctu
<jmarek> Myslim, ze primo cislo uctu by melo byt jeho id
<jmarek> pak ta databaze bude citelnejsi
<jmarek> bude to sice trosku pomalejsi
<jmarek> ale v tomhle pripade bych to radeji nechal...
<roman> pro citelnost z hlediska spravce to bude lepsi, ale k tomu se tedy muzeme vrati pozdeji
<jmarek> dobra...
<jmarek> je jasny, ze to schema je pracovni, takze se jeste bude menit...
<jmarek> s konkretni databazovou podobou predpkladam, ze nam poradi Karel Zak
<jmarek> ma s tim docela zkusenosti...
<roman> u dokladu v deniku bych si jeste pamatoval datum dokladu a to proto ze muze byt jine datum vystaveni doikladu a datum uctovani
<roman> datum uctovani ma byt datum plneni
<jmarek> nad tim jsem uvazoval: je to uplne nutny?
<jmarek> to datum dokladu budeme mit v databazi prvotnich zaznamu a budeme se na ni umet rychle odkazat...
<roman> to je sice pravda, ale bude jedna tabulka prvotnich dokladu, nebo bude pro kazdy typ dokladu jina??
<jmarek> to zatim nevim...
<jmarek> zvazoval jsem moznost, ze by byla jedna tabulka HLAVICEK prvotnich dokladu....
<roman> proc:
<roman> proc?
<jmarek> no a proc ne?
<jmarek> jak rikam, je to zatim pouze uvaha, ale branilo by tomu neco?
<roman> prvotni doklad je dodaci list, faktura, interni doklad, kazdy z nich ma sice podobne udaje, ale mnoho rozdilu
<jmarek> to je pravda...
<roman> ale ja se nebranim nejake tabulce spolecnych udaju a dalsi pro kazdy tym dokladu, nebo skupinu typu
<jmarek> :-)))
<jmarek> no, u me se zatim jedna o VELMI MLHAVE predstavy...
<jmarek> myslim, ze by bylo dobre o tom trosku podiskutovat s nekym, kdo uz treba o tom premyslel...
<roman> ja v tom nemam taky uplne jasno co by bylo nejlepsi
<jmarek> minimalne si myslim, ze by bylo dobre do jedne databaze sloucit hlavicky dokladu, ktere budou mit vliv na DPH...
<jmarek> aby se pocitani DPH mohlo delat pres jednu databazi...
<jmarek> teda tabulku... ja jsem ovlivneny Fox--kou...
<roman> obavam se ze DPH se musi resit z radku dokladu
<jmarek> myslim, ze by se dalo pri ukladani dokladu nejak nacpat do hlavicky...
<jmarek> nebo udelat specialni tabulku ciste pro DPH.
<roman> tech udaju je mnoho, je zaklad pro 0, 5, 22 a pak jeste dalsi skupiny jako narok na odpocet, bez naroku na odpocet .....
<jmarek> a kdyz by se doklad ukladal, tak by se pro kazdy doklad do teto tabulky ulozilo vse, co je treba k DPH evidovat...
<roman> tabulka pro DPH by to resila
<jmarek> hmmm... musim se podivat, jak to ma vyreseny konkurencni produkt ;-)))
<jmarek> jen co si spustim dosemu...
<roman> jaky konkurent??
<jmarek> Abra ;-)
<jmarek> tu znam nejvic
<jmarek> a navic si myslim, ze ma pomerne logicky navrzeny databaze...
<roman> ja bych si predstavoval obsah tabulky DPH takto: identifikace dokladu (rada,cislo,obdobi) zaklad a dan, a pak nejaky odkaz na tu spravnou polozku DPH priznani
<jmarek> alespon ja jsem se v nich vzdycky vyznal...
<jmarek> no: pro zajimavost z Abry:
<jmarek> v hlavicce dokadu ma akorat castku bez DPH a castku celkovou
<jmarek> to vlastne staci k rozuctovani
<jmarek> no a DPH se pocita z radku dokladu, presne, jak jsi navrhoval...
<jmarek> asi to holt bude potreba...
<roman> omyl DPH pocita z deniku
<jmarek> neni pravda: v deniku pro to nema vsechny informace...
<jmarek> DPH pocita ale z dokladu, ktere uz jsou zauctovane v deniku...
<roman> a jak to budeme resit my?
<jmarek> v polozkach v tabulce deniku neni DPH index...
<jmarek> no, ja bych se pridrzel osvedceneho reseni ;-)))
<roman> ABRA?
<jmarek> no, ma stejny zpusob, jaky jsi navrhoval ty...
<roman> podobny, ja bych pri ukladani dokladu doplnil tabulku DPH
<jmarek> ted jen presvedcit vaclava koranka ;-)))
<jmarek> no, ja kdyz tak o tom premyslim, tak z teto tabulky by se velmi jednoduchou upravou dala vyrobit tabulka radku dokladu...
<jmarek> akorat, ze by jich tam holt bylo vice...
<roman> nechapu?
<jmarek> no, vem si napr. fakturu:
<jmarek> co radek faktury, to jedno DPH (+-)
<roman> ano...
<jmarek> no a pak je to treba pouze nascitat dokupy...
<jmarek> muzou byt tedy i jen textove radky
<jmarek> ale ty se daji vyradit nejakym logicky switchem, ze...
<roman> jaky z toho plyne zaver?
<jmarek> no, ze DPH lze pocitat z tabulky, ve ktere jsou radky jednotlivych dokladu.
<jmarek> ktere samozrejme maji na DPH vliv, ze...
<jmarek> takze faktury a pokladni pohyby...
<jmarek> a JCD-cka...
<roman> to je pravda, bude-li vsak jedna tabulka radku pro fakty prijate, dalsi pro vydane (jako abra) pak je treba natitat z nekolika tabulek (4-5)
<jmarek> ty jsou ale specialnim pripadem faktury...
<jmarek> nene...
<roman> ??
<jmarek> abra ma jednu tabulku textu pro oboje faktury (ftexty) a jednu tabulku pro texty pokladnich dokladu (ptexty). To je vse...
<jmarek> u nas by to asi slo sloucit dokupy, ne?
<roman> NE: ftexty, ptexty, fdsazby, pvsazby a jeste interni doklady
<jmarek> interni doklady nemaji vliv na DPH...
<roman> maji alespon u abry ano, a je treba je tam mit
<jmarek> jak to?
<roman> pri zauctovani leasingu je treba ovlivnit DPH
<jmarek> interni doklady jsou prece bez DPH???
<jmarek> no, tohle asi stejne nebude publikovatelny...
<jmarek> mas pravdu
<jmarek> i v internich dokladech je mozno pracovat s DPH...
<jmarek> nejak jsem si to neuvedomil...
<roman> ja bych rekl, ze ucetni obcas potrebuje ovlivnit DPH a neni to ani faktura ani pokladna
<roman> napriklad vraceni dane cizincum
<jmarek> to se da zaridit uz pri kontaci dokladu, ze se sice DPH vypocita a na doklad napise, ale nezauctuje...
<jmarek> no jo no... tak jak z toho ven...
<roman> ja byl ted mimo (telefon)
<roman> takze udelame tabulku na DPH?
<jmarek> no, ja porad premyslim, jak to udelat, aby to bylo co nejjednodussi a pritom prijatelny...
<jmarek> samozrejme bych byl rad, aby byla tabulka jen pro DPH
<jmarek> ovsem premyslim, zda by nesla spojit s texty dokladu, ktere DPH mohou ovlivnovat, tedy: faktury, pokladni doklady a interni doklady...
<jmarek> vadilo by to necemu?
<roman> ja myslim ze by to spojit urcite slo
<roman> mozna by se to dalo vyresit procedurou, ktera by pro jednotlive polozky DPH vse potrebne vyhledala v jednotlivych tabulkach
<jmarek> hmm...
<roman> ta procedura by se spoustela s parametrem daneho radku DPH priznani (DPH indexu) a vratila by zaklad a dan
<roman> vse by spocital SQL server (sumy umi kazdy) a zatizeni stanice a aplikacniho serveru by bylo male, co ty na to
<jmarek> obecnejsi by asi bylo, kdyby ta procedura mela jako prametry: dphindex, zaklad/DPH a vracela by cislo...
<jmarek> tedy sumu toho dphindexu zaklad nebo DPH
<roman> je potreba to jeste omezit za datum od do, mozna stredisko, zakazku
<jmarek> to jde vlastne odlisit i tim DPH indexem samym...
<jmarek> ano, samozrejme...
<jmarek> dobra, tohle by slo...
<jmarek> ale porad je tu otazka ukladani tech prvotnich dokladu...
<roman> jaka?
<jmarek> no, zda bude napr. pouze jedna tabulka hlavicek a jedna tabulka textu+DPH, nebo bude napr. vice tabulek hlavicek a jedna tabulka textu, nebo nakonec bude vice tabulek hlavicek, vice tabulek textu+DPH, pripadne vice tabulek hlavicek, vice tabulek taxtu a jedna nebo vice tabulek DPH udaju...
<jmarek> tohle bychom meli nejak vymyslet, abychom mohli navrhnout jednoznacne id dokladu, ne?
<roman> to je v tuto chvili prece jedno, kde to bude ulozeno bude vedet ta procka na DPH a z hlediska DPH nas vice nezajima
<roman> jednoznacne ID dokladu bude Rada dokladu, Obdobi, a Cislo
<jmarek> mozna jeste typ...
<roman> otazkou zustava jednoznacne id z hlediska systemu nebo uzivatele?
<jmarek> takhle: Typ:obdobi:rada:cislo...
<jmarek> tohle bych videl z hlediska uzivatele...
<jmarek> otazka je, jak to udelat z hlediska systemu tak, aby byl doklad v rozumne dobe dohledatelny...
<roman> proc typ? rada prece definuje typ dokladu
<jmarek> typ jsem myslel takto:
<jmarek> typ: faktura vydana, obdobi je jasny, rada:prvni v ramci FV, a cislo v ramci typ+obdobi+rada...
<roman> asi to nechapu
<jmarek> myslis, ze by se mel spojit typ s radou?
<roman> jak chapes typ dokladu?
<jmarek> typ: napr. faktura vydana
<jmarek> rada: cislo rady (napr. pro kazde oddeleni, ktere bude fakturovat, pobocku apod...)
<jmarek> jak's to myslel ty?
<roman> ne uplne, ale pouziti se upresni
<roman> typ tam se shodnem
<roman> rada: presne jako jiz zminovana konkurence
<roman> az na to ze neni nutna vazba na oddeleni
<jmarek> neni, to uvadim jako priklad...
<roman> obdobi: beru jako ucetni rok
<jmarek> dava to moznost importu dokladu z jine lokality bez toho, ze by nastavly problemy s doklady stejneho cisla...
<roman> To je prada, ale to se da resit i jinak
<jmarek> obdobi: sohlas...
<roman> treba pristupovymi pravy
<jmarek> to neni nic moc... ostatne abra to ma udelano automaticky: tim, jak si zvolis umisteni pocitace v ramci struktury firmy (do ktereho oddeleni ten pocitac spada), tak ti zacne doplnovat do cisla dokladu cislo rady: cislo oddeleni...
<jmarek> alespon IMHO: nazivo jsem to jeste nezkousel...
<jmarek> mozna...
<jmarek> u nas by bylo lepsi to resit tak, ze by sereklo:
<jmarek> faktury vydane: pro oddeleni to a to vytvarime tuto radu. A je to ne?
<jmarek> a k te rade se daji oddeleni prava...
<jmarek> rada se zase automaticky zacne promitat do cisla dokladu
<jmarek> a tim se pri importu dokladu nenadelaji problemy...
<roman> je to reseni, ale pokud budu mit nekolik oddeleni a kazde bude mit svou radu expedicnich dokladu tak v tom bude zachvili pekny zmatek (prijklad)
<jmarek> proc?
<roman> priklad:
<jmarek> alespon se hned pozna, ktery oddeleni doklad vystavilo...
<jmarek> no?
<roman> mam maoobchod a velkoobchod a oba vyskadnuji z jednoho skladu, proc mit vice rad DL
<roman> to oddeleni stejne bude na tom dokladu, jen nebude mit svou vlastni radu
<jmarek> protoze dokazes zjistit, co slo pres velkoobchod (na co jsi mel mensi marzi) a co pres maloobchod (co jsi prodal v koncovych cenach)... napr.
<roman> mam tam preci to stredisko
<jmarek> dobra... ale zkus si predstavit, ze ten maloobchod maz treba v Praze a velkoobchod napr. v tabore, protoze v praze jsou hrozny ceny najmu velkych prostor...
<roman> ja bych navrhoval nasledujici:
<jmarek> pak s vyhodou pouzijes generovani cisel dokladu vc. rady
<jmarek> protoze jinak by sis musel overovat, zda je zrovna toto cislo dokladu volny
<roman> rada nebude vazana na stredisko, bude ji vsak mozno stredisku pridelit a tim ji pridelit jednomu konkretnimu, nebo nekolika
<jmarek> nebo jaky mas vlastne pouzit...
<roman> co ty na to?
<jmarek> ano, souhlasim s tim, ze se ta rada vubec nemusi pouzit, pokud dve strediska nejsou v odlisne lokalite.
<jmarek> pokud jsou, pak by to melo byt temer povinnosti...
<jmarek> jinak s tim souhlasim
<roman> nerozumim, znamena to ze muzu mit v jedne lokalite jen jednu radu?
<jmarek> bylo by to nejrozumnejsi...
<jmarek> ne jen jednu radu, muze jich tam samozrejme byt vice...
<jmarek> ale v kazde lokalite by mela byt JINA rada (minimalne jedna), nez v lokalite jine...
<jmarek> jinak nastane problem u pridelovani cisel dokladu a u mergingu dat z techto odlisnych lokalit...
<roman> znamena to, ze stredisku se musi urcovat lokalita, co v pripade slouceni stredisek, nebo prechodu na online
<jmarek> samozrejme pri slouceni, nebo prechodu na online by tohle odpadlo...
<jmarek> jinak je jasne, ze v hlavicce dokladu by melo byt stredisko v kazdem pripade...
<roman> v hlavicce nebo obsahu?
<jmarek> domnivam se, ze by melo stacit v hlavicce...
<jmarek> nedokazu si predstavit, ze by cast faktury vystavili v tabore a cast v praze...
<jmarek> vetsinou jedno oddeleni vystavuje jeden doklad cely. ne?
<roman> moment
<roman> zase priklad: velkoobchod a servis v jedne lokalite a oba se podileji na jedne dodavce
<roman> vynosy z teto dodavky by sly pouze na jedno stredisko a nebo to musi ucetni rozuctovat
<roman> ted me napada jestli by nestacilo radu priradit na lokalitu a ne stredisko?
<jmarek> ano, to by jasne stacilo...
<jmarek> viz vyse...
<jmarek> jde mi predevsim o zabezpeceni pred kolizi se svema shodnymi cisly dokladu...
<jmarek> svema=dvema... :-(
<roman> jasne
<jmarek> tim se umozni velmi jednoduchy import dokladu z vice lokalit
<jmarek> a to i off-line, tzv. kabelovy prenos: disketa do kabely ;-)
<jmarek> nebo davkovy...
<jmarek> obecne...
<jmarek> takze jsme se domluvili?
<roman> myslim ze jo, pokud bude rada dokladu pripojena na lokalitu a v prubehu existence to pujde zmenit pa s tim souhlasim
<jmarek> a tvar 'pointru' by byl: typDokladu:ucetniObdobi:rada:cislo
<jmarek> myslim, ze rada dokladu by mela jit proste pridat do nejake konfigurace systemu a pak teprve urcit, ktera oddeleni (ve ktere lokalite) k ni maji pristup...
<roman> ten typ sice povazuji za zbytecny (je obsazen v rade) ale souhlacim
<jmarek> to bude zalezet na tom, jak vymyslime uloziste prvotnich dokladu: v tom typ-u by vlastne mohlo byt 'zakodovano' jmeno tabulky hlavicek dokladu, nebo podobne...
<jmarek> no a pokud se strediska slouci, nebo se prejde na online, pak staci zablokovat radu dva a pridat prava k rade jedna a je to...
<roman> taky moznost, ale zatim bych to nechal otevrene, stejne na rade je informace o typu, zanmenalo by to vsak sahnout do definic rady
<jmarek> dobra...
<roman> s blokovanim souhlasim, pri propojeni online se pouze nastavi rade jina lokalita a jedem
<jmarek> treba...
<roman> dohodnuto?
<jmarek> jasne...
<roman> rad bych se vratil nekam na zacatek, kdy jsme diskutovali datum dokladu v ucetnim deniku, nedospeli jsme k zadnemu zaveru
<jmarek> dobra...
<jmarek> jak to vidis?
<roman> zajimave, co jako?
<jmarek> jak to vidis = jaky na to mas nazor ;-)))
<roman> ze je vhodne mit datum dokladu v deniku, zase priklad:
<roman> prelom ucetniho obdobi, datum vystaveni dokladu je v novem obdobi, ale datum plneni a tim i uctovani je obdobi stare, potrebuji to videt v jednom zaznamu (pokud jsem ucetni)
<jmarek> dotaz: musi byt datum uctovani=datu plneni?
<jmarek> datum plneni je relevantni pro DPH
<jmarek> je i relevantni pro uctovani?
<roman> ja nevim, pokud jsem mel moznost cist zakon tak to z toho neni patrne a vyklady se lisi
<roman> doplnuji: jasne patrne
<roman> datum plneni == datum DPH
<jmarek> to sou ty nase zakony (o zakonodarcich nemluve) :-(((
<jmarek> s rovnici plne souhlasim.
<jmarek> ale nevim, zda musi nutne platit i v pripade uctovani...
<roman> prave to je ten zakon o ucetnictvi, kde se rika neco o tom jake datum ma byt datum uctovani a tady to neni jasne plneni, nebo datum dokladu
<jmarek> hmmm...
<jmarek> ja jsem myslel, ze by se dalo velmi svizne ziskat pohledem do toho prvotniho dokladu...
<roman> to je pravda, musim se vsak dotazovat do jedne nebo nekolika tabulek a jsme tam kde jsme byli
<jmarek> hmm... no prave...
<jmarek> asi budu muset uvazovat o zpusobu ukladani tech prvotnich dokladu...
<roman> co takhle osvedcena matoda, konkurence?
<jmarek> porad mi to neni jasny...
<jmarek> uz tam nahlizim ;-)
<jmarek> tam jsou primo tri data:
<jmarek> zauctovani, doklad a zd. plneni.
<jmarek> nu dobra...
<roman> plneni tam davat nebudem, nebo jo?
<jmarek> no, uplne nutny by tam nebylo. otazka je, zda by nebylo dobre...
<jmarek> jo a k tomu DPH a uprave tabulky: asi by tam taky nebyl treba ten zaznam o probehle uzaverce DPH...
<roman> asi to nebude treba
<jmarek> uz jsem to zrusil...
<roman> jeste bych doplnil do deniku informaci o tom zda je to fronta nezauctovanych dokladu nebo denik
<jmarek> jo vidis... to jsem nejak vynechal...
<jmarek> jasne...
<roman> a mozna by nebylo k zahozeni doplnit jmeno meny, pokud je uvedena cizi mena
<jmarek> tak asi spis oznaceni z nejake tabulky men: ta by se mohla hodit, ne?
<roman> urcite, mel by to byt odkaz
<jmarek> zatim jsem to nechal stejne, jako cisla uctu...
<jmarek> BTW: jdu na obed, takze tak cca 30-40 min. budu off
<jmarek> tak jsem zase tady...
<jmarek> ale stejne... nenechame to zatim trosku uzrat?
<jmarek> ja uz mam ve schrance 265 mailu...
<jmarek> ja dodelam diagram podle toho, na cem jsme se domluvili
<jmarek> a zbytek bych nechal na zitra...
<jmarek> treba se nas sejde vice...
<roman> jo, bylo by treba se zacit venovat nejake vydelecne cinnosti,
<roman> takez ahoj zitra


Náš projekt :-)    Copyright (c) 2001 Všechna práva vyhrazena