Dashboard: 'bez fiskalnog računa' razdvojeno na prodaju i servis (posebna
dugmad koja vode na tačan spisak, ne uvek na /prodaja).
Servis detalji: kartica 'Fiskalni račun' sad jasno razlikuje avansni od
konačnog računa; dodata posebna kartica za povraćaj viška avansa. Modal
za preuzimanje više se ne zaglavljuje kad avans pokrije ceo iznos (dugme
'Preuzmi' bez obaveznog unosa u polju Primljeno).
Štampa fiskalnog računa (/servis/{id}/fiskalni-racun) sad prioritetno
vraća konačan (Normal/Sale) račun umesto poslednjeg upisanog — ranije je
avansni povraćaj (upisan posle konačnog računa) prekrivao prikaz stvarne
fakture. Kad postoji i povraćaj viška avansa, štampa se u istom prozoru
odmah posle konačnog računa (izbegnut drugi popup koji brauzer blokira).
Avans se do sada nikad nije fiskalizovao — bio je samo interno polje. Zbog
toga je konačni fiskalni račun (pri preuzimanju) uvek prikazivao povraćaj
protiv PUNOG iznosa stavki, bez znanja da je avans već delimično plaćen.
Sad:
- avans se fiskalizuje kao Advance/Sale pri kreiranju/izmeni naloga
(fiskalizujAvansServisa — fiskalizuje samo deltu ako se avans dopunjava)
- konačan Normal/Sale račun pri preuzimanju šalje advancePaid/advanceTax/
advanceLastInvoiceNumber/advanceLastInvoiceDateTime — PFR sad zna za avans
i tačno računa preostali dug i kusur
- ako avans premaši punu cenu, konačan račun se zatvara do pune cene, a
razlika se automatski vraća posebnim Advance/Refund zahtevom
- servis_detalji modal prikazuje 'Avans premašuje cenu — vratiti klijentu X'
umesto tihog svođenja duga na 0
Uzgred ispravljena dva mesta koja su koristila DohvatiPoServisu (samo
najnoviji zapis, bilo kog tipa) umesto DohvatiPoServisuITip(Normal,Sale):
- PromeniStatus je avansni račun pogrešno tretirao kao 'već fiskalizovano'
i preskakao konačan račun kad god je nalog imao avans
- RetryFiskalizacija i FiskalGreska detekcija na servis_detalji stranici
su imale isti problem — nalog sa avansom je izgledao fiskalizovan i
dugme 'Pokušaj ponovo' se nije ni prikazivalo
PorezIzBrutoAvansa pretpostavlja opštu PDV stopu (20%) jer stavke u trenutku
uplate avansa još nisu poznate — nema opšteg rešenja bez pretpostavke.
Dugme 'Promeni' za oba polja se sad krije kad je nalog u statusu Preuzeto —
garantni list je već izdat na osnovu garancije, a nalog je zatvoren pa nema
razloga za promenu servisera. Dodata i server-side provera u
AzurirajGarancijaDana/AzurirajTehnicar (ne samo skrivanje dugmeta u UI).
Input 'Primljeno (din)' u modalu za preuzimanje je bio VAN <form> koji se
submituje — koristio se samo za JS prikaz kusura na ekranu, ali server ga
nikad nije primao. Fiskalni račun je uvek prikazivao Gotovina=dug (posle
avansa), Povraćaj=0,00, bez obzira šta je kupac stvarno predao.
Premešten input u POST formu; fiskalizujServis sad prima primljeno i šalje
max(dug, primljeno) kao Payment.Amount — PFR sam računa kusur, isto kao kod
Prodaje (fiskal.NapraviZahtev).
NAPOMENA: kad nalog ima avans, PFR i dalje računa povraćaj protiv PUNOG iznosa
stavki (ne umanjenog za avans), jer se avans nikad ne fiskalizuje kao posebna
transakcija — PFR ga ne 'vidi'. Za tačan kusur i u tom slučaju bi avans morao
biti fiskalizovan kao Advance tip transakcije pri uplati; to je veći, zaseban
zahvat.
Do sada je jedini način da se poništi naplaćen/preuzet servisni nalog bio
fizičko brisanje (ObrisiNalog), koje ostavlja KIR/KPO/fiskalne zapise sa mrtvim
izvor_id — prihod ostaje prijavljen za nalog koji više ne postoji.
Migracija 100: servisni_nalozi dobija stornirano/razlog_storniranja (kao
prodajni_nalozi/nabavke). ServisRepo.Storno vraća ugrađene delove na stanje
ali NE briše nalog. Novi handler StornoNaloga (dozvola servis.storno):
- KIR/KPO original ostaje, dograđuje se storno stavka (model.KirStorno/KpoStorno)
- fiskalni refund (best-effort) preko refundujServis — Refund zahtev sa
ReferentDocumentNumber ka originalnom PFR broju, isti obrazac kao stornirajProdaju
- ObrisiNalog sad odbija brisanje ako nalog već ima fiskalni/KIR/KPO zapis i
upućuje na Storno
stornoBezRefunda (dashboard upozorenje) prošireno da prati i servisne stornose
bez uspešnog fiskalnog refunda, ne samo prodaju.
- Dashboard kartica prikazuje naloge bez KIR/KPO/fiskalnog upisa i sumnjive duplikate (double-submit), sa zaštitom od automatskog dupliranja prihoda pri bulk dopuni
- Registrovane nedostajuće KPO dozvole (kpo.pregled/dodaj/obrisi) — modul je bio potpuno nedostupan
- Uklonjen suvišan/nefunkcionalan 'Ukloni nalog' (duplirao Storno bez stvarne razlike); Storno u listi prodaje sad vodi direktno na formu
- Kasir na fiskalnom računu koristi ime prijavljenog korisnika umesto fiksnog podešavanja
- Fiskalni računi za nalog uvek prikazuju najnoviji zapis (original vs. refund posle storna)
- Verifikaciona stranica (/v/) jasno označena kao lokalna test simulacija, ne prava provera kod PURS-a; dodat prikaz kusura
- Mock brojač fiskalnih računa (kartica emulator) sad preživljava restart servera
- PDV uslovi (Moduli.pdv) na: predračun, otpremnica, garantni list, prodaja_stampa
- Modal za preuzimanje: jedna cena (sa/bez PDV), ne duplo
- Javna status stranica: PDV uslovi za cene, predlog, checkbox-ove
- Svi print templejti: viewport=device-width+min-width, bez responsive
- JavniToken generisan za postojeće naloge bez tokena (QR popravka)
- UkupnoSaPdv() metode na ServisniRad i ServisniDeoSaArtiklom
- UkupnoBezPdv() na StavkaProdaje
Dodat FiskalRepository.DohvatiPoServisu (repo + interfejs)
PodaciDetaljiNaloga.FiskalniRacun — učitava se pri otvaranju detalja
Kartica u servis_detalji.html — PFR broj, vreme, brojač, QR, link ka PURS-u
Migracija 082: nacin_placanja i naplaceno na servisni_nalog
Model, repo, handler — pun lanac za čuvanje naplate
fiskalizujServis helper — šalje radove+delove ka PFR serveru
Modal za Preuzeto dobio izbor načina plaćanja (Gotovina/Kartica/Virman)
Dasko