Pet odluka koje se posle ne dodaju, donete pre prvog knjiženja
ERP se bira na deset godina, a ocenjuje u drugoj. Ono što odlučuje kako sistem izgleda u desetoj godini nisu ekrani nego pretpostavke ugrađene u model podataka pre nego što je proknjižen prvi dokument: kako se vodi analitika, kako se izoluju podaci, ko sme šta i šta se dešava sa istorijom kad se pravilo promeni. NG One te odluke ima donete. Sve što na njima stoji — devet poslovnih prostora, oko 60 tehničkih domena i osam procesa koji ih povezuju od ponude do naplate — deli jedan model podataka, jednu izolaciju i jednu autorizaciju.
- Modularni monolit
- Izolacija u bazi (RLS)
- Šest slojeva autorizacije
- OpenAPI nad svime
- Verzionisana konfiguracija
- Control/Data Plane granica
Zašto arhitektura, a ne spisak funkcionalnosti
Svaki ERP na tržištu ima fakture, zalihe i glavnu knjigu. Razlika se ne vidi na demonstraciji nego treće godine, kad se traži nešto što model nije predvideo.
Funkcionalnost se dodaje. Pretpostavka se ne dodaje. Kad sistem godinama radi sa modelom koji nema analitičku dimenziju na stavci knjiženja, dimenzija se ne uvodi podešavanjem — uvodi se novim kontnim okvirom i ponovnim knjiženjem istorije, što niko ne radi. Kad je poreska stopa upisana kao broj u kodu, sistem ne zna da je prošle godine bila druga, i prva ispravka dokumenta iz prethodnog perioda tiho proizvede pogrešan iznos. Kad je autorizacija ostala na frontendu, svaki sledeći kanal — mobilni uređaj, integracija, API ključ — otvara vrata koja niko nije zaključao. Tri različita problema, isti uzrok: odluka koja je odložena dok se nije okamenila.
NG One te odluke ima donete, zapisane i sprovedene u šemi. Jezgro je modularni monolit — jedan deploy, moduli sa jasnim granicama i komunikacijom isključivo preko imenovanih interfejsa i domenskih događaja. To nije kompromis nego izbor: mikroservisi bi doneli distribuiranu transakciju tamo gde treba jedna, a granice modula postoje i bez mreže između njih. Podaci klijenata dele bazu, ali ne dele red — izolacija je politika u PostgreSQL-u koju aplikacija ne može da zaobiđe, a build pada ako neka tabela od nje odstupi. Pravna lica su dimenzija unutar klijenta, ne druga instalacija.
Iznad toga stoji sloj koji većina domaćih sistema nema kao proizvod: konfiguracija je podatak, verzionisan i auditiran. Tipovi dokumenata, statusne mašine, podešavanja, posting pravila i cenovnici imaju datum važenja i istoriju izmena, a svaka transakcija čuva referencu na verziju pravila po kojoj je nastala. Praktična posledica je jednostavna: konsultant menja ponašanje sistema kroz konzolu bez programera, a izmena od danas nikad ne menja ono što je juče proknjiženo. Sve što sledi na ovoj stranici izvedeno je iz te tri rečenice.
Pet ne-retrofitabilnih odluka
Izvedene su iz mapiranja Pantheona, Business Centrala, Odoo-a, SAP-a B1 i regionalnih igrača, i iz srpskih propisa za 2026. Nijedna nije funkcionalnost koju korisnik vidi — sve su pretpostavke u modelu podataka, i upravo zato se posle ne mogu dodati.
Dimenziono knjiženje
Svaka stavka knjiženja nosi neograničen skup analitičkih dimenzija — mesto troška, nosilac, projekat, sektor, region, kanal — umesto da se analitika širi kroz kontni plan. Zašto se ne dodaje kasnije: dimenzija koja ne postoji u trenutku knjiženja ne postoji ni u istoriji. Sistem koji je analitiku rešio šifrom konta drži je u kontnom okviru, a ne na stavci; uvođenje dimenzija tada znači novi kontni okvir i ponovno knjiženje svega što je zatvoreno. NG One knjiži dimenziono od prve stavke, pa controlling i projektno računovodstvo nisu novi modul — samo još jedna dimenzija nad podacima koji je već nose.
Vremenski važeći zakonski parametri
Neoporezivi iznosi, osnovice doprinosa, minimalna zarada, kamatne stope i stope PDV-a su uvek šifarnik sa datumom početka i kraja važenja, nikad konstanta u kodu. Zašto se ne dodaje kasnije: sistem koji je stopu upisao kao broj ne zna da je prošle godine bila druga. Prva ispravka dokumenta iz prethodnog perioda primeni današnju stopu na prošlogodišnji promet, a greška se ne vidi dok ne dođe kontrola. U Srbiji se ovi parametri menjaju najmanje jednom godišnje, često i u toku godine — obračun zarada i PDV bez ovog pravila pucaju u prvoj izmeni propisa.
Tenant model spreman za agencijski režim
Model identiteta predviđa da jedan korisnik pripada većem broju klijenata, sa zasebnim ulogama u svakom — knjigovođa u agenciji radi portfelj iz jednog pristupa, bez odjave i ponovne prijave, dok izolacija podataka između klijenata ostaje netaknuta. Zašto se ne dodaje kasnije: sistem koji je pretpostavio da je jedan korisnik jedna firma agenciju rešava zasebnom instalacijom po klijentu. Od tog trenutka se svaka nadogradnja plaća onoliko puta koliko agencija ima klijenata, a to je trošak koji ne prestaje. U NG One-u je agencijski portfelj režim istog modela identiteta — jedna instalacija, jedna nadogradnja, granica izolacije netaknuta.
Domenski graf uz razdvojene integracije
Interno su otpremnica, faktura, PDV evidencija i naplata povezani entiteti jednog toka — država ih je 2026. i formalno povezala, pa se taj graf modeluje od početka. Spolja je slika drugačija: eFaktura, eOtpremnica, CRF, fiskalizacija i PDV evidencije su različiti sistemi sa različitim životnim ciklusima, pa svaki dobija sopstveni adapter, sopstvene statuse sinhronizacije i sopstveni retry, bez pretpostavke o zajedničkom stanju. Zašto se ne dodaje kasnije: povezanost koja se ugradi u integracioni sloj znači da zastoj jednog državnog servisa zaustavi tokove koji sa njim nemaju veze, a razdvajanje tada traži prepravku domena, ne adaptera. Povezanost je u domenu; integracije su namerno razdvojene.
Clean-core ekstenzije i verzionisana konfiguracija
Prilagođavanje klijentu nikad ne dira jezgro: proširenja se kače na domenske događaje, a konfiguracija — tipovi dokumenata, statusne mašine, podešavanja, pravila — je podatak sa verzijom, istorijom i diff pregledom. Zašto se ne dodaje kasnije: kad klijentska izmena jednom uđe u jezgro, nadogradnja se pregovara sa svakom izmenom posebno. Ta cena je poznata i kod domaćih i kod svetskih igrača — kastomizacije koče upgrade, a upgrade koji kasni postaje zamrznuta verzija koju niko ne sme da dodirne. Verzionisanje dodatno znači da izmena podešavanja danas nikad retroaktivno ne menja ono što je juče proknjiženo.
Svih pet je zapisano u registru arhitektonskih odluka (ODLUKE.md §19), sa razlogom, razmotrenim alternativama i posledicom po model podataka uz svaku. Odluka ovog reda se ne opoziva, pa mora da se može pročitati — i da se vidi na podacima: otvorite bilo koju stavku glavne knjige i na njoj su dimenzije, otvorite dokument iz zatvorenog perioda i na njemu je verzija pravila po kojoj je nastao.
Jezgro
Tehnološki izbori su fiksirani i javni. Nijedan nije napravljen zbog mode — svaki rešava problem koji smo videli u sistemima iz kojih klijenti prelaze.
Interfejs
React 19 SPA · tipizirani klijenti iz OpenAPI-ja
Jedna aplikacija, serverski podaci odvojeni od stanja interfejsa, dve teme i dve gustine. Dozvole na klijentu samo prikazuju — nikad ne odlučuju.
API sloj
REST · OpenAPI · ProblemDetail (RFC 9457)
Specifikacija je izvor istine, a ne dokumentacija napisana posle: iz nje se generišu tipizirani klijenti. Isti resursi nose i spregu ka MCP alatima.
Identitet i autorizacija
Spring Authorization Server · OAuth 2.1 · OIDC · Argon2id
Šest slojeva autorizacije na serveru, nikad na klijentu: uloge, opseg podataka, limiti, razdvajanje dužnosti, maker-checker i delegacije — uz nepromenljiv dnevnik.
Dokument-framework i workflow kernel
Statusne mašine · automatska pravila · outbox
Životni ciklus dokumenta, odobrenja sa limitima i pravila događaj → uslov → akcija stoje u jezgru, pa svaki modul dobija isto ponašanje umesto sopstvene verzije.
Modularni monolit
Spring Boot 4.1 · Spring Modulith 2.1 · Java 25
Jedan deploy, moduli sa tvrdim granicama: komunikacija ide isključivo preko imenovanih interfejsa i domenskih događaja kroz outbox, a arhitektonski testovi obaraju build kad se granica prekorači.
Podaci i izolacija
PostgreSQL 18 · Row Level Security (FORCE)
Svaka tabela sa podacima klijenta nosi identifikator klijenta i politiku koju runtime nalog ne sme da zaobiđe; meta-test nad šemom obara build ako je neka ostane bez nje.
Modularni monolit
Spring Boot 4.1 na Javi 25, Spring Modulith 2.1, jedan deploy. Moduli imaju tvrde granice: komunikacija ide isključivo preko imenovanih interfejsa i domenskih događaja kroz outbox, a arhitektonski testovi obaraju build kad neko granicu prekorači. Mikroservisi nisu odbačeni zauvek — komunikacija je već takva da se modul može izdvojiti kad za to bude razlog, a ne pre.
Izolacija klijenata u samoj bazi
PostgreSQL 18. Svaka tabela sa podacima klijenta nosi identifikator klijenta i politiku Row Level Security u režimu FORCE; runtime nalog nema pravo da je zaobiđe. Kontekst klijenta se postavlja na početku svake transakcije, a meta-test nad šemom obara build ako neka takva tabela ostane bez politike. Izolacija tako nije disciplina programera nego osobina baze.
Više pravnih lica unutar jednog klijenta
Pravno lice je dimenzija, ne druga instalacija: svaka transakciona tabela nosi pravno lice, numeracija dokumenata ide po pravnom licu, a korisnik dobija pristup po pravnom licu koji server proverava na svakoj komandi. Hijerarhija je klijent → pravna lica → organizacione jedinice → dokumenti i magacini. Podržan je rad u više valuta, sa NBS kursnom listom kao izvorom.
Identitet po standardu
Ugrađen Spring Authorization Server: OAuth 2.1 i OpenID Connect, authorization code sa PKCE za SPA, rotacija refresh tokena, ES256 sa JWKS objavom ključeva. QR prijava za skenere u magacinu je poseban grant nad istim serverom, a ne zaobilaznica pored njega. Lozinke idu kroz Argon2id. Sopstveni auth protokol nije ušao u razmatranje.
Dokument-framework i statusne mašine
Dokument nije generička tabela sa magičnim tipom nego tabela po modulu uz registar tipova i konfigurabilnu statusnu mašinu: stanja, prelazi, uslovi i efekti se podešavaju po tipu dokumenta, a imenovani uslovi i efekti su registrovani u kodu. Sve što je knjigovodstveno ili poresko je tipizirana kolona; JSONB nosi samo dodatna polja. Invarijante su uvek uključene.
Workflow kernel
Život dokumenta vodi statusna mašina; rad ljudi vodi workflow kernel — zadaci, jedno i višekoračna odobrenja, uslovno grananje po iznosu ili tipu, rokovi sa eskalacijom, delegiranje i zamene. Kernel je sopstveni i namerno mali: pun BPM sistem donosi tuđ model podataka, tuđ UI i operativni teret koji odobravanje fakture ne opravdava.
Automatska pravila
Događaj → uslov → akcija, konfigurisano kroz konzolu, sa imenovanim akcijama registrovanim u kodu. Sistem sam kreira zadatak, pošalje obaveštenje, napravi dokument ili izvrši prelaz kad su uslovi ispunjeni — i svaki takav potez ostaje vidljiv u istoriji izvršenja, sa odgovorom na pitanje šta je sistem uradio sam i po kom pravilu.
Poslovni kalendar i periodi
Fiskalna godina ne mora da bude kalendarska. Periodi se vode po modulu, računovodstveni odvojeno od poreskih, sa privremenim i konačnim zatvaranjem — a ponovno otvaranje ide isključivo kroz odobrenje i ostaje u dnevniku. Dokument nosi pet datuma razdvojenih od prvog dana: datum dokumenta, prometa, knjiženja, valute i poreski datum, svaki sa svojom ulogom u obračunu.
Verzionisanje pravila i „objasni knjiženje”
Posting šeme, poreske stope, cenovnici, kursevi i konfiguracija dokumenata su vremenski važeći i verzionisani. Svako knjiženje čuva referencu na tačnu verziju pravila i snapshot ključnih vrednosti, pa funkcija „objasni knjiženje” za svaku stavku pokazuje koji dokument, koja šema u kojoj verziji, koja stopa, koji kurs i ko je i kada menjao konfiguraciju. Stara transakcija se rekonstruiše identično posle bilo koje izmene.
Konfigurabilnost bez programera
Podešavanja imaju metapodatke — tip vrednosti, opseg važenja, validaciju i uputstvo — pa ih konzola renderuje sama: novo podešavanje ne traži novi ekran. Konsultant kroz konzolu otvara klijenta, bira module, primenjuje predefinisan config set, kreira prvo pravno lice i admin nalog. Svaka izmena konfiguracije ide u append-only dnevnik sa starom i novom vrednošću.
Import i izvoz kao okvir
Uvoz nije skripta po modulu nego platformski okvir: template builder kojim konsultant sam pravi šablon, mapiranje kolona izvora na polja NG One-a koje se pamti i ponovo koristi, validacija sa greškom po redu, dry-run diff pre potvrde i idempotentnost — ponovljen uvoz ne duplira. Izvoz u Excel postoji na svakoj listi u sistemu, ne samo na izveštajima.
Verzije prate `TECH_LOCK.md` i menjaju se kroz kontrolisan kvartalni prozor; svaki veći skok nosi zapis odluke i proveru kompatibilnosti.
NG One Platform Control Center
Upravljanje platformom je zaseban proizvod, a ne najveći nalog u sistemu.
Uobičajeno rešenje je „super tenant” — nalog koji vidi sve, jer je nekome trebalo da otvori klijenta i pogleda zašto se žali. To rešenje je tiho i praktično dok se ne postavi pitanje ko je juče u 23h čitao vaše ugovore i marže. Odgovor obično ne postoji, jer sistem koji je granicu ostavio ulozi nema šta da zabeleži.
NG One deli platformu na dve ravni sa tvrdom granicom između njih. Control Plane drži metapodatke o klijentima: pretplate, licence, potrošnju, zdravlje, podršku, platformski dnevnik. Data Plane drži poslovne podatke klijenta. Platformsko osoblje živi u prvoj ravni, sa obaveznom dvofaktorskom prijavom, i podrazumevano nema nikakav pristup drugoj — poslovne podatke ne čita ni direktnim upitom, jer nad njima nema ni pravo u bazi. Sve što Control Plane zna o radu klijenta stiže kao agregirana i anonimizovana metrika.
Jedini put preko granice je Support Access: inženjer traži pristup sa razlogom, obimom i rokom, klijentov administrator ga odobrava u svom sistemu, a sesija nosi baner u interfejsu, ističe sama i ostaje zapisana u oba dnevnika — platformskom i klijentovom. Klijent posle dobija izveštaj šta je tokom sesije rađeno. Pre svakog takvog zahteva stoji dijagnostički paket bez ličnih podataka, koji rešava većinu slučajeva bez ulaska u podatke uopšte.
Dve ravni, jedna granica
Control Plane
Klijenti i okruženja, katalog i cenovnici, pretplate, licence, potrošnja, zdravlje, podrška, platformski dnevnik. Odvojena šema, odvojene role, obavezna dvofaktorska prijava. Bez podrazumevanog pristupa poslovnim podacima — bilo kojim API-jem.
Tenant Data Plane
Dokumenti, partneri, glavna knjiga, zalihe, zarade — podaci klijenta. Izolovani politikom Row Level Security po klijentu. Ka Control Plane-u ne vode nikad; iz Control Plane-a se dodiruju isključivo kroz odobrenu, vremenski ograničenu i auditiranu Support Access sesiju.
Klijenti i okruženja
Lista i detalj klijenta, sa okruženjima (produkcija, test, sandbox), verzijom aplikacije i šeme i statusom u životnom ciklusu. Ciklus je mašina sa uslovima, od prospekta i provizioninga, preko probnog perioda i aktivnog rada, do mirovanja i kontrolisanog gašenja — svaki prelaz ostavlja zapis.
Katalog, edicije i verzionisani cenovnici
Proizvod → edicija → paket → cenovnik sa datumom važenja. Cenovnik se ne prepisuje nego dobija novu verziju, pa se svaki ugovor može pročitati po cenama koje su važile kad je potpisan. Izmene se pregledaju kao diff pre nego što stupe na snagu.
Pretplate i ugovori
Pretplata sa stavkama, ugovor sa popustima i posebnim uslovima, obnova sa najavama u više rokova. Prelazak na veći ili manji paket ima datum stupanja na snagu, a smanjenje proverava da li trenutna potrošnja uopšte staje u novi paket pre nego što se potvrdi.
Licence i entitlement
Prava klijenta se računaju iz paketa uz kontrolisane izuzetke, i proveravaju se na API sloju pored provere dozvola — mogućnost nije isto što i modul. Licence se dodeljuju po tipu korisnika (puna, granula, HHT, samo pregled). Istek licence vodi u grace period sa degradacijom, nikad u naglo gašenje. Podržana je i potpisana offline licenca za on-prem rad.
AI krediti
Potrošnja AI-ja se vodi kao knjiga: dodela, potrošnja i prekoračenje, append-only, sa budžetom po klijentu i vidljivim troškom. Klijent u svakom trenutku zna koliko je potrošio i na šta, a ručna dodela iznad praga traži drugog čoveka.
Merenje potrošnje i kvote
Događaji potrošnje — API pozivi, dokumenti, prostor, aktivni korisnici, AI, obaveštenja, automatizacije — stižu asinhrono, kroz outbox, bez uticaja na transakcije klijenta; dimenzije koje bi otkrile poslovni podatak se hešuju. Dnevni agregat hrani kvote: meki limit upozorava, tvrdi limit degradira tačno određenu stvar. Tvrdi limit AI kredita zaustavlja AI pozive — nikad knjiženje.
Zdravlje klijenta
Periodičan snimak: verzija aplikacije i šeme, poslednja migracija i njen ishod, status integracija, zaglavljeni ili pali poslovi, rast baze, stopa grešaka, p95 latencija — i, jednako važno, status backup-a i datum poslednjeg dokazanog restore drilla. Rezultat je ocena po klijentu i pregled cele flote sa alarmima.
Support Access uz odobrenje klijenta
Zahtev nosi razlog, obim i trajanje najviše osam sati. Odobrava ga klijentov administrator u svom sistemu. Sesija radi sa ograničenim opsegom, nosi vidljiv baner, ističe sama i beleži svaku radnju u platformski i u klijentov dnevnik. Klijent dobija kompletan izveštaj sesije.
Platformski dnevnik i maker-checker
Svaka radnja platformskog osoblja ide u append-only dnevnik. Kritične radnje — suspenzija, reaktivacija, gašenje klijenta, izuzetak od prava, izmena cene na aktivnom ugovoru, vanredni pristup, svako brisanje — traže drugog čoveka više uloge: predlog, pregled, izvršenje, zapis.
Control Center je zaseban proizvod sa sopstvenom šemom i sopstvenim rolama u bazi, a ne modul unutar aplikacije klijenta. Granica zato nije podešavanje koje se može isključiti niti uloga koja se može proširiti — ona je posledica toga gde podaci stoje i ko nad njima ima pravo. Ista granica važi i za naš tim.
Šest slojeva autorizacije
Uloga odgovara na pitanje šta korisnik sme da otvori. Ostalih pet slojeva odgovaraju na pitanja koja u poslu zapravo bole: koje podatke, do kog iznosa, u kojoj kombinaciji ovlašćenja, uz čiju potvrdu i po čijem ovlašćenju u tuđem odsustvu.
Uloge i dozvole
Lanac uloga → funkcionalnost → dozvola, sa izričitim kodovima radnji: pregled, kreiranje, potpis, opoziv potpisa, potvrda, storniranje, štampa. Provera je na serveru, od prvog use-case-a; frontend dobija spisak dozvola samo da bi znao šta da prikaže, nikad da bi odlučivao.
Opseg podataka
Ograničenje po pravnom licu, magacinu, sektoru, organizacionoj jedinici ili mestu troška. Ovo je deo autorizacione odluke na serveru, a ne filter u interfejsu — korisnik koji vidi jedan magacin ne vidi drugi ni kroz izveštaj, ni kroz pretragu, ni kroz API.
Limiti odobravanja
Do kog iznosa korisnik odobrava, po tipu dokumenta i procesu. Limit sprovodi workflow kernel: dokument iznad praga ne čeka nečiju dobru volju nego automatski traži odobrenje na višem nivou, sa zapisom ko je i kada odlučio i šta je u tom trenutku video.
Razdvajanje dužnosti (SoD)
Matrica nespojivih ovlašćenja: isti čovek ne otvara dobavljača i ne odobrava mu isplatu, ne unosi i ne potvrđuje popis. Provera radi na dva mesta — pri dodeli uloge, da se sukob ne stvori, i pri samoj radnji, da se ne zaobiđe kombinacijom privremenih prava.
Maker-checker
Kritične radnje traže drugog čoveka. Šta je kritično je konfiguracija, ne pretpostavka: isplate po pravilu, izmene matičnih podataka po izboru klijenta, platformske radnje uvek. Tok je isti — predlog, pregled druge osobe, izvršenje, zapis odluke sa sadržajem koji je pregledan.
Delegacije i zamene
Privremeno ovlašćenje sa rokom i zamena za vreme odsustva, sa istim limitima kao original i sa jasnim tragom ko je u čije ime odlučio. Ovde stoji i posebna dimenzija zabrana: pristup zaradama, maržama i drugim osetljivim podacima se uskraćuje nezavisno od uloge.
Dnevnik: pravilo bez zapisa nije pravilo
Autorizacija se dokazuje zapisom, ne opisom. NG One zato vodi dva odvojena traga koji se ne mogu izmeniti unazad — jedan o tome šta se dogodilo sa podacima, drugi o tome kako je sistem u tom trenutku bio podešen.
- Nepromenljiv (append-only) dnevnik poslovnih radnji: ko, šta, kada, nad čime i iz kog konteksta
- Change log konfiguracije: svaka izmena podešavanja sa starom i novom vrednošću, uključujući konsultantske
- Istorija stanja dokumenta: svaki prelaz sa uslovom koji ga je dozvolio i odobrenjem koje ga je pratilo
- Evidencija svakog izvoza podataka — ko, šta, kada i u kom obimu
- Zapis odluke u odobrenju: šta je odobravalac video u trenutku odluke, a ne šta dokument sadrži danas
Svih šest slojeva sprovodi server, na svakoj komandi, u svih ~60 tehničkih domena — nijedan nije opcion i nijedan se ne oslanja na to da je interfejs sakrio dugme. Zato ih ima šest od prvog use-case-a: sloj koji ne postoji od početka znači da je svaki dotad napisan use-case pisan bez njega, a to se ne ispravlja dodavanjem sloja nego čitanjem svega ispod njega ponovo.
API-first
Interfejs je prvi klijent API-ja, a ne obrnuto. Sve što korisnik može da uradi kroz ekran, može i kroz API — sa istom autorizacijom i istim dnevnikom.
REST i OpenAPI nad svime
Resursi pod jednom verzionisanom osnovom, bez omotača oko odgovora: uspeh je podatak sa pravim HTTP statusom, greška je ProblemDetail po RFC 9457 sa kodom i identifikatorom traga. OpenAPI specifikacija je izvor istine, a ne dokumentacija napisana posle: iz nje se generišu tipizirani klijenti, pa ručno pisanih poziva nema.
Komande umesto generičkog CRUD-a
API izlaže poslovne radnje, ne tabele: potpiši, potvrdi, storniraj, odobri. Pretraga ide kroz eksplicitan ugovor za filtriranje i straničenje, sa obaveznim spiskom dozvoljenih polja po resursu. Idempotency-Key stoji na osetljivim pozivima, pa ponovljen zahtev ne pravi drugi dokument.
Red poslova i asinhroni rad
Dugotrajni poslovi — uvoz, obračun, generisanje izveštaja, slanje ka spoljnim sistemima — idu kroz red sa pokušajima, vidljivim statusom i istorijom. Domenski događaji se objavljuju kroz outbox, pa se poruka ne gubi kad primalac padne, a transakcija koja ju je proizvela ostaje jedna.
Obaveštenja kroz jedan port
E-pošta, SMS, Viber i push idu kroz isti kanal sa šablonima, pravilima isporuke i pretplatom po korisniku. Kanal je konfiguracija: dodavanje novog ne dira modul koji obaveštenje šalje, jer modul objavljuje događaj, a ne poruku.
Ključevi, ograničenja i verzije
Javni API ključevi i servisni nalozi sa bezbednim skladištenjem, ograničenje broja poziva i verzionisanje su deo platforme, a ne dodatak na kraju. Spoljni sistem dobija svoja prava kao i čovek — kroz iste dozvole i isti opseg podataka.
Spremno za MCP
Resursi i radnje su modelovani kao alati: isti ugovor kojim ih poziva interfejs izlaže ih i AI agentu kroz MCP, bez drugog, paralelnog API-ja sa drugim pravilima autorizacije. Agent radi u ime čoveka i nasleđuje njegov identitet u celini — dozvole, opseg podataka, izolaciju klijenta — pa podatak na koji taj čovek nema pravo ne dobija ni preko alata. Svaki poziv ulazi u AI dnevnik kao i svaki drugi.
Enterprise interfejs
ERP se koristi osam sati dnevno, a ne pogleda jednom na demonstraciji. Odluke o interfejsu su donete iz te činjenice.
NgDataTable
Jedna enterprise tabela za ceo sistem, na AG Grid Community, izložena isključivo kroz sopstvenu komponentu — tako izmena ponašanja tabele ide na jednom mestu, a ne u stotinu ekrana. Liste se opisuju registrom: nova lista je unos u registar i tanka stranica, ne novi kod za sortiranje i filtriranje.
Standard svake tabele
Svaka lista u sistemu ima isto: paljenje, gašenje, redosled, širinu i zakivanje kolona; brz i napredni filter sa operatorima; čuvanje filtera i pogleda po korisniku; izvoz u Excel; masovne akcije; sume u podnožju; režim preko celog ekrana. Korisnik nauči jednu tabelu i time zna sve.
Tri ekranske strategije, namerno
Složeni ekrani — glavna knjiga, izvodi, planiranje, masovni unos — su desktop-first: gustina podataka, tastatura, više monitora, minimalna podržana širina 1280 piksela. Pregledi, odobravanja i pokazatelji su responsive. Operativa u magacinu i na terenu dobija namenski HHT interfejs na 390 piksela, sa velikim tasterima, skenerom kao prvim ulazom i QR prijavom.
React 19 SPA
Jedna aplikacija, tipizirani klijenti generisani iz OpenAPI-ja, serverski podaci odvojeni od stanja interfejsa. Forme dele jedan generički obrazac za dokumente sa praćenjem izmena po razlici od poslednjeg snimljenog stanja i porukama po polju na srpskom. Dozvole nikad ne odlučuju na klijentu — samo prikazuju.
Dve teme i dve gustine
Svetla i tamna tema su punopravne od prvog dana, sa svetlom kao podrazumevanom jer se u njoj radi ceo dan; svaki token je definisan za obe, a testovi prolaze u obe. Gustina se bira između comfortable i compact — razlika je stvarna, ne kozmetička, i pamti se po korisniku. Sistem sr i en od početka, latinica podrazumevano.
Welcome & Workspace Setup
Prva prijava vodi kroz personalizaciju sa živim pregledom koji se crta od stvarnih komponenti sistema: jezik, tema i gustina se menjaju odmah i vide se pre potvrde, bez treperenja pri učitavanju. Bira se i podrazumevano pravno lice i početni radni prostor — isključivo iz onoga na šta korisnik ima pravo. Podešavanja se čuvaju na serveru i menjaju kasnije iz profila; panel ne iskače na svaku prijavu.
Zašto modularni monolit, a ne mikroservisi?
Zato što mikroservisi rešavaju probleme koje NG One nema, a stvaraju one koje bi imao. Knjiženje fakture dodiruje partnera, artikal, zalihu, poresku evidenciju i glavnu knjigu u jednoj transakciji — u distribuiranom sistemu ta transakcija postaje saga sa kompenzacijama, i to je posao koji radite umesto poslovne logike. Modularni monolit daje isto što se od mikroservisa zapravo očekuje: tvrde granice modula, komunikaciju preko imenovanih interfejsa i događaja i mogućnost da se modul izdvoji. Razlika je što se ta cena plaća kad se pokaže potreba, a ne unapred i svima. Granice čuvaju arhitektonski testovi, pa ne postoje samo u dokumentu.
Deljena baza za sve klijente — koliko je to zaista izolovano?
Izolacija ne stoji na aplikaciji nego na bazi. Svaka tabela sa podacima klijenta nosi identifikator klijenta i politiku Row Level Security u režimu FORCE, a nalog pod kojim aplikacija radi nema pravo da politiku zaobiđe — nije reč o filteru koji programer sme da zaboravi u upitu, nego o pravilu koje baza sprovodi za svaki red. Kontekst klijenta se postavlja na početku svake transakcije. Uz to postoje dva testa koja obaraju build: jedan proverava da nijedna tabela sa identifikatorom klijenta nije ostala bez politike, drugi pokušava da iz konteksta jednog klijenta pročita i izmeni podatke drugog i traži da ne uspe. Oba danas rade.
Kakva je razlika između klijenta (tenanta) i pravnog lica?
Klijent je granica izolacije podataka — ono što je u starim sistemima bila cela zasebna instalacija ili baza. Pravno lice je dimenzija unutar klijenta: jedna firma sa tri d.o.o.-a je jedan klijent sa tri pravna lica, deli šifarnike i korisnike, a ima odvojenu numeraciju dokumenata, odvojene bankovne račune i odvojene izveštaje. Razlika je važna zbog cene: sistemi koji nemaju pravna lica kao dimenziju rešavaju ovo trećom instalacijom, pa se svaka nadogradnja plaća tri puta, a konsolidovan pogled se sklapa u tabeli van sistema.
Šta znači da platformsko osoblje ne vidi poslovne podatke?
Znači tačno to, i to na nivou prava u bazi, ne na nivou obećanja. Control Plane i podaci klijenta su odvojene šeme sa odvojenim rolama; platformske role nemaju pristup poslovnim tabelama, pa upit koji bi ih pročitao ne uspeva ni kad bi ga neko napisao. Sve što platforma vidi o radu klijenta je agregirana i anonimizovana metrika — koliko dokumenata, koliko poziva, kolika baza — bez sadržaja. Kad je pristup zaista potreban, ide kroz Support Access: klijent ga odobrava, sesija ima obim i rok, radnje se beleže u dva dnevnika, a klijent dobija izveštaj. Granicu ne čuva obećanje nego test: pokušava da kao platformski administrator otvori poslovni podatak i traži da ne uspe. Dok on ne prođe, verzija ne izlazi.
Kako da promenim ponašanje sistema bez programera?
Kroz konzolu. Tipovi dokumenata, numeracije, statusne mašine sa uslovima i efektima, obavezna polja, štampani šabloni, pravila odobravanja, automatska pravila i podešavanja su konfiguracija sa metapodacima — konzola sama iscrtava kontrolu za svako podešavanje, pa novo podešavanje ne traži novi ekran. Granica je jasna i namerna: konfigurišete kombinaciju, ne izmišljate novu vrstu ponašanja. Uslovi i efekti koje statusna mašina poziva su imenovane funkcije registrovane u kodu — birate ih i vezujete, ali ih ne pišete u podešavanju. Svaka izmena ide u dnevnik sa starom i novom vrednošću.
Šta se dešava sa proknjiženim dokumentima kad se promeni pravilo?
Ništa — i to je poenta. Pravila su vremenski važeća i verzionisana, a svako knjiženje čuva referencu na verziju po kojoj je nastalo, uz snimljene ključne vrednosti. Nova posting šema važi od datuma koji joj odredite; dokument iz prošlog perioda i dalje pokazuje šemu, stopu i kurs koji su važili tada. Funkcija „objasni knjiženje” to i prikazuje: koji dokument, koja šema u kojoj verziji, koja stopa, koji kurs, ko je i kada menjao konfiguraciju. Bez ovoga bi izmena podešavanja tiho prepisala prošlost, što je greška koja se otkrije tek u kontroli.
Mogu li da izvučem svoje podatke iz NG One-a?
Da, i to na tri nivoa. Svaka lista u sistemu ima izvoz u Excel. API je otvoren nad svim resursima, sa OpenAPI specifikacijom, pa se podaci mogu čitati programski uz iste dozvole koje važe za čoveka. I postoji kompletan izvoz podataka klijenta, koji je deo procedure gašenja: klijent koji odlazi dobija svoje podatke pre nego što se bilo šta obriše, a izvoz radi i dok je nalog suspendovan zbog neplaćanja. Svaki izvoz se beleži — ko, šta, kada i u kom obimu.
Kako da proverim da je ovo tačno, a ne dokument?
Tako što tražite da vam pokažemo mesto na kome sistem pada ako nije tačno. Izolacija: meta-test nad šemom obara build ako tabela sa identifikatorom klijenta ostane bez RLS politike, a drugi test iz konteksta jednog klijenta pokušava da pročita i izmeni tuđe podatke i traži da ne uspe. Granice modula: arhitektonski testovi obaraju build na svaki poziv koji nije prošao kroz imenovani interfejs ili događaj. Verzionisanje: „objasni knjiženje” nad dokumentom iz zatvorenog perioda i posle izmene konfiguracije pokazuje staru šemu, staru stopu i stari kurs. Dimenzije: otvorite bilo koju stavku glavne knjige i pogledajte nosi li ih. Na tehničkom pregledu prolazimo kroz sve četiri, sa kodom i sa podacima — arhitektura koja se ne može pokazati na ekranu je slajd.
Proverite arhitekturu pre nego što proverite ekrane
Zakažite tehnički pregled platforme sa našim timom. Prolazimo kroz model podataka, izolaciju, autorizaciju i granicu prema podacima — i odgovaramo na pitanja koja vaš IT postavlja, ne na ona koja je lakše postaviti.