Razlika u sumi fiskaliziranih računa i izvještaja iz kase/PDV obrasca

Jun 29 at 8:04 AM
Edited Jun 29 at 8:05 AM
Neki dan su me zvali iz PU da se ukupna suma fiskaliziranih računa za 2015tu godinu ne podudara sa iznosom na PDV obrascu.

Razlika je poprilično velika, a ja sam uvjeren da je s moje strane sve u redu. Fiskalizacija definitivno uredno radi i izvještaji iz kasa se podudaraju sa PDV obrascem.
Problem je u tome da ovi iz PU daju jako šture informacije pa ne mogu napraviti usporedbu za recimo samo jedan mjesec i jednu kasu, samo su dali ukupan iznos za cijelu godinu.

Jel itko imao sličan problem i jel uspio dobiti detaljniji opis problema? Možda listu fiskaliziranih računa za 1 mjesec?
Jun 29 at 9:22 AM
Jedino što smo mi uspjeli dobiti je iznos razlike.

Pripremili smo izvještaj fiskaliziranih računa, provjerili da se naši podaci u bazi podudaraju sa xml zahtjevima i odgovorima i proslijedili u računovodstvo, koje je dalje to rješavalo.

Prvu godinu smo imali slučaj da je do razlike došlo zbog toga jer je korisnik fiskalizirao sve račune (gotovinske i transakcijske), a budući da je obrtnik, transakcijske račune je obračunavao po naplaćenoj realizaciji, što znači da nenaplaćene IRE nisu ušle u PDV obrasce, i to je bila točno ta razlika.

Znači, ako ne fiskaliziraš transakcijske, provjeri što imaš u poslanim xml zahtjevima i podudara li se to sa tvojim izvještajima iz baze.
Jun 29 at 9:26 AM
Taj dio je provjeren i što se tiće programa i fiskalizacije sve funkcionira. Transakcijski se ne fiskaliziraju.

Budem probao i sam, ali da li je moguće da račun sa istim ZKIom prođe dva ili više puta postupak fiskalizacije, odnosno da isti ZKI ime dodjeljen više razlićitih JIRa.
Pretpostavljam da bi CIS odbio zahtjev za računom sa istim ZKIom?
Jun 29 at 9:29 AM
Edited Jun 29 at 9:32 AM
kish89 wrote:
ali da li je moguće da račun sa istim ZKIom prođe dva ili više puta postupak fiskalizacije, odnosno da isti ZKI ime dodjeljen više razlićitih JIRa.
Pretpostavljam da bi CIS odbio zahtjev za računom sa istim ZKIom?
Isti račun sa istim ZKI-em može biti poslan više puta, ali 2. i svaki sljedeći put mora imati oznaku naknadne dostave. Možda da to provjeriš. CIS ga ne bi odbio, baš zbog mogućnosti naknadne fiskalizacije.
Jun 29 at 9:31 AM
Da upravo isprobano i uredno prolazi račun sa istim ZKIom isvaki puta dobije novi JIR.
Ništa, vidjet ću možda tu negdje postoji greška.
Hvala.
Jun 29 at 9:35 AM
Pogledaj u drugom slanju tog računa, je li ti u polju NaknDost vrijednost true. Ako nije, našao si grešku.
Jun 29 at 9:43 AM
Samo info.. čuo jesam za sličnu situaciju. Nekako je počela priča da Apis zbraja duplikacije, jako je teško reći što je točno? U načelu može se dogoditi da dva različita računa dobiju isti ZKI, ali to bi bila rijetkost i nebi stvorila razliku kao duplikacije.. čak se događa da dobiveni JIR bude jednak..
Jun 29 at 9:51 AM
Program uredno prebacuje NaknDost na true ako se radi o naknadnoj fiskalizaciji.
Samo je pitanje da li je bilo tako 2015te godine jer te vrijednosti nisu bile spremane u lokalnu bazu pa nemam mogućnost provjere.
Mada ništa nije dirano u kodu fiskalizacije od samog početka pa mi je mala vjerovatnost za to.

@VKR71 Kako apis može utjecati na dobivanje duplog ZKIa? Mislim, eventualno je moguće za JIR, ali ZKI se generira u programu, jedino ako se u apisovoj bazi nešto pošemeri pa spremi isti ZKI na dva ili više računa.
Jun 29 at 10:05 AM
kish89 wrote:
@VKR71 Kako apis može utjecati na dobivanje duplog ZKIa? Mislim, eventualno je moguće za JIR, ali ZKI se generira u programu, jedino ako se u apisovoj bazi nešto pošemeri pa spremi isti ZKI na dva ili više računa.
Naravno mi generiramo ZKI a ne Apis i može se dogoditi na velikom broju računa da je jednak isto kao što Apis nama na veliki broj računa vrati jednak JIR. To nema stvarnog utjecaja, porezi se ne zbrajaju po ZKI i JIR-u več po cjelovitim računima sa svim svojim elementima. Bilo bi dobro da nam bar po noči dozvole da pregledavamo naše testne podatke, ovako se možemo samo nervirati ako ne ubodemo baš ono što bi moglo biti.
Jun 29 at 11:48 AM
Naravno mi generiramo ZKI a ne Apis i može se dogoditi na velikom broju računa da je jednak isto kao što Apis nama na veliki broj računa vrati jednak JIR. To nema stvarnog utjecaja, porezi se ne zbrajaju po ZKI i JIR-u več po cjelovitim računima sa svim svojim elementima. Bilo bi dobro da nam bar po noči dozvole da pregledavamo naše testne podatke, ovako se možemo samo nervirati ako ne ubodemo baš ono što bi moglo biti.
Ovo ti baš i ne stoji. Ne postoji nikako način da generiraš identičan ZKI dva puta !!!
Znaju se elementi koji utječu na kreiranje ZKI-a :
  • HashMD5 (Elektronički potpis privatnim ključem (OIB+datum i vrijeme izdavanja+brojčana oznaka računa+oznaka poslovnog prostora+oznaka naplatnog uređaja+ukupni iznos računa)
Svi elementi se mogu pogoditi osim "brojčane oznake računa" - koja se generira na nivou prodajnog mjesta ( znači jedinstveni brojač za PM ) ili na nivou naplatnog uređeja.
Jun 29 at 12:26 PM
Ako softver nije dobro napisan i ako tehnologija ne podržava sve što bi trebala tada imate problem. Imate i sreću što vam Porezna to tolerira.
Meni je nezamislivo da danas netko radi fiskalizaciju u DOS-u ili Accesu i da se ozbiljno bavi ovim poslom, no vidim da vas ima.
No, bez relacione baze podataka, bez referencijalnog integriteta, ograničenja, trigera, bez transakcija nitko živ ne može garantirati da neće biti takvih problema.
Nije da vam želim nešto pametovati, ali bilo bi dobro da malo razmislite o tome.
Jun 29 at 2:46 PM
Nemoj sad pretjerivati, zasto access ne bi bio dovoljno dobar.
90% mojih korisnika ima jednu blagajnu, a takvi smo vecina ovdje na forumu. Zar da za jednu blagajnu treba imati sql server. I kao da je to sad neka komplicirana baza podataka, ista je kao i prije fiskalizacije sa par dodanih tablica ili polja.
Jun 29 at 2:56 PM
Edited Jun 29 at 2:58 PM
Stanki wrote:
No, bez relacione baze podataka, bez referencijalnog integriteta, ograničenja, trigera, bez transakcija nitko živ ne može garantirati da neće biti takvih problema.
Ovo ne postoji pod DOS sustavima?!?!?! Otkad? Sve te (dijelom ili u potpunosti) su odavno baze pod DOS-om imale. Npr, Dbase, Btrieve, itd. Ali ovo nije uopće bitno i nemojmo raspravu skretati na nevažne stvari.

Očigledno je APIS počeo (a što je davno već trebao) kontrolirati što mu šaljemo i kroz porezne uprave nas obavještavati o "bugovima" u programima. Obzirom da (valjda???) na ovom forumu većina koristi Raverus komponente za fiskalizaciju, pojavljuje se pitanje gdje su bugovi? U našim programima, u Raverus kodu, u Fiski (koju ja koristim) u nekompatibilnosti (bolje reći problematičnosti) DOS/Windows komunikacije ili je nešto deseto u pitanju. Na to se treba fokusirati, a ne na rasprave tipa "može li DOS i ostali relikti prošlosti raditi fiskalizaciju."

I ja sam počeo dobijati različite poruke od knjigovođa mojih korisnika sa raznim problemima (manje vrijeme slanja od izdavanja, zaokruživanje na 1 lp, ali i različite osnovice za periode. Pokušavam skužiti gdje je problem, imam XML-ove i kopam po njima. Čini mi se da je problem u ponovo poslanim računima, ali ne mogu još odgonetnutni točno zašto i kako, jer ima više različitih varijanti, koje ne mogu svesti na brojke koje imaju smisla s onime što prijavljuje kasa i PU. Možda su korisnici pronašli neki način da ometaju rad kase, a ja to ne kužim, iako mi je to prilično nemoguća situacija (ali nikad se ne zna što će budali pasti na pamet).

Bilo bi dobro kad bismo mogli saznati da li se (i koje) greške dešavaju kod onih koji ne koriste Raverus. Recimo, ima li sličnih problema kod Fiskal1 kasa? Ja kontaktiram s nekim korisnicima koji ne koriste Raverus, a imaju dopise od PU (svakakve).
Jun 29 at 3:38 PM
Edited Jun 29 at 3:53 PM
@Georgija47:
Bila si brža! I u pravu si.

@Stanki:
Odmah na početku, nemoj, molim, ništa zamjeriti.
Nisam siguran što si htio reći u one dvije rečenice u kojima spominješ DOS i relacione (relacijske) baze, integritet, transakcije... - Da li je to bilo u smislu "to su bile igračke"?
Za pod DOS-om postoje i neke vrlo ozbiljne baze koje nekim svojim (praktično korisnim) mogućnostima nadilaze neke današne produkte, a da o integritetu podataka i ne govorim.
A za samostalne kase, kako kaže Georgija47, stvarno ne treba nešto za što svaka 4 dana dolazi sigurnosna zakrpa i ima Sintaksu.Za.Koju.TrebašDoktorat&Prevoditelja(DaBi@Baza.NašlaPodatakKojiTiJeNeki_DrugiTaskPromijenioPrijeNegoŠtoSiOčekivaoPaTiSeNeštoZmeša,jerboBUG=true). (pa se nešto pravi pametno i shvati ovo kao mail adresu)
A što se razmišljanja tiče, budi siguran da smo dobro razmislili, i shvatili da nam procesor u glavi svakom danom radi na sve nižem clocku, dok okolnosti traže sve više. Fiskalizuacije po DOS-mo ne radimo, nego održavamo u živoru, silom prilika.
Pa ti razmisli koliko ćeš nakon još 20-tak ili više godina istraživati nove alate. Želim ti svaku sreću. Trebat će ti.
Jun 29 at 3:57 PM
Edited Jun 29 at 3:58 PM
gmacarol, daj da rješavamo probleme, ovo flejmanje ničemu ne vodi, osim da ljude odvraća od čitanja zbog mase nebitnih postova (kao što je i ovaj moj).
Jun 29 at 3:58 PM
gmacarol wrote:
@Georgija47:
Bila si brža! I u pravu si.

Brža?!
Georgia kao drzava u SAD, a ne kao zenski George :)
Jun 29 at 6:13 PM
Edited Jun 29 at 11:50 PM
kish89 wrote:
Jel itko imao sličan problem i jel uspio dobiti detaljniji opis problema? Možda listu fiskaliziranih računa za 1 mjesec?
Ne da im se raditi jer im je sustav toliko spor i šteka da je to užasno - uvjerio sam se u to jer sam i osobno vidio uživo. In case - Još u početku fiskalizacije, dobio sam izlistanje prometa sa iznosima poreza razvrstanim po stopama za svaki dan na posebnom papiru za cijeli jedan mjesec. Pokušaj samo na lijepi način zamoliti i nemoj doći naravno pred njihov kraj radnog vremena nego po mogućnosti što ranije. Listu fiskaliziranih računa, pogotovo za cijeli mjesec nema šanse da dobiješ. Kontam da bi im za to trebalo 2 mjeseca. ;D
EDIT: Jedino ako to odradi APIS pošto oni imaju direktan pristup serveru, ovi iz porezne to rade putem neta a to je sporo.

GoranV13 wrote:
Ne postoji nikako način da generiraš identičan ZKI dva puta !!!
Znaju se elementi koji utječu na kreiranje ZKI-a...
GoranV13 je sve objasnio. Pošto se za ZKI veže vrijeme izdavanja (sat:minuta:sekunda) ali i brojčana oznaka pa sve ostalo..., nemoguće je kreirati 2 ista ZKI-a.
Sve u svemu, ne mogu vjerovati da u 2016.toj još uvijek moramo pisati o tome kako se kreira ZKI. :S

Mogu se okladiti da se ljudima događaju problemi brkanja pojmova koji su povezani sa vremenom izdavanja i vremenom slanja, ili kod naknadnog slanja i eventualno (možda netko ne zapisuje kod prvog kreiranja) ponovnog kreiranja ZKI-a. ZKI za račun je uvijek isti, em što i mora zakonski ostat isti, em je i formula takva da se svakim izračunom uvijek dobije isti.


Stanki wrote:
...Accesu i da se ozbiljno bavi ovim poslom...
Bullshit.
Jun 29 at 6:40 PM
@Georgia47: Sorry. J previše. Događa se i najboljima :)
Brža?! - Brži (u reakciji na Stankijev post)

@viggor:
OK, ajmo sa problemima

Kod mene 45 DOS aplikacija pod XP-om, koristim EXE.
  • Imao sam samo jednog korisnika kojem je PU prigovorila, i to za 19 računa iz cijele 2015-te, kod kojih je, navodno, vrijeme slanja manje od izdavanja, s time da su za primjer naveli JIR samo jednog od tih računa. U lokalnoj arhivi, na tom računu nepravilnost ne postoji. Postavlja se pitanje kako i odakle čupaju ta, navodno, neispravna vremena, i zašto ne daju konkretne podatke kako bismo imali što tražiti. Nije valjda da oni čitaju vrijeme primitka računa po svom lokalnom vremenu, a ne podatke iz XML-a? Da li je to netko utvrdio?
    Malo filozofiranja: Regularno, ne možemo izdati račun bez JIR-a, dakle, moramo ga prvo poslati, primiti odgovor, pa ga tek onda izdati. I što se onda bune?
  • Isti korisnik se malo zaigrao s normativima, "natezao" je škropec na okruglu cijenu i pritom "nategnuo" zaokruživanje osnovice vina i vode u +1 Lp, a poreza u -1 Lp, pa se uz ostala malo gore/malo dole zaokruživanja tijekom 2015-te nakupilo 7,68 Kn razlike. Riješeno dopisom u PU uz ispriku i ispravak normativa.
  • Pročešljao sam arhive nekoliko korisnika i nisam našao duple JIR-ove. Da sam ih našao, zabrinuo bih se, jer bi (J)edinstveni (I)dentifikator (R)ačuna trebao biti jedinstven. Ako se nekom pojavljuju dupli JIR-ovi, neka proanalizira nije li to posljedica izčitavanja odgovora prije nego što je odgovor došao, tj. možda u varijabli (ili datoteci odgovora) još stoji JIR prethodnog računa. Ja prilikom čitanja odgovora provjerim da li u odgovoru imam UUID za koji čekam JIR.
  • Na jednom računalu (second hand sa pred-instaliranim "refubrished" XP-om) primijećeno je da povremeno (pod neutvrđenim okolnostima) DOS-vrijeme ne prati XP-vrijeme. DOS vrijeme je naprosto stalo, a opet se uskladilo izlaskom/ulaskom u program (full screen). Riješeno re-instalacijom XP-a (ista verzija, isti SP3, isti driveri...). PU do sada nije reagirala, valjda im je izgledalo kao da izdani račun putuje sat-dva do njih, pa se ne bune da je poslan prije nego je izdan.
Da rezimiram:
Dajem ruku u vatru da Raverus EXE ne pati od BUG-ova. Čvrsto vjerujem da su i COM/DLL i ostale varijante također OK.
Mislim da je problem u samim aplikacijama - u nedostatnoj kontroli procesa od početka unosa preko šaljem/primam do izdavanja tj. arhiviranja računa.
Osim toga, na neke okolnosti ne možemo programski utjecati. Primjer (jedan od više mogućih scenarija):
Nakucamo račun, složimo XML, pošaljemo, zvekne struja. Struja došla, aplikacija kreće, nalazi zadnji račun bez JIR-a, ide provjeriti postoji li XML-zahtjev i XML-odgovor (po UUID-u). Nađe zahtjev ali nema odgovor. Zahtjev poslan ili nije?? Odgovor nije došao ili je došao pa samo nije stigao doći do diska (visio u cashu)??. Program zaključuje da račun treba slati ponovo (naknadno slanje, ručno od strane korisnika, u petlji automatski - nije bitno). PU ga već ima jer je onaj prvi zahtjev prošao. Oni (imam dojam) mehanički zbroje sve što imaju i evo razlike između fiskalizacije i obračuna PDV-a.
I da, trebalo bi nekako utjecati na APIS/PU da informacije ne daju samo na kapaljku. Osim ako im osnovna misao nije punjenje proračuna kroz kazne :(
Jun 29 at 9:19 PM
Samo napomena za koju sam 100% siguran. Možete jedan te isti račun slati 50 puta (uzmimo primjer da je 100kn iznos), on će dobiti 50 različitih JIR-ova, kod njih u poreznoj če se taj račun vidjeti 50 puta ALI kada u poreznoj zatraže neki svoj interni upit taj račun če se SAMO JEDNOM obračunati, tj. iznos če biti 100kn.
Jun 29 at 10:17 PM
Edited Jun 29 at 10:58 PM
Ovako, kod mene se na jednom certifikatu koriste trenutno 4 kase (na razini naplatnog uređaja). Išao sam tražiti duplikate ZKIa, prošao sam samo dvije kase, na jednoj ima oko 30 a na drugoj oko 50 duplikata.
Zanimljivost je da većina tih duplića je sljedeći ZKI "d41d8cd98f00b204e9800998ecf8427e" , dakle na obje kase isti ZKI.
Ako ima netko uvid u koju bazu, bio bih zahvalan ako može potražiti taj ZKI, da li je moguće da postoji kakav bug kod generiranja?
Vjerovatno je problem u mojem kodu, u svakom slucaju zanimljivo.

btw. znam da su šanse male/nemoguće, ali ako tko ima minutu neka provjeri
Jun 29 at 11:43 PM
Edited Jun 30 at 12:03 AM
Napisao sam poprilično velik post, ali gle vraga, kliknem save i pukla veza sa codeplexom, a naravno moj post ode u maglu. -.-'
Ide ponovljena ali ovaj puta skraćena verzija;

In case: CIS sprema uvijek ZADNJI račun i eliminira postojeći jedino UKOLIKO SU SVI PARAMETRI RAČUNA POSLANI ISTI. Dakle jedan račun koji je fiskaliziran možeš još fiskalizirati bezbroj puta, JIR će biti drugačiji ali provjera putem ZKI-a uvijek prolazi. (Slučaj gdje ako račun sa JIR-om koji je uzeo kupac ponovo naknadno fiskaliziraš xy puta i dobiješ drugi JIR, online ZKI provjera UVIJEK mora proći jer se ZKI u osnovi nije mjenjao, kao i ništa drugo sa računa.) I da, naravno da će račun biti vidljiv samo kao jedan, iako je poslan npr 500 puta. Da skratim priču, prošao zahtjev, ne prošao, isti račun poslan više puta identičnim parametrima snima se kao jedan.

@Kish89: Ne znam koji alat za izradu software-a koristiš ali bug je 100% kog tebe i to kod funkcije koja kreira ZKI. Bug kod generiranja od strane Raverusa ne postoji, jer bi to svi već do sada primjetili. Ali gotovo sam siguran da postoji kod tvojih parametara s kojima ga generiraš ili gdje koristiš tu funkciju. Možda se kod kreiranja ZKI-a povlače neki parametri koji su ostali od prethodnog računa...to mi je prvo palo na pamet. Svojom voljom naravno možeš napraviti (a i nitko te ne tjera da se razumijemo) copy/paste cijele funkcije za kreiranje ZKI-a, pa će ti netko pomoći, ako to već ne budem mogao ja.

Isti slučaj je već imao jedan korisnik ovdje koji se isto ovako javio kao i ti za pomoć, i nakon što sam mu dao prijedlog da nam pokaže svoju funkciju, nije želio, niti se više ikad javio, ni pozdrav, ni hvala, ni A, ni B, ništa. Mislim si, svi mi programeri ovdje smo željni nečije funkcije koja ima bug i nitko od nas još nema ispravno implementiranu fiskalizaciju pa ćemo "ukrasti taj dio codea" za svoju aplikaciju i zaraditi milijune...svakakvih ljudi na ovom svijetu, stvarno. =)
Jun 30 at 1:46 AM
kish89 wrote:
Zanimljivost je da većina tih duplića je sljedeći ZKI "d41d8cd98f00b204e9800998ecf8427e" , dakle na obje kase isti ZKI.
Nisam pronašao taj ZKI među 300.000 računa

Da demistificiramo ponavljenje ZKI-ja.
ZKI i JIR se MOGU ponoviti premda za to postoji vrlo mala mogućnost. Nisu bitni ulazni parametri u HashMD5 algoritmu nego rezultantni broj koji je dužine 32 hexadecimalna broja.
Pretpostavimo da neki algoritam daje za rezultat 2 hexadecimalna broja....
Jun 30 at 5:46 AM
DejanK wrote:
Napisao sam poprilično velik post, ali gle vraga, kliknem save i pukla veza sa codeplexom, a naravno moj post ode u maglu. -.-'
Ide ponovljena ali ovaj puta skraćena verzija;

In case: CIS sprema uvijek ZADNJI račun i eliminira postojeći jedino UKOLIKO SU SVI PARAMETRI RAČUNA POSLANI ISTI. Dakle jedan račun koji je fiskaliziran možeš još fiskalizirati bezbroj puta, JIR će biti drugačiji ali provjera putem ZKI-a uvijek prolazi. (Slučaj gdje ako račun sa JIR-om koji je uzeo kupac ponovo naknadno fiskaliziraš xy puta i dobiješ drugi JIR, online ZKI provjera UVIJEK mora proći jer se ZKI u osnovi nije mjenjao, kao i ništa drugo sa računa.) I da, naravno da će račun biti vidljiv samo kao jedan, iako je poslan npr 500 puta. Da skratim priču, prošao zahtjev, ne prošao, isti račun poslan više puta identičnim parametrima snima se kao jedan.

@Kish89: Ne znam koji alat za izradu software-a koristiš ali bug je 100% kog tebe i to kod funkcije koja kreira ZKI. Bug kod generiranja od strane Raverusa ne postoji, jer bi to svi već do sada primjetili. Ali gotovo sam siguran da postoji kod tvojih parametara s kojima ga generiraš ili gdje koristiš tu funkciju. Možda se kod kreiranja ZKI-a povlače neki parametri koji su ostali od prethodnog računa...to mi je prvo palo na pamet. Svojom voljom naravno možeš napraviti (a i nitko te ne tjera da se razumijemo) copy/paste cijele funkcije za kreiranje ZKI-a, pa će ti netko pomoći, ako to već ne budem mogao ja.

Isti slučaj je već imao jedan korisnik ovdje koji se isto ovako javio kao i ti za pomoć, i nakon što sam mu dao prijedlog da nam pokaže svoju funkciju, nije želio, niti se više ikad javio, ni pozdrav, ni hvala, ni A, ni B, ništa. Mislim si, svi mi programeri ovdje smo željni nečije funkcije koja ima bug i nitko od nas još nema ispravno implementiranu fiskalizaciju pa ćemo "ukrasti taj dio codea" za svoju aplikaciju i zaraditi milijune...svakakvih ljudi na ovom svijetu, stvarno. =)
Ovdje sam se javio za pomoć jer su se meni(mom knjigovodstvu) kao krajnjem korisniku softwarea javili iz PU da mi se na poklapaju iznosi fiskalizacije i onaj s PDV obrasca. U nastojanju da riješim taj problem zatražio sam pomoć na više mjesta.
Ja sam i sam ITovac, doduše u drugoj branši (mreže), ali nije mi strano ni programiranje.
Naravno, prvo sam prošao kompletnu proceduru fiskalizacije sa autorom programa, i zaključili smo da nisu postojale ni najmanje šanse da su se zabunom fiskalizirali transakcijski računi i/ili da se neki računi više puta fiskaliziraju.
Ali s obzirom da si ti (i još netko ako se ne varam) ovdje napomenuli da PU ne zbraja račune sa istim parametrima, odbacio sam mogućnost da mi je zbog toga došlo do razlike u iznosima. I naravno zahvaljujem se zbog toga kao i ostalih "tip-ova".

Nisam siguran da li se smije ovdje raditi "reklama" za software, pa neću ulaziti u detalje. Program koji ja koristim je napravio čovjek iz BiH, i kako sam taj program koristio i prije fiskalizacije, čovjek je praktički samo radi mene napisao dodatni dio koda jer se program ne distributira u HR.
Jedina greška koju smo našli je bila ova sa duplim ZKIom, koja je jučer ujedno i popravljena. Greška je bila u generiranju ZKIa (što ste i sami mogli zaključiti), a ja mogu pitati autora programa da li je voljan podjeliti dio koda gdje je došlo do greške ako se nekome dešava ista stvar.
Jun 30 at 7:32 AM
Meni se čini da smo se svi pomirili s time da ćemo i ubuduće pitati babu Vangu ili ako tko sam zna bacati grah i čitati ga kadgod nam porezna pošalje štura upozorenja tipa 'nešto vam ne valja pa vi vidite što', ne očekujući da oni ikad poduzmu nešto da do takvih grešaka ne dođe.
CIS ima vremena za svaki za svaki zahtjev za JIR-om provjeriti ispravnost strukture xml-a, te da li je potpisan pripadajućim certifikatom prema OIB-u.
Moja laička procjena je da je to dosta zahtjevnije nego provjeriti je li zbroj poreza i osnovica u njemu jednak iznosu, te da li je vrijeme slanja manje od izdavanja, pa da slične banalne provjerice ugrade u sustav, to bi neznatno povećalo vrijeme obrade pojedinog zahtjeva.
U tom slučaju, ako bi CIS odbijao dodjelu JIR-a sa nekom smislenom povratnom greškom, već u prvoj godini fiskalizacije bismo svi detektirali i pokrpali bugove.
Ovako, gledajući bijelo u greške računa od prije godinu dana, prvo što se pitam je da li su svi računi poslani prije 2015. ispravni pa sam sad nešto sjebao prošle godine?
A i u ovih godinu dana sam štošta prčkao po programu pa se možda greške više ne ponavljaju?

I još nešto: ne znam kako vama, ali meni ih je par prijavilo grešku fiskalizacije nakon 78 sati od izdavanja. Nije li zakonski rok 48 sati?
Pretpostavljam da je nekom pobjegao prstić sa četvorke na sedmicu na num tipkovnici, pa su poreznicima poslali šprancu opomena s tipfelerom :)
Jun 30 at 8:47 AM
Edited Jun 30 at 8:52 AM
Da pridonesem temi i iznesem dvije važne situacije kada porezna javlja da se ne poklapa iznos:
  1. Korisnik fiskalizira virmanske račune, a u PDV obrazcu prijavjuje samo naplaćene račune - RAZLIKA NASTAJE
    Isto tako korisnik ne fiskalizira transakcijeske račune,a u PDV obrazcu prijavjuje naplaćene virmanske račune - RAZLIKA NASTAJE
  2. Korisnik ima naplatu karticom na rate, a u PDV obrazcu prijavljuje samo naplaćeni mjesećni dio - RAZLIKA NASTAJE
Onaj stari problem kod ugostitelja koji rade preko ponoci zadnji dan u mjesecu:
subota radno vrijeme do 03:00 u jutro, zadnji dan mjeseca....cijeli promet knjigovoda prijavljuje u mjesec. Razlika evientna, ali se poklapa u dva mjeseca za redom ako je to jedini takav dan u ta dva mjeseca.

mozda nekome pomogne
Jun 30 at 8:58 AM
Vrlo dobro znam kakvih problema imate, jer sam i sam migrirao sa DOS/Clipper/DBF na SQL Server i Delphi.
Tvrdim da ta tehnologija ne može garantirati integritet podataka, kao i spriječiti ovakve greške o kojima pišete.
Svakako razgovarajte i probajte smanjiti probleme, no nikada nećete biti 100% sigurni da je sve ok.
Molio bi da ne replicirate na ovaj post, jer ovo nije mjesto za to i to nema smisla.
Jun 30 at 9:04 AM
Ako je iznos fiskaliziranih računa veći od prijavljenoga bilo bi dobro i važno naći tu bubu. Možda bi trebali zamoliti Apis da napravi ispis svih računa za spornu godinu, sa svim elementima računa po sljednosti. Vjerujem da bi tako buba bila izvađena..
Jun 30 at 9:04 AM
Edited Jun 30 at 9:06 AM
markoveic wrote:
  1. Korisnik fiskalizira virmanske račune, a u PDV obrazcu prijavjuje samo naplaćene račune - RAZLIKA NASTAJE
    Je, u pravu si. Fiskaliziraj samo gotovinske račune.
Isto tako korisnik ne fiskalizira transakcijeske račune,a u PDV obrazcu prijavjuje naplaćene virmanske račune - RAZLIKA NASTAJE
To nije sporno. Većina korisnika ima i transakcijske prihode. PU se buni samo ako je PDV kroz fiskalizaciju veći od PDV-a u poreznoj prijavi.
  1. Korisnik ima naplatu karticom na rate, a u PDV obrazcu prijavljuje samo naplaćeni mjesećni dio - RAZLIKA NASTAJE
    Je, ako se tako knjiži tada je to zaista problem.
Onaj stari problem kod ugostitelja koji rade preko ponoci zadnji dan u mjesecu:
subota radno vrijeme do 03:00 u jutro, zadnji dan mjeseca....cijeli promet knjigovoda prijavljuje u mjesec. Razlika evientna, ali se poklapa u dva mjeseca za redom ako je to jedini takav dan u ta dva mjeseca.

__Istina. Jedino rješenje je objašnjenje koje se šalje u PU u takvim slučajevima. Imao sam toga.
No, bitno je zabraniti da se na kraju godine to ne dogodi, dakle, svi koje rade 31.12 na 1.1 jer onda imate gadnih problema sa dokazivanjem.
__
Jun 30 at 11:10 AM
Edited Jun 30 at 11:11 AM
u vezi fiskalizaranja samo gotovinskih računa.

moj stav je da je bolje fiskalizirati sve račune, nego razmišljati (a i programirati) o tome da li nešto fiskalizirati ili ne. Tehnička specifikacija navodi šifre za načine plaćanja i prema tome dozvoljeno je sve slati u poreznu.

G – gotovina
K – kartice
C – ček
T – transakcijski račun
O – ostalo
U slučaju više načina plaćanja po jednom
računu, isto je potrebno prijaviti pod
'Ostalo'.
Za sve načine plaćanja koji nisu prije
navedeni koristiti će se oznaka ‘Ostalo’.

ako program može (a mora moći) generirati izvještaj dnevnog prometa po načinu plaćanja, na knjigovođi je da to evidentira na ispravan način po raznim obrascima. naravno, osim u slučaju kada to radi program. a onda je ipak na programeru da vodi računa da se sve ispravno evidentira.
Jun 30 at 11:22 AM
viggor wrote:
Čini mi se da je problem u ponovo poslanim računima, ali ne mogu još odgonetnutni točno zašto i kako, jer ima više različitih varijanti, koje ne mogu svesti na brojke koje imaju smisla s onime što prijavljuje kasa i PU. Možda su korisnici pronašli neki način da ometaju rad kase, a ja to ne kužim, iako mi je to prilično nemoguća situacija (ali nikad se ne zna što će budali pasti na pamet).

Slažem se. Da pokušam rezimirati moguće greške:
  • fiskaliziraju se transakcijski računi koji nisu plaćeni (to se lako otkrije i zatim otkloni)
  • računi izdani poslije pola noći, na zadnji dan u mjesecu, prijave se u prethodni mjesec (PU zna za ovo i zato gledaju PDV za cijelu godinu. Provjereno)
  • kod ponovnog slanja istog računa, Apis to gleda kao 2 računa (NE VJERUJEM U OVO)
  • kod ponovnog slanja istog računa (isti broj računa!), a različitim podacima, Apis to gleda kao 2 računa. OVO MI SE ČINI ITEKAKO VJEROJATNIM.
Zadnji slučaj treba još izanalizirati.
Jun 30 at 11:26 AM
kish89 wrote:
Razlika je poprilično velika, a ja sam uvjeren da je s moje strane sve u redu. Fiskalizacija definitivno uredno radi i izvještaji iz kasa se podudaraju sa PDV obrascem.
Bilo bi dobro znati o kojoj se bazi podataka radi i kolika su opterećenja odnosno koliko se maksimalno izdaje računa. Također bi bilo dobro znati da li je ugostiteljstvo ili neka druga djelatnost.. kao i cca postotak razlike (+) ili (-)..
Jun 30 at 11:43 AM
Damir, možeš objasniti što znači 'slanje istog računa sa različitim podacima'? To bi trebalo biti nemoguće.
Jun 30 at 1:45 PM
Stanki wrote:
Damir, možeš objasniti što znači 'slanje istog računa sa različitim podacima'? To bi trebalo biti nemoguće.
Slažem se da bi trebalo biti nemoguće, ali ima puno postova iz kojih je vidljivo da se to događa. Recimo https://fiskalizacija.codeplex.com/discussions/445921 gdje se u 1. postu spominje "višak" računa, ali problem će biti i "višak" PDV-a.

O nemogućoj situaciji mogu samo naglas razmišljati. Naša pogreška u programu "naknadna fiskalizacija".

Ukoliko programsko rješenje omogućava promjenu prethodnih računa koji nemaju JIR-a, moglo se dogoditi da je CIS zaprimio račun, ali da nije dohvaćen JIR (zbog greške na NET-u ili "pomoći" operatera).

Operater naprasno prekine fiskalizaciju (ili cijeli program), CIS je uspio zaprimiti račun, ali JIR nije upisan u bazi. Operater se vrati na račun, promjeni ga i pošalje (ili ponovo prekida). Kad ga pošalje, dohvaćeni XML će pregaziti prethodni XML (ako ga je uopće bilo), što otežava pronalazak "kvara".
Fiskalizacija se može prekinuti vađenjem kabla iz kompa, gašenjem routera, naprasnim zatvaranjem kase klikom na X, firewallom na 8449 port ili nekom drugom intuitivnom metodom.

Dvije kase fiskaliziraju sa istom config datotekom pa ih CIS vidi kao 1 kasu. Tada ima 2 računa sa brojem 1, 2 računa sa brojem 2, 2 računa sa brojem 3...

Uvjeren sam da problem leži u tome što je CIS zaprimio 2 računa sa istim brojem, a različitim sadržajem.
Jun 30 at 2:52 PM
**damir_ wrote:**
Stanki wrote:
Damir, možeš objasniti što znači 'slanje istog računa sa različitim podacima'? To bi trebalo biti nemoguće.
Uvjeren sam da problem leži u tome što je CIS zaprimio 2 računa sa istim brojem, a različitim sadržajem.
Čim su 2 računa sa različitim sadržajem, mora biti i različit ZKI (bez obzira na isti broj računa - zaboravite na "teorije urote" i istom ZKI-ju za različite podatke - u ovom svemiru nemoguće!). U komunikaciji sa bbankom sam shvatio (a logično je to što on tvrdi), da APIS ne gleda brojeve računa već mu je bitan isključivo ZKI! 2 ista računa sa različitim ZKI-jem i PU uzima u obračun oba!!!Ako je ZKI isti (to znači da je i sadržaj isti), PU, (tj. APIS) ga ne duplira (triplira/kvadriplira/itd), već uzima samo jedan u obračun. Ovu zadnju rečenicu sam potvrdio osobno usporedbom podataka iz PU i sa kase.
Jun 30 at 11:42 PM
Edited Jul 1 at 12:04 AM
**damir_ wrote:**
Uvjeren sam da problem leži u tome što je CIS zaprimio 2 računa sa istim brojem, a različitim sadržajem.
Kako je i sam rekao, greška je bila u generiranju ZKI-a.

btw. Pošto si citirao moj post gdje sam opisao svoj problem, tek mi je naknadno korisnik rekao da je pritisnio dugmic "sleep" pa sam počeo svima isključivati tu opciju u Windowsima. Isto tako sam pokušao ponoviti ishod gdje se krene fiskalizirat račun i u tom trenutku PC ode u "sleep mode", uvijek mi je račun ostao zapisan u bazi, pošto sam odredio prvo snimanje pa tek fiskalizaciju...tako da je ovo za mene misterija ali isto tako moguć ishod za dupli račun. Tko zna šta se dogodi u tom trenutku sleep modea PC-a. Trebalo bi se sve ostat u RAM-u, ali čini se da u ovom slučaju iz nekog razloga nije bilo tako...

viggor wrote:
Ako je ZKI isti (to znači da je i sadržaj isti), PU, (tj. APIS) ga ne duplira (triplira/kvadriplira/itd), već uzima samo jedan u obračun. Ovu zadnju rečenicu sam potvrdio osobno usporedbom podataka iz PU i sa kase.
Meni isto potvrđeno od strane APIS-a.
Jul 1 at 8:52 AM
Da se oglasim. Problem u mom slućaju je bio greška u programu. PNP kod fiskalzacije je svrstavao pod PDV, dok je u našim izvještajima sve bilo u redu. Zato je u PU i bila veća osnovica za PDV.
Jul 1 at 9:32 AM
Edited Jul 1 at 9:34 AM
Većinom je tako (problem u našem softveru).
Nadam se da je svima jasno da JEDAN račun mora biti jedinstven i nepromjenjiv, te stoga sa UVIJEK istim ZKI-om.
Dalje: NEMOGUĆE je da APIS primi isti račun sa istim ZKI-jem i da duplira promet.
I sad, kako to sve podesiti a da osigura prvo autentičnost zapisa, nepromjenjivost zapisa, bilo kakvu grešku u komunikaciji sa PU, pa čak i u graničnim slučajevima, kao što su nestanak napajanja, nestanak interneta, nedobivanje odgovora od APIS-a itd.
Ja bez transakcija i bez dobre baze podataka ne vidim odgovore na ova pitanja (dakle, namjera mi nije da vam popujem, nego pomognem).
Prvo, treba osigurati da se sam račun sa svim svojim elementima, znači i zaglavlje i stavke i pomoćne tablice, a možda netko koristi i kumulativne prometne tablice (kao ja), i sa obradama koje treba napraviti (npr kod mene trigeri updataju stanje zaliha u izvedenim tablicama, razdužuju proizvode po normativima itd) - dakle treba osigurati da se sve to zapiše BEZ greške. Ja NE ZNAM kako to bez transakcija napraviti. Možda netko zna? :)
Drugo, nakon zapisa podataka o računu, treba za njega osigurati nepromjenjivost i jednoznačnost (meni SQL server to omogućava, da sad ne idem u detalje).
Tada treba za račun doći do ZKI-a. Ako teoretski u toj funkciji nešto pukne, treba osigurati da se račun bez ZKI-a NE MOŽE ispisati na printer, jer to nije dozvoljeno.
Treće, treba u komunikaciji sa CIS-om doći do JIR-a, zapisati ga u bazu i ispisati račun sa svim elementima.
Pa, možda nekom ova kratka analiza pomogne.
Jul 1 at 9:41 AM
Edited Jul 1 at 9:44 AM
Evo još jedan savjet, vezan uz backup (danas sam baš dobre volje).
Čak i ja, koji gotovo apsolutno vjerujem u SQL server, zbog dodatne sigurnosti podataka o računima, prilikom zapisivanja podataka u bazu podataka generiram XML shemu za kopiju računa sa zaglavljem i stavkama. To čuvam u posebnom folderu isto kao i Zahtjeve i Odgovore APIS-a.
Taj folder mi je kod svih korisnika u CLOUD backupu.
Koristim MEGA sync, besplatan je do 50 Gb i omogućava sinhronizaciju POJEDINIH foldera.
Zašto tako?
Jednostavno, jer je ON LINE backup nemoguće napraviti, čak i kod inkrementalnih backapa je to gotovo nemoguće.
A podatke o računima od APIS-a je nemoguće dobiti.
Jul 1 at 10:07 AM
Edited Jul 1 at 10:08 AM
Stanki, sve ovo što si napisao stoji. korištenje transakcija je obvavezno. sve poslane i primljene informacije (ZKI, JIR, nazive poslanih i primljenih XML-ova) treba spemati u bazu a XML-ove u odgovarajuće foldere. baza se obavezno backupira na vanjski disk.
jedino tako je kasnije moguće analizirati podatke i tražiti greške.
i na kraju da napomenem da sve ovo kod mene radi sa access bazom u pozadini već 20 godina. prelazak na SQL server je udaljen jamo jedan klik (zamjena connection stringa).
u svakom slučaju u pravu si sa tvrdnom da obrada podataka mora biti pouzdana (privremene tabele, transakcija, ...) i sve relevantno mora biti spremljeno
Jul 1 at 12:20 PM
Edited Jul 1 at 12:21 PM
DejanK wrote:
btw. Pošto si citirao moj post gdje sam opisao svoj problem
Citirao sam post jer je zgodan reprezent problema, bez ikakvih insinuacija. Mogu se izviniti, ako treba.
Pritisak na tipku sleep baš u trenutku fiskalizacije spada u one intuitivne metode operatera koje sam gore spominjao i dobro ju je znati.

viggor wrote:
da APIS ne gleda brojeve računa već mu je bitan isključivo ZKI! 2 ista računa sa različitim ZKI-jem i PU uzima u obračun oba!!!
Rekao sam "različitim sadržajem", a bilo bi preciznije reći "različitim ZKI-jem". I ja sam uvjeren da 2 računa sa različitim ZKI-jem, PU uzima oba. To znači da uzima i dupli PDV.
Kako Apis zna da 2 računa imaju isti ili različit ZKI? Uspoređuje brojeve računa sa njihovim ZKI. Ako je isti ZKI to znači da računi imaju isti sadržaj. Tome i služi ZKI, jer bi inače morali provjeravati svaki pojedini parametar primljenog računa.
Jul 1 at 1:04 PM
Da li je moguće da Apis generira svoj ZKI za svaki račun i da ga uspoređuje sa zaprimljenim ZKI-jem? Ako nije isti, duplira PDV?
DA li Apis i Raverus koriste različite programe za izračun ZKI-ja? Naravno da se oba drže MDB5 algoritma, ali možda ponekad daju različiti rezultat?
Jul 1 at 4:34 PM
**damir_ wrote:**
Da li je moguće da Apis generira svoj ZKI za svaki račun i da ga uspoređuje sa zaprimljenim ZKI-jem? Ako nije isti, duplira PDV?
DA li Apis i Raverus koriste različite programe za izračun ZKI-ja? Naravno da se oba drže MDB5 algoritma, ali možda ponekad daju različiti rezultat?
Nije moguće, jer što će APISu ZKI? I koji ZKI, sa svojim digitalnim potpisom? ZKI je, da se ne zaboravi, dobijen digitalnim potpisivanjem pomoću korisničkog certifikata, kojeg nema NITKO osim korisnika - i ne može takav isti kreirati nitko drugi osim onoga tko ima certifikat. APIS, koliko ja znam, nema nikakve veze sa korisničkim certifikatima, već FIINA, koja ih izdaje, a pretpostavljam da niti ona nema pristup korisničkim certifikatima, već ih samo generira.

Pitanje je što radi APIS: da li "duplira" ili "dodaje" neki potpuno drugi iznos u poreznu osnovicu? Meni se pojavljuju računi sa istim brojem, a različitim ZKI-jem, jer su podaci u računu različiti: NEMAM POJMA ODAKLE, ali očigledno se to u malom broju slučajeva dešava i to samo kod ponovljenog slanja (ali i tad rijetko, 5 puta na 2200 računa). Moram ponovo debugirati program, ali je problem prilično maglovit, jer ima "milion" ponovljenih slanja, koja nisu napravila nikakav problem, a nekoliko jeste. Prije će biti da ću nekim dodatnim kontrolama i blokadama zabraniti događanje "nečega", nego da ću točno otkriti što se događa, obzirom da ne mogu sa sigurnošću kreirati identične uvjete koji se pojavljuju kad se desi greška.
Jul 2 at 9:57 AM
zp1956 wrote:
i na kraju da napomenem da sve ovo kod mene radi sa access bazom u pozadini već 20 godina. prelazak na SQL server je udaljen jamo jedan klik (zamjena connection stringa).
Ja sam sa Accessom imao prilično iznenađujuća iskustva.
Npr, mislim da još uvijek imam taj primjer, u jednoj tablici u polju AutoNumber uspio mi je dodati 10-tak istih brojeva!?!

Ostale usporedbe neću raditi jer naprosto nemaju smisla
Jul 2 at 5:18 PM
Edited Jul 2 at 5:19 PM
Stanki wrote:
zp1956 wrote:
i na kraju da napomenem da sve ovo kod mene radi sa access bazom u pozadini već 20 godina. prelazak na SQL server je udaljen jamo jedan klik (zamjena connection stringa).
Ja sam sa Accessom imao prilično iznenađujuća iskustva.
Npr, mislim da još uvijek imam taj primjer, u jednoj tablici u polju AutoNumber uspio mi je dodati 10-tak istih brojeva!?!

Ostale usporedbe neću raditi jer naprosto nemaju smisla
moguće! ali ja ne bih odmah krivio alat. pitanje je kako je baza bila struktuirana, u kakvom okruženju je radila, .... svaki alat ima svoje mogućnosti i ograničenja, i to treba znati prilikom izbora baze. ako pogledaš temu od početka vidiš da se ponekad sumnja i na APIS i na njihovo riješenje koliko god bilo kompleksno. riješavanje POS-a nije baš nešto zahtjevan zadatak i za to ne trebamo tešku artiljeriju.

ono što sam nastojao istaknuti i u čemu se jedino donekle slažem s tobom je da u početku treba definirati redoslijed aktivnosti (od kreiranja računa do obrade finalnog ogovora od porezne, kakav god on bio), koristiti transakcije i predvijdjeti što sve treba arhivirati u bazu zbog kasnije analize. za korisnika naših programa u 99% slučajeva krivi su programeri.

i na kraju, svrha ove teme je da pomognemo onima koji imaju 'problem' s poreznom na način da damo svoja iskustva i ideju što se u programu može popraviti da bi se greška otklonila. čak i porezna u ovim svjom zadnjim mailovima nije restriktivna i naglašava da podatke ne treba ispravljati, već smo objasniti zbog čega je došlo do odstupanja) i potvrditi da je greška otklonjena. osobno sam u prepisci s poreznom u vezi jednog problema (konsignacija i prodaja uramljenih slika gdje se porez obračunava samo na maržu odnosno uramljivanje) gdje stvarno postoji odstupanje, ali o tome možda kasnije.
Jul 3 at 2:01 PM
Slažem se. Pozitivno.
Jul 4 at 11:20 AM
Edited Jul 4 at 11:21 AM
dakle, prošli tjedan sam imao slučaj gdje je porezna prijavila grešku tipa 'Ukupan iznos na računu nije ispravan prema formuli'. radi se o prodaji uramljenih slika gdje bi izračun PDV-a bio slijedeći:
  • vrijednost slike (umjetničko dijelo, oslobođeno plaćanja PDV-a): 1000 kn
  • uramljivanje: 200 kn
  • PDV: 50 kn
dakle, kupac plaća 1250 kn i autoru slike se isplaćuje 1000 kn

na računu kako je trenutno implementirano piše:
  • iznos ukupno: 1250 kn
  • osnovica 25%: 200 kn
  • PDV 25%: 50
a trebalo bi pisati:
  • iznos ukupno: 1250 kn
  • neoporezivo: 1000 kn
  • osnovica 25%: 200 kn
  • PDV 25%: 50
moja greška je što u request datoteci nisam koristio mogućnost prijave ovog neoporezivog iznosa.
to smo objasnili poreznoj i naveli da će program biti korigiran. inače, PDV je ispravno izračunat, samo se nije vidjelo da ovaj neoporezivi iznos postoji

sad dolazim do implementacije i tu promjetim jedan potencijalni problem.

na stranici 10. i 11. tehničke specifikacije navede se tri slučaja koja spadaju u kategoriju neoporezivog.
  • Iznos oslobođenja
  • Iznos na koji se odnosi poseban postupak oporezivanja marže
  • Iznos koji ne podliježe oporezivanju
za ovaj drugi slučaj spominju se umjetnička dijela (Marža za rabljena dobra, umjetnička djela, kolekcionarske ili antikne predmete - članak 22.a zakona o PDV-u)

u svom programu koristim svoje procedure za fiskalizaciju gdje mogu korisiti bilo koju od ove tri kategorije i fisku (by bbanko) koja ima samo jednu mogućnost prijave neoporezivog dijela u redu 11 (koji bi odgovarao ovoj saznjoj kategoriji iz tehničke specifikacije).

i sad si postavljam pitanje, koju kategoriju koristiti za prijavu neoporezivog iznosa kod prodaja uramljenih slika i da li način na koji to fiska riješava zadovoljava.
Jul 4 at 12:29 PM
I ja sam imao isti problem "ukupan iznos računa ne odgovara prema formuli"
Uspio sam stuptiti u kontakt sa poreznom i dobiti par računa koji nisu OK.
Razlika je u svim slučajevima bila povratna naknada. Izgleda da je problem kod njihove kontrole. Rekapitulacija PDV-a (suma osnovica i poreza) ne morajaju dati
ukupan iznos računa. Jer povratna naknada ne ulazi u rekapitulaciju PDV-a
Jul 4 at 2:43 PM
Edited Jul 6 at 6:49 PM
točno. povratna naknada se u request datoteci navodi odmah iza ove 3 gore navedene kategorije.. srećom, u mom slučaju iznos povratne naknade je bio uključen u request file.