Greške u poreznoj

May 12 at 10:27 AM
Zvala me stranka da su joj u poreznoj rekli da ima greške u fiskaliziranim računima.

Nisu joj znali reći koje su to greške, na kojim računima i općenito o čemu se radi.

Kažu u poreznoj da njima samo napiše da postoje greške i da bi bilo dobro da se proizvođač programa očituje o tome nekim dopisom.

Mogu im napisati da je popu Šimi izgorjela štala pa su im zato računi u crvenom :D :D

Da li je netko imao sličan slučaj?
May 12 at 1:46 PM
Pozdrav,
ja sam imao slučaj još na samom početku fiskalizacije sa oznakom sustava PDV-a, umjesto true/false, slao sam 0 i 1 kako je i pisalo u specifikaciji no međutim, njima je to bilo "krivo" pa su mi rekli da prepravim.

Ono što ti savjetujem, jest da nekako probaš doći u kontakt preko svojeg klijenta sa poreznim referentom koji je izjavio da imaš greške, pa da ti objasne šta točno i kako. Tako sam barem ja, jer ovo da se očituješ za nešto što ne znaš mi je stvarno debilno s njihove strane...
May 13 at 7:34 AM
Jednom mome su tražili očitovanje zato jer mu 'u računu OIB nije prošao formalnu provjeru'.
Niti riječi u kojem računu, je li u više računa, u kom periodu, je li OIB operatera ili firme (pretpostavio sam da je riječ o operateru, jer bi firmin pretpostavljam uzrokovao pogrešku u verifikaciji potpisa certifikata), koji je bio podatak za OIB. Baš ništa odakle bi čovjek krenuo nešto ispitivati ili istraživati.
Normalno, provjerio sam trenutno postavljene OIB-e i svi su u redu.
May 16 at 8:25 AM
Edited May 16 at 8:26 AM
Ista stvar i kod mene zvala porezna.
Samo što je kod mene problem : 142 - Na računu postoji podatak 'PDV' različit od '0,00'. Sada bih volio vaše mišljenje.
Stranka nije u sustavu PDV-a kod formiranja xml-a sam rekao da uzme pdv postotak od 0, pa osnovica recimo '100.00' te iznos poreza je '0.00' ili uopće nisam trebao doznačiti PDV ako se radi o 0 % PDV-a ?
May 16 at 8:35 AM

Upravo tako, ne smiješ dotnačiti 0 vec bez tog taga. Nula je isto obveza pdv a po nultoj stopi, iako je matematički isti dr..


pon, 16. svi 2016. 09:25 bubausluge <[email removed]> je napisao:

From: bubausluge

Ista stvar i kod mene zvala porezna.
Samo što je kod mene problem : 142 - Na računu postoji podatak 'PDV' različit od '0,00'. Sada bih volio vaše mišljenje.
Stranka nije u sustavu PDV-a kod formiranja xml-a sam rekao da uzme pdv postotak od 0, pa osnovica recimo '100.00' te postotak poreza je '0.00' ili uopće nisam trebao doznačiti PDV ako se radi o 0 % ?

Read the full discussion online.

To add a post to this discussion, reply to this email ([email removed])

To start a new discussion for this project, email [email removed]

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

May 16 at 8:40 AM
Po tome ovo bi trebao biti ispravan XML prema poreznoj ?

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance">
<soapenv:Body>
<tns:RacunZahtjev xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Id="signXmlId" xmlns:tns="http://www.apis-it.hr/fin/2012/types/f73">
  <tns:Zaglavlje>
    <tns:IdPoruke>0ac0e3d3-6096-49f8-a2c6-9d36264c35bd</tns:IdPoruke>
    <tns:DatumVrijeme>16.03.2016T09:27:37</tns:DatumVrijeme>
  </tns:Zaglavlje>
  <tns:Racun>
    <tns:Oib>12345678911</tns:Oib>
    <tns:USustPdv>false</tns:USustPdv>
    <tns:DatVrijeme>16.03.2016T09:27:47</tns:DatVrijeme>
    <tns:OznSlijed>N</tns:OznSlijed>
    <tns:BrRac>
      <tns:BrOznRac>27</tns:BrOznRac>
      <tns:OznPosPr>POS1</tns:OznPosPr>
      <tns:OznNapUr>1</tns:OznNapUr>
    </tns:BrRac>
    <tns:IznosUkupno>5.00</tns:IznosUkupno>
    <tns:NacinPlac>G</tns:NacinPlac>
    <tns:OibOper>12345678911</tns:OibOper>
    <tns:ZastKod>84315a12e4120010fec6e8d19ebc24a6</tns:ZastKod>
    <tns:NakDost>false</tns:NakDost>
  </tns:Racun>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
      <Reference URI="#signXmlId">
        <Transforms>
          <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
          <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        </Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
        <DigestValue>bN3djde0vSvg0CC34+Crzr/Oe+o=</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>TYQ/EvA56cz2q2wM/pUfboW8IpjFFF6/Vm45wBeQaKPdhKfiAnWCMFRXV1mS7eKhw4TekFRIrr6gNWcHTX1/byRM0h+FDRJL4H9GvOujOZSeAD8hNwsrHcgzy8ZwY/8I/vjOID7j++sfYtk6kbI4q3OpCwvzlijy9mB7pcFw0wGVbc2CZhV4ebm1r6I8L4hZmpqhiXV+v2jQm89R8BDt36ePVIR0HayM19EqBqsW5qzxw3tj16xI4g7wBaM7lvrhgWYvNO+UKobGu6iq1gGcYMY0IxoWcGPosuCFrxDhrDyciYnXPW74pXG9qG0VROJEFk8Jkm86iWJMUf5V0RSt+A==</SignatureValue>
    <KeyInfo>
      <X509Data>
        <X509IssuerSerial>
          <X509IssuerName>CN=Fina Demo CA 2014, O=Financijska agencija, C=HR</X509IssuerName>
          <X509SerialNumber>1395332228</X509SerialNumber>
        </X509IssuerSerial>
        <X509Certificate>MIIGkDCCBHigAwIBAgIEUysUhDANBgkqhkiG9w0BAQsFADBIMQswCQYDVQQGEwJIUjEdMBsGA1UEChMURmluYW5jaWpza2EgYWdlbmNpamExGjAYBgNVBAMTEUZpbmEgRGVtbyBDQSAyMDE0MB4XDTE1MTExMzEwMjExNloXDTE3MTExMzEwNTExNlowWzELMAkGA1UEBhMCSFIxKTAnBgNVBAoTIEJVQkEgVVNMVUdFIEQuTy5PLiBIUjc3MjA1ODQ5NDQ4MQ4wDAYDVQQHDAVLUknFvTERMA8GA1UEAxMIRklTS0FMIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDeq/TWe0C0TAQwien/0CZq87VxoYHJjRzdo9svGL3M9ys/Uxi/vYS/9j91ijoLi0QkAL+2vVNbaNb24JXvPaCioRy88u7XHKE8YWlaFUznXUkmldIE3b7ckjuheJO7CAD+wBExWGqJsqQT79oDmuzFWP4uI3loZ0CmL9mKsddSYCfIXlw+ALaHCdAcbyzycUHK7LmsQW04MPYLPrlRar//++7AJUOymNt8FA3IS0INiCwVuL/bu9o5z241xqSxHgYjbaQvT8GEDqzmOXYgS8cBct1nLRAd+e9pWu/S5PRX6QpnsS/Yhi0ZDla5J/jJ5EoDOUlj4K2xlpdW7v+IGSYxAgMBAAGjggJtMIICaTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFMGA1UdIARMMEowSAYJK3yIUAUgBQMBMDswOQYIKwYBBQUHAgEWLWh0dHA6Ly9kZW1vLXBraS5maW5hLmhyL2NwL2NwZGVtbzIwMTR2MS0wLnBkZjB9BggrBgEFBQcBAQRxMG8wKAYIKwYBBQUHMAGGHGh0dHA6Ly9kZW1vMjAxNC1vY3NwLmZpbmEuaHIwQwYIKwYBBQUHMAKGN2h0dHA6Ly9kZW1vLXBraS5maW5hLmhyL2NlcnRpZmlrYXRpL2RlbW8yMDE0X3N1Yl9jYS5jZXIwggEXBgNVHR8EggEOMIIBCjCBpqCBo6CBoIYoaHR0cDovL2RlbW8tcGtpLmZpbmEuaHIvY3JsL2RlbW8yMDE0LmNybIZ0bGRhcDovL2RlbW8tbGRhcC5maW5hLmhyL2NuPUZpbmElMjBEZW1vJTIwQ0ElMjAyMDE0LG89RmluYW5jaWpza2ElMjBhZ2VuY2lqYSxjPUhSP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3QlM0JiaW5hcnkwX6BdoFukWTBXMQswCQYDVQQGEwJIUjEdMBsGA1UEChMURmluYW5jaWpza2EgYWdlbmNpamExGjAYBgNVBAMTEUZpbmEgRGVtbyBDQSAyMDE0MQ0wCwYDVQQDEwRDUkwyMB8GA1UdIwQYMBaAFDuEWhT1xTzhSDtd0Sc1e9VlvA4qMB0GA1UdDgQWBBSdD4PKGN9QEquPRALd8LntCCyygTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBCwUAA4ICAQAwmNjwlhEBHwUF0+hrLmSDk64RT8bl8LvZQg1utRHtSPwF4A//j3gEQVpYdRuvwWQwuniWUrZkYnKyZDcBbGb1RW7mqYPpwhyK6U1gRckQEkKq2SIkbXkXp9qhTOqOSBnfbXT/Q+QtiteBTcnWFr/vbnAFsQJtIgfe+IQm8zrJrSGGTVtoTeSH6TninTawFeX1H0CNtikW1NbrRfGzBImA5HgXVde1CU9wi0bRgQjtUv+e9j3ZselpHHKIHZZqmR2IqIX8Lkt2x0weKwIdEBFy08cQKRf/H4Z2l+SwJUz316BitQa68hmRxtU6rho0I4Ps1AaD7joeoLsYYwGKxHh47CbQuhBDA5fCR8Df8QWvrTfF3H67PJljzOUSHT70iz4lMVDFlVQQ9umCq4jtzV40PhfqGshFV1YHxZg+YuMge9m9V7Ruzw8WhqSDAFv6KeDp48cdxBH5tBaqaJjJgshYLFzDEy5BkJlLUAa05OZ4RWTCHCeo2bz1OFGQCa8K4gnfgLuvl8l5PVSU0ZSUaWMch6PYlhv5m4M8aOYOUKkEZ+6krh5NonsoI/5hx480KFPuqRYQhh8Orgh0NFRHD5MQxkkK+o6gJTq7UjSweKj0cXucZtrTKSQc/OvFepaOeStwD7xdn2Ol2R4iTwSAYMGBcG3o48J63LDHf0SbrYQJNA==</X509Certificate>
      </X509Data>
    </KeyInfo>
  </Signature>
</tns:RacunZahtjev>
</soapenv:Body>
</soapenv:Envelope>
May 17 at 8:05 AM
Nama ovih dana dva klijenta zatražila da li im možemo napraviti ispis sa svim fiskaliziranim računima, ZKI, JIR... u odabranom periodu, jer su im iz Porezne uprave poslali zahtjev, odnosno, molbu (da, lijepo su ih zamolili), da zbog pogreške u sustavu (valjda APIS), nemaju evidentirane račune, bla bla bla....
Za ovako nešto prije nisam čuo, naravno da ćemo to napraviti, ali zahtjev je onako, lagano, blesav.
May 18 at 10:22 AM
Aha, izgleda da su se probudili u proeznoj....:)

Ovog puta sam dobio dopis od porezne sa opisom greške i sa primjerom racuna gdje se pojavljuje ta greška.

Sad ću to malo proučiti i javiti o čemu se sve radi
May 18 at 5:51 PM
I meni, tj. jednom mojem klijentu isto tako rekli da je "racune izdavala osoba koja nije za to bila registrirana", a radi se o konobarici koja je vec 12 godina uredno zaposlena kod njega ( i to na racunima iz 2015.) ... sad ne kuzim i kako uopce gledaju tko bi trebao izfavati racune ako je to zapisano u internom aktu kojeg ne vide dok ne dodju u lokal ... jos rekli da su i na hrpu racuna krivo obracunati porezi, prosao sve opet rucno i svi izracunati kako treba ...

za sada cekam dalje sta ce biti ...
May 18 at 6:47 PM
Sada gledam onaj primjer gore šta je kolega stavio:

<tns:DatumVrijeme>16.03.2016T__09:27:37__</tns:DatumVrijeme>
</tns:Zaglavlje>
<tns:Racun>
<tns:Oib>12345678911</tns:Oib>
<tns:USustPdv>false</tns:USustPdv>
<tns:DatVrijeme>16.03.2016T__09:27:47__</tns:DatVrijeme>
Jel se meni čini ili je taman ubo u taj problem sa vremenom?
May 19 at 7:45 AM
E ovako, bile su sljedeće greške :

1) naknadna fiskalizacija nakon 48 sati
2) fiskalizacija za poslovni prostor koji nije prijavljen

...e sad ide ono "veselo"

3) "Ukupan iznos na računu" nije ispravan prema formuli

Ne znam po kojoj formuli računaju iznos računa. Pretpostavljam da zbrajaju osnovice i iznose poreza. To se ponekad razlikuje od ukupnog iznosa za lipu, dvije....za ovo jednostavno ne postoji rješenje koje bi zadovoljilo i poreznu i knjigovođe. Pošto je porezna glavni igrač idemo prema tome da nju zadovoljimo, zaokružimo iznose
da štimaju a knjigovođama prenesemo da se obrate poreznoj ako im na kraju mjeseca ne štima osnovica i iznos poreza :D :D

4) "Datum i vrijeme izdavanja" računa veće je od "Datum i vrijeme slanja"

Ovo je nemoguće. U programu prvo pamtim datum i vrijeme računa iz tekućeg vremena u PC-u a tek nakon toga uzimam tekuće vrijeme za izradu XML datoteke. Jedini mogući logični zaključak (ukoliko se ne radi o greški u kodu programa) je da se vrijeme na PC automatski ažurira preko itnerneta točno u trenutku kada se radio račun.

Toliko za sada.

Bog nam pomogo

:D
May 19 at 12:45 PM
Fiskalizacija počela od 2012. a oni se sjetili bacit kontrolu 2016.

Eto problema kod mojih korisnika :
1) Iskonfali program tako da je program po defaultu u pdv-u ,a oni nisu. ( Šalje PDV tag sa 0% PDV-a i iznosom PDV-a 0.00 , a osnovica je finalni iznos.)
2) Ukupan iznos na računu - Po kojoj logici izračunati da to poreznu zadovoljava ? Dali je ovaj moj način ok ?
Jun 6 at 4:31 PM
Od porezne smo dobili samo informaciju da u 2015 imamo 40 'neispravnih' računa i žele očitovanje. Kao primjer su naveli samo 4 računa s tipom greške. Za tip greške 104 znam da znači 'Datum i vrijeme izdavanja' računa je veće od 'Datum i vrijeme slanja'. Za ostale tipove grešaka nemam pojma što znače a oni ne žele tu pomoći.
Što znače tipovi grešaka 114, 115 i 116?. Odnosno, gdje bi mogao naći popis grešaka.
Jun 6 at 5:02 PM
102 – datum i vrijeme izdavanja računa je za više od 78 sati manje od datum i vrijeme obrade
103 - „ od 6 sati veće od datuma i vrijeme obrade
137 - ukupan iznos na računu nije ispravan prema formuli
101 - datum i vrijeme slanja je za više od 6 sati manje ili veće od datum i vrijeme obrade
104 - datum i vrijeme izdavanja računa je veće od datum i vrijeme slanja
111 - porezna stopa je navedena više puta za isti račun
116 - iznos poreza je više od 1 kn veći od izračuna poreza pdv-a
119 - porezna stopa poreza na potrošnju navedena je više puta za isti račun
120 - osnovica PNP-a je veća od podatka Ukupni iznos kada je Ukupni iznos pozitivnog predznaka ili je jednak 0
122 - Osnovica PNP-a nije istog predznaka kao i Ukupni iznos
141 - polje „specifična namjena“ nije prazno
Ovo su najccesce greske koje su se kod mojih korisnika pojavljivale, uz nekoliko slucajeva gdje je veci iznos fiskaliziran nego prikazan u PDV obrascu sto zahtjeva poseban tretman. Sve to ukratko obrazlazem time da ne mogu utjecati na vrijeme koje je u racunalu a pogotovo ne na datum koji ce korisnik upisati kao tocno vrijeme i datum. Mislim da se formula odnosi na zaokruzivanje, gledao sam lipa gore dolje, dakle nije isto kad racunas po preracunatoj stopi pa unazad, a sto ce korisnik kod pojedinog artikla upisati kao stopu poreza i kako ce obracunati porez ili kasnije mijenjati ili zadebiliti kod unosa racuna to je isto moguce obrazloziti.
Jun 6 at 5:46 PM
Hvala.
Ok, za grešku 104 sam i mislio objasniti nešto slično tome. Problem mi je sa ove druge tri greške.
Unosi u bazu su identični onome što je poslano prema serveru. Odgovro servera je također ok. Problem je što su u bazu unešene vrijednosti koje nemaju smisla i koje korisnik nije mogao sam unijeti. NA dva računa mi se pojavljuje neka povratna naknada koja ne postoji u šifrarniku artikala. Korisnik samo izabire, odnosno potvrđuje artikel i unosi količinu i eventualni popust za pojedine stavke.
Rezultat je da izdani račun nije ispravan. Da ne ulazim u detalje, ovdje sigurno postoji neka mogućnost krivog unos ili izračuna i to moram riješiti. Zanimljivo da se ta greška nalazi samo na dva računa od preko 6500 izdanih računa. Kako u ovom slučaju odgovoriti poreznoj?
Jun 6 at 6:23 PM
Edited Jun 6 at 6:24 PM
U obrazloženju treba napisati ono što stvarno je i ako greška već nije ispravljena, ispraviti je da se ne bi ponavljala.

Citiram jednu od primljenih poruka iz porezne: " Ukoliko se radi o greškama zbog neispravnog programskog rješenja, potrebno je isto napisati u Internom aktu, potrebno je ispraviti programsko rješenje kako se greške više ne bi ponavljale (možda je to već učinjeno i riješeno obzirom da ih nema u xx. i yy. mjesecu????). Takve greške ne smiju se ispravljati retroaktivno, već od ovog trenutka pa nadalje. "

Moguće je da su vam te tri greške vezane baš za ta dva računa obzirom da je račun neispravan.
Da li možete kontaktirati neku drugu ispostavu porezne pa ih zamoliti za pomoć oko šifri grešaka? Koliko sam primijetila, različite ispostave različito nastupaju prilikom traženja obrazloženja. Jedni lijepo sve napišu, podatke o računu i koje su greške, dok drugi napišu nešto općenito kao da je to državna tajna.
Jedni nisu znali reći ni na koji se poslovni prostor račun odnosi.
Jun 6 at 6:27 PM
Sa stranica porezne uprave, možda bi oni bili voljni pomoći:

__APIS IT pruža podršku proizvođačima/održavateljima softvera vezano za tehničke probleme u povezivanju na CIS Porezne uprave
APIS e-pošta: fiskalizacija.help@apis-it.hr __


http://www.porezna-uprava.hr/HR_Fiskalizacija/Stranice/Fiskalizacija_kontakti.aspx
Jun 6 at 8:52 PM
zp1956 wrote:
Od porezne smo dobili samo informaciju da u 2015 imamo 40 'neispravnih' računa i žele očitovanje. Kao primjer su naveli samo 4 računa s tipom greške. Za tip greške 104 znam da znači 'Datum i vrijeme izdavanja' računa je veće od 'Datum i vrijeme slanja'. Za ostale tipove grešaka nemam pojma što znače a oni ne žele tu pomoći.
Što znače tipovi grešaka 114, 115 i 116?. Odnosno, gdje bi mogao naći popis grešaka.
Bubam napamet, ali vjerojatn imaš još problem u zaokruživanju poreza i osnovica, naknadna fiskalizacija nakon 48 sati i možda da su izdali račun prije nego su prijavili poslovni prostor. To su najčešće greške.

Kako ti je netko predložio, kontaktiraj referenta, znaju biti susretljivi.
Jun 9 at 9:06 AM
3) "Ukupan iznos na računu" nije ispravan prema formuli
Iz porezne dobio informaciju da su naknadno dobili naputak da se tolerira do 1kn.
U slucaju da je kod svih racuna tako, ne morate nista prepravljati.
Jun 9 at 9:28 AM
divkovi1 wrote:
3) "Ukupan iznos na računu" nije ispravan prema formuli
Iz porezne dobio informaciju da su naknadno dobili naputak da se tolerira do 1kn.
U slucaju da je kod svih racuna tako, ne morate nista prepravljati.
Da nisi krivo shvatio? Tolerancija do jedne kune mi izgleda nekako puno previše. Makar bi bilo odlično da je tako.
Jun 9 at 10:51 AM
moremore wrote:
divkovi1 wrote:
3) "Ukupan iznos na računu" nije ispravan prema formuli
Iz porezne dobio informaciju da su naknadno dobili naputak da se tolerira do 1kn.
U slucaju da je kod svih racuna tako, ne morate nista prepravljati.
Da nisi krivo shvatio? Tolerancija do jedne kune mi izgleda nekako puno previše. Makar bi bilo odlično da je tako.
Nisam, u zadnja dva tjedna sam imao iste razgovore sa vise poreznih uprava, vezano za isti problem :)
Jun 9 at 11:05 PM
Edited Jun 9 at 11:10 PM
Razmišljam o dokazivanju problema sa većim vremenom izdavanja računa od vremena fiskalizacije.
Nisam još imao nikakvih dodira niti upita od porezne (otkako smo krenuli u fiskalizaciju), ali obzirom da su sad izgleda napokon savladali pristup bazama koje se nalaze u APISu, očekujem da neće ni mene mimoići sa tim debilanama (fali državi para, o tome se radi, pa sad jadne poreznike tjeraju da pregledaju milijarde cifara i traže bilo kakvu "greškicu").

Čuvate li XML-ove koje šaljete? I XML-ove koje primate natrag, sa JIR-om?
Iz tih fajlova je valjda moguće rekonstruirati što se događa. Obzirom da se u XML zahtjevu mora upisati vrijeme slanja na fiskalizaciju u <tns:ZAGLAVLJE>, a vrijeme izdavanja u <tns:RACUN>, ako se čuvaju XML-ovi, moguće je iz njih rekonstruirati griješi li vaš program ili je problem u APISu. Naime, možda (ali samo možda!) APISov softver ne gleda u vaš XML i odatle čita podatak o vremenu iz ZAGLAVLJA, nego uzima trenutak stizanja XML-a po svom lokalnom satu, a ako su njihov i vaš sat u koliziji, eto problema. Ako čuvate te XML-ove, lako je provjeriti (prije bih se kladio na bugove u našim (vašim) programima nego u APISu).

Kako ja za fiskalizaciju koristim FISKU, ona sama odradi ZAGLAVLJE, tako da ja nemam dokaz što ona pošalje u CIS (moram vjerovati bbanku, kreatoru fiske, ali vjerujem da bi on davno primijetio takvu grešku) i ne mogu provjeravati na ovaj način (XML sadrži samo podatke od <tns:Racun>, ali ja zapisujem u bazu i vrijeme SLANJA na fiskalizaciju). Jedino što bih mogao je uspoređivati vrijeme izdavanja računa i kreiranja XML fajla kao fajl atributa (da eventualno nađem bug u programu).

Obzirom da CIS vraća XML sa JIR-om, a u njemu se isto tako nalazi <tns:DatumVrijeme> (koje bi trebalo biti veće ili jednako i od vremena izdavanja i od vremena slanja), moguće je možda i to iskoristiti za neku forenziku.
Jun 10 at 9:31 AM
Ako imamo potpisane XML-e onda imamo i zabilježenu grešku koju navodi porezna. Postoji sigurno veliki broj mogučih scenarija kako se generira ova greška, nabrojati ču samo neke:
  • Računalo zablokira i ne uspije fiskalizirati, a račun je proknjižen u bazi. Nakon restarta računalo uskladi vrijeme i tako naše vrijeme slanja je moguće manje od vremena na računu. Ova je možda rijetko, ali je moguće..
  • Promjene Regional setinga u naknadnoj fiskalizaciji može generirati ovu grešku..
  • Situacije kod Client/Server računala za isti naplatni uređaj. Da bi sačuvali vremensku slijednost, svi klijenti koriste vrijeme baze sa servera, fiskalizacija kako bi bila samostalna ide po vremenu Client računala pa su takve greške realne za očitavanje.
  • Sigurno postoje i neke App situacije za razlike u čitanju vremena.. Vrijeme je ipak relativna stvar.
    Rekao bi da Apis takođe ima vrijeme svog servera i iz njega može puno zaključiti. Tri godine takve stvari su bile ok, a sada odjednom nisu dobre. .
Jun 11 at 3:26 PM
divkovi1 wrote:
3) "Ukupan iznos na računu" nije ispravan prema formuli
Iz porezne dobio informaciju da su naknadno dobili naputak da se tolerira do 1kn.
U slucaju da je kod svih racuna tako, ne morate nista prepravljati.
Ja sam dobio slijedeći odgovor na moj upit:

"Napominjemo da iznos PDV-a mora odgovarati umnošku vrijednosti isporuka i odgovarajuće stope PDV-a, a što se tiče eventualno nastalih odstupanja postavkama informacijskog sustava Porezne uprave dozvoljeno je odstupanje +/- 1.00 kuna za mjesečne i tromjesečne prijave PDV-a."


Prilično sam siguran da ne toleriraju kunu po računu.
Jun 11 at 3:30 PM
Inače kako ste riješili te razlike od 1 lipe?

Ja što god da radim, a nije baš da imam previše opcija, ponekad se nađe račun koji ima i 13% + 3% , 25%+3%, 13%, 25%, pa onako i fini popust od 10 %....

Mogao bih na silu trpati tu lipu razlike, ali nije mi to baš neka fora..
Jul 7 at 12:17 PM
Pozdrav svima,

I mi smo počeli dobivati pozive korisnika i Porezne da nam se pojavljuje greška "137 - ukupan iznos na računu nije ispravan prema formuli". Izolirali smo slučajeve i zaključili da se radi o računima na kojima postoji Povratna naknada 0,50 kn.

S obzirom da je ista "prolazna stavka" u smislu PDV-a, da li netko zna da li se ista šalje u još nekom podatku u XML-u, osim u standardnom elementu "Naknade"? Konkretno, treba li ga slati i u elementu "Iznos koji ne podliježe oporezivanju"?

Hvala.
Jul 7 at 2:29 PM
Kod ugostitelja - primjer sa porezom na potrošnju i stopama 13% i 25%:
<tns:Racun>
<tns:Oib>OIB :)</tns:Oib>
<tns:USustPdv>true</tns:USustPdv>
<tns:DatVrijeme>06.07.2016T07:05:47</tns:DatVrijeme>
<tns:OznSlijed>N</tns:OznSlijed>
-<tns:BrRac>
<tns:BrOznRac>18944</tns:BrOznRac>
<tns:OznPosPr>u02</tns:OznPosPr>
<tns:OznNapUr>101</tns:OznNapUr>
</tns:BrRac>
-<tns:Pdv>
-<tns:Porez>
<tns:Stopa>13.00</tns:Stopa>
<tns:Osnovica>34.49</tns:Osnovica>
<tns:Iznos>4.48</tns:Iznos>
</tns:Porez>
-<tns:Porez>
<tns:Stopa>25.00</tns:Stopa>
<tns:Osnovica>6.25</tns:Osnovica>
<tns:Iznos>1.56</tns:Iznos>
</tns:Porez>
</tns:Pdv>

-<tns:Pnp>
-<tns:Porez>
<tns:Stopa>3.00</tns:Stopa>
<tns:Osnovica>7.11</tns:Osnovica>
<tns:Iznos>0.21</tns:Iznos>
</tns:Porez>
</tns:Pnp>

<tns:IznosUkupno>47.00</tns:IznosUkupno>

<tns:NacinPlac>G</tns:NacinPlac>
<tns:OibOper>OIB operatera :)</tns:OibOper>
<tns:ZastKod>c1b7f1948a6b2ad62eca5b594aea8a31</tns:ZastKod>
<tns:NakDost>false</tns:NakDost>
</tns:Racun>

Sad ću ti poslati primjer sa povratnom naknadom
Jul 7 at 2:42 PM
Kad ti zbrojimo dvije osnovice, dva poreza i PNP dobije se 46.99
34.49 + 6.25 + 4.48 + 1.56 + 0.21 = 46.99
Je li se ta 1 lp tolerira?
Jul 7 at 3:00 PM
Da. Baš lijep primjer. :) Mislim da to prolazi. Do sada nisam imao problema sa tim
Jul 7 at 3:13 PM
Ajde pošalji taj jedan primjer s povratnom naknadom, iako nemam takvih korisnika zanima me ako bude trebalo
Jul 7 at 3:26 PM
Izgleda da i ja tu imam bug. Pa, ne mogu vjerovati!!
Može netko drugi s primjerom dok ja provjerim code?
Jul 7 at 3:30 PM
Postoji u Tehničkoj dokumentaciji tag Naknade:
Naknade koje se mogu pojaviti na računu tipa povratne naknade za ambalažu i sl.
Podatak se dostavlja Poreznoj upravi samo ako na računu postoje naknade.
Podatak se sastoji od naziva naknade i iznosa naknade.
Može postojati lista naknada.
Naziv naknade Opisno naziv naknade. DA, ako postoji naknada Varchar(100)
Iznos naknade DA, ako postoji naknada Decimal(15,2)
Jul 7 at 3:58 PM
Edited Jul 7 at 3:59 PM
Ide naziv naknade i iznos, nez. u kojem nodu. Sjećam se nekog primjera: "POVRATNA NAKNADA" 2.00
Jul 7 at 8:24 PM
Postoji poseban node za povnak. Posaljem kada budem na komp
Jul 7 at 10:05 PM
Evo primjer XML-a računa sa:
PDV13%, PDV25%, PP 3%, POVRATNA NAKNADA
  1. Da li povratnu naknadu, kako je prolazna stavka moramo prikazati još u nekom tag-u ili je ovo dovoljno?
  2. Ako korisnik nije u sustavu PDV-a, tag PDV-a ne šaljemo, to je nekako ok. Ako je korisnik u sustavu PDV-a i ima stavku PDV=0%. Nekako se nameće da taj tag trebamo slati. Često su te stavke zakonske odredbe kao: ne podliježe, oslobođeno itd.. pa onda imamo više kombinacija. Volio bi znati da li je netko detaljizirao ovu priću..
Po pitanju zaokruživanja, mi zaokružujemo u natrag tako da razlike lipica ostanu u osnovici, nije idealno ali MPV ostaje bez tih lipa razlike..
<tns:RacunZahtjev xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Id="signXmlId" xmlns:tns="http://www.apis-it.hr/fin/2012/types/f73">
<tns:Zaglavlje>
<tns:IdPoruke>5ef76788-f375-442c-839f-8d2ad096c500</tns:IdPoruke>
<tns:DatumVrijeme>07.07.2016T21:55:35</tns:DatumVrijeme>
</tns:Zaglavlje>
<tns:Racun>
<tns:Oib>12345678901</tns:Oib>
<tns:USustPdv>true</tns:USustPdv>
<tns:DatVrijeme>07.07.2016T21:55:30</tns:DatVrijeme>
<tns:OznSlijed>N</tns:OznSlijed>
<tns:BrRac><tns:BrOznRac>200002</tns:BrOznRac>
<tns:OznPosPr>POSL1</tns:OznPosPr>
<tns:OznNapUr>1</tns:OznNapUr>
</tns:BrRac>
<tns:Pdv>
<tns:Porez>
<tns:Stopa>13.00</tns:Stopa><tns:Osnovica>502.86</tns:Osnovica><tns:Iznos>65.37</tns:Iznos>
</tns:Porez>
<tns:Porez>
<tns:Stopa>25.00</tns:Stopa><tns:Osnovica>87.60</tns:Osnovica><tns:Iznos>21.90</tns:Iznos>
</tns:Porez>
</tns:Pdv>
<tns:Pnp>
<tns:Porez>
<tns:Stopa>3.00</tns:Stopa><tns:Osnovica>345.69</tns:Osnovica><tns:Iznos>10.37</tns:Iznos>
</tns:Porez>
</tns:Pnp>
<tns:Naknade>
<tns:Naknada><tns:NazivN>Povratna naknada ambalaža</tns:NazivN><tns:IznosN>0.50</tns:IznosN></tns:Naknada>
</tns:Naknade>
<tns:IznosUkupno>688.60</tns:IznosUkupno>
<tns:NacinPlac>G</tns:NacinPlac>
<tns:OibOper>23456789012</tns:OibOper>
<tns:ZastKod>864d5637d541cbd6aece50f74646eeb7</tns:ZastKod>
<tns:NakDost>false</tns:NakDost></tns:Racun>
</tns:RacunZahtjev>
Jul 8 at 8:33 AM
Je. Ovo je informatički korektno. No, ovako nešto u praksi je nemoguće. Ne možeš imati PDV, Porez na potrošnju i povratnu naknadu u istom računu.
Bar ja ne znam za takve slučajeve
Jul 8 at 10:50 AM
Stanki wrote:
Je. Ovo je informatički korektno. No, ovako nešto u praksi je nemoguće. Ne možeš imati PDV, Porez na potrošnju i povratnu naknadu u istom računu.
Bar ja ne znam za takve slučajeve
Ako u blagajni imaš više mjesta troška, od kojih je jedno ugostiteljstvo a drugo trgovina, onda je to normalan račun. Naravno sama trgovina nema PP, a ugostiteljstvo obično nema povratnu naknadu.. bar ne znam da je netko koristi.
Jul 8 at 1:47 PM
Ako postoji ugostiteljstvo i trgovina tada bi se trebalo raditi o 2 prodajna mjesta, odnosno o 2 poslovne jedinice/skladišta.
U ugostiteljstvu imamo porez na potrošnju, pa se na računima koje imaju te stavke to iskazuje.
U trgovini imamo povratnu naknadu, pa se na računima koje imaju te stavke iskazuje povratna naknada.
Na istom računu imati obadvoje: i porez na potrošnju i povratnu naknadu za ambalažu, je po meni nekorektno.
Jul 9 at 5:37 PM
Stanki, žalim, ali može.
Prodajno mjesto maštovitog naziva Caffe@Backery (a vidio sam i druge slične prodajne prostore) servira kave (sa corissantom ili bez), sladoled u kuglicama, trokute pizze, bezalkoholna pića, piva pa i žestice kao normalno ugostiteljstvo (vani terasa, unutra par barskih stolica). U istom prostoru je i trgovčki pult/vitrine gdje se prodaju razna peciva, kruh, sladoled (tvornički korneti i štapići), mlijeko, "dedeki" jegera, pelinkovca i sl, a postoji i rashladna vitrina sa vodama/sokovima/pivama u PET ambalaži i limenkama. Sve to "poduprto" plakatom koji kaže da konzumacija tih (trgovačkih) artikala nije dozvoljena u prodajnom prostoru.
Spomenuo sam croissant na tanjuriću (npr. uz kavu). Taj je po ugostiteljskoj cijeni, a isti taj na pultu (za van) je po trgovačkoj cijeni, uz naravno i pripadajuće različite PDV-ove. Pizza, začudo, uvijek po trgovačkoj cijeni.
I sve to, naravno, na jednom računu, jer diša kaže: Zašto gost nebi naručio kavu s croissantom, i pizzu & pivce za na plažu? Šta, konobar treba nositi kalkulator da zbraja račune? (doduše, on kaže digitron)

A zaokruživanje osnovica/pdv/potrošnja vs iznos računa je posebna priča. Meni su npr. prigovorili za račun koji je imao dvije stavke, obje miješane od artikala iz različitih poreznih skupina (kokteli od voća, žestice, sokova i kave). Obje osnovice odoše prema gore (ili dole, ne sjećam se), porezi odoše suprotno, i eto ti protudržavnog elementa koji na svim računima na razini cijele godine skupi cijelih 7,68 kn razlika u zaokruživanju - i sve to uredno plati jer knjigovođa provodi obračun na razini mjeseca!

Je.. fiskalizaciju, je.. APIS i PU, je.. takvu državu, stvarno mi je muka od svih njih.
Jul 10 at 8:40 PM
gmacarol wrote:
Je.. fiskalizaciju, je.. APIS i PU, je.. takvu državu, stvarno mi je muka od svih njih.
Pridružujem se ovim lijepim željema!
Jul 10 at 11:02 PM
viggor wrote:
gmacarol wrote:
Je.. fiskalizaciju, je.. APIS i PU, je.. takvu državu, stvarno mi je muka od svih njih.
Pridružujem se ovim lijepim željema!
Melem od komentara!!!
Jul 21 at 8:19 AM
Malo gledam oko tih poruka iz porezne... U dva navrata su nam korisnici poslali popis računa za koje se kaže da im je vrijeme računa manje od vremena zahtjeva...
Pustio sam si kontrolu tih računa i nigdje nije bilo tih razlika, potpuno je nemoguće uopće da se to dogodi u mom kodu... E sad je pitanje odakle porezna, APIS, bilo tko, izvlači takve "greške". Za jedan takav upit sam kreirao PDF sa svim računima da si pregledaju, file je velik preko 200 MB-a i probao sam poslati u poreznu, naravno, nije prošao zbog veličine.
Jul 21 at 9:19 AM
Da li ste probali uspoređivati sa datumom koji je upisan u xml datoteteci odgovora?
Možda se ne slaže vrijeme računa sa njihovim vremenom, odnosno vrijeme na kasi je bilo veće od vremena na serveru porezne.
Aug 19 at 3:08 PM
Edited Aug 22 at 8:59 AM
Dok su u APIS-u pomoću studenata provjeravali potpise za kandidaturu, a sami močili dupe u moru, ja sam marljivo i detaljno analizirao onih nekoliko grešaka na koje su iz PU upozoravali moje klijente.
  1. 'Datum i vrijeme izdavanja' računa je veće od 'Datum i vrijeme slanja' (v104).
    Uvijek su u pravu, a greška je rezultat prelaska iz sekunde u sekundu prilikom slaganja XML-a.
    • Rješenje je moguće, na način da se vrijeme ne čita funkcijom svaki put kad zatreba, nego samo jednom, pospremi se u varijablu i koristi na oba mjesta u XML-u.
      Koliko sam shvatio, korisnici Fiske (ja koristim EXE) to ne mogu, ali zato mogu "ukrasti" par sekundi sa pročitanog vremena računa, pa će tako i oni zadovoljiti ovu stupidnu kontrolu.
  2. 'Datum i vrijeme izdavanja' računa je za više od 6 sati veće od 'Datum i vrijeme obrade' (v103).
    Ovo se dešava kada korisnik zaključi blagajnu na kraju radnog vremena i onda mu uleti kupac. Obično je datum računa već "gurnut" na sljedeći radni dan, pa ode račun sa datumom koji je cijeli jedan dan ispred datuma i vremena zaprimanja, tj. obrade.
    • Rješenje je moguće, na način da zabranite izdavanje i fiskaliziranje računa sa datumom većim od trenutnog sistemskog datuma. "Neprogramersko" rješenje (upozoriti klijente da to ne rade) provjereno radi samo kod malih korisnika (čitaj: vlasnik na blagajni) i to samo ako je dotični razuman. Dakle, ne pali.
  3. 'Ukupan iznos na računu' nije ispravan prema formuli (v137).
    I ovdje su uvijek u pravu, ali samo temeljem kontrole koju je u nekim situacijama nemoguće zadovoljiti - tolerancija je premala.
    (Da, vezano za solar-ov post u temi "TLS 1.1 i 1.2 protokol: Testna okolina: 1.9.2016 Produkcija: 9.1.2017 --- Pitanje je da je li je u dokumentaciji navedena točna formula za dotičnu kontrolu!? --- Ja PPOM nemam, pa ne brinem)
    • Rješenje ne vidim. Kada se osnovice i porezi kalkuliraju povratnim stopama (što, koliko znam, nije zabranjeno), matematika i zaokruživanje su neumoljivi. Do te greške UVIJEK može doći ako su na računu dvije ili više stavki iz različitih poreznih skupina uz još i porez na potrošnju. Pritom osnovice ili porezi mogu "skrenuti" u istu stranu i eto razlike od barem 2 lipe (tolerira se jedna)
      Ono "UVIJEK" od maloprije odnosi se na način računice: zbrajali se iznosi na razini svake stavke ili na razini međusuma pojedinih skupina i bez obzira na broj decimala (do 8), rezultat može biti "krivi".
      Na tragu toga, uputio sam APIS-u mail sljedećeg sadržaja:
      EDIT1: Ups, "slomili" su se redovi u kojima su sa strane iznosi na 8 decimala....
      EDIT2: Evo, sredio sam da bude čitljivije.
Poštovani,
 
Molim Vas da mi objasnite kako u XML datoteci zahtjeva za fiskalizaciju zadovoljiti kontrolu SUM(Iznos osnovica PDV) + SUM(Iznos PDV) + (Iznos PNP) + (Iznos oslobođenja) + (Iznos koji ne podliježe oporezivanju) + SUM(Iznos naknada) +/- 0,01 kuna u slučaju kada se iskazuje više različitih poreznih stopa, kao što je prikazano na ovom primjeru:
 
Napominjem da sam svjestan "krivog zbroja" zaokruženih osnovica, što, međutim, ne utjeće na iznose u XML-datoteci.
 
ISPIS RAČUNA (zaokruženje na 2 decimale):
 
Opis           Količina Cijena     Iznos
----------------------------------------
Stock 0.03          4     7.00     28.00
Liker 0.03          4     6.00     24.00
Mineralna 0.1       3     1.00      3.00
----------------------------------------
UKUPNO kn:                         55.00
                                        
POREZ   Osnov. Potroš.    PDV     Ukupno
----------------------------------------
3%+13%   2.59     .08      .34      3.00
3%+25%  40.63    1.22    10.16     52.00
----------------------------------------
        43.21    1.30    10.49     55.00

POREZ (izračun povratnim stopama na 8 decimala)
3%+13%  2.586206897   0.077586207    0.336206897    3.00000000
3%+25% 40.625000000   1.218750000   10.156250000   52.00000000
--------------------------------------------------------------
       43.211206897   1.296336207   10.492456897   55.00000000

IZVADAK ODGOVARAJUĆEG XML ZAHTJEVA:
<tns:Pdv>
  <tns:Porez>
    <tns:Stopa>13.00</tns:Stopa>
    <tns:Osnovica>2.59</tns:Osnovica>
    <tns:Iznos>0.34</tns:Iznos>
  </tns:Porez>
  <tns:Porez>
    <tns:Stopa>25.00</tns:Stopa>
    <tns:Osnovica>40.63</tns:Osnovica>
    <tns:Iznos>10.16</tns:Iznos>
  </tns:Porez>
</tns:Pdv>
<tns:Pnp>
  <tns:Porez>
    <tns:Stopa>3.00</tns:Stopa>
    <tns:Osnovica>43.21</tns:Osnovica>
    <tns:Iznos>1.30</tns:Iznos>
    </tns:Porez>
</tns:Pnp>
<tns:IznosUkupno>55.00</tns:IznosUkupno>
 
Iz gore navedenog primjera, jasno je da tolerancija Vaše formule nije dovoljna, te da bi trebala iznositi:
+/- onoliko lipa koliko ima različitih stopa PDV-a + 0,01 kn
 
Ukoliko mi ne možete dati objašnjenje kako riješiti gore navedeni problem, molio bih Vas za očitovanje koje bi krajnji korisnici, obveznici fiskalizacije, mogli podastrijeti Poreznoj upravi kada ih traži očitovanje vezano na grešku "v137", a koja je vezana uz gore izneseni problem.
 
Unaprijed zahvaljujem na odgovoru žive osobe i srdačno Vas pozdravljam.
Zanima kakvo je vaše mišljenje o tom problemu (između ostalog, da li padam iz osnovnoškolske matematike jer sam ono jednom markirao), i naravno, što će mi APIS odgovoriti (ako uopće).
Ni od vas ovdje, a ni od njih ne prihvaćam odgovor tipa "porihtaj ručno..." :)
Aug 19 at 3:29 PM
Ne kužim ti točku 2. Kako misliš da je datum gurnut na slijedeći dan? Zar ne čitaš uvijek sistemski datum u trenutku izdavanja računa? Znam da većina u ugostiteljstkim programima vodi u bazi 2 datuma, "datum" i "datum_z" nazovimo ih tako. Ali na računu ispisuješ datum a ne datum_z.

Točku 1. koliko sam shvatio se događa kod korisnika fiske/raverusa? Ili tu grešku imaju i programeri koji fiskalizaciju odrađuju unutar svoje aplikacije?

Točka 3. Štimaj ručno :D Uzmi MPC, odbij PDV i za osnovicu napiši MPC-PDV.
Aug 19 at 3:50 PM
Tocka 2. se moze desiti uslijed krivo definiranog datuma u OSu, sto aplikacija ne moze znati...
Aug 19 at 3:54 PM
A može se stavit provjera da li je datum tekućeg računa manji od najvećeg datuma u računima. Ako je == nešto ne štima.
Aug 19 at 3:59 PM
A ako je veci za 6 sati? :)
Aug 19 at 4:10 PM
Hahahaha. Ma u principu te greške se događaju kada je baterija na matičnoj u klincu pa se datum vrati na 19xx godinu. Tako da ako se taj dio izbjegne sa porukom da se ispravi datum, mislim da se rješio problem za 99,99% slučajeva.
Aug 19 at 4:49 PM
Edited Aug 19 at 6:44 PM
@moremore
Da, vidio sam razne stvari, ali ja imam filozofiju "redundancija je često poželjna".
Primjer: Više puta sam kod knjigovođa vidio kako tzv. Trgovačka knjiga (iz kase, koja nije moj program) štima sa karticama, a razlikuje se od primki/utržaka u knjigovodstvenom servisu, i to zato jer je na kasi zginula pokoja stavka sa kartica, iz kojih se (između ostaloga) "vadi" i ispis trgovačke knjige.
Da se i meni nebi desilo tako nešto, a da ni ja ni korisnik to ne primjetimo, ja imam običaj u posebnu tablicu upisati "sažvakane" utrške (zaključke) i pojedine ulaze, pa ako mi to ne bi štimalo sa karticama, barem bih znao da ne štima i valjda lakše našao o čemu se radi. A i arhivu držim "sa strane".
Zato, da ne narušim tako koncipirane podatke, "knjiženje" zaključka "gurne" datum blagajne na sutrašnji datum i nema, brale, da mi nakucaš račun u zaključeni datum.

Točka 1. se odnosi na sve koji pokušavaju raditi u real-time-u, što sam i ja nadobudno htio, kao, biti će najtočnije :(
Slijed radnji je bio:
  • Imam račun bez vremena i krenem u izdavanje
  • Krenem fiskalizirati, slažem zaglavlje XML-a (pročitam i upišem trenutno sistemsko vrijeme)
  • XML gradim dalje, pa kad dođem na vrijeme računa opet pročitam sistemsko vrijeme, upišem ga u XML i zapamtim ga kao vrijeme računa
  • S tim vremenom generiram ZKI i završim XML
  • Šaljem/primam putem EXE
  • U račun dopišem vrijeme, ZKI, JIR pa kreiram ispis računa, pošaljem ga printeru, i usput (redundancija!) u txt-file sa arhivom (kontrolnom trakom za taj dan)
    E, pa u trenutku između dva čitanja sistemskog vremena se promijeni sekunda i vrijeme u zaglavlju XML-a ispadne manje od vremena računa, tj . v104
Sada vrijeme pročitam jednom i svugdje upisujem to isto vrijeme (naravno, osim kod naknadnog slanja), pa te greške ne može biti.

Točka 3. U stvari to i radim, doduše programski, jer ne stignem ručno kod svih u realnom vremenu :))
Iz zbroja cijele grupe prodajnih iznosa sa istim porezima preračunatom stopom izračunam porez na potrošnju i PDV, koje odbijem od prodajnog iznosa i time dobijem osnovicu.
Izgleda nisi detaljno pogledao, problem nastaje kad tako obradim dvije grupe sa različitim PDV-ovima, ispravno zaokružim na dvije decimale i upišem ih u dva odvojena nod-a u XML-u i onda još u posebni nod XML-a upišem (zbrojeno) osnovicu i iznos poreza na potrošnju.
Jasnije?
Aug 19 at 4:57 PM
Edited Aug 19 at 4:58 PM
@moremore & divkovi1
To stoji, ali ni to vam se na može desiti ako sinhronizirate vrijeme prilikom ulaska u aplikaciju (oni paranoični mogu to obavljati i svaki puni sat, npr)
Ako vas to muči, vidi moj post (za sada pri kraju) Sinkronizacija vremena (BAD CMOS)
Aug 19 at 5:20 PM
Šta se tičke točke 1: a zašto ne napraviš ovako:
  1. korisnik kucka račun i klikne spremi
  2. zapišeš trenutno vrijeme i zapišeš kompletan račun u bazu
  3. kreneš generirati xml, pročitaš trenutno vrijeme i zapišeš u xml
U tom slučaju nema šanse da ti se dogodi da je vrijeme xml-a prije računa zato jer čitaš uvijek isto sistemsko vrijeme. Na ovajk način kako si ti opisao, ako sam dobro shvatio, tebi se lako može dogoditi da bude i 2, 3 sekunde razlike ako je sporija mašina, pa malo šteka bla bla...

Da, točku 3. nisam dobro popratio, i u pravu si. Ali mene toliko živciraju sa tim greškama jer da nas time j.bu nema nikakve veze sa mozgom...
Aug 19 at 6:31 PM
Tvoja točka 2. u vezi moje točke 1. je nepotrebna, jer ja imam "kompletan" račun, osim vremena, ZKI-a i JIR-a.
Dakle, ako u tom trenutku snimam račun, mogu dopisati samo vrijeme, a ZKI I JIR moram dopisati naknadno, poslije fiskalizacije. Zato preskakanjem točke 2. i zapisivanjem vremena poslije fiskalizacije, istovremeno sa ZKI-jem i JIR-om u stvari štedim vrijeme, habanje diska i sl.
Zeka-peka. Poanta je u tome da sam priznao svoj BUG zbog krivog redosljeda radnji i upozorio gdje možda leži zec, ako još netko koristi EXE, vlastitim snagama slaže XML i ako ima sličnih problema.

Što se Fiske tiče (nju ne koristim niti sam ikada probao), u primozgu mi je ostala informacija da se iz aplikacije predaje CSV-datoteka sa podacima o računu i iznosima, pa Fiska iz toga slaže XML, generira ZKI i ostala čudesa, šalje u PU i vraća aplikaciji odgovor.
Ako je točno da aplikacija nema utjecaja na vrijeme u zaglavlju XML-a, i ako se javlja greška 'Datum i vrijeme izdavanja' računa je veće od 'Datum i vrijeme slanja' (v104) tada je logično da od realnog vremena treba oduzeti par sekundi, to staviti u CSV i na račun, čime se može osigurati uvjet da vrijeme računa nije veće od datuma slanja.
Ako premisa iz prethodne rečenice nije točna, ispričavam se, krivo sam shvatio postove, nekako mi se zapelcalo u primozgu da su i korisnici Fiske imali ovaj problem, makar, moram priznati, to mi nije logično ako Fiska kreće u akciju NAKON što je složen CSV,

Što se tiče 2,3 sekunde ako je sporija mašina, za to me zabole, jer te 2,3 sekunde nisu kontra kontrole da je vrijeme računa prije fiskalizacije (zaglavlja XML-a).
Isto tako, te 2,3 sekunde razlike ni ne postoje ako u XML-u koristim uvijek isto vrijeme i to ono koje pročitam u trenutku slaganja zaglavlja XML-a. Poslije fiskalizacije i na računu piše isto to vrijeme, pa svi valjda misle da se kasa vrti na gejmerskom stroju koji odrađuje sve unutar jedne sekunde. Makar su gejmerski strojevi u toj ulozi čista fikcija, činjenica je da se fiskalizacija najčešće i obavi unutar 1-2 sekunde.

I na kraju, mene također dovode do ludila, pa sam zato i oživio aktivnost ove teme, da vas upoznam s time što sam poduzeo, kako vidim problem, kakvi su vaši stavovi o tome i u konačnici da (ako sam s matematikom u pravu) da mi se priključite u pritisku na APIS.
Aug 20 at 7:54 AM
Edited Aug 20 at 11:54 AM
Po točki 1. se potpuno slažem, i tako sam napravio od početka, zapravo škrtareći na još jednom datetime podatku, tako da nisam kod korisnika imao niti jednu takvu grešku pri prvom uspješnom izdavanju/fiskalizaciji računa, jer je u tom slučaju u XML-u na obadva mjesta isti podatak. Napominjem da sam to vrijeme definirao kao vrijeme na db serveru u update triggeru kada se u bazu bilježi izdavanje računa.
Greške su moji imali samo kod naknadnog slanja, ali ne prave, skupne obrade svih nefiskaliziranih računa, koja se u principu radi u značajnom vremenskom odmaku od izdavanja zadnjeg nefiskaliziranog računa.
Problem je nastajao kod korisnika sa server-klijent sustavima, gdje sam dopustio ulazak u program na klijentskom računalu samo ako je razlika lokalnog vremena klijenta u toleranciji +/- 30 s prema serverskom vremenu. I problem je u minus toleranciji, zato jer sam u programu (zbog smanjenja potrebe za skupnom naknadnom fiskalizacijom) napravio da naknadnu fiskalizaciju odrađuje svako sljedeće printanje prvotno nefiskaliziranog (izdanog s ZKI) računa. I tada sam, pogađate, za vrijeme slanja koristio lokalno vrijeme klijentskog računala, i zato su mi sve takve greške bile unutar tih 30 s, kada bi korisnik izdao račun samo s ZKI, te odmah potom printao još jednom, a naknadna fiskalizacija bi prošla.

U vezi točke 3., čestitam na točnoj logičko/matematičkoj analizi, mada bi to trebala biti pučkoškolska matematika, ali i ja si to pokušavam razjasniti dugi niz godina čitajući zakone, pravilnike i svađajući se s trgovcima i knjigovođama, ali bezuspješno. Svi hoće da im se sve slaže u lipu, a čim počnem o trećoj decimali i zaokruživanju, popizde i, poput Porezne, kažu da ih ne zanima kako ali da 'MORA ŠTIMATI!!!' (čitaj: moraš poštimati)...
Zato me jaaako zanima odgovor APIS-a na tvoj upit, pa ako ga uopće dobiješ, nadam se da ćeš ga promptno podijeliti s nama.

Jedino bih ja taj tvoj primjer još dodatno zasolio s povratnom naknadom na još jednoj stavci računa...

Edit: Uostalom, malo sam se poigrao matematike i ostao i sam iznenađen: do iznosa od 100,00 kn postoji čak 1162 (!!!) iznosa čija osnovica (zaokružena na dvije decimale) zbrojena s iznosom PDV na tu osnovicu (također zaokruženim na lipe) ne daje polazni iznos računa:

Iznos: .02 Osnovica: .02 PDV: .01
Iznos: .07 Osnovica: .06 PDV: .02
Iznos: .12 Osnovica: .10 PDV: .03
Iznos: .17 Osnovica: .14 PDV: .04
Iznos: .22 Osnovica: .18 PDV: .05
Iznos: .27 Osnovica: .22 PDV: .06
Iznos: .32 Osnovica: .26 PDV: .07
Iznos: .37 Osnovica: .30 PDV: .08
Iznos: .42 Osnovica: .34 PDV: .09
Iznos: .47 Osnovica: .38 PDV: .10
Iznos: .52 Osnovica: .42 PDV: .11
Iznos: .57 Osnovica: .46 PDV: .12
Iznos: .62 Osnovica: .50 PDV: .13
Iznos: .67 Osnovica: .54 PDV: .14
Iznos: .72 Osnovica: .58 PDV: .15
Iznos: .77 Osnovica: .62 PDV: .16
Iznos: .82 Osnovica: .66 PDV: .17
Iznos: .87 Osnovica: .70 PDV: .18
Iznos: .92 Osnovica: .74 PDV: .19
Iznos: .97 Osnovica: .78 PDV: .20
Iznos: 1.02 Osnovica: .82 PDV: .21
Iznos: 1.07 Osnovica: .86 PDV: .22
Iznos: 1.12 Osnovica: .90 PDV: .23
Iznos: 1.17 Osnovica: .94 PDV: .24
... itd ...
Iznos: 99.42 Osnovica: 79.54 PDV: 19.89
Iznos: 99.47 Osnovica: 79.58 PDV: 19.90
Iznos: 99.52 Osnovica: 79.62 PDV: 19.91
Iznos: 99.57 Osnovica: 79.66 PDV: 19.92
Iznos: 99.62 Osnovica: 79.70 PDV: 19.93
Iznos: 99.67 Osnovica: 79.74 PDV: 19.94
Iznos: 99.72 Osnovica: 79.78 PDV: 19.95
Iznos: 99.77 Osnovica: 79.82 PDV: 19.96
Iznos: 99.82 Osnovica: 79.86 PDV: 19.97
Iznos: 99.87 Osnovica: 79.90 PDV: 19.98
Iznos: 99.92 Osnovica: 79.94 PDV: 19.99
Iznos: 99.97 Osnovica: 79.98 PDV: 20.00
Aug 20 at 2:55 PM
Edited Aug 20 at 8:18 PM
Povratnu naknadu nisam uključio u primjer jer nije bitna. Odbijem ju od prodajnog iznosa pa opet imam to što je u primjeru.
Osim toga, nije mi u interesu da APIS-ov analitičar dobije moždani udar. Možda ipak dobijem nekakvi odgovor.
Već ovo je totalni horor za taj sustav.
Zamisli, (hipotetski) da prizna neumoljivost matematike i izloži se kritici svog nadređenog, pa predloži da se to popegla. Hej, treba obaviti brdo papirologije, promijeniti čak 1-2 retka koda kontrole, pa treba objaviti novu verziju tehničke upute, ili barem ispravku.
I to sve u sustavu koji mora biti potpuno nepropusan za razliku od ePorezne u kojoj je TLS v1.0 (da ne kažem XP) zadovoljavajući - Pa financijski podaci svih pravnih i fizičkih osoba su svakako manje važni od anonimnih računčića koje šalju veliki, srednji i pik-zibner poduzetnici...
Aug 20 at 8:13 PM
gmacarol wrote:
APIS-ov analitičar dobije moždani udar.
Nije li ovo oksimoron?
Aug 22 at 7:35 AM
Edited Aug 22 at 7:36 AM
Ovo što kažeš da treba pritisnuti developere iz APIS-a, odnosno nekog tko je osmišljavao cijeli sustav, pokušao sam početkom uvođenja same fiskalizacije. Slao sam nekakve, po meni, ispravne upite, odnosno zahtjeve za promjenom i nadogradnjom sustava. Čini mi se da sam tada bio onako nadobudan pa sam slao gotovo svaki dan nekakav upit, ali nikada nisam dobio niti povratnu informaciju da su uopće primili moje mailove, ne da su ih pročitali. Nisam čak ni neku odbijenicu u stilu "odjebi sa svojim idejama", nikada dobio. Smatram da bi ih sada, kad počne ta testna nova okolina, trebali zatrpati sa svim našim prijedlozima, odnosno onim s čime smatramo da bi se trebalo primijeniti. Što se tiče njihovog osnovnoškolskog znanja matematike (mislim i na APIS u globalu, kao i na "porezne inspektore" u Poreznoj, to više nema smisla ni komentirati. Inače, imam jednog susjeda, par metara od mene, koji također "radi" u Poreznoj kao inspektor i nekoliko puta mi je došlo da mu ozbiljno zaprijetim nekim vidom fizikalne terapije, baš zbog tog poznavanja materije.
Aug 22 at 9:31 AM
Edited Aug 22 at 9:35 AM
Moram vas demantirati. ODGOVOR OD ŽIVE OSOBE IZ APIS-a JE STIGAO !!!
Doduše, nije baš neki, al je stigao:

Poštovani,

Tolerancija formule ukupnog iznosa po pojedinom računu je definirana od strane Porezne uprave.
Svoje obrazloženje problema i sugestije možete predložiti Poreznoj upravi.
Preporučamo da savjet potražite kod stručnjaka iz područja računovodstva i poreza.
APIS IT pruža podršku vezano za tehničke probleme prilikom povezivanja na sustav Porezne uprave, a navedeni problem nije iz te domene.

S poštovanjem,

Ja se nedam, pa dodatno pitam:

Zahvaljujem na odgovoru uz još jedno pitanje:
Možete li me uputiti koji je odjel Porezne uprave za to nadležan, ili konkretnije, na koju bih adresu svoj upit/sugestiju mogao poslati?

Unaprijed hvala i lijepi pozdrav.

@OzrenKrestan: Inače, imam jednog susjeda... (susjedu), poznamo se iz pesjih šetnji po kvartu, koja "radi" prilično visoko pozicioniran "posao" u odjelu za financijski kriminal. Shvatio sam samo da je njezin nadređeni totalni idiot, da ona ne stiže proučiti sve nove zakone i pravilnike o PDV-u, ali zato jako dobro računa koliko još ima do penzije i da je savršeno upoznata s time koji se praznici daju spojiti s vikendima...
Aug 22 at 9:35 AM
Eeeee, to. Koga pitati, kojeg "stručnjaka" iz Porezne uprave? To je vječno pitanje... Inače, kad naša kolegica, inače vrsna stručnjakinja, sada nije šala, koja i nama vodi knjigovodstvo, naleti na nekakvu nebulozu i zove "stručnjake", nitko joj ništa ne može suvislo i na prvu loptu odgovoriti, nego se i oni moraju posavjetovati sa još većim "stručnjacima" i naravno, odgovor nikada ne dobije.
Aug 22 at 10:37 AM
@gmacarol
Sad mi je žao što ti odmah nisam napisao kakav odgovor očekujem... možda bi bila razlika u par interpunkcijskih znakova...
Aug 22 at 2:08 PM
Evo, stigao je i odgovor na dodatno pitanje:

Poštovani,
Za Vaš slučaj preporučujemo Vam da potražite savjet iskusnog računovođe vezano za računanje poreza koji bi Vam obzirom na iskustvo s tog podrucja mogao dati najbolji savjet.
Eventualno se možete obratiti (i) na mail adresu fiskalizacija@porezna-uprava.hr . Napominjemo da je ova mail adresa ustvari adresa za pitanja iz područja fiskalizacije, a za PDV i ostale poreze je najbolje da Vas uputi sama PU.
Lijepi pozdrav
Fiskalizacija help


Nije ni njima lako, moje pitanje vode pod brojem 64995.

Ček' malo. Kaže "eventualno" jer je navedena adresa namijenjena "za pitanja iz područja fiskalizacije" ?!?
Hm, jel' sam ja postavio pitanje o oporezivanju neprofitnih organizacija ili o tome kako da prilikom fiskalizacije u XML-u zadovoljim zadani uvijet?
Ništa, idem probat pokucat na druga vrata...
Aug 22 at 2:11 PM
Mora vam (ti) se priznati da imate (imaš) živce k'o at (strašnomlat). Ja sam odavno izgubio bilo kakvu volju za bilo kakvom iterakcijom s tim polusvijetom birokracije u Hrvatskoj.
Aug 24 at 11:14 AM
Evo, došao je i odgovor iz Porezne uprave:

Poštovani,

vezano uz grešku fiskalizacije „Ukupan iznos na računu“ nije ispravan prema formuli održana je edukacija u Poreznoj upravi tijekom travnja 2016.g. i dodatno je dana uputa referentima PU kako u slučaju razlika do 1 kunu nije potrebno pozivati obveznike, niti se isto smatra greškom.
Također, uskoro će se i sistemski onemogućiti da se takva greška pojavljuje.

S poštovanjem,

Porezna uprava
Aug 24 at 11:28 AM
Tijekom travanja....Hma a oni zbog toga gnjave još i sada...
Osim toga, totalna debilana je njihovo upozorenje da broj računa ne smije imati više od 6 karaktera?!?! Poslao sam im odgovor nekoliko puta da u specifikacijam stoji do 20 karaktera, ali ne... I danas sam imao oko toga fight....!
Aug 24 at 11:50 AM
gmacarol wrote:
u slučaju razlika do 1 kunu nije potrebno pozivati obveznike, niti se isto smatra greškom.
Ja sam zgranut, iskreno ne mogu vjerovati da si ovo dobio kao službeni odgovor državne institucije koja se bavi porezima. Onoga tko je ovo napisao ne da treba otpustiti, nego njega i onoga tko ga je zaposlio u zatvor.

KAKAV JE TO JEBENI RAČUN KOJI JE ISPRAVAN SA 99 LIPA RAZLIKE OSNOVICE+POREZA PREMA IZNOSU ZA PLAĆANJE?

Dao si im i primjer, i formulu za broj toleriranih lipa (broj poreznih skupina +1 za Porez na potrošnju) i opet ne mogu uzeti knjigu iz matematike za 4. osnovne i uključiti primozak!!!
I hajde, kad već nisu ni pametni, ni sposobni, ni vrijedni da promisle, da onda kažu 'OK, ukidamo tu kontrolu, ali vas čekamo na poreznoj prijavi', oni stave granicu na JEDNU KUNU!!! Čitavih STO LIPA!!!

Imam neodoljivu potrebu da otvorim trgovinu čačkalicama, da ih prodajem po kunu i to po sistemu jedna čačkalica - jedan račun i sve takve račune pošaljem na fiskalizaciju s jednom lipom osnovice i nula poreza. Pa nek netko kaže da mi je račun NEISPRAVAN PREMA FORMULI.
Aug 24 at 12:46 PM
gmacarol wrote:
Evo, došao je i odgovor iz Porezne uprave:

Poštovani,

vezano uz grešku fiskalizacije „Ukupan iznos na računu“ nije ispravan prema formuli održana je edukacija u Poreznoj upravi tijekom travnja 2016.g. i dodatno je dana uputa referentima PU kako u slučaju razlika do 1 kunu nije potrebno pozivati obveznike, niti se isto smatra greškom.
Također, uskoro će se i sistemski onemogućiti da se takva greška pojavljuje.

S poštovanjem,

Porezna uprava
Jos da stave to negdje na svoje stranice da bude sluzbeno, pa da mozemo referentima samo poslati link na to :)
Aug 24 at 5:42 PM
Jos da stave to negdje na svoje stranice da bude sluzbeno, pa da mozemo referentima samo poslati link na to :)
Ovo je najbitniji dio :)
Aug 24 at 5:42 PM
gmacarol, mi možeš proslijediti tu mail poruku na infoMAJMUMolis.hr ako ti nije problem?
Aug 24 at 9:27 PM
Nije, evo...
Sep 15 at 1:36 PM
moremore wrote:
gmacarol, mi možeš proslijediti tu mail poruku na infoMAJMUMolis.hr ako ti nije problem?
Joj sad i mene zezaju s ovim !!!!!
Jel moze i meni netko proslijediti na dinko@comperio.hr? ;)
Sep 16 at 8:25 AM
Ajd pliz i meni toliko da riješim bar taj problem

sasa@bestek.hr

Thx
Sep 16 at 10:13 AM
Poslano obojici
Sep 16 at 11:26 AM
Ne budi ti teško, molim da to isto proslijediš i na milan.galant@popsy.com.hr

Hvala !
Sep 16 at 12:02 PM
Bilo bi bezgranično lijepo da to netko digne na neki ftp, kako bi svima bilo dostupno.. sadržaj je svima nama na ovom forumu zanimljiv.

thanks !
Sep 16 at 12:48 PM
Ili ovako? :)

From: "fiskalizacija" fiskalizacija@porezna-uprava.hr
To: "XXX" XXX@XXX.hr
Sent: Wednesday, August 24, 2016 11:15 AM
Subject: Odgovor: 'Ukupan iznos na računu' nije ispravan prema formuli


Poštovani,

vezano uz grešku fiskalizacije „Ukupan iznos na računu“ nije ispravan prema
formuli održana je edukacija u Poreznoj upravi tijekom travnja 2016.g. i
dodatno je dana uputa referentima PU kako u slučaju razlika do 1 kunu nije
potrebno pozivati obveznike, niti se isto smatra greškom.
Također, uskoro će se i sistemski onemogućiti da se takva greška pojavljuje.

S poštovanjem,

Porezna uprava
Sep 16 at 2:27 PM
Edited Sep 16 at 2:54 PM
Evo, "bezgranično lijepo" od mene: ZIPani odgovor PU u eml formatu

Usput:
Ima li netko da je već složio kakav proxy preko kojeg bi XP mogao do testne fiskalizacije, onako za probu?
Sep 16 at 2:34 PM
Link bas i ne radi :)
Sep 16 at 3:01 PM
gmacarol wrote:
Evo, "bezgranično lijepo" od mene: ZIPani odgovor PU u eml formatu

Usput:
Ima li netko da je već složio kakav proxy preko kojeg bi XP mogao do testne fiskalizacije, onako za probu?
Sorry, pes me je došao tražiti ručak, pa je stvar izmakla kontroli... :)
Evo sada radi i ovdje i gore.

I opet, usput:
Ima li netko da je već složio kakav proxy preko kojeg bi XP mogao do testne fiskalizacije, onako za probu?