Davčne blagajne

Verjetno kličeš napačen naslov.
Obstoječ testni je:
blagajne-test.fu.gov.si:9002/v1/cash_registers
začasni testni pa malo drugače:
blagajne.fu.gov.si:9008/v1/cash_registers

Zdravo,

se kdo slucajno uporablja cURL za komunikacijo s FURSom?

Do menjave certifikatov je vse delalo OK, ko pa certifikat zamenjam in zelim testirati, pa dobivam

SSL certificate problem: self signed certificate in certificate chain

Zacasno bom pac izklopil preverjanje certifikata, ampak vseeno bi rad imel stvari postimane kot je treba.

Ales je 11. nov 2018 ob 15:13 izjavil:

Boš moral malo bolj točno opisati, kako uporabljaš cURL. Pa ne pozabit, da je pri novem FURS-ovem strežniškem certifikatu uporabljeno tudi novo digitalno potrdilo izdajatelja SIGOV-CA. mogoče je prav sprememba slednjega težava pri tebi.

CURLOPT_CAINFO nastavim na path do .pem datoteke (preverjeno pravilna lokacija). To datoteko sem generiral z

openssl x509 -inform der -in sigov-ca2.xcert.crt -out fursserver.pem

Sem si PEM pripravil narobe? Na isti nacin sem zadevo zapakiral s prejsnim certifikatom. Bi moral ta SIGOV-CA rocno instalirati na Ubuntu streznik, da zadeva deluje?

beretnc je 12. nov 2018 ob 07:28 izjavil:

V pem datoteki morata biti oba potrdila izdajatelja - root in intermediate.

Dela!

Najlepsa hvala, glavo sem si razbijal ze par dni, verjetno ne bi nikoli sam razvozlal problema.

Dolzen pivo!

MarjanV je 12. nov 2018 ob 15:22 izjavil:

Tudi mi imamo težave z OpenSSL
Na testnem serverju nam še vedno vse deluje.
Na produkcijskem serverju pa ne.

Lepo prosim, če mi lahko malo bolj pomagate z rešitvijo - oba certifikata v eni PEM datoteki

Marjan

Tole bi moralo zgenerirat PEM z obema:

openssl x509 -inform der -in sigov-ca2.xcert.crt -in si-trust-root.crt -out furs.pem

Pozdravljeni,

Se je morda kdo soočal z napako S004 Identifikator digitalnega potrdila ni ustrezen (JSON). Serijsko številko in ostale podatke sem pridobil preko openssl x509 iz mojega .pem testnega certifikata (pretvorjen iz .p12 pridobljen s strani fursa).

Hvala!

mm&r je 22. jan 2019 ob 21:26 izjavil:

Poglej JWS header kakšno serijsko številko digitalnega potrdila imaš notri, pa če je zapisana kot integer, ali jo imaš kot hex.

Super, to je rešilo težavo. Serijska je bila v napačnem formatu. Hvala.

Zanima me še kako ste definirali prostor in elektronsko napravo v primeru spletne aplikacije. Sem poizkusil povprašati na fursu ampak niso ravno preveč bogati v svojih odgovorih, pošljejo samo link do dokumentacije :D Se pravi plačila v spletni aplikaciji ki ponuja samo storitve (membership ipd.). NI trgovina in ni pošiljanja paketov oz prostora kjer bi se pakirali, striktno vse prek strežnika. Kateri je v tem primeru poslovni prostor in elektronska naprava? Sploh v samem business premise dokumentu, kjer se navaja naslov.

Pa čisto tako informativno/ idejno glede same prijave poslovnega prostora. Je to enkratna prijava ali pred vsako potrditvijo računa? Na kakšen način se ta dva dokumenta povezujeta? Se pred fiskalizacijo samo pošlje ločena prijava prostora kot nek session ali se dokumenta povezujeta prek npr. message id? Vsaj tako sem razbral iz dokumentacije - oba dokumenta imata enak message id.

100x hvala :)

DamijanD je 23. jan 2019 ob 10:40 izjavil:

Prostor potrdiš samo 1x. Kaj je pa poslovni prostor, pa najbolje, da ti FURS pove.

Se pravi enkrat lifetime? Hvala ti!

Poskušam se povezati na JSON storitev za potrjevanje računov iz node.js, pa imam težavo že pri echo opearaciji:

const request = require('request');
const fs = require('fs');

process.env['NODE_TLS_REJECT_UNAUTHORIZED'] = 0;

const p12 = fs.readFileSync(__dirname + '/10537945-1.p12');

function echo() {
  const data = { EchoRequest: 'furs' };

  const options = {
    url: 'https://blagajne-test.fu.gov.si:9002/v1/cash_registers/echo',
    headers: {
      'Content-Type': 'application/json; charset=UTF-8'
    },
    agentOptions: {
      pfx: p12,
      passphrase: 'N7YMPO3NQEBW'
    },
    data: { EchoRequest: 'furs' }
  };

  request.post(options, (error, response, body) => {
    console.log(body);
  });
}

echo();

namreč vedno vrne

{ "EchoResponse": "" }

Lahko kdo pomaga?

Fursov certifikat je po mojem mnenju potreben za verifikacijo odgovora - da veš, da je res prišel od fursa.
Po nasvetu sem zamenjal "request" z "node-libcurl" in sedaj echo deluje, imam pa težavo pri prijavi poslovnega prostora:

 
{
  "BusinessPremiseResponse": {
      "Header": {
          "MessageID": "4e64a93a-40fa-4c02-afb1-488534b85e4c",
          "DateTime": "2020-02-09T17:48:08"
      },
      "Error": {
          "ErrorCode": "S004",
          "ErrorMessage": "Identifikator digitalnega potrdila ni ustrezen"
      }
  }
}

header oblikujem na naslednji način:

const messageHeader = {
  alg: 'RS256',
  subject_name: 'C = SI, O = state-institutions, OU = DavPotRacTEST, OU = 10537945, serialNumber = 1, CN = TESTNO PODJETJE 1462',
  issuer_name: 'C = SI, O = state-institutions, CN = Tax CA Test',
  serial: 404087658474032914
};

mislim, da je FURS zaklenil dostop iz tujih IPjev, če je to lahko problem v tem primeru.

Ja, po vsej verjetnosti je bil res problem zaradi prepoznanega IPja iz tujine - čeprav je server dejansko v Sloveniji, je pa domena gostovana na CloudFlare in verjetno kakšen proxy vmes zmoti fursov strežnik. So na fursu dodali IP kot izjemo in sedaj deluje.

Se je kdo že lotil menjave certifikatov, ki so jo napovedali za november?

Je sploh potrebno karkoli posodobiti, če uporabljamo CA bundle root + intermediate? Torej v .pem ključu si-trust-root.crt in sigov-ca2.xcert.crt?

kuall je 7. okt 2020 ob 21:46 izjavil:

če imaš takole kodo ti ni treba nič delat, ne?

ServicePointManager.ServerCertificateValidationCallback += new System.Net.Security.RemoteCertificateValidationCallback(CertCheck);

private static bool CertCheck(object sender, X509Certificate cert,
X509Chain chain, System.Net.Security.SslPolicyErrors error)
{
return true;
}


kaj pa je sploh točno prednost, da namesto return true daš preverjanje? saj približno se mi sanja ampak kakšna jasna razlaga bi prav prišla.

če imaš kodo jo prilimaj sem, ker un demo od fursa tudi takole dela se mi zdi (ne preverja).

Gre se za to, da v tvojem primeru lahko nekdo zmanipulira DNS, ki ga uporabljaš (ali kakšno izmed drugih komponent sistema) in preusmeri zahtevke na svoj strežnik (ker ne preverjaš, kam se pošiljajo).
Seveda pa je drugo vprašanje, kaj točno bi s tem res pridobil oz. kakšno škodo bi ti naredil :)

Dokler samo sprasujes kaj lahko gre narobe, ce certifikata ne preverjas, ni problema. Ce pa dejansko zelis kaj taksnega implementirati, pa se prosim ne dotikaj vec kode.

Namen ServicePointManager.ServerCertificateValidationCallback je implementacija svoje logike validiranja. Naceloma je to napacno, razen ce je namen se dodatno omejiti kateri certifikati so dovoljeni (pa se v tem primeru se lahko hitro kaj narobe implementira!), ce pa kar onemogocis preverjanje, se pa gre za malomarnost.

A hočeš povedat, da ServerCertificateValidationCallback sploh ni potreben in se ustreznost server certifikata preverja samodejno v ozadju? To bi bilo meni logično.
Vem da če server certifikat npr preteče (da ga niso admini na serverju obnovili) potem bo tvoj app metal napake brez ServerCertificateValidationCallback, z njim pa ne.

Ja to je razumljivo.

To se pravi če implementiram servercallback, ki vrne true, pol je isto, kot da ne preverja sploh certifikata. Je pa po drugi strani manj verjetnosti, da bo crknila fiskalizacija, če na serverju kaj mutijo s certifikatom, da postane neveljaven, kar se kar pogosto zgodi, no za furs ne vem, tam najbrž ne, na splošno govorim.

Certifikat se ponavadi namesti na vsak računalnik, kjer laufa blagajna.

In zdej ko bo nov server certifikat morajo svoje blagajne spreminjat samo uni programerji, ki delajo kakšno ročno preverjanje certifikata. npr če bi prav pribil ime server certifikata ali izdajatelja itd v ta callback pol bi imel zdej probleme.

Ne ni to moj cilj. Moj cilj je malo bolje razumet vse skupaj, nič drugega. Se mi zdi, da zdj razumem.

Ales, ravno to sem poizkusil, kar si predlagal, ampak se nič ne zgodi. Niti mi ne javi nobene napake, niti se ne spremeni veljavnost aplikacije.

Ima kdo idejo kaj bi bilo narobe pri fiskalizaciji dobropisa?

FURS zavrača z napako
Request error (S002): Sporočilo ni v skladu s shemo JSON

Request je identicen tistemu ki je tudi v (neki drugi) FURSovi dokumentaciji z njihove strani, cim dodamo ReferenceInvoice crknejo stvari. Uradna dokumentacija je hudo skrta glede dobropisa/storno podatkov.

Iz istega okolja normalno fiskaliziramo racune.

JSON je enak temu

Sporočilo s podatki o izdanem računu TRGOVINA1-BLAG2-146  s katerim se stornira račun št. TRGOVINA1-BLAG2-145:

<fu:InvoiceRequest Id="test">
                                   <fu:Header>
                                               <fu:MessageID>3e25fffd-3112-4c92-8e05-018341842b47</fu:MessageID>
                                               <fu:DateTime>2015-09-07T12:48:39</fu:DateTime>
                                   </fu:Header>
                                   <fu:Invoice>
                                               <fu:TaxNumber>10000658</fu:TaxNumber>
                                               <fu:IssueDateTime>2015-09-07T12:48:39</fu:IssueDateTime>
                                               <fu:NumberingStructure>B</fu:NumberingStructure>
                                               <fu:InvoiceIdentifier>
                                                           <fu:BusinessPremiseID>TRGOVINA1</fu:BusinessPremiseID>
                                                           <fu:ElectronicDeviceID>BLAG2</fu:ElectronicDeviceID>
                                                           <fu:InvoiceNumber>146</fu:InvoiceNumber>
                                               </fu:InvoiceIdentifier>
                                               <fu:InvoiceAmount>-66.71</fu:InvoiceAmount>
                                               <fu:PaymentAmount>-66.71</fu:PaymentAmount>
                                               <fu:TaxesPerSeller>
                                                           <fu:VAT>
                                                                      <fu:TaxRate>22.00</fu:TaxRate>
                                                                       <fu:TaxableAmount>-23.14</fu:TaxableAmount>
                                                                       <fu:TaxAmount>-5.09</fu:TaxAmount>
                                                           </fu:VAT>
                                                           <fu:VAT>
                                                                       <fu:TaxRate>9.50</fu:TaxRate>
                                                                       <fu:TaxableAmount>-35.14</fu:TaxableAmount>
                                                                       <fu:TaxAmount>-3.34</fu:TaxAmount>
                                                           </fu:VAT>
                                               </fu:TaxesPerSeller>
                                               <fu:OperatorTaxNumber>12345678</fu:OperatorTaxNumber>
                                               <fu:ProtectedID>ca1cb5819841db0ab2af1e2094f68c66</fu:ProtectedID>
                                               <fu:ReferenceInvoice>
                                                           <fu:ReferenceInvoiceIdentifier>
                                                                       <fu:BusinessPremiseID>TRGOVINA1</fu:BusinessPremiseID>
                                                                       <fu:ElectronicDeviceID>BLAG2</fu:ElectronicDeviceID>
                                                                       <fu:InvoiceNumber>145</fu:InvoiceNumber>
                                                           </fu:ReferenceInvoiceIdentifier>
                                                           <fu:ReferenceInvoiceIssueDateTime>2015-09-07T12:12:54</fu:ReferenceInvoiceIssueDateTime>
                                               </fu:ReferenceInvoice>
                                   </fu:Invoice>
</fu:InvoiceRequest>

Vse to je bilo, fiskalizacija računov je potekala normalno.

Anyway, za naslednje iskalce (kw: dobropis, storno):
ReferenceInvoice je array (ne pa single JSON), kar bi moralo biti v dokumentaciji.

Nope, ne tukaj.

Limam example iz njihove dokumentacije.

True za napake.