Hm,
pretpostavio sam a priori da uspješno odrađen zahtijev nije prerequisite za izdavanje računa jer bi poslijedice toga bile pre brutalne (od kolapsa maloprodajnog sustava RH u slučaju pada hosta do golemih komplikacija na prostorima koji stalno ili privremeno nemaju broadband i široki spektar disaster scenarija između).
...i čini se da mi je pretpostavka na mjestu, ovo kaže specifikacija:
U slučaju da se prilikom obrade poruke zahtjeva dogodi greška (poruka neispravna po XML shemi,
neispravan elektronički potpis i sl.) CIS vraća XML poruku odgovora koja sadrži opis greške. U tom
slučaju odgovor ne sadrži JIR i operater na naplatnom uređaju (blagajnik) izdaje kupcu račun bez JIR-a.
Poslovni proces izdavanja računa kupcu ne smije biti onemogućen zbog nastale greške ali obveznik
fiskalizacije je dužan ispraviti nepravilnosti u slanju poruke i poruku naknadno dostaviti. Proces u slučaju
greške je prikazan slijednim dijagramom na slici 2.
Čini se da smiješ izdati račun čak i kada pogrešno isprogramiraš sustav, koristiš krivi certifikat i sl, samo to moraš dojaviti i naknadno poslati ispravno. I još jedan pointer, delayed job ti omogućava da kao parametar šalješ cijelu instancu modela koju ovaj marshallizira iirc, nemoj to raditi zato što ako imaš buhu u modelu ćeš ju mnogo teže naknadno ispraviti na način da se ti requesti na kraju pošalju prema hostu bez mnogo dopunskog petljanja.
Idealno bi bilo ako bi bilo dovoljno poslati id transakcije kao parametar u job, pa da trenutačna verzija koda zna što sa time treba napraviti (drugi razlog su preformanse).
Borna