Cinci feluri în care integrările ERP eșuează în tăcere

O integrare rareori eșuează zgomotos în prima zi. Eșuează tăcut, luni mai târziu, iar cineva află de la un client. Acestea sunt cele cinci tipare pe care le vedem cel mai des când suntem chemați să reparăm una.

1. Fără idempotență, deci reîncercările creează duplicate

Secvența clasică: magazinul trimite o comandă către ERP, ERP-ul este lent, apelul expiră, magazinul reîncearcă — iar ERP-ul crease deja comanda. Acum sunt două. Soluția nu este un timeout mai lung. Este o cheie de idempotență: fiecare mesaj poartă o referință externă unică, receptorul o stochează, iar o a doua livrare a aceleiași chei returnează rezultatul original în loc să creeze ceva.

Această singură decizie de proiectare elimină o categorie întreagă de incidente și trebuie să existe de la început, pentru că adăugarea ei ulterioară înseamnă reconcilierea duplicatelor deja create.

2. Cuplare sincronă, deci un sistem lent îl blochează pe altul

Dacă checkout-ul așteaptă ca ERP-ul să confirme o comandă, atunci o fereastră de mentenanță a ERP-ului devine o pană a magazinului tău. Pune o coadă între ele. Magazinul scrie în coadă și răspunde imediat; un worker livrează către ERP, cu reîncercări și backoff. Clientul nu vede niciodată disponibilitatea ERP-ului.

Același lucru se aplică invers la actualizările de stoc: împingerea sincronă a patruzeci de mii de actualizări de SKU într-un magazin web, în timpul programului, va face rău ambelor sisteme.

3. Erori care nu au unde să ajungă

Un număr surprinzător de integrări scriu erorile într-un fișier pe care nu-l citește nimeni. Când ERP-ul începe să respingă comenzi pentru că s-a schimbat un câmp obligatoriu, nimeni nu află. Trei săptămâni mai târziu, financiarul observă un gol.

Observabilitatea minimă viabilă: adâncimea cozii, rata de erori și ultima sincronizare reușită pe fiecare flux, într-un tablou de bord, cu o alertă care ajunge la un om. Dacă un mesaj își epuizează reîncercările, locul lui este într-o coadă dead-letter pe care o revizuiește cineva zilnic — nu într-o linie de log.

4. Mapare care ignoră cazurile incomode

Maparea câmpurilor se scrie de obicei după drumul fericit. Apoi producția livrează restul: livrări parțiale, note de credit, comenzi cu cote de TVA mixte, clienți care există de două ori în ERP, discounturi pe care magazinul le aplică pe linie și ERP-ul pe document, retururi care sosesc înainte ca factura să fi fost înregistrată.

Leacul este plictisitor și eficient — iei un eșantion de date istorice reale, inclusiv cazurile ciudate, îl parcurgi prin mapare cu oamenii din ambele departamente și scrii regulile pe care nu le documentase nimeni. Este cea mai ieftină săptămână din tot proiectul.

5. Fără reconciliere, deci deriva se acumulează

Chiar și o integrare bine construită va rata la un moment dat ceva: un mesaj pierdut într-un incident de infrastructură, o înregistrare editată direct într-un sistem, o corecție manuală care nu s-a propagat. Fără un job de reconciliere, acea derivă se acumulează tăcut.

O comparație nocturnă — număr și valori de comenzi, cantități de stoc pe SKU, starea facturilor — care fie corectează automat, fie ridică o excepție, nu este o muncă spectaculoasă, dar transformă „sistemele sunt de acord” dintr-o speranță într-un fapt verificat în fiecare dimineață.

O notă despre conformitatea din România

Dacă integrezi în România, transmiterea e-Factura prin SPV-ul ANAF merită același tratament ca orice alt flux: transmitere idempotentă, răspuns stocat, interogarea stării, reîncercări și o coadă vizibilă de documente care au picat validarea. Cea mai frecventă eroare pe care o vedem este tratarea ei ca pe un upload de tip „trimite și uită”, urmată de descoperirea peste câteva săptămâni că un lot a fost respins.