ERP ostaje glavni sistem: artikli, kupci, kalkulacije i nivelacije kroz Tezga API
10 min čitanja
Firma sa ERP-om ne želi drugi sistem u kome se vode artikli i cene. Tekst pokazuje podelu uloga: ERP je izvor artikala, kupaca i cena, a Tezga izdaje i fiskalizuje račune, vodi KEP i vraća ishod. Uz tačne pozive, pravila uparivanja i ono što Tezga namerno ne radi.
Kad firma ima ERP, on ostaje glavni sistem. Tezga u toj arhitekturi radi tri stvari: prima artikle i kupce iz ERP-a (do 500 po pozivu), izdaje i fiskalizuje račune po porudžbini, i vodi KEP kroz kalkulaciju i nivelaciju. Ishod se vraća ERP-u webhook-om. Šta Tezga ne radi je materijalno knjigovodstvo, glavna knjiga i slojevita zaliha: to ostaje ERP-u.
- Artikal se upisuje po šifri (bez šifre po nazivu), kupac po PIB-u, pa mejlu, pa nazivu; ništa se ne briše, a polje koje ne pošalješ ostaje kakvo jeste.
- Jedna loša stavka ne ruši ostale, a ponovljen zahtev je bezbedan.
- Stanje zaliha se ne upisuje direktno: menja se kroz kalkulaciju (prijem) i prodaju, da knjiga promena ostane tačna.
- Kalkulacija i nivelacija su deo paketa Biznis; svaka u jednoj transakciji upisuje cene, zalihe i KEP red.
- Gotov konektor za SAP ne postoji: SAP, Dynamics, NetSuite i Odoo se vezuju kroz isti javni API.
Ko je glavni za koji podatak?
Najčešća greška u ovim projektima nije tehnička nego organizaciona: podatak se vodi na dva mesta, pa se razilazi. Zato se pre prvog poziva zapiše ko je izvor istine. Preporučena podela za firmu koja ima ERP:
| Podatak | Izvor istine | Smer | Poziv |
|---|---|---|---|
| Artikli, šifre, poreske stope, jedinice mere, GTIN | ERP | ERP, pa Tezga | POST /products |
| Kupci, PIB, matični broj, JBKJS, adresa | ERP | ERP, pa Tezga | POST /customers |
| Fiskalni račun, PFR broj, QR, javni PDF | Tezga | Tezga, pa ERP | Odgovor na /order i webhook |
| Prijem robe, nabavna cena, prodajna cena | ERP | ERP, pa Tezga | POST /kalkulacija |
| Promena prodajne cene | ERP | ERP, pa Tezga | POST /nivelacija |
| Uplate sa izvoda | Banka, preko Tezge | Tezga, pa ERP | GET /transactions |
ERP šalje podatke ka Tezgi, a ishod fiskalizacije se vraća ERP-u događajem koji nosi njegov externalId.
Kako se upisuju artikli i kupci?
Poziv POST /products prima od 1 do 500 artikala, a POST /customers isto toliko kupaca. Pravilo traženja je isto kao pri sinhronizaciji iz shopa: artikal se traži po šifri, a artikal bez šifre po nazivu. Nađen artikal se menja, nov se pravi, ništa se ne briše, a polje koje ne pošalješ ostaje kakvo jeste. Kupac se traži po PIB-u, pa po mejlu, pa po nazivu; ulaz sa PIB-om se po mejlu i nazivu prepoznaje samo u kupcu koji PIB nema. Prazno polje ne gazi već uneto.
Odgovor ima ishod po stavci, pa jedna loša ne ruši ostale, a ponovljen isti zahtev je bezbedan (status bez_izmene). Polja zaliha (stanje, zaliha, zalihe, kolicina, pratiZalihu, minStanje) vraćaju grešku stavke: zaliha se menja samo kroz knjigu promena.
Kako se prijem robe i promena cene knjiže?
Dva poziva zamenjuju ručno knjiženje u kasi. POST /kalkulacija je prijem robe: artikli se uparuju po šifri iz kataloga, cena se računa (nabavna cena i marža, ili zadata prodajna), a motor u jednoj transakciji upiše prodajne cene, zaduži zalihe i upiše red u KEP. POST /nivelacija je promena prodajne cene: zahtev nosi samo novu cenu, a staru cenu i zatečenu količinu motor čita iz kataloga u trenutku knjiženja. Poskupljenje je zaduženje, sniženje razduženje.
Oba su idempotentna po externalId, a ako se isti zahtev još obrađuje, odgovor je 409. Šifra koje nema u katalogu vraća 422, pa ERP prvo šalje artikle, pa tek onda kalkulacije. Proknjižen dokument se ne menja i ne briše; ispravka je novi dokument sa suprotnim znakom. Pojmovi su u rečniku: kalkulacija, nivelacija i nabavna cena.
Čija cena važi na računu: ERP-a ili porudžbine?
Poziv /order ima polje cenaIzZahteva upravo za ovo. Kad je true, za stavku čija šifra postoji u katalogu važe cena i popust iz zahteva, a iz kataloga ostaju veza sa artiklom, naziv, jedinica mere i poreska stopa. Kad je izostavljeno ili false (provajder custom), važe cena, stopa i popust iz kataloga, a popust u zahtevu uz takvu stavku vraća 422. Za gotove provajdere (WooCommerce, Shopify, PrestaShop, OpenCart, Magento, BigCommerce) uvek važi cena iz shopa.
Za ERP koji je izvor cena razumna je kombinacija: katalog se osvežava iz ERP-a, a porudžbina nosi cenaIzZahteva: true kad je cena na porudžbini rezultat popusta ili akcije koju ERP već izračunao.
Šta Tezga namerno ne radi?
- Nema materijalnog knjigovodstva ni glavne knjige. KUF, KIF, konta i obračun ostaju u knjigovodstvenom programu.
- Nema slojevite zalihe. Nema FIFO ni prosečne nabavne cene; nabavna cena se pamti po artiklu kao poslednja iz kalkulacije.
- Nema normativa proizvodnje. Tezga radi trgovinu i uslugu.
- Zalihu prate samo artikli koje korisnik označi. Ako ERP vodi zalihu, Tezga ne mora.
- Nema gotovog konektora za SAP. Veza ide preko SAP Integration Suite ili direktnog HTTP poziva, a izdat račun se vraća webhook-om na knjiženje.
Izvori: OpenAPI opis Tezga eKase, verzija 1.6.0 (pos.narbiz.com/api/openapi.json), ИБ 1597; Pravilnik o evidenciji prometa u maloprodaji (član 14, neizmenljivost proknjiženog dokumenta); uslovi Enterprise nivoa (tezgafiskal.com/enterprise); Zakon o fiskalizaciji (Sl. glasnik RS 153/2020, 96/2021, 138/2022).
Česta pitanja
Mogu li iz ERP-a da upišem stanje zaliha preko API-ja?
Ne. Polja stanja i zaliha vraćaju grešku stavke, jer se stanje menja samo kroz knjigu promena: prodajom, kalkulacijom, popisom, otpisom i povraćajem. Tako svaka promena ima trag i stanje posle sebe.
Šta se desi ako šaljem isti artikal dva puta?
Ništa loše: ponovljen zahtev je bezbedan i vraća status bez_izmene. Artikal se traži po šifri, pa se isti ne pravi drugi put, a polje koje ne pošalješ ostaje kakvo jeste.
Kako da kalkulacija ne padne zbog nepoznate šifre?
Prvo pošalji artikle, pa tek onda kalkulaciju. Šifra koje nema u katalogu vraća 422 i ništa ne knjiži. Isti redosled važi za nivelaciju.
Šta znači 409 na kalkulaciji ili nivelaciji?
Zahtev sa istim externalId se već obrađuje. Sačekaj i pročitaj ishod ponovnim pozivom: isti zahtev vraća status postojalo kad je knjiženje završeno, bez duplog knjiženja.
Mogu li kalkulacija i nivelacija bez paketa Biznis?
Ne. Kalkulacija i nivelacija su funkcija „roba” paketa Biznis. U nižim paketima su zalihe isključivo količinske, a API u celini je deo paketa Biznis i Enterprise nivoa.
Da li Tezga računa FIFO ili prosečnu nabavnu cenu?
Ne. Nabavna cena se pamti po artiklu kao poslednja iz kalkulacije, bez slojevite zalihe. Ako obračun rezultata zavisi od FIFO ili prosečne cene, ta evidencija ostaje u ERP-u ili posebnom skladišnom sistemu.
Postoji li gotov konektor za SAP, Dynamics ili Odoo?
Za SAP, Dynamics 365, NetSuite i Odoo ne postoji gotov konektor: veza se pravi kroz isti javni REST API, u okviru jednokratne integracije na Enterprise nivou. Artikli i kupci ulaze kroz /products i /customers, a izdat račun se vraća webhook-om.
Da vidiš kako tvoj ERP šifarnik izgleda u Tezgi, uvezi nekoliko artikala u simulaciji i izdaj jedan račun po šifri. Probni pristup traje 48 sati i otvara se na strani probaj fiskalnu kasu, a ceo API je na strani API za fiskalizaciju.