Ponovno poslani računi sa istim brojem

Jan 10, 2013 at 6:33 PM
Edited Jan 10, 2013 at 6:36 PM

Kako se račun evidentira ako se pošalje 2 puta sa istim brojem računa (slučajno zbog greške u aplikaciji ili namjerno jer želimo stornirati). Znam da se može stornirati tako da se napravi novi račun sa istim podacima samo sa negativnim količinama i iznosima, a novim id-om računa.
Znači da li je netko poslao račune sa istim brojem, da li je netko preskočio brojeve računa i da li je netko slučajno poslao neke bezvezne račune na produkciju kod testiranja i koliko se trebamo bojati za to?

Jan 10, 2013 at 6:52 PM

Sta se tice storno racuna, o tome je vec bilo rijeci: radis novi racun sa minusnim iznosima i vrijednostima.

Nikada ne dirati vec poslani racun !!!

A sto se tice slanja 2 puta sa istim brojem, e tu stvarno nebi znao reci sta ce ti se desiti. Nelogicno je da CIS dobije 2 ista broja racuna sa razlicitim vrijednostima.

Napravite neki zapisnik ili kako vec to nazvati da je uslijed toga i toga doslo do greske koja je rezultirala slanjem 2 ista broja racuna.

I ni slucajno te racune ne brisati ili nesto drugo, posto su otisli takvi kakvi jesu..

Jan 10, 2013 at 7:02 PM
Edited Jan 10, 2013 at 7:04 PM

smijes poslati isti račun više puta. ali ISTI račun.

naime, u scenariju kada klijentska aplikacija pošalje request, koji se upiše u CIS, ali veza pukne na response-u, čime klijentska aplikacija ne dobije JIR, moguće je, i potpuno legitimno, da aplikacija ponovno pošalje isti zahtjev kako bi dobila JIR. Niti CIS ne zna da response nije stigao do clienta.

Aplikacija u tom trenutku niti ne zna da račun već postoji u bazi CISa, a CIS će takav dupli record tretirati kao jedan zapis, odnosno "gledati će" samo noviji insert u bazi. Samo ti je uniqueID (uuid) tog requesta različit, (jer je to ID zahtjeva, što znači novi zahtjev-novi ID), a sve ostalo ti mora biti identično kao u prvom zahtjevu.

Jan 11, 2013 at 1:56 PM
mladenbabic wrote:

smijes poslati isti račun više puta. ali ISTI račun.

naime, u scenariju kada klijentska aplikacija pošalje request, koji se upiše u CIS, ali veza pukne na response-u, čime klijentska aplikacija ne dobije JIR, moguće je, i potpuno legitimno, da aplikacija ponovno pošalje isti zahtjev kako bi dobila JIR. Niti CIS ne zna da response nije stigao do clienta.

Aplikacija u tom trenutku niti ne zna da račun već postoji u bazi CISa, a CIS će takav dupli record tretirati kao jedan zapis, odnosno "gledati će" samo noviji insert u bazi. Samo ti je uniqueID (uuid) tog requesta različit, (jer je to ID zahtjeva, što znači novi zahtjev-novi ID), a sve ostalo ti mora biti identično kao u prvom zahtjevu.

Ovo mi je sve jasno ako račun nije prvobitno zaprimljen zbog neke greške i nije dobio JIR. Postavi se parametar za naknadno slanje na "TRUE" i sve štima.

Međutim, što napraviti u ovakvom scenariju, kada dođe do gubitaka podataka. Znači račun je uredno ispisan, poslan u poreznu upravu dobio je svoj JIR. Dogodi se nekakva havarija (npr. spaljen HDD) i izgube se određeni podaci.

Recimo da je korisnik ažuran što se tiče backupa, nakon popravka računala gdje se nalazi baza podataka vratimo nazad backup. Pretpotstavimo da korisnik ima i papirne kopije svih ispisanih računa. Od vraćenog backup-a do zadnjeg stvarnog ispisanog računa postoji "rupa" od recimo 20-tak računa.

Moje pitanje je sada što raditi sa tih 20 računa koji nisu upisani u bazu:

1.) Ručno ih prepisati redosljedom kako su i ispisivani prvi puta i ručno upisati JIR

2.) Ručno ih prepisati redosljedom kako su i ispisivani prvi puta, ali JIR ostaje prazan, ZKI ostaje isti i zatražiti ponovno JIR iz porezne uprave (u toj situaciji bi server morao prepoznati da je JIR već jednom bio dodjeljen i vratiti nazad isti JIR)

3.) Zatvoriti naplatni uređaj (poslovni prostor) zbog gubitka podataka i otvoriti novi poslovni prostor odnosno naplatni uređaj i to prijaviti u poreznu upravu

Jan 11, 2013 at 2:05 PM

Ja bi zatvorio PM, otvorio novo, prijavio i krenuo od 1.

Jan 11, 2013 at 3:38 PM

Krečeš sa sljedećim brojem naplatnog uređaja. Računi kreću od 1.

Jan 13, 2013 at 4:41 PM

Mislim da bi u slučaju slanja istog broja računa(račun id, oznaka poslovnice, oznaka nap. uređaja) porezna morala odgovoriti da je račun sa tim brojem već zaprimljen tako da bi onda mogao. posložiti bazu i račune po pravilima. Npr ako sam kod testiranja poslao 3, 4 račune. Onda bi 1, 2 poslao sa naknadnom dostavom true i stavio vrijednost računa 0 (bez artikla) te nakon toga krenuo od računa br 5 i sve bi štimalo. A sada pitaj boga šta je zaprimljeno kod porezne jer mi nije radilo kod prebacivanja sa demo na produkciju pa sam testirao sa produkcijom i poslao nekoliko računa bezveze i onda krenuo od računa br. 1. sve ispočetka Sada teoretski inspekcija može doći kad god i pronađe da mi ne štima kasa te plačam kaznu, a ja bi naravno uredno platio porez i sve kako sam prijavio račune, ali neznam šta je prijavljeno.

Komentari?

Jan 16, 2013 at 8:15 PM
mladenbabic wrote:

smijes poslati isti račun više puta. ali ISTI račun.

naime, u scenariju kada klijentska aplikacija pošalje request, koji se upiše u CIS, ali veza pukne na response-u, čime klijentska aplikacija ne dobije JIR, moguće je, i potpuno legitimno, da aplikacija ponovno pošalje isti zahtjev kako bi dobila JIR. Niti CIS ne zna da response nije stigao do clienta.

Aplikacija u tom trenutku niti ne zna da račun već postoji u bazi CISa, a CIS će takav dupli record tretirati kao jedan zapis, odnosno "gledati će" samo noviji insert u bazi. Samo ti je uniqueID (uuid) tog requesta različit, (jer je to ID zahtjeva, što znači novi zahtjev-novi ID), a sve ostalo ti mora biti identično kao u prvom zahtjevu.

Mladen, sta ako imamo problem na racunu gdje se javila razlika u PNP-u, sve ostalo je ok... jel se takav racun salje ponovo isti (ispravljen iznos pnp-a) ili se radi storno i prijavljuje novi?

Jan 16, 2013 at 11:13 PM

@krunof, ja bih napravio onako kako ti sugerira kolega @drumisek. znači novi naplatni uređaj, računi od broja 1 na razini naplatnog uređaja i ne zaboraviti popravak u "aktu".

@fico7489, porezna, odnosno CIS, ne radi nikakvu validaciju primljenog zahtjeva. za to nema dovoljno resourca a niti ima takve potrebe.  ja uz račune evidentiram i flag koji mi govori o kojoj se vrsti servera radilo prilikom kreiranja i fiskalizacije tog računa. na taj način mogu prepoznati prave od onih drugih JIRova.

@mirkofodor, a trebao bi napraviti novi račun s identičnim "storno" iznosima, a zatim posebno fiskalizirati i novi a ispravan račun.  sve to naravno s novim, dakle aktualnim datumima koji odgovaraju datumu "uočavanja pogreške". 

Jan 17, 2013 at 10:44 PM
mladenbabic wrote:

@krunof, ja bih napravio onako kako ti sugerira kolega @drumisek. znači novi naplatni uređaj, računi od broja 1 na razini naplatnog uređaja i ne zaboraviti popravak u "aktu".

@fico7489, porezna, odnosno CIS, ne radi nikakvu validaciju primljenog zahtjeva. za to nema dovoljno resourca a niti ima takve potrebe.  ja uz račune evidentiram i flag koji mi govori o kojoj se vrsti servera radilo prilikom kreiranja i fiskalizacije tog računa. na taj način mogu prepoznati prave od onih drugih JIRova.

@mirkofodor, a trebao bi napraviti novi račun s identičnim "storno" iznosima, a zatim posebno fiskalizirati i novi a ispravan račun.  sve to naravno s novim, dakle aktualnim datumima koji odgovaraju datumu "uočavanja pogreške". 

Najlakše je reći nema resursa i potrebe za tim, vlada je namjerno dala da se fiskalizacija mora provesti na način kakav jest jer se prema njihovim riječima tako razvijaju informatičke firme i to je istina, ali i to znači da je svatko mogao napraviti rješenje, a ne samo kvalitetne firme sa iskustvom i vrlo je vjerojatno da će dosta toga biti napravljeno nespretno, pa se ne može samo tako reći da ne nije bila potrebna validacija! Mogli su barem napraviti da se može dobiti ispis prijavljenih računa makar da se plati. Recimo da je na serveru uz svaki certifikat i radno mjesto zapisan sljedeći broj koji se očekuje i ako prijaviš nešto drugo on ti vrati grešku to je jedna if provjera. Jer ako krivo definiraš poreze, cijenu, plačanje itd. to se da riješiti storniranjem, a za ove račune prijavljivane preskokce ili prijavljivani i nezabilježeni tijekom testiranja produkcije se ne mogu nikako riješiti.

Jan 18, 2013 at 8:40 AM
Edited Jan 18, 2013 at 8:41 AM

fico7489, software je u produkciji, i do sada, znači bez ikakve fiskalizacije, MORAO osigurati ispravan rad. i do sada je, npr.  rekapitulacija prometa prijavljivala tamo neki PDV a temeljem kojega se u konačnici i generirala obveza poreza. dakle i do sada je to bilo prilično odgovoran posao. do sada smo znači radili validaciju samih sebe. i ako nešto nije bilo ok, plaćale su se kazne. dakle, općenito - svatko mora odgovorno stajati iza svog posla. ne vidim zašto bi baš sada validaciju očekivao od nekog drugog, npr. od CISa?

Coordinator
Jan 18, 2013 at 8:45 AM
Edited Jan 18, 2013 at 8:47 AM

Ma kakva validacija od strane back-enda... Nije APIS-IT od jučer.. 
Recimo, ja s njima radim nekih 6-7 godina. Rade arhiviranje nekih digitalnih arhiva Komora za koje radim.
Kada je krenuo pravilnik o arhivskoj građi (da ne davim glupostima sad), ista je frka bila - evo vama xsd shema pa vi nama šaljite podatke tako i tako.. Apsolutno ista priča je bila kao sa fiskalizacijom, ali nije bilo toliko razvikano. Do dana današnjeg, kakvi su bili njihovi web servisi za pozivanje arhiviranja predmeta, takvi su i danas. Nikakve kontrole i povratne informacije. Što i je u redu. Da sam ja gazda backenda, odnosno onoga što stoji iza CIS-a, također ne bih radio nikakvu validaciju - dobili ste shemu, izvolite raditi po njoj. Prilagodi se ili umri...

Dec 20, 2014 at 11:43 AM
Pozdrav svima,
ja vam nisam dev ali bih molio odgovor ako je moguće.

Da li fiskal na androidu ima neku svoju bazu gdje sve zapisuje, ili je samo jedna korisnička?
Ako se zaboravi par dana zaboravi napraviti backup a nešta se dogodi s korisničkom bazom možeš si sjesti i plakati, pogotovo jer nemam naviku svaki dan poslije cijelog dana maltretiranja sa strankama sjediti i prepisivati račune u knjigu prometa.

Uglavnom, napravio sam glupost, tablet je krenuo brojati od jedinice i još sto drugih problema da ne zamaram, uglavnom da li se nešta da uzvući van iz tog androida osim te baze koja se backupira?
Ivan
Dec 20, 2014 at 4:13 PM
Najčešće nije moguće, ako si obrisao račune. Ali o tome bi trebao pričati sa programerom. Zašto bi prepisivao račune u knjigu prometa? Kako si napravio da opet krenu od 1? Prijenos u novu godinu, ili? Jer možda su računi još uvijek "tamo negdje". U svakom slučaju, zovi svog programera.
Dec 22, 2014 at 12:11 PM
dkustec wrote:
Ma kakva validacija od strane back-enda... Nije APIS-IT od jučer..&nbsp
Slažem se, kontrolirati nešto znači i imati odgovornost. Evo priče od prije 3-4 godine, ako nekog zanima.
Čovjek odnese virman u Finu i ostavi ga na šalteru. Plaća ratu kredita sa ozbiljnim iznosom. Na broju računa za uplatu pogrešno upiše jednu brojku. Ko' za vraga taj račun postoji! Ko' za vraga ta firma je u debeloj blokadi! Za nekoliko dana zove banka i vrišti gdje je rata kredita. Tek tad je shvatio šta se dogodilo.
Dogovorno je sa Finom podijelio trošak jer je na virmanu ispravno napisao naziv firme (banke) kome plaća, a Fina je to bila dužna kontrolirati kod unosa virmana u računalni sustav.
Dec 22, 2014 at 1:28 PM
OK, ne moraju validirati oni, ali neka daju neki pristup informacijama da se barem na većem uzorku može provjeriti da li sve štima.