4 . dio:
Iz testova je vidljivo sljedeće:
Iz testova je vidljivo sljedeće:
- Ispravno se kopira enkoding datoteke PoslovniProstorZahtjev.xml u Zahtjev/PoslovniProstorZahtjev_xyz.xml u svim verzijama v2000 i v3000
- Razlike u načinu enkodiranja nema u verzijama v2000 i v3000, sve ostale datoteke imaju miješani enkoding
- Kad se dogodi greška tj. formira Greska.txt sljedeća akcija, kopiranje u Zahtjev/xyzZahtjev_xyz.xml ima enkoding kao i Greska.txt tj. ANSI umjesto UTF8 BOM kao kad zahtjev uspije.
- Txt datoteke uvijek imaju enkoding ANSI, što nije greška jer nemaju "alfa utf8" znakove pa možda i nije toliko bitno
- FiskalizacijaDEV.log uvijek ima ispravan, po našem mišljenju i po Unicode standardu (više @http://stackoverflow.com/a/2223926), osim ako nemate hebrejske znakove :)
- Kod nove metode (ProvjeraZahtjev) sve ostaje isto osim XML header-a poruke i toga što se prilikom "Snimanja" u mape Odgovor i Zahtjev spreme kao Provjera[xyz].xml
-
U slučaju računa se neispravno izmjeni iz originalnog RacunZahtjev (UTF8) u Zahtjev/ProvjeraZahtjev_xyz.xml (ANSI)
- Ispravno se kopira enkoding datoteke PoslovniProstorZahtjev.xml u Zahtjev/PoslovniProstorZahtjev_xyz.xml u svim verzijama v2000 i v3000
Smatramo da je ovo najbolja varijanta.
Pretpostavljamo da je razlog što smo mi stvorili UTF8 no BOM a tako isto je enkodirana i kopirana datoteka sa drugim name-om prilikom snimanja.
Bilo bi odlično da kako enkodiramo stvorenu datoteku zahtjeva, tako bude enkodirana datoteka odgovora i ona koja se kopira prilikom snimanja. -
Razlike u načinu enkodiranja nema u verzijama v2000 i v3000, sve ostale datoteke imaju miješani enkoding
Bilo bi odlično da su sve datoteke enkodirane u UTF8 i to UTF8 no BOM. -
Kad se dogodi greška tj. formira Greska.txt sljedeća akcija, kopiranje u Zahtjev/xyzZahtjev_xyz.xml ima enkoding kao i Greska.txt tj. ANSI umjesto UTF8 BOM kao kad zahtjev uspije.
Vjerojatno treba bugfix/hotfix u v3000 i v2000. -
Txt datoteke uvijek imaju enkoding ANSI, što nije greška jer nemaju "alfa utf8" znakove pa možda i nije toliko bitno
Bilo bi odlično da su i txt datoteke enkodirane u UTF8 ili još bolje (ako se sve ovo bude rješavalo) da bude UTF8 no BOM.
Razlog zašto je nama bitno da su txt u UTF8 (ili još bolje UTF8 no BOM) možemo naći u Greska.txt datoteci koju mi moramo posebno učitavati tj. izvršiti konverziju u UTF8 kako bi nam u bazi i putem aplikacije bili vidljivi hrvatski znakovi. -
FiskalizacijaDEV.log uvijek ima ispravan, po našem mišljenju i po Unicode standardu (više @http://stackoverflow.com/a/2223926), osim ako nemate hebrejske znakove :)
Ovo nam je posebno drago jer je bar jedna datoteka enkodirana po preporukama unicode-a (@http://www.unicode.org/versions/Unicode5.0.0/ch02.pdfstr. 35).
Smiješno je što u dokumentaciji za fiskalizaciju (Tehnicka specifikacija za korisnike - sva izdanja) nije navedeno da bude BOM ili no BOM. -
Kod nove metode (ProvjeraZahtjev) sve ostaje isto osim XML header-a poruke i toga što se prilikom "Snimanja" u mape Odgovor i Zahtjev spreme kao Provjera[xyz].xml
Mogući problemi kod nove metode:
6.1. nije izdvojena posebna naredba (PZ-ProvjeraZahtjev) već je iskorištena RZ-RacunZahtjev,
6.2. nije izdvojena posebna datoteka (ProvjeraZahtjev.xml) već je iskorištena RacunZahtjev.xml,
6.3. nije izdvojena posebna datoteka (ProvjeraOdgovor.xml) već je iskorištena RacunOdgovor.xml,
6.4. nije formirana nova datoteka umjesto JIR.txt npr. "Provjera.txt" u kojoj će biti samo elementi tns:Greske ili samo možda tekst grešaka.
Navedeno rješenje stvara konfuziju i nije baš dobro jer ne prati logiku koja je određena ponašenjem za RacunZahtjev.
Ako promatramo da posljednji RacunZahtjev tj. RacunOdgovor odgovara posljednjem kopiranom u Zahtjev/RacunZahtjevxyz i tj. Odgovor/RacunOdgovorxyz,
onda bi bilo dobro da se zadrži ista logika i prilikom formiranja ProvjeraZahtjev (PZ).
Isto se može zaključiti iz posljednje WDSL dokumentacije (Fiskalizacija-WSDL_v1.3) - bez obzira što je XML gotovo isti, postoji dodatna metoda Provjera.
Razlozi za takvu implementaciju su:
6.1. bilo bi jasnije za što koristimo FiskalDEV.exe - Racun ili Provjera Zahtjev (iako su tad potrebne dodatne dorade u programima ako žele implementirati provjeru - ionako ih sad već mijenjamo)
6.2. i 6.3. mogli bi imati posljednje stanje provjere i računa u istoj mapi u "root-u" (ProvjeraZahtjev.xml i RacunZahtjev.xml te ProvjeraOdgovor.xml i RacunOdgovor.xml),
6.4. ovo bi moglo biti od pomoći onima koji imaju (DOS i ostale dinosaure) i ne mogu jednostavno iz DOM-a izvući podatke već se muče sa parsiranjem - zato je i dodan JIR.txt. -
U slučaju računa se neispravno izmjeni iz originalnog RacunZahtjev (UTF8) u Zahtjev/ProvjeraZahtjev_xyz.xml (ANSI)
Ovo je jedina razlika koju je Nino pitao ako postoji između v2000 i v3000 - provjera se ne ponaša isto ako RZ (ali RZ je isti u v2 i 3).
Nadam se da je ovo razlog :) radi kojeg bi Nino bio dobar i rješio neke od ovih problema.
