eFiskalizacija i ESIR: šta softver mora da ispuni

Fiskalizacija se u razgovorima često svede na jedno pitanje: „da li nam softver radi fiskalizaciju“. To je pogrešno postavljeno pitanje, jer fiskalizacija nije funkcija koju ekran na kasi ima ili nema. To je servis — deo sistema koji svaki kanal prodaje poziva na isti način, bez obzira na to da li se prodaja dešava na kasi u radnji, u veb prodavnici ili kroz radni nalog u servisu.

Ovaj tekst opisuje arhitekturu i uloge u opštem modelu eFiskalizacije, iz ugla softvera. Namerno ne ulazi u konkretne brojeve, rokove ni pravne odredbe — one se menjaju i nisu stvar softvera nego propisa. Za sve što traži sigurnost, jedini merodavan izvor su objavljeni zahtevi poreske uprave i vaš računovođa.

Uloge u modelu: ESIR, procesor i poreska

Model se lakše razume kada se razdvoje tri uloge. One nisu tri programa nego tri odgovornosti, i vredi ih držati odvojeno u glavi čak i kada ih jedan sistem tehnički objedini.

Za softver je najvažnije da razume granicu: ESIR priprema i traži, procesor obezbeđuje i vraća, poreska postavlja pravila i prima. NG eFiscal je softverski ESIR kompanije Konis Software — deo koji sastavlja račun i komunicira s procesorom. Šta tačno svaka uloga sme i mora, propisuje poreska uprava, i to je granica na kojoj softver prestaje da bude izvor istine.

Račun se fiskalizuje pre nego što stigne kupcu

Suština koja oblikuje ceo tok naplate glasi jednostavno: račun mora biti fiskalizovan pre nego što se preda kupcu. To znači da u trenutku kada kupac dobija dokument, fiskalni elementi već moraju biti na njemu. Fiskalizacija nije korak koji se radi kasnije, uveče, u paketu — ona je unutar same prodaje.

Za tok na kasi to menja redosled. Naplata se ne završava kada je novac uzet, nego kada je račun fiskalizovan i odštampan sa svim elementima. Ako sistem prvo uzme novac pa pokuša da fiskalizuje, a fiskalizacija zakaže, ostali ste s naplaćenom prodajom bez važećeg računa — najgore moguće stanje. Zato se tok projektuje tako da je predaja računa kupcu poslednji korak, a ne prvi.

Offline režim i revizioni trag

Mreža će pasti. Ne kao izuzetak koji se planira jednom godišnje, nego kao redovna pojava usred radnog dana. Pitanje nije da li, nego šta se dešava sa prodajom u tom trenutku. Sistem koji staje kada nestane veze zaustavlja i naplatu — a red na kasi ne čeka da se internet vrati.

Zato offline režim nije luksuz. Prodaja mora da se završi i kada procesor trenutno nije dostupan, uz uslov da se sve uredno zabeleži i naknadno usaglasi kada se veza vrati. To povlači nekoliko obaveza koje softver mora da ispuni:

• Trajan zapis svake prodaje u trenutku dešavanja, pre svake mrežne komunikacije, da ništa ne zavisi samo od uspešne veze.
• Revizioni trag koji pokazuje šta se desilo i kada — koja prodaja je nastala offline i kada je naknadno usaglašena.
• Naknadno slanje koje se pokreće samo kada se veza vrati, bez ručne intervencije i bez rizika da nešto ostane nezabeleženo.

Fiskalizacija iza servisa, ne u POS ekranu

Najčešća greška u dizajnu je da fiskalizacija živi unutar ekrana na kasi. Deluje prirodno — kasir pritisne dugme, račun se odštampa — ali svaka logika ugrađena u jedan ekran postaje nedostupna svemu ostalom. Onog trenutka kada firma dobije i veb prodavnicu, i servisni modul, i prodaju na terenu, fiskalizacija zaključana u POS ekranu mora da se piše iznova za svaki kanal.

Ispravno je da fiskalizacija bude servis iza korisničkog interfejsa: jedno mesto koje sastavlja zahtev, priča s procesorom i vraća rezultat, a svaki kanal ga poziva na isti način. Kasa, NG Commerce i servisni tok tada dele istu logiku umesto tri odvojene kopije koje se razilaze. To je isti princip o kome govorimo kada pišemo o integracijama: pravilo se piše jednom, na mestu gde mu je mesto.

Idempotentnost: nikad dvaput isti račun

Isti problem koji muči svaku integraciju vraća se ovde s većim ulogom. Kasa pošalje prodaju na fiskalizaciju, procesor je obradi, ali odgovor se izgubi na putu nazad. Kasa ne zna da li je uspelo. Ako pokuša ponovo bez zaštite, ista prodaja se fiskalizuje dvaput — a dupli fiskalni račun je greška koju je teško i neprijatno ispravljati.

Rešenje je isto kao kod svake ozbiljne integracije: idempotentnost. Svaka prodaja nosi jedinstvenu oznaku, pa ponovljeni pokušaj sa istom oznakom ne stvara novi račun nego vraća postojeći rezultat. Ponovni pokušaj tada postaje bezopasan — a upravo ponovni pokušaji su ono što neizbežno sledi kada mreža otkazuje.

Ispravke se ne rade brisanjem. Povraćaji, storniranja i korektivni računi su predviđeni upravo zato što se prodaja ne može jednostavno obrisati kao da se nije desila. Softver mora da ih podrži kao zasebne, praćene radnje koje se vezuju za originalni račun, a ne kao improvizaciju povrh njega.

U praksi to znači da svaki od tih dokumenata ima svoj tok: povraćaj vezan za original, storno koji ga poništava, korektivni račun koji ispravlja iznos. Svaki od njih se i sam fiskalizuje i ostavlja svoj trag, jer i ispravka je promet o kome poreska mora da zna. Softver koji to rešava „naknadnim ručnim knjiženjem“ pravi rupu u tragu koja se kasnije teško zatvara, i po pravilu se otkrije tek pri prvoj kontroli.

Integracija sa eCommerce i radnim nalogom

Kada fiskalizacija postoji kao servis, novi kanali se priključuju bez ponovnog izmišljanja. Veb prodavnica u trenutku naplate poziva isti servis kao kasa. Servisni tok — na primer radni nalog u Fleet Stop-u, gde se usluga i delovi obračunavaju po završetku posla — takođe poziva isti servis kada dođe do naplate.

Poenta nije u konkretnom proizvodu nego u obrascu: prodaja može da nastane na deset mesta, ali fiskalizacija ostaje jedna. Svaki kanal donosi stavke i podatke o kupcu, a servis ih pretvara u fiskalizovan račun na isti način. Time se izbegava najgori scenario — deset različitih implementacija fiskalizacije koje se ponašaju malo drugačije i otkazuju svaka na svoj način.

Testiranje bez dodirivanja produkcije

Poslednja stvar koju tim shvati, obično posle prvog incidenta, jeste da se fiskalizacija ne sme testirati na pravim podacima. Fiskalizovan promet je zvaničan; jednom kada nastane, nije stvar softvera da ga poništi. Testiranje mora da se odvija odvojeno od produkcije, tako da nijedan probni račun nikada ne dodirne stvarne fiskalne podatke.

1. Odvojeno okruženje u kome se tokovi prolaze bez ijednog stvarnog fiskalnog zapisa.
2. Jasna granica između probnih i pravih podataka, tako da nije moguće greškom poslati test u produkciju.
3. Provera ivičnih slučajeva — prekid mreže usred prodaje, dupli pokušaj, povraćaj — pre nego što se sistem pusti u rad.

Ništa u ovom tekstu nije pravni savet niti tvrdnja da je bilo koji proizvod odobren ili sertifikovan. Opisali smo kako softver treba da bude građen da bi ispunio zahteve. Za same zahteve — šta je obavezno, do kada i pod kojim uslovima — merodavni su isključivo objavljeni propisi poreske uprave i vaš računovođa. Ako želite da razgovaramo o tome kako fiskalizacija sedi u vašem toku prodaje, kontaktirajte nas ili pogledajte česta pitanja.