Kiekvienas užsakymas vienoje laiko juostoje, nuo priėmimo iki apmokėtos sąskaitos.
Order to cash (nuo užsakymo iki apmokėjimo), procure to pay (nuo pirkimo iki mokėjimo) ir paslaugų užsakymai eina per ERP, CRM, e. prekybos, sandėlio, transporto ir finansų sistemas. Jas sujungiame dokumentuotomis API ir įvykiais, kiekvienam užsakymui suteikiame vieną būseną visose sistemose, o kiekvieną išimtį perduodame DI agentui, kuris parengia sprendimo pasiūlymą žmogui patvirtinti.
Lietuvos gamintojams, eksportuotojams ir platintojams, kurie parduoda, perka ir išrašo sąskaitas keliose ES valstybėse narėse, kiekvienoje su savo sistemomis, vežėjais ir e. sąskaitų taisyklėmis.
Pardavimo užsakymas, pirkimo užsakymas ar paslaugos užsakymas vieną kartą įrašomas jį valdančioje pirminėje sistemoje ir per dokumentuotas API bei įvykius paskirstomas kitoms sistemoms. Iš būsenos įvykių kiekvienam užsakymui sudaroma viena laiko juosta. Kai žingsnis nepavyksta arba išeina už leistinų ribų, agentas surenka kontekstą ir pasiūlo sprendimą, kurį žmogus patvirtina, prieš jį įvykdant pirminėje sistemoje. Sąskaitos siunčiamos ir sutikrinamos kaip struktūrizuotos e. sąskaitos, o procesų savininkai peržiūri srautą ir sąsajų būklę.
Prieš ir po
Kas pasikeičia kasdienėje veikloje
Dabar
Su sistema
Dabar
Dabar: Įvedama iš naujo kiekviename perdavime
E. parduotuvėje ar pardavimų komandos priimtas užsakymas iš naujo įvedamas į ERP, o pristatymo ir sąskaitos duomenys ranka kopijuojami į sandėlio, transporto ir finansų sistemas.
Su sistema
Su sistema: Įvesta kartą, naudojama visur
Kiekvienas užsakymas, pristatymas ir sąskaita sukuriami juos valdančioje sistemoje ir paskelbiami kaip įvykis. Kitos sistemos šį įvykį prenumeruoja, o ne perrašo duomenis.
Dabar
Dabar: Vakarykštė būsena
Dėl naktinių paketinių sąsajų klientų aptarnavimas, planavimas ir finansai mato skirtingą, pasenusią to paties užsakymo būseną. Klientui, kuris klausia, kur jo siunta, tenka laukti atskambinimo.
Su sistema
Su sistema: Viena dabartinė būsena
Kiekvienas užsakymas ar prašymas turi vieną laiko juostą, sudarytą iš visų sistemų, per kurias jis eina, įvykių. Klientų aptarnavimas, planavimas ir finansai mato tuos pačius faktus, kaip ir aptarnavimo asistentas, atsakantis į būsenos klausimus.
Dabar
Dabar: Išimtys sprendžiamos pašto dėžutėse
Atsargų trūkumas, kainų neatitikimai, nepavykę pristatymai ir atmestos e. sąskaitos sprendžiami el. laiškais ir skaičiuoklėmis, o vėliau niekas negali pasakyti, kas ką nusprendė.
Su sistema
Su sistema: Išimtys ateina su pasiūlymu
Agentas surenka kiekvienos išimties duomenis ir pasiūlo sprendimą. Žmogus jį patvirtina, pataiso arba atmeta viename išimčių pulte, o sprendimas užfiksuojamas.
Dabar
Dabar: Nesutampantys pagrindiniai duomenys
Tas pats klientas, tiekėjas, produktas ar kaina keliose sistemose turi skirtingas reikšmes, ir niekas neatsako už tai, kuri teisinga.
Su sistema
Su sistema: Vienas savininkas kiekvienam duomenų objektui
Klientai, tiekėjai, produktai ir kainos turi sutartą pirminę sistemą ir paskirtą savininką. Apie dublikatus ir konfliktus pranešama tam savininkui, o ne tyliai taisoma tolesnėse sistemose.
Dabar
Dabar: Kiekvienas pokytis prideda sąsają
Naujas pardavimo kanalas, prekyvietė ar juridinis asmuo reiškia dar vieną tiesioginę sąsają. Skirtingų šalių e. sąskaitų reikalavimai kiekvienam procesui prideda dar ir struktūrizuotą formatą bei tinklą.
Su sistema
Su sistema: Nauji ryšiai naudoja tas pačias specifikacijas
Naujas kanalas, juridinis asmuo ar e. sąskaitų tinklas vieną kartą prijungiamas prie dokumentuotų API ir įvykių, o ne prie kiekvienos sistemos atskirai.
Darbo procesas
Kaip vyksta darbo procesas
Kai duomenys tvarkingi, pagrindiniame kelyje rankinio darbo nereikia. Kai užsakymas, pristatymas ar sąskaita nukrypsta, išimčių ciklas pateikia juos žmogui su įrodymais ir pasiūlymu, o patvirtintas pataisymas grįžta per tą patį integracijų sluoksnį.
Iliustracinis darbo procesas
7 žingsniai · 1 žmogaus patikra
Legenda
Sistema
DI agentas
Žmogus
Žmogaus patikra
Išimties kelias
Susieti procesai: iliustracinis darbo procesas su išimčių ciklu
Skaityti diagramą kaip tekstą
Pagrindinis kelias eina nuo verslo įvykio įrašymo vieną kartą pirminėje sistemoje, per jo paskirstymą kitoms sistemoms API ir įvykiais bei vienos laiko juostos kiekvienam užsakymui sudarymą, iki sąskaitų, sutikrinimo ir atsiskaitymo. Jis baigiasi tuo, kad procesų savininkai peržiūri srautą ir šalina išimčių priežastis.
Kai žingsnis nepavyksta, vėluoja ar išeina už leistinų ribų, išimtis po laiko juostos žingsnio pasuka iš pagrindinio kelio. Agentas surenka kontekstą ir pasiūlo sprendimą, o žmogus jį patvirtina, pataiso arba atmeta. Patvirtintas veiksmas įvykdomas pirminėje sistemoje ir kaip naujas įvykis grįžta į paskirstymo žingsnį.
Patvirtinimo žingsnis yra žmogaus patikra: be žmogaus neregistruojama jokia finansinė operacija, nekeičiama kaina ar kredito limitas ir neįsipareigojama klientui.
01
1 žingsnis: Įvykio įrašymas vieną kartąSistema
Pardavimo užsakymas iš e. parduotuvės, prekyvietės, EDI ar pardavimų komandos, pirkimo užsakymas ar paslaugos užsakymas sukuriamas jį valdančioje sistemoje. Ši sistema paskelbia verslo įvykį CloudEvents formatu, aprašytą AsyncAPI specifikacijoje. Popieriniai ir PDF užsakymai bei tiekėjų sąskaitos pirmiausia praeina išmanųjį dokumentų apdorojimą.
02
2 žingsnis: Paskirstymas per API ir įvykiusSistema
Integracijų sluoksnis per dokumentuotas API (OpenAPI) pristato įvykį sandėlio, transporto, finansų ir CRM sistemoms. Gavėjai yra idempotentiški, todėl pakartota žinutė niekada nesukuria antros siuntos ar sąskaitos, o nepristatytos žinutės laukia klaidų eilėje, kad jas būtų galima pakartoti.
03
3 žingsnis: Viena laiko juosta kiekvienam užsakymuiSistema
Visų sistemų būsenos įvykiai (patvirtinta, surinkta, išsiųsta, pristatyta, išrašyta sąskaita, apmokėta) pagal verslo nuorodą sujungiami į vieną laiko juostą. Etapų ir leistinų nuokrypių taisyklės sukuria išimtį, kai žingsnis nepavyksta, vėluoja ar nesutampa: atsargų trūkumas, kaina už sutarto nuokrypio ribų, nepavykęs pristatymas, atmesta e. sąskaita.
04
4 žingsnis: Konteksto surinkimas ir pasiūlymasDI agentas
Kiekvienai išimčiai agentas iš susijusių sistemų perskaito tai, ko reikia: užsakymą, atsargų likučius, kainų susitarimą, vežėjo būseną ir kliento sąlygas. Jis pasiūlo sprendimą su argumentais ir naudotais duomenimis, pavyzdžiui, pakaitinę prekę, pataisytą kainą, naują pristatymo datą ar pataisytą sąskaitą.
Išimties kelias: Žingsnis nepavyko arba už leistinų ribų
05
5 žingsnis: Patvirtinimas pagal ribasŽmogus
Klientų aptarnavimo, logistikos ar finansų darbuotojas išimčių pulte mato išimtį, įrodymus ir pasiūlymą ir jį patvirtina, pataiso arba atmeta. Patvirtintas veiksmas įvykdomas per pirminės sistemos API, o ši pakeitimą paskelbia kaip naują įvykį.
Išimties kelias: Žingsnis nepavyko arba už leistinų ribų· Grįžtama į 2 žingsnį
Žmogaus patikra
Agentai be patvirtinimo niekada neregistruoja finansinių operacijų, nekeičia kainų ar kredito limitų ir neįsipareigoja klientui. Kas tvirtina, lemia kiekvienam veiksmo tipui nustatytos ribos, o kiekvienas pasiūlymas ir sprendimas registruojamas.
06
6 žingsnis: Sąskaitos, sutikrinimas ir atsiskaitymasSistema
Siunčiamos sąskaitos iš ERP išeina kaip struktūrizuotos e. sąskaitos: klientams šalyse, kuriose naudojamas Peppol, per prieigos tašką (Peppol BIS Billing 3.0, EN 16931), o Lietuvos perkančiosioms organizacijoms per SABIS. Gaunamos tiekėjų sąskaitos sutikrinamos su pirkimo užsakymais ir prekių gavimu, o banko ar mokėjimo paslaugų teikėjo pranešta mokėjimo būsena užbaigia laiko juostą.
07
7 žingsnis: Srauto peržiūra ir priežasčių šalinimasŽmogus
Procesų savininkai ir integracijų komanda reguliariai peržiūri išimtis pagal priežastį, sąsajų gedimus ir pagrindinių duomenų konfliktus. Jie šalina priežastį ten, kur ji yra: pagrindinių duomenų įraše, nuokrypio taisyklėje ar duomenų susiejime, o ne vis iš naujo sprendžia tą pačią išimtį.
Komponentai
Ką sukurtume
01
Įvykiais grindžiamas integracijų sluoksnis
Pagal iš anksto sutartas specifikacijas kuriamos API ir įvykiai tarp ERP, CRM, e. prekybos, sandėlio, transporto ir finansų sistemų, aprašyti OpenAPI ir AsyncAPI su CloudEvents formatu, Jūsų esamoje integracijų platformoje arba debesijai pritaikytoje architektūroje.
Sutarta pirminė sistema ir savininkas kiekvienam duomenų objektui, klientų, tiekėjų ir produktų sutapdinimo taisyklės bei ataskaitos apie dublikatus ir konfliktus juos valdantiems žmonėms.
Paslauga, kuri įvykius sujungia į vieną laiko juostą kiekvienam užsakymui ar prašymui, taiko etapų ir nuokrypių taisykles ir procesų savininkams rodo srautą bei išimtis.
Išimčių eilė su surinktu kontekstu ir agento pasiūlymu, patvirtinimo, taisymo ir atmetimo veiksmais bei kiekvienam veiksmo tipui nustatytomis tvirtinimo ribomis, taikomomis ten, kur veiksmas vykdomas.
Peppol BIS Billing 3.0 ir EN 16931 sąskaitos UBL formatu, siunčiamos ir gaunamos per prieigos tašką, ir e. sąskaitos Lietuvos perkančiosioms organizacijoms per SABIS; prieš siunčiant visos sąskaitos patikrinamos, o atmestos nukreipiamos į išimčių pultą.
Kiekvienos sąsajos būklės stebėsena ir įspėjimai, eksploatavimo vadovai komandai ir kontroliuojamas nepavykusių žinučių pakartojimas, diegiami kaip infrastruktūra kaip kodas Jūsų debesijos aplinkoje.
SAP S/4HANA pardavimai, pirkimai ir finansaiPlatformaSAP
Salesforce Sales, Service ir Commerce CloudPlatformaSalesforce
Odoo pardavimai, atsargos, pirkimai ir apskaitaPlatformaOdoo
E. prekybos platformos, prekyvietės ir vežėjų API
Sandėlių ir transporto valdymo sistemos
Peppol prieigos taškas, SABIS, bankai ir mokėjimų paslaugų teikėjai
Produktų informacijos valdymas ir duomenų platforma
Kontrolės priemonės
Nuo pradžių numatytos kontrolės priemonės
Prieigos ribos
Kiekviena integracija ir agentas kiekvienoje sistemoje veikia su savo paslaugos tapatybe, apribota tik reikalingomis API operacijomis. Agentas kontekstui surinkti gali skaityti iš kelių sistemų, bet rašyti gali tik per trumpą patvirtintų veiksmų sąrašą, vykdomą per pirminės sistemos API ir niekada tiesiogiai duomenų bazėje.
Žmogaus peržiūra
Tvirtinimo ribos kiekvienam veiksmo tipui nustatomos su proceso savininku: ką agentas gali tik pasiūlyti, ką tvirtina komandos narys ir kam reikia antro tvirtintojo. Finansinės operacijos, kainų ir kredito limitų pakeitimai bei įsipareigojimai klientams visada laukia žmogaus. Mažo poveikio, grįžtami veiksmai, pavyzdžiui, nepavykusios žinutės pakartojimas, gali vykti be patvirtinimo, jei savininkas sutinka.
Atsekamumas
Kiekvienas įvykis, pasiūlymas, patvirtinimas, atmetimas ir įvykdytas veiksmas registruojamas prie užsakymo ar prašymo numerio, kartu su agento naudotais duomenimis, modelio ir instrukcijų versija bei tvirtintoju. Ginčijamą sąskaitą ar kliento skundą galima atsekti žingsnis po žingsnio.
Duomenų apsauga
Klientų ir tiekėjų kontaktiniai duomenys keliauja tik į tas sistemas, kurioms jų reikia. Laiko juostoje saugomos verslo nuorodos ir būsenos, o ne visi įrašai, žurnalai saugomi Jūsų nustatytą laiką, o duomenys tvarkomi sutartame regione.
DI skaidrumas
Agento pasiūlymai išimčių pulte taip ir pažymimi, šalia rodant įrodymus ir argumentus. Pirminės sistemos lieka lemiamos: laiko juosta rodo tai, ką jos praneša, ir niekada jų duomenų nepakeičia.
Rodikliai
Ką matuotume
Šiuos rodiklius sutariame su Jumis analizės etape, o pradinį lygį paimame iš dabartinių sistemų ir sąsajų žurnalų, prieš ką nors keičiant.
Ką matuotume
Rodiklis
Kodėl tai svarbu
Kaip tai matuotume
01Užsakymo ciklo trukmė
Kodėl tai svarbuRodiklis, kurį klientai pastebi pirmiausia ir kuris parodo, kur užsakymai laukia.
Kaip tai matuotumeLaikas nuo užsakymo gavimo iki pristatymo ir iki apmokėjimo pagal kanalą ir juridinį asmenį, iš laiko juostos įvykių.
02Užsakymai be rankinio įsikišimo
Kodėl tai svarbuParodo, kokia srauto dalis veikia su tvarkingais duomenimis ir sutartomis taisyklėmis.
Kaip tai matuotumeUžsakymų ir prašymų, kurie pasiekia atsiskaitymą be jokio rankinio žingsnio ar išimties, dalis pagal laiko juostą.
03Išimtys pagal priežastį ir sprendimo trukmė
Kodėl tai svarbuParodo, kurias priežastis šalinti pirmiausia ir ar išimčių pultas spėja.
Kaip tai matuotumeIšimčių skaičius pagal priežasties kodą ir laikas nuo aptikimo iki įvykdyto sprendimo pagal išimčių pulto žurnalus.
04Atmestų e. sąskaitų dalis
Kodėl tai svarbuAtmestos sąskaitos vėlina mokėjimą ir dažniausiai rodo pagrindinių duomenų ar susiejimo klaidas.
Kaip tai matuotumeAtmestų siųstų ir gautų e. sąskaitų dalis pagal priežastį, iš e. sąskaitų kanalų grąžinamų atsakymų.
05Sąsajų gedimai ir atkūrimo trukmė
Kodėl tai svarbuParodo, ar integracijų sluoksnis patikimas ir ar gedimai greitai pastebimi ir pašalinami.
Kaip tai matuotumeNepavykusios žinutės kiekvienoje sąsajoje ir laikas nuo gedimo iki sėkmingo pakartojimo pagal integracijų stebėseną.
06Pagrindinių duomenų dublikatai ir konfliktai
Kodėl tai svarbuDauguma išimčių kyla dėl duomenų, kurie skirtingose sistemose skiriasi.
Kaip tai matuotumeNeišspręsti dublikatai ir nesutampančios reikšmės pagal duomenų objektą ir sistemą, iš sutapdinimo ataskaitų.
Kol nėra pradinio lygio, tikslinių reikšmių nenustatome.
Diegimas
Kaip diegtume
01 etapas
Analizė ir proceso žemėlapis
Vienas procesas, pavyzdžiui, order to cash vienam pardavimo kanalui, ir vienas išimties tipas. Sudarome sistemų, sąsajų ir duomenų savininkų žemėlapį ir išanalizuojame, kaip išimtys sprendžiamos šiandien.
Etapo užbaigimo kriterijai
Sudarytas proceso, sistemų ir duomenų savininkų žemėlapis
Sutartas pirmasis išimties tipas ir tvirtinimo ribos
Pradinis lygis paimtas iš dabartinių žurnalų
02 etapas
Integracija ir laiko juosta
Dokumentuotos API ir įvykiai aprėpties sistemoms, o laiko juosta veikia greta esamų sąsajų jų nekeisdama.
Etapo užbaigimo kriterijai
Įvykių specifikacijos paskelbtos ir versijuojamos
Laiko juosta atrinktuose užsakymuose sutampa su pirminėmis sistemomis
Išbandyti pakartojimas ir eksploatavimo vadovai
03 etapas
Bandomasis išimčių pulto etapas
Agentas siūlo sprendimus pasirinktam išimties tipui, o žmonės tvirtina kiekvieną pasiūlymą. Pasiūlymus lyginame su tuo, ką būtų darę darbuotojai.
Etapo užbaigimo kriterijai
Pasiūlymų kokybė atitinka sutartus kriterijus
Ribos ir tvirtintojai nustatyti kiekvienam veiksmo tipui
Audito seką peržiūrėjo finansų ir vidaus kontrolės specialistai
04 etapas
Plėtra ir senųjų sąsajų išjungimas
Daugiau išimčių tipų, kanalų, juridinių asmenų ir procesų, pavyzdžiui, procure to pay, naudojant tas pačias specifikacijas. Senosios tiesioginės sąsajos išjungiamos po vieną.
Etapo užbaigimo kriterijai
Kiekvienas naujas srautas naudoja tas pačias specifikacijas ir stebėseną
Gamybos pagal užsakymą ir atsarginių dalių užsakymai nuo ERP iki sandėlio ir vežėjų, tiekėjų patvirtinimus ir e. sąskaitas sutikrinant su pirkimo užsakymais.
Šilumos tiekimo įmonių prijungimo ir įrengimo darbai, sekami nuo darbo užsakymo per vizitą vietoje iki sąskaitos, ir medžiagų pirkimai pagal sutartis su tiekėjais.
Miesto viešojo transporto ir kelių priežiūros įmonių techninės priežiūros darbų užsakymai, rangovų pirkimo užsakymai ir jų sąskaitos, sekami nuo užsakymo iki mokėjimo.
Procure to pay su struktūrizuotomis e. sąskaitomis viešojo sektoriaus institucijoms ir iš jų, sutikrinant jas su užsakymais ir prekių gavimu prieš mokėjimą; tiekėjai e. sąskaitas perkančiosioms organizacijoms teikia per SABIS.
Iliustracinis pavyzdys
Baldų eksportuotojas, parduodantis keliose šalyse
Situacija
Baldų gamintojas parduoda per e. parduotuvę, dvi prekyvietes ir prekybos tinklus keliose ES šalyse, o prekes siunčia iš dviejų sandėlių. Užsakymai iš naujo įvedami į ERP, vežėjai apie pristatymo problemas praneša el. paštu, o kiekvienoje šalyje sąskaitos išrašomos savaip.
Sistema
Užsakymai, atsargos, siuntos ir sąskaitos kaip įvykiai keliauja tarp e. parduotuvės, ERP, sandėlio sistemos ir vežėjų, o kiekvienas užsakymas turi vieną laiko juostą. Sąskaitos išsiunčiamos kaip struktūrizuotos e. sąskaitos per vieną prieigos tašką tokiu tinklu ir formatu, kokio reikalauja kiekviena šalis.
Žmogaus kontrolė
Atsargų trūkumas ir nepavykę pristatymai patenka į vieną išimčių pultą, kuriame agentas pasiūlo pakaitinį gaminį ar naują pristatymo datą. Kiekvieną pasiūlymą tvirtina klientų aptarnavimas, o kainų pakeitimams ir kreditinėms sąskaitoms reikia finansų skyriaus patvirtinimo.
Ką matuotume
Užsakymų be rankinio įsikišimo dalis pagal šalį ir kanalą, išimtys pagal priežastį ir sprendimo trukmė bei atmestų e. sąskaitų dalis pagal šalį.
Lietuva
Vienas procesas, Lietuvos ir eksporto rinkų reikalavimai
Eksportuojančios Lietuvos įmonės ir platintojai tuos pačius order to cash ir procure to pay procesus vykdo su klientais keliose Europos Sąjungos valstybėse narėse, per skirtingus vežėjus ir bankus. Lietuvoje e. sąskaitos perkančiosioms organizacijoms teikiamos per SABIS nuo 2017 m. liepos 1 d., kitų šalių nacionaliniai reikalavimai įsigalioja skirtingu metu, o ES paketas „PVM skaitmeniniame amžiuje“ (ViDA) nuo 2030 m. liepos 1 d. struktūrizuotas e. sąskaitas daro numatytąja tvarka ES vidaus B2B tiekimui. Kuriame vieną integracijų sluoksnį, kuriame kiekvienos šalies formatas ir kanalas yra už tų pačių įvykių, todėl naujas reikalavimas reiškia naują jungtį, o ne naują procesą.
Duomenų aktas, taikomas nuo 2025 m. rugsėjo 12 d., nustato perėjimo tarp duomenų tvarkymo paslaugų taisykles, todėl įvykių specifikacijas ir duomenų eksportą laikome perkeliamus. Išimčių pulto agentai projektuojami atsižvelgiant į Dirbtinio intelekto aktą, o integracijos turi registruojamą prieigą ir dokumentuotus komponentus klientams, kurie turi įrodyti tiekimo grandinės saugumą pagal Kibernetinio saugumo įstatymą; jo įgyvendinimą prižiūri Nacionalinis kibernetinio saugumo centras (NKSC).
Ne. Jūsų ERP, CRM, e. parduotuvė ir sandėlio sistema kiekviena atlieka savo darbą. Integruojame aplink šias pirmines sistemas, sutariame, kuri sistema valdo kuriuos duomenis, ir suteikiame procesui vieną laiko juostą per visas jas. Kai sena užsakymų ar ERP sistema stabdo pokyčius, pirmiausia ją apgaubiame API, kaip aprašyta puslapyje Senųjų sistemų modernizavimas.
02Ar pakeičiate mūsų integracijų tarpinę programinę įrangą?
Ne, jei ji atlieka savo darbą. Kuriame ant Jūsų jau naudojamos integracijų platformos ar pranešimų brokerio ir pridedame specifikacijas, stebėseną ir pakartojimą ten, kur jų trūksta. Jei tokios platformos nėra, kuriame debesijai pritaikytą sprendimą. Daugiau rasite puslapyje Integracijos ir API.
03Ar agentai gali veikti savarankiškai?
Tik neperžengdami ribų, kurias sutariate kiekvienam veiksmo tipui, ir tik atlikdami mažo poveikio grįžtamus veiksmus, pavyzdžiui, pakartodami nepavykusią žinutę. Finansinėms operacijoms, kainoms, kredito limitams ir įsipareigojimams klientams visada reikia žmogaus. Skaitykite, kur DI agentams reikia žmogaus patvirtinimo.
04Kaip čia dera e. sąskaitų reikalavimai?
Lietuvoje e. sąskaitos perkančiosioms organizacijoms per SABIS privalomos nuo 2017 m. liepos 1 d. Kitose valstybėse narėse nacionaliniai reikalavimai įsigalioja skirtingu metu, o ES paketas „PVM skaitmeniniame amžiuje“ (ViDA) nuo 2030 m. liepos 1 d. struktūrizuotas e. sąskaitas daro numatytąja tvarka ES vidaus B2B tiekimui. E. sąskaitą laikome dar vienu proceso įvykiu: ji išrašoma ERP sistemoje, išsiunčiama atitinkamu kanalu, o atmesta sprendžiama išimčių pulte. Skaitykite mūsų gidą apie e. sąskaitas.
05Kaip išvengiate dar vieno trapaus tiesioginių sąsajų tinklo?
Sistemos skelbia ir naudoja dokumentuotus įvykius ir API per vieną sluoksnį, o ne tiesiogiai jungdamosi viena su kita. Specifikacijos versijuojamos, gavėjai idempotentiški, nepavykusias žinutes galima pakartoti, o kiekvienas srautas turi paskirtą savininką. Naujas kanalas prenumeruoja esamus įvykius, o ne prideda sąsają prie kiekvienos sistemos.
06Kaip atrodo pirmoji apimtis?
Vienas procesas ir vienas išimties tipas, pavyzdžiui, order to cash vienam pardavimo kanalui, kai pirmoji išimtis yra atsargų trūkumas. Taip patikrinami įvykiai, laiko juosta ir tvirtinimo srautas, prieš pridedant daugiau. Daugiau rasite puslapyje Kaip dirbame.
Aptarkime Jūsų užsakymų ir sąskaitų srautus
Pasirinkite vieną procesą ir šalis, kuriose jis vyksta. Kartu sudarysime sistemų, sąsajų ir išimčių žemėlapį ir pasiūlysime pirmąją versiją, veikiančią visiems Jūsų juridiniams asmenims.