Fiskalizacija veb prodavnice: šta se tačno fiskalizuje i kada

Veb prodavnica nema pult, nema kasira i nema štampač, ali ima kupce koji su fizička lica. To je dovoljno: onlajn prodaja fizičkom licu je promet na malo i fiskalizuje se kao i svaka druga.

Kako mi razumemo član 3 stav 4 Zakona, sedište obveznika koji prodaje na malo preko interneta smatra se maloprodajnim objektom, pa se kroz veb prodavnicu fiskalizuje i prodaja firmama i preduzetnicima, sa njihovim PIB-om na računu.

Ono što se stvarno razlikuje jesu tri stvari: kada se račun izdaje, kako stiže do kupca i ko pritisne dugme. Nijedna od njih nije pitanje da li račun postoji.

Kada se fiskalizuje porudžbina

Pravilo je isto kao na pultu: račun se izdaje u trenutku prometa, a novac primljen pre toga je avans, koji se fiskalizuje kad je primljen (član 6 stav 1 Zakona). Prodaju na daljinu propis ne uređuje posebno, pa je ovo naše razumevanje, koje vredi proveriti sa knjigovođom. Tri scenarija vredi držati odvojeno, zato što ih prodavnice stalno mešaju.

Treći red je onaj o kome vredi razmisliti. Uplata unapred za robu koja tek treba da bude poslata je, kako mi razumemo zakon, avans: račun za avans izdaje se najkasnije narednog radnog dana od prijema uplate (član 11 Pravilnika), a konačni račun pri prometu. Poreska uprava je u odgovorima na najčešća pitanja navela i da se, kad fizičko lice uplati ceo iznos iz predračuna, u momentu prometa može izdati konačni račun; ako tako radite, potvrdite to sa knjigovođom.

Kako račun stiže do kupca

Ako prodajete isključivo preko interneta, fiskalni račun se izdaje u elektronskom obliku (član 13 stav 3 Pravilnika o vrstama fiskalnih računa). Ako imate i prodavnicu u objektu, račun se, kako mi razumemo pravilnik, izdaje u štampanom obliku (na primer uz pošiljku), a elektronski može da se dostavi samo uz saglasnost kupca, uz štampani, a ne umesto njega (član 13 st. 1 i 2).

Pravilo koje pri tom važi jeste da račun izdat u elektronskom obliku umesto QR koda nosi adresu za proveru u obliku hiperlinka. To je i praktično: QR kod u mejlu nema ko da skenira kad je telefon već u ruci, a link se otvara klikom.

Po našem razumevanju to znači da adresa za proveru u mejlu treba da bude pravi link koji se otvara klikom, a ne tekst u kome adresa stoji kao običan niz znakova. To je sitnica koju je lako preskočiti i lako proveriti: otvorite mejl na telefonu i pokušajte da kliknete.

Kako se prodavnica povezuje sa ESIR-om

Veb prodavnica nije ESIR. Ona je sistem koji zna šta je prodato i kome, a izdavanje računa prepušta ESIR-u preko interfejsa. U praksi postoje dva načina.

Gotov dodatak

Za WooCommerce i slične platforme postoji dodatak koji sam razgovara sa kasom. Tipična postavka traži četiri podatka:

• adresu ESIR-a,
• API ključ,
• status porudžbine koji okida izdavanje računa,
• mapiranje načina plaćanja iz prodavnice na sedam fiskalnih načina plaćanja.

Treća stavka je ona o kojoj vredi razmisliti pre nego što se stisne „sačuvaj“. Ako fiskalizaciju okida status „obrada“, a porudžbina plaćena pouzećem taj status dobije u trenutku naručivanja, izdali ste račun pre nego što ste videli novac. Za pouzeće, kako mi razumemo, odgovara status iz kasnijeg koraka, pri otpremi ili pri isporuci, a koji od ta dva trenutka važi, proverite sa knjigovođom. Za karticu odgovara status koji dobijate pri uspešnoj naplati, uz račun za avans ako roba još nije isporučena.

REST API

Ako prodavnica nije na gotovoj platformi, ista stvar se radi direktno preko API-ja. Zahtev nosi stavke, količine, cene, poreske oznake i način plaćanja, a odgovor nosi PFR broj, brojač, žurnal i link za proveru.

POST /api/v1/invoices
Authorization: Bearer VAS_API_KLJUC
Content-Type: application/json

{"invoiceType":"NORMAL","transactionType":"SALE",
 "items":[{"name":"Мајица","labels":["Ђ"],"quantity":1,"unitPrice":2490.00}],
 "payments":[{"paymentType":"CARD","amount":2490.00}]}

Poreske oznake po proizvodu

Ovo je najčešći uzrok pogrešnih računa iz veb prodavnica. Prodavnica po pravilu zna cenu, ali ne zna poresku oznaku, zato što njoj ona nije trebala.

Rešenje je da oznaka postane podatak proizvoda, jednako kao cena. U WooCommerce se to radi kroz meta polje, a u sopstvenom sistemu kroz kolonu u tabeli proizvoda. Ako oznaka nedostaje, kasa ili odbija račun ili podrazumeva nešto, a podrazumevano je ovde uvek pogrešno za bar neki deo asortimana.

Šta se dešava kad nešto pođe naopako

Ovo je deo koji se obično ne osmisli, pa se rešava uživo. Tri situacije vredi pokriti unapred:

• Procesor nije dostupan. API mora da vrati jasnu grešku i račun tada nije izdat. Prodavnica ne sme da pretpostavi uspeh. Porudžbina ostaje označena kao nefiskalizovana, a pokušaj se ponavlja.
• Odgovor se izgubi posle uspeha. Zahtev je prošao, mreža je pukla na povratku, prodavnica misli da nije uspelo i šalje ponovo. Bez zaštite to znači dva fiskalna računa za jednu porudžbinu. Zaštita se zove idempotentnost: zahtev nosi ključ, a kasa na isti ključ vraća isti račun umesto da izda nov.
• Kupac otkazuje porudžbinu. Izdati račun se ne briše nego se ispravlja refundacijom, koja nosi referentni broj originala i ID kupca.

Kako to radi u Otkucaju

Otkucaj ima REST API v1 sa Bearer ključevima i gotov WooCommerce dodatak. Dodatak u svaku porudžbinu upisuje PFR broj i link za proveru, a poreska oznaka po proizvodu se zadaje kroz meta polje otkucaj_label.

API prima idempotentni ključ, pa izgubljen odgovor ne može da proizvede drugi račun. Greške su predvidive i uvek istog oblika, a 502 znači da procesor nije odgovorio i da račun nije izdat.

Detalji su u API dokumentaciji.

Otkucaj je ESIR odobren kod Poreske uprave, evidencioni broj 1667, klasifikacija 3. Nov nalog počinje u test okruženju, gde računi nisu fiskalni; produkcija traži sopstveni bezbednosni element i PAK.