Davčne blagajne

Dva delovna dneva ali 1 dan po prenehanju razlogov za napako?

Evo mi smo imeli eno manjšo obdelavo od 90000 faktur.. in so bile težave z FURSOM okoli 23:06 - do 23:08 - je FURS imel totalni mrk in za vse javljal timeout...
Tako da.. ni glih bulet proof zadeva ;)

gapipro1 je 5. jan 2016 ob 13:49 izjavil:

Super app je tale "Preveri Račun".

Glede na to da so na netu dostopne davčne številke lahko enostavno preverimo koliko računov so že potrdili.

POST: https://blagajne.fu.gov.si/v1/mobile_cr...

Fajn =)

Kakšne neumnosti pišeš?

1. davčne številke fizičnih oseb (razen SP) niso nikjer javno objavljene
2. pravne osebe ne morejo sodelovati v nagradni igri

peterv6i je 6. jan 2016 ob 07:57 izjavil:

Evo mi smo imeli eno manjšo obdelavo od 90000 faktur.. in so bile težave z FURSOM okoli 23:06 - do 23:08 - je FURS imel totalni mrk in za vse javljal timeout...
Tako da.. ni glih bulet proof zadeva ;)

peter, s tistimi tvojimi 40 računi na sekundo ni sistem niti 0,5% obremenjen.

Poskusi enkrat čez dan, ko je sistem najbolj obremenjen, z malo večjim številom kot 40/s. Pa da vidmo kaj je in kaj ni bulletproof.

Recimo, eden izmed zavezancev je v preteklih dneh BP poslal 400.000 računov v 20 minutah. Pošiljal je 350 računov/s. Šlo bi tudi desetkrat hitreje, vendar zavezanec ni mogel hitreje pripravljati zahtevkov.

Je pa res, da smo imeli ravno takrat, ko si to pošiljal, polminutne težave z vzdrževalnimi deli, ki so povzročila, da ti je od 90.000 padlo 11 računov. Tko, da dramatiziranje o tem, kako smo imeli totalni mrk, ni ravno na mestu.

Aja, predlagam ti, da si povečaš timeout na malo več kot 100ms, ker takih odzivnih časov nikoli nismo garantirali (ampak 20x višje), čeprav jih v praksi zagotavljamo. Trenutno povprečje je 55 ms.

Generalno bi bilo pa prav, da tisti, ki imate masovke, schedulirate te v nočni čas, recimo med 2. in 5. uro (čeprav danes tudi potrjevanje masovk čez dan ne predstavlja nobenega problema).

Jaz sem približno 8 minut stal na blagajni večjega bencinskega servisa in potem dobil račun brez ene šifre, mislim, da je brez EOR. Če ne bi plačal s kartico (plačilo s kartico je del računa), bi najraje odšel in prišel po račun naslednjič, saj se mi je mudilo.

perci je 6. jan 2016 ob 11:48 izjavil:

Je pa dejstvo, jst lahko v telefon vpišem random davčno številko (ni posebne avtorizacije) in mi bo sistem javil, koliko računov in katere, je ta DŠ preverila. In? Kakšna je vrednost tega podatka?

Upam, da se zajebavaš oz. si samo še pjan...

gapipro1 je 6. jan 2016 ob 11:57 izjavil:

Lahko prideš do informacije kje se je neka davčna številka nahajala na določen dan. Ti ne pove točno kdo ta oseba je ampak če kadar koli naletiš na to davčno imaš lahko kak podatek več o njej. Overall gre se za princip sledenja DŠ.

Na linku je basic auth. vzemiracun:vklopirazum

Ne rečem da ni enostavno to da je trenutno samo DŠ za uporabnike, ampak ne nudi pa nobene varnosti. Poznamo pa dobre načine, kako se to pravilno rešuje in ne ni to pošlji po pošti.

Dober point. Ampak ti ne bo uspelo kar baze dol potegnit na ta način.

no comment je 6. jan 2016 ob 12:30 izjavil:

perci je 6. jan 2016 ob 11:48 izjavil:

Je pa dejstvo, jst lahko v telefon vpišem random davčno številko (ni posebne avtorizacije) in mi bo sistem javil, koliko računov in katere, je ta DŠ preverila. In? Kakšna je vrednost tega podatka?

Upam, da se zajebavaš oz. si samo še pjan...

Bom odgovoril kar s tvojim nickom.

čuhalev je 6. jan 2016 ob 11:57 izjavil:

Jaz sem približno 8 minut stal na blagajni večjega bencinskega servisa in potem dobil račun brez ene šifre, mislim, da je brez EOR. Če ne bi plačal s kartico (plačilo s kartico je del računa), bi najraje odšel in prišel po račun naslednjič, saj se mi je mudilo.

Ne zaradi FURS-a.

MH0 je 6. jan 2016 ob 12:53 izjavil:

@perci: Poleg timeoutov pri nastavitvi 4000ms, od vas kdaj dobim še: The remote server returned an error: (500) Internal Server Error.
Tudi kaj takšnega: The request was aborted: Could not create SSL/TLS secure channel.
In takšnega se zgodi: The remote server returned an error: (503) Server Unavailable.
Dalje bomo to raziskovali, ko bo tega preveč. Bulletproof pa sigurno ni.

@peterv6i: Na CRO ni bilo težav.

Predlagam, da nič ne odlašaš ampak kar takoj skupaj poskušamo ugotoviti kje je domnevna napaka.

Sem ti poslal PM.

Najden je "bug" na FURSovem sistemu.
Če izdajaš račune brez povezave na FURS in se vmes zmotiš in izdaš račun za 0,00€ in ga ne storniraš, imaš problem, ko hočeš račune naknadno poslat na FURS. V tem primeru sistem zablokira in "crknejo" vsi računi, ki so bili izdani pred (ali po, ne vem točno) tistim računom za 0,00€.
Problem je že kar razširjen, danes mi je razlagal nekdo z biro servisa in pravi, da ga je že več strank klicalo zaradi tega.
Ne znam bolj tehnično razložit, bodo že drugi, ko se razve naokoli.

Meni se nič ne zdi, samo podajam informacije naprej.

Er333: Saj če malo razmisliš, bi ugotovil, da bi bil to težko bug FURSa - razen, če bi v tem primeru celoten sistem (torej vsem uporabnikom) nehal delovati :-)

A kdo ve za članarine, ki so oproščene DDV (Od članarin se ne obračunava DDV, če prejeta članarina ne predstavlja plačila za opravljanje enakih ali podobnih transakcij, kot jih v okviru dejavnosti iz drugega odstavka 5. člena ZDDV-1 opravlja drug davčni zavezanec.) ali se znesek da v ExemptVATTaxableAmount ali kam drugam?

Ena od strank zahteva zagotovilo, da je moj vmesnik za potrjevanje računov zakonsko ustrezen in da deluje pravilno. Kaj mu naj odgovorim, ker neke garancije, posebej pa ne prevzemanja finančne in kazenske odgovornosti ne bi sprejemal?

Skratka, ti že sedaj odgovarjaš za prekršek, če tvoja blagajna narobe deluje. Ne rabiš ničesar podpisovati, ker zakon tako določa.

V praksi se našim uporabnikom dostikrat dogaja, da stranki izdajo negotovinski račun, pozneje pa stranka pride z gotovino in želi ta račun plačat. Tudi negotovinske račune ob izdaji opremimo z vsemi obveznimi podatki (zaporedna številka, ZOI itd), zato jim lahko naknadno pripnejo gotovinsko plačilo in se takrat brez težav pošljejo v davčno potrjevanje.
Do tukaj vse ok - pred novi predpisi so v takem primeru račun za stranko ponovno natisnili in na tem prepisu je bilo navedeno, da je bil račun poravnan. Novi predpisi pa zahtevajo, da je kopija računa enaka originalu - torej ob ponovnem tiskanju na računu še vedno piše, naj ga plačajo v roku ...
Bi moral v takem primeru stranki dat blagajniški prejemek - je to sploh še dovoljeno? Kako ste to uredili drugje?
Podobna zadeva je pri gotovinskem računu, ki ob izdaji zaradi napake v komunikaciji ni potrjen. Naknadno, ko pridobi EOR kodo, se ta ne sme izpisat na kopiji računa, ampak se mora hranit v programu ... uporabniku lahko potem samo preko nekega dnevnika prikažemo, ali računi imajo EOR ali ne..

o katerem appu govoriš?

Ja, sej to me zanima, app za potrošnike ni za preverjanje pravilnosti kode.

A je kaj narobe z aplikacijo Preveri kodo?

Zdaj sem zvedel še člene: DDV ni obračunan po 11. točki 42. člena ZDDV-1 in 16. členu Pravilnika o izvajanju ZDDV.

Ma, jst tko pravm. Če ga aplikacija lahko poskenira, ne bo noben kompliciral. Če ga pa ne bo mogla, se bo pa začelo gledati, če ustreza standardom.

Inšpektorji ne bodo imeli takih navodil. Itak ne vejo kaj so to moduli.

Sem pa ravno danes dobil račun, na katerem je naveden znesek 17 EUR, na FURS so pa poslali podatek o znesku v višini 3 EUR :). Jst ne vem, a je možno, da je napaka programska? Al so res nekateri tako navini, da mislijo, da bodo s takimi diletantskimi poskusi manipulacij prišli skozi?

perci je 8. jan 2016 ob 19:23 izjavil:

Inšpektorji ne bodo imeli takih navodil. Itak ne vejo kaj so to moduli.

Sem pa ravno danes dobil račun, na katerem je naveden znesek 17 EUR, na FURS so pa poslali podatek o znesku v višini 3 EUR :). Jst ne vem, a je možno, da je napaka programska? Al so res nekateri tako navini, da mislijo, da bodo s takimi diletantskimi poskusi manipulacij prišli skozi?

Ma to se čisto lahko zgodi pri malo manj profesionalnem programiranju. Malih "neprofesionalnih" ponudnikov pa je v tej zgodbi precej. Polna implementacija pošiljanja na FURS nikakor ni preprosta in ima veliko priložnosti za buge. V kombinaciji s hitenjem decembra zagotovo manjka temeljitega testiranja. Pomoje se jih bo odkrilo še veliko, nekatere tudi šele ob miniranju po podatkih s strani FURSa.

Tvoj primer je verjetno posledica copy paste spremenljivke z davkom v polje s končnim zneskom, kjer so jo pozabili popraviti :) FURS servis načeloma nič ne preverja nelogičnih kombinacij zneskov in davkov, požre vse

Ugibam: (QR) koda je zelo opazna in potem veš, kje iskati ZOI.
Drugače pa ZOI mora biti samo nad kodo in ne neposredno nad.
Minimalna velikost QR je 12x12 mm, če tiste 4 module zaokrožimo na 2 mm, je vsega skupaj 16x16 mm.

Če te moti ozka pokončna stvar uporabi code 128 v dveh vrsticah po 3,5 mm. Ker je koda 1D, potrebuješ rob samo levo in desno. S 16 mm višine prideš na 7 mm.

Sprejmem argumente in rešitve shadow7, nisem pa navdušen nad njimi.

Evo ti ideje - račun, ki ga izda mini blagajna

Morebitni očitki, da sistem davčnih blagajn pri FURS upočasnjuje izdajo računov pri poslovnih
subjektih, niso utemeljeni. V kolikor prihaja do daljših zakasnitev pri izdaji, je to zaradi
neustreznih programskih rešitev ponudnikov davčnih blagajn. Tudi, če bi bil sistem FURS
popolnoma nedostopen, mora davčna blagajna izdati račun najpozneje v roku štirih sekund.
Takšen račun sicer v tistem trenutku ni potrjen na FURS (nima EOR številke), davčna blagajna
pa ga potem avtomatično skuša potrditi na FURS za nazaj, ko vzpostavi povezavo.

Tole je pa malo poenostavljena trditev v idealnih razmerah:
- nekateri tiskalniki (naš lokalni Tuš npr.) so tako stari/počasni da samo QR kodo tiska 2-3s :-)
- nekje so GSM povezave tako slabe, da v 4s timeouta praktično nobenega računa ne potrdi, tako da če hočeš da je račun potrjen takoj je potrebno imeti timeout večji od 10s :-(

d(-_-)b je 9. jan 2016 ob 19:51 izjavil:

Meni je pa stranka postavila zanimivo vprašanje - kje lahko preveri, da naša blagajna deluje pravilno, po vseh predpisih?
To tudi mene zanima - zdaj, ko smo dali program v uporabo - kako naj preverim, da nismo česa spregledali ali pa narobe razumeli?
Nujno bi moral FURS omogočiti vpogled v prejete podatke, vsaj nek sumarni ...

No to sem mislil. Debug pravilnosti pri vseh možnih različnih tipih računov in njihovih variantah je dokaj zahtevna stvar. Servis za prijavo računov le teh nič ne preverja in sprejme popolnoma napačne podatke brez pripomb. Ko daš program potem na mnogo poslovnih mest, kjer ti ga po možnosti še na tebi nepoznan način uporabijo (zlorabijo), res težko ugotoviš, če ga kje kaj serje. Lahko preveriš račun z aplikacijo (samo končni znesek), in pa ročno preverjaš poslane XMLe. Dodstop in datamining po svojih podatkih na FURSu bi bila kar zanimiva reč
No, tudi brez tega se bo slej ko prej našlo vse buge. Vsak software jih ima. Z nekaj več časa za razvoj se bo tudi kodo uredilo in tako kaj odkrilo. Samo upam, da bodo to razumeli tudi inšpektorji