odgovor na račun error

Oct 26, 2012 at 12:59 AM
Edited Oct 26, 2012 at 12:59 AM

Molim pojasnjenje, mozda sam previdio to negdje, da li se error sifra ispisuje na racunu u slucaju neispravnog odgovora

Coordinator
Oct 26, 2012 at 7:20 AM

Mislim da ovdje govorimo o nekoliko scenarija:

  1. greška je u tvom algoritmu, bilo uslijed krivog XML-a, bilo uslijed greške u potpisivanju
  2. ne radi blagajna
  3. ne radi ti Internet
  4. ne radi CIS

 

Kako postupati:

  1. ne bi se smjelo događati u produkciji, zato i postoji period testiranja; uglavnom, obveznik ti j... sve po spisku :)
  2. događa se da se software za blagajnu sruši, bilo jer je loša aplikacija, bilo uslijed problema sa Windowsima, hardwareom ili sl. - mislim da u tom slučaju u roku od 2 dana moraš ponovo poslati račun, kada se problem otkloni
  3. isto kao i 2., šalješ u roku od 2 dana ponovo
  4. valjda isto kao i 2.

 

Odmah naglašavam da ovo pišem a da nisam baš 100% siguran u ispravnost, bilo bi dobro da se još netko uključi u ovu raspravu, tko možda ima više informacija. U svakom slučaju, po mom mišljenju je ovo dosta važna stvar i trebala bi biti vrlo striktno definirana u Zakonu, Pravilniku, Tehničkoj dokumentaciji, ...

Spremam se već neko vrijeme otvoriti issue i/ili discussion na temu "Kako riješiti naknadno slanje XML-a", pa je ovo možda dobar početak, da se prvo "teoretski" raspravi ovo prije nego vidimo kako to implementirati kroz kod.

Coordinator
Oct 29, 2012 at 10:42 AM

U kodu bi svakako bilo dobro implementirati vraćanje greške u obliku teksta, koja bi se pospremala u definirani direktorij, kao što se pospremaju zahtjevi i odgovori. Poruka o pogrešci, koja bi bila pospremljena, trebala bi sadržavati ID poruke, kako bi se developeri mogli vezati sa svojom bazom podataka nepotpisanih računa sa onim računima koji se trebaju poslati, neki ENUM pogreške (radi lakše odluke što s tim računom) te datumvrijeme prvog slanja. 

U praksi se neće događati da jedan račun prođe, drugi ne, nakon njega pet njih prođe, šesti padne... U ovakvim sustavima, kakav je CIS, kada negdje zapne s jednim, zaglaviti će i sa svakim sljedećim, do određenog trenutka kada računi opet budu normalno prolazili, naravno - uzimajući u obzir da se ovdje radi isključivo o pogrešci sa strane CIS-a.

Uglavnom će biti problema sa strane klijenta - pao Internet, crknuo switch, rasturio se stroj na kojem je aplikacija za blagajnu. Ukoliko se ne dogodi zadnja opcija, mora postojati opcija naknadnog slanja, što je i predviđeno protokolom, naravno.

Najkritičniji dio u cijeloj ovoj priči je ne izgubiti slijednost računa. Međutim, kada se aplikacija sruši, ili stroj na kojem se nalazi jednostavno umre - teško da će se odmah moći doći do podatka koji je bio zadnji broj računa (a) ako je slijednost N crknutog posa ili (b) ako je slijednost P zadnjeg izdanog računa u poslovnici... Po Tehničkoj dokumentaciji, ukoliko se dogodi ovakav scenario - prelazi se na paragon blok, a, naravno - svaka dobra domaćica blagajne u svakom trenutku "zna" koji joj je zadnji broj izdanog računa bio pa da za n+1 može upisati broj na paragon.. Mislim da će s ovim biti najviše problema svima... te da će ovo biti jedan od načina za različite pokušaje manipulacije sustava.. no, tu kontemplaciju ću vrlo rado ostaviti za razmišljanje onima koji su sve ovo zakuhali...

Dvojim se... zbilja se dvojim između opcija da se naknadno slanje računa ostavi na kontrolu i praćenje developeru aplikacije ili da mi kroz naš dll pratimo i vodimo računa o istome.. Jedino bi bilo dobro da se na jedan upit dobije JIR i slijedni broj računa zadnjeg uspješno potpisanog računa, ali ako rikne stroj ili zamre parent proces koji poziva ovaj dll, teško da će se i ta stvar bez finog znanja o informatici i računalstvu moći na jednostavan način saznati....

Oct 30, 2012 at 7:59 PM
Edited Oct 30, 2012 at 8:01 PM

Moji su scenariji slijedeći :

A) Blagajna radi, Internet konekcija radi :

- blagajna kreira račun, u bazu upiše JIR i Zaštitni kood

B) Blagajna radi, dostava računa ne radi (npr. ne radi Internet konekcija ili CIS)  :

  1. blagajna bez obzira na sve, bez ikakvog čekanja - izdaje račun, generira Zaštitni kood i ispisuje ga na računu. JIR ostaje prazan i na računu i u bazi
  2. aplikacija omogućuje naknadno automatsko slanje računa koji u bazi nemaju upisani JIR. 
    Pri ponovnom slanju se : 
    - ne generira novi zaštitni kood, već se šalje onaj stari, iz baze
    - flag za naknadnu dostavu se podiže
    - napomena :  jedan te isti se račun može bez bez problema slati u CIS i više puta *

C) Blagajna privremeno ne radi (npr. nema struje) :

  • Izdaju se računi iz paragon bloka kojega je ovjerila porezna uprava. Njihova se numeracija sastoji isto tako od oznake poslovnice, oznake bloka i naravno broja računa.
  • Kada se blagajna osposobi, aplikacija mora omogućiti naknadni unos računa kao kopije paragon računa - pri čemu se uz svaki unos mora upisati i oznaka paragon računa kao poveznicu

D) Blagajna trajno ne radi :

  • kao i "C"
  • osigurati mogućnost izrade sigurne kopije računa (kao i do sada). mogućnost da održavatelj sustava obnovi novu instancu istog naplatnog uređaja na novom računalu pomoću sigurne kopije
  • u ovom se slučaju može osposobiti novi naplatni uređaj, kao zamjena za neispravnu blagajnu, čiji brojevi računa kreću od 1 ali im je naravno oznaka naplatnog uređaja drugačija

 

* računi se mogu i više puta slati u poreznu upravu - mogući je scenario da se račun pošalje, ali do pucanja konekcije dolazi u trenutku prije prihvata JIRa na client sideu. To znači da račun postoji u bazi CISa, ali je na clientu označen kao ne dostavlje, dakle bez JIRa. Zato CIS omogućuje višestruko prihvaćanje istih računa, a onda će CIS interno ostavljati najnoviju kopiju.

Nov 1, 2012 at 6:25 PM
Edited Nov 1, 2012 at 6:30 PM

@mladenbabic Nije mi podpuno jasno ovo "- napomena :  jedan te isti se račun može bez bez problema slati u CIS i više puta *"

- dali je to činjenica ili jedan od od scenarija koji smatraš poželjnim.

Ako je to činjenica dali to podrazmjeva da se podaci za Isti račun u CIS_u mjenjaju novo-poslanim , ili ...?

 

Nevezano uz to .

- Iskreno , nije mi baš jasno zašto se ( i dali se definitivno uopče) trebaju u CIS slati računi za bezgotovinske oblike plačanja , uključujuči Virmanske.

- Očito da kad imaju predviđenu svoju oznaku pod "<tns:NacinPlac>" iste treba slati - mada to nema nikakav alibi u deklarativnom nazivu prijedloga zakona

   "Fiskalizacija u prometu gotovinom", i u tom slučaju ne postoji obveznik koji račune netreba slati, makar ni jedan izdao gotovinski.

Postavljaju se i druga pitanja :

Recimo kad i kako u CIS račun šalje web shop.

Ili što če napraviti firma ako bude trebala fakturirati kakvu zaboravljenu fakturu u prvom mjesecu - na staru godinu.

  Da ne kažem da se u tom slučaju isto pravilo treba primjeniti i na HT i ostale firme koje račune desetog - štancaju na zadnji dan prošlog mjeseca.

- Ukoliko pak Virmanske račune netreba slati - onda za iste treba očito postojati poseban brojčani niz u kontekstu očuvanja brojčanog niza gotovinskih računa.

 

@mladenbabic odlično analizira moguće situacije pri radu sa kasama , ali sigurno postoji još par logičkih praktičnih problema.

Recimo : - KASA 1 kreira račun sa dodjeljenim brojem i šalje ga u CIS, ali on iz bilo kojeg razloga ne prolazi pozitivno

                 U međuvremenu - prije negoje kasa jedan uspjela uspješno poslati svoj račun , KASA 2(koja radi sa istim računskim nizom) dva kreira račun sa sljedečim brojem i šalje ga u CIS  sa svim uvjetima da prođe pozitivno.

PITANJE JE - Dali če CIS prihvatiti  (u ne DEMO uvijetima) i poslati pozitivan odgovor za račun KASE 2,te nakon toga isto to napraviti (i pod kojim eventualnim uvjetima) za račun KASE 1  mada je isti za 1 broj manji (vjerojatno hoče).

Ukoliko je odgovor POZITIVAN- dali se onda račun KASE 1 šalje sa oznakom naknadne dostave računa - (bez obzira dali je fizički već uručen kupcu ili ne).

I koji je to vremenski rok u kojem račun koji nije prošao treba nakasnije dostaviti.

Ukoliko je odgovor NEGATIVAN - onda mora postojati programski semafor za sve kase - da do daljnjega nemogu izdavati račune (mada je CIS dostupan), dok se uspješno ne pošalje neuspješno poslan račun KASE 1.

 

U pravilu je i inzistiranje CIS_a na "neprekinutoj sljednosti" računa logički nepotrebno, jer bi krajni cilj trebao biti "svaki izdani gotovinski račun mora nositi na sebi JIR"  . E sad dali su to 3 računa sa brojevima 1, 2  i 3   ili  000POS1-1 , 000POS1-4 i 000POS1-127 to bi trebalo biti svejedno.               

Neisparavan bi za inspekcijske trebao biti  nađen kao izdan četvrti račun (sa bilo kojim brojem) koji nije uredno evidentiran u CIS_u.

 

 

Nov 1, 2012 at 7:29 PM
Edited Nov 1, 2012 at 7:44 PM

@vvrbane, 

ponovno slanje - uvijek se ponovno šalju svi računi za koje ne postoji JIR. (client uopće ne mora biti svjestan da je taj račun već u CISu, i CIS ga u tom slučaju neće odbiti jer su svi podaci isti). Nadam se da je svima jasno da to nema nikakve veze sa storniranjem računa. Storno računi su NOVI računi s negativnim stavkama, koji se posebno i fiskaliziraju.

slanje bezgotovinskih računa - mislim da se moraju slati samo gotovinski računi, ali se mogu slati i svi. Kažem "mislim" - dakle nisam siguran, zaključak kreiram  temeljem logike koju bi imao porezni nadzor. Računi sa svim ostalim načinima plaćanja su "uhvatljivi" jer postoji trag knjiženja na  izvodu. (iako i tu postoji "mogućnosti manipulacije")

Web shop - fiskaliziraju se svi gotovinski računi odmah po izdavanju. Dakle i oni koji se plate poštaru u gotovini prilikom preuzimanja od strane naručitelja.
(dostava s otkupninom).

Ne postoji "stara faktura" s datumom fakture iz 1. mjeseca a koja se kreira u 12.mj. Postoji "Storno račun" s datumom 12.mj., a postoji i "Knjižna obavijest" o ispravku pretporeza itd. itd. Dakle postoje dokumenti koji nose datum iz 12.mj. i "popravljaju" sve onako kako bi trebalo biti unutar poslovne godine. Storno se račun isto tako fiskalizira - zar ne?  Ne postoji fizička izmjena već izdanog dokumenta iz 01.mj. jer je za 01. mj. , npr. PDV obrazac već predan, i porez plaćen. Dakle tu nema diranja, nego se jednostavno fiskalizira storno račun, i eventualno novi račun koji nose datum 12.mj.

Svi računi, unutar iste oznake naplatnog uređaja  mogu imati svoj knjigovodstveno-godišnji slijed. Znači, ako imaš tri naplatna uređaja, svaki može imati svoj brojčanik od 1. Svi računi znači upravo to - SVI RAČUNI - bez obrzira na način plačćanja svakoga od njih. U veletrgovini (koja će se kasnije fiskalizirati), način plaćanja je tek PLANIRANI način plaćanja. Jer račun koji je izdan s oznakom plačanja "Virman" (odnosno HUB :)) ), može kasnije biti plaćen u gotovini. Dođe gazda i kaže, e znaš onaj dug, daj da ti to platim u cacheu. I ti mu izdaš, storno izvornog računa, kojega ponovno fiskaliziraš, i onda mu izdaš novi račun za gotovinu, kojega opet fiskaliziraš. Sve pet.

"Dvije kase .... izdaju račun ... " : U primjeru ove dvije "KASE" si zaboravio da svaka ima svoju "Oznaku naplatnog uređaja" pa prema tome svaka može imati račun broj 1 koji u kombinaciji s "Oznakom naplatnog uređaja" jednoznačno određuje račun sa svake od blagajni.
Da, "kasa1" diže flag naknadne dostave računa, jer je razlika vremena  dostave  računa u CIS i vremena na računu - izvan neke vremenske tolerancije. Dakle i bez dizanja tog flaga, CIS bi razlikom vremena s računa i vremena dostave mogao odprilike to odrediti. Ali to sve nije toliko bitno. Bitno je da kada dođe porezni nadzor s podacima iz CISa, da mu se takav promet analitički predoči iz naplatnog uređaja. To je to.

Rok za naknadnu dostavu računa u CIS je dva dana.

Ne treba nikakav semafor. Blagajne samo piče. Kada ulove vremena, na zahtjev operatera (ili u drugom threadu ), šalju zaostale račune u CIS.
Aplikacija zaostale račune detektira temeljem činjenice da uz njih u bazi podataka nema JIRa. To je sve. 

Slijednost računa uopće ne definira CIS niti pravila fiskalizacije. To je definirano u drugim pravilnicima i Zakonima. Oduvijek. To što su bircevi svaki dan kreirali račune od 1, s mogućnošću jednostavnog brisanja proizvoljnog broja računa od jučer, je i do sada bilo protivno pravilima ali se iz "nekih razloga" toleriralo.
Dakle, računi moraju ići od 1 do x unutar knjigovostvene godine. Kraj. Ti računi mogu biti na nivou poslovnice i naplatnog uređaja unutar poslovnice. CIS omogućuje da mu se kaže kako idu brojači : za cijelu poslovnicu centralizirano ili za svaki naplatni uređaj posebno. 

Bbroj računa je REDNI broj. Tu je sve je jasno i imam neke informacije da će se na to obratiti posebna pozornost.
Znači u aplikaciji moraš imati SVE račune u slijednom nizu, a fiskalizirati možeš samo gotovinske (ovo zadnje je još pod valjda)

Ne znam jesam li ti na sve odgovorio. 

Nov 1, 2012 at 8:15 PM
Edited Nov 1, 2012 at 8:24 PM

@mladenbabic . Hvala ti na opsežnom odgovoru, u njemu ima puno korisnih informacija.

Vezano za Broj Računa

Međutim nisam u zakonu o PDV_u niti pravilniku pročitao da Redni broj knjige IRA  mora biti i broj računa bez obzira na slijednost.

Predpostavljam da si do sad več vidio račune sa brojem XY-1234-PZ itd (pogledaj račun za struju ili telefon).

Nisam nigdje uočio da zakonodavac (dosad) nalaže da se računi izdaju od broja 1.. na dalje pa iz toga mislim se može (ili se barem dosad moglo) slobodno formirati brojeve računa u formi jednog ili više brojeva ili kombinaciji slova i brojeva - koliko to čak meni i ne izgleda praktično.

Vezano uz Virmanske račune i sljednost .

Ja naime vodim sve vrste plačanje u istom nizu, te me stoga interesira dali ako ne pošaljem VP račun broj 52 , on narušava slijed između poslanih Gotovinskih 51 i 53.

Vezano za račune na prošli mjesec (ili čak 12 mj prošle godine) - govorio sam u slučaju potrebe za slanjem "Virmanskih" računa.

Sigurno si uočio praksu da pojedine firme (naročito komunalne), desetog u mjesecu nalupaju par hiljada računa na zadnji dan prošlog mjeseca.

Isto tako si sigurno vidio slučaj da je neko (prije obračuna PDV_a za 12 mjesec) u prvom izdao račun za zaboravljenu robu ili usluge na 31.12 stare godine.

 

ODOBRENJA su poseban problem , jer ako CIS bude u budučnosti uspoređivao podatke sa predanim obrascima, to nikako nebude štimalo.

U uvjetima ako je to samo baza za komparaciju štampanih JIR brojeva to je ok.

 

Vezano uz primjer sa 2 kase.

On se odnosio na kase koje rade na zajedničkoj bazi sa "istim računskim nizom" (znači ne broje svaka svoje račune).

U tim uvijetima je pitanje bilo :

Na kasi 1 izdaješ račun broj 128 koji prođe u CIS 2 min nakon što je kasa 2 poslala račun broj 129.    

Dali je oznaka nakndne dostave računa true ili false , ako smo zaključili da CIS prihvača brojeve preko reda.

 

Vezanu uz račune izdane bez JIR_a (po pravilniku a radi zastoja)

U kontekstu "nagradne igre" predpostavljam da če svaki račun ez JIR_a biti posjet inspektora .   Neznam dali je  :-)))  ili :-(((.

 

Nadam se da neče više biti značajnih preinaka u specifikaciji od strane CIS a pogotovo ne nakon početka primjene.

Samo kod nas ima da prvo idemo u implementaciju na osnovu predpostavki, onda donosimo zakon.

Sigurno je na to mislio Milanović, kad je rekao da čemo od sad biti uređena država.

 

U svakom slučaju hvala na konstruktivnoj raspravi ,koja pomaže da probleme sagledamo i iz perspektiva

kojih se ranije možda nebi sjetili.

Coordinator
Nov 1, 2012 at 8:51 PM

Trebalo bi napraviti jedan wiki site i ove mladenove, vvrbanove i nrasiceve odgovore tamo copy pastati :) MIslim da bi taj potez riješio pola muke naših kolega :)

@mladenbabic, svaki tvoj post je suho zlato :)

Nov 2, 2012 at 9:04 AM
Edited Nov 2, 2012 at 9:11 AM

da, svaki post od @mladenbabic zlata vrijedi, no glede gore opisanog scenarija, zašto pamtiti zaštitni kod računa koji nije prošao u CIS, pa što ako se dogodi da se neznam radi čega promjeni kombinacija zaštitnog koda sa pripadajućim računom, pa takav račun neće nikada biti prihvaćen od CIS-a, zašto jednostavno ako račun nema JIR, izračuna se zaštitni kod u tom trenutku i onda se šalje u CIS, te ako je odgovor u redu (račun dobiva JIR) tek onda se pamti zaštitni kod. Ne vidim problema ako se i 100 puta računa zaštitni kod za račun tako dugo dok račun ne sjedne u poreznu.

Nov 2, 2012 at 2:21 PM

@jdvorski, "zašto pamtiti zaštitni kood odmah?" :

"ZaštitniKod" kodira, između ostalih podataka, i "datumTvrijeme" IZDAVANJA računa (ne vrijeme DOSTAVE računa).
To znači da je "ZKod" ISTI i za prvi pokušaj slanja kao i za sva eventualna naknadna slanja tog istog računa!

Dakle, izračunaš ga prvi puta i čuvaš. Bez obzira na uspješnost dostave CISu.
Za svaku slijedeću ga dostavu više ne trebaš računati, jer je tako "jeftinije".

Nov 2, 2012 at 7:22 PM
Edited Nov 2, 2012 at 7:24 PM

ma, sve jasno, , sjetit ćeš se mene kad prvi put kod korisnika stane slanje računa zbog netočnog zaštitnog koda, a da će doći do neslaganja zaštitnog koda sa sadržajem računa, doći će, a da me pitaš zašto? e to neznam, pitaj Murphya :-)) zato bolje računati ponovno nego uzimati ga zdravo za gotovo.

Coordinator
Nov 7, 2012 at 9:30 AM

@mladenbabic, ako si zainteresiran da nešto od ovoga stavimo u zaseban post ili wiki, pls, javi - stavili bi link ovdje, pod Resources: http://fiskalizacija.codeplex.com/documentation

Nov 8, 2012 at 4:03 PM

sorry, tek sada zapazih da sam prozvan.

da, naravno, što god mislite da je od javnog interesa. samo dajte.

Coordinator
Nov 8, 2012 at 4:40 PM

@mladenbabic, ok, thnx :)

Nov 9, 2012 at 7:10 AM

Slažem se, razmišljam o scenarijima otprilike isto kao i Mladen. Što se zaštitnog koda tiče, njegova svrha i je da "glumi" jir, odnosno jednoznačno identificira nefiskalizirani račun. zato ga i treba pamtiti u bazi, jer kad kupac odnese ZK na listiću računa sa sobom i dans-sutra ga provjeri u CIS-u. (ili inskepktor PU), kod se MORA podudarati, kao što se mora podudarati.   Mene više brine "klopka u koju sam upao". Naime, kako potpisivanje radim putem API-ja (xmlsec, opensssl) moj delphi program više nije imun na "sakaćenje" povezanih resursa, odnosno ako naiđe neki (anti)virus i pojede neki dll, netko nešto zbrlja, iszpremjesti, obriše, promjeni putanju ili dođe do ikojeg problema sa certifikatom gubim preduvjet za regularan oblik ZK, tj. ne mogu digitalno potpisati string sa podacima računa. OK je što ga iz tih razloga ne mogu poslati u CIS dok se ne otkloni kvar, no ne bi mogao ni ispisati račun jer ne bi imao ZK.  S obzirom da md5 (kojim se uvjetno rečeno ZK po tipu i duljini normalizira u neki format) uvijek vraća neki hash odlučio sam ako ima problema sa potpisivanjem ZK izračunati kao MD5 stringa s podacima, za razliku od regularne varijante kad se radi MD5  SHA1 potpisa stringa. I takvog ga pamtim. Problem bi se pojavio dok se opet uvede regularno stanje gdje bi kod ponovnog slanja ZK bio drugčiji zbog razlike u tom potpisu. Zato ću uz ZK pamtiti i jedan flag koji mi govori treba li idući put izračunati ZK s potpisom ili bez, kako bi ZK uvijek bio identičan onome ispisanom na bloku.

Slažete li se?

 

Što se tiče redudancije, ja trenutno u 2 direktorija pamtim odvojeno sve potpisane zahtjeve i sve potpisane odgovore. Eventualno još na neku dodatnu memoriju tipa usb sticka mogu u nečemu jednostavnom pamtiti zadnje vrijednosti koje su prošle u CIS, tj. vratile se iz njega.  Ako nešto i ode, a zbog nekog razloga se ne vrati, smatram da nije ni otišlo i ponovim slanje, a slanje se uvijek za iste račune može ponoviti i vrijedi zadnji poslan.

Slušao sam (i čitao) kolege koji razmišljaju o backupu podataka na Internet no to mi se ne sviđa, od sigurnosti nečijih podataka (mislim da postoji zakon koji nešto govori o tome), do pitanja pouzdanosti takve usluge koja bi se bazirala vjerojatno na nekom ftp-u. ili isto soap servisu (no vjerojatno bez https-a.) nekog VPS servera ili možda kolociranog servera.

Coordinator
Nov 9, 2012 at 8:45 AM

Po onom algoritmu, dobijem svake sekunde različit ZKI, iako su iznosi računa i datumvrijeme izdavanja računa isti.

E sad, ako označim naknadno slanje računa i pošaljem nezapamćeni, dakle - novogenerirani ZKI na naknadno poslanom računu (koji bi po ovoj logici morao imati jednak ZKI kao njegov original) kolika je vjerojatnost da CIS račun kao takav to ne prihvati?

Da li je netko ovo provjerio sa PU?

Coordinator
Nov 9, 2012 at 9:05 AM
Edited Nov 9, 2012 at 9:09 AM

Mea culpa :)

Sad sam tek skontao da je u sample programu korišteno trenutno datumvrijeme, umjesto datumvrijeme izdavanja računa.. Kada tu liniju koda postavim ovako:

 

Raverus.FiskalizacijaDEV.Schema.RacunType racun = new Schema.RacunType() { Oib = textBox18.Text, USustPdv = checkBox1.Checked, DatVrijeme = Raverus.FiskalizacijaDEV.PopratneFunkcije.Razno.FormatirajDatumVrijeme(dateTimePicker2.Value.Date), OznSlijed = Schema.OznakaSlijednostiType.P };

Ispada sve OK. MD5hash MORA uvijek biti isti i biti će i isti na istom uređaju, bez obzira koliko se puta izda račun sa istim podacima (podacima preko kojih se hasha ZKI).

..nisam još do kraja popio kavu.. pa sam malo paranoidan...

Nov 9, 2012 at 9:46 AM

Vrijeme i datum izdavanja računa su isti, promjenjivo je samo vrijeme i datum slanja, a oni ne ulaze u izračun zk.

Račun je izdan samo jednom, u svoje vrijeme i to vrijeme se više ne mijenja. Štoviše, promjena vremena izdavanja ili ukupnog iznosa mijenja ZK i asocira na moguću malverzaciju, a na što će pretpostavljam CIS i poreznički nadzor biti osjetljivi.

Coordinator
Nov 9, 2012 at 10:10 AM

veky, ma sve 5 :) jasno mi je da ZK mora biti konstantno i uvijek isti, samo me bunilo to sto mi se mijenjao radi gorenavedenog razloga :) sad sam popio kavu pa sam malo.. "bistriji" :)