krpan in druščina postani član

Naslov teme: glavna knjiga/pomožne knjige

1214  15.02.2004 - 21:33h / Ostalo / Avtor: andrejka / 96 / 4

Lepo prosim za vaše izkušnje pri knjiženju faktur;
kot vemo obstaja več datumov pri knjiženju:
1/ datum opravljene storitve/odpreme blaga
2/ datum fakture
3/ datum zapadlosti fakture
4/ datum prejema fakture
5/ datum knjiženja fakture

sedaj pa nastopi problem:
datum pod 1. točko je datum stroška/prihodka
datum pod 2. točko je datum za pomožno knjigo (saldakonti)
datum pod 4. točko je datum za DDV knjige

če imaš rač.program kjer so z vnosom v pomožno knjigo hkrati tudi vnosi v pomožne knjige pride do neskladja; kajti dnevnik glavne knjige se ti ne more ujemati: ne moreš imeti samo na kto 4 ne pa tudi protikonta na 2, ce je prejem blaga v prejšnjem mesecu, datum fakture pa v naslednjem mesecu. Prosim za ideje kako to rešiti, da bo glavna knjiga usklajena s pomožnimi in bodo dokumenti ustrezno evidentirani. Ali drugače: zalogo blaga smo povečali 31.1., datum fakture pa je bil 3. februar; če želim imeti pravilno obremenjeno zalogo bi morala per 31/1 evidentirati 66/220 = ko bom pa usklajevala saldakonte oni ne bodo imeli tega računa med odprtimi postavkami, ker so ga izstavili šele v februarju; da pa bi komplicirali s knjižbami 66/224, je pa zelo težko oz. se bojim, da bi se izgubili s preknjiževanjem.

Upam, da sem razumljivo napisala, samo s programerji imamo žal težave, ker nikakor ne pridemo skupaj okoli teh datumov
hvala za vsako idejo oz. kako imate to programsko rešeno vi oz. kaj je knjigovodsko pravilno?

- 15.02.2004 - 23:13

Jaz imam možnost, da v glavni knjigi določim v kateri obračunski mesec knjižim fakturo, pa naj ima datum kakeršenkoli.
Kako pa rešujete take zadeve, ko gre leto naokoli? Saj v januarju prejemate fakture, ki se nanašajo na december, in morajo biti tudi poknjižene v decembersko leto. Enako naredite med meseci.

tina - 16.02.2004 - 06:11

Za GK kot tudi za saldakonte upoštevaš datum dokumenta, obdobje knjiženja pa je mesec nastanka poslovnega dogodka.V davčnih knjigah pa je obdobje tako ali tako določeno drugače : pri izdanih fa sicer po datumu izdane fa oz. po datumu ECL (izvoz), v knjigo prejetih fa pa imaš datum prejema listine, kar nima veliko zveze z datumom nastanka dogodka.
Če si začetnik in imaš računalniški program - vprašaj programerja, pa ti bo vse razložil (programi imajo vse to že predvideno!) Če pa nimajo, potem zamenjaj program !

andrejka - 16.02.2004 - 07:30

Glede DDVja je čisto jasno kako se knjiži, program čisto prav zajema podatke;
na koncu leta enostavno račune preko razmejitev knjižim konec leta;

problem pa nastane npr., če prejmemo sredi leta račun, ki se nanaša na prejšnje leto (recimo, da je bil račun večkrat zavrnjen in na koncu se potem račun prizna zaradi uskladitve oz. dobrih poslovnih odnosov); kdaj potem ta dokument zavedemo = na začetku tekočega poslovnega leta s katerim datumom dokumenta ali ga knjižimo v obračunsko obdobje, ko smo dokument prejeli ali?

Matjaž K - 16.02.2004 - 07:41

Najenostavnejša rešitev je ta, da knjižite vse v januar.

V temprimeru se sekirati glede tega, da bo stanje per 31.1. 2004 izkazovalo v IOP tudi listine iz feb/2004. Poglejte si malo IOP Pošte ali Telekoma. Isti hec.


Druga rešitev pa je res ta, da uporabljate že med letom Kto 224 in "telovadite" s preknjiževanjem. AMpak po vsebini gre za isti hec, kot če bi knjižili na 220. Saj bo IOP za Kto 224 tudi kazal, d aje po stanju 31.1. 2004 v obveznostih račun iz feb/2004.


Možna pa je tudi rešitev, da prevzema blaga ne sknjižite toliko časa, dokler ne dobite listine - izjema je konec poslovnega leta - kar pa tudi pomeni, da blago toliko časa ne more iti v prodajo, dokler ni prejet račun dobavitelja.


Sicer pa sem mnenja, da tega problema noben program ne more rešiti.
Gre pač za razliko med dejaskim "fizičnim" dogodkom in dogodkov, ki je "podprt" z listino.

Vedno bolj ugotavljam, da je knjigovodstvo samo poskus vzpostaviti ideal - in to deluje samo, če so listine izdajane in predajane v knjiženje ter knjižene s "svetlobno hitrostjo" (kar pa je možno samo v velikih sistemih npr. banke, mobilni opreraterji ipd).

LP