Ponovni ulazak naloga u status Preuzeto (dupli klik, dupli submit modala naplate,
sekvenca Preuzeto→Završeno→Preuzeto) je ponovo pokretao fiskalizaciju i upis u
KIR/KPO bez provere da li već postoje — svaki ulazak je duplirao prihod i PDV
obavezu, a dashboard/backfill duplikat nikad nije prijavljivao jer je dovoljan
bio bar jedan zapis. Dodate PostojiZaIzvor/DohvatiPoServisu provere pre svakog
upisa (isti obrazac kao RetryFiskalizacija).
KIR upis servisa refaktorisan u model.KirIzServisa (deljeno sa budućim backfill-om).
KpoRepo.Kreiraj sad dodeljuje redni_broj automatski (COALESCE(MAX,0)+1) — kolona
je postojala u šemi ali se nikad nije popunjavala, pa knjiga o ostvarenom prometu
paušalaca nije imala redni broj koji Pravilnik zahteva.
Garancija se sad čuva kao broj dana (GarancijaDana), a konkretan datum
(GarancijaDo) se računa tek kad nalog pređe u Završeno/Preuzeto — na osnovu
stvarnog datuma završetka, ne datuma prijema. Ranije se datum računao odmah
pri prijemu naloga, pa je garancija krenula da teče pre nego što je popravka
uopšte gotova.
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.
Storno je fizički brisao vezani KIR/KPR/KPO zapis — zakon o računovodstvu ne
dozvoljava brisanje poslovnih knjiga (KPO dodatno ima redni broj bez prekida).
Sad se original čuva, a storno se dograđuje kao poništavajuća stavka
(negirani iznosi, referenca na original) — model.KirStorno/KprStorno/KpoStorno.
Usput ispravljen i pravi uzrok prijavljenog bug-a: kirKandidatiProdaje je
filtrirala samo internu mapu, ne i listu naloga koju obilazi KirBackfillProdaje
— stornirani nalozi su zbog toga dobijali ponovni (pogrešan) KIR upis.
- 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.
KirIzProdaje je postavljao oba datuma na nalog.Datum. Za prodaju upisanu
odmah (SacuvajProdaju) to je ispravno jer je knjiženje istog trenutka.
Za backfill starih naloga (KirBackfillProdaje) upis kasni za periodom —
datum_knjizenja je sada trenutak backfilla, ne datum same prodaje.
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).
parseFormuProdaje je proveravala samo pozitivnu količinu i nenegativnu cenu.
Popust preko 100% bi dao negativnu osnovicu/PDV, a pdv_stopa (hidden/JS polje)
mogla je stići sa proizvoljnom vrednošću direktnim POST-om mimo forme —
fiskal.OznakaPDV bi za takvu stopu tiho vratio pogrešnu poresku oznaku.
Sada se popust ograničava na 0-100%, a pdv_stopa mora biti 0, 10 ili 20.
ObrisiProdaju je brisao samo auto-KIR zapis, ali ne i fiskalni refund i KPO
zapis, za razliku od StornoProdaje koji radi sve troje. Izdvojena zajednička
stornirajProdaju funkcija koju sada koriste oba handlera. Dozvola ujednačena
na prodaja.obrisi (u skladu sa rutom u main.go) — ranije se interno
proveravala prodaja.storno, što je bilo nekonzistentno sa ruterom.
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.
KirIzProdaje je za B2B fakture upisivao pun (nediskontovan) iznos u KIR, ignorišući
popust_procenat — PDV evidencija je bila precenjena za stavke sa popustom. Isti
propust je postojao u ProdajaRepo.Kreiraj (cena_bez_pdv/pdv_iznos po stavci računati
bez popusta, dok je ukupno polje popust uračunavalo). fiskal.NapraviZahtev je to
slučajno kompenzovao ponovnim primenjivanjem popusta nad već (pogrešno)
nediskontovanom vrednošću iz baze — sad bi to duplo diskontovalo, pa je uklonjeno.
Usput ispravljena i dva zastarela testa koja su pogrešno pretpostavljala da je
CenaPoKomadu bruto cena (aktuelna semantika, potvrđena i u ntech.js, jeste neto).
- Prihod meseca: izbačeni stornirani nalozi, servis preko naplaceno+avans
- Servis KIR: neto cena + PDV po stvarnoj stopi (PdvKir.DodajNeto), bez hardkodovanih 20%
- TopKlijenti: samo preuzeti nalozi sa naplatom/avansom
- Izveštaji: mesečni ključevi sidreni na 1. u mesecu (bez preliva dana)
- BUG-04: konačna cena servisa bez dvostrukog računanja delova
- Dashboard: uklonjena kartica „Prihod ovog meseca"
- Default port 3000
- Dodati testovi: prihod/storno/delovi/nivelacija/KIR/mesečni ključevi
- 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
Dasko