» »

Davčne blagajne

Davčne blagajne

««
11 / 27
»»

peterv6i ::

Ok ok.. bo treba prebrat navodila :)

Še ena zanimiva stvar se mi pojavlja (mogoče ima kdo več izkušenj)..
Torej generiranje ZOI številke lokalno se mi izvaja v 7-9 msec kar je ok..
Ko pa Java razred prenesem na bazo (oracle) se tam v PLSQL-u klic izvaja 600-700 msec!?!? (koda je identična, hardver pa je exadata oracleov)..

jype ::

Kje (kako daleč po omrežju) je ta oracle in koliko je obremenjen z drugimi rečmi?

peterv6i ::

Ma java stored procedura se izvaja na samem serverju.. Je pa tako.. da sta 2 node-a (2 instance baze)..
Na enem node-u dela 600-700 msec na drugem pa nekaj sekund :)

To so testni strežniki ene od zavarovalnic ampak niso nevem koliko obremenjeni.. (trenutno ni nobenih večjih obdelav ali česarkoli)..
Samo različno se obnaša en node napram drugemu (koda je pa ista)..

Bom povprašal še na oracle metalink...

dextersi ::

kkranjc

Mi je uspelo ja. Ja mas header.payload. ...
Base64 decode in potem verificiras token s tem key/em iz jwt headerja.

Lp
mama mi kuha vecerjo, večkrat dnevno!!!

Tech2k ::

Ali ima še kdo težave s prvim pošiljanjem v dnevu JSON-a na furs ker je timeout, ki ga imam nastavljenega na 5 sekund? Vsi ostali zahtevki gredo pa potem pod 1 sekundo!

bad_dog ::

Ima kdo informacijo kdaj bo FURS začel izdajati prave certifikate?

Na FURS-ovi spletni strani so objavljeni samo testni certifikati:

DIGITALNA POTRDILA
Digitalna potrdila IS FU

zadnja sprememba 09.09.2015
Povezave do javnih ključev digitalnih potrdil IS FU.

Testno okolje:

Javni ključ digitalnega potrdila za vzpostavitev TLS povezave: test-tls.cer.
Javni ključ digitalnega potrdila za podpis: test-sign.cer.
Certifikat overitelja za TLS potrdilo: sitest-ca.cer.
Certifikat overitelja Tax CA test: TaxCATest.cer.

perci ::

Od ponedeljka jih že izdajajo. Na edavkih imaš novo vlogo. Čez par minut (cca 10) dobiš geslo in prevzameš certifikat.

VKR77 ::

Eno vprašanje, uporaba "ReferenceInvoice"

Pozitiven maloprodajni račun 11 = 9.14 Eur.
Storno računa 11 delajo z negativno račun 12 = -9.14 Eur.

Zgled XML-a
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xd="http://www.w3.org/2000/09/xmldsig#" xmlns:fu="http://www.fu.gov.si/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<fu:InvoiceRequest Id="data">
<fu:Header>
  <fu:MessageID>7bf8bfbc-9609-4fce-b66e-2b5bed0fd38a</fu:MessageID>
  <fu:DateTime>2015-11-22T12:50:23</fu:DateTime>
</fu:Header>
<fu:Invoice>
<fu:TaxNumber>20048592</fu:TaxNumber>
<fu:IssueDateTime>2015-11-19T06:04:38</fu:IssueDateTime>
<fu:NumberingStructure>C</fu:NumberingStructure>
<fu:InvoiceIdentifier>
  <fu:BusinessPremiseID>PP3</fu:BusinessPremiseID>
  <fu:ElectronicDeviceID>EN1</fu:ElectronicDeviceID>
  <fu:InvoiceNumber>12</fu:InvoiceNumber>
</fu:InvoiceIdentifier>
<fu:InvoiceAmount>-9.14</fu:InvoiceAmount><fu:ReturnsAmount>0.00</fu:ReturnsAmount>
<fu:PaymentAmount>-9.14</fu:PaymentAmount><fu:TaxesPerSeller>
<fu:VAT>
  <fu:TaxRate>22.00</fu:TaxRate>
  <fu:TaxableAmount>-7.49</fu:TaxableAmount>
  <fu:TaxAmount>-1.65</fu:TaxAmount>
</fu:VAT>
</fu:TaxesPerSeller>
<fu:OperatorTaxNumber>12345678</fu:OperatorTaxNumber>
<fu:ProtectedID>751643959887698117f96727249566d6</fu:ProtectedID>
<fu:ReferenceInvoice>
  <fu:ReferenceInvoiceIdentifier>
    <fu:BusinessPremiseID>PP3</fu:BusinessPremiseID>
    <fu:ElectronicDeviceID>EN1</fu:ElectronicDeviceID>
    <fu:InvoiceNumber>11</fu:InvoiceNumber>
  </fu:ReferenceInvoiceIdentifier>
  <fu:ReferenceInvoiceIssueDateTime>2015-11-19T05:18:12</fu:ReferenceInvoiceIssueDateTime>
</fu:ReferenceInvoice>
</fu:Invoice>
</fu:InvoiceRequest>
</soapenv:Body>
</soapenv:Envelope>


Ali je primerno, uporabiti "ReferenceInvoice" ?

matijaDS ::

Ja. Kolikor jaz vem je tako edino pravilno.

dextersi ::

Ste že rešili ? Modulu 10 - ne poznam tega, mogoče kdo kaj več lahko pove ? Tnx


Primer / Example:
ZOI: a7e5f55e1dbb48b799268e1a6d8618a3
-> desetiško / decimal notation: 223175087923687075112234402528973166755
Davčna številka / Tax number: 12345678
Datum / Date: 15.8.2015, 10:13:32
Podatkovni zapis/ Data record: 223175087923687075112234402528973166755123456781508151013321
Zadnji kontrolni znak je 1. / Control character is 1.
mama mi kuha vecerjo, večkrat dnevno!!!

matijaDS ::

Modulo 10 pomeni, ostanek pri deljenju z 10. 21/10=2 in ostane 1 torej modulo je v tem primeru 1.

Pri programiranju se za izračun modula ponavadi uporablja znak % 21%10 = 1

Upam da ti je zdaj kaj bolj jasno :)

grandibal ::

Sešteješ vse številke stringa desetiška ZOI + davčna + čas in datum, kontrolni znak je vsota mod 10 (ostanek pri deljenju z 10).

V Delphiju zgleda to takole:
// ZOI
  ZOI := '';
  KodaIzpis := '';

  //DATUM IN ČAS
  tD := StringReplace(eDateTimeR,'T','',[rfReplaceAll]);
  tD := StringReplace(tD,'Z','',[rfReplaceAll]);

  S:=   davcnaSt
      + td
      + invoiceNumber
      + businessPremiseID
      + electronicDeviceID
      + paymentAmount;

  // HASH
  ZOI := IzracunajZOI(S);

  // DESETIŠKO
  KodaIzpis:='';
  i1:=UBigIntsV3.TInteger.create;
  if i1.assignHex(ZOI) then KodaIzpis:=i1.ConvertToDecimalString(false);
  i1.free;

  // DAVČNA
  KodaIzpis:=KodaIzpis+ExtractNumberFromString(frmnastavitve.cxDavcna.text);

  // CAS IZDAJE RACUNA ZA KODO IZPIS
  casIzdajeRacunaQR:='';
  casIzdajeRacunaQR:= casIzdajeRacunaQR +FormatDateTime('yy-mm-dd',issueDateTime);
  casIzdajeRacunaQR:= casIzdajeRacunaQR +FormatDateTime('hh:nn:ss',issueDateTime);
  casIzdajeRacunaQR := StringReplace(casIzdajeRacunaQR, ' ', '', [rfReplaceAll, rfIgnoreCase]);
  casIzdajeRacunaQR := StringReplace(casIzdajeRacunaQR, '-', '', [rfReplaceAll, rfIgnoreCase]);
  casIzdajeRacunaQR := StringReplace(casIzdajeRacunaQR, ':', '', [rfReplaceAll, rfIgnoreCase]);

  KodaIzpis:=KodaIzpis+ casIzdajeRacunaQR;

  // KONTROLNI ZNAK
  kontrolnaVsota:=0;
  for i := 1 to (Length(KodaIzpis)) do
  begin
    kontrolnaVsota:=kontrolnaVsota+strtoint(KodaIzpis[i]);
  end;
  kontrolniZnak:=kontrolnaVsota mod 10;
  KodaIzpis:=KodaIzpis+inttostr(kontrolniZnak);

  // DODA VODILNE NICLE CE JE KRAJSA OD 60
  if Length(KodaIzpis)<60 then
  begin
   for i := 60 Downto Length(KodaIzpis)+1  do
   begin
     KodaIzpis := '0' +  KodaIzpis;
   end;
  end;

  xmldata := xmldata + '<fu:ProtectedID>'+ZOI+'</fu:ProtectedID>';

dextersi ::

Hvala, uspelo !

LP
mama mi kuha vecerjo, večkrat dnevno!!!

dextersi ::

Spodaj je prečrtano besedilo v pogostih vprašanjih (http://www.fu.gov.si/fileadmin/Internet.... Kateri podatki natančno se uporabljajo za QR kodo če to ne velja več ? Thx

QR koda vsebuje podatke v obliki: zaščitna oznaka izdajatelja računa#davčna številka
zavezanca#datum in čas izdaje računa v obliki LLLL-MM-DDTUU:MM:SS. QR koda je
sestavljena iz 29 x 29 modulov z ravnjo odprave napak L. Natisnjena velikost QR kode je vsaj
20 mm x 20 mm. QR koda je obdana s prazno obrobo v velikosti vsaj 2 mm.
mama mi kuha vecerjo, večkrat dnevno!!!

perci ::

Vmes je bil spremenjen pravilnik.

Upam, da spremljaš to stran.

In svoj mailbox kamor dobivaš (če si razvijalec) vsa sporočila o morebitnih spremembah tehničnih specifikacij.

Skratka, odpri zadnje tehnične specifikacije (trenutno je verzija 1.3, v kraktem pa pričakuj še en update)in se prestavi na stran 111.

dextersi ::

Ta navodila imam že zapečena v glavi :/. Lahko ti izluščiš informacijo o tem kateri podatki točno so v QR kodi ? Če preberem testno je HEX#davčnaštevilka#datum ... ? LP
mama mi kuha vecerjo, večkrat dnevno!!!

perci ::

Torej, specifikacije, stran 111, takoj po cititatu iz pravilnika, začne se pri...

Vse tri predvidene kode vsebujejo podatkovni zapis v dolžini 60 numeričnih mest, ki je stavljen iz 4 delov...


... in potem dol do primera.

dextersi ::

Imam polno funkcionalen API pa vendarle ne štekam tega kaj točno želijo tam notri imeti. Primer je ena stvar, navodila je druga stvar, mene pa zanima kaj točno se želi notri imeti. Preko njihovega .apk testiram prebiranje njihove QR kode pa pravi da ni pravilen, torej nekaj tukaj "fali".

Bomo očitno še mal počakal.
mama mi kuha vecerjo, večkrat dnevno!!!

grandibal ::

Meni njihova aplikacija za preverjanje QR kode danes javlja, da je potekla licenca, ter da checksum ni pravilen, čeprav so podatki isti kot prej.
Zgleda, da je problem pri FURSU.

StratoFlier ::

@grandibal: šmrk, tud men ne dela, potekla licenca za preverjanje, ko naložim na novo mi javlja enako, ja poraduš ?

StratoFlier ::

Daš datum na telefonu za par dni nazaj pa spet dela.

pmetod ::

Tech2k je izjavil:

Ali ima še kdo težave s prvim pošiljanjem v dnevu JSON-a na furs ker je timeout, ki ga imam nastavljenega na 5 sekund? Vsi ostali zahtevki gredo pa potem pod 1 sekundo!


Nekaj podobnega sem opazil tudi jaz (pošiljam XML). Občajno se tudi prvo potrjevanje sicer izvede (čakam 4 sekunde), vendar je opazno daljše kot v nadaljevanju dela (tudi pri meni ponavadi od 0,6 do 0,8 s). Res pa da v zadnjih dneh tega nisem oazil, ker testiram tako, da ob zagonu programa pošljem echo.

kovack ::

pozdrav iz HR

probao sam echo demo sa adrese http://datoteke.durs.gov.si/dpr/files/e...

imam test-sign.cer i test-tls.cer u trusted root-u

dobijem ovu grešku : Could not create SSL/TLS secure channel

gdje griješim ?

jeli uopće moguće pristupiti vašim fiskalnim servisima izvan SLO ?

hvala

VKR77 ::

Da to radi iz Hrvatske, zelo dobro. Naj bi personal certifikat in echo.

perci ::

Kolikor vem, je zadeva za tujino blokirana (vsaj na produkciji) in boš moral posebej zaprositi za IP izjemo, če boš hotel uporabljati tuj IP.

kovack ::

hvala, radi echo iz HR na testnom servisu, a za produkcijski me ne čudi da radi samo za SLO, tako radi i HU fiskalizacija npr. mada njihov sustav i nije neki primjer

VKR77 ::

Jaz sem tudi v hrvaščini, dokumentacijo je zelo precej, jaz ne vem, če razumem vse:
- ki ne more biti fiskalizirano
- veleprodaja, način storna i spremembe računov
- načini plačila i fiskalizacija

perci ::

Objavljena je nova verzija specifikacij .


Dodano pojasnilo pri konvertiranju ZOI v desetiško obliko (poglavje 11)
Spremenjen primer JSON sporočila za poslovni prostor (odstranjen element "Closing Tag").
Spremenjena predpisana velikost QR kode (poglavje 11)
Dodan servis za masovno pošiljanje računov (poglavje 6.1.).
Objavljena ISFU produkcijska digitalna potrdila (poglavje 2).

BOCo. ::

perci je izjavil:

Dodan servis za masovno pošiljanje računov (poglavje 6.1.).


Je že kdo poskusil? Meni javlja, da XML ni skladen s shemo pa čeprav zunanji validatorji pravijo, da je. Bo očitno potrebno malo počakati, mogoče še na kakšen testni primer z njihove strani.

MH0 ::

@perci, tako btw.,a tam pri vas kdo razume čemu je namenjena kontrolka?

vajenec ::

Pozdravljeni,

a še komu vrne odgovor v napačni obliki - pošljem testni primer XML za echo (validatorji pravijo, da je OK), s FURSA pa je odgovor v JSON obliki? Je kakšna očitna napaka, za katero še ne vem?

BlackLight ::

Že ima morda kdo pripravljeno stvar v javi in ima mogoče kakšen testen projekt ki ga je pripravljen prosim delit malce?

perci ::

MH0 je izjavil:

@perci, tako btw.,a tam pri vas kdo razume čemu je namenjena kontrolka?

Pri nas? Moja žena ne razume :D.

MH0 ::

@perci pač malo daješ občutek, da si insider.

Po novem torej QR vsaj 12x12mm ali vsaj 14x14mm odvisno ali bereš slovensko ali angleško? :-)

perci ::

MHO, ne bi rad ratal helpdesk tule :).

Lej, kontrolka je pač namenjena temu, da vidiš ali si pravilno poskeniral kodo. App za skeniranje to zazna.

Po novem torej QR vsaj 12x12mm ali vsaj 14x14mm odvisno ali bereš slovensko ali angleško? :-)

Haha, lepa. Težave s tujimi jeziki :). 12mm je prav.

BOCo. ::

BOCo. je izjavil:

perci je izjavil:

Dodan servis za masovno pošiljanje računov (poglavje 6.1.).


Je že kdo poskusil? Meni javlja, da XML ni skladen s shemo pa čeprav zunanji validatorji pravijo, da je. Bo očitno potrebno malo počakati, mogoče še na kakšen testni primer z njihove strani.


Sedaj pa deluje :)

zhigatsey ::

Bom vprašal še tule, kajti od fursa ne dobim odgovora, na tel. se tudi nihče ne oglasi, me pa zanima kako se spopadate s sledečo situacijo -> dilema kdaj označiti račun kot "naknadno potrjevanje".

V dokumentaciji piše, da se račun označi, kot "naknadno potrjevanje" v primeru, ko je izdan brez EOR oznake (če npr. furs ni dosegljiv). Iz tega sklepam, da takšen račun ob izdaji vsebuje samo ZOI, EOR oznake pač ne.

Enostavno bi potem lahko flag "naknadno potrjevanje" v xml dodal takrat, če račun ob davčnem potrjevanju že ima ZOI...

Problem nastane pri računih, za katere vnaprej ne vemo ali ga bo kupec plačal z gotovino (internetna prodaja npr). V dokumentaciji piše, da se ga izda brez EOR oznake in ga je potrebno davčno potrditi v 10 delovnih dneh od dneva plačila računa.

Ali takšen račun ob izdaji mora vsebovati ZOI? Če logično pomislim NE, kajti če na račun damo ZOI je račun obvezno potrebno davčno potrditi -> ZOI vsebuje zaporedno številko in če takšnega računa ne bi davčno potrdili bi nam na FURSU manjkala zaporedna številka.

Ko takšen račun želimo ob prejemu gotovinskega plačila davčno potrditi pridem do dileme ali je potrebno takšen račun označiti kot "naknadno potrjevanje"? Če spet logično pomislimo, gre za naknadno potrjevanje, vendar ne vem točno kako bi program za takšen račun flag "naknadno potrjevanje" v xml-u samodejno označil ob davčnem potrjevanju. Lahko bi gledal datum in čas izdaje... npr. če je datum in čas izdaje računa manjši od trenutnega časa, potem račun označi, kot "naknadno potrjevanje". Ta pogoj pa ni ok, kajti datum in čas izdaje računov bo praviloma vedno manjši od časa davčnega potrjevanja (ekstremen primer npr. natakarja, ko gost naroči pijačo, natakar izda račun, gost pa šele po dveh urah plača račun)...

Zanima me tudi kdaj vaši informacijski sistemi določijo datum in čas izdaje računa (ob kreiranju računa, ob tiskanju računa, tik pred pošiljanjem na furs, ipd.). Sprašujem bolj za izdajanje računov iz zaledja (ne pos blagajna), kjer uporabniki lahko kreirajo račun, ga npr. dva dni urejajo in šele drugi dan zaključijo, potem razni vnosi računov za nazaj (v prejšnji mesec). Sicer bodo takšne situcije bolj malo verjetne ampak vseeno...

Zgodovina sprememb…

denis88 ::

Pozdravljeni vsi skupaj,

najprej zahavala uporabnikom na tem forumu, sem si malce pomagal z vašimi rešitvami pri razvoju apija za davčne blagajne (predvsem kar se windows xp tiče) :)

Imam pa še nekaj vprašanj, za katere nisem našel odgovora, ki bi me zadovoljil do te mere, da bi bil prepričan in sicer:
- ali se poslovni prostor prijavi samo enkrat in sicer pred izdajo prvega računa ali je potrebno potem podatke o poslovnem prostoru pošiljati še pred vsakim računom (torej racun XML in posl.prostor XML)?
- kateri datum je potrebno vpisati za veljavnost poslovnega prostora, takrat, ko delamo elektronsko prijavo s pošiljanjem XMLja ali kateri drugi datum...?
- na naslovu https://blagajne-test.fu.gov.si:9002/ca... lahko preverjamo ali je bil račun davčno potrjen. Še pred par dnevi mi je tukaj kazalo pravilo uro, danes pa (brez spremembe kode na moji strani) kaže napačno uro in sicer je ena ura nazaj (na računu npr. ura 9.57, na tej strani mi pokaže 8.57). Ima še kdo podobno težavo?


Za odgovore se že vnaprej zahvaljujem!

Tech2k ::

Pomemben je datum plačila, če stranka ne plača takoj ga ni in s tem tudi ne moreš zgenerirati ZOI in ne izdaš računa ampak potrdilo.
Poslovni prostor se prijavi samo enkrat in velja za vedno dokler ga ne odjaviš z ClosingTag "Z".

zhigatsey ::

Tech2k je izjavil:

Pomemben je datum plačila, če stranka ne plača takoj ga ni in s tem tudi ne moreš zgenerirati ZOI in ne izdaš računa ampak potrdilo.


Kakšno potrdilo?? Npr. stranki pošljemo račun za neko storitev ali dobavo, za katerega smatraš da ga bo poravnala npr. preko nakazila na trr, stranka pa pride čez dva dni na upravo in želi poravnati račun z gotovino. Ok generiraš ZOI in davčno potrdiš račun. In če je pomemben datum plačila, tukaj ne gre za naknadno potrjevanje računa, čeprav je datum in čas izdaje računa dva dni nazaj. Je tako?

Zgodovina sprememb…

Tech2k ::

Če pride stranka plačat na upravo pač izdaš račun z trenutim datumom plačila (in ne 2 dni nazaj) in ga potrdiš. Če pa nakaže preko trr ti pa ni treba pošiljati na FURS ker ne gre za gotovinsko plačilo.

Potrdilo - nisem dober napisal, izdaš račun brez ZOI, EOR ker ti ga ni potrebno pošiljati na FURS.

Zgodovina sprememb…

  • spremenil: Tech2k ()

zhigatsey ::

Tech2k je izjavil:

Če pride stranka plačat na upravo pač izdaš račun z trenutim datumom plačila (in ne 2 dni nazaj) in ga potrdiš.


In kaj zbrišeš ali storniraš prvotni račun, ter izdaš novega? To že zaradi praktičnih razlogov ne pride v poštev in tudi uporabniki ne bodo spreminjali ustaljenega načina dela. V prvem odstavku vprašanja 83 v FAQ-u davčnega potrjevanja računov tudi piše:

Če bo zavezanec kupcu izdal račun za plačilo na transakcijski račun, a ga bo kupec pozneje
plačal z gotovino neposredno pri dobavitelju, bo moral zavezanec naknadno izvesti postopek
potrditve takega računa. Zavezanec bo moral podatke o računu posredovati davčnemu organu
v desetih delovnih dneh od dneva izdaje računa. V takem primeru kupcu ne bo potrebno izdati
še enega računa, na katerem bi bila EOR oznaka.


In tako še vedno ne vem ali tisti zboldani "naknadno" pomeni tudi označitev naknadnega potrjevanja v xml-u? In tudi če je takšen račun potrebno označiti kot naknadno potrjevanje, še vedno ne vem na kakšen način bi lahko samodejno določil v programu ali gre za naknadno potrjevanje ali ne... Me res zanima kakšen bo odgovor fursa, če bodo sploh odgovorili...

Tech2k ::

Zakaj bi storniral prvotni račun, vpišeš datum plačila in pošlješ na FURS v potrditev. Zakaj bi pa moral naknadno izvesti postopek potrditve če ga v primeru plačila preko trr sploh nisi poslal?

Je pa še vedno opcija 2 in sicer rečeš stranki naj gre plačat preko UPN in s tem nimaš več težav.

SonjaP ::

Pozdravljeni!
Dosedaj sem vas samo brala, sedaj pa tudi mene bega ta dilema ob naknadnem pošiljanju računov v potrjevanje.

Torej: Najbolj logična pot je: račune izdaš normalno in pričakuješ plačilo na TRR. Potem pa nekdo pride plačat na blagajno z gotovino in takrat generiraš ZOI in potrdiš račun na FURS-u.

Vendar je razlaga v FAQ dokumentu taka (vprašanje 165 in tudi druga):
.... Zavezanec mora računu dodeliti številko ob izdaji le-tega. Če ob izdaja računa ni znan način plačila, obstaja pa možnost, da bo plačan z gotovino, je potrebno računu že ob izdaji dodeliti številko v skladu z ZDavPRv obliki OZNAKA_POSLOVNEGA_PROSTORA-OZNAKA_ELEKTRONSKE_NAPRAVE-ZAPOREDNA_ŠTEVILKA_RAČUNA. Opozarjamo, da mora takšen račun poleg predpisane vsebine in oblike Številke računa vsebovati tudi ostale podatke, ki so z ZDavPR predpisani za gotovinske račune (čas izdaje računa, oznako fizične osebe, ki izda račun z uporabo elektronske naprave, zaščitno oznako Izdajatelja računa (ZOI) –v tekstovni obliki in v obliki QR kode), brez enkratne identifikacijske oznake računa (EOR).

Butasto.. ampak mi bomo z ZOI označili vse račune, ki bi bili lahko teoretično plačani z gotovino, ob plačilu pa jih potrdili na FURS-u.
Datum ni datum plačila ampak datum računa.

Kakšna druga ideja?

DayTripper ::

Pozdravljeni,

A še komu od vas Android aplikacija za test QR kode po skeniranju in kliku na Izpis javi Checksum napako?
To se mi zgodi v vseh primerih - ko skeniram moje ali pa njihove kode iz navodil.

Zgodovina sprememb…

MH0 ::

Pri pregledu algoritmov sem naletel na eno nenavadno zadevo.
C# koda za ZOI iz dokumentacije:
            RSACryptoServiceProvider rsaCSP = (RSACryptoServiceProvider)_cert.PrivateKey;
            CspParameters cspParameters = new CspParameters();
            cspParameters.KeyContainerName = rsaCSP.CspKeyContainerInfo.KeyContainerName;
            cspParameters.KeyNumber = rsaCSP.CspKeyContainerInfo.KeyNumber == KeyNumber.Exchange ? 1 : 2;

            RSACryptoServiceProvider rsaAesCSP = new RSACryptoServiceProvider(cspParameters);
            byte[] signaturef = rsaAesCSP.SignData(podatki, CryptoConfig.MapNameToOID("SHA256"));
            string rezultatf = GetMd5Hash(signaturef);

Vrača za enake vhodne podatke, vsakič drugačen rezultat. Kaj sem spregledal?

Prej tega nisem videl, ker sam delam tako:
RSACryptoServiceProvider key = new RSACryptoServiceProvider();
key.FromXmlString(_cert.PrivateKey.ToXmlString(true));
byte[] signature = key.SignData(podatki, "SHA256");
return GetMd5Hash(signature);

Zdaj pa sem šel preverit ali dobim enak rezultat, kot "furs".

        private static string GetMd5Hash(byte[] input) {
            byte[] data = MD5.Create().ComputeHash(input);
            StringBuilder sBuilder = new StringBuilder();
            for(int i = 0; i < data.Length; i++) sBuilder.Append(data[i].ToString("x2"));            
            return sBuilder.ToString();
        }


V "furs" primeru je signature dolg 128, v mojem primeru pa 256 byte-ov.
Certifikat pa pride iz datoteke, ne iz store-a, če to na kaj vpliva?

Zgodovina sprememb…

  • spremenilo: MH0 ()

raufnk ::

Za računanje ZOI uporabljam FURS-ovo kodo in se mi vrednost pri istih vhodnih podatkih ne spreminja... spremeni se pač vsako sekundo, ker za datum računa uporabljam trenutni čas.
lp raufnk

vajenec ::

DayTripper je izjavil:

Pozdravljeni,

A še komu od vas Android aplikacija za test QR kode po skeniranju in kliku na Izpis javi Checksum napako?
To se mi zgodi v vseh primerih - ko skeniram moje ali pa njihove kode iz navodil.


Ravnokar preveril in na mojem telefonu deluje OK (z mojimi kodami in s FURS-ovim primerom).

denis88 ::

Tech2k je izjavil:

Pomemben je datum plačila, če stranka ne plača takoj ga ni in s tem tudi ne moreš zgenerirati ZOI in ne izdaš računa ampak potrdilo.
Poslovni prostor se prijavi samo enkrat in velja za vedno dokler ga ne odjaviš z ClosingTag "Z".


Hvala za odgovor glede prijave poslovnega prostora. Torej pri izdajanju računov se pošilja samo še xml od računov...

Še vedno pa me zanima kateri datum je potrebno vnesti za "Datum začetka veljavnosti podatkov" - P_6.0, stran 70 v tehničnih navodilih 1.4. Je to datum, ko naredimo elektronsko prijavo...?

Prav tako me še vedno zanima ali ima še kdo težave pri preverjanju računov na strani https://blagajne-test.fu.gov.si:9002/ca... - meni namreč še vedno kaže, da je bil račun izdan eno uro prej preden je bil dejansko izdan (npr. na računu uro 14.41, na strani po vnosu eor 13.41)?

Tech2k ::

SonjaP je izjavil:

Pozdravljeni!
Dosedaj sem vas samo brala, sedaj pa tudi mene bega ta dilema ob naknadnem pošiljanju računov v potrjevanje.

Torej: Najbolj logična pot je: račune izdaš normalno in pričakuješ plačilo na TRR. Potem pa nekdo pride plačat na blagajno z gotovino in takrat generiraš ZOI in potrdiš račun na FURS-u.

Vendar je razlaga v FAQ dokumentu taka (vprašanje 165 in tudi druga):
.... Zavezanec mora računu dodeliti številko ob izdaji le-tega. Če ob izdaja računa ni znan način plačila, obstaja pa možnost, da bo plačan z gotovino, je potrebno računu že ob izdaji dodeliti številko v skladu z ZDavPRv obliki OZNAKA_POSLOVNEGA_PROSTORA-OZNAKA_ELEKTRONSKE_NAPRAVE-ZAPOREDNA_ŠTEVILKA_RAČUNA. Opozarjamo, da mora takšen račun poleg predpisane vsebine in oblike Številke računa vsebovati tudi ostale podatke, ki so z ZDavPR predpisani za gotovinske račune (čas izdaje računa, oznako fizične osebe, ki izda račun z uporabo elektronske naprave, zaščitno oznako Izdajatelja računa (ZOI) –v tekstovni obliki in v obliki QR kode), brez enkratne identifikacijske oznake računa (EOR).

Butasto.. ampak mi bomo z ZOI označili vse račune, ki bi bili lahko teoretično plačani z gotovino, ob plačilu pa jih potrdili na FURS-u.
Datum ni datum plačila ampak datum računa.

Kakšna druga ideja?



Jaz bi v vašem primeru pošiljal na FURS vse račune gotovinske in negotovinske, vsi bi imeli tudi EOR ki ga vrne FURS, v primeru pa da kupec potem ne plača se pa pač naredi storno.

Ker kolikor sem "slišal" bodo verjetno čez dve leti uvedli še obvezno pošiljanje negotovinskih plačil.
««
11 / 27
»»


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Davčne blagajne - PHP

Oddelek: Programiranje
116079 (1125) vsepocenv
»

C# davčno potrjevanje

Oddelek: Programiranje
163970 (3439) windigo
»

E-račun

Oddelek: Programiranje
217085 (3848) ivanhoe5x
»

PHP davčna blagajna

Oddelek: Programiranje
187652 (5676) brble
»

[JAVA] HTTPS client

Oddelek: Programiranje
173058 (1788) peterv6i

Več podobnih tem