Personalizarea SAP Business One, de la configurare la module proprii

O firmă din Cluj care vinde pe bază de contracte-cadru, o fabrică din Prahova cu rețete variabile, un distribuitor din București care cere aprobări pe fiecare reducere: toate vor, mai devreme sau mai târziu, ca ERP-ul să se potrivească cu felul lor de lucru. Dezvoltarea SAP Business One răspunde exact acestei cereri, dar nu înseamnă același lucru de la un proiect la altul. Uneori este o oră de configurare, alteori un modul întreg scris special.

Pagina de față explică ce nivele de personalizare există, ce impact are fiecare asupra actualizărilor și cum judecați un dezvoltator sau un integrator înainte să semnați. Dacă încă nu ați ales produsul, începeți cu prezentarea generală a modulelor SAP Business One, apoi reveniți aici.

Cele patru nivele ale personalizării SAP Business One

Regula utilă în orice proiect: mergeți de jos în sus. Fiecare nivel costă mai mult în întreținere decât cel dinainte.

Nivelul unu: parametrarea standard

Înainte de orice discuție despre cod, verificați dacă nevoia nu se rezolvă cu setările existente. Multe cerințe care par „speciale” sunt, de fapt, o combinație de parametri, grupuri de articole, liste de prețuri și drepturi de acces. O parte din această muncă se face în faza de implementare a proiectului, dar o analiză onestă la început evită zeci de ore de dezvoltare inutilă.

Nivelul doi: instrumentele de personalizare incluse

Cursul de implementare publicat de SAP Learning prezintă ca instrumente de personalizare câmpurile (UDF), tabelele (UDT), obiectele (UDO) și valorile (UDV) definite de utilizator, plus interogările SQL, alertele și fluxurile de aprobare. În practică:

• Câmpuri proprii: adăugați pe o factură, pe o fișă de client sau pe un articol informația pe care o cere contabilul sau comercialul dvs., de pildă un cod intern, o condiție de livrare sau un punct de lucru.
• Tabele și obiecte proprii: țineți în sistem date pentru care standardul nu are loc, fără foi Excel paralele.
• Interogări SQL: extrageți exact lista de care aveți nevoie, fără să cereți o dezvoltare.
• Alerte: primiți un mesaj când o comandă depășește un prag sau când un termen de plată se apropie.
• Fluxuri de aprobare: o reducere peste o limită sau o comandă de achiziție mare trece prin persoana potrivită înainte de confirmare.

Acest nivel acoperă, în multe firme mici și mijlocii, cea mai mare parte a diferenței dintre „standard” și „cum lucrăm noi”. Un integrator bun vă va propune să epuizați acest nivel înainte să vorbiți despre programare.

Extensii existente: nu reinventați ce există

SAP indică, într-un articol din decembrie 2025, un ecosistem de 850 de parteneri și peste 500 de extensii sectoriale și pe țară pentru SAP Business One. Prezentarea Integration Framework vorbește și ea de peste 500 de soluții ale partenerilor. Concluzia pentru dvs.: înainte să comandați un modul nou, întrebați dacă există deja o soluție pentru sectorul dvs.

O extensie existentă aduce avantaje reale: a fost folosită de alte firme, are o documentație și este întreținută de un furnizor. Are însă și limite. Trebuie să verificați cine o actualizează după fiecare versiune, ce se întâmplă dacă furnizorul dispare și dacă se potrivește cu particularitățile românești. Pentru contextul local, vedeți și pagina despre SAP Business One în România: obligații precum RO e-Factura, SAF-T (D406) sau RO e-Transport se confirmă cu integratorul, nu se presupun.

Dezvoltare specifică: când se justifică și cu ce instrumente

Cazurile în care are sens un modul la comandă sunt, de obicei, aceleași:

1. un proces comercial care vă diferențiază de concurență și pe care nu vreți să-l alterați;
2. o legătură cu un sistem extern (magazin online, aplicație de teren, echipament, platformă de transport);
3. un ecran sau un calcul care revine zilnic și face pierdere de timp mare dacă rămâne manual;
4. un raport reglementat sau cerut de un client mare, pe care nicio extensie nu îl produce.

Service Layer: calea modernă

Service Layer este API-ul de extensie al SAP Business One. Conform ghidului SAP, este un API REST bazat pe HTTP și OData, cu schimburi în format JSON. Documentul acceptă OData v3 prin /b1s/v1/$metadata și OData v4 prin /b1s/v2/$metadata. SAP Learning adaugă faptul că implementează schemele de autentificare Basic și OAuth și că urmărește să ușureze dezvoltarea de aplicații web și mobile.

Ce rezultă practic pentru dvs.:

• orice dezvoltator care știe să lucreze cu servicii web poate construi o aplicație care citește sau scrie date în SAP Business One;
• Service Layer rulează pe SUSE Linux Enterprise și pe Microsoft Windows și poate fi instalat în mod integrat sau distribuit, cu Apache ca repartitor de sarcină;
• împarte cu DI API aceleași definiții de obiecte, prin componenta DI Core, deci regulile de validare ale aplicației se aplică și datelor care intră pe această cale.

Ultimul punct contează mult: un modul care trece prin interfața oficială respectă regulile sistemului, în timp ce o scriere directă în baza de date le ocolește.

SDK, add-on-uri și Integration Framework

SDK-ul rămâne instrumentul pentru extensiile care se integrează în aplicația clientului. Ghidul de licențiere SAP precizează că licențele de utilizator includ automat, fără cerere separată, SDK-ul în versiune de implementare, SDK Tools, SAP AddOns, licența de compatibilitate pentru add-on-uri și Workflow. Nu plătiți deci separat instrumentele, ci munca celui care le folosește.

Integration Framework, descris de SAP ca parte integrantă a produsului, utilizabilă local sau în cloud, servește ca mediu de dezvoltare și execuție pentru scenarii de integrare: tablouri de bord, aplicații mobile, salarizare externalizată, cerere automată de ofertă, servicii web, aplicații SAP și non-SAP. Dacă proiectul dvs. e în principal o legătură între sisteme, ar trebui să citiți și pagina despre integrări și conectori.

SAP Learning prezintă produsul ca pe un nucleu ERP gândit pentru extindere, îmbogățit cu inteligență artificială, învățare automată și servicii cloud din SAP Business Technology Platform (BTP), cu modele de automatizare accesibile prin Business Accelerator Hub și SAP Build. Pentru o PMM românească, aceste servicii sunt de obicei o a doua etapă, nu o condiție de pornire.

Impactul asupra actualizărilor

Aici se plătește sau se câștigă adevăratul preț al personalizării. Principiul este simplu: cu cât vă abateți mai puțin de la standard, cu atât o versiune nouă se aplică mai ușor.

• Configurarea și câmpurile proprii, făcute prin instrumentele oficiale, trec în general fără probleme, dar se verifică.
• O extensie a unui partener depinde de compatibilitatea declarată de furnizor pentru versiunea țintă.
• Un modul specific scris pe interfețele oficiale se retestează, iar ce nu mai funcționează se corectează.
• O intervenție directă în baza de date este cea mai fragilă: poate funcționa azi și se poate opri după o actualizare, fără ca nimeni să știe de ce.

Înainte de a trece la o versiune nouă, cereți integratorului lista tuturor personalizărilor, cu proprietarul fiecăreia. Informații despre ediții și cicluri de versiune găsiți în pagina despre versiunile SAP Business One.

Bune practici: rămâneți la standard, documentați, testați

Rămâneți cât mai aproape de standard

Fiecare personalizare este o promisiune de întreținere pe termen lung. Înainte de a o accepta, puneți trei întrebări: ce problemă de afaceri rezolvă, cine o folosește și ce se întâmplă dacă renunțăm la ea. Dacă răspunsul la prima este vag, este un semn bun să renunțați. Uneori e mai ieftin să schimbați procesul intern decât să adaptați sistemul.

Documentați de la început

Pentru fiecare câmp, interogare, alertă, flux sau modul, cereți o fișă scurtă: scop, autor, dată, obiecte atinse, mod de testare. Fără ea, cunoașterea rămâne în capul unui singur om, iar plecarea lui blochează proiectul. Cerința aceasta se pune în caietul de sarcini și în contract, nu la final.

Testați pe un mediu separat

Nicio personalizare nu se trece direct în producție. Cereți un mediu de test cu date reale anonimizate, scenarii scrise cu utilizatorii (contabilul, magazionerul, agentul comercial) și o semnătură de recepție. Același mediu servește la fiecare actualizare viitoare.

Cereți predarea codului și a accesului

Contractul trebuie să spună clar cine deține codul sursă, unde este stocat și ce se întâmplă dacă schimbați furnizorul. Fără aceste clauze, rămâneți dependent de o singură firmă pentru lucruri pe care le-ați plătit dvs.

Cum evaluați un dezvoltator sau un integrator SAP Business One

Nu căutați cel mai mare portofoliu, ci cea mai bună potrivire cu nevoia dvs. Câteva criterii verificabile:

• Începe cu analiza, nu cu oferta. Un partener care propune cod fără să fi înțeles procesul vă va face o factură lungă.
• Arată o referință comparabilă, într-un sector apropiat, pe care o puteți vizita sau apela.
• Explică alternativa fără cod. Dacă nu vă spune niciodată „aici nu merită dezvoltare”, ceva nu e în regulă.
• Lucrează prin interfețele oficiale și vă spune cum le folosește.
• Descrie testarea și predarea: mediu de test, documentație, instruire a utilizatorilor, ghid pentru administrator.
• Cunoaște contextul românesc: contabilitate, ANAF, facturare electronică, relația cu contabilul firmei.
• Prevede suportul de după lansare, inclusiv retestarea la actualizări; detalii în pagina despre suport și mentenanță.

Ghidul nostru despre alegerea unui partener SAP Business One dezvoltă aceste criterii. Dacă aveți deja un proiect cu personalizări multe și rezultate slabe, un audit al proiectului ajută să separați ce merită păstrat de ce trebuie refăcut.

Cum vă ajutăm să găsiți dezvoltatorul potrivit

Integrator ERP este un serviciu gratuit de punere în legătură. Nu facem noi dezvoltarea și nu suntem afiliați la niciun editor: descrieți proiectul, iar noi vă punem în legătură cu un integrator ERP certificat care are experiență pe nevoia dvs. și lucrează în regiunea sau sectorul potrivit. Apoi comparați propunerile după criteriile de mai sus, fără obligație.

Pentru o cerere bună, pregătiți trei lucruri: procesele pe care vreți să le păstrați, cele pe care sunteți dispus să le schimbați și sistemele cu care ERP-ul trebuie să comunice. Cu aceste informații, discuția cu orice partener devine concretă de la primul apel.

Numele programelor menționate sunt mărci ale editorilor respectivi și apar doar cu titlu informativ. Acest site este independent și nu este afiliat niciunui editor.