Nova stranica /admin/blokirane-ip — lista IP adresa sa previše neuspelih pokušaja
prijave (broj neuspeha, poslednji pokušaj, preostalo vreme zaključavanja) i dugme
za ručno odblokiranje. Nova dozvola 'bezbednost.odblokiraj', namerno rezervisana
isključivo za ulogu superadmin (admin je nema — odblokiranje zaobilazi bruteforce
zaštitu). Repo metode PokusajiPrijaveRepo.ListaBlokiranih/Odblokiraj.
Novi sistem fiskalizacije izveštava SUF kontinuirano po računu, pa presek stanja
(zaključenje dana) više nije zakonska obaveza — samo opcioni reset brojača na
ekranu. Dodata polja od/do datuma (podrazumevano danas) za preuzimanje izveštaja
nezavisno od toga da li je ikad urađen presek. Dugme 'Zaključi dan' preimenovano
u 'Resetuj brojače (opciono)', manje istaknuto, sa jasnijim opisom u potvrdi.
- Nova stranica fiskal_pazar: presek prometa od poslednjeg zaključenja, zaključenje dana, generisanje PDF izveštaja
- fiskal.go: dodati pozivi Presek/ZakljuciDan/GenerisiIzvestaj ka /api/financial/summary i /api/financial/report/summary
- PrazninaKnjigovodstva razdvojena na Prodaja/Servis varijante sa ID listama za direktne linkove sa dashboard-a
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.
- 'Predviđeni datum završetka' je bio prazan iako servis_detalji stranica prikazuje
računat default (datum prijema + rok iz podešavanja) — StampaEskalacionogLista
nije primenjivala isti default, sad je usklađeno.
- 'Poziv klijenta (obaveštenje o dijagnozi)' se sad auto-popunjava datumom odluke
kad klijent odgovori preko javne stranice (QR kod) — nema potrebe za ručnim
unosom poziva ako je klijent već digitalno potvrdio da je obavešten.
'Poziv klijenta (obaveštenje o završetku)' ostaje ručno polje — ne postoji
ekvivalentan trag (klijent ne potvrđuje ništa preko javne stranice posle
završetka, samo je vidi).
@page je bio postavljen na landscape, a fiksni min-width:780px na body je terao
sadržaj šire nego što uspravna A4 stranica ima mesta. Smanjen font/padding u
tabeli da svih 10 kolona stane u uspravan format bez sečenja.
Servisni KIR upis nije imao nijedan mehanizam oporavka — ako auto-upis pri
preuzimanju padne, B2B servisni promet tiho ispadne iz PDV evidencije bez traga
za korisnika. Dodato po uzoru na Prodaju:
- kirKandidatiServisa (preuzeti nalozi sa identifikovanim kupcem)
- KirBackfillServisa ruta + dugme "Uvezi iz servisa" na KIR stranici
- PraznineKnjigovodstva sad broji i servisne KIR praznine (dashboard upozorenje)
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.
Na KIR stranici se sad vidi kartica sa B2B prodajama koje je automatski
backfill preskočio jer izgledaju kao dupli submit forme naplate (isti kupac
i iznos u roku od 60s) — sa objašnjenjem i linkom na ručni unos ili storno.
- 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
- dugme Naplati otvara modal (primljeno/kusur, način plaćanja, prikaz računa)
- primljeni iznos se prosleđuje u fiskalni zahtev radi tačnog Gotovina/Povraćaj
- nova ruta i handler za prikaz/štampu fiskalnog računa prodaje
- fiskalni tab se otvara preko imenovanog prozora (bez blokiranja popup-a)
- Fisk mock: refund se sada računa iz stvarnih plaćanja, ne fiksno 0
Traka za pretragu/filtere na telefonu je bila samo flex-wrap red koji se
zbijao nezgodno. Sada: '+ Nova prodaja' preko cele širine na vrhu, pretraga
preko cele širine u svom redu, Od/Do datum jedan pored drugog, a dugmad
(Stornirano/Prikaži/Resetuj/Ovaj mesec) se sam uklapa po dva u red.
Dropdown za pretragu klijenta u Novom nalogu je imao tvrdi limit od 100
rezultata. Sada radi po istom obrascu kao u Novoj prodaji — učitava po 30,
i dogrejava sledećih 30 kad korisnik skroluje do dna liste.
Kad je postavljena pozadinska slika (Podešavanja → Izgled), tekst van .kartica
(filter labele, naslovi sekcija, prazna stanja, paginacija, radio-dugmad bez
klase) ostajao je u tamnoj boji teme i gubio se preko slike. Dodato: pravilo
za .polje-labela/.sekcija-naslov/.prazno-stanje, opšte pravilo za elemente sa
inline bojom teme, i podrazumevana bela boja za ceo glavni sadržaj (.sadrzaj)
koja se nasleđuje na gole elemente bez ijedne klase.
Lista prodaje po prvom ulasku (bez upit parametara) prikazuje samo današnje
naloge; čim korisnik pošalje formu (i praznu), poštuje se njegov izbor.
Čekboks 'Samo stornirano' sada je stilizovan kao dugme-prekidač. Dugme
'+ Nova prodaja' premešteno ispred trake za pretragu/filtere.
Vrsta dokumenta se više ne bira ručno u formi — određuje se iz dužine unetog
broja (13 cifara = JMBG, 9 = broj lične karte). Dodata provera JMBG kontrolne
cifre i datuma rođenja po standardnom mod-11 algoritmu.
Zakon o PDV (čl. 42, sadržaj računa) zahteva adresu kupca na fakturi za
pravna lica — polje 'Mesto' (grad) samo nije dovoljno. Dodata kolona
adresa u klijenti, novo polje na formi, obavezno kad je tip pravno.
Kartica izabranog klijenta u Novoj prodaji sad prikazuje PIB/JMBG
(zavisno od tipa), adresu, mesto, telefon i email — svako popunjeno
polje u svom redu, samo kad je klijent već izabran.
window.ntechToast je crtao svaki novi toast na istoj fiksnoj poziciji pa
su se preklapali kad se više njih pojavi zaredom (npr. auto-snimanje
više polja). Sad se dodaju u zajednički kontejner koji ih slaže jedan
iznad drugog preko flex-a.
Flash poruke su menjale raspored na 480px dok ostatak aplikacije koristi
768px kao mobilni prelom — ujednačeno na 768px.
Refundacija po propisu zahteva PIB/JMBG kupca — ako nalog nema klijenta
sa upisanim poreskim brojem, storno sad traži ručni unos pre nego što
se pošalje fiskalni refund zahtev.
TipPlacanja je upoređivao velika slova (Gotovina/Kartica/Virman) dok
Prodaja čuva nazive malim slovima (gotovina/kartica/prenos) — svaka
prodaja je zato padala na paymentType "Other" umesto stvarnog načina
plaćanja. Poređenje je sad case-insensitive.
- Lista prodaje: filter po periodu (od/do), prečica 'Ovaj mesec', filter samo stornirano
- Nova prodaja: pretraga klijenta sa filterom tipa (sva/pravna/fizička lica) umesto
običnog dropdown-a, sa dogruzavanjem rezultata pri skrolu
- Ispravljen nedostajući CSRF token u formi nove prodaje (POST je uvek padao na 403)
- Ispravljeno vizuelno poravnanje polja Način plaćanja
Kolona datum_placanja je postojala u pdv_kpr tabeli ali se nikad nije
popunjavala za auto-upise iz nabavke — relevantno za gotovinski PDV odbitak.
Dodato polje Nabavka.DatumPlacanja (migracija 096, opciono polje u formi
nabavke, prikaz u detaljima), KprIzNabavke ga sada prosleđuje u KPR zapis.
Zbirni 'rucno' KIR zapis dnevnog pazara nema povratnu vezu ka pojedinačnim
maloprodajnim nalozima, pa ga naknadni storno ili nova prodaja tog dana ne
mogu sami korigovati. Umesto tihog auto-prepisivanja poreske evidencije,
PdvKir handler sada upoređuje upisani Ukupno sa trenutno preračunatim
DnevniPrometMaloprodaje i u listi prikazuje bedž 'zastareo iznos' sa linkom
na formu za osvežavanje (koja već ima logiku zamene starog zapisa).
Prethodna zaštita od duplog unosa (77320d2) je trajno onemogućavala ispravku
zbirnog KIR zapisa jednom kad bi bio sačuvan — a taj zapis nema vezu nazad ka
pojedinačnim nalozima, pa naknadni storno ili nova prodaja istog dana ne mogu da
ga koriguju kroz postojeće mehanizme (ObrisiPoIzvoru radi samo za B2B auto-KIR).
Sad se ponovni upis za isti dan tretira kao ažuriranje: stari zapis (po broju
dokumenta FISK-YYYYMMDD) se briše i zamenjuje trenutno tačnim iznosima. Forma i
dalje upozorava da zapis već postoji, ali dugme dozvoljava svesno ažuriranje
umesto da bude trajno sakriveno.
SacuvajDnevniPazarKir je upisivao ručni zbirni KIR zapis za dati dan bez provere
da li već postoji — za razliku od auto-KIR-a iz pojedinačnih faktura (koji ima
PostojiZaIzvor zaštitu), ovde ništa nije sprečavalo duplo klikanje/ponovni unos
istog dana, što bi duplo precenilo PDV osnov u zvaničnoj evidenciji.
Broj dokumenta (FISK-YYYYMMDD) je već deterministički po danu, pa se koristi kao
prirodni ključ za proveru. Forma sad prikazuje upozorenje i sakriva dugme za upis
ako je dan već zaveden.
Dasko