Davčne blagajne

VKR77 je 2. dec 2015 ob 20:21 izjavil:

Da mi smo se , nismo znali kako če stabilno sustav raditi. Za probleme koji se događaju extremno rijetko FURS če sigurno imati toleranciju. Najvažnije je da su riješene duplikacije, odnosno uzastopno slanje istog računa kod lošeg interneta. Kod vas je riješena veza između poslovnog prostora i slanja računa, a među nama, kod vas je zakonodavac dobro opisao zakonom osjetljive segmente fiskalizacije, reklo bi se bingo
za FURS, ako svi poštuju sustav .

Ideja u prvom postu je bila da bi bilo dobro logirati svaku komunikaciju sa FURS-om i to potpisani request kao i potpisani response za svaki request. Dobro je loviti sve response exception, uključujuči i web exception, te ih takođe logirati..

U svakom slučaju, svaki prijedlog za povečanje, prije svega naše sigurnosti je dobro došao..

Dobra ideja, bom verjetno res napravil logiranje vse dogodkov. Hvala.

zhigatsey je 26. nov 2015 ob 15:00 izjavil:

.....
Ne vem kako da sem zgrešil vprašanje 165. Sedaj je vse jasno. Ker je v našem primeru vsak račun lahko plačan z gotovino, bomo pač vsem računom generirali FURS številko, ZOI ipd., davčno bomo potrjevali samo tiste ki bodo res plačani z gotovino, ker itak ni panike če na FURS manjkajo vmes zaporedne številke...

Tole mislim, da ni res! Na FURS morajo priti zaporedne številke!

Ni treba. Če imate enotno številčenje za gotovinske in negotovinske račune, bodo vmes pri potrjevanju pač manjkali. Se pravi bo FURS dobil 1,3,4,7..., 2,5 in 6 pa so negotovinski.

ivanhoe5x je 3. dec 2015 ob 16:46 izjavil:

Ima še kdo problem s podpisovanjem prijave poslovnega prostora v PHP? Napaka S03: Digitalni podpis ni ustrezen? Kako razrešiti...
Moja koda za izvedbo podpisa je naslednja:

 $rootElem = $PEXML->getElementsByTagName("BusinessPremiseRequest")->item(0);
 $sigNode = $rootElem->appendChild(new DOMElement('Signature'));
 
 //$sigNode = new DOMElement('Signature');
 $sigNode->setAttribute('xmlns', 'http://www.w3.org/2000/09/xmldsig#');
 $signedInfoNode = $sigNode->appendChild(new DOMElement('SignedInfo'));
 
 $canonMethodNode = $signedInfoNode->appendChild(new DOMElement('CanonicalizationMethod'));
 $canonMethodNode->setAttribute('Algorithm', 'http://www.w3.org/TR/2001/REC-xml-c14n-...
 
 $signatureMethodNode = $signedInfoNode->appendChild(new DOMElement('SignatureMethod'));
 $signatureMethodNode->setAttribute('Algorithm', 'http://www.w3.org/2001/04/xmldsig-more#...
 
 $referenceNode = $signedInfoNode->appendChild(new DOMElement('Reference'));
 $referenceNode->setAttribute('URI', '#test');
 
 $transformsNode = $referenceNode->appendChild(new DOMElement('Transforms'));
 $tr1Node = $transformsNode->appendChild(new DOMElement('Transform'));
 $tr1Node->setAttribute('Algorithm', 'http://www.w3.org/2000/09/xmldsig#envel...
 
 $digestMethodNode = $referenceNode->appendChild(new DOMElement('DigestMethod'));
 $digestMethodNode->setAttribute('Algorithm', 'http://www.w3.org/2001/04/xmlenc#sha256...
 
 $referenceNode->appendChild(new DOMElement('DigestValue', $signatureDigest));
 
 $signedInfoNode = $PEXML->getElementsByTagName('SignedInfo')->item(0);
 $sigNodeXMLString = $signedInfoNode->C14N(false, true);
 
 openssl_sign($sigNodeXMLString, $signature, $raw_cert['pkey'], OPENSSL_ALGO_SHA256);
 
 $signatureValue = base64_encode($signature);
 $sigNode = $PEXML->getElementsByTagName('Signature')->item(0);
 $sigNode->appendChild(new DOMElement('SignatureValue', $signatureValue));
 
 $certData = openssl_x509_parse($raw_cert['cert']);
 
 $sigNode = $PEXML->getElementsByTagName('Signature')->item(0);
 
 $keyInfoNode = $sigNode->appendChild(new DOMElement('KeyInfo'));
 $x509DataNode = $keyInfoNode->appendChild(new DOMElement('X509Data'));
 
 $x509IssuerSerialNode = $x509DataNode->appendChild(new DOMElement('X509IssuerSerial'));
 $issuer = $certData['issuer'];
 $temp = array();
 foreach ($issuer as $key => $val) {
 $temp[] = $key . '=' . $val;
 }
 $issuerString = implode(',', $temp);
 $x509IssuerSerialNode->appendChild(new DOMElement('X509IssuerName', $issuerString));
 $x509IssuerSerialNode->appendChild(new DOMElement('X509SerialNumber', $certData['serialNumber']));
 $x509DataNode->appendChild(new DOMElement('X509SubjectName', trim(str_replace("/", " ", $certData['name']))));
 $fileName2 = 'podpisanFURS.xml';
 
 $PEXML->save($file_path_xml.$fileName2);
 

Hvala vsakemu, ki bi karkoli pomagal. Pripravljen sem tudi plačati.

Prosim uporabljaj "st.koda php" značko za lepljenje kode. -- moderator

Enako se dogaja tudi pri meni - račun je podpisan na enaki način pa je OK, pri prostoru pa javi napako S003...

BOCo. je 4. dec 2015 ob 09:57 izjavil:

 $referenceNode->setAttribute('URI', '#test');

Ni mogoče tukaj #data?

Tudi z "data" je odgovor enak (vsaj pri meni).

S tem, da če ročno nastavim requestu atribut id na data ali test mi pa javi da sporočilo ni v skladu z xml shemo...

Se strinjam s sklepanjem glede preverjanja... Ni mi jasno ali je potrebno podpisati celoten dokument z ovojnico vred ali samo request. (logično bi mi bilo da samo request, saj je on označen z identom na katerega se sklicuje referenca v podpisu..) ... adijo pamet...

Aplikacija za preverjanje kode deluje tudi na produkciji?

Ja, skoraj sigurno je to. Upam, da se bo oglasil kdo, ki to obvlada in bo pripravljen prilepiti kodo za podpis.

Nič ne bo narobe, če potrjuješ tudi negotovinske račune.

Je pa to, kar sem zgoraj napisal, zagotovo res. Mislim, da imaš to tudi v FAQ, vendar se mi ne da brskat.

Zaporedne številke računov si morajo v skladu s petim odstavkom 5. člena ZDavPR vsako
poslovno leto slediti v neprekinjenem zaporedju po vsakem poslovnem prostoru zavezanca ali
po elektronski napravi za izdajo računov v poslovnem prostoru zavezanca. Zaporedne številke
računov si morajo po vsakem poslovnem prostoru ali elektronski napravi slediti v enem
neprekinjenem zaporedju, pri čemer zaporedne številke računov lahko vsebujejo le številke.

http://www.fu.gov.si/fileadmin/Internet... (stran 88 - vprašanje 160)

Potem pa sledi 165. vprašanje

Finančna uprava v postopku potrjevanja računov ne bo preverjala zaporedja številčenja
računov. Zaporedje številčenja računov se bo preverjalo v naknadnih analizah in postopkih
nadzora. Pomembno je, da obstaja ustrezno zaporedno številčenje računov v knjigovodstvu
zavezanca ter da je le to jasno predpisano z internim aktom zavezanca. To pomeni, da bodo v
postopku potrjevanja računov obstajale »luknje« pri številkah računov, ki se bodo potrjevali, če
zavezanec uporablja isto zaporedje številčenja računov za račune, ki so plačani neposredno na
transakcijski račun. Predlagamo (neobvezno), da v takšnih primerih zavezanec v potrjevanje
pošilja tudi račune, ki so plačani neposredno na transakcijski račun zavezanca.

BOCo. je 4. dec 2015 ob 16:39 izjavil:

Zaporedne številke računov si morajo v skladu s petim odstavkom 5. člena ZDavPR vsako
poslovno leto slediti v neprekinjenem zaporedju po vsakem poslovnem prostoru zavezanca ali
po elektronski napravi za izdajo računov v poslovnem prostoru zavezanca. Zaporedne številke
računov si morajo po vsakem poslovnem prostoru ali elektronski napravi slediti v enem
neprekinjenem zaporedju, pri čemer zaporedne številke računov lahko vsebujejo le številke.

http://www.fu.gov.si/fileadmin/Internet... (stran 88 - vprašanje 160)

Potem pa sledi 165. vprašanje

Finančna uprava v postopku potrjevanja računov ne bo preverjala zaporedja številčenja
računov. Zaporedje številčenja računov se bo preverjalo v naknadnih analizah in postopkih
nadzora. Pomembno je, da obstaja ustrezno zaporedno številčenje računov v knjigovodstvu
zavezanca ter da je le to jasno predpisano z internim aktom zavezanca. To pomeni, da bodo v
postopku potrjevanja računov obstajale »luknje« pri številkah računov, ki se bodo potrjevali, če
zavezanec uporablja isto zaporedje številčenja računov za račune, ki so plačani neposredno na
transakcijski račun. Predlagamo (neobvezno), da v takšnih primerih zavezanec v potrjevanje
pošilja tudi račune, ki so plačani neposredno na transakcijski račun zavezanca.

Računovodsko morajo biti računi zaporedno številčeni, brez lukenj. Ampak ker niso vsi računi zavezani k potrditvi, bodo pri FURSU registrirani samo gotovinski in njihove številke. To pomeni da lahko pri FURSU obstajajo luknje v zaporednih številkah, pri vas pa ne, ker imate vmes tudi negotovinske račune.

Mimogrede, ni obvezno, da začneš številčiti z 1, lahko naprimer komot začneš s 500001. Edino v aktu je fajn te stvari opredeliti.

Preveri, če imaš v xmlju s prijavo prostora closingtag in ga vrzi ven. Ta namreč določa, da je poslovni prostor zaprt. Seveda ponovi prijavo prostora.

vuego je 4. dec 2015 ob 20:01 izjavil:

Preveri, če imaš v xmlju s prijavo prostora closingtag in ga vrzi ven. Ta namreč določa, da je poslovni prostor zaprt. Seveda ponovi prijavo prostora.

Saj deluje, le "BusinessPremiseID" v prijavi prostora mora biti enaka na računu.
Hvala, tvoj način deluje.
Kako pa preverjaš ali je odgovor res s FURSA?

Kar se tiče številčenja:
Številčenje izdanih računov

Po ZDavPR mora biti številka računa sestavljena iz treh delov:
-oznake poslovnega prostora zavezanca,
-oznake elektronske naprave za izdajo računov
-zaporedne številke računa (zaporedne številke si morajo vsako poslovno leto slediti v neprekinjenem zaporedju po vsakem poslovnem prostoru zavezanca ali po elektronski napravi za izdajo računov v poslovnem prostoru zavezanca.
TOREJ JE POTREBNO ZAPOREDNO ŠTEVILČENJE. Če so vmes negotovniski računi, jih je prav tako potrebno potrjevati preko FURS (ZOI -> EOR)! Zaradi števičenja seveda!
Lahko pa se seveda gotovinski računi ločeno označijo z dodatno oznako! Le-ti ponovno: MORAJO slediti zaporedno!

VSEKAKOR PA JE TREBA PREJ SPREJETI/NAPISATI INTERNI AKT o številčenju računov! le-tega je potrebno pokazati ob morebitnem nadzoru!


Zanima pa me sledeče:
Potrebno je dati tudi vse informacije o poslovnem prostoru davčni upravi!
Ali je to možno zahtevati preko eDavki?
(nisem zasledil obrazca)

mimogrede:
Tudi tale nalepka bo potrebna na vidnem mestu v prostoru! :)
http://www.fu.gov.si/fileadmin/Internet...

Primer 2: Uporabljam isto zaporedje številčenja računov za račune, ki so plačani z gotovino, in račune, ki so plačani neposredno na transakcijski račun. Ali je potrebno v tem primeru v potrjevanje pošiljati tudi negotovinske račune (račune, ki so plačani neposredno na transakcijski račun)? Če jih ne bom pošiljal v potrjevanje, bodo na Finančni upravi obstajale luknje v zaporedju številk računov.
Finančna uprava v postopku potrjevanja računov ne bo preverjala zaporedja številčenja računov. Zaporedje številčenja računov se bo preverjalo v naknadnih analizah in postopkih nadzora. Pomembno je, da obstaja ustrezno zaporedno številčenje računov v knjigovodstvu zavezanca ter da je le to jasno predpisano z internim aktom zavezanca. To pomeni, da bodo v postopku potrjevanja računov obstajale "luknje"< pri številkah računov, ki se bodo potrjevali, če zavezanec uporablja isto zaporedje številčenja računov za račune, ki so plačani neposredno na transakcijski račun. Predlagamo (neobvezno), da v takšnih primerih zavezanec v potrjevanje pošilja tudi račune, ki so plačani neposredno na transakcijski račun zavezanca.

Iz odgovora na 165. vprašanje se mi zdi logično, da imaš lahko za negotovinske račune svoje številčenje (če je 100%, da bodo ti računi plačani na TRR).
Jaz imam ločeno številčenje, vendar bomo potrjevali tudi negotovinske račune, ker se v praksi redno dogaja, da želijo stranke tudi te kdaj plačani z gotovino ...

Pozdravljeni,
imam težave s potrjevanjem računov na sistemu Windows Xp.
Upošteval sem vse nasvete iz tega foruma, inštaliral Windows XP SP3, dodal .NET Framework 4.0, v register sem dodal zapis, ki ga je napisal @pix. Kasneje še namestil tale dodatek KB3055973 (https://www.microsoft.com/en-us/downloa... in zadeva se še vedno zalomi pri vzpostavljanju povezave s strežnikom. Dobim error:

System.Net.WebException : The underlying connection was closed: An unexpected error occurred on a send.
System.IO.IOException : Unable to read data from the transport connection: Obstoječo povezavo je prisilno zaprl oddaljeni System.Net.Sockets.SocketException : Obstoje?o povezavo je prisilno zaprl oddaljeni gostitelj

Trenutek za tem sem račun isti račun z enako verzijo programske opreme in enakimi konfiguracijami (Tls1.0) potrdil na drugemu računalniku z nameščenim Windows 7 je vse steklo kot mora. Ima še kdo enak problem?

Hvala za odgovore in nasvete.
Lp

Razbijam si glavo s stvarjo, za katero sem mislil, da bo enostavna: izpis QR kode na račun v tekstovnem načinu - z uporabo ESC komand. Na mizi imam tri tiskalnike: STAR TSP700, STAR TSP100 in Posiflex AURA PP7000II. Povsod že izpisujem črtno kodo 128 (recimo v dveh ali štirih vrsticah), vendar bi raje QR.
Podatek (60 mest desetiško) za izpis imam pripravljen.
A lahko kdo zaupa zaporedje sekvenc, da bi to prišlo na papirnat trak?

Primer, ki mi ne deluje (Za STAR tiskalnike):
1Bh 1Dh 79h 53h 30h 31h
1Bh 1Dh 79h 53h 31h 31h
1Bh 1Dh 79h 53h 32h 03h
1Bh 1Dh 79h 44h 31h 00h 30h '206083988331468961524731379511898607095100131561512021514037'
1Bh 1Dh 79h 50h

perci je 5. dec 2015 ob 20:37 izjavil:

Kaj pa PDF417?

Nisem prepričan, če STAR TSP100 in 700 podpirata PDF417. (http://www.star-m.jp/eng/service/userma..., stran 15)

Zupkoo je 1. dec 2015 ob 10:19 izjavil:

Test dela, produkcija mi ne dela..

V javi dobim: trust anchor for certification path not found (Nekaj glede certifikatov mu ne paše..)

Prej smo uporabljal za vzpostavitev TLS : test-tls.cer in pa pk12 ki smo ga dobil. (To je bilo tud vse kar si rabu da je delalo)

Zdej naj bi se uporabljal blagajne.fu.gov.si.cer in pa pk12

Do sem sicer ne pride zaradi napake ampak:
Za preverjanje podpisa je biu prej test-sign.cer zdaj je DavPotRac.cer ?

Kam za vraga pa daš :
Javni ključ izdajatelja SIGOV-CA: sigov-ca.crt.

--------------------------------------------------------------------------------------------------------------

Živjo, danes sem dobil enako sporočilo.. ste našli rešitev?

Glede JSON se moram strinjati. Imajo pa objavljeno JSON shemo.

beno95 je 23. sep 2015 ob 18:41 izjavil:

theanswer3 je 16. sep 2015 ob 16:20 izjavil:

Ok še eno vprašanje. Se komu svita kako se generira MessageID oziroma kaj pač pomenijo te cifre.

V XSD kolobociji http://www.datoteke.fu.gov.si/dpr/files... so zapisali kakšen mora biti "pattern value"
Torej mora biti MessageID take oblike: 12345678-1234-1234-1234-1234567890ab

še zdaj ne vem kaj mora vsebovati messageID, čeprav sem pregledal celotno tehnično specifikacijo 1.5

detroit je 5. dec 2015 ob 15:59 izjavil:

No pa se sem še jaz našel čas za to...jap pozno. Ampak dobivam: C100 Napaka pri obdelavi sporočila, pri registraciji. Je še kdo naletel na podobne težave in kakšni so bili vrzoki?

se popravljam S100

Zdravo,

Tudi jas imam enaka težava, sem preveril JSON vse po dokumentacije, echo je ok... ne vem zakaj mi vrača S100 Sistemska napaka pri obdelavi sporočila... prosim če iznajdeš kakšna rešitev, odgovor.. pošlji tukaj.. vraćam enako :)

lp
UG

inkanet je 6. dec 2015 ob 00:40 izjavil:

Na FURS-ovi strani s tehničnimi specifikacijami so objavljeni primeri sporočil kar precej olajša delo. Je pa zapostvljena "JSON skupnost" saj je večina primerov objavljenih samo za XML. Ker sta obe varianti enakovredni bi bilo pošteno da sta objavljena primera v obeh različicah.

Konkretno bi rabil primer JSON sporočila za storno računa?

Spodnja koda mi vrne napako S002, sporočilo ni v skladu s shemo JSON. Ker ni nobenega primera za JSON sem del ki označuje račun na katerega se storno nanaša (ReferenceInvoice) izpeljal iz primera za XML. Očitno nepravilno =).

 {
    "InvoiceRequest": {
       "Header": {
          "MessageID": "262f64f7-d3fd-72cc-e050-1fb073201f57",
          "DateTime": "2015-12-06T00:31:06"
       },
       "Invoice": {
          "TaxNumber": 10001239,
          "IssueDateTime": "2015-12-06T00:31:07",
          "NumberingStructure": "C",
          "InvoiceIdentifier": {
             "BusinessPremiseID": "1964",
             "ElectronicDeviceID": "1",
             "InvoiceNumber": "15080"
          },
          "InvoiceAmount": -268.9,
          "PaymentAmount": -268.9,
          "TaxesPerSeller": [
             {
                "VAT": [
                   {
                      "TaxRate": 22,
                      "TaxableAmount": 0,
                      "TaxAmount": 0
                   },
                   {
                      "TaxRate": 9.5,
                      "TaxableAmount": -250,
                      "TaxAmount": 0
                   }
                ]
             }
          ],
          "OperatorTaxNumber": 61281808,
          "ProtectedID": "f36d298b501a4f7dcf29e4af4d8e6f7b",
          "ReferenceInvoice": {
             "ReferenceInvoiceIdentifier": {
                "BusinessPremiseID": "1964",
                "ElectronicDeviceID": "1",
                "InvoiceNumber": "15079"
             },
             "ReferenceInvoiceIssueDateTime": "2015-12-06T00:29:55"
          }
       }
    }
 }
 

"ReferenceInvoice": {
"type": "array",.....

{
   "InvoiceRequest": {
      "Header": {
         "MessageID": "262f64f7-d3fd-72cc-e050-1fb073201f57",
         "DateTime": "2015-12-06T00:31:06"
      },
      "Invoice": {
         "TaxNumber": 10001239,
         "IssueDateTime": "2015-12-06T00:31:07",
         "NumberingStructure": "C",
         "InvoiceIdentifier": {
            "BusinessPremiseID": "1964",
            "ElectronicDeviceID": "1",
            "InvoiceNumber": "15080"
         },
         "InvoiceAmount": -268.9,
         "PaymentAmount": -268.9,
         "TaxesPerSeller": [
            {
               "VAT": [
                  {
                     "TaxRate": 22,
                     "TaxableAmount": 0,
                     "TaxAmount": 0
                  },
                  {
                     "TaxRate": 9.5,
                     "TaxableAmount": -250,
                     "TaxAmount": 0
                  }
               ]
            }
         ],
         "OperatorTaxNumber": 61281808,
         "ProtectedID": "f36d298b501a4f7dcf29e4af4d8e6f7b",
         "ReferenceInvoice": [{
            "ReferenceInvoiceIdentifier": {
               "BusinessPremiseID": "1964",
               "ElectronicDeviceID": "1",
               "InvoiceNumber": "15079"
            },
            "ReferenceInvoiceIssueDateTime": "2015-12-06T00:29:55"
         }]
      }
   }
}