Stranke in naročila
Prenesejo se podatki, ki so v naročilu dejansko prisotni in potrebni za dogovorjen dokument. Pravilo določi, kdaj partnerja poiščemo, posodobimo ali ustvarimo.
Minimax · spletna trgovina · avtomatizacija
Povezava lahko iz spletne trgovine v Minimax prenaša dogovorjene poslovne podatke in po potrebi vrača podatke, ki jih Minimax API dejansko omogoča prebrati. Obseg določimo šele po preverjanju organizacije, licence, dovoljenj, dokumentnih tokov in vzorčnih podatkov.
Najprej poslovni proces
Spletne trgovine imajo naročila, Minimax pa več vrst poslovnih dokumentov in pravil njihovega knjiženja. Zato izraz prenos naročila še ne določa rezultata. Naročnik in računovodstvo morata potrditi, kateri dokument se ustvari, v katerem poslovnem letu in organizaciji, s katerimi nastavitvami ter kdo ga pozneje pregleda ali izda.
V prvi fazi je smiselno avtomatizirati en dobro opredeljen tok. Integracija na primer prenese nova plačana naročila, ustvari ali poveže stranko, poveže postavke z artikli in zapiše dokument. Vračila, dobropisi, delne dobave, več skladišč ali več organizacij so ločeni procesi in jih ne vključimo samodejno brez specifikacije.
Prenesejo se podatki, ki so v naročilu dejansko prisotni in potrebni za dogovorjen dokument. Pravilo določi, kdaj partnerja poiščemo, posodobimo ali ustvarimo.
Postavko povezujemo z Minimax artiklom prek enolične šifre. Samodejno ustvarjanje manjkajočih artiklov vključimo le, če so določena vsa obvezna polja.
Status, številka dokumenta ali drug podatek se lahko vrne v trgovino samo, če ga je mogoče zanesljivo prebrati in smiselno preslikati.
Uradni dostop
Uradna navodila Minimax opisujejo API in prijavo OAuth 2.0. Za namensko povezavo potrebujemo registriranega odjemalca, pravilno povratno povezavo ter odobritev uporabnika, ki ima dostop do izbrane organizacije. Skrivni podatki se hranijo šifrirano oziroma izven javnega dela strani in se nikoli ne izpisujejo v dnevnik.
Pred razvojem preverimo pridobitev ter varno obnavljanje dostopa, seznam organizacij in po eno bralno metodo za zahtevane podatke. Nato na testnem ali dogovorjenem omejenem primeru preverimo zapis. Nabor virov in polj se lahko spremeni, zato uporabljamo aktualno dokumentacijo ter modele dejanskega okolja, ne starih primerov kode.
Podatkovna specifikacija
Iz trgovine običajno preberemo identifikator in številko naročila, datum, valuto, stanje plačila, kupca, naslova, davčne podatke, postavke, količine, cene, popuste, davek, dostavo, način plačila in opombe. Prenesemo samo podatke, ki jih cilj potrebuje in jih sme prejeti.
V vmesni aplikaciji se vrednosti normalizirajo in preslikajo. Šifra države, davčna stopnja, merska enota, način plačila, dostava ter artikel morajo dobiti ustrezno vrednost v Minimaxu. Če preslikava manjka, je varneje naročilo zadržati za pregled kot ustvariti vsebinsko napačen dokument.
Vmesna aplikacija
Dogodek iz trgovine ali redni urnik ustvari opravilo. Aplikacija shrani osnovni identifikator in preveri, ali je bilo naročilo že uspešno obdelano. Nato prebere celoten zapis, izvede validacijo ter ga pripravi za Minimax. Po uspešnem odgovoru shrani Minimax identifikator in rezultat, po začasni napaki pa opravilo ostane v vrsti.
Kontrolna plošča pokaže čas zadnjega uspešnega prenosa, rezultate zagonov, število uspešnih, preskočenih in neuspešnih zapisov ter razumljiv razlog napake. Omogoča ročni zagon in varen ponovni poskus. Osnovna plošča ni namenjena spreminjanju računovodskih dokumentov ali zamenjavi Minimax uporabniškega vmesnika.
Novo ali izbrano naročilo dobi enolično opravilo in se postavi v čakalno vrsto.
Preverijo se kupec, SKU-ji, zneski, davki, valuta ter obvezni podatki ciljnega dokumenta.
Vrednosti trgovine se pretvorijo v potrjene Minimax identifikatorje in strukturo.
Aplikacija izvede dovoljeno API operacijo ter shrani tehnični in poslovni rezultat.
Napaka se razvrsti, začasen primer se ponovi, vsebinski primer pa čaka na popravek ali odločitev.
Prevzemni primeri
Pred produkcijo preverimo vsaj fizično osebo, podjetje, davčnega zavezanca, več postavk, popust, kupon, strošek dostave, različne davčne stopnje, že obstoječega kupca in manjkajoč SKU. Znesek dokumenta primerjamo z naročilom po postavkah, davku in zaokrožitvah.
Ponovimo isti dogodek in potrdimo, da ne nastane podvojen dokument. Preverimo tudi prekinjen dostop, potečen žeton, začasno nedosegljiv API in zavrnjen vsebinski zapis. Produkcijo vključimo postopno, prve prenose pa skupaj z naročnikom preverimo v trgovini in Minimaxu.
Sinhronizacijo zaloge, računov, dobropisov ali drugih dodatnih tokov vključimo le, ko so zahtevani poslovni proces, API operacije in prevzemni primeri ločeno potrjeni.
Brez praznih obljub
Pogosta vprašanja
Možnosti vedno preverimo na konkretnih sistemih, licencah, dostopih in vzorčnih podatkih.
Da, če je jasno določen ciljni dokument, so podatki veljavni in zahtevano operacijo podpira dejanski API. Neveljavni ali nepopolni primeri se zadržijo za pregled.
Ne privzeto. Prenos naročila, ustvarjanje dokumenta, izdaja računa in davčno potrjevanje so različni poslovni koraki. Vključimo samo korake, ki so izrecno dogovorjeni in tehnično preverjeni.
Vmesna baza shrani zunanjo referenco naročila, stanje obdelave in Minimax identifikator. Pred ponovnim zapisom aplikacija preveri že uspešen rezultat.
Da, če trgovina omogoča zanesljiv dostop do potrebnih podatkov in dogodkov. Minimax del ostane ločen modul, vhodni modul pa se prilagodi konkretni platformi.
Da. Modularna zasnova omogoča nadgradnje, vendar se zaloga, računi, dobropisi, vračila ali dodatne organizacije specificirajo, preverijo in ocenijo takrat, ko so dejansko potrebni.