ERP integracija za web shop nije samo povezivanje dva sistema jednim API pozivom. Potrebno je unapred odrediti koji sistem je izvor istine za artikle, cene, zalihe, kupce i statuse porudžbina, kao i šta se dešava kada jedan sistem privremeno nije dostupan.
U najčešćem scenariju ERP šalje katalog, cenovnike i raspoložive količine ka web shopu, dok web shop prosleđuje nove porudžbine, podatke o kupcu i promene statusa nazad u ERP. Međutim, konkretan tok zavisi od poslovnih pravila: broja magacina, B2B ili B2C prodaje, načina obračuna PDV-a, rezervacije robe, kurirskih integracija i toga da li se prodaje i kroz fizičke prodavnice.
Zato integraciju treba projektovati kao deo arhitekture web prodavnice, a ne kao dodatak koji se uključuje tek nakon izrade interfejsa. Ako se tek tada otkriju razlike u šifarnicima ili cenovnicima, problem nije samo tehnički: može nastati pogrešna cena, prodaja nedostupne robe ili ručni rad koji poništava korist automatizacije.
Šta ERP integracija treba da reši
Cilj integracije je da se isti poslovni podatak ne unosi ručno na više mesta. Web shop treba da bude pouzdano prodajno mesto i korisnički interfejs, dok ERP najčešće upravlja poslovnom evidencijom, dokumentima, nabavkom, magacinima i finansijskim procesima. To nije univerzalno pravilo, ali je dobar početni model za definisanje odgovornosti.
Pre razvoja treba napraviti mapu podataka i za svaku oblast odgovoriti na četiri pitanja:
- Gde podatak nastaje?
- Koji sistem ga može menjati?
- Koliko brzo promena mora da bude vidljiva?
- Kako se evidentira greška ili neuspešna sinhronizacija?
U praksi se najčešće integrišu:
- artikli, varijante, kategorije i atributi;
- prodajne i nabavne cene;
- stanje po magacinu i raspoloživa količina;
- porudžbine i stavke porudžbine;
- podaci o kupcu i adresama;
- statusi obrade, isporuke, otkaza i povraćaja;
- porezi, popusti, načini plaćanja i dostave.
Ne mora svaki od ovih objekata biti sinhronizovan u oba smera. Na primer, web shop može primati podatke o cenama iz ERP-a, ali obračunati privremeni promotivni kod u svom checkout procesu. Važno je da se takav izuzetak eksplicitno definiše, umesto da nastane slučajno.
Porudžbine: od checkouta do ERP dokumenta
Porudžbina je centralna tačka integracije jer spaja kupca, artikle, cenu, porez, dostavu i naplatu. Kada kupac završi checkout, web shop najpre treba da sačuva sopstvenu porudžbinu i dodeli joj jedinstveni identifikator. Tek zatim je prosleđuje ERP-u ili integracionom sloju.
Ovakav redosled je važan. Ako se porudžbina kreira direktno u ERP-u bez lokalne evidencije, privremeni prekid veze može ostaviti nejasno da li je zahtev prihvaćen, odbijen ili samo nije dobio odgovor. Web shop tada mora imati mehanizam za ponovni pokušaj bez dupliranja dokumenta.
Podaci koji se obično šalju
- interni ID web shop porudžbine;
- datum i vreme kreiranja;
- podaci kupca i kontakt informacije;
- adresa za dostavu i eventualno adresa za račun;
- šifre artikala ili SKU vrednosti;
- količine, cene po stavci, popusti i porez;
- trošak dostave i izabrani način isporuke;
- način plaćanja i status naplate;
- napomena kupca i izvor prodaje.
ERP često ne koristi isti model porudžbine kao web shop. Jedan sistem može imati korpu, porudžbinu i potvrđenu prodaju kao odvojene faze, dok drugi odmah kreira prodajni dokument. Zbog toga se ne mapiraju samo nazivi polja, već i poslovno značenje statusa.
Statusi ne treba da budu samo tekstualne oznake
Status „obrađuje se“ u web shopu ne mora značiti isto što i „potvrđeno“ u ERP-u. Potrebna je tabela mapiranja, na primer:
| Web shop status | ERP događaj | Dozvoljena akcija |
|---|---|---|
| Nova porudžbina | Primljen zahtev za dokument | Provera artikala i plaćanja |
| Potvrđena | Kreiran ili odobren prodajni dokument | Rezervacija i priprema |
| Poslata | Izdata pošiljka ili otprema | Slanje broja za praćenje |
| Otkazana | Storno ili odbijanje | Oslobađanje rezervacije prema pravilima |
| Vraćena | Pokrenut proces povraćaja | Dalja obrada prema politici povrata |
Ova tabela nije tehnička dokumentacija sama po sebi, ali je odličan test da li su poslovni procesi zaista usaglašeni. Ako ne postoji jasan odgovor na to koji događaj menja koji status, integracija će teško biti pouzdana.
Zalihe: raspoloživo nije isto što i fizičko stanje
Najčešća greška kod zaliha je prikazivanje jedne brojke bez definicije šta ona predstavlja. ERP može voditi fizičko stanje, rezervisanu količinu, robu u prijemu, robu u tranzitu i količinu raspoloživu za prodaju. Web shop ne treba automatski da prikazuje sve te vrednosti kao jednu „zalihu“.
Pre integracije treba definisati formulu za prodajnu raspoloživost. Ona može zavisiti od fizičkog stanja, rezervacija, minimalne sigurnosne zalihe i izabranog magacina. Formula nije ista za svaki biznis: prodavac sa jednim magacinom ima drugačiji problem od trgovca sa više lokacija i preusmeravanjem porudžbina.
Posebno treba razjasniti:
- da li se zaliha prikazuje po artiklu, varijanti ili lokaciji;
- kada se količina rezerviše — pri kreiranju porudžbine, potvrdi plaćanja ili kasnije;
- da li se neuspešno plaćene porudžbine računaju u raspoloživost;
- kako se obrađuje otkazivanje i povraćaj;
- šta se dešava kada dva kanala prodaju poslednji komad;
- da li se kupcu prikazuje tačan broj ili samo stanje poput „dostupno“ i „uskoro nedostupno“.
Za detaljniju odluku o učestalosti i načinu prenosa količina korisno je odvojeno razmotriti sinhronizaciju zaliha u web shopu: real-time ili batch pristup. Real-time pristup može smanjiti vremenski jaz, ali donosi veću zavisnost od dostupnosti sistema i veću složenost. Periodična, odnosno batch sinhronizacija, jednostavnija je za određene modele, ali ostavlja prozor u kome prikazana količina može biti zastarela.
Cene, cenovnici i pravila popusta
Cena u web shopu često nije samo jedno polje na artiklu. Može zavisiti od tržišta, valute, kupca, količine, kampanje, članstva, kanala prodaje ili načina plaćanja. ERP i web shop zato moraju imati dogovor o tome koja cena se šalje, u kom formatu i sa kojim datumom važenja.
Najpre treba odvojiti osnovnu cenu od konačne cene koju kupac vidi na checkoutu. Ako se popusti obračunavaju u web shopu, ERP mora dobiti dovoljno podataka da se dokument može proveriti i proknjižiti. Ako se cena formira u ERP-u, web shop mora znati koji cenovnik važi za konkretnog kupca ili grupu kupaca.
Primer matrice za cenovnu logiku
| Element | Mogući izvor | Pitanje za specifikaciju |
|---|---|---|
| Osnovna cena | ERP ili web shop | Ko menja redovnu cenu? |
| B2B cenovnik | ERP | Kako se kupac povezuje sa cenovnikom? |
| Kampanjski popust | Web shop ili ERP | Gde se definiše period važenja? |
| Količinski rabat | ERP ili pravila web shopa | Da li se šalje kao cena ili kao popust? |
| Porez | ERP ili kombinovana logika | Da li cena uključuje porez i za koje kupce? |
Važno je i zaokruživanje. Razlika od nekoliko decimalnih mesta između web shopa i ERP-a može napraviti neusaglašen iznos porudžbine, naročito kada postoji više stavki, popust i dostava. Pravila za valutu, decimalna mesta, PDV i redosled obračuna treba zapisati u specifikaciji i proveriti kroz testne primere.
Jedan izvor istine ili kontrolisana podela odgovornosti?
Izraz „jedan izvor istine“ koristan je samo ako se precizno odnosi na određeni podatak. Nije nužno da jedan sistem bude vlasnik svega. ERP može biti vlasnik šifre i nabavne cene, web shop vlasnik SEO opisa i merchandising sadržaja, a servis za plaćanje vlasnik statusa transakcije.
Dobro definisana matrica odgovornosti može izgledati ovako:
- ERP: šifre artikala, magacini, poslovni cenovnici, dokumenti prodaje i finansijski podaci;
- web shop: prezentacija proizvoda, kategorije za navigaciju, sadržaj, kampanjski baneri i korisnički prikaz statusa;
- payment servis: autorizacija, uspeh ili neuspeh transakcije i identifikator plaćanja;
- kurirski sistem: podaci o pošiljci, nalepnica i praćenje isporuke;
- CRM: segmenti, komunikacioni događaji i širi profil odnosa sa kupcem.
Ako se poslovni podaci o kupcima koriste i za segmentaciju ili automatizovane kampanje, treba planirati i CRM tok, a ne ga naknadno dodavati na porudžbine. Povezivanje je objašnjeno u vodiču CRM integracija za e-commerce: kupci, segmenti i lifecycle podaci.
Kako izgleda tehnička arhitektura integracije
Postoje tri uobičajena modela:
- Direktna integracija: web shop komunicira direktno sa ERP API-jem. Ovo može biti jednostavno za ograničen broj tokova, ali web shop preuzima više odgovornosti za autentikaciju, mapiranje i obradu grešaka.
- Integracioni servis ili middleware: poseban sloj prima, transformiše i prosleđuje podatke. Pogodan je kada postoji više kanala, različiti formati ili potreba za centralnim logovanjem.
- Razmena fajlova: sistemi razmenjuju CSV, XML ili drugi dogovoreni format u terminima. Može biti praktična za početak ili starije ERP sisteme, ali zahteva kontrolu verzija fajlova, duplikata i kašnjenja.
Pri izboru nije dovoljno pitati da li ERP „ima API“. Treba proveriti da li API podržava baš potrebne operacije: čitanje artikala, slanje porudžbine, proveru stanja, cenovnike, statuse i eventualno povraćaje. Takođe treba proveriti autentikaciju, ograničenja broja zahteva, format grešaka, verzionisanje i način prijave promena.
Na primer, platforme kao što su Shopify i WooCommerce imaju dokumentovane API mehanizme, ali se detalji objekata, dozvola i procesa razlikuju. Shopify Admin API dokumentacija i WooCommerce REST API dokumentacija treba da budu početna tačka za proveru konkretnih mogućnosti, a ne zamena za poslovnu specifikaciju.
Greške, ponovni pokušaji i kontrola duplikata
Integracija nije završena kada podaci prolaze u idealnom slučaju. Pouzdanost se vidi kada ERP ne odgovara, kada artikl više ne postoji, kada je cena promenjena između dodavanja u korpu i checkouta ili kada je porudžbina primljena, ali odgovor nije stigao do web shopa.
Za svaki tok treba definisati:
- kako se greška beleži;
- da li se zahtev automatski ponavlja;
- koliko dugo i koliko puta se ponavlja;
- kada se uključuje ručna intervencija;
- ko dobija obaveštenje;
- kako se proverava da li je dokument ipak kreiran.
Posebno je važna idempotentnost: isti zahtev za kreiranje porudžbine ne sme napraviti dva ERP dokumenta ako se pošalje više puta. To se obično rešava jedinstvenim ID-jem web shop porudžbine, evidencijom statusa slanja i proverom postojećeg dokumenta pre ponovnog kreiranja.
Potrebni su i operativni izveštaji: porudžbine koje čekaju slanje, artikli sa neusaglašenom zalihom, odbijeni cenovnici, neuspešne izmene statusa i zapisi bez odgovarajuće šifre. Bez ovih kontrola problem može ostati neprimećen dok ga ne prijavi kupac.
Testiranje pre puštanja u rad
Testiranje treba da obuhvati više od jedne uspešne kupovine. Napravite testni scenarij za svaku kritičnu poslovnu putanju:
- standardna porudžbina sa jednom stavkom;
- porudžbina sa više varijanti i različitim stopama poreza, ako postoje;
- kupovina artikla čija se zaliha promeni između korpe i checkouta;
- neuspešno plaćanje i ponovni pokušaj;
- duplirano slanje istog događaja;
- otkazivanje pre otpreme;
- povraćaj dela porudžbine;
- promena cene i cenovnika;
- nedostupan ERP ili prekid mreže;
- porudžbina iz drugog prodajnog kanala koja utiče na stanje.
Za svaki scenario treba porediti podatke u oba sistema, a ne samo proveriti da li je porudžbina „prošla“. Kontrolišu se stavke, količine, popusti, porez, dostava, ukupna suma, status i identifikatori. Tek tada se vidi da li su mapiranje i pravila obračuna zaista usklađeni.
ERP integracija u kontekstu celog web shop projekta
Integracija utiče na izbor platforme, model administracije, checkout, prikaz zaliha, korisničke naloge i način upravljanja sadržajem. Zato je treba obraditi pre konačne odluke između gotove platforme i prilagođenog rešenja. Vodič Custom web shop ili Shopify/WooCommerce: kako izabrati platformu može pomoći da se ta odluka posmatra kroz procese i ograničenja, a ne samo kroz listu funkcija.
Ako je web shop deo šireg digitalnog sistema, mogu biti relevantni i korporativni sajt, katalog, korisnički portal ili posebni landing sadržaji. U tom slučaju vredi sagledati i izradu sajta kao odvojenu arhitektonsku celinu, ali bez mešanja njegovih uloga sa transakcionim delom web prodavnice.
Za sam web shop, specifikacija integracije treba da bude deo projekta izrade web shopa. To ne znači da svaki projekat zahteva kompleksan middleware ili trenutnu sinhronizaciju. Znači da se odluka donosi na osnovu stvarnih tokova: koliko kanala postoji, koliko često se menjaju zalihe i cene, koji ERP se koristi i koliko je tolerancija na ručni rad.
Praktičan redosled za pripremu projekta
Pre tehničke procene pripremite sledeće:
- spisak sistema i njihovih uloga;
- šifarnik artikala sa primerima varijanti;
- opis magacina i pravila raspoloživosti;
- cenovnike, poreze i popuste;
- statusni model porudžbine i povraćaja;
- primer stvarne ili anonimizovane porudžbine;
- dokumentaciju ERP-a, platforme i servisa za plaćanje;
- zahteve za logovanje, nadzor i ručnu korekciju;
- listu scenarija koji moraju biti testirani.
Na osnovu toga može se napraviti mapa integracije sa ulazima, izlazima, učestalošću, vlasnikom podatka i ponašanjem u slučaju greške. Takav dokument je korisniji od opšte tvrdnje da su „ERP i web shop povezani“, jer jasno pokazuje šta je obuhvaćeno, a šta nije.
Sledeći korak nije izbor najkomplikovanijeg rešenja, već potvrda najkritičnijih tokova: porudžbina, raspoloživa zaliha, cena i status isporuke. Kada su ta pravila jasna, lakše je proceniti platformu, obim razvoja i način održavanja bez iznenađenja nakon puštanja web shopa u rad.
