Dijagnostika i popravka kvarova EFU komponenti

U slucaju da LPFR nije dostavio odredjene fiskalne racune na SUF, neophodno je pre svega utvrditi uzrok problema, a zatim resiti na nacin koji je opisan na ovoj stranici. Ako vas LPFR ima vise od 10 racuna na cekanju u vasem LPFR Control Panelu, potrebno je da pokrenete proces iscitavanja, bilo u lokalnom ili internet modu. Lokalno iscitavanje omogucuje da sve prethodno neisporucene fiskalne racune izvezete na USB disk, a zatim ih rucno uploadujete na SUF na nacin na koji je predvidjeno novom fiskalizacijom.Internet iscitavanje je automatsko i vrsi se periodicno od strane vaseg LPFR audit servisa.

U slucaju da LPFR audit servis ne uspeva da posalje audit pakete i iz nekog razloga su racuni i dalje na cekanju u vasem LPFR Control Panelu, potrebno je da:

• reinstalirate LPFR audit servis
• pokrenete LPFR audit servis
• posaljete komandu za internet iscitavanje

Ukoliko LPFR audit servis ne uspeva da posalje odredjeni broj audit paketa na SUF, uzrok tome moze biti prekid internet konekcije, neispravan token za povezivanje na SUF portalom ili ostecenje audit paketa. Ostecenje audit paketa moze nastati zbog softverskog ili hardverskog problema, a takodje i ako ste na primer obrisali sadrzaj nekog od direktorijuma koji se proveravaju prilikom pokretanja procesa iscitavanja.

RUCNO RESAVANJE PROBLEMA:

Ako nemate pristup USB disku, resenje je da pronadjete zeljene audit pakete (JSON datoteke) i posaljete ih na SUF (putem portala). Fajlovi se nalaze u direktorijumu:

C:\LPFR\WebService\Audit\

NAPOMENA:

Nemojte rucno brisati sadrzaj direktorijuma unutar C:\LPFR\WebService\Audit. C:\LPFR\WebService\Invoices i C:\LPFR\WebService\Logs

Sadrzaj ovih direktorijuma mozete obrisati samo u slucaju da su 100% isporuceni svi audit paketi na SUF

Preporuka je da se sadrzaj ovih direktorijuma arhivira na nacin predvidjen uputstvom za servisiranje FoxCreek LPFR-a

Ostecenja sifrovanih audit paketa

Najcesci razlog gresaka tokom fiskalizacije racuna ili tokom procesa kreiranja sifrovanih audit paketa je problem sa drajverom citaca kartica. Do ovog kvara dolazi u slucaju prekida komunikacije izmedju LPFR-a i BE, ili kada god BE prijavi neki od APDU gresaka koji su definisani prema ISO 7816 standardu.
Neke od najcescih APDU gresaka su:

• 0x6300
• 0x6310
• 0x630F

Uzrok problema moze biti hardverske prirode (npr kvar citaca kartica ili prekid u napajanju racunara el. energijom), a takodje I softverski. Ukoliko vise aplikacija paralelno komunicira sa BE (slanje audit paketa, fiskalizacija, isctivanje, audit restore itd), moze doci do konflikta izmedju APDU komandi koje su prethodno poslate I cekaju odgovor od BE I onih koje se upravo izvrsavaju.

Fail safe mehanizam

U slucaju kvara u toku fiskalizacije racuna, LPFR ce pokusati da snimi originalni zahtev koji je poslat iz ESIR-a, kao i podatke koji su iscitani iz BE (pre greske), a koji se mogu koristiti za ponovno kreiranje sifrovanog audit paketa.

ESIR-u se uvek vraca obavestenje da je doslo do greske u komunikaciji sa BE (npr greska 2220). Takodje se prosledjuju i neophodni podaci za dijagnostiku I otklanjanje eventualnih problema koji su nastali tokom fiskalizacije racuna.

S obzirom da svaki zahtev koji ESIR salje u LPFR ima jedinstvenu oznaku (requestId) i datum i vreme, moguce je proveriti originalni zahtev koji je poslat iz ESIR-a, sadrzaj komande poslate u BE, kao I odgovor koji je preuzet iz BE tokom te transakcije.

U slucaju da pojedine datoteke iz odredjene transakcije ne bude kreirane, ili ukoliko njihov sadrzaj nije ispravan, nece biti moguce uraditi restore audit paketa. Npr, ako dodje do ozbiljnijeg kvara u momentu fiskalizacije racuna, moze se desiti da LPFR uopste I ne dobije odgovor od BE-a.

Dijagnostika kvara

Da bismo otkrili problem sa odredjenim zahtevom za fiskalizaciju racuna, neophodno je da prvo ustanovimo requestId za tu transakciju. To je moguce saznati iz odgovora sa opisom greske koji je dobio ESIR, ili iz LPFR log datoteke (C:\LPFR\WebService\Logs\*.txt. Kada imamo requestId (npr 637950877959906274), mozemo da pretrazimo file system, s obzirom da sve datoteke koje nastaju tokom transakcije sadrze requestId u svom nazivu:

• 575UMFVS-637950877959906274_.dump,
• 575UMFVS-637950877959906274_request.json
• 575UMFVS-637950877959906274_responseInfo.json

Informacije o odredjenoj transakciji mozemo dobiti I putem API-a:

http://localhost:7788/api/v3/requests/637950877959906274

Odgovor ce sadrzati sve informacije koje su neophodne za dijagnostiku:
{
"errors": [],
"exceptions": [],
"logFiles": [
"C:\\LPFR\\WebService\\\\\\Logs\\575UMFVS-637950877959906274_request.json",
"C:\\LPFR\\WebService\\\\\\Logs\\575UMFVS-637950877959906274_requestInfo.json",
"C:\\LPFR\\WebService\\\\\\Logs\\575UMFVS-637950877959906274_responseInfo.json"
],
"auditFiles": [
"C:\\LPFR\\WebService\\\\\\Audit\\575UMFVS-637950877959906274.in",
"C:\\LPFR\\WebService\\\\\\Audit\\575UMFVS-637950877959906274_.dump",
"C:\\LPFR\\WebService\\\\\\Audit\\575UMFVS-637950877959906274_1.dump"
]
}

Regenerisanje audit paketa

Proces regenerisanja audit paketa je potrebno inicirati pozivanjem audit_restore komande sa datumom i vremenom kada se desila greska.

http://localhost:7788/api/v3/audit_restore/find/all?fromDate=2022-08-01T00:00:00&toDate=2022-08-23T13:44:00&uid=575UMFVS

Audit pakete je moguce regenerisati I pojedinacno (ukoliko znamo tacan requestId, tj naziv datoteka na disku).

http://localhost:7788/api/v3/audit_restore/auto?filename=575UMFVS-637950877959906274&uid=575UMFVS