Fiecare comandă pe o singură cronologie, de la primire la factura încasată.
Order to cash, procure to pay și fluxul de la solicitarea de service la factură trec prin ERP, CRM, magazin online, depozit, transport și contabilitate. Le conectăm prin API-uri și evenimente documentate, dăm fiecărei comenzi un singur stadiu în toate aceste sisteme și trimitem fiecare excepție unui agent care pregătește o soluție, aprobată apoi de o persoană.
Pentru organizații care vând, cumpără și facturează în mai multe state membre ale UE, fiecare cu propriile sisteme, transportatori și reguli de facturare electronică.
Echipele de furnizori și clienți din contabilitate
Echipele de integrare și operațiuni IT
Flux de lucru ilustrativ
01Evenimentul, înregistrat o singură datăSistem
02Distribuire prin API-uri și evenimenteSistem
03O singură cronologie pe comandăSistem
04Adunarea contextului și propunereaAgent IA
05Aprobare în limita pragurilorPersoană
06Facturare, potrivire și încasareSistem
07Analiza fluxului și corectarea cauzelorPersoană
O comandă de vânzare, o comandă de achiziție sau o solicitare de service este înregistrată o singură dată în sistemul care o deține și distribuită celorlalte sisteme prin API-uri și evenimente documentate. Evenimentele de stadiu construiesc o singură cronologie pentru fiecare comandă. Când un pas eșuează sau iese din toleranță, un agent adună contextul și propune o soluție, pe care o persoană o aprobă înainte de a fi executată în sistemul care deține datele. Facturile sunt transmise și potrivite ca facturi electronice structurate, iar responsabilii de proces analizează fluxul și starea interfețelor.
Înainte și după
Ce se schimbă în operațiunile zilnice
Astăzi
Cu sistemul
Astăzi
Astăzi: Reintroducere la fiecare predare
O comandă primită în magazinul online sau de echipa de vânzări este scrisă din nou în ERP, iar datele de livrare și de facturare sunt copiate manual în sistemele de depozit, de transport și de contabilitate.
Cu sistemul
Cu sistemul: Introdus o dată, folosit peste tot
Fiecare comandă, livrare și factură este creată în sistemul care o deține și publicată ca eveniment. Celelalte sisteme se abonează la eveniment în loc să îl reintroducă.
Astăzi
Astăzi: Stadiul de ieri
Interfețele care rulează noaptea fac ca relația cu clienții, planificarea și contabilitatea să vadă fiecare un stadiu diferit și depășit al aceleiași comenzi. Un client care întreabă unde este livrarea primește un telefon mai târziu.
Cu sistemul
Cu sistemul: Un singur stadiu actual
Fiecare comandă sau solicitare are o singură cronologie, construită din evenimentele tuturor sistemelor prin care trece. Relația cu clienții, planificarea și contabilitatea văd aceleași fapte, la fel ca un asistent din soluția Asistență pentru clienți și cetățeni care răspunde la întrebări despre stadiu.
Astăzi
Astăzi: Excepții rezolvate prin e-mail
Lipsurile de stoc, diferențele de preț, livrările eșuate și facturile electronice respinse se rezolvă prin e-mail și foi de calcul, iar ulterior nimeni nu poate spune cine ce a decis.
Cu sistemul
Cu sistemul: Excepțiile vin cu o propunere
Un agent adună datele din spatele fiecărei excepții și propune o soluție. O persoană o aprobă, o modifică sau o respinge într-un singur birou de excepții, iar decizia este înregistrată.
Astăzi
Astăzi: Date de referință care nu se potrivesc
Același client, furnizor, produs sau preț există în mai multe sisteme, cu valori diferite, și nimeni nu răspunde de varianta corectă.
Cu sistemul
Cu sistemul: Un singur responsabil pentru fiecare tip de date
Clienții, furnizorii, produsele și prețurile au fiecare un sistem de referință convenit și un responsabil numit. Dublurile și conflictele sunt raportate acelui responsabil, nu corectate pe tăcute în sistemele din aval.
Astăzi
Astăzi: Fiecare schimbare adaugă o interfață
Un canal de vânzare nou, un marketplace sau o entitate juridică nouă înseamnă încă o legătură punct la punct. Obligațiile naționale de facturare electronică, precum RO e-Factura, adaugă peste fiecare proces un format structurat și un canal de transmitere.
Cu sistemul
Cu sistemul: Conexiunile noi refolosesc aceleași contracte
Un canal nou, o entitate nouă sau un nou canal de facturare electronică se conectează o singură dată la API-uri și evenimente documentate, în loc să se conecteze separat la fiecare sistem.
Flux de lucru
Cum funcționează fluxul de lucru
Când datele sunt curate, ramura principală nu cere nicio intervenție manuală. Când o comandă, o livrare sau o factură deviază, bucla de excepție o aduce la o persoană, cu dovezile și o propunere, iar corecția aprobată trece înapoi prin același strat de integrare.
Flux de lucru ilustrativ
7 pași · 1 verificare umană
Legendă
Sistem
Agent IA
Persoană
Verificare umană
Ramură de excepție
Procese conectate: flux de lucru ilustrativ cu buclă de excepție
Citiți diagrama ca text
Ramura principală merge de la înregistrarea unui eveniment de business o singură dată în sistemul care îl deține, prin distribuirea lui către celelalte sisteme cu API-uri și evenimente și construirea unei singure cronologii pe comandă, până la facturare, potrivire și încasare. Se încheie cu analiza fluxului de către responsabilii de proces și corectarea cauzelor excepțiilor.
Când un pas eșuează, întârzie sau iese din toleranță, excepția părăsește ramura principală după pasul cronologiei. Un agent adună contextul și propune o soluție, iar o persoană o aprobă, o modifică sau o respinge. Acțiunea aprobată este executată în sistemul care deține datele și revine la pasul de distribuire ca eveniment nou.
Pasul de aprobare este punctul de verificare umană: nicio înregistrare financiară, nicio schimbare de preț sau de limită de credit și niciun angajament față de un client nu se fac fără o persoană.
01
Pasul 1: Evenimentul, înregistrat o singură datăSistem
O comandă de vânzare din magazinul online, de pe un marketplace, prin EDI sau de la echipa de vânzări, o comandă de achiziție sau o solicitare de service este creată în sistemul care o deține. Acel sistem publică un eveniment de business într-un plic CloudEvents, descris într-un contract AsyncAPI. Comenzile pe hârtie sau în PDF și facturile furnizorilor trec mai întâi prin soluția Procesarea documentelor.
02
Pasul 2: Distribuire prin API-uri și evenimenteSistem
Stratul de integrare livrează evenimentul către sistemele de depozit, transport, contabilitate și CRM prin API-urile lor documentate (OpenAPI). Consumatorii sunt idempotenți, așa că un mesaj repetat nu creează niciodată o a doua expediere sau o a doua factură, iar mesajele care nu pot fi livrate așteaptă într-o coadă de erori pentru a fi retrimise.
03
Pasul 3: O singură cronologie pe comandăSistem
Evenimentele de stadiu din fiecare sistem (confirmată, pregătită, expediată, livrată, facturată, încasată) sunt corelate după referința de business într-o singură cronologie. Regulile pentru etape și toleranțe ridică o excepție când un pas eșuează, întârzie sau nu se potrivește: o lipsă de stoc, un preț în afara toleranței convenite, o livrare eșuată, o factură electronică respinsă.
04
Pasul 4: Adunarea contextului și propunereaAgent IA
Pentru fiecare excepție, un agent citește din sistemele implicate ce îi trebuie: comanda, nivelul stocului, acordul de preț, stadiul de la transportator și condițiile clientului. Propune o soluție, cu raționamentul și datele folosite, de exemplu un produs înlocuitor, un preț corectat, o nouă dată de livrare sau o factură corectată.
Ramură de excepție: Pas eșuat sau în afara toleranței
05
Pasul 5: Aprobare în limita pragurilorPersoană
Un angajat din relația cu clienții, din logistică sau din contabilitate vede în biroul de excepții excepția, dovezile și propunerea și o aprobă, o modifică sau o respinge. Acțiunea aprobată este executată prin API-ul sistemului care deține datele, iar acesta publică schimbarea ca eveniment nou.
Ramură de excepție: Pas eșuat sau în afara toleranței· Revine la pasul 2
Verificare umană
Agenții nu înregistrează niciodată tranzacții financiare, nu schimbă prețuri sau limite de credit și nu își asumă angajamente față de clienți fără aprobare. Pragurile pe tip de acțiune stabilesc cine aprobă, iar fiecare propunere și decizie este înregistrată.
06
Pasul 6: Facturare, potrivire și încasareSistem
Facturile emise pleacă din ERP ca facturi electronice structurate, conforme EN 16931: cele care intră sub obligația RO e-Factura, prin sistemul național al ANAF, în termen de 5 zile lucrătoare de la emitere; pentru partenerii din alte state membre, prin rețeaua și formatul cerute acolo, de exemplu Peppol. Facturile primite de la furnizori sunt potrivite cu comenzile de achiziție și cu recepțiile, iar stadiul plății de la bancă sau de la procesatorul de plăți închide cronologia.
07
Pasul 7: Analiza fluxului și corectarea cauzelorPersoană
Responsabilii de proces și echipa de integrare analizează la intervale fixe excepțiile pe motive, erorile de interfață și conflictele din datele de referință. Corectează cauza acolo unde se află, într-o înregistrare de date de referință, într-o regulă de toleranță sau într-o corespondență între câmpuri, în loc să rezolve din nou aceeași excepție.
Componente
Ce am construi
01
Strat de integrare bazat pe evenimente
API-uri și evenimente definite mai întâi prin contract între ERP, CRM, magazin online, depozit, transport și contabilitate, specificate în OpenAPI și AsyncAPI, cu plicuri CloudEvents, pe platforma de integrare existentă sau construite nativ în cloud.
Un sistem de referință și un responsabil conveniți pentru fiecare tip de date, reguli de potrivire pentru clienți, furnizori și produse și rapoarte despre dubluri și conflicte pentru cei care răspund de ele.
Cronologia procesului și tablouri de bord pentru flux
Un serviciu care corelează evenimentele într-o singură cronologie pentru fiecare comandă sau solicitare, aplică regulile pentru etape și toleranțe și arată fluxul și excepțiile responsabililor de proces.
O coadă de excepții care arată contextul adunat și propunerea agentului, cu acțiunile aprobare, modificare și respingere și cu pragurile de aprobare aplicate pe tip de acțiune chiar în punctul în care acțiunea se execută.
Facturi conforme SR EN 16931-1 și specificațiilor RO_CIUS, în UBL sau CII, transmise prin RO e-Factura și validate înainte de transmitere cu artefactele publicate de Ministerul Finanțelor, cu facturile respinse direcționate către biroul de excepții; pentru partenerii din alte state membre, rețeaua cerută acolo, de exemplu Peppol.
Monitorizarea stării și alerte pentru fiecare interfață, proceduri de operare pentru echipa de operațiuni și retrimiterea controlată a mesajelor eșuate, implementate ca infrastructură descrisă în cod în tenantul dumneavoastră de cloud.
Comenzi din magazinul online și de pe marketplace-uri
EDI și alte mesaje B2B de comandă
Comenzi de achiziție și confirmări de la furnizori
Solicitări de service și rapoarte de intervenție
Urmărirea transporturilor și evenimente de livrare
Facturi electronice și mesaje de validare
Extrase bancare și notificări de plată
Nucleul soluției
Procese conectate
Sisteme cu care lucrează
SAP S/4HANA pentru vânzări, achiziții și financiarPlatformăSAP
Salesforce Sales, Service și Commerce CloudPlatformăSalesforce
Odoo pentru vânzări, stocuri, achiziții și contabilitatePlatformăOdoo
Platforme de comerț online, marketplace-uri și API-urile transportatorilor
Sisteme de gestionare a depozitului și a transportului
Conexiunea cu RO e-Factura, alte rețele de facturare electronică, bănci și procesatori de plăți
Gestionarea informațiilor despre produse și platforma de date
Controale
Controale prevăzute din proiectare
Limite de acces
Fiecare integrare și agentul rulează sub propria identitate de serviciu în fiecare sistem, limitată la operațiile API de care au nevoie. Agentul poate citi din mai multe sisteme pentru a aduna context, dar poate scrie numai printr-o listă scurtă de acțiuni aprobate, executate prin API-ul sistemului care deține datele și niciodată prin acces direct la baza de date.
Verificare umană
Pragurile de aprobare se stabilesc pe tip de acțiune, împreună cu responsabilul de proces: ce poate agentul doar să propună, ce aprobă un membru al echipei și ce are nevoie de o a doua aprobare. Înregistrările financiare, schimbările de preț și de limită de credit și angajamentele față de clienți așteaptă întotdeauna o persoană. Acțiunile cu impact mic și reversibile, cum ar fi retrimiterea unui mesaj eșuat, pot rula fără aprobare, dacă responsabilul este de acord.
Auditabilitate
Fiecare eveniment, propunere, aprobare, respingere și acțiune executată este înregistrat pe referința comenzii sau a solicitării, cu datele folosite de agent, versiunea modelului și a promptului și persoana care a aprobat. O factură contestată sau o reclamație a unui client poate fi urmărită pas cu pas.
Protecția datelor
Datele de contact ale clienților și furnizorilor ajung numai în sistemele care au nevoie de ele. Cronologia păstrează referințe de business și stadii, nu înregistrări complete, iar jurnalele urmează perioada de păstrare stabilită de dumneavoastră. Prelucrarea rămâne în regiunea convenită.
Transparența IA
Propunerile agentului sunt marcate ca atare în biroul de excepții, cu dovezile și raționamentul afișate alături. Sistemele care dețin datele rămân sursa de referință: cronologia arată ce raportează ele și nu le înlocuiește niciodată.
Indicatori
Ce am măsura
Stabilim acești indicatori împreună cu dumneavoastră în etapa de analiză și luăm valoarea de referință din jurnalele actuale ale sistemelor și interfețelor, înainte de orice schimbare.
Ce am măsura
Indicator
De ce contează
Cum l-am măsura
01Durata ciclului comenzii
De ce conteazăIndicatorul pe care clienții îl observă primul și cel care arată unde așteaptă comenzile.
Cum l-am măsuraTimpul de la primirea comenzii până la livrare și până la plată, pe canal și pe entitate, din evenimentele cronologiei.
02Comenzi fără intervenție manuală
De ce conteazăArată cât din flux rulează pe date curate și pe reguli convenite.
Cum l-am măsuraPonderea comenzilor și a solicitărilor care ajung la încasare fără niciun pas manual și fără excepții, din cronologie.
03Excepții pe motive și timpul de rezolvare
De ce conteazăVă arată ce cauze trebuie corectate mai întâi și dacă biroul de excepții face față.
Cum l-am măsuraVolumul excepțiilor pe cod de motiv și timpul de la detectare până la soluția executată, din jurnalele biroului de excepții.
04Rata de respingere a facturilor electronice
De ce conteazăFacturile respinse întârzie plata și indică de obicei erori în datele de referință sau în corespondența câmpurilor.
Cum l-am măsuraPonderea facturilor electronice emise și primite care sunt respinse, pe motive, din mesajele de validare și de stare primite.
05Erori de interfață și timpul de recuperare
De ce conteazăArată dacă stratul de integrare este fiabil și dacă erorile sunt observate și corectate rapid.
Cum l-am măsuraMesajele eșuate pe fiecare interfață și timpul de la eroare până la retrimiterea reușită, din monitorizarea integrărilor.
06Dubluri și conflicte în datele de referință
De ce conteazăCele mai multe excepții provin din date care diferă între sisteme.
Cum l-am măsuraDublurile deschise și valorile contradictorii pe tip de date și pe sistem, din rapoartele de potrivire.
Nu stabilim ținte înainte de a avea o valoare de referință.
Implementare
Cum l-am pune în funcțiune
Etapa 01
Analiză și harta procesului
Un singur proces, de exemplu order to cash pentru un canal de vânzare, și un singur tip de excepție. Cartografiem sistemele, interfețele, responsabilii de date și felul în care sunt tratate astăzi excepțiile.
Criterii de încheiere
Procesul, sistemele și responsabilii de date cartografiați
Primul tip de excepție și pragurile de aprobare convenite
Valoarea de referință luată din jurnalele actuale
Etapa 02
Integrare și cronologie
API-uri și evenimente documentate pentru sistemele din perimetru și cronologia rulând alături de interfețele existente, fără să le modifice.
Criterii de încheiere
Contractele de evenimente publicate și versionate
Cronologia corespunde sistemelor care dețin datele, pe un eșantion de comenzi
Retrimiterea și procedurile de operare testate
Etapa 03
Pilot pentru biroul de excepții
Agentul propune soluții pentru tipul de excepție ales, iar oamenii aprobă fiecare propunere. Comparăm propunerile cu ce ar fi făcut personalul.
Praguri și persoane care aprobă stabilite pe tip de acțiune
Pista de audit verificată de departamentul financiar și de controlul intern
Etapa 04
Extindere și retragere
Mai multe tipuri de excepții, canale, entități și procese, de exemplu procure to pay, toate pe aceleași contracte. Vechile interfețe punct la punct sunt oprite una câte una.
Criterii de încheiere
Fiecare flux nou pe aceleași contracte și cu aceeași monitorizare
Interfețele înlocuite scoase din funcțiune
Responsabilitatea preluată de echipa dumneavoastră
Comenzi pentru produse realizate la comandă și pentru piese de schimb, din ERP către depozit și transportatori, cu confirmările furnizorilor și facturile electronice potrivite cu comenzile de achiziție.
Cereri de racordare și de instalare la un operator de distribuție sau la o companie de termoficare, urmărite de la comanda de lucru și intervenția pe teren până la factură, cu materiale cumpărate pe bază de contracte-cadru cu furnizorii.
Comenzi de lucru pentru mentenanță, comenzi către subcontractori și facturile acestora, urmărite de la solicitare până la plată, pentru operatori de transport public urban și de terminale logistice.
Procure to pay cu facturile furnizorilor primite de autoritățile contractante prin RO e-Factura, potrivite cu comenzile și recepțiile înainte de plată.
Exemplu ilustrativ
Un producător alimentar care vinde în două țări
Situație
Un producător alimentar vinde către lanțuri de magazine prin EDI, către clienți din HoReCa printr-un magazin online și prin agenți de vânzări, în România și în Bulgaria, din două depozite. Comenzile sunt reintroduse în ERP, transportatorii semnalează problemele de livrare prin e-mail, iar fiecare țară facturează în felul ei.
Sistem
Comenzile, stocurile, expedierile și facturile circulă ca evenimente între magazinul online, ERP, sistemul de depozit și transportatori, iar fiecare comandă are o singură cronologie. Facturile emise de entitatea din România către clienții din țară sunt transmise din ERP prin RO e-Factura, iar cele ale entității din Bulgaria în formatul și pe canalul cerute acolo.
Control uman
Lipsurile de stoc și livrările eșuate ajung într-un singur birou de excepții, unde un agent propune un produs înlocuitor sau o nouă dată de livrare. Echipa de relații cu clienții aprobă fiecare propunere; schimbările de preț și facturile de stornare au nevoie de aprobarea departamentului financiar.
Ce am măsura
Ponderea comenzilor fără intervenție manuală pe țară și pe canal, excepțiile pe motive și timpul de rezolvare, precum și rata de respingere a facturilor electronice pe țară.
România
Un singur proces, mai multe țări și obligații
Grupurile cu filiale în România și în alte state membre rulează adesea aceleași procese order to cash și procure to pay pe instanțe ERP, transportatori și bănci diferite. În România, facturile B2B ale persoanelor impozabile stabilite în țară se raportează prin RO e-Factura în termen de 5 zile lucrătoare de la emitere; în alte state membre obligațiile vin la date diferite, iar pachetul privind TVA în era digitală (ViDA) face din facturarea electronică structurată regula pentru livrările B2B intracomunitare din 1 iulie 2030. Proiectăm un singur strat de integrare, cu formatul și canalul fiecărei țări în spatele acelorași evenimente, astfel încât o obligație nouă înseamnă un conector nou, nu un proces nou.
Regulamentul privind datele, aplicabil din 12 septembrie 2025, stabilește reguli pentru schimbarea furnizorului de servicii de prelucrare a datelor, așa că păstrăm portabile contractele de evenimente și exporturile de date. Agenții din biroul de excepții sunt proiectați ținând cont de Regulamentul IA, iar integrările vin cu acces înregistrat și componente documentate pentru clienții care trebuie să demonstreze securitatea lanțului de aprovizionare potrivit OUG nr. 155/2024.
Nu. ERP-ul, CRM-ul, magazinul online și sistemul de depozit își fac fiecare treaba. Integrăm în jurul acestor sisteme care dețin datele, stabilim ce sistem deține ce date și dăm procesului o singură cronologie peste toate. Acolo unde un sistem vechi de comenzi sau un ERP vechi blochează schimbarea, soluția Modernizarea sistemelor legacy îl pune mai întâi în spatele unor API-uri.
02Înlocuiți middleware-ul de integrare pe care îl avem?
Nu, dacă își face treaba. Construim pe platforma de integrare sau pe brokerul de mesaje pe care îl folosiți deja și adăugăm contracte, monitorizare și retrimitere acolo unde lipsesc. Acolo unde nu există nimic, construim nativ în cloud. Aflați mai multe despre Integrări și API-uri.
03Pot agenții să acționeze singuri?
Numai în pragurile pe care le stabiliți pe tip de acțiune și numai pentru acțiuni cu impact mic, care pot fi anulate, de exemplu retrimiterea unui mesaj eșuat. Înregistrările financiare, prețurile, limitele de credit și angajamentele față de clienți au nevoie întotdeauna de o persoană. Citiți unde au nevoie agenții IA de aprobare umană.
04Cum se încadrează obligațiile de facturare electronică?
În România, operatorii stabiliți în țară transmit prin RO e-Factura facturile către autoritățile și entitățile contractante din 1 iulie 2022, facturile B2B din 1 ianuarie 2024 și facturile B2C din 1 ianuarie 2025, în termen de 5 zile lucrătoare de la emitere. În alte state membre obligațiile vin la date diferite, iar pachetul privind TVA în era digitală (ViDA) face din facturarea electronică structurată regula pentru livrările B2B intracomunitare din 1 iulie 2030. Tratăm factura electronică drept încă un eveniment în proces: emisă din ERP, transmisă prin sistemul sau rețeaua cerută și tratată în biroul de excepții atunci când este respinsă. Citiți ghidul nostru despre facturarea electronică.
05Cum evitați o nouă rețea fragilă de legături punct la punct?
Sistemele publică și consumă evenimente și API-uri documentate printr-un singur strat, nu prin legături directe între ele. Contractele sunt versionate, consumatorii sunt idempotenți, mesajele eșuate pot fi retrimise, iar fiecare flux are un responsabil numit. Un canal nou se abonează la evenimentele existente, în loc să adauge o legătură către fiecare sistem.
06Cum arată un prim perimetru?
Un singur proces și un singur tip de excepție, de exemplu order to cash pentru un canal de vânzare, cu lipsurile de stoc ca primă excepție. Acesta validează evenimentele, cronologia și fluxul de aprobare înainte de a adăuga altceva. Aflați mai multe despre abordarea noastră.
Discutați despre fluxurile de comenzi și facturi
Alegeți un proces și țările în care rulează. Cartografiem împreună sistemele, interfețele și excepțiile și vă propunem o primă versiune care funcționează pentru toate entitățile dumneavoastră.