API za fiskalizaciju 1.0. i 2.0.

Adeo POS API — pitanja i odgovori

Odaberite temu ili potražite odgovor za svoju integraciju: od prvog API poziva do poslovnog modela i podrške.

20 pitanja za početak

Što je Adeo POS i kome je namijenjen?
Možemo li zadržati postojeću aplikaciju i koristiti samo API?
Koji Adeo POS API trebamo za naš projekt?
Znači li HTTP 200 da je račun uspješno fiskaliziran?
Kako dobivamo rezultat i što ako callback ne stigne?
Što je ExternalID i kada ga trebamo dodijeliti?
Kako izbjeći dvostruko izdavanje pri ponovljenom zahtjevu ili timeoutu?
Što ako je porezni ili fiskalni servis privremeno nedostupan?
Može li cloud API raditi bez interneta?
Može li jedna SaaS integracija raditi za više poslovnih subjekata?
Možemo li povezati postojeći webshop s Adeo POS-om?
Možemo li zadržati payment gateway i postojeću raspodjelu uplata?
Možemo li dobiti PDF s QR kodom ili sami oblikovati račun?
Šalje li Adeo POS automatski račun kupcu e-mailom?
Možemo li slati eRačune iz vlastitog ERP-a?
Može li samoposlužni ili vending sustav koristiti cloud API?
Možemo li Adeo POS koristiti na više tržišta?
Tko provodi onboarding novih korisnika?
Kako se određuje cijena API integracije?
Kakvu podršku dobivamo tijekom integracije?

Osnove i tržišta

Što je Adeo POS i kome je namijenjen?

Adeo POS povezuje izdavanje računa, fiskalizaciju, eRačune i poslovne aplikacije. Može se koristiti kao POS rješenje ili putem API-ja u webshopu, ERP-u, SaaS platformi, mobilnoj aplikaciji ili samoposlužnom sustavu. Funkcionalnosti ovise o odabranom proizvodu i tržištu.

Možemo li zadržati postojeću aplikaciju i koristiti samo API?

Da. Vaša aplikacija, webshop ili ERP može ostati glavno korisničko sučelje, a Adeo POS obrađivati fiskalizaciju i druge dogovorene procese putem API-ja. Opseg integracije određuje koje podatke i statuse vaša aplikacija treba slati, primati i prikazivati.

Možemo li integrirati račune za potrošače, tvrtke i javna tijela?

Projekt može obuhvatiti različite vrste kupaca i dokumenata. Pri odabiru API-ja potrebno je razlikovati fiskalizaciju računa od slanja i zaprimanja eRačuna te potvrditi podržani postupak za svako tržište i vrstu dokumenta.

Što znači fiskalizacija u API integraciji?

Fiskalizacija je elektronička dostava podataka o računu nadležnom fiskalnom sustavu. API integracija povezuje vašu aplikaciju s tom obradom i omogućuje praćenje rezultata. Podaci, identifikatori i tijek rada razlikuju se među državama.

Što Adeo POS obrađuje i koje rezultate vraća?

Adeo POS zaprima podatke računa, obrađuje ih i komunicira s odgovarajućim fiskalnim sustavom. Integracija zatim preuzima status, rezultat ili podatke o grešci. Hrvatski identifikatori JIR i ZKI koriste se u odgovarajućim hrvatskim scenarijima; nisu univerzalni nazivi za sva tržišta.

Koji Adeo POS API trebamo za naš projekt?

FiskalQ služi izdavanju i fiskalizaciji računa te podržanim postupcima izdavanja eRačuna. ADEO poslovni API namijenjen je poslovnim podacima i operacijama, a zaseban eRačuni API drugim procesima obrade eRačuna. Potrebna sučelja biraju se prema cijelom tijeku rada, a ne samo prema tome treba li izdati račun.

Možemo li Adeo POS koristiti na više tržišta?

Adeo POS se koristi na više tržišta, uključujući Hrvatsku, Crnu Goru, Srbiju, Sloveniju i Češku. Postojeća integracija može biti polazište za širenje, ali dostupnost pojedinog proizvoda, obvezna polja i lokalni postupci provjeravaju se za svaku državu. Ne treba pretpostaviti da je isti zahtjev bez prilagodbe primjenjiv na svim tržištima.

Što dobivamo u odnosu na izravnu integraciju s fiskalnim sustavom?

Adeo POS preuzima dogovoreni sloj komunikacije i obrade prema fiskalnom sustavu, umjesto da ga razvijate zasebno za svaku integraciju. Vaš tim i dalje oblikuje poslovni proces, šalje ispravne podatke i obrađuje statuse. Podjelu odgovornosti i opseg održavanja definiramo pri ugovaranju.

API integracija i statusi

Koji format i način komunikacije koristi API?

Format zahtjeva, autentikacija i dostupne operacije definirani su dokumentacijom odabranog API-ja i njegove verzije. Prije razvoja zatražite odgovarajuću specifikaciju i primjere. Nemojte pretpostaviti da različite Adeo POS API cjeline imaju ista polja i način pristupa.

Je li cloud fiskalizacijski API sinkron ili asinkron?

Cloud FiskalQ koristi asinkronu obradu: aplikacija predaje zahtjev, a konačni rezultat preuzima naknadno. Time komunikacija s vanjskim fiskalnim sustavom ne mora blokirati cijeli proces aplikacije. Način rada drugih API-ja ili lokalnih komponenti treba provjeriti zasebno.

Znači li HTTP 200 da je račun uspješno fiskaliziran?

Ne. U cloud modelu predaje računa u red čekanja početni HTTP 200 potvrđuje da je zahtjev zaprimljen u obradu. Poslovna validacija i fiskalni rezultat dolaze naknadno, pa treba provjeriti status ili obraditi callback. Uspješan HTTP odgovor nije potvrda ispravnosti svih podataka ni dovršene fiskalizacije.

Kako dobivamo rezultat i što ako callback ne stigne?

Rezultat možete primiti callbackom ili naknadno dohvatiti statusnim API-jem, prema odabranoj integraciji. Ako callback izostane, provjerite postojeću transakciju umjesto da odmah izdajete novi račun. Učestalost provjere, nazive statusa i pravila callbacka uskladite s dokumentacijom konkretne verzije.

Što je ExternalID i kada ga trebamo dodijeliti?

ExternalID je identifikator računa iz vašeg sustava. Dodijelite ga prije prvog slanja i trajno povežite s poslovnim dokumentom kako biste mogli pratiti rezultat i ponavljati isti zahtjev. Koristite stabilan identifikator koji se ne ponavlja u dogovorenom opsegu integracije; točan opseg jedinstvenosti i dopušteni format provjerite u specifikaciji.

Kako izbjeći dvostruko izdavanje pri ponovljenom zahtjevu ili timeoutu?

Za isti poslovni događaj sačuvajte isti ExternalID i prvo provjerite postojeću transakciju. Ako je ponovno slanje potrebno, nemojte stvarati novi identifikator samo zato što odgovor nije stigao. Zaštita od duplikata oslanja se na pravilnu uporabu identifikatora; ispravak sadržaja već prihvaćenog računa zaseban je postupak prema specifikaciji.

Kako obraditi isti callback više puta?

Obradu callbacka projektirajte tako da ponovna obavijest za istu transakciju samo uskladi njezin status. Ne bi trebala ponovno pokrenuti naplatu, izdavanje računa ili isporuku. To je pravilo za vašu aplikaciju, ne pretpostavka o zajamčenom broju dostava callbacka.

Kako planirati integraciju s velikim brojem računa?

Pri planiranju navedite očekivani mjesečni volumen, vršna opterećenja, broj korisnika i uređaja te potrebna vremena obrade. Na temelju toga dogovaraju se tehnički i komercijalni uvjeti. Konkretne limite, učestalost API poziva i test opterećenja treba potvrditi za vaš projekt.

Kako dobivamo dokumentaciju i testni pristup?

Nakon opisa poslovnog scenarija zatražite dokumentaciju i testni pristup za potrebnu API cjelinu. Integraciju razvijajte i provjerite u testnom okruženju prije uključivanja produkcijskih postavki. Specifikacija poslovnog API-ja ne zamjenjuje dokumentaciju za FiskalQ, eRačune ili App2App.

Tko izrađuje integraciju i što treba implementirati?

Integraciju u pravilu izrađuje vaš razvojni tim ili izvođač aplikacije prema odgovarajućoj specifikaciji. Osnovni opseg uključuje pripremu podataka računa, identifikatore, slanje, praćenje statusa i obradu grešaka. Adeo POS podrška i eventualni dodatni razvoj dogovaraju se zasebno.

Tko određuje numeraciju računa?

Odgovornost za dodjelu brojeva i način prijenosa numeracije treba definirati za odabrani proizvod i tržište. Prije razvoja uskladite poslovne prostore, blagajne i pravila numeriranja. ExternalID služi povezivanju transakcije i ne treba ga automatski poistovjetiti s fiskalnim brojem računa.

Može li jedan račun sadržavati stavke s različitim stopama PDV-a?

Da, u opisanom API modelu moguće je slati stavke s različitim stopama PDV-a. Stope, iznosi i način obračuna moraju odgovarati tržištu i specifikaciji integracije. U testiranje uključite kombinirane stope i provjeru ukupnih iznosa.

Pouzdanost i obrada grešaka

Što ako je porezni ili fiskalni servis privremeno nedostupan?

Cloud obrada koristi red čekanja i automatsko ponavljanje komunikacije prema fiskalnom servisu kod privremenih komunikacijskih problema. Vaša aplikacija treba pratiti konačan status. Pogrešni podaci ili nevažeći certifikat zahtijevaju zasebno rješavanje; retry nije obećanje da će svaki zahtjev uspjeti ili da se ponavlja neograničeno.

Što ako naša aplikacija ne može dosegnuti Adeo POS?

Sačuvajte poslovnu transakciju i njezin ExternalID u svom sustavu. Nakon povratka veze provjerite je li zahtjev ranije zaprimljen i nastavite prema pravilima za istu transakciju. Adeo POS red čekanja prema fiskalnom servisu ne zamjenjuje pohranu zahtjeva koji još nije stigao do Adeo POS-a.

Što ako nakon slanja izgubimo vezu i ne znamo je li zahtjev prihvaćen?

Prekid veze ne dokazuje da zahtjev nije zaprimljen. Sačuvajte postojeći ExternalID i provjerite status transakcije dostupnim API postupkom. Ako je ishod i dalje nejasan, uključite podršku prije pokušaja izdavanja novog računa za isti događaj.

Znači li FiscalizationErrorCode 900 da račun nije fiskaliziran?

Ne može se zaključiti samo iz tog koda. Zabilježen je slučaj u kojem je račun bio fiskaliziran, ali se rezultat zbog komunikacijskog problema nije vratio u FiskalQ. Provjerite konkretnu transakciju i po potrebi uključite podršku; nemojte automatski izdavati novi račun niti isti uzrok pripisivati svakom kodu 900.

Koje podatke trebamo poslati podršci kod nejasnog statusa?

Pripremite ExternalID, vrijeme zahtjeva s vremenskom zonom, testno ili produkcijsko okruženje, API verziju i dobiveni status ili kod greške. Dodajte primjer zahtjeva i odgovora bez lozinki, tokena, privatnih ključeva i nepotrebnih osobnih podataka. Navedite je li zahtjev ponavljan i je li callback zaprimljen.

Webshop, naplata i dokumenti

Možemo li povezati postojeći webshop s Adeo POS-om?

Da, ako webshop ili njegov izvođač može implementirati potrebne API pozive i obradu statusa. Postojeći webshop može ostati prodajno sučelje, a Adeo POS obrađivati račune i dogovorene povezane procese. Dostupnost gotovog dodatka za određenu platformu treba provjeriti zasebno.

Možemo li zadržati payment gateway i postojeću raspodjelu uplata?

Da. Naplata i raspodjela novca mogu ostati kod vašeg pružatelja platnih usluga, dok Adeo POS obrađuje račun. To vrijedi i za arhitekture s platformskim naplatama, ali samo po sebi ne znači da postoji gotov konektor za određenog providera. U integraciji treba jasno povezati uplatu, prodavatelja i račun.

Može li potvrđena uplata automatski pokrenuti izdavanje računa?

Da, to je jedan od mogućih integracijskih tijekova: aplikacija nakon potvrde uplate šalje podatke računa i naknadno prati obradu. Kada se račun mora izdati i koje podatke treba pokazati kupcu ovisi o poslovnom modelu i tržištu. Asinkroni API sam po sebi ne određuje dopušteni trenutak izdavanja ili isporuke.

Možemo li dobiti PDF s QR kodom ili sami oblikovati račun?

U podržanom modelu Adeo POS generira PDF računa s QR kodom, a integrator može kupcu ponuditi poveznicu na dokument. Možete i sami oblikovati dokument koristeći podatke računa i fiskalni rezultat. Način dohvata, identifikator dokumenta i sadržaj QR koda provjerite za odabrani API i tržište.

Šalje li Adeo POS automatski račun kupcu e-mailom?

Generiranje PDF-a ne znači automatski i slanje e-maila. U uobičajenom integracijskom tijeku vaša aplikacija šalje kupcu vlastitu poruku s poveznicom na račun. Ako želite da poruku šalje Adeo POS, dostavu, predložak i eventualni dodatni razvoj treba izričito uključiti u opseg projekta.

Možemo li sami mijenjati predložak e-maila koji šalje Adeo POS?

Samostalni uređivač predložaka nije automatski dio API integracije. Slanje prema unaprijed dogovorenom predlošku i alat kojim ga sami mijenjate različiti su zahtjevi. Ako trebate takvu mogućnost, definirajte je pri dogovoru dodatnog razvoja.

Kako povezujemo artikle, cijene, zalihe i poslovne partnere?

To je opseg poslovnog API-ja, koji treba razraditi odvojeno od same fiskalizacije. Potvrdite dostupne operacije prema dokumentaciji i odredite koji sustav vodi koji podatak. ERP ili webshop može ostati glavni izvor podataka; ne treba pretpostaviti da su svi željeni endpointovi već dostupni.

Je li slanje narudžbe u POS isto što i integracija fiskalizacije?

Ne. Narudžba ima vlastiti tijek prihvata, odbijanja, izmjene, otkazivanja i obavještavanja kupca. Fiskalizacija računa može biti jedan korak tog procesa. Potrebne statuse narudžbe i dostupne operacije treba zasebno definirati; API za račun ne podrazumijeva cjelovit sustav upravljanja narudžbama.

Jesu li storno računa i povrat novca isti postupak?

Ne. Ispravak ili storno fiskalnog dokumenta i povrat novca preko payment providera odvojeni su postupci koje vaša aplikacija treba povezati. Prije razvoja potvrdite podržane dokumente, referencu na izvorni račun i obradu djelomičnih povrata. Točan API poziv i postupanje s računom koji još nema konačan rezultat ovise o specifikaciji.

SaaS, partneri i onboarding

Može li jedna SaaS integracija raditi za više poslovnih subjekata?

Da. Jedna platformska integracija može obrađivati račune za više poslovnih subjekata, uz zasebne fiskalne i organizacijske postavke svakog korisnika. U Hrvatskoj to uključuje njegov OIB. Novi korisnik uključuje se kroz onboarding i konfiguraciju, bez razvoja nove integracije od početka.

Kako se pristupa marketplace ili franšiznom modelu?

Najprije odredite tko prodaje, tko izdaje račun i kojem subjektu pripada transakcija. Centralna aplikacija može povezivati više subjekata, ali njihovi računi i fiskalne postavke moraju biti pravilno razdvojeni. Provizije, vaučeri i naplata u ime drugih zahtijevaju zasebno oblikovan poslovni tijek.

Koja je razlika između clientCode i OIB-a?

U opisanom partnerskom modelu clientCode identificira integratora, a OIB poslovnog subjekta korisnika za kojeg se obrađuje račun. Ne treba ih zamjenjivati niti pretpostaviti da jedan clientCode znači jednog izdavatelja računa. Pristupe i povezane subjekte konfigurirajte pri onboardingu.

Je li automatsko otvaranje korisnika i upravljanje certifikatima dio fiskalizacijskog API-ja?

Ne treba to pretpostaviti. Otvaranje subjekata, poslovnih prostora, blagajni i operatera te dostava ili zamjena certifikata zaseban su administracijski opseg. Dostupne API operacije i eventualne dorade treba potvrditi prema vašem modelu onboardinga.

Tko provodi onboarding novih korisnika?

Onboarding se može organizirati uz Adeo POS ili preko obučenog partnera. Potrebno je prikupiti ispravne poslovne i fiskalne podatke, dogovoriti unos i održavanje postavki te provjeriti početak rada. Trajanje ovisi o spremnosti podataka i potrebnoj konfiguraciji.

Postoji li partnerski model za softverske tvrtke?

Da. Partnerstvo može obuhvatiti integraciju Adeo POS usluge u vaš proizvod i njezinu ponudu krajnjim korisnicima. Ugovorom se određuju komercijalni uvjeti, onboarding, naplata i razina podrške. Konkretan model prilagođava se ulozi partnera.

Tko sklapa ugovor s krajnjim korisnikom?

To ovisi o partnerskom modelu. Moguće je izravno ugovaranje korisnika s Adeo POS-om ili centralni partnerski odnos. Prije uključivanja korisnika treba jasno dogovoriti ugovornu stranu, način naplate i odgovornost za podršku.

Možemo li imati centralni partnerski portal?

Centralnu administraciju treba definirati prema zadacima koje partner treba obavljati: uključivanje korisnika, pregled postavki, praćenje rada ili obračun. To nije automatski uključeno u API za izdavanje računa. Dostupne alate i potreban razvoj razrađujemo kao zaseban opseg.

Tko pruža podršku korisnicima partnera?

Podršku može pružati partner ili Adeo POS, ovisno o ugovoru. Potrebno je dogovoriti prvu razinu podrške, eskalaciju tehničkih problema i komunikaciju s krajnjim korisnikom. Ta podjela utječe i na partnerske uvjete.

Možemo li početi s jednim korisnikom i kasnije dodavati druge?

Da, projekt se može uvoditi postupno. Ako planirate više subjekata, od početka odvojite njihove postavke i identifikatore te jasno povežite svaki račun s izdavateljem. Time izbjegavate naknadno preoblikovanje integracije koja je zamišljena samo za jednog korisnika.

eRačuni i arhiva

Možemo li slati eRačune iz vlastitog ERP-a?

Da. Izdavanje eRačuna može se uključiti u integraciju vlastite aplikacije ili ERP-a. Pri definiranju projekta treba odabrati odgovarajući API, podržanu vrstu dokumenta i tržište. Slanje dokumenta i njegovi naknadni statusi trebaju biti dio istog dogovorenog tijeka.

Je li zaprimanje eRačuna isti proces kao njihovo slanje?

Ne. Ulazni i izlazni dokumenti imaju različite postupke obrade. Ako trebate dohvat i obradu ulaznih eRačuna, uključite taj opseg i odgovarajući eRačuni API u projekt. Sama integracija izdavanja preko FiskalQ-a ne znači da je riješen i cijeli ulazni proces.

Kako pratimo status eRačuna?

U integraciju uključite preuzimanje i obradu statusa koje izlaže odabrani eRačuni API. Potvrdite što pojedini status znači za predaju, dostavu i daljnju obradu dokumenta. Nemojte pretpostaviti da tehnički prihvat dokumenta automatski znači sve kasnije korake ili njegovu naplatu.

Možemo li eRačune dodati u kasnijoj fazi projekta?

Da, tehnički opseg projekta može se podijeliti u faze. Potrebne API-je i budući tijek ulaznih i izlaznih dokumenata korisno je planirati unaprijed. Redoslijed uvođenja mora odgovarati potrebama poslovanja i obvezama na vašem tržištu.

Uređaji, Android i offline rad

Može li cloud API raditi bez interneta?

Za predaju zahtjeva cloud API-ju potrebna je mrežna veza. Offline rad zahtijeva zasebno projektiranu lokalnu pohranu i komponentu koja odgovara uređaju i tržištu. Cloud red čekanja prema poreznom servisu nije isto što i offline rad vašeg uređaja; lokalni tijek i naknadnu obradu treba provjeriti za konkretan proizvod.

Može li samoposlužni ili vending sustav koristiti cloud API?

Da. Vending ili drugi samoposlužni sustav može povezati svoju aplikaciju s Adeo POS cloud API-jem bez klasičnog POS sučelja. Centralna platforma može slati račune za više uređaja, uz pravilnu identifikaciju uređaja, naplatnog mjesta i izdavatelja. Potrebni su odgovarajuća mrežna veza i konfiguracija za tržište.

Kako projektirati vending sustav s povremenim prekidima interneta?

Najprije definirajte što uređaj smije i može raditi tijekom prekida te gdje čuva transakciju i identifikatore. Lokalnu fiskalnu obradu, naknadno slanje i korisnički prikaz treba potvrditi za konkretan uređaj i tržište. Nemojte pretpostaviti da cloud API sam daje gotov offline servis.

Postoji li Android blagajna i povezivanje putem App2App-a?

Da. Adeo POS ima Android blagajnu s fiskalnom logikom i postojeći App2App način prihvata podataka računa iz druge aplikacije. Točan korisnički tijek i podržane uređaje treba uskladiti s verzijom aplikacije. Postojanje App2App-a ne znači automatsko dovršavanje računa bez korisničke interakcije.

Mora li cloud uređaj lokalno čuvati fiskalni certifikat?

U opisanom cloud modelu fiskalni certifikat pohranjuje se i koristi u Adeo POS sustavu, a korisnik osigurava važeći certifikat. To ne opisuje automatski lokalnu ili offline arhitekturu. Potrebne certifikate, siguran način dostave i odgovornost za obnovu treba definirati za konkretno tržište i projekt.

Cijene, podrška i početak rada

Kako se određuje cijena API integracije?

Cijena ovisi o proizvodu, tržištu, broju poslovnih subjekata, blagajni ili uređaja, volumenu dokumenata i potrebnoj podršci. POS, web blagajna, vending i partnerski projekti nemaju nužno isti model obračuna. Za ponudu navedite očekivani opseg; nemojte pretpostaviti da se svaki račun naplaćuje zasebno ili da je svaki API uključen u postojeću licencu.

Kako se ugovaraju pretplata i početne naknade?

U ponudi treba navesti obračunsko razdoblje, uključene licence ili dokumente, početni setup i podršku pri integraciji. Mjesečni ili godišnji uvjeti ovise o proizvodu i tržištu. Jednokratni troškovi i dodatni razvoj trebaju biti jasno odvojeni od redovne pretplate.

Postoje li posebni uvjeti za partnere i veći broj korisnika?

Partnerski uvjeti mogu se dogovoriti prema proizvodu, broju aktivnih korisnika ili blagajni, volumenu i ulozi partnera u podršci. Popust ili cijena iz pojedinačne ponude nisu univerzalni uvjeti za sve projekte. Točan model i obračun navode se u vašoj ponudi i ugovoru.

Što trebamo pripremiti za početak suradnje?

Opišite aplikaciju, države, izdavatelje računa, načine plaćanja i potrebne vrste dokumenata. Navedite broj poslovnih subjekata i uređaja, očekivani volumen, offline potrebe te trebate li samo izdavanje ili i ulazne eRačune i poslovne podatke. Na toj osnovi određujemo API-je, dokumentaciju, testiranje i ponudu.

Koliko traje integracija?

Trajanje ovisi o opsegu, spremnosti podataka, raspoloživosti razvojnog tima i rezultatima testiranja. Jednostavno slanje računa razlikuje se od projekta s više tržišta, korisnika, eRačunima i offline radom. Rok se procjenjuje nakon razrade zahtjeva; trajanje samog unosa korisnika nije rok razvoja cijele integracije.

Kakvu podršku dobivamo tijekom integracije?

Opseg tehničke podrške i konzultacija definira se prema API cjelinama koje koristite i ugovorenom modelu. Dogovorite kontakt, način prijave problema i provjeru integracije prije produkcije. U testove uključite uspješne i neuspješne zahtjeve, ponavljanja, izgubljene odgovore i ispravno razdvajanje poslovnih subjekata.

Možemo li postupno prijeći s drugog fiskalizacijskog servisa?

Migracija se može planirati kroz razvoj i testiranje novog integracijskog sloja te postupno uključivanje korisnika. Posebno uskladite numeraciju, identifikatore, otvorene transakcije i trenutak prebacivanja. Paralelno testiranje ne znači slanje iste stvarne transakcije na dva produkcijska sustava.

Pokriva li postojeća POS licenca novu web blagajnu?

Ne treba pretpostaviti da pokriva. Web blagajna ili novi API projekt može imati zaseban licencni model i naknadu za podršku pri integraciji. Provjerite postojeći ugovor i zatražite potvrdu opsega prije uključivanja nove usluge.

Broje li se u volumenski obračun ulazni i izlazni dokumenti?

Obračunska jedinica ovisi o ugovorenom modelu. U partnerskom modelu moguće je uključiti i ulazne i izlazne dokumente. U ponudi treba izričito navesti što se broji te kako se tretiraju storna, duplikati i neuspjeli pokušaji.

Uključuje li integracijska podrška razvoj novih funkcionalnosti?

Podrška pri korištenju postojećeg API-ja i razvoj novih endpointova, predložaka ili korisničkih alata različiti su opsezi. Dodatni razvoj, testiranje i održavanje treba posebno dogovoriti. Jedna naknada za podršku ne znači automatski da su uključene sve API cjeline ili neograničene dorade.