Bonuri care satisfac legea

Legea românească a comerțului cu amănuntul cere ca o vânzare să producă un bon fiscal de la un dispozitiv certificat. Dispozitivul își ține propria înregistrare protejată împotriva falsificării, raportează către autoritatea fiscală, și e evidența legală a ce a vândut magazinul. Software-ul nu-l înlocuiește și nu poate să-l suprascrie.

Asta inversează relația obișnuită. În majoritatea integrărilor, sistemul pe care-l construiești deține adevărul, iar periferia e un output. Aici imprimanta deține adevărul, iar aplicația trebuie să fie de acord cu ea.

Dispozitivul e autoritatea

O imprimantă fiscală își ține propriul tabel de articole: produsele pe care le va imprima, fiecare legat de un grup de taxă. O vânzare poate referi doar articole pe care dispozitivul le cunoaște deja. Deci catalogul trebuie proiectat pe dispozitiv și ținut sincron pe măsură ce produsele se schimbă.

Grupurile de taxă sunt a doua jumătate. Catalogul stochează cotele de TVA așa cum le gândește afacerea; dispozitivul stochează grupuri literale. Acea mapare e fixată de dispozitiv și de lege, nu aleasă. Greșești și bonurile se tipăresc cu TVA greșit. Ceea ce nu e un bug de afișare, ci unul contabil, descoperit la finalul perioadei fiscale.

Reconcilierea e feature-ul real

Dispozitivul raportează totaluri zilnice. Aplicația își ține propriile înregistrări de vânzări. Cele două cifre trebuie să fie de acord, iar când nu sunt, dispozitivul câștigă.

A construi pentru asta schimbă designul. O vânzare e înregistrată atomic, așa că nu există niciodată o înregistrare în aplicație fără una fiscală corespunzătoare. Eșecurile în timpul tipăririi trebuie să se rezolve într-o stare cunoscută, nu să lase o vânzare pe jumătate înregistrată. Iar o discrepanță trebuie să iasă la suprafață imediat, pentru că o divergență găsită o săptămână mai târziu nu mai poate fi urmărită înapoi la o tranzacție.

Corectitudinea parțială n-are valoare aici. Un bon e valid sau nu e.

Construiește pe hardware-ul real

Ne-am integrat cu un dispozitiv real din prima zi, nu cu un simulator. Dispozitivele fiscale au comportamente pe care nicio specificație nu le prinde: cum răspund la mijlocul unei tranzacții, ce se întâmplă când se termină hârtia în timpul unei tipăriri, cum se recuperează după o pană de curent cu o vânzare deschisă.

Un simulator codifică ce spune documentația. Bug-urile trăiesc acolo unde documentația greșește, ceea ce e același motiv pentru care testele noastre de bază de date rulează pe o bază de date reală, nu pe un mock.

Ce înseamnă asta pentru un magazin

Operatorul nu vede nimic din toate astea. Scanează un cod de bare, ia numerar sau card, și un bon se tipărește. Munca e în a te asigura că acel bon e unul pe care autoritatea fiscală îl acceptă, de fiecare dată, și că înregistrările proprii ale magazinului se potrivesc cu ce a raportat dispozitivul.