ZKI , JIR i UUID

Nov 5, 2012 at 12:34 PM

UUID citat

"Identifikator poruke ID poruke (UUID).
Svaka poruka koja se šalje prema CIS-u
mora sadržavati različiti ID poruke. Isto
vrijedi i u slučaju kad se ponavlja slanje
poruke zbog greške u razmjeni poruka."

Pitanje glasi zašto MORA - ako definitivno prolaze poruke sa istim ID i uredno se dobiva JIR. Dali je tovo činjenica samo u testnom okruženju.

ZKI citat

"Zaštitni kod izdavatelja obveznika fiskalizacije je alfanumerički zapis kojim se potvrđuje veza između
obveznika fiskalizacije i izdanog računa. Zaštitni kod formira obveznik fiskalizacije, ispisuje ga na računu
i dostavlja Poreznoj upravi kao obavezni element računa.
Osnovna namjena ovog koda je da se obveznik fiskalizacije zaštiti od mogućih pokušaja nanošenja štete
od strane treće osobe. Samo obveznik fiskalizacije može ponovo kreirati isti zaštitni kod temeljem
ulaznih parametara za konstrukciju koda. Porezna upravane provjerava zaštitni kod ali na njezin zahtjev
obveznik fiskalizacije, temeljem istih ulaznih parametara, mora kreirati zaštitni kod jednak onome s
računa.
Druga namjena zaštitnog koda je provjera računa putem Weba i SMS-a u slučajevima kad je račun izdan
bez JIR-a. U tom slučaju se zaštiti kod može koristiti kao identifikator računa u kombinaciji s drugim
podacima.
Kako bi se osigurale prije navedene namjene, zaštitni kod mora biti određen s nekoliko parametara koji
osiguravaju:
a)  jedinstvenost računa: OIB obveznika, datum i vrijeme izdavanja računa, brojčana oznaka
računa, oznaka poslovnog prostora, oznaka naplatnog uređaja, ukupni iznos računa
b)  autentičnost korisnika: privatni ključcertifikata za fiskalizaciju (kojeg je FINA dodijelila
obvezniku fiskalizacije)
Koristeći MD5 kriptografsku hash funkciju (po standardu RFC 1321 The MD5 Message-Digest Algorithm)
dobiva se rezultat: 32-znamenkasti broj zapisan u heksadecimalnom formatu koji se ispisuje na račun.
Prilikom formiranja zaštitnog koda dozvoljeno je koristiti samo brojeve i mala slova: 0-9, a-f. Primjer
zaštitnog koda:
e4d909c290d0fb1ca068ffaddf22cbd0"

Nikako mi nije jasan "ZAŠTITNI"  dio funkcije ZKI.

Naime - izdavatelj računa izgleda mora moći ponovno kreirati  ZKI da bi dokazao da je "To njegov račun  koji je poslao"  a ako nemože "onda ga je poslao neko drugi" .

Mogu shvatiti njegovu drugu funkciju u slučaju izdavanja računa bez JIRA, ali to nema nikakve veze sa nazivim"Zaštitni kod izdavatelja".

JIR

On mi je za razliku od ostatka jasan, jedino mi nije jasno zašto se jednostavno u bazu CIS-a ne spremaju i na račun štampaju ili taj "jedinstveni" UUID ili ZIK koji se također n po kojoj logici nemože ponoviti 2 puta za različiti račun.

 

Uz sve te nejasnoće, jasno mi je da ova poruka neophodno i ne zahtjeva odgovor, nego predstavlja čisto moje razmišljanje, pa ako nekoga umara nek se previše oko nje ne napreže .

:-)))

Iz uz sve to nemam nikakve namjere utjecati na promjenu specifikacija , nego doprinjeti shvačanju problematike, javnom diskusijom.

Coordinator
Nov 5, 2012 at 12:58 PM

Evo nekih moji razmišljanja:

1. UUID - istina, za UUID možeš poslati BILO što, ako je po XSD specifikaciji; svaki puta možeš slati isti UUID i mislim da ovo nije stvar testnog okruženja, vjerujem da će tako biti i u produkciji jer bi ih "pojelo" da idu provjeravati da li je UUID na svakoj poruci stvarno jedinstven. Na obvezniku je da to osigura, da nikada ne šalje dvije poruke sa istim UUID-om. Naime, kada ti CIS odgovara nešto nazad, taj se odgovor veže na UUID tvoje poruke koja je "trigerirala" odgovor; e, sad, ako imaš u svom sustavu više poruka sa istim UUID-om, nije jasno na kaj si dobio odgovor. Uglavnom, da zaključim, ako se svi drže toga da sa odgovarajućom funkcijom kreiraju UUID, mislim da u praksi ovo ne bi trebao biti neki problem, sve ako će CIS i dozvoljavati slanje više različitih poruka sa istim UUID-om. Pored samog UUID-a, postoje i druge stvari koje mogu dovesti, u slučaju nekih problema, do jednoznačne identifikacije poslane poruke.

2. ZKI - "zaštitni" dio se odnosi na činjenicu da se koristi TVOJ certifikat kod kreiranja ZKI - dakle - ako samo ti imaš svoj certifikat, nitko drugi ne može kreirati isti ZKI za iste ulazne parametre osim tebe; ako, pak, netko drugi dođe do tvog certifikata, onda imaš veći problem od ZKI-a :)  ZKI se provjerava samo na zahtjev, iznimno, a ne redovito.

3. JIR - Zato što je to jedini broj na koji Porezna ima utjecaj... oni ga kreiraju, oni znaju da je unique i oni znaju da ga i ti moraš isprintati na računu ili si naj...

Nov 10, 2012 at 10:26 PM

Nadam se da je banalno ali ne kontam

- kako dobivate UUID brojeve?

- Kako generirati ZKI?

nekoliko dana čitam ali nikako da moj mali plavi mozak uhvati ...

Coordinator
Nov 10, 2012 at 11:25 PM
Edited Nov 10, 2012 at 11:33 PM
drumisek wrote:

Nadam se da je banalno ali ne kontam

- kako dobivate UUID brojeve?

- Kako generirati ZKI?

nekoliko dana čitam ali nikako da moj mali plavi mozak uhvati ...

1.) 

Schema.ZaglavljeType zaglavlje = new Schema.ZaglavljeType() { DatumVrijeme = Razno.DohvatiFormatiranoTrenutnoDatumVrijeme(), IdPoruke = Guid.NewGuid().ToString() };

2.)

private static string ComputeHash(byte[] objectAsBytes)
		{
			//MD5 md5 =  new MD5CryptoServiceProvider();
			MD5 md5 = MD5.Create();
			try
			{
				byte[] result = md5.ComputeHash(objectAsBytes);

				// Build the final string by converting each byte
				// into hex and appending it to a StringBuilder
				StringBuilder sb = new StringBuilder();
				for (int i = 0; i < result.Length; i++)
				{
					sb.Append(result[i].ToString("x2"));
				}

				// And return it
				return sb.ToString();
			}
			catch (ArgumentNullException ane)
			{
				//If something occurred during serialization, 
				//this method is called with a null argument. 
				Console.WriteLine("Hash has not been generated.");
				return null;
			}
		}

		private static string ZKI(X509Certificate2 certifikat, string oibObveznika, string datumVrijemeIzdavanjaRacuna, string brojcanaOznakaRacuna, string oznakaPoslovnogProstora, string oznakaNaplatnogUredaja, string ukupniIznosRacuna)
		{
			string zastitniKod;

			StringBuilder sb = new StringBuilder();
			sb.Append(oibObveznika);
			sb.Append(datumVrijemeIzdavanjaRacuna);
			sb.Append(brojcanaOznakaRacuna);
			sb.Append(oznakaPoslovnogProstora);
			sb.Append(oznakaNaplatnogUredaja);
			sb.Append(ukupniIznosRacuna.Replace(',', '.'));

			byte[] by = Potpisivanje.PotpisiTekst(sb.ToString(), certifikat);
			if (by != null)
				zastitniKod = ComputeHash(by);
			else
				zastitniKod = "";


			return zastitniKod;
		}

 

UUID broj nije ništa drugo nego  Universally Unique IDentifier

http://en.wikipedia.org/wiki/Universally_unique_identifier

ZKI je zaštitni kod izdavatelja, a koji je određen nekim parametrima (stringovima) koji se nakon sastavljanja hashaju MD5 načinom.

Ako koristite FiskalizacijaDEV.dll, o ovim stvarima se ne treba brinuti, jer je to sve napravljeno.

A sve ove metode oko dobijanja ZKI i UUID su, zapravo, pojašnjene u tehničkoj dokumentaciji. Za ZKI vidjeti zadnju stranicu (dodatak).

Nov 10, 2012 at 11:54 PM

Da lie netko napisao kod u CLIPPERu za pisanje ZKI broja i voljan ga je ovdje postaviti?

Coordinator
Nov 11, 2012 at 7:05 AM

Od v.1.2. možete iskoristiti i COM odnosno EXE (ako ne radite u .NET-u) i za generiranje UUID-a i za izračun ZKI - u popratnoj dokumentaciji su primjeri pozivanja.

Nov 11, 2012 at 5:22 PM
Edited Nov 11, 2012 at 5:23 PM
margy wrote:

Da lie netko napisao kod u CLIPPERu za pisanje ZKI broja i voljan ga je ovdje postaviti?

Rješenje za tvoj upit  je na

http://fiskalizacija.codeplex.com/discussions/402638

Wrapper između ostalog izračunava i upisuje ZKI u tvoju XML datoteku , a tebi je vraća na način opisan u uputama za korištenje.

Bojim se da to u CLIPPERU nebudeš uspio izračunati .

Nov 15, 2012 at 8:41 PM

Ako netko zna odgovor na kratko pitanje:

Je li obveznik fiskalizacije obvezan spremati dobivene JIRove u vlastitu bazu podataka?

Nije problem kod spremanja online dobivenog JIRa jer ga ionako moraš ispisati na račun pa ga usput i spremiš u svoju bazu, ali što s naknadno poslanim računima koji nisu mogli ići online.

Iz dobivenog xml odgovora JIR možeš vezati s izdanim računom jedino dovodeći ga u vezu s UUID-om izdanog i u međuvremenu spremljenog i otiskanog računa. Mislim, nije ni to problem napraviti, ali onda moraš za svaki račun spremati i UUID da bi pomoću njega u xml odgovoru pronašao JIR i napravio update odgovarajućeg sloga.

Nov 15, 2012 at 9:15 PM
Georgia47 wrote:

Ako netko zna odgovor na kratko pitanje:

Je li obveznik fiskalizacije obvezan spremati dobivene JIRove u vlastitu bazu podataka?

Nije problem kod spremanja online dobivenog JIRa jer ga ionako moraš ispisati na račun pa ga usput i spremiš u svoju bazu, ali što s naknadno poslanim računima koji nisu mogli ići online.

Iz dobivenog xml odgovora JIR možeš vezati s izdanim računom jedino dovodeći ga u vezu s UUID-om izdanog i u međuvremenu spremljenog i otiskanog računa. Mislim, nije ni to problem napraviti, ali onda moraš za svaki račun spremati i UUID da bi pomoću njega u xml odgovoru pronašao JIR i napravio update odgovarajućeg sloga.

obavezan si naknadno (u roku dva dana) dostavljati nedostavljene racune. a kako ces znati koji nisu dostavljeni ako ne biljezis jir-ove za dostavljene racune? oni racuni koji nemaju jir se dostavljaju ponovo, s podignutim flagom za naknadnu dostavu. i sve tako dok ne dobijes jir. ne treba ti uid, niti ikakva relacija na nj.

Nov 15, 2012 at 9:23 PM
mladenbabic wrote:
vezan si naknadno (u roku dva dana) dostavljati nedostavljene racune. a kako ces znati koji nisu dostavljeni ako ne biljezis jir-ove za dostavljene racune? oni racuni koji nemaju jir se dostavljaju ponovo, s podignutim flagom za naknadnu dostavu. i sve tako dok ne dobijes jir. ne treba ti uid, niti ikakva relacija na nj.

Zar nije jednostavnije sve generirane racunzahtjev.xml koji nisu poslani CISu spremiti u jedan direktorij i onda naknadno kad uspostaviš vezu jednim klikom poslati sve *.xml iz tog direktorija i nakon toga izbrisati sve iz tog direktorija.

I ako ne moram spremati JIRove što me briga za JIRove koji će biti u racunodgovorima.xml za naknadno poslane račune. Ionako ih nemam kome tiskati jer je račun već otišao.

Nov 15, 2012 at 9:34 PM
Edited Nov 15, 2012 at 9:37 PM

jir ako ga dobijes zapises u bazu. naknadno saljes one racune koji nemaju jir. kakvi fileovi, folderi i ostale gluparije.

pa valjda imas metodu za slanje, kojoj posaljes broj racuna i ona obavi sve?

Nov 15, 2012 at 9:43 PM
mladenbabic wrote:

jir ako ga dobijes zapises u bazu. naknadno saljes one racune koji nemaju jir. kakvi fileovi, folderi i ostale gluparije.

pa valjda imas metodu za slanje, kojoj posaljes broj racuna i ona obavi sve?

Program je u Turbo C-u u DOSu i nemam bazu podataka kojoj mogu tako lako napraviti UPDATE ili SELECT/WHERE nego je baza niz binarnih datoteka.

Pitao sam samo je li moram spremati JIR i nisam dobio odgovor. Ostalo ću napraviti kako znam i kako mogu s obzirom na alat u kojem je program izrađen.

Nov 15, 2012 at 9:47 PM
Edited Nov 15, 2012 at 9:47 PM

aaaahaaaa. davno je to bilo :)

racun mora cuvati jir uvijek. mora postojati u slucaju poreznog nadzora. ponovno slanje mora generirati novi uuid i dici flag naknadne dostave. znaci moras ponovo u te fileove injektirati izmjene.

Nov 15, 2012 at 9:49 PM
mladenbabic wrote:

aaaahaaaa. davno je to bilo :)

racun mora cuvati jir uvijek. mora postojati u slucaju poreznog nadzora. ponovno slanje mora generirati novi uuid i dici flag naknadne dostave. znaci moras ponovo u te fileove injektirate izmjene.

Zašto jednostavno kad može komplicirano. Sve što sam tražio je to podebljano.

Nov 15, 2012 at 9:56 PM
Georgia47 wrote:

Ako netko zna odgovor na kratko pitanje:

Je li obveznik fiskalizacije obvezan spremati dobivene JIRove u vlastitu bazu podataka?

Nije problem kod spremanja online dobivenog JIRa jer ga ionako moraš ispisati na račun pa ga usput i spremiš u svoju bazu, ali što s naknadno poslanim računima koji nisu mogli ići online.

Iz dobivenog xml odgovora JIR možeš vezati s izdanim računom jedino dovodeći ga u vezu s UUID-om izdanog i u međuvremenu spremljenog i otiskanog računa. Mislim, nije ni to problem napraviti, ali onda moraš za svaki račun spremati i UUID da bi pomoću njega u xml odgovoru pronašao JIR i napravio update odgovarajućeg sloga.

daj si procitaj inicijalni post. spominjes bazu,  a poslije i fileove koje ces cuvati. stvarno si jednostavan i ne kompliciran.

Coordinator
Nov 16, 2012 at 10:51 AM

Ne zaboravite i na ZKI :), koji MORA biti na računu.. bez obzira što on nema JIR.

Nov 16, 2012 at 2:44 PM
dkustec wrote:

Ne zaboravite i na ZKI :), koji MORA biti na računu.. bez obzira što on nema JIR.

Sad još i to.

Meni je baza pokazivač na niz struktura i jedan član niza mi je jedan slog i sad još i ZKI, a program još uvijek radi s memorijskim ograničenjem od 64kB.

 I sve to zbog par prijatelja koji rade na mom programu još iz ranih devedesetih, a ne bi želio ostaviti dojam da ne mogu riješiti.

Ajde please, tko zna sigurno je li na svakom evidentiranom računu u korisnikovoj bazi trebaju biti sva trojica: JIR, UUID i ZKI ?

 

 

Coordinator
Nov 16, 2012 at 2:47 PM

@Georgia47, gle - ne moraju :)  Zakon ne propisuje kako ćeš ti organizirati svoju bazu. No, dobra praksa bi svakako bila da za svaki račun imaš UUID (koji je primary key) + ZKI + JIR.

Coordinator
Nov 16, 2012 at 2:51 PM

ahaha, pati baby :) trebao si biti pravnik... ehehe

Šala..

Ajde, jedna dobra vijest - ZKI ne moraš evidentirati niti čuvati - on se generira "on the fly", tako da njega uvijek možeš dobiti pozivanjem metode izračuna ZKI (ako naknadno šalješ račun, iz nekog razloga" - osim ako zbija nemaš dobar razlog "pamtiti" ZKI..

E sad... na računu od svega nabrojanog MORAŠ imati ZKI. JIR ne moraš (ako kihne veza na CIS, nije propast svijeta - ali MORAŠ staviti ZKI na račun i kao takvog ga ispisati). Da li ćeš za taj račun pamtiti ZKI ili ga računati naknadno - tvoja stvar... Također, tvoja je stvar da li ćeš UUID i JIR pospremati u bazu.. Ukoliko ti se desi da ti poreznik navrati kod klijenta, njih će zanimati da li račun koji oni imaju dobije isti ZKI kada ga se izračuna naknadno... I da je slijedni broj jednak onome slijednom broju s kojim će te trati (tj. tvojeg klijenta).

Nov 16, 2012 at 2:53 PM
nrasinec wrote:

@Georgia47, gle - ne moraju :)  Zakon ne propisuje kako ćeš ti organizirati svoju bazu. No, dobra praksa bi svakako bila da za svaki račun imaš UUID (koji je primary key) + ZKI + JIR.

Tko će meni dati PK ? Baza su mi binarne datoteke i "PK" mi je broj računa kao član strukture i ako ne moram ne bi ni spremao njih trojicu.

Njih trojica povećaju sizeof(strukture) za 96 + 3 byteova, i ako ne moram neću ih ni pamtiti.

Mislim, hoće li poreznici u kontroli tražiti ta tri broja ili neće ?

Nov 16, 2012 at 2:57 PM
dkustec wrote:

ahaha, pati baby :) trebao si biti pravnik... ehehe

Šala..

Ajde, jedna dobra vijest - ZKI ne moraš evidentirati niti čuvati - on se generira "on the fly", tako da njega uvijek možeš dobiti pozivanjem metode izračuna ZKI (ako naknadno šalješ račun, iz nekog razloga" - osim ako zbija nemaš dobar razlog "pamtiti" ZKI..

E sad... na računu od svega nabrojanog MORAŠ imati ZKI. JIR ne moraš (ako kihne veza na CIS, nije propast svijeta - ali MORAŠ staviti ZKI na račun i kao takvog ga ispisati). Da li ćeš za taj račun pamtiti ZKI ili ga računati naknadno - tvoja stvar... Također, tvoja je stvar da li ćeš UUID i JIR pospremati u bazu.. Ukoliko ti se desi da ti poreznik navrati kod klijenta, njih će zanimati da li račun koji oni imaju dobije isti ZKI kada ga se izračuna naknadno... I da je slijedni broj jednak onome slijednom broju s kojim će te trati (tj. tvojeg klijenta).

Hvala, sad mi je sve jasno.

Nov 17, 2012 at 9:17 PM

Znaci, ako cikne veza račune bez JIR-a ali sa ZKI-om ispisujem na POS printer ili se mora zavest u onu crnu(prethodno ovjerenu) knjigu računa???

Nov 17, 2012 at 9:39 PM
Edited Nov 17, 2012 at 9:44 PM

turpija, tu imas sve scenarije : http://fiskalizacija.codeplex.com/discussions/400859