Nema JIR-a pa neću izdati račun

Aug 29, 2014 at 5:19 PM
Pri izdavanju računa program nakon određenog vremena (iz iskustva, 4-6 s., ovisno o konfiguraciji PC-a) nezaprimanja JIR-a od PU korisniku nudi daljnje čekanje, izdavanje računa samo sa ZKI (bez JIR) i odustajanje od izdavanja računa (ne zapisuje se vrijeme izdavanja, kreirani ZKI niti redni broj računa).
Treću opciju sam dopustio da smanjim broj računa izdanih bez JIR-a i potrebu za naknadnim slanjem u slučajevima da korisnik sam u kratkom vremenu može otkloniti problem sa mrežnom/internet povezivošću (izvukao se LAN/telefonski kabel, zaboravio uključiti router....).
Shema 'odustajanja od izdavanja' uredno šljaka kada nema veze s internetom (zahtjev se ne šalje pa ne stiže ni JIR).
U slučaju da veza s PU radi (zathtjev se odašilje), ali JIR stiže usporeno (krivnjom internet providera, zbog sporog računala ili -nedajbože- sporosti CIS-a u datom trenutku), te moj korisnik odustane od izdavanja računa, a JIR naknadno stigne, pri sljedećem pokušaju izdavanja (printanja) računa šalje se novi zahtjev za isti račun, ali s novim vremenom izdavanja, te novim ZKI (jer je i vrijeme izdavanja novo, neovisno je li broj računa isti ili novi).
U tom slučaju, CIS za isti račun prima dva (ili više) zahtjeva s oznakom prvog (ne ponovnog) slanja, što i jeste slučaj, jer u programu račun zbilja nije izdan (isprintan) sve dok korisnik odustaje od izdavanja računa bez JIR-a. U svakom zahtjevu je različito (sve veće) vrijeme izdavanja i, shodno tomu, različiti ZKI.
'Pametni' CIS bi u takvom slučaju zaključio da se račun pokušao izdati više puta, ali izdan je samo zadnji puta kad je stigao zahtjev za fiskalizaciju.
Referent PU mom korisniku uz izlist iz CIS-a šalje upozorenje da je isti račun fiskaliziran tri puta sa različitim vremenima izdavanja (razmak 1 min) i ZKI-ovima. Možda je fiskaliziran tri puta, ali izdan je (i prvi put isprintan) samo jednom i to pri zadnjem (jedinom uspjelom) pokušaju fiskalizacije, te je u bazi zabilježen s rednim brojem, vremenom izdavanja, ZKI-jem i JIR-om posljednjeg pokušaja.
Jedini zaključak do koga mogu doći:
AKO SI KREIRAO ZKI, MORAŠ IZDATI RAČUN, S JIR-om ILI BEZ!!!!!!
To nigdje gdje ja znam ne piše eksplicitno, ali očigledno gornji scenarij CIS ne prihvaća kao regularan.
Pitanje: zna li tko način (koristim Raverus EXE) provjere je li zahtjev uredno otposlan i zaprimljen od CIS-a, te je li odgovor s JIR-om CIS uputio ili nije (jer ne mogu ga čekati sto godina da zaključim da neće stići).
U suprotnom, upozoravam sve koji su eventualno u svoja rješenja ugradili sličnu opciju odustajanja od izdavanja računa ako JIR ne stigne u razumnom vremenu, da ju izbace.
Aug 29, 2014 at 7:25 PM
Pa ne znam niti kako ti je palo na pamet to raditi. Kako možeš znati da li je račun stigao do CIS-a, dobio JIR, server je poslao JIR ali ga ti nisi zaprimio, pa to ne znaš. Pretpostavljam da je CIS svjestan takvih situacija, i vidi kada se to dogodi, ali sve dok je vrijeme isto, zki isti, ne reagiraju jer znaju da tu nema pomoći. Ali ako kao ti brišeš taj račun (recimo br. 6 iznos 10kn), a CIS ga je zaprimio, a ti nisi dobio JIR, slijedeći račun koji ti izdaš će opet biti broj 6, ali recimo 20kn. I naravno da je to pogrešno i ne bi se smjelo događati. Zato i postoji ZKI.
Aug 29, 2014 at 7:29 PM
Edited Aug 29, 2014 at 7:54 PM
PBDudek wrote:
AKO SI KREIRAO ZKI, MORAŠ IZDATI RAČUN, S JIR-om ILI BEZ!!!!!!

Yebote što si ti to sve zakomplicirao, a sve je tako jednostavno.
Kao prvo i osnovno: U SVAKOM slučaju moraš izdati račun
Nadalje,
if(računalo ne radi)
izdaješ ga iz knjige računa bez ZKI i JIR. ali ga kasnije šalješ CIS-u
else if(Internet ne radi)
izdaješ ga sa ZKI-om bez JIR-a ali kad dođe Internet šalješ ga sa ISTIM ZKI-om, datumom, itd....
else
izdaješ ga sa ZKI-om i dobijenim JIR-om

EDIT:
Koji k. je ovom formatiranju, zasto ne mogu maknuti ove okvire?
Aug 29, 2014 at 8:33 PM
Edited Aug 29, 2014 at 8:38 PM
Slažem se sa odgovorima, ali evo moje nedavno iskustvo sa CIS-om.

Poruka zahtjev za isti račun slana je 15 puta - sa istim ZK-om, od 2. slanja nadalje sa oznakom naknadne dostave (sve xml poruke zahtjeva za taj račun su identične osim zaglavlja - id i vrijeme poruke). Tek 15. puta dobiven je odgovor (kod korisnika) i upisan JIR.
Slijedi nadzor u kojem PU kaže da u odr. mjesecu postoji razlika između fiskaliziranih računa i predanog PDV obrasca - razlika je upravo u 14 x iznos tog računa. Naravno, pripremio sam prikaz fiskalizacije za taj mjesec sa logovima, id-evima poruka itd. i poslao u PU i čekam od sredine 6. mj. odgovor i nisam više siguran kako CIS tretira naknadna slanja i na koji način slaže evidenciju inspektorima.

Nadam se da će se pokazati da nije problem u tom računu, inače sve ovo nema smisla.
Aug 29, 2014 at 9:08 PM
Edited Aug 30, 2014 at 8:12 AM
@moremore - objasnio sam kako mi je palo napamet - da smanjim broj izdanih računa bez JIR-a. Ideja je da ako nisam izdao (isprintao) račun, mogu ponovno za njega tražiti JIR, sa novim (kasnijim) vremenom izdavanja i nanovo kreiranim ZKI. Ne znam kako si zaključio da brišem račun, ne brišem ga nego ga ostavljam u statusu neizdanog. I dalje sam mišljenja da bi takve slučajeve CIS mogao protumačiti da korisnik pri fiskalizaciji nakon otposlanog zahtjeva nije primio JIR (u očekivanom vremenu ili nije uopće, što je u ovom scenariju svejedno), te da ako ponovno isti račun šalje na fiskalizaciju sa oznakom prvog slanja, da ga zapravo nije izdao i da će prihvatiti zadnji JIR u nizu slanja istog računa.

@georgia47 - ako ne postoji ikakva mogućnost odustajanja od izdavanja računa nakon neuspjelog pokušaja fiskalizacije, slažem se sa 'elseif' i 'else', a izdavanje računa bez ZKI i bez JIR ne znam kojom zakonskom rupom pravdaš....

@davor_h - Dakle, tvoje rješenje nema mogućnost odustanka od izdavanja nakon nezaprimanja JIR, pa ipak si (kao i ja) došao pod lupu nadzora PU. Danas sam prilagodio program u smislu da ako korisnik odbije dalje čekati JIR, da mora izdati račun samo s ZKI. Prema tvom iskustvu, očekujem uskoro nadzor iz istog razloga kao i kod tebe, jer ukoliko ne tjeramo korisnika da čeka JIR do besvjesti (ako ikada i stigne), očigledno je da CIS svako ponovljeno slanje zahtjeva (bilo prvog - kao kod mene, bilo naknadnog - kao kod tebe, a od sutra i kod mene) za isti račun jednostavno zbraja i uspoređuje s poslanom PDV prijavom. I kod mog korisnika, razlog nadzora i 'istrage' PU je diskrapancija podataka iz CIS-a i podnijete porezne prijave. Pa ako je i uzastopno višestruko ponovljeno slanje nedopustivo, onda - koje je ispravno rješenje?
Aug 29, 2014 at 9:27 PM
PBDudek wrote:
@georgia47 - ako ne postoji ikakva mogućnost odustajanja od izdavanja računa nakon neuspjelog pokušaja fiskalizacije, slažem se sa 'elseif' i 'else', a izdavanje računa bez ZKI i bez JIR ne znam kojom zakonskom rupom pravdaš....
Pa to ti je ona knjiga računa koja nema ni ZKI ni JIR (a kako bi ih i imala kad oni ovise o certifikatu korisnika, samom računu itd...), ali ima prazne kućice u koje se upiše taj JIR koji dobijaš naknadnom fiskalizacijom.

PBDudek wrote:
Pa ako je i uzastopno višestruko ponovljeno slanje nedopustivo, onda - koje je ispravno rješenje?

Ispravno rješenje je upravo to: ponovljeno slanje, ako treba i višestruko. Ne znam što je bilo konkretno u tom slučaju, ali mnogo mojih korsnika mnogo puta ostanu bez Interneta i naknadno pošalju račune. Naknadno slanje računa je jedan od temelja fiskalizacije.
Aug 29, 2014 at 10:12 PM
Sorry, ne kužim te... knjiga računa koja nema ZKI ni JIR, ali ima kućice za upis? Misliš valjda na ovjerene blok račune ispunjene kemijskom za slučaj da sve krepa? Onda OK.
Što se tiče ponovljenog (da se držimo zakonske terminologije - naknadnog) slanja računa, nije li ti slučaj koji je opisao davor_h dovoljno analogan mom slučaju? Njemu je, koliko sam ja razumio, istraga inicirana zbog uzastopnog NAKNADNOG slanja (što je, po tvome, ispravno), a meni zbog uzastopnog PRVOG slanja (po tvome, nedopustivog). Zar ćemo za svako ponovljeno naknadno slanje računa morati Poreznoj Upravi slati izvještaje i opravdanja?
Aug 30, 2014 at 12:11 AM
Edited Aug 30, 2014 at 12:43 AM
Ljudi, ajde da razjasnimo neke stvari, ZKI kada je jednom kreiran i ispisan, i prilikom naknadne fiskalizacije bi morao po svim pravilima biti isti - nije ga više potrebno niti računati ponovo jer se on veže za datum i vrijeme računa te iznos (informacije koje SE NE MIJENJAJU više nikad u ovom životu).
ISTI tj jedan račun se NAKNADNO može fiskaliziratii 100 puta ali pod uvjetom da su SVI PODACI RAČUNA KOJI SE ŠALJU ISTI iz razloga da CIS to ne bi tretirao kao novi račun nego bi uvijek "pregazio stari zapis".

Dakle ako si POSLAO račun a nema odgovora nakon par sekundi (tvoj slučaj), taj račun spremi, ispiši i šibaj dalje. Njega ostavi za naknadnu fiskalizaciju iz tog razloga što ga je CIS zaprimio možda, a ti nisi dobio odgovor. Dakle ispiši ga samo sa ZKI i mirna bosna. Ovo odustajanje od računa je moram reći glupa solucija i apsolutno nema smisla jer kako sam rekao, ne znaš jel negdje "zaštekao" odgovor na putu prema tebi.

davor_h wrote:
...sve xml poruke zahtjeva za taj račun su identične osim zaglavlja - id i vrijeme poruke...
Odbijam povjerovati u ovo.
Aug 30, 2014 at 7:14 AM
Edited Aug 30, 2014 at 7:31 AM
DejanK wrote:
...Ovo odustajanje od računa je moram reći glupa solucija i apsolutno nema smisla jer kako sam rekao, ne znaš jel negdje "zaštekao" odgovor na putu prema tebi.
Tvoja ocjena svrhovitosti opcije odustajanja od izdavanja računa mi je malo paušalna. I u mom slučaju ponovljenog prvog slanja i u slučaju višestrukog ponovljenog slanja (za koji tvrdiš da je jedini ispravan i moguć) logično je za zaključiti da će za dati račun u sustavu korisnika ostati posljednje prijavljeni podaci (podaci iz posljednjeg zahtjeva za fiskalizacijom i odgovora s JIR-om na njega).
I sam kažeš: 'ZKI kada je jednom kreiran i ispisan' - kod odustajanja ne vidim problem da ako nisam ISPISAO račun da ZKI nanovo kreiram pri sljedećem pokušaju izdavanja (što znači fiskaliziranja i ispisivanja) računa.

DejanK wrote:
davor_h wrote:
...sve xml poruke zahtjeva za taj račun su identične osim zaglavlja - id i vrijeme poruke...
Odbijam povjerovati u ovo.
Zar nije normalno da su ponovljeni naknadni zahtjevi za fiskalizacijom jednaki (osim UUID i vremena slanja zahtjeva)?

Zahvaljujem svima koji su se uključili u raspravu, ali kako sam očigledno samo ja jedini bio dopustio takovo rješenje u programu i sada ga izbacujem, daljnje kompliciranje i teoretiziranje je izlišno.

Jedino me još zabrinjava slučaj koji je opisao davor_h, jer prema tomu CIS nije u stanju pravilno prepoznati niti korektno ponovljeno naknadno slanje zahtjeva za fiskalizaciju, pa nisam ziher da sam izbacivanjem išta riješio za ubuduće.
Aug 30, 2014 at 9:37 AM
Edited Aug 30, 2014 at 9:41 AM
PBDudek wrote:
Jedino me još zabrinjava slučaj koji je opisao davor_h, jer prema tomu CIS nije u stanju pravilno prepoznati niti korektno ponovljeno naknadno slanje zahtjeva za fiskalizaciju, pa nisam ziher da sam izbacivanjem išta riješio za ubuduće.
Kažem, od PU smo uspjeli dobiti samo razliku za taj mjesec. Mi (znači ne PU) smo zaključili da je razlika jednaka zbroju naknadnih slanja tog računa (ostali računi su išli "iz prve"). Evo, ponovno gledam i tns:Racun node je identičan u svim datotekama, jedina razlika je što prva ima NakDost false, a ostale true.

Ne mogu reći da CIS ne prepoznaje naknadna slanja, jer još nismo dobili odgovor od PU.

Možda nisam ni trebao ovo pisati prije konačnog odgovora PU, samo radite prema tehničkoj dokumentaciji i trebalo bi biti sve ok sa naknadnim slanjima.
Aug 30, 2014 at 9:45 AM
koliko sam pohvatao iz gore svega, moje misljenje je slijedece: PBDudek, krivo radis i sto prije to izbaci iz programa. Ako te napenale s nekom kaznom, nece biti korisnik kriv sto tako radi, nego ti sto si mu to omogucio, a onda idu na bubanj i svi ostali gdje si instalirao program i poslao prijavu prostora sa svojim OIB-om.

Jedino ispravno je gore vec opisano, saljes podatke u CIS i nakon sto dobijes JiIR, printas ... ako nema JIR-a, ide samo sa ZKI-jem ... kasnije naknadna fiskalizacija svih racuna koji su otisli bez JIR-a sa istim onim ZKI-jem s kojim je i odstampan racun, nikako drugim ili drugacijim.
Rok je 2 dana za naknadno fiskaliziranje, mada sam imao neke koji su debelo premasili te periode, ali jos ih nitko nikada nije pitao za to.

Ako krepa komp, knjiga racuna i kad sve popravis, prepisivanje u kasu, te klamanje tih racuna u knjigu popisa, da ne prepisujes JIR i ZKI u "prazne kucice"
Aug 30, 2014 at 11:25 AM
Ma dobro, sad već valjda debelo tjeram mak na konac, izbacio sam to prokleto odustajanje, ali...
Ali...
Ali, ja zbilja nigdje, niti iz zakona, niti iz pravilnika, niti iz tehničke specifikacije ne vidim da je decidirano, niti neizravno, igdje navedeno kako je takvo postupanje nedopušteno, te sam i dalje mišljenja da bi CIS prema takvim scenarijima mogao uzeti istu logiku kao i pri ponovljenom naknadnom slanju računa, samo računajući da u prethodnim zahtjevima za fiskalizaciju račun zbilja nije izdan.
Jedini razlog što sam izbacio tu opciju su vaše preporuke u ovoj diskusiji, sama činjenica da mi poreznjaci gnjave korisnika i linija manjeg otpora.

Problem je što nitko (osim valjda samih poreznjaka) ne zna koja su točno pravila što smije biti poslano u CIS a što ne, pa o tome zaključujemo samo kad se pojave kod korisnika i tvrde da je nešto pogrešno, ne obrazlažući to ni objavljenim zakonima, ni pravilnicima ni tehničkom specifikacijom.
Eto, sad smo zaključili da je višestruko prvo slanje računa nedopušteno, da je jedno prvo i jedno ili više naknadnih slanja (valjda) dopušteno i pravilno, ali volio bih da to negdje konkretno i službeno i PIŠE.
Aug 30, 2014 at 12:01 PM
PBDudek, što tebi znači odustajanje od računa?
Što tvoji korisnici daju kupcu ako ne dobiju JIR i kako ti kažeš odustanu od računa?
Mislim da znaš da svaki kupac mora dobiti račun i to nema veze s fiskalizacijom.
Aug 30, 2014 at 12:12 PM
Ne odustajanje od računa, nego odustajanje od IZDAVANJA računa. To znači da u tom pokušaju račun neće biti izdan jer nije dobio JIR, a korisnik želi pokušati popraviti vezu. Račun se ne printa, pa niti ne može biti uručen kupcu. Operater nakon što je sredio internet (uštekao kabel, resetirao router ili sl.), ponovno izdaje račun, dobija JIR i printa se i uručuje kupcu sa JIR-om.

Koliko vidim iz gornjeg posta, a i iz vlastitog iskustva, izdavanje računa sa ZKI bez JIR i sve moguće poruke programa kako u tom slučaju račun treba naknadno fiskalizirati ništa ne znače velikom broju korisnika, te na naknadnu fiskalizaciju računi čekaju dok zbog nečeg drugoga ne dođem ja ili moji kolege pa nađemo hrpetine računa koji kasne na fiskalizaciju po mjesec dana. Ali po tom pitanju od PU niti ja dosad nisam imao primjedbi.

Dakle, s opcijom PRIVREMENOG odustajanja od IZDAVANJA nefiskaliziranih računa htio sam smanjiti potrebu za naknadnim slanjem. Normalno da se svaki račun na kraju MORA izdati.
Aug 30, 2014 at 12:32 PM
Stvar bi trebala biti vrlo jednostavna, kod izdavanja računa kupac dobije račun sa zkir bez Jira ako recimo nema pristup internetu. Prilikom izdavanja sljedečeg racuna cis automatski pretražuje bazu da li postoji račun bez Jira i ako da onda najprije automatski
ažurira jir na prethodno izdanim računima bez Jira a trenutni račun normalno izlazi fiskaliziran. Tako ste riješili problem naknadnog slanja od strane korisnika i automatizacijom ste onemogučili svaku daljnju manipulaciju s računima bez Jira. Ivica Pavlacic
Merlinka d.o.o. Senjska 6 47000 Karlovac
Aug 30, 2014 at 1:30 PM
@merlinka - To je super kad imaš pilu od kompa od 7000 kn i povezan si najskupljim i najpouzdanijim Sprinternetom, pa operater nema pojma da je program u pozadini nabrzaka u bazi na serveru za tren provjerio ima li nefiskaliziranih računa, našao ih stotinjak, a CIS je baš u tom trenu neopterećen pa ti JIR-ove šalje ko na traci.

A onda zamisli dućan na otoku, komp koji ne možeš prodati za sto kuna sa 512 RAM-a (ima i pokoji virus koji mu troši 80-90% resursa), u njega uštekan stick koji je gazda jučer zaboravio obnoviti bonom od 50 (pardon, 55) kuna, a koji kada ima kuna- više ne radi nego radi, i 10 ljudi čeka u redu da se naknadno fiskalizira jučerašnjih 150 računa kako bi se izdao današnji račun onom prvom u redu...

Hoću reći da naknadno slanje može biti vremenski vrlo zahtjevan proces, pa smatram da korisnik sam treba odlučiti kada će se provesti naknadna fiskalizacija (najčešće ili kada nema gužve ili po zatvaranju dućana).
Aug 30, 2014 at 8:20 PM
Edited Aug 31, 2014 at 11:33 AM
PBDudek wrote:
Zar nije normalno da su ponovljeni naknadni zahtjevi za fiskalizacijom jednaki (osim UUID i vremena slanja zahtjeva)?
Normalno da je, ali nisam citirao srž pa nisi shvatio, ali evo opet...

davor_h wrote:
Poruka zahtjev za isti račun slana je 15 puta - sa istim ZK-om, od 2. slanja nadalje sa oznakom naknadne dostave (sve xml poruke zahtjeva za taj račun su identične osim zaglavlja - id i vrijeme poruke). Tek 15. puta dobiven je odgovor (kod korisnika) i upisan JIR.
Slijedi nadzor u kojem PU kaže da u odr. mjesecu postoji razlika između fiskaliziranih računa i predanog PDV obrasca - razlika je upravo u 14 x iznos tog računa...
Koliko sam razumio, davor_h je i napravio onako kako treba - ponovljeni naknadni zahtjev je jednak kao i originalni ali je valjda to CIS zaprimio kao novi račun. Zato sam napisao da odbijam povjerovati u to jer je to u praksi nemoguće.

Po drugi puta ću objasniti ovo ispod.
PBDudek wrote:
Ne odustajanje od računa, nego odustajanje od IZDAVANJA računa. To znači da u tom pokušaju račun neće biti izdan jer nije dobio JIR, a korisnik želi pokušati popraviti vezu.
Može korisnik popraviti vezu, šta god, ali bi trebao ispisati ga odmah samo sa ZKI i naravno, pošto si poslao zahtjev, ti taj račun MORAŠ spremiti i naknadno fiskalizirati jer ne znaš jel ga je CIS zaprimio ili ne.

Jednom poslani zahtjev u CIS je gotova stvar za sve vijeke vjekova imao on odgovor ili ne, to te ne bi trebalo uopće zanimati.

Naknadno slanje se lako isprogramira da se odradi automatski kada npr poslovni prostor ne radi (npr. bilo kada tokom noći. Ja sam napravio da korisink može odabrati vrijeme.)
Da se netko potrudio nama omogućiti kroz CIS provjeru računa, onda bi tvoja solucija bila super jer bi se mogao provjeriti račun jel zaprimljen, pa onda odustati od računa ukoliko nije. (Iako bi i to bilo kompliciranje jer baš zbog tog razloga i postoji ZKI...) Ali za sada, ne možeš odustati od računa i "pregaziti ga s novim" nakon što si poslao zahtjev a nema JIR-a. To nema smisla jer sam već gore objasnio i podebljao razloge.

Kako sam i rekao, upravo iz tog razloga postoji ZKI - ako nema odgovora nakon slanja zahtjeva, račun se mora spremiti jer je možda taj ZKI upisan u CIS i isti jedino može služiti kupcu kod provjere tako što će se naknadnom fiskalizacijom poslati taj ZKI i sve ostalo što kupac ima na računu. Nadam se da sam ti malo uspio pojasniti stvar. Znam ja da si ti zamislio da olakšaš korisnicima to sa naknadnom fiskalizacijom, tj da računa bez JIR-a nema, ali mislim da nisi dobro pohvatao logiku onda zašto služi ZKI...
Aug 31, 2014 at 11:12 AM
Edited Aug 31, 2014 at 12:00 PM
marino235 wrote:
Ako te napenale s nekom kaznom, nece biti korisnik kriv sto tako radi, nego ti sto si mu to omogucio, a onda idu na bubanj i svi ostali gdje si instalirao program i poslao prijavu prostora sa svojim OIB-om.
Koliko ja znam (ispravite me ako griješim), vezano za fiskalizaciju a i općenito - klijent sam odgovara za svoje poslovanje. Program je tu kao pomagalo tako da programer nikako ne može kazneno odgovarati ukoliko klijentu nešto nije uredu. Jedino privatna tužba...iako sumnjam da će i doći do tako nečeg. Ja sam imao slučaj da sam za sustav PDVa umjesto true/false koristio 1/0 i gle vraga, provjerili su tko još koristi moj software i otišli do par klijenata ali nije bilo nikakvih problema...

Ono što bi JA napravio, otišao bi u poreznu, i porazgovarao o tome sa nekim tko je na višoj poziciji, objasnio bi situaciju - čisto da ih informiram, ukoliko dođe do nekog problema, da se možeš pozvati na nekoga iz porezne i da si ti taj propust već ispravio jel...
Aug 31, 2014 at 10:30 PM
Ovu sam diskusiju zapravo pokrenuo već 'post festum', kada sam već maknuo iz programa to svoje 'odustajanje od izdavanja', tek toliko da mi srce bude na mjestu da mi kolege potvrde da nisam njime napravio tako kardinalnu, banalnu i ordinarnu glupost, već da je to samo jedna od posljedica nedorečenosti u pravilima igre oko fiskalizacije koju mi, koji njen sustav trebamo pretvoriti u jednoznačni dijagram toka i isprogramirati tako da i najgluplji operater ne može poslati sistemski pogrešan podatak u PU, u detalje zapravo upoznajemo tek kad neki od njih (korisnika) upadne u ralje inspektora koji su tek nijansu upućeniji u pravila fiskalizacije od prosječnog konobara ili kćeri vlasnika malomišćanskog dućana koji je nekim čudom uzeo naš program umjesto Fiskala koji može kupiti u Konzumu. I kad on (inspektor) kaže da nešto nije u redu, trčimo to ispraviti ne pitajući po kojem slovu zakona, a kamoli kojom logikom smo pogriješili.
Sva naša palamuđenja oko toga da kad JIR nije zaprimljen (na vrijeme ili nije uopće) i koje su nam opcije u tom slučaju - jer ne znamo je li zahtjev uopće odaslan, ako je - da li je i zaprimljen, ako je - da li je odgovor (bio u njemu JIR ili poruka o greški) od CIS-a otposlan, te kako postupati (koliko na njega čekati) ako jest, a što poduzeti i kako saznati da zapravo nije, dakle sva ta realna pitanja su od početka prebačena na nas, pa kad se u vezi njih pojavi problem (ili 'problem'), u raspravama nam je najnormalnije da razmišljamo da li će kaznom 'napenaliti' nas ili korisnike naših programa.
A zašto?
Kada je fiskalizacija krenula, na ovom mjestu sam nahvalio APIS kako su, unatoč svim zlogukim prorocima, odradili dobar posao, pa sam čak dao plus i poreznjacima kako je to ipak znatan iskorak u uvođenju ne samo informatizacije, već i šire shvaćenog uređivanja močvare koja je do tada vladala u fakturiranju i prijavljivanju PDV-a.
Ali sada sve više shvaćam da su oni odradili samo usko svoj dio posla, ne vodeći računa o drugoj strani - nama i našim korisnicima.
Godinu dana je prošlo uz pokoju vijest kako su nekoga uhvatili 'in flagranti' - tipa inspektor kupi sladoled i ne dobije račun pa se slastičarna zatvori. A sada evo dolaze prvi konkretni nadzori temeljeni 'analizom' podataka poslanih fiskalizacijskom sustavu.
I što?
Nakon toliko vremena ja saznajem da moj sustav 'odustajanja od izdavanja' nije regularan. Valjda je ovaj korisnik prvi koji je odabrao tu opciju u programu. Čisto sumnjam.
Davor_h nakon toliko vremena dobija nadzor iz razloga ponovljenog naknadnog slanja. Valjda su mu svi korisnici do tada dobivali JIR-ove iz prve? Čisto sumnjam.
I moji, a koliko mi je bilo ovdje pročitati, i vaši korisnici prelaze rok od dva dana za naknadno slanje, i to debelo, a nitko se još nije javio sa viješću da mu je netko došao u nadzor, a kamoli 'napenalio kaznu' zbog toga.
Meni to miriši na to da su APISovci nakon što su uspješno složili sustav zaprimanja računa i slanja JIR-a ili otišli na malo duži odmor, ili su se godinu dana bavili nečim drugim, a sada su počeli smišljati algoritme analize zaprimljenih podataka, i u tijeku je faza ispitivanja... na živim podacima...
P.S. Ako se čudite duljini ovoga posta - nakon što sam izbacio opciju odustajanja iz programa, uzeo sam tjedan godišnjeg pa sada imam vremena pisati diskusije :)
Aug 31, 2014 at 10:37 PM
Jesam li uopće spomenuo da su 'inkriminirani' podaci koje su mi poslali - iz 2013.?
Sep 1, 2014 at 8:06 AM
Stavr je jako jednostavna. Ti JESI u prekršaju jer izdaješ novi ZKI za račun koji je već napravljen i koji možda je ili možda nije stigao do CIS-a. I neme se tu šta raspravljati. Sve bi bilo u redu da nisi mijenjao vrijeme (možda i datum) računa i kreirao novi ZKI.
Sep 1, 2014 at 8:09 AM
PBDudek wrote:
Pri izdavanju računa program nakon određenog vremena (iz iskustva, 4-6 s., ovisno o konfiguraciji PC-a) nezaprimanja JIR-a od PU korisniku nudi daljnje čekanje, izdavanje računa samo sa ZKI (bez JIR) i odustajanje od izdavanja računa (ne zapisuje se vrijeme izdavanja, kreirani ZKI niti redni broj računa).
PBDudek wrote:
ne brišem ga nego ga ostavljam u statusu neizdanog.
Ako ne zapisuješ vrijeme i datum izdavanja, niti redni broj, onda je to isto kao da ga obrišeš.
Sep 1, 2014 at 8:21 AM
Da, moremore, stvar je jako jednostavna. I nema se što raspravljati.
Drugim riječima, makni to iz programa, mi to tako nismo zamislili.
Ne znamo ni sami što smo zamislili, ali ti JESI u prekršaju.

Koji sam članak prekršio i kolika je zapriječena kazna?

Ne pitam za kaznu za obrisani račun, to je valjda svima jasno, i nema načina da mi korisnik obriše račun. Izdat će ga kad-tad (jer mu ne dam zaključiti smjenu sa neizdanim računima). Samo sam mu htio omogućiti da račun izda s JIR-om u najvećem broju slučajeva, što mi još odpočetka rasprave nije nitko argumentirano pojasnio zašto ne smijem.
Sep 1, 2014 at 8:49 AM
Znam ja da si ti imao dobre namjere. ALI, ponavljam: ti NE ZNAŠ da li je CIS zaprimio računa.

Uzmimo za primjer računa br. 50, 100kn izdan 01.09.14. sati 12.00.00 ZKI 1234567891231

Poslao si ga, nisi dobio JIR, ti NE PAMTIŠ ZKI, datum, vrijeme i broj. E sada, CIS JE ZAPRIMIO račun ali ti nisi dobio JIR. Izdaješ slijedeći račun, koji po ovome šta si ti napisao će opet imati broj 50!!! Sa drugim iznosom, datumom, vremenom itd.

Ti je sada jasnije da si u prekršaju i da te mogu opaliti kaznom?
Sep 1, 2014 at 9:22 AM
Edited Sep 1, 2014 at 9:23 AM
  1. Pametno se osigurati. Ja imam osigurano u Allianzu na osiguranu štetu do 200.000 kn. Godišnja premija je oko 1.500 kn
  2. Kod zapisivanja računa u tablice mislim da je nemoguće to korektno napraviti bez TRANSAKCIJE. No, oni koji nemaju relacionu bazu (ja radim sa SQL serverom) mogu biti i jesu u velikim potencijalnim problemima. A to govori o kvaliteti vašeg softvera. Tehnologija je izuzetno bitna!
  3. U praksi je moguće (istina rijetko, ali moguće), da 'spletom okolnosti' (loš PC, stick internet) račun ne dobije ni ZKI ni JIR. Mada se bez ZKI-a to ne bi smjelo desiti, ali se dešava, jer je moguće da dio programa (niti) koji obrađuje ZKI uslijed takvih okolnosti se mora prekinuti. Taj račun NIJE ISPRAVAN. S druge strane mora ostati zapisan u bazi sa svim elementima koje je imao. Ja takve račune pamtim, ali ih NE ISPISUJEM jer su NEISPRAVNI. Kad se veza popravi (ili odmah) pokušam ih ponovno fiskalizirati i tada ih ispisujem, ako dobiju ZKI.
  4. Račun se nakon dobivanja ZKI-a ne smije mijenjati ni u jednom elementu ( a i prije naravno). Ako pukne fiskalizacija i ne dobijete JIR, treba nakon nekog vremena ponoviti zahtjev sa istim onim elementima koje račun ima, sve ostalo je greška i kažnjivo. Račun bez JIR-a, a sa ZKI-om je 100% korektan račun.
  5. BACKUP podataka je izuzetno bitan! Ja kod zaključivanja blagajne radim backup na 2 lokacije (lokalno na disk i još dodatno na neki magnetni medij). Čuvam 5-10 kopija kompletne baze. U toku dana izdane račune dodatno u XML shemi spremam u poseban folder koji ima SINHRONIZACIJU sa CLOUD DISKOM. Tu mi se pokazao najbolji MEGA CLOUD jer nudi 50 Gb FREE, a može sinhronizirati bilo koji folder na disku
Sep 1, 2014 at 11:50 AM
Stanki wrote:
  1. Pametno se osigurati. Ja imam osigurano u Allianzu na osiguranu štetu do 200.000 kn. Godišnja premija je oko 1.500 kn
Je li to klasično osiguranje od odgovornosti ili je specificirano?
Možeš postati nekako policu osiguranja da vidim što piše u njoj, ako nije tajna?
Sep 1, 2014 at 4:34 PM
Edited Sep 1, 2014 at 4:35 PM
marino235 wrote:
Rok je 2 dana za naknadno fiskaliziranje, mada sam imao neke koji su debelo premasili te periode, ali jos ih nitko nikada nije pitao za to.
Itekako pitaju, tvoji su imali sreću. Napisana je kazna zbog 1 računa prekasno fiskaliziranog. Nadzor je, naravno, trajao vrlo kratko.
Sep 1, 2014 at 10:13 PM
Edited Sep 1, 2014 at 10:35 PM
PBDudek wrote:
Samo sam mu htio omogućiti da račun izda s JIR-om u najvećem broju slučajeva, što mi još odpočetka rasprave nije nitko argumentirano pojasnio zašto ne smijem.
Tvoje namjere su bile super i sigurno bi se svidjele ovima iz PU, samo što su oni sa ZKI pokušali koliko toliko smanjiti manipulaciju računa koje CIS nije zaprimio. I nitko nije ni rekao da ne smiješ, naprotiv, ali kada POŠALJEŠ jednom zahtjev, on se vodi kao RAČUN i MORAŠ ga spremiti.

A sad argumentirano (copy paste iz tehničke specifikacije):
2.1 Račun
...U svim slučajevima kad obveznik iz nekog razloga nije dobio JIR za izdani račun (prekid Internet veze,
potpuni prestanka rada naplatnog uređaja, greška u poruci odgovora, privremena nedostupnost CIS-a)
obveznik je dužan naknadno ponoviti slanje poruke....

12. DODATAK: Zaštitni kod izdavatelja
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č

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.
Ne želim te ugnjetavati, super je što si to na vrijeme ispravio. Da je tvoje "odustajanje od računa" bilo zamišljeno, sigurno bi tako nešto naveli, ali nisu. Stvar je baš (po meni) logički jednostavno odrađena.
Mislim da nema smisla rovariti po ovoj temi više jer se reklo sve što se moglo. Iskreno se nadam a i vjerujem da neće biti nikakvih problema sa PU.
Sep 2, 2014 at 8:07 AM
DejanK wrote:
Mislim da nema smisla rovariti po ovoj temi više jer se reklo sve što se moglo.
Slažem se i još jednom hvala svima koji su se javili.
Sep 3, 2014 at 9:29 AM
Edited Sep 3, 2014 at 9:30 AM
To je osiguranje u Allianzu od javne odgovornosti iz djelatnosti prema trećim osobama do iznosa 250.000 kn po štetnom događaju i 500.000 kn ukupno godišnje. Obuhvaća djelatnosti: računalno programiranje i knjigovodstvene usluge. Premija osiguranja je 1000 kn godišnje. (imam još osigurano požar, poplavu...pa sam mislio da je veća cijena).