Integrarea Wolt, Glovo și Bolt cu sistemul ERP: ce se întâmplă cu adevărat cu comenzile tale

Fiecare comandă introdusă manual presupune un risc. Nu neapărat o eroare mare — poate fi un produs greșit, o cantitate incorectă sau o comandă pierdută în fluxul de lucru. La 30–50 de comenzi pe zi de la trei platforme diferite, erorile se acumulează.

Mai important, fără integrare: stocul din sistem nu reflectă în timp real ce s-a vândut prin agregatori, facturile fiscale trebuie create manual, reconcilierea financiară cu platformele devine o operație săptămânală consumatoare de timp, iar analiza vânzărilor pe canal este imposibilă fără export manual din fiecare platformă. În implementările similare, munca administrativă poate ajunge la 2–4 ore zilnic în perioadele de vârf, iar o parte importantă din acest efort dispare după integrare.

Platformele Wolt, Glovo și Bolt pun la dispoziție API-uri prin care trimit comenzile în timp real printr-un mecanism numit webhook. Când un client plasează o comandă, platforma trimite automat datele comenzii — produse, cantități, preț, adresă, comentariul clientului — către serverul tău, fără nicio acțiune manuală.

Aceasta este prima lecție practică: nu toate câmpurile vin în formatul la care te aștepți.

Prețurile vin în unități de bani, nu în lei. O comandă de 45,50 RON poate apărea ca 4550. Sistemul trebuie să facă conversia automat, altfel casierul vede prețuri de 100 de ori mai mari.

Valuta poate apărea diferit dacă setările contului nu sunt aliniate cu ERP-ul. Rezultatul: comenzile pot ajunge cu valuta greșită, fără un mesaj clar de eroare.

Comentariile clienților trebuie mapate explicit. Dacă un client scrie că vrea „fără ceapă”, această informație nu apare în comanda din ERP dacă integrarea nu o transmite în documentul operațional.

SKU-urile produselor trebuie potrivite corect. Wolt, Glovo și Bolt pot avea identificatori proprii de produs, iar dacă aceștia nu sunt mapați cu articolele din ERP, comanda nu poate fi procesată automat.

Una dintre situațiile cel mai des întâlnite în practică: comanda este anulată de platformă sau de client, dar în ERP rămâne activă. Statusul „Rejected” trebuie tradus explicit în logica sistemului ERP. Acest lucru nu se întâmplă automat dacă nu este configurat în integrare.

La fel, dacă anulezi o linie de produs din comanda din ERP, PayDesk nu reflectă automat acea modificare dacă integrarea nu trimite explicit statusul actualizat. Suma de plată poate rămâne calculată cu produsul anulat, ceea ce duce la erori în încasare.

Comportamentul corect: când o linie este anulată în comanda ERP, sistemul trebuie să recalculeze automat totalul și să actualizeze documentul din PayDesk înainte de fiscalizare.

Dacă în ERP creezi un document de modificare a prețului cu o dată de intrare în vigoare viitoare, sistemul nu trebuie să îl trimită imediat către platformă, pentru că există riscul ca prețul să fie aplicat înainte de termen. Soluția corectă este ca ERP-ul să creeze o sarcină programată și să trimită modificarea abia în ziua aplicării, sau să gestioneze separat prețul curent și prețul viitor.

Dacă ai mai multe liste de prețuri, de exemplu una pentru Wolt, una pentru Glovo și una pentru vânzare directă, sistemul trebuie să sincronizeze cu fiecare platformă doar modificările din lista corespunzătoare. Altfel, orice modificare de preț poate declanșa schimburi de date cu toți agregatorii, chiar dacă nu este relevantă pentru toate canalele.

Dacă vinzi un produs cu prețul per kilogram, dar platforma afișează produsul per ambalaj, de exemplu pachet de 500 g, sistemul trebuie să calculeze și să transmită automat prețul per ambalaj. Maparea trebuie să facă această conversie corect în ambele direcții.

Pentru comenzile primite prin Wolt, Glovo sau Bolt, logica fiscală trebuie tratată separat de fluxul operațional al comenzii. Integrarea trebuie să poată diferenția între comenzile pentru care se emite doar bon fiscal și situațiile în care este necesară emiterea unei facturi și transmiterea acesteia în sistemul RO e-Factura.

În practică, sistemul trebuie să permită marcarea comenzilor pentru care nu se trimite factură în RO e-Factura și să ofere o procedură clară pentru cazurile în care clientul solicită factură. Pentru aceste situații, datele clientului trebuie colectate corect, factura trebuie emisă din ERP, iar apoi transmisă prin fluxul e-Factura.

Important: regulile privind RO e-Factura trebuie verificate înainte de implementare în funcție de tipul clientului, tipul tranzacției și legislația aplicabilă la momentul respectiv. Conform Ministerului Finanțelor, transmiterea facturilor în sistemul RO e-Factura în relația B2C este obligatorie începând cu 01.01.2025, iar ANAF tratează separat regimul pentru relațiile B2B/B2G și B2C.