Integrare SmartBill cu ERP și magazinul online (și Oblio, FGO): cine ține stocul

Stocul stă în WinMentor sau în Saga. Facturile ies din SmartBill, prin pluginul din WooCommerce, când comanda trece în „Finalizată”. Prețurile le schimbă cineva de mână în magazin, iar pe eMAG Marketplace stocul se editează separat, din alt ecran. Rezultatul: trei stocuri, două liste de prețuri și nimeni care să știe sigur care e cea corectă, până la inventar.

O integrare de felul ăsta nu se strică pentru că lipsește un plugin. Se strică pentru că nimeni n-a hotărât ce program are ultimul cuvânt pentru preț, stoc și client. Partea incomodă e că API-urile programelor de facturare hotărăsc oricum în locul tău. Oblio n-are un endpoint, adică o comandă din API, pentru crearea produselor, iar API-ul V1 al SmartBill le creează doar odată cu factura. De aceea, la o firmă care are ERP, stocul și prețul trebuie să stea în ERP, iar SmartBill, Oblio sau FGO rămân emitent de facturi și poartă spre SPV.

Ce poate citi și ce poate scrie fiecare API

Un API e ușa prin care un alt program citește sau scrie date fără să intervină un om. Fiecare dintre cele trei programe are una, dar ușile nu sunt la fel de late. Mai jos găsești, pe tipuri de date, ce spune documentația oficială a fiecăruia, așa cum arăta pe 2 noiembrie 2026. Unde documentația publică nu spune nimic, am scris asta, nu am ghicit.

La SmartBill am căutat în referința API și în articolele de ajutor despre integrare. Indexul referinței listează resursele, dar nu spune dacă resursele V3 permit scriere, ce câmpuri de preț există și dacă factura pleacă în SPV printr-un apel separat. Le-am trecut, cu celelalte necunoscute, în lista de întrebări pentru furnizor de la finalul articolului.

Citit pe orizontală, tabelul spune un lucru simplu: factura și încasarea circulă bine în toate trei programele, catalogul și recepția nu. Prin API-ul V1, SmartBill adaugă produse și clienți noi „prin simpla inserare a unei facturi sau proforme”. Referința mai listează o versiune V3, cu gestiuni, produse, clienți, furnizori, cote TVA și NIR-uri. La Oblio, produsele cu stoc, clienții, gestiunile, seriile și cotele de TVA au doar endpointuri de citire, iar lista completă nu conține nici creare de produs, nici recepție.

Oblio scrie totuși ceva în catalog, pe ușa din spate. La emiterea facturii, câmpul save al produsului salvează prețul de listă și e activ din oficiu, iar câmpul save de la client îi poate modifica datele. Dacă nu știi asta, o factură emisă din magazin cu un preț promoțional poate rescrie prețul de listă din Oblio. Încasarea se poate scrie direct, cu parametrul collect la emitere sau separat, pe lângă webhookul de încasare.

Fiecare program iese în față la altceva. FGO v2 are o resursă pentru facturile primite de la furnizori, pe care le poate citi și înregistra, iar resursa de facturi acoperă emiterea, stornarea, anularea și e-Factura. Versiunea v1 e depreciată, deci orice integrare nouă pornește pe v2. Oblio are webhookuri, adică notificări trimise singur către programul tău când se schimbă stocul, când se anulează o factură sau când intră o încasare. Mai are o cheie unică la emitere, care împiedică dublarea facturii la reîncercare.

Prețul de vânzare e zona cea mai cețoasă. ContentSpeed scrie în fișa modulului lor SmartBill: „Preturile produselor se vor seta manual in magazinul online”. Afirmația e sigură pentru modulul lor, nu neapărat pentru API-ul SmartBill în sine.

Regula care ține integrarea în picioare: un singur stăpân pentru fiecare dată

Stăpânul unei date e programul în care un om are voie s-o modifice. Celelalte programe primesc doar copia și n-o schimbă. Sună birocratic, dar e singurul fel în care trei programe pot avea același stoc fără ca cineva să-l corecteze de mână în fiecare.

• ERP-ul (WinMentor, Saga, Nexus sau altul): catalogul, prețul și stocul.
• Magazinul online: comanda și datele de livrare ale clientului.
• Programul de facturare: factura, încasarea și trimiterea în SPV.
• eMAG Marketplace și celelalte canale: doar citesc stocul și prețul din ERP.

Invers nu merge, și motivul principal nu ține de API. Stocul se schimbă la recepție, la NIR, la retur și la inventar, iar la o firmă cu ERP toate astea se fac deja în ERP, de către gestionar. Chiar acolo unde API-ul programului de facturare are resursă de produse, cum e cea de articole din FGO sau resursa de produse din SmartBill V3, a muta stocul în programul de facturare înseamnă a dubla munca gestionarului sau a-l obliga să schimbe programul. La Oblio întrebarea nici nu se pune: API-ul nu creează produse, doar salvează prețul de listă la emiterea facturii.

Fără ERP, programul de facturare cu gestiune poate fi stăpânul stocului, cu o condiție: sincronizarea spre magazin să fie completă, nu doar la produsele care s-au mișcat. eMAG merită o frază separată. Dacă stocul de acolo se editează de mână, ai creat al treilea adevăr, iar o comandă pe un produs pe care nu-l mai ai devine o chestiune de timp.

Diagrama de mai jos arată drumul unei comenzi cu împărțirea de mai sus. Stocul se rezervă în ERP imediat ce comanda intră, nu abia după încasare: la ramburs pot trece zile, iar între timp același produs s-ar putea vinde pe eMAG. Pluginul oficial SmartBill emite factura la schimbarea statusului comenzii, iar Oblio trimite factura în SPV prin API doar pentru facturile emise în Oblio. Omul rămâne în două locuri: la factura respinsă de SPV și la rambursul încasat de curier.

Unde se rupe sincronizarea fără să afli

Cel mai neplăcut risc e documentat chiar de SmartBill. La sincronizarea stocului cu WooCommerce, „Un stoc va fi trimis doar daca el sufera o modificare”, iar la activare nu pleacă nimic spre magazin. Exemplul din documentație: din 100 de produse, după 5 facturate și 5 recepționate, doar 10 primesc stocul nou. Celelalte 90 rămân cu ce aveau în site.

Pe un catalog real, efectul crește. Să luăm, ca exemplu ilustrativ, un magazin cu 2.000 de produse, din care 300 se vând sau se recepționează într-o lună. Celelalte 1.700 de produse rămân în site cu stocul de la ultima lor mișcare, care poate fi de acum câteva luni. Remediul e banal, dar trebuie știut: o preluare completă la activare și o reconciliere periodică, programată.

A doua ruptură e potrivirea produselor. Documentația spune că „Modulul SmartBill va identifica produsele dupa cod sau dupa denumire”, adică după codul de produs sau, dacă lipsește, după denumirea identică. Un spațiu în plus sau o denumire scurtată în ERP și legătura nu se mai face, sau se face cu produsul greșit. E aceeași problemă care strică și fișierul D406; am scris separat despre datele de bază care fac și SAF-T-ul să pice.

Apoi sunt condițiile scrise mărunt. Sincronizarea automată din pluginul WooCommerce cere server Apache și directiva SetEnvIf Authorization în configurare, deci pe alt tip de server trebuie verificat dinainte că stocul chiar ajunge. În Gomag, opțiunea funcționează doar la produsele cu „Gomag gestioneaza automat stocul produsului” bifat. În MiniCRM, stocul se actualizează imediat după o factură emisă din MiniCRM. Mișcările făcute în altă parte, o recepție sau o vânzare pe alt canal, ajung însă o dată la 24 de ore dacă nu activezi webhookul. Până atunci, poți vinde ce nu mai ai.

Ultima ruptură vine din lege. Prin Legea 141/2025, din 1 august 2025 cota standard de TVA a trecut de la 19% la 21%, iar cota redusă a devenit 11%. Cotele trebuiau schimbate identic în ERP, în magazin și în programul de facturare. Dacă una rămâne în urmă, factura emisă prin API iese cu altă valoare decât comanda plătită de client.

Black Friday, calculat: limitele de apeluri și de documente

Limitele de apeluri par un detaliu de programator până în ziua în care comenzile se triplează. SmartBill acceptă 3 apeluri pe secundă, iar documentația adaugă: „In caz de abatere, se blocheaza accesul timp de 10 minute.” Trei apeluri pe secundă înseamnă 10.800 pe oră, destul pentru facturi. Problema e scriptul scris neatent: un al patrulea apel în aceeași secundă blochează tot, iar timp de 10 minute nu ies nici facturile comenzilor noi.

Un calcul de verificat: dacă o resincronizare citește câte un produs pe apel, 5.000 de produse / 3 apeluri pe secundă = 1.667 de secunde, adică circa 28 de minute. Dacă API-ul permite citirea în bloc, timpul scade mult.

Oblio are două limite: 30 de cereri la 100 de secunde pentru cererile care generează documente și 30 de cereri la 10 secunde pentru restul. Pentru facturi, asta dă 0,3 documente pe secundă, adică cel mult 1.080 de facturi pe oră. Dacă integrarea a stat jos o zi și ai 2.000 de comenzi nefacturate, recuperarea durează 2.000 / 30 × 100 s ≈ 6.667 s, adică o oră și 51 de minute, doar pentru emitere. Citirea catalogului e, în schimb, rapidă: produsele vin câte 250 pe pagină, deci 5.000 de produse înseamnă 20 de cereri.

La FGO am găsit limite publicate doar pentru arhivele PDF: un apel la 5 secunde pe firmă la verificarea limitelor și la citirea stadiului arhivei, plus un apel la 30 de secunde la crearea ei, cu răspuns 429 la depășire. Specificația precizează că limitele se pot modifica, iar pentru restul API-ului v2 nu publică nicio cifră. Dacă vinzi sezonier, asta e prima întrebare pentru FGO.

Plasa de siguranță e termenul legal. Factura trebuie transmisă în RO e-Factura în 5 zile lucrătoare de la emitere, conform art. 10 din OUG 120/2021, în forma modificată prin OUG 89/2025 și aplicabilă din 1 ianuarie 2026. Obligația acoperă și facturile către persoane fizice, din 1 ianuarie 2025. Dacă și facturile primite îi ocupă contabilului zilele, vezi unde se pierd orele după descărcarea din SPV.

Aici contează cheia unică de la Oblio. Când o factură nu primește răspuns și integrarea reîncearcă, cheia împiedică emiterea aceleiași facturi de două ori. Unde nu există un mecanism echivalent, integrarea trebuie să verifice singură, înainte de reîncercare, dacă factura n-a ieșit totuși.

Cât costă integrarea, cu tot cu orele pe care le economisește

Ca să compari corect, pune unul lângă altul abonamentul, documentele peste plafon și orele de retastare. Exemplul de mai jos e ilustrativ: un magazin cu 1.500 de comenzi pe lună, fiecare cu o factură emisă prin API. Presupunem că doar facturile se numără ca documente.

La SmartBill, pluginul și API-ul pentru magazin merg pe pachetele Platinum, Gestiune Plus și Ecommerce. Pagina de prețuri arată 700 de documente API incluse la un plan și 1.000 la pachetul cu gestiune, iar pachetele Ecommerce și Ecommerce Gestiune includ 3.000 pe lună. Din pagină nu reiese limpede care plafon îi revine lui Platinum și care lui Gestiune Plus, așa că dăm ambele variante. Peste plafon, fiecare document costă 0,017 € + TVA. La plafonul de 700: (1.500 − 700) × 0,017 € = 13,60 € + TVA pe lună, adică 16,46 € cu TVA de 21%. La plafonul de 1.000: 500 × 0,017 € = 8,50 € + TVA, adică 10,29 € cu TVA. Pe Ecommerce, cele 1.500 de facturi încap în plafon, deci nu plătești nimic peste.

Sumele sunt mici. Ce merită urmărit e soldul: depășirea se scade din credite, la 1 credit = 0,01 € + TVA, iar creditele nu trebuie să se termine în mijlocul unei campanii. Ai grijă și la ce include pachetul. Pagina de pluginuri SmartBill, care descrie o versiune mai veche a modulului, spune că sincronizarea stocului e disponibilă doar pe pachetul Ecommerce.

La FGO, GO Premium costă 57 de lei pe lună, cu 1.200 de automatizări pe an, stocuri, NIR, eMAG, WooCommerce și API. GO Enterprise costă 140 de lei pe lună, cu 3.600 de automatizări pe an și 0,10 lei pentru fiecare automatizare peste limită. Toate prețurile sunt fără TVA, iar pe an dau 57 × 12 = 684 de lei, respectiv 140 × 12 = 1.680 de lei. Pagina nu spune ce înseamnă o automatizare. Lângă plafon apar trimiterea automată în SPV, preluarea e-Facturilor de furnizor, potrivirea bancară, facturile recurente și e-mailul automat, deci o factură emisă și trimisă automat poate consuma mai multe automatizări.

Ca estimare minimă, dacă fiecare factură ar consuma o singură automatizare, magazinul din exemplu ar depăși plafonul GO Enterprise cu 18.000 − 3.600 = 14.400 de automatizări pe an. La 0,10 lei bucata, rezultă cel puțin 1.440 de lei pe an + TVA, peste abonament. Dacă factura și trimiterea ei în SPV se numără separat, suma se poate dubla.

Oblio costă 29 € pe an, cu facturi nelimitate și cu stocurile, e-Factura, e-Transport și SAF-T incluse. Pagina nu spune dacă suma include TVA. Fără nicio integrare, costul se mută în ore. Să luăm un magazin mai mic, cu 40 de comenzi pe zi, 3 minute de retastare pe comandă (client, produse, factură) și un cost de 40 de lei pe oră cu tot cu taxele; toate trei sunt ipoteze ale exemplului. Calculul dă 40 × 3 = 120 de minute pe zi, × 21 de zile lucrătoare = 42 de ore pe lună, × 40 de lei = 1.680 de lei pe lună.

Pe abonament, cele trei programe pornesc de la 29 € pe an la Oblio și ajung la 1.680 de lei + TVA pe an la GO Enterprise, cu SmartBill de la 195,84 € + TVA. Diferența dintre un API care înregistrează facturi de furnizor și unul care nu le vede deloc se măsoară însă în orele contabilului, lună de lună. Programul de facturare se alege după ce permite API-ul lui, nu după preț.

Plugin, integrare la comandă sau roluri schimbate: cum alegi

Din tabelul de la început și din regula stăpânului ies trei variante. Niciuna nu e bună pentru toată lumea, iar cea mai scumpă nu e automat cea corectă.

Pluginul gata făcut

Merge când nu ai ERP, nu vinzi pe marketplace, catalogul e mic, iar stocul și prețul le ții într-un singur loc. Costul e abonamentul care include API și, dacă vrei stocul sincronizat, pachetul care include această funcție. Ce poate merge prost: sincronizarea e mai ales într-un singur sens, stocul pleacă doar la produsele cu mișcare, iar suportul SmartBill pentru API și pluginuri, scrie chiar în documentație, „se realizeaza doar prin email”. Dacă pluginul ajunge să fie mai multă bătaie de cap decât platforma care îl găzduiește, merită privit și un magazin cu integrările construite direct în el.

Integrarea la comandă, prin API

Are sens când ai ERP (WinMentor, Saga, Nexus), vinzi și pe eMAG și treci de câteva sute de comenzi pe lună. O integrare făcută bine are o coadă care reîncearcă facturile căzute și respectă limitele de apel ale fiecărui program. Mai ține un jurnal cu fiecare document și trimite o alertă când o factură n-a ieșit sau a fost respinsă în SPV. La e-data, asta e partea în care legăm ERP-ul, magazinul și programul de facturare: datele vechi se curăță întâi, iar conflictele ajung la un om.

Cum arată o sincronizare completă, nu doar la produsele mișcate, se vede la theBitSmith. Acolo nu e vorba de un ERP legat de un program de facturare, ci de catalogul distribuitorului NOD, importat în magazinul construit pe Medusa. Sunt 5.445 de produse importate automat, cu stocul și prețurile actualizate pentru tot catalogul de 4 ori pe zi, la 05, 11, 17 și 23. Principiul e același pe care îl cerem de la orice sincronizare de stoc: fiecare rulare trece prin tot catalogul.

Rolurile schimbate

Factura rămâne în SmartBill, Oblio sau FGO, dar stocul și prețul se mută în ERP, iar programul de facturare devine doar emitent. Poate fi cea mai ieftină cale de a scăpa de trei stocuri, pentru că nu schimbi niciun program, schimbi doar cine are voie să modifice ce. Oblio declară integrare cu Saga, WinMentor și Ciel, deci în unele combinații legătura spre contabilitate există deja. La Oblio, dezactivează salvarea prețului de listă la emitere, ca factura să nu rescrie prețul ținut în ERP.

Un flux simplu, fără ERP, arată ca la DanBlocks, unde am construit magazinul de produse digitale: plata, factura Oblio și linkul produsului pleacă singure, cu 0 pași manuali la o vânzare. Acolo programul de facturare intră într-un singur pas al fluxului: emite factura după plată. Spunem deschis și ce n-am face: n-am construi o integrare la comandă pentru un magazin cu 50 de comenzi pe lună și fără ERP. Acolo pluginul plus o reconciliere săptămânală a stocului ajung.

Înainte să conectezi ceva: lista de verificare

Lista se face cu contabilul și gestionarul la masă, înainte de orice plugin sau ofertă. Fiecare punct se bifează sau nu; „cred că da” nu contează ca bifă. Penultimul punct strânge tot ce documentația publică a furnizorilor n-a lămurit în articolul de față.

Dacă după listă nu e clar ce program ar trebui să fie stăpânul stocului, al prețului și al facturii la tine, cere evaluarea gratuită a integrării dintre ERP, magazin și programul de facturare. Pornim de la programele pe care le ai deja, iar prețul și etapele le primești fix, în scris.