104 - 'Datum i vrijeme izdavanja' računa je veće od 'Datum i vrijeme slanja'

May 24, 2016 at 9:01 PM
Korisnik je dobio obavijest iz PU sa navedenom greškom 104, uz primjerak jednog takvog računa. Na računu piše slijedeće:

Datum i vrijeme izdavanja: 12.01.2015 09:31:34
Datum i vrijeme slanja: 12.01.2015 09:31:31
Datum i vrijeme obrade: 12.01.2015 09:31:32

Vidi se razlika od 3 sekunde. Da li se još netko susreo sa ovim?
Nemam kontrolu nad 'Datum i vrijeme slanja', a očekivao sam da je to vrijeme "iz Windowsa".
Koje je to vrijeme slanja? Sa nekog time servera? Možda Raverus zna odgovor.
Coordinator
May 25, 2016 at 6:48 AM
U XML-u postoje dva datum/vrijeme elementa, jedan se odnosi na datum i vrijeme izdavanja računa, a drugi na datum i vrijeme slanja računa (tj. XML poruke) u CIS. Ovo prvo ne bi trebalo biti veće od drugog.
May 25, 2016 at 7:20 AM
Ja sam se susreo sa time i jedino što mi je palo na pamet da da si windowsi automatski reguliraju vrijeme preko interneta
May 25, 2016 at 10:55 AM
nrasinec wrote:
a drugi na datum i vrijeme slanja računa (tj. XML poruke) u CIS

Slažem se sa svime. Tako kaže i Tehnička specifikacija.
Koristim program od bbanka i dostavljam u zahtjevu samo datum/vrijeme izdavanja računa. Znači da netko poslije mene u XML nadoda datum/vrijeme slanja i pošalje takav XML u CIS.
Ne znam tko i odakle kupi datum/vrijeme slanja? Za sada vidim 2 mogućnosti:
  • Fiska (Raverus) kupi vrijeme iz Windowsa, a Windowsi dostavljaju DOS kasi vrijeme VEĆE za 3 sec. od stvarnog vremena (djeluje nemoguće, ali....)
  • Fiska (Raverus) kupi vrijeme iz nekog time servera, a Windowsi dostavljaju DOS kasi svoje vrijeme (dva različita sata daju različito vrijeme. Očekivano.)
Da li CIS izvuče vrijeme slanja iz nekakvog headera?


andrejp u postavkama WIndowsa je po defaultu uključena sinhronizacija vremena sa time.windows.com
May 25, 2016 at 11:11 AM
Edited May 25, 2016 at 11:24 AM
Imaš li ti te zapise u svojim bazama? I u onome što šalješ kao XML?

Ja isto tako koristim Fisku od bbanka, ali imam i zapise u DBF bazama o datumu/vremenu kreiranja računa (trenutni datum na PC-u), koji se koristi i za izračun ZKI-a, kao i datum/vrijeme slanja, koje se može naknadno mijenjati, jer koliko se sjećam, ZKI se ne kreira uz pomoć tog podatka, pošto se može desiti da se račun fiskalizira i naknadno (do 48h). Ono što je prvo upisano u DBF bazu, to se prepiše u XML i kao takav šalje u CIS. Ne bi tu trebalo biti nikakve razlike, niti da netko ili nešto promijeni podatke u XML-u.

Ja bih napravio kontrolu ZKI-a, baza i poslanih XML-ova, da se ustanovi gdje je greška. Meni najprije "smrdi" na neki bug u tvom programu (a i sam imao sličnih petljavina oko datuma IZDAVANJA i SLANJA, jer zvuče slično, a uopće nisu).

EDIT: uostalom, može se usporediti datum/vrijeme kreiranja XML fajla koji šalje FISKA (kao atribut samog fajla), sa datumom/vremenom koji je zapisan u sam XML fajl, u polju <tns:DatVrijeme> (to bi trebalo biti vrijeme izdavanja računa - ne slanja!). E sad, ako ne čuvaš XML zahtjeve koje šalješ u CIS, to je već problem druge vrste...
May 25, 2016 at 2:20 PM
Čini se da sam riješio ovu misteriju, iako treba još provjera.
Ako promijenim vrijeme u Windowsima dok je kasa pokrenuta, na kasi ostaje staro vrijeme. Da bi dobio novo vrijeme moram ponovo pokrenuti kasu. Očito Foxpro pokupi vrijeme prilikom pokretanja, a zatim koristi svoj interni clock. Možda ima preveliki timeout za refresh sistemskog vremena, što ću još provjeriti.

Nadalje, ako je uključena Windows sinhronizacija vremena, a po defaultu je, javlja se razlika od nekoliko sekundi nakon svake sinhronizacije. Posebno kod starijih računala sa slabijom baterijom.
Morat ću isključiti sinhronizaciju , a pokrenut ju samo prilikom pokretanja kompa (ili kase). Koja banana.

Hvala svima.
May 25, 2016 at 5:52 PM
Edited May 25, 2016 at 6:11 PM
**damir_ wrote:**
Datum i vrijeme izdavanja: 12.01.2015 09:31:34
Datum i vrijeme slanja: 12.01.2015 09:31:31
Bit će da ti brkaš ova dva pojma.

-Dakle pokupiš vrijeme i spremiš u varijablu. Spremiš u bazu račun sa tim podacima vremena iz varijable kao datum i vrijeme računa. (To kasnije ispisuješ na računu i to je vrijeme izdavanja)
-Kreiraš ZKI sa vremenom iz te varijable datuma i vremena izdavanja.
-U međuvremenu prođe možda sekunda dvije dok se to sve zaipiše u bazu ali to tebe uopće ne zanima.
-Šalješ račun sa podacima izdavanja iz upravo te varijable u koju si prethodno spremio vrijeme.

Dakle vrijeme slanja tek sad "pokupiš" neposredno prilikom slanja tj. nakon svih tih operacija i jedino može biti NAKON vremena izavanja (snimanja) po nekoj logici. U krajnjem slučaju može biti isto (ako imaš neku mašinu od PC-a i brutalan NET - da se zapiše u bazu, kreira zki, kreira zahtjev i posalje u finu u istoj sekundi...). Nikako ne može biti prvo poslan račun pa tek izdan. Vrlo jednostavno - Izdaješ račun u smislu - snimaš ga, a vrijeme slanja je trenutno vrijeme tek nakon što su se sve te operacije odradile. Onda ga ispisuješ sa parametrima vremena kod izdavanja. Nadam se da si shvatio...
May 28, 2016 at 12:13 PM
Što mislite o slijedećem? DOS kasa ujutro prilikom pokretanja pokupi vrijeme iz PC-a i dalje vrijeme mjeri po svom internom clocku (to POUZDANO ZNAM od ranije samo nisam "ubrao" posljedice toga). Znamo da se kasa ujutro pokrene i obično ne gasi do kraja radnog vremena.

Slučaj kad vrijeme u PC-u ide naprijed:
Vrijeme u PC-u do kraja dana požuri (ide naprijed) za nekoliko sekundi, što nije ne moguće kod starijih računala. Fiska (Raverus) prilikom slanja korektno kupi trenutno vrijeme iz PC-a, ali ono je nekoliko sekundi manje od vremena izdavanja u kasi (pogotovo navečer).

Slučaj kad vrijeme u PC-u kasni:
Windows time synchronisation se pokreće svakih 7 dana (po defaultu). Ako starije računalo kasni, taj 7. dan će se javiti greška 104, jer je Windows pomaknuo vrijeme "u naprijed".
Jun 8, 2016 at 1:05 PM
@damir_

Pogledaj ovu staru diskusiju glede sinkronizacije vremena: sinkronizacija