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.
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.
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.
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
- migracija 048: kolona uvoz na pdv_kpr (0=domaća nabavka, 1=uvoz)
- model PdvKpr.Uvoz; MapirajPPPDV(kir, kprDomace, kprUvoz) rutira uvoz u 006/106,
domaće u 008/108; test ažuriran + uvozni scenario
- repo: KPR Lista/DohvatiID/Kreiraj čitaju i pišu uvoz
- obračun: KPR se razdvaja na domaće/uvozne; obaveza ostaje na ukupnom KPR-u
- KPR forma: kvačica „Uvoz (JCI)"; lista: oznaka UVOZ uz broj dokumenta
model.MapirajPPPDV preslikava zbirove KIR/KPR na polja zvaničnog
obrasca PPPDV (001-005/103-105, 006-009/106-109, 110, povraćaj) u
celim dinarima; zbirovi se računaju iz zaokruženih polja. Uvoz
(006/106) i nadoknada poljoprivredniku (007/107) se ne prate → 0.
Sekcija PPPDV dodata na /pdv/obracun. Prikaz za popunjavanje, ne
elektronska predaja.
Interni obračun: izlazni (dugovani) PDV iz KIR i odbitni (prethodni)
PDV iz KPR po stopama, konačna obaveza za uplatu ili povraćaj/prenos.
PdvBezOdbitka se ne računa u odbitni PDV. Stranica /pdv/obracun
(podrazumevano tekući mesec), link u sidebaru. Brojčana podloga za
budući zvanični PPPDV/POPDV obrazac.
PDV se izvodi iz stope artikla po stavci (aproksimacija: nabavna cena
= osnovica bez PDV). Grupisanje po stopi (20→opšta, 10→posebna,
ostalo→oslobođena nabavka), broj dokumenta NAB-<id>, veza izvor/izvor_id.
Auto-zapisi se ne mogu ručno brisati u KPR; brisanje nabavke uklanja
vezani KPR zapis.
Kad se sačuva prodaja na klijenta (PDV obveznik), zapis se sam zavede u
KIR (model.KirIzProdaje grupiše stavke po stopi). Storno/brisanje prodaje
uklanja vezani KIR zapis (ObrisiPoIzvoru). Maloprodaja građanima (bez
klijenta) se preskače — ide preko fiskalizacije (Faza 3). Helper
modulUkljucen; auto-zapisi u UI nemaju ručno brisanje. Test.
Dasko