![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() Uvod Stav vývoje ![]() Konference ![]() Pravidla IRC ![]() Vývoj Download Dokumentace CVS Odkazy ![]() | ![]() |
UCTO.LINUX.CZ
Konference - IRC - Session 2Tato session se uskutecnila dne 5. 10 2001:<VKoranek> 7 min. to left<VKoranek> Tak moc lidi tu zrovna neni :-( <VKoranek> Nebo mm pockat na 14:00 .-) <jmarek> zdar... ja zrovna programuju na Web zaznam z te prvni session... <jmarek> roman zdravim... <jmarek> zatim trosku jeste cekame, jestli se nekdo neprida... <VKoranek> Tak zdravim <VKoranek> Jinak jestli chce neco Roman hodit k diskuzi do placu, je moznost .... :-) <jmarek> tak jsem ted na http://ucto.linux.cz hodil nasi prvni session... ;-) <jmarek> jeste to bude chtit teda graficky doladit, ale jinak je to uz OK... <jmarek> takze ted jsem k dispozici... <jmarek> Petr Fershmann sel do skoly... <VKoranek> Vzhledem k tomu, ze nas asi vic nebude :-( zacli ? <VKoranek> Haloooooooooooooo <VKoranek> :-) <jmarek> proc ne... <jmarek> omlouvam se, jeste porad si hraju s tim webem... <VKoranek> Tak mame dva typy el. dokladu <VKoranek> prvotni doklad bude zrejme odlisny modul od modulu .... <VKoranek> ucetni doklad vzdy sejny neb bude jen v jednom modulu ... <VKoranek> Navrhhuji probrat jako hlavni modul :-) modul ucetnictvi (popripade co budeme za modul povazovat) <VKoranek> Howk <jmarek> nebudeme se jeste zabyvat tokem dokladu, kdo je bude mit v ruce apod.? <VKoranek> Nemyslim si ze je treba: <VKoranek> Kdyz budu konkretizovat a bavit se pouze o napr. fakture <jmarek> hmm... <jmarek> dobre... <jmarek> tak tedy faktura... <VKoranek> Tak staci jednotlive role v systemu aplikovat tak, e budu mit ACL k polokm faktury (dodavtel,..) <VKoranek> Paklize si myslis neco jineho (ne ze bych te za to ... :-) ) rekni proc <jmarek> prosim bez diakritiky, diky... <VKoranek> Ani jsem si nevsiml :-) <jmarek> no, pokud specifikujeme role, tak budemem mit jasno i o minimalnim poctu ACL... <jmarek> jinak budeme muset ACL delat temer na vse a pak vyhazovat nepotrebne... <VKoranek> To asi ne ... :-) jak prvotni doklad tak ucetni by mely mit nejake standartni + nejake rozsirujici, jinak nikdy nevyhovime vsem ... .-) <VKoranek> Jo ACL na vse ... :-( <VKoranek> Stejnak bychom k tomu jednou dospeli :-) <jmarek> nerad bych, abychom dopadli jak ve WinNT s registry: tam se michaji polozky: uzivatel, masina a sit dohromady... <jmarek> Co z toho muze vzniknout, nez gulas? <VKoranek> Tomu rozumim, ale garantuji, ze od velikosti cca 5 users uz jsou potreba ACL na vsechno .... <VKoranek> Gulas je pouze relativni ... Od toho bude moznost defautnich nastaveni, ne ? <jmarek> myslim si, ze by bylo lepsi udelat to tak, ze by byly specifikovany polozky a pak u uzivatelu by bylo napr.: polozka:R, nebo polozka:W... <jmarek> no, aby na to nemusel byt specialni tlusty manual, jak nastavit prava ;-) <VKoranek> Jako idea je to dobry <VKoranek> Vsak se nase navrhy naylucuji, nebo ano ? <jmarek> asi spis ne... Stene to nakonec bude muset byt tak, ze bude nejaky default a pak specifikum pro toho ktereho uzivatele... <VKoranek> P.S.: Default polozka muze byt DENY :-) + Default skupina uzavatelu administrator s pravy RW ? <VKoranek> No ja predpokladam skupinova prava, lepe moznost skupinovych prav <jmarek> asi bude rozumne zalozit i nejake skupiny pro jednoduchou administraci... <VKoranek> Nutne <jmarek> neco podobneho jako unixovy filesystem... <VKoranek> Tak dalece ho neumim, ale postacoval by :-) <jmarek> ;-) <VKoranek> Takze ... nekde se lisime ? <jmarek> no, takze zpet k dokladu: prijde napr. faktura, kterou bude treba zauctovat... <jmarek> ani ne ;-) <VKoranek> A ? <jmarek> ale jako ujasneni to bylo dobry, ne? <jmarek> no bude ji treba dat do systemu... <jmarek> takze bude treba vyplnit zakladni udaje (zatim asi pomineme, ktery) <VKoranek> Tj. chces se bavit o toku dokladu ? <jmarek> tim by se mela vytvorit polozka v evidenci prvotnich dokladu... <jmarek> zkusil bych to... co ty na to? <VKoranek> Nebo o tom jak a co ma doklad obsahovat ? <jmarek> to bych se pokusil zatim vynechat... <VKoranek> Tok dokladu je z meho pohledu jasny. <VKoranek> nejdrive prvotni doklad <VKoranek> po te ucetni <jmarek> rekneme pokus o specifikaci, co se s tou fakturou bezne dela a co by bylo dobre implementovat do naseho programu... <jmarek> jasny... <jmarek> ovsem napr. u nas je treba tuhle fakturu potvrdit nejakym nadrizenym... <VKoranek> potom musime rozdelit pozadevek na to co se dela s fakturou od pozadavku na to co se dela s primatnim dokladem a osobne si myslim ze by bylo jednodusi zabyvat se ucvetnim dokladem neb ten ma vzdy tejne zpracovani <jmarek> mozna jo... <jmarek> ale treba by nebylo od veci umoznit napr. putovani dokladu po firme... <jmarek> a to treba i nekterych, ktere firma vydava... <VKoranek> Ono pak pujde mechanizmy na kterych se domluvime na ucetnim dokladu pouzit i na prvotni ... <VKoranek> Putovani jednoho dokladu po firme kazdy doklad muze v pripojene evidenci / tabulce nest informaci o tom u koho zrovna je, s casovym razitkem i vyjadrenim prisl. pracovnika <jmarek> treba tak, ze by kazdy uzivatel toho systemu mel jakousi frontu, kam by mu ty doklady chodily... <VKoranek> ? <jmarek> no neco takoveho... <VKoranek> Lepe bych to videl jako view na pred chvilkou zminenou evidenci <jmarek> jen abychom nenarazili na prilisnou slozitost... <jmarek> hmm... to neni spatny napad... <VKoranek> no a kdyz je view tak mame moznost o tom informovat uzivatele napr. e-mailem a hle mame tu workflow :-) <jmarek> jo jo... prave... je mi jasny, ze to je tak trosku z rise snu... <jmarek> ale velmi by se to hodilo... <VKoranek> Ani ne <VKoranek> Me taky <VKoranek> A staci malo :-) <jmarek> no, jak se to vezme... <VKoranek> Jo naprogramovat rozhrani a server ... <VKoranek> Ja tu databazi primo vidim :-) <VKoranek> Jen k ni mit rozhrani <jmarek> hmm... to mas ale ostry zrak ;-))) <VKoranek> Taky uz v tom / na tom pracuju od 1993 <VKoranek> :-) <VKoranek> (datovy model) <jmarek> aha, takze nejen ostry zrak, ale i zkusenosti... no vida... ;-) <VKoranek> :-) <VKoranek> Tak se vratime k definici ucetniho dokladu ? <jmarek> jasne... <VKoranek> Z jakoho pohledu se na nej chces divat ? <jmarek> rekneme tedy, ze mame zaevidovany prvotni doklad a uzivatele se k nemu muzou vyjadrovat napr. formou poznamek... <jmarek> no a ted prijde zajimava transformace: prvotni doklad -> ucetni doklad <VKoranek> Tu pro zjednoduseni prsim ted vynechme <VKoranek> :-) <jmarek> ;-) <jmarek> no, prece jen bychom si alespon meli mirne ujasnit, jak bude probihat, ne? <VKoranek> Netreba tato transformace muze probihat klidne i jako xml2xml ani az tak zajimava :-) (ted) Ja bych to smeroval k modulu ucetnictvi s rozhranim <jmarek> hmm... tak zkus ;-) <jmarek> jako zkonkretnit... <VKoranek> P.S.: Urcite budeme potrebovat predkontace a dalsi ficurky, ale ty se vztahuji dle meho nazoru k prvotnimu dokladu <jmarek> no, urcite plati, ze (vybrana data z prvotniho dokladu)+kontace=ucetni doklad... <VKoranek> jako prvni krok bychom si mohly vytycit vytvoreni modulu ucetnictvi a to minimalne popisu :-) <VKoranek> P.S.: potvrzuji rovnici :-) <jmarek> dobra. rekneme tedy, ze budeme mit jako prvni priblizeni modul ucetnictvi a modul evidenci prvotnich dokladu <VKoranek> OK <jmarek> a ted se zamerime na ten modul ucetnictvi... <VKoranek> Nejdrive co po nem chveme ? <jmarek> v kazdym pripade potrebujeme evidovat jednotlive ucetni pripady tak, abychom z nich byli schopni sestavit financni denik a ucetni denik, nebo jak se to jmenuje... Jsou to ale vlastne jen dva pohledy na ta sama data... <VKoranek> OK <jmarek> dale musime byt schopni zajistit jakousi konzistenci ucetnich zapisu <jmarek> co si pod tim predstavuji: <VKoranek> (Takze potrebujeme rozhrani pro editaci, format dat a store pro ulozeni ) <jmarek> ano... <jmarek> i kdyz s tou editaci bych byl asi dost opatrny... <VKoranek> Predim by jsi mel ovsem definovat co obsahuje / znamena ucetni zapis <VKoranek> P.S.: Opatrnost viz ACL <jmarek> v konfere jsme psali, ze editovat by mel jit predevsim doklad v prvotni evidenci... <jmarek> nebo spise dostat doklad do stadia pred tim scitanim, ktere jsem tu uvadel ;-) <VKoranek> A co zmena MD a D ? <VKoranek> (porizovac a uctetni jsou rozdilne osoby) <jmarek> no tot otazka... <VKoranek> Jak rikam ACL :-) <jmarek> ja bych asi udelal takovou kulisarnu: <VKoranek> Pricemz nerikam ze to tak muze byt nastaveno <VKoranek> nemuze <jmarek> v ucetnictvi by byla fronta dokladu cekajicich na zauctovani, kde by se dalo v podstate kouzlit s uctovanim <jmarek> ale do teto evidence bych zas moc zasahu nepovoloval... <VKoranek> Jak jsi rekl v ucetnictvi :-) <VKoranek> ne na prvotnim dokladu <jmarek> I kdyz: oprava kontace s tim, ze by se pouze prepsal jeden ucet... <jmarek> no, neco na tom taky je... <VKoranek> System urcite pujde sesnerovat vy stylu ABRA :-) , ale mel by byt take dost volny pro ty co vi co delaji :-) <jmarek> no, ono i v ABRE je mozno upravovat veci primo v ucetnictvi... <jmarek> dobra... <VKoranek> Definice co obsahuje / znamena ucetni zapis <VKoranek> ? <jmarek> minimalne ale na castku bych nedovolil sahnout, protoze to znamena zvetseni poctu radku... (je treba dopsat nekde to, co zbyva, pripadne zmenit jeste jeden radek...) <jmarek> k tomu obsahu: <jmarek> videl bych to tak na: <jmarek> MD,D,datum,nejaky odkaz na prvotni doklad,text zauctovani,priznak, zda proslo uzaverkouDPH, priznak, zda proslo uzaverkou roku,DPH index. <jmarek> Zapomnel jsem na neco? <roman> co je to DPH index <jmarek> Jo, zapomnel: myslim, ze by bylo dobre udelat ve stylu ABRY jeste jeden index jedinecny napr. v tom roku a dle neho sdruzovat doklady, ktere k sobe logicky patri... <roman> proc je vec ktera souvisi s DPH na radku ucetniho dokladu <VKoranek> Datum, doklad, text operace, castka (K <jmarek> DPH index je oznaceni, ktere rozlisuje polozky jednak na zaklad nebo dan a jednak na typ te dane... <jmarek> tedy DPH samozrejme... Koukni na priznani k DPH, co vsechno se musi evidovat... <jmarek> No a jeste me napadly cizi meny??? Jak s nimi? <jmarek> Ucetnictvi se IMHO vede v jedne mene, takze napr. v Kc... <VKoranek> Vaechny ostatni jsou rozsirujici pricemz mezi bezne pozadovane patri: parovaci znak, vyporadaci znak, castka CM, kurz CM, index DPH, stredisko, zakazka <jmarek> ???vyporadaci znak??? <VKoranek> Ucetnictvi se sice vede pouze v K <VKoranek> :-) <jmarek> jo, to stredisko a zakazka by tam mely byt... <VKoranek> vyporadaci znak oznacuje ucetni polozky ktere vyznamove patri do jedne skupiny napr. predpis a platba <jmarek> castka CM a kurs CM je prebytecny: to se vyrovnava kurzovymi rozdily... <VKoranek> Ucetnictvi se sice vede pouze v K <VKoranek> povinost <VKoranek> :-) <jmarek> jo, tak to je pro meten jedinecky index v ramci napr. roku... <VKoranek> ? <jmarek> dobra, nazveme to vyporadaci znak... <VKoranek> Ten je stejny pro celou skupinu <jmarek> jo... tak jsem to myslel... <jmarek> tak a jeste mi nejsou uplne jasny ty CM v tvem navrhu? <VKoranek> casta CM a kurz CM : <jmarek> ja bych tam dal proste castku... <VKoranek> napr pro predpis FP na 10 DM je treba <jmarek> tohle si myslim, ze by se melo resit uz v evidenci prvotnich dokladu a do ucetnictvi by mela prijit jedna castka, ktera uz by byla prepocitana... ne? <jmarek> ale dokonci to... <roman> do ucta musi jit jet Kc, ale je dobre tam videt i CM, krasne se pak sleduje saldo napr. 221 a 211 proti knize prvotnich dokladu <jmarek> to nechapu? <jmarek> zkus napsat nejaky priklad... <roman> dostanu pokladni knihu v USD a soucasne si vyjedu ucet taky v USD <VKoranek> roman to je spravny smer <VKoranek> Omlouvam se musim odejit .... <VKoranek> Zdar <jmarek> mej se... <roman> budem pokracovet nebo toho nechame <jmarek> muzeme pokracovat... <jmarek> ;-) <jmarek> jeste porad mi to neni uplne jasny... <jmarek> myslis tim jako pobocku v zahranici? <jmarek> nebo moznost vest pokladnu v cizi mene? <roman> ANO, pokladny a banky vest v cizi mene <jmarek> aha... <roman> a soucasne v KC <jmarek> tohle jsem jeste neuctoval, tak si to moc nedokazu predstavit... <jmarek> no, ono to nakonec musi byt v Kc, jako pri inventarizaci... <jmarek> a dorovnava se to kurzovyma rozdilama, ne? <jmarek> a taky pri uzaverce, jasne... <roman> zadavam pokladni doklad v USD a zadam kurz ke Kc <roman> na konci roku provedu uzaverku pokladny a prepoctu ji v kurzu dle CNB <jmarek> jasny a dal? <roman> v kase mas stejne nejake USD a ty ti musi odpovidat tomu co je v programu <roman> nelze to prepocitavat dle kurzu <jmarek> jasne... ale pak to vlastne v uzaverce do ucetnictvi musis nejak srovnat dle kurzu, ne? <roman> uzaverka pokladny a banky vytvori kurzovy zisk nebo ztratu a to pouze v Kc <roman> ke konci ucetniho obdobi musis mit v pokkladne vedene v cizi mene tolik co na uctekurz <jmarek> jasne. potrebujes tedy spocitat kurzovy rozdil pokladny a zauctovat to jako zisk/ztratu... <roman> jak jednoduche :-) <jmarek> ale proc bys mel vest polozky CM a kurzCM primo v ucetnictvi? <roman> predstav si ze nekde udelas chybu, lehce se ti to dohledava <jmarek> staci si prece nechat vypsat stav pokladny a vynasobit kurzem CNB (napr.) <jmarek> no a co kdyz mas takovy priklad: dostanes fa v DM a platis v Euro? <jmarek> (teda pripustme, ze by to slo, ono to uz vlastne ani jit moc nema) <roman> Haa ?? <jmarek> nebo jinak: mas napr. ucet v USD a zaplatis z nej fakturu v Euro... <roman> Je potreba se vyrovnat jak s kurzem tak s vzniklym prepladkem, nedoplatkem <jmarek> tohle je mi jasny... <roman> A jaky je zde problem? proste mi z uctu odejde USA a <roman> na druhou stranu prijde bud USD nebo Euro jak reknes, a pak taky podle toho platis poplatky <jmarek> problem je ten, ze tu mas kurzy dva... jeden USD/Euro a druhy USD/Kc <roman> musis prepocitat kurz platby na Kc a pak Kc prepocitat na DEM (treba) <jmarek> tedy v nasem priklade na Euro, je to tak? <roman> podle kurzu ktery ma tva firma stanoveny <jmarek> no, jasny mi to tedy porad moc neni, ale rekneme, ze to tam tedy bude dobre... <roman> odesles 100 USD (34kc), -> 3400kc -> xxEURO (30kc) <jmarek> porad si ale myslim, ze bych si vystacil s tou castkou v Kc... <roman> myslis v ucetnim deniku? <jmarek> no a tvuj kontrolni mechanismus bude fungovat jak? <jmarek> ano... <jmarek> nadefinujme si to tedy presne... <roman> polozim si vedle sebe dve sestavy, pokladni knihu a ucet 221 <jmarek> dobra, pokracuj... <roman> to je vse :-), zbytek spravi ostra tuska ucetni <jmarek> no a co uvidis? <jmarek> pokladni kniha bude mit pohyby v USD, 221 bude v Kc... <roman> rozdily, v cizi mene a Kc <jmarek> a budes prepocitavat kurzy... <roman> NEE, 221 bude jak v Kc tak v USD, stejne jako pokladny/banka <roman> ta cizi mena je tam jako dalsi informace pro snazsi orientaci <jmarek> jo tak... konecne jsem to pochopil... <roman> takze pokracuj <jmarek> proto jsem uvadel ten priklad se dvema menama: vlastne mi slo o to, jakou menu pak polozis do toho ucetniho zapisu... <jmarek> cili jde pouze o polozky na uctech 221 nebo 211 v pripade, ze existuji pokladny, nebo bankovni ucty v cizi mene... <roman> menu v ktere to prislo, fakturu v EURO, platbu v USD a vse v Kc <roman> rekl bych ze to same se tyka zaloh 314/324, odberatelu dodavatelu 311/321 a mozna i dalsich <jmarek> Pak se do te polozky CM zapise vlastne kolik odeslo z toho uctu, pripadne kolik se z te pokladny vyplatili v te same cizi mene, v jake je ta pokladna, nebo ten bankovni ucet. <jmarek> Je tak? <roman> Ano je tak <jmarek> co se tyka zaloh, dodavatelu apod: tam je vzdycky zaznam vzhledem k placeni, coz je tedy vzdy tak, ze jeden z uctu (MD,D) bude 211 nebo 221. <jmarek> cili se tim zkontroluje, zda pokladni nevyplatila o 10 vic, coz by se ztratilo v kurz. ztrate... <jmarek> dobry... uz je mi to jasny... <roman> nejsem si jisty ze si rozumime <jmarek> ??? <roman> v pokladni knize je 10USD co ze 340Kc a to same je v ucetnictvi, to plati pro jakykoliv doklad, fakturu, zalohu .... <jmarek> ano... <roman> pak je vse OK, a muze postoupit dale :-)) <jmarek> no, jeste kdyz se tak na to divam: tebe prece pri uctovani _predpisu_ zalohy nezajima CM a kurz. rozdil: to te prece zajima az pri uhrazeni/prijeti penez, ne? <jmarek> (teda do te pokladny, prip. na bank. ucet v cizi mene) <jmarek> ty to prece mas uctovat v Kc... <roman> to je sice pravda, ale na 314/324 by me to teda hodne zajimalo, kolik mi tam visi uhrazenych a nevycerpanych zaloh <jmarek> Nebo je mozne poslat do zahranici fa v USD? <jmarek> ale jiste, ale to v Kc prece lehce vycislis... <roman> Nase legislativa umoznuje vystavit tuzemskou fakturu v USD, ale je tam problem s vycislenim DPH <jmarek> (protoze v ucetnictvi to v Kc mit budes) <jmarek> no proste dobra: v ucetnictvi bude polozka CM a kursCM a pak uvidime, kdy bude rozumne do teto polozky neco psat... <jmarek> V podstate asi tedy i pri vydani dokladu v CM... <roman> psat by se tam melo vzdy, otazkou je kdo to pouzije :-)) <roman> stejne se to bude pocitat automaticky <jmarek> i kdyz to bude v Kc a kurz bude 1:1? ;-))) <roman> to zalezi na tom kdo to naprogramuje :-)) <roman> rsp. kdo udela analyzu <jmarek> at zije jednoduchost ;-) <roman> co tedy bude obsahovat ucetni zaznam (v deniku?) <jmarek> uz to hledam... <jmarek> MD,D,datum,odkaz na prvotni doklad, DPH index, castkaKc, castkaCM, kursCM, parovaci znak, vyporadavaci znak, stredisko, zakazka, priznak, zda doklad prosel uzaverkou DPH, priznak, zda doklad prosel uzaverkou roku, text zauctovani <jmarek> je to komplet? <roman> zarai me to DPH, pro ho cpat do deniku? <jmarek> o tom jsme diskutovali predvcirem, koukni na web ;-) <jmarek> uz to tam je ;-) <roman> OK, kouknu a uvidim <roman> dal bych tam datum dokladu, datum uctovani a pokud by tam melo zustat i to DPH pak datum plneni <jmarek> hmmm... o to by se to asi melo rozsirit... <jmarek> aby se DPH dalo z toho deniku jasne vytahnout... <roman> nechapu? <jmarek> co? <jmarek> no jen rikam, ze ty polozky, co's uvedl, by se tam mely dat... <jmarek> jako doplnit... <roman> nechapu to s tim DPH, jak vytahnout? <jmarek> no, aby se z toho ucetnictvi dalo vytahnout priznani k DPH... <roman> muj nazor na DPH .. <jmarek> no? <roman> kazdy prvotni doklad ma v nasich koncinanch maximalne 3 sazby 0, 5, 22 <jmarek> a dal? <roman> vytvorit vlastni evidenci (tabulku) ve ktere se zaznamena doklad a jeho sazba, zaklad, dan vstup a vystup) <jmarek> neni to tak jednoduchy... <roman> to znamena, ze by kazdy doklad mel max 3 radky .... <jmarek> koukni se na formular priznani k DPH, co vse je nutne evidovat... <jmarek> navic se ti muze sazba DPH zmenit... <jmarek> proto ty indexy DPH... <roman> vim celkem dobre jak vypada soucasny formular DPH a vim co je treba evidovat <roman> ja nerikam, ze DPH indexy ne, jen si myslim, ze neni dobre je svazovat s ucetnictvim <roman> a to take z duvodu moznosti kontroly 343 proti DPH <jmarek> jasny, neni to potreba... Ale Vaclav Koranek predvcirem zastaval nazor, ze by to melo jit... <roman> moment neco plodim... <jmarek> ??? <roman> Problem nastava u faktury prijate, tam je treba rozlisit zda se jedna o nakup, kde si mohu uplatnit odpocet, nebo budu kratit pomoci koeficientu, nebo nemam narok na odpocet ... <jmarek> to se da prece vyresit pri zapisu faktury do prvotni evidence, ne? <roman> to by znamenalo ze pokud nastane tato kombinace na jednom radku faktury pak tento radek musim zauctovat nekolika zapisy do ucetnictvi abych mohl dat pokazde jiny DPH index <jmarek> ano... to souhlasi... <jmarek> je v tom nejaky problem? <roman> ja bychrekl ze jo, proc zbytecne natahovat ucetni denik? <jmarek> no, myslim, ze takovych pripadu moc nebude? <roman> to je sice pravda, ale to me nepresvedcilo, mozna bych tuto debatu nechal az se bude moci Vaclav Koranek vyjadrit, <roman> rad bych ho presvedcil :-)) <jmarek> mozna k tomu mel jeste i jine duvody... treba kontrolni... <jmarek> ja jsem v podstate zastaval taky nazor, ze by melo stacit delat evidenci DPH z prvotnich dokladu... <jmarek> Ale chapu, ze nekdo treba bude chtit delat tuhle evidenci z ucetnictvi... <jmarek> pokud se jedna o vetsi pocet radku: nemel by to byt az takovy problem... <roman> To muze znamenat problemy <jmarek> proc? <roman> uz treba kontrola, pokud kontroluji 343 a DPH a vse je jen jinej pohled na stejna data, kde je zajisteno ze je vse OK <jmarek> jakym zpusobem bys ho kontroloval? <jmarek> BTW: vzdy budes mit moznost si dle jednotlivych DPH indexu doklad rozuctovat na analytiky... <roman> minimalne obrat uctu 343 mi musi sedet s radky v DPH priznani <roman> a co v pripade, ze neni neco zauctovane? <jmarek> ano, to souhlasi... <roman> a ma to byt v DPH <roman> ja si proste myslim, ze DPH ma byt oddelene od ucetnictvi, mam spatne skusenosti, kdyz je to v celku <jmarek> proto navrhuji jeste priznak bylo/nebylo zahrnuto do uzaverky DPH, kam by se asi melo napsat, do ktere uzaverky se to zahrnulo, napr. 200101-200112, prip. 200101-200104. Pak by pri kontrole mohl program zarvat: chcete delat uzaverku DPH za obdobi 01012001-30032001, ale jeste tam smrdi doklad, ktery uzaverkou neprosel a ma datum zd. plneni 30122000... <roman> to je fajn, ze mi program zarve ze je pruser, ale co to opravne priznani a z toho plynouci sankce ... <jmarek> podobne u uzaverky roku... <roman> kdyz jsme u uzaverky roku, spise bych palnoval obdobi, nemusi byt kalendarni rok = obdobi <jmarek> obvykle jde jen vzit doklad a zmenit mu dat. zd. plneni tak, aby spadal do toho obdobi. Pak se muze rict, ze prisel pozde... <roman> a pokud je to faktura, kterou jsem vystavil ja?? a nebyla zauctovana v ucetnictvi?? <jmarek> pokud to tedy neni pul roku ;-) <jmarek> to je samozrejme prus... <jmarek> no, jeste to asi probereme s Vaclavem... Jak rikam, ja jsem se taky spise priklanel k DPH z prvotnich dokladu... <roman> lze mit prechodne obdobi 1.1. - 31.3 a pak 1.4-31.3 to je jen priklad <jmarek> jasne... <jmarek> dobra... <jmarek> ja asi uz pomalu budu koncit... <jmarek> jeste se pokusim tohle hodit na web... <roman> jo taky musim zajit na objed, takze ahoj <jmarek> mej se... |
![]() |
![]() | |
![]() |
Náš projekt :-)
Copyright (c) 2001 Všechna práva vyhrazena
![]() |