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

May 24 at 10: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 at 7: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 at 8: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 at 11: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 at 12:11 PM
Edited May 25 at 12:24 PM
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 at 3: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 at 6:52 PM
Edited May 25 at 7: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 at 1: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 at 2:05 PM
@damir_

Pogledaj ovu staru diskusiju glede sinkronizacije vremena: sinkronizacija