Zastitni kod

Nov 21, 2012 at 10:53 AM

Evo jedno pitanje u vezi zastitnog koda.

Kao sto znamo zastitni kod se generira za svaki zahtjev za racun bez obzira da li je zahtjev uspjesan ili ne (JIR se dohvatio ili ne).

Ukoiko se JIR ne dohvati (npr nema mreže) on se ne ispisuje na računu ali se i dalje ispisuje ZASTITNI KOD.

E sad. Jedan od parametara za računanja zastitnog koda je vrijeme slanja koji se cuva u bazi.

Nakon naknadnog potpisivanja tog računa (koji se prije nije potpisao) vrijeme slanja ce biti neko drugo a predhodni zastitni kod kao vise ne vrijedi. ILI???

Sve sto mi pada na pamet je da se mozda vrijeme racuna (a ne vrijem slanja) koristi u izracunu za zastitni kod.

Pomoć...

 

Coordinator
Nov 21, 2012 at 10:55 AM

Za izračun ZKI se koristi datum i vrijeme IZDAVANJA računa.

Nov 21, 2012 at 10:59 AM

Malo si "preskočio", ne pamti se nikakav datum slanja nego datum izdavanja, znači trenutak kad je čovjeku odštampan i uručen račun.

Ono što je otisnuto na računu je ZAKON i to se uvijek mora poklapati. Bilo u CIS-u. bilo u tvojoj bazi (naknadnim generiranjem i usporedbom ZKI s CIS-om ili otisnutim računom).  Jedinu slabu kariku u tom lancu vidim u potencijalnoj nemogućnosti generiranja digitalnog potpisa (netko obriše dll, datoteku, nešto treće), no i tada je moguće pseudo-generiranje zki bez komponente digitalnog potpisa. pravno gledano - to nije promjena elemenata računa nego sigurnosne komponente i kasnije generiranje ZKI, ali bez digitalnog potpisa opet daje isti ZKI. O tome sam pisao na nekom drugom topicu pa malo pogledaj.

Nov 21, 2012 at 11:42 AM
gpleic wrote:

Evo jedno pitanje u vezi zastitnog koda.

Kao sto znamo zastitni kod se generira za svaki zahtjev za racun bez obzira da li je zahtjev uspjesan ili ne (JIR se dohvatio ili ne).

Ukoiko se JIR ne dohvati (npr nema mreže) on se ne ispisuje na računu ali se i dalje ispisuje ZASTITNI KOD.

E sad. Jedan od parametara za računanja zastitnog koda je vrijeme slanja koji se cuva u bazi.

Nakon naknadnog potpisivanja tog računa (koji se prije nije potpisao) vrijeme slanja ce biti neko drugo a predhodni zastitni kod kao vise ne vrijedi. ILI???

Sve sto mi pada na pamet je da se mozda vrijeme racuna (a ne vrijem slanja) koristi u izracunu za zastitni kod.

Pomoć...

 

A ne kuzim, kaj te specava da taj zastitni kod upises negdje u svoju tablicu: pa bio JIR dohvacen ili ne .

Kad se mreza, kvar ili kaj sve ne vec osposobi, saljes sam to racun u CIS sa vec postojecim Zastitnim kodom.

Bar sam ja to tako zamislio.

Nov 21, 2012 at 11:56 AM

Stoji priča, ali ukoliko se zastitni kod za generiranje uzima vrijeme slanja, onda je za svako slanje potrebno generirati novi zastitni kod.

Izgleda da se uzima vrijeme racuna pa je sve OK

Nov 21, 2012 at 12:02 PM
gpleic wrote:

Stoji priča, ali ukoliko se zastitni kod za generiranje uzima vrijeme slanja, onda je za svako slanje potrebno generirati novi zastitni kod.

Izgleda da se uzima vrijeme racuna pa je sve OK

Pa da, uzima se vrijeme generiranj, ispisa ili kaj sve ne racuna.

E sada, ti mozes negdje spremiti datum ,vrijeme, oib operatera, iznos racuna i kaj sve treba za izracun zastitnog koda ili mozes ( kaj je po meni jednostavnije ) spremiti vec taj izracunati ZK.

Sa vvim onim parametrima ti bi trebao uvijek dobiti isti ZK.

Nov 21, 2012 at 1:47 PM

Možda ja nisam pažljiv, no daj mi molim te reci gdje si vidio da se uzima (i na kraju, racionalno iz kojeg razloga) datum i vrijeme slanja? Bitan i važan podatak je vrijeme i datum izadavanje računa i oni su od trenutka izdavanja računa konstanta, bez obzira slao ti račun tada, par ms kasnije, par sati ili nakon 2 dana. Upravo zbog toga ZKI  je uvijek za isti račun jednak. Vrijeme slanja nije bitno baš za ništa, kao ni onaj Id u zaglavlju, tek da ih usporediš i vidiš proteklo vrijeme i vidiš kako je prema Id taj   odgovor upravo odgovor na taj zahtjev.

Nov 21, 2012 at 2:07 PM
Veky wrote:

Možda ja nisam pažljiv, no daj mi molim te reci gdje si vidio da se uzima (i na kraju, racionalno iz kojeg razloga) datum i vrijeme slanja? Bitan i važan podatak je vrijeme i datum izadavanje računa i oni su od trenutka izdavanja računa konstanta, bez obzira slao ti račun tada, par ms kasnije, par sati ili nakon 2 dana. Upravo zbog toga ZKI  je uvijek za isti račun jednak. Vrijeme slanja nije bitno baš za ništa, kao ni onaj Id u zaglavlju, tek da ih usporediš i vidiš proteklo vrijeme i vidiš kako je prema Id taj   odgovor upravo odgovor na taj zahtjev.

To ide mene ?

Coordinator
Nov 21, 2012 at 2:16 PM

za ZKI se uzima datum i sat IZDAVANJA računa, koje se, uz ostale podatke s računa šalje na CIS.

Cijela institucija ZKI-a bi bila besmislena da se za izračun uzima datum i vrijeme SLANJA računa ) jer bi u tom slučaju, isti račun, svake sekundi dobijao drugi ZKI i kornisk bi ti imao njesra žešće s poreznicima radi toga. Upravo ZKI nam služi za potvrdu da je račun primjera poslanog u CIS jednak onome primjerku računu u bazi, kojeg možeš generirati bilo kada, a da dobiješ jednak ZKI kojeg si izračunao prvi puta kada si fiskalizirao račun.

A sada jedna dilema koju mučim već danima...

- certifikat traje 5 godina. 

- 7 godina je rok čuvanja računa.

da li se može dogoditi da ti poreznci traže račun iz vremena kada si imao stari certifikat? - u tom slučaju, ako ne pamtiš ZKI, ne bi mogao izračunati jednak ZKI kojeg imaš na primjerku računa kojim ti poreznici mašu pred nosom... 

razmislite malo o ovome.. ovo može biti jeb.. problem...

Nov 21, 2012 at 2:21 PM

Pa to sam i rekao, da sprema negdje u tablicu ZK, pa ako ode u CIS dobro inace ce ga poslati naknadno... Sa tim istim ZK.

Coordinator
Nov 21, 2012 at 2:22 PM

@goranv13, ti i jesi bio u pravu...

Nov 21, 2012 at 5:00 PM

Svi su u pravu, samo je nejasno što su pisci htjeli reći da ako ti dođu sa fiskaliziranim računom, pa traže od tebe da ponoviš ZKI? Ako padnu na to da im ga ponovno pročitaš iz baze, onda baš i ne vidim neku sigurnost da ga u međuvremenu nisi mijenjao (u bilo kojem elementu kojim se gradi ZKI, ali vjerujem da im je najinteresantniji iznos). Oni ga ne mogu sami provjeriti, jer nemaju tvoj privatni ključ.

Uostalom, ako se čita što su oni napisali, nigdje ne piše da im na zahtjev moraš POKAZATI isti taj ZKI za određeni račun, već da ga za ne TAJ, nego TAKAV račun možeš ponovno generirati. Prema tome, jedino što je meni logično je, da u programskom rješenju moraš imati prozor gdje ćeš, na zahtjev inspektora PU, 'uglavu' upisati oznaku računa, datum i vrijeme izdavanja, iznos i sve ostalo iz čega se ZKI gradi, i onda taj prozor prikaže isti ZKI kao na računu koji je inspekcija došla kontrolirati.

Ako nije tako, onda se CENSORED na takvu provjeru...

Coordinator
Nov 21, 2012 at 5:06 PM

@PBDudek, hej, nemoj tako - mislit će ljudi da mi radimo cenzuru - ako želiš psovati jer si ljut na situaciju - ovo je pravo mjesto za to :)

Coordinator
Nov 21, 2012 at 5:06 PM

@dudek, a što ako ti poreznici dođu tri dana nakon što ti je istekao certifikat, a ti si u međuvremenu kupio novi? (Mislim na produkcijski FISKAL cert).

S novim certifikatom više ne bi mogao generirati isti ZKI kojeg oni imaju i kojeg si ti onomad generirao... 

To bi značilo da u tom slučaju, treba pamtiti s kojim certifikatom si generirao ZKI, a s obzirom na NotAfter property certifikata, ne vjerujem da sa starim certifikatom uopće možeš hendlati - jer pravno gledajući, tvoj potpis više ne vrijedi ukoliko si ga generirao certifikatom koji je istekao..

... i eto nam paradoksa....

Nov 21, 2012 at 5:18 PM

@nrasinec - sorry, neću više

@dkustec - O tome neka brinu oni. Ali ja tu kontrolu zamišljam (i ja bih je proveo tako ako je već provodim) da inspektor dolazi sa svim podacima potrebnim za generiranje ZKI računa (koje IMA iz zahtjeva za JIRom), pa mi kaže: 'Ajde sad upiši sve kako je na računu!'. Ja upišem i paf! - eto ti isti ZKI. Onda on kaže: 'Ajde sad promijeni vrijeme slanja!'. Ja promijenim i paf! - eto ti drugi ZKI! Onda on kaže: 'Vrati vrijeme, ali promijeni iznos!'. Ja opet sve po njegovom i paf! - izađe ISTI ZKI!!!

I onda on mene fino u ... pa platim kaznicu jer sam napisao program u kome korisnik može napraviti račun sa jednom stavkom, generirati ZKI na sto kuna, tražiti i dobiti JIR od CIS-a, pa dodati preostalih x stavki računa, izdati ga kupcu i nadati se da mi neće provjeravati račun...

opet @nrasinec: je li ... u redu ili ne smijem ni to?

Nov 21, 2012 at 5:20 PM

Po meni imaju četri propusta :

1. mogućnost zamjene stavaka robe/usluge na računu - pa ako je isti iznos računa, ZKI se ne mijenja.
Ovo je plodno tlo za "trošenje" crne robe kroz bijele kanale. Netko proda "cigarete, cigarete" s placa za 20kn kroz dućan, a poslije ih zamijeni s kikirikijem od 20kn.  Na cigaretama zaradi 10kn a na kikirikiju prikaže zaradu od 1 kn, i na tu dodanu vrijednost plati PDV. Još k svemu, sada ima kikiriki "za cache", i prodaje ga ispod nabavne cijene.

2. mogućnost da netko izmišlja ZKI, a kada mu netko dođe s takvim računom, on kaže da to nije njegov račun.
nitko ne može dokazati da je račun njegov.  što god na njemu pisalo. (osim valjda vještaka za printer)

3. mogućnost da se jednom dodijeljeni JIR pamti i ispisuje taj stari JIR na novom računu, umjesto novog JIRa.
Provjera SMSom ili WEBom pada u vodu - ovisi naravno kakva je provjera i što će ista vraćati - koje elemente računa.
Ako vrati samo "Taj račun je uredno fiskaliziran" ...

4. OIB tvrtke koja je radila program se uopće ne kontrolira. Bilo tko može upisati bilo čiji OIB. Čemu onda to služi.

Naravno, iako u Zakonu piše da se krasti ne smije, lopov ipak MOŽE krasti.

Mislio sam da će fiskalizacija onemogućiti ovakve "mogućnosti" .... vidjeti ćemo do kraja kako će se to odvijati.

Coordinator
Nov 21, 2012 at 5:24 PM

@PBDudek, mislim da se previše brineš oko toga - prvo - OBVEZNIK je taj koji je odgovoran pred zakonom, a NE onaj koji mu je prodao aplikaciju. Drugo - u Tehničkoj je dokumentaciji opisan algoritam za izračun ZKI i tvoje je (naše je) da ga ispravno implementiraš u svom programu...

Nov 21, 2012 at 5:30 PM

Lopov je i tko ljestve drži. Meni napamet ne pada u program ubaciti 'fičr' kakav sam opisao, ali da sam te vrste mislim da bih našao dosta korisnika koji bi to dočekali kao nepobjedivu prednost mog prema drugim programima... Istina, moram upisati svoj OIB u zahtjev JIR-u... (ali vidi prethodni post mladenbabic).

@mladenbabic na istu temu: točka 4 - nije Apisu valjda problem vidjeti tko je zatražio razvojne certifikate... Misliš da je netko mogao razviti svoje rješenje bez toga?

Nov 21, 2012 at 5:33 PM
Edited Nov 21, 2012 at 5:38 PM

@PBDudek, pa ja upišem tvoj OIB u svoje riješenje, i ti si tražio razvojni certifikat, nisi li? I što sad? Čemu služi to?

Govorim otvoreno, kao apsolutni legalist, samo o onome što sam uočio, jer sam koliko, 50 dana, kao i svi vi "umočen" u "fiskalizacijska pravila".

Mene najviše brine ova prva točka. Ona otvara mogućnost prodaje švercane robe, bilo kakve kvalitete kroz legalne kanale prodaje, i to fiskalizirane kanale - što kupcima daje dodatnu vjeru i "sigurnost" u kvalitetu robe !

Kupiš djetetu nešto, i uvjeren si da je to sigurno, jer imaš fiskalizirani, provjerljivi račun. "Sve ok".
A uopće ne mora biti tako !!!

Nov 21, 2012 at 5:37 PM

Ti si Mladene postao veći Slavko od Slavka, žestoko njegove brige brineš.

Evo ti pa čitaj najnoviji članak iz 24 sata :

Stoljetni ratovi s Osmanlijama imali su sudbonosne posljedice za sve slojeve hrvatskog društva, no najteže su pogađali seljake. Oni su, osim redovitih obveza prema vlasteli, prema crkvi i državi, bili opterećeni i izvanrednim obvezama – o vlastitom su trošku i sa svojim zapregama popravljali i gradili pogranične utvrde, hranom opskrbljivali njihove posade, prihvaćali pušku kad bi zagustilo, plaćali redovite i izvanredne ratne daće itd. Budući da ih je bilo sve manje, nameti su bili sve veći.

Sve bi se to i podnijelo da ih nisu mučila vlastela, koju opće nedaće nisu mogle odvratiti od misli na vlastiti džep, a o kojima je ostrogonski nadbiskup ANTUN VRANČIĆ izvijestio kralja Maksimilijana da "s njima gospoda u Hrvatskoj gore postupaju negoli s marvom". Vlastela su prisiljavala seljake da viškove, koje su iznosili na tržište, prvo ponude njima. Oni bi im to plaćali po niskoj cijeni, a prodavali po višoj. Uz to, vlastela su im povećala davanja u prirodninama (naturi). Seljačku trgovinu otežavali su i mitnicama na kojima su ubirali mitničarinu prema vlastitoj procjeni. Sve je to otežavalo i onako težak položaj seljaka.

 

Upss ili je to iz malo starijeg broja, pa me sličnost zeznula.

 

Ja sam inače podpuno za fiskalizaciju jer mislim da če me to riješiti barem djela nelojalne konkurencije.

Ali tak dugo dok Slavko Tahi ne veli kmetovima , dečki , bumo sad pošteno djelili pola-vašega-vama pola-vašega-nama nebude niš od gospodarskog oporavka.

Oni po svjetu traže budale koje budu kod nas u privredu investirali uz ovu poreznu i paraporeznu presiju.

Takvih , osim trgovačkih lanaca nema.

Nije država sama sebi cilj, i tebala bi se rastegnuti na krevet koliki ima, a fiskalizacija bude samo prebacila polu-sivi dio privrede u potpuno-sivi(fuš).


Nov 21, 2012 at 5:53 PM
Edited Nov 21, 2012 at 5:54 PM

@vvrbane, ti si ravnodušan prema mogućnosti da djetetu kupiš kinesku zabranjenu žvakalicu, koju je LIDL dao na uništavanje, a za koju si u loklanom dućanu dobio FISKALIZIRANI račun, koji prolazi provjeu SMSom pa ti je time fiskalizacija dodatno produbila tvoju sigurnost u tu žvakalicu?

kako to misliš da su to slavkove brige a ne moje?

Nov 21, 2012 at 6:01 PM
mladenbabic wrote:

@vvrbane, ti si ravnodušan prema mogućnosti da djetetu kupiš kinesku zabranjenu žvakalicu, koju je LIDL dao na uništavanje, a za koju si u loklanom dućanu dobio FISKALIZIRANI račun, koji prolazi provjeu SMSom pa ti je time fiskalizacija dodatno produbila tvoju sigurnost u tu žvakalicu?

kako to misliš da su to slavkove brige a ne moje?

Pa mislim u tom kontekstu da bi bio red da daju finalnu specifikaciju, a ne da im mi do 31.12. dajemo svaki dan ideju da dodaju nekaj novoga.

A ni staro nisu dokraja definirali ni obrazložili.

Da ne velim da se ne sječam ni da je zakon o fiskalizaciji donesen.

Sav posel bumo finalizirali od božića do nove godine.

Vidiš da budu Dudeka v grob sterali.

Nov 21, 2012 at 6:16 PM
mladenbabic wrote:

@PBDudek, pa ja upišem tvoj OIB u svoje riješenje, i ti si tražio razvojni certifikat, nisi li? I što sad? Čemu služi to?

Govorim otvoreno, kao apsolutni legalist, samo o onome što sam uočio, jer sam koliko, 50 dana, kao i svi vi "umočen" u "fiskalizacijska pravila".

Mene najviše brine ova prva točka. Ona otvara mogućnost prodaje švercane robe, bilo kakve kvalitete kroz legalne kanale prodaje, i to fiskalizirane kanale - što kupcima daje dodatnu vjeru i "sigurnost" u kvalitetu robe !

Kupiš djetetu nešto, i uvjeren si da je to sigurno, jer imaš fiskalizirani, provjerljivi račun. "Sve ok".
A uopće ne mora biti tako !!!

Prvo, otkud znaš da sam tražio certifikat (dobro OIB ćeš mi lako naći, ali nije pod PBDudek:)). Svejedno, tko god podvali moj OIB kao proizvođača softwarea i radi malverzacije, kad inspektori uoče nepravilnosti kod nekog od (tvojih) korisnika, oni po OIB-u dođu k meni, ja kažem da ne poslujem s tom firmom, oni me suoče s direktorom i on prizna da me nikad u životu nije vidio. K tome, svoje programsko rješenje je kupio od tebe i platio tebi, pa ako ti ga nije platio preko neke fantomske offshore firme, lako će naći tebe umjesto mene.

A za švercanu robu (cigarete prekucane u kikiriki) - to se moglo i dosada, ali se moglo još povrh toga i utajiti porez.

Nov 21, 2012 at 6:19 PM

@vvrbane - Dudek je preživel i Cinobera i Regu, pa će i fiskalizaciju... Možda ga v groba steraju švercani cigaretlini koje je platio kao kikiriki...

Nov 21, 2012 at 6:49 PM

@PBDudek, ja ne govorim da to nije uhvatljivo - sve je. ja govorim o propustu fiskalizacije, a osnovna zadaća fiskalizacije je spriječiti posljedice, a ne liječiti ih.
do sada su ih samo liječili, odnosno "liječili". 

Kao što obveznik fiskalizacije prijavljuje poslovni prostor, svojim certifikatom, na isti bi način vlasnik programa trebao prijaviti svoj naziv svog programa i svoj OIB pa takav zahtjev digitalno potpisati svojim certifikatom. U tom slučaju ti ne možeš prijaviti moj OIB u svoj program jer nemaš moj certifikat.

Nov 21, 2012 at 7:23 PM

Prijedlog je dobar - ako nadležni prate ovu diskusiju.

Ali, do ove problematike smo došli širenjem teme, a ja sam isprva samo htio ukazati na razliku pristupu problema kada inspekcija zatraži ponovljen ZKI za neki račun, za koji mislim da im nije dovoljno ponovno isprintati isti račun sa istim zaštitnim kodom, već u svojim rješenjima moramo u tu svrhu osigurati ISTOVJETNO REGENERIRANJE zaštitnog koda za uvjete prema već prethodno izdanom računu.

Nov 21, 2012 at 7:34 PM

A propos prethodnog posta, to znači da je pametno uz svaki račun u bazi čuvati sve elemente koji sudjeluju u kreiranju ZKI-a (koji, priznajem, mogu u tu svrhu biti korisni samo dok se ne promijeni privatni ključ certifikata...), a nije naodmet zabilježiti i sam ZKI, čisto da ga se ne mora generirati svaki put kad ponovno zatreba isprintati kopiju izdanog računa.

Nov 21, 2012 at 7:34 PM
Edited Nov 21, 2012 at 7:42 PM
PBDudek wrote:

Prijedlog je dobar - ako nadležni prate ovu diskusiju.

Ali, do ove problematike smo došli širenjem teme, a ja sam isprva samo htio ukazati na razliku pristupu problema kada inspekcija zatraži ponovljen ZKI za neki račun, za koji mislim da im nije dovoljno ponovno isprintati isti račun sa istim zaštitnim kodom, već u svojim rješenjima moramo u tu svrhu osigurati ISTOVJETNO REGENERIRANJE zaštitnog koda za uvjete prema već prethodno izdanom računu.

i ja sam to tako shvatio, da imam formu u koju upisem podatke koje porezna izdiktira, i generiram zki.

moguci je problem, ono sto je dkustec izvrsno primjetio, istek certikata s kojim je zki bio potpisan. pitanje je, jeli moguce koristiti kljuc iz isteklog certifikata za potpis? ako je, onda moramo cuvati i sve certifikate, kao i podatak s kojim je certikatom originalni racun potpisan.

edit /

inace po trenutnim se pravilima, mora omoguciti naknadno printati racun sa svim identicnim podacima originalnom, prvoprintanom racunu. znaci mora se cuvati i zki. (ako se ne printa na duplu traku). zato nisu vazeci oni r-1,2 racuni koji imaju crtu, da si kupac saam upise svoje podatke.

Nov 21, 2012 at 7:37 PM

E tu bi bilo lijepo od nadležnih da nam pojasne kako oni to zamišljaju...

Nov 21, 2012 at 7:39 PM

A mi smo barem 5 godina (ili koliko već vrijede???) po tom pitanju mirni... nadam se da ne misle da su i oni...

Nov 24, 2012 at 9:58 PM

Ne kuzim zasto se inzistira na PONOVNOM GENERIRANJU ZKI-a??? Gdje to u Zakonu pise da ga je potrebno "ponovo generirati"? Treba li onda ponovo generirati sve elemente racuna (datum, vrijeme, broj racuna, operatera, itd)? Jer samo tako se moze pravilno generirati isti ZKI. Zasto bi bilo dopusteno cuvati datum i vrijeme u bazama, a ne i ZKI ?  Mozda zato da nam bude teze???

Po meni je, radi naknadne kontrole, potrebno u bazama cuvati sto vise elemenata racuna, a sto manje ih ponovo racunati, jer ce se kad tad desiti situacija da se nesto promijenilo, a bitno utjece na repliku racuna. U principu, ja cuvam sve osim zaglavlja i podnozja racuna u koje korisnik upisuje svoje reklamne podatke, a koje je lako ponovo upisati da budu identicni (ako su u medjuvremenu mijenjani). Jedino sto ponovo racunam su porezi (njih ne cuvam-samo porezne stope) i total. Stoga mislim da se i JIR i ZKI itekako trebaju cuvati u bazama, dok UUID nije potrebno cuvati, uostalom on se nigdje ne printa pa ga eventualna kontrola nema sto ni traziti.

Nov 26, 2012 at 5:15 AM

@viggor Tehnička specifikacija, poglavlje 12, citat:

Porezna uprava ne provjerava zaštitni kod ali na njezin zahtjev obveznik fiskalizacije, temeljem istih ulaznih parametara, mora kreirati zaštitni kod jednak onome s računa.

Nov 26, 2012 at 10:21 AM

@PBDudek

Odlicno, i sto sad? Otkud oni znaju da li je program "generirao" ili procitao kod iz baze? Da nece mozda disasemblirat source? Mislim da su se sami malo "zajebunili" oko terminologije, ali cisto pravno gledano, ovo sto pise u Teh. spec ispada da je tako - treba ponovo generirati, ali u praxi prilicno upitan nacin "generiranja" i njihove kontrole.

Jedan od parametara ZKI-a, koliko vidim, je i broj racuna. Cim ti kazu, ajmo mali, da vidimo racun broj x, tvoj program bi trebao znati o kojem racunu se radi i sve podatke koji su u njega upisani. Dakle, po meni, iako u teh. spec pise to sto pise, lakse je nama programerima "pamti pa isprintaj".

Ne pricam ja ovo samo zato da bih se pravio pametan vec zato sto je najcesce program za izdavanje racuna (KASA, BLAGAJNA ili kako god se zvao) odvojen od nekog administracijskog programa (kojim se radi sve ostalo osim izdavanja trenutnih racuna), tako da ako se rutine za racunanje MORAJU napraviti (ili pozivati) u KASI, zasto bi se isto radilo i u ovom drugom administrativnom dijelu paketa, pa kad nesto treba promijeniti, da se mijenja na 2 mjesta, itd, itd.

Nov 26, 2012 at 10:33 AM

Kako god želiš (ili ti je jednostavnije)...

Meni nije problem napraviti formu za unos parametara, pa pozvati istu rutinu koja formira ZKI za račun pri izdavanju. Time se unaprijed osiguravam da mi kod nekog korisnika ne uleti neki nadobudni inspektor koji je stvar protumačio isto kao i ja, pa prekršitelje hvata na foru da zahtijeva ZKI prvo sa jednim od parametara koji je različit od onog u računu (npr. vrijeme izdavanja sekundu kasnije - pa ne smiješ dobiti isti), a zatim traži da se upiše jednako kao u računu i očekuje ZKI sa računa.

Ako je tebi manji problem upuštati se sa takvima u raspravu oko tumačenja što moraš ili ne moraš imati u programu... onda sretno!

Nov 26, 2012 at 11:37 AM
PBDudek wrote:

Kako god želiš (ili ti je jednostavnije)...

Meni nije problem napraviti formu za unos parametara, pa pozvati istu rutinu koja formira ZKI za račun pri izdavanju. Time se unaprijed osiguravam da mi kod nekog korisnika ne uleti neki nadobudni inspektor koji je stvar protumačio isto kao i ja, pa prekršitelje hvata na foru da zahtijeva ZKI prvo sa jednim od parametara koji je različit od onog u računu (npr. vrijeme izdavanja sekundu kasnije - pa ne smiješ dobiti isti), a zatim traži da se upiše jednako kao u računu i očekuje ZKI sa računa.

Ako je tebi manji problem upuštati se sa takvima u raspravu oko tumačenja što moraš ili ne moraš imati u programu... onda sretno!

Pametno zboris,

i ja sam slozio Formu gdje se unese datum,vrijeme,broj racuna i iznos racuna.

OIB, poslovni prostor i naplatni uređaj su iz korisnika programa. I peri....

Na osnovu toga generira se identican ZK kao i prema prilozenom ( od starne inspekcije ) racunu.

Tek toliko da se "gospodi" ne dozvoli mogucnost naplate nekakvih kaznica i tko zna cega sve ne...

Coordinator
Nov 26, 2012 at 11:49 AM

Danas ti ističe FISKAL certifikat.

Sutra nabaviš novi, a preksutra ti dođe inspektor tražiti izračun ZKI kooda od prije 10 dana... 

što onda?!

Nov 26, 2012 at 11:54 AM
dkustec wrote:

Danas ti ističe FISKAL certifikat.

Sutra nabaviš novi, a preksutra ti dođe inspektor tražiti izračun ZKI kooda od prije 10 dana... 

što onda?!

Svi su već zaključili da to komplicira stvari, ali i ja sam već naveo u ovoj diskusiji da je to razmišljanje 5 godina unaprijed, kada počnu isticati certifikati. Do tada vjerojatno više neće biti Linića, a možda ni fiskalizacije;)

Nov 26, 2012 at 12:29 PM
dkustec wrote:

Danas ti ističe FISKAL certifikat.

Sutra nabaviš novi, a preksutra ti dođe inspektor tražiti izračun ZKI kooda od prije 10 dana... 

što onda?!

Pa tko kaze da se novi certifikat nece zvati FISKAL 2.

Ako radis sa starim FISKAL 1 dobit ces isto.....

Coordinator
Nov 26, 2012 at 12:31 PM
Edited Nov 26, 2012 at 12:33 PM

@goranv13, da, u pravu si - upravo će se tako zvati, ali privatni ključ koji će biti u njemu, a preko kojega generiraš ZKI, neće biti jednak onom privatnom ključu kojim si generirao ZKI na originalnom računu s jednakim podacima - a to bi značilo da bi apsolutno isti račun mogao imati različit ZKI.. što je jedan veliki propust...

Nadalje, ako koristiš stari certifikat, morat ćeš za svaki račun pamtiti i s kojim si certifikatom generirao ZKI tog računa, a to bi bila noćna mora za održavanje kako sustava tako i aplikacije... A uopće ne znam da li je moguće manipulirati privatnim ključem certifikiata koji je istekao "NotAfter" property.

Nov 26, 2012 at 1:07 PM
dkustec wrote:

@goranv13, da, u pravu si - upravo će se tako zvati, ali privatni ključ koji će biti u njemu, a preko kojega generiraš ZKI, neće biti jednak onom privatnom ključu kojim si generirao ZKI na originalnom računu s jednakim podacima - a to bi značilo da bi apsolutno isti račun mogao imati različit ZKI.. što je jedan veliki propust...

Nadalje, ako koristiš stari certifikat, morat ćeš za svaki račun pamtiti i s kojim si certifikatom generirao ZKI tog računa, a to bi bila noćna mora za održavanje kako sustava tako i aplikacije... A uopće ne znam da li je moguće manipulirati privatnim ključem certifikiata koji je istekao "NotAfter" property.

Pa zar ti u aplikaciji i naziv certifikata nije parametar?