Davčne blagajne

Pri pošiljanju računov smo odkrili napako, ki povzroči, da se v določenih (redkih) okoliščinah pošlje napačen znesek na furs. Kaj nam je storiti z napačno poslanimi računi? Jih pošljemo še enkrat v potrditev?

če mi spomin drži, sem nekje prebral da lahko pišeš na FURS da ti IP whitelistajo.

trstenjak je 19. jan 2016 ob 11:02 izjavil:

Pri pošiljanju računov smo odkrili napako, ki povzroči, da se v določenih (redkih) okoliščinah pošlje napačen znesek na furs. Kaj nam je storiti z napačno poslanimi računi? Jih pošljemo še enkrat v potrditev?

Ne kar tako, ker bodo potem zneski dvojni. Postopali boste podobno kot v FAQ 193, vendar počakajte na končna navodila. Upam seveda, da je napaka programska in ne posledica "inovativnih" strank in razvijalcev.

eniLS je 19. jan 2016 ob 11:14 izjavil:

Ker sem tukaj prebral, da so blagajne nedostopne iz tujine imam eno vprašanje.
Imam zakupljen server v nemčiji na katerem teče lasten CRM sistem. Lahko iz tega CRM sistema potrjujem račune ali ne? Bom moral zakupit server v sloveniji?
In če, zakaj dodatni stroški? Kje je problem, da nemorem potrditi računa iz mojega serverja v EU?

@perci, ali kdorkoli prosim za odgovor.

LP

Na FURS bošlji svoje podatke in IP-je, da ti jih whitelistamo.

Malajlo je 19. jan 2016 ob 14:07 izjavil:

Neobdavčene transakcije moraš navesti, znesek davka je seveda 0.

Ampak še večja nebuloza - vse gre skozi, pa imaš paper jam. FURS pravi, da moraš v tem primeru račun stornirati! WTF? Ok, printamo v pdf in potem milijon kopij na papir. Al kam so kompas založili ...

Ops, spregledal sem, da izdaš novega iz VKR. Prehiter ;)

Lej, te kopije so posledica...ne bom rekel česa in koga. Se strinjam, da je butasto, vendar to ni bila želja FURS - mi smo jasno povedali, da je to brezveze.

Ufff, sem 90%, da ja, ne znam ti pa 100% potrdit. Kaj bi imel smisel varovati samo produkcijo, če je oboje na isti liniji. Za DDOS ti potem nič ne pomaga.

Bom preveril pa javim.

perci je 19. jan 2016 ob 18:31 izjavil:

Malajlo je 19. jan 2016 ob 14:07 izjavil:

Neobdavčene transakcije moraš navesti, znesek davka je seveda 0.

Ampak še večja nebuloza - vse gre skozi, pa imaš paper jam. FURS pravi, da moraš v tem primeru račun stornirati! WTF? Ok, printamo v pdf in potem milijon kopij na papir. Al kam so kompas založili ...

Ops, spregledal sem, da izdaš novega iz VKR. Prehiter ;)

Lej, te kopije so posledica...ne bom rekel česa in koga. Se strinjam, da je butasto, vendar to ni bila želja FURS - mi smo jasno povedali, da je to brezveze.

Ah, glede teh kopij se mi vedno dvigne pritisk.
Da je to velik prekršek, če program omogoča večkrat izpisati isti račun!
In da mora na vsakem izpisu pisati "Kopija" in zaporedna številka kopije pa da hranimo timestamp, kdaj je bila ta "kopija" narejena.
Ampak, so nam povedali na seminarju - tiste račune, ki jih izpisujemo za lastne potrebe oz. vse tiste račune, ki jih ne izročimo kupcu, ni trena označevati s "kopijo".
O, yebela cesta, kdo si je to izmislil?
Kolk sem pa na ta račun besed na K..., F..., in P... že slišal.

Kako ste ta problem reševali v softveru?
Ali oštevilčite čisto vsak izpis računa? Itak je to brez veze, pa vseeno.
V programu sem mojim uporabnikom omogočil, da ob izpisu računa, takoj po davčnem potrejvanju, natisne 1 ali pa 2 izvoda računa (si lahko sami nastavijo število kopij).
Enega izročijo kupcu, drugega shranijo za lastno evidenco. Na nobenem ne piše "kopija" in tudi ni potrebe, da bi pisalo, saj kupec dobi samo en izvod.

Kako, zaboga, naj vem, da ne bo kdo od uporabnikov "žleht" in dal še tisti svoj izvod kupcu?
Ne morem.

Ali pa, če si bo kdo naštimal PDF virtualni tiskalnik in tja izpisoval po en račun, potem pa ga veselo spustil na printer v 100 izvodih?

Grrr.

Zakaj kompliciranje z nepotrjevanjem takih računov? Če obstaja najmanjša možnost, da se račun plača z gotovino ga pač že TAKOJ davčno potrdiš, kje je problem?

Kako ga potrdiš takoj? Potrdiš ga naknadno potem, ko je (če je) plačan z gotovino. Ni tako?

Kako je s številčenjem kopij v primeru, da se lahko izpis dinamično spreminja (uporabnik ima možnost, da npr. dodatno izpiše serijsko številko artikla, doda ean kodo artikla, ...)?
Se številčenje kopij resetira, ker izpis ni enak originalnemu, kljub temu, da se podatki samega računa niso spremenili?
Isti problem je pri izpisu računa v tujem jeziku (podatki so isti, izgled pa drugačen).

Celovitost vsebine se v skladu z ZDDV-1 ne spremeni, saj se obvezni podatki ne spremenijo, pač pa se dodajo nekateri neobvezni podatki.

Hvala za pomoč :)

Torej če stranka hoče izpisat davčno potrjen račun in želi pri artiklih serijske številke, ki jih pri originalu ni bilo, je to spet originalen račun.
Isto potem tudi velja za izpis v tujem jeziku.
Hvala

Če slučajno kdo potrebuje JSON implementacijo davčnih blagajn v PHP-ju, lahko uporabi mojo (pull requesti so seveda dobrodošli ): https://packagist.org/packages/neonbug/...

Je imel kdo težavo, da mu potrjevanje z eno povezavo ni delovalo, z drugo pa?
PRIMER:
Če se povežem preko mobilnega telefona (mobilna dostopna točka) zadeva deluje, če pa preko SIOL interneta pa ne deluje.
Zadeva je delovala nekaj dni, zadnjih 14 dni pa več ne. Javi napako The underlying connection was closed: An unexpected error occured on a send.
Imam pa SIOL MODEM, DLINK ROUTER (brez kakih omejitev, požarnih zidov, filtrov...) in brezžično povezavo do računalnika, kjer je davčna blagajna. Internet (vse ostalo) deluje brez problema.
hvala

Imam vprašanje.
Ali lahko tu:
https://blagajne-test.fu.gov.si:9002/ca...

preverjam tudi račune, ki so bili poslani preko vmesnika za masovno sprejemanje podatkov o računih? Oz. če ne morem tukaj, kje lahko? Ker normalno dobim nazaj EOR, ampak ko ga želim preveriti tu, mi ga ne najde.

Vmesnik za masovno pošiljanje podatkov o računih v produkciji deluje?

Hvala in lp

Povzetek iz odgovora na vprašnje 257:

Dovoljeno pa je, da zavezanec na istem naslovu registrira več poslovnih prostorov v katerih izdaja račune (npr. posamezne pisarne), in sicer tudi v primeru, če za stavbo v registru nepremičnin ni evidentiranih posameznih delov stavbe.

Sklepam - če jih imaš lahko hkrati registriranih več na istem naslovu, potem lahko tudi en prostor zapreš in registraš novega.
Številčenje in blagajna sta ista, tako da je to res samo kozmetika. Bom jih opozoril na navedbo v internem aktu, hvala.

perci je 22. jan 2016 ob 19:08 izjavil:

Na istem naslovu imaš lahko več PP. V istem PP (recimo pisarni, trgovini) pa ne smeš imeti prijavljenih več PP.

Ja, če pa je številčenje isto (da se nadaljuje), potem res ne vidim problema.

Lahko še prosim navedeš vir?

Se pravi je zdaj že vse prepovedano kar ni dovoljeno ali kako?

Številčenje v okviru PP in v isti prostor postaviš blagajne različnih proizvajalcev npr..

perci je 23. jan 2016 ob 00:04 izjavil:

Mislim, da je bilo to vprašanje postavljeno na tistih izobraževanjih, ki jih je FURS organiziral, samo odgovora se žal ne spomnim :)

Treba je imeti tudi pravilnik in se ravnati po njem. :)

Da nej bom tih :)

Zakaj? Saj imaš lahko številčenje na blagajno, ne na PP?

Hja, to imaš point, nisem pomislil na to.

V zadnji verziji QA so navodila kako ravnati v primeru, če ste poslali napačne podatke o registraciji računa in jih želite popraviti.

Pa da ne bom vedno samo nergal - pohvale za tole res enostavno možnost popravka napačno poslanih podatkov .

Se trudimo za vas .

Zdej pa že nehajte napake delat, da ne boste rabili teh popravkov .

Mogoče bo perci tole vedel:
Tale pravilnik o datotekah s podatki o računih: https://e-uprava.gov.si/drzava-in-druzb... je še vedno le predlog.
Ampak a ni to sedaj nepotrebno, saj dobite vse podatke o računih z davčnim potrjevanjem..
Torej - a bo to sprejeto, ali ne.. ?

Hvala perci. Fajn je, kadar kaj ni treba nardit