Personalizarea Business Central: de la parametrare la module la comandă

Dezvoltarea în Business Central are o reputație dublă: pentru unii este libertatea de a adapta ERP-ul la firma lor, pentru alții este originea unor actualizări dureroase și a unor costuri care scapă de sub control. Ambele reputații sunt meritate, în funcție de cum se face. Această pagină vă ajută să separați ce se rezolvă fără cod de ce cere într-adevăr o dezvoltare, și să judecați calitatea celor care vă propun să o facă.

Dacă încă comparați produse, începeți cu pagina despre Business Central în România; aici presupunem că ați ales deja platforma sau că o evaluați serios.

Personalizare, parametrare, dezvoltare: aceleași cuvinte, lucruri diferite

În discuțiile cu furnizorii, termenii se amestecă, iar confuzia costă. Merită să-i despărțiți de la început.

• Parametrarea înseamnă să folosiți ce există: planul de conturi, seriile de numere, grupurile contabile, fluxurile de aprobare, rolurile și vederile fiecărui utilizator. Nu produce cod și se păstrează la actualizări.
• Configurarea interfeței înseamnă să rearanjați paginile, să ascundeți câmpuri, să adăugați câmpuri proprii pe o pagină. Designerul integrat în client permite acest lucru prin glisare și plasare, cu previzualizare, fără a părăsi aplicația.
• Extensiile existente sunt aplicații instalate din Microsoft Marketplace. Sunt scrise de alții, au propriul ciclu de versiuni și rezolvă nevoi frecvente.
• Dezvoltarea specifică este codul scris pentru firma dumneavoastră, ca extensie proprie.

Regula practică: coborâți pe această scară doar când treapta de sus nu mai acoperă nevoia. Fiecare treaptă în jos aduce mai multă flexibilitate, dar și mai mult de întreținut.

Ce se poate rezolva fără să scrieți cod

Mulți directori cer „un modul la comandă” pentru ceva ce parametrarea acoperă deja. Înainte de orice ofertă de dezvoltare, cereți integratorului să demonstreze, în sandbox, că nevoia nu poate fi acoperită standard.

Cazuri frecvente la IMM-urile din România care se rezolvă adesea fără cod:

• fluxuri de aprobare pentru achiziții sau cheltuieli, în funcție de valoare și de departament;
• câmpuri suplimentare pe fișa clientului sau a articolului, afișate doar rolurilor care au nevoie de ele;
• rapoarte și vederi adaptate pentru contabil, director comercial sau gestionar;
• structura dimensiunilor analitice pentru centre de profit și proiecte, necesară controlului de gestiune.

Dacă lista dumneavoastră de cerințe este încă vagă, redactați-o mai întâi: modelul de caiet de sarcini ERP vă ajută să marcați ce este obligatoriu, ce este de dorit și ce poate fi abandonat.

Extensii din Marketplace: a doua opțiune de verificat

În versiunea online, Business Central se extinde prin aplicații instalate din Microsoft Marketplace. Există pagini dedicate aplicațiilor de conectivitate și celor bancare, care permit, de exemplu, importul tranzacțiilor bancare. Pentru comerțul electronic, Microsoft furnizează un conector Shopify care sincronizează produse, stocuri, clienți, comenzi, expedieri, tranzacții și plăți între magazin și ERP. Sincronizarea poate rula automat, în fundal, prin coada de lucrări a sistemului, cu jurnal detaliat pentru depanare.

Pentru o firmă din România, întrebarea esențială este alta: ce acoperă aplicațiile pentru obligațiile locale. Microsoft furnizează direct localizarea în mai multe țări, dar pentru restul, inclusiv pentru particularitățile locale, există aplicații de localizare dezvoltate de parteneri și găsite în Marketplace. Cereți integratorului să vă spună exact ce aplicație acoperă RO e-Factura, SAF-T (D406) și RO e-Transport, cine o întreține și cum se actualizează când ANAF schimbă specificațiile. Detaliile obligațiilor sunt în ghidul despre SAF-T D406 și ERP.

Avantajul unei aplicații existente este costul împărțit și întreținerea asigurată de un editor. Riscul este dependența de acel editor: verificați cine răspunde dacă aplicația nu mai este actualizată.

Dezvoltarea specifică în AL: ce înseamnă concret

Când nici parametrarea, nici Marketplace nu ajung, se trece la cod. Business Central se personalizează prin extensii scrise în limbajul AL, în Visual Studio Code. Se pot adăuga sau modifica tabele, pagini, codeunit-uri și rapoarte fără a atinge codul de bază. Extensia se compilează într-un fișier .app, care se publică într-un mediu.

Pentru dumneavoastră, ca decident, contează trei consecințe.

1. Codul este al firmei dumneavoastră. Cereți în contract predarea surselor și dreptul de a le da altui furnizor. Fără aceasta, rămâneți dependent de o singură echipă.
2. Mediul de dezvoltare este sandbox-ul. Mediile sandbox sunt concepute pentru dezvoltare: punctul de depanare este deschis implicit și publicarea se face din Visual Studio Code. Un dezvoltator care lucrează direct în producție încalcă o regulă elementară.
3. Apelurile externe sunt controlate. În sandbox, apelurile HTTP trimise de extensii sunt blocate până când le autorizați extensie cu extensie. Este o protecție utilă, dar trebuie prevăzută în planul de test al unei integrări.

Când se justifică un modul la comandă

Un modul specific are sens atunci când procesul respectiv vă diferențiază pe piață și nicio aplicație nu îl acoperă. Exemple tipice: un mod propriu de calcul al prețurilor pentru clienți contractuali, o regulă de alocare a costurilor specifică unui lanț de producție, o formă de document cerută de un client important. Nu se justifică pentru a copia obiceiurile unui program anterior doar pentru că utilizatorii sunt obișnuiți cu ele; acolo este mai ieftin să schimbați procesul.

Integrări: unde dezvoltarea ajunge cel mai des

O mare parte din codul scris în jurul Business Central privește legătura cu alte sisteme: magazin online, platformă de curierat, aplicație de teren, sistem bancar. Business Central expune o API REST (v2.0) pentru conectarea cu soluții terțe, iar API-urile sunt activate implicit în versiunea online.

Câteva lucruri de știut, pentru că ele schimbă costul unei integrări:

• adăugarea de câmpuri la un API standard nu este posibilă; se copiază codul AL și se creează un API personalizat, pe care îl veți întreține;
• apelurile OData V4 sunt limitate per utilizator: 5 cereri simultane, 100 de conexiuni și o fereastră glisantă de 6 000 de cereri pe 5 minute; peste limită, serviciul răspunde cu codul HTTP 429;
• Microsoft recomandă API sau OData în locul SOAP, care urmează să fie depreciat.

Aceste limite contează pentru o firmă cu volum mare de comenzi: o integrare gândită fără ele se oprește exact în perioadele de vârf. Pentru un tablou complet al conectorilor, vedeți pagina despre integrările Business Central.

Un mediu Business Central poate fi legat și de un mediu Power Platform de același tip (producție sau sandbox); legătura este exclusivă și devine ținta implicită pentru integrările cu Power Platform și cu alte produse Dynamics 365. Dacă planificați automatizări în afara ERP-ului, aflați de la început în ce mediu vor rula.

Impactul asupra actualizărilor

Aceasta este întrebarea care separă un proiect sănătos de unul care îmbătrânește prost. Într-un model cu extensii, codul dumneavoastră stă lângă aplicația Microsoft, nu în interiorul ei; de aceea actualizările pot veni fără ca personalizările să fie rescrise. Dar „pot” nu înseamnă „vor”. Se întâmplă probleme când:

• extensia se bazează pe comportamente care se schimbă între versiuni;
• aplicațiile terțe instalate nu sunt compatibile cu noua versiune;
• nimeni nu testează în sandbox înainte ca versiunea să ajungă în producție;
• dezvoltatorul a copiat cod standard în loc să-l extindă, deci trebuie refăcut la fiecare schimbare.

Pentru a înțelege ritmul versiunilor și ce puteți amâna, citiți pagina despre versiunile și edițiile Business Central. Fiecare personalizare este, în fond, un angajament de testare la fiecare ciclu.

Bune practici: standard, documentație, testare

Cele mai ieftine proiecte pe termen lung respectă câteva reguli simple.

Cum se arată „documentat” în practică

O documentație utilă nu este un manual de sute de pagini. Este o fișă scurtă pentru fiecare extensie: ce problemă rezolvă, cine a cerut-o, ce tabele și ce procese atinge, cum se testează și cine o poate modifica. Dacă un integrator nu poate produce așa ceva pentru un modul livrat anul trecut, așteptați-vă să nu o producă nici pentru al dumneavoastră.

Cum evaluați un dezvoltator sau un integrator Business Central

Un portofoliu de proiecte spune puțin. Întrebările de mai jos spun mult mai mult și se pun într-o oră.

1. Ce ați face fără cod? Un partener bun începe prin a vă arăta ce acoperă standardul. Unul care vinde ore propune cod imediat.
2. Unde lucrați și cum promovați modificările? Răspunsul corect: sandbox, apoi producție, cu o procedură scrisă.
3. Cine deține codul? Cereți răspunsul în contract, nu în discuție.
4. Cum gestionați o actualizare majoră? Să vă descrie testele, nu doar să promită că „se rezolvă”.
5. Ce ați construit pentru contextul românesc? Cereți exemple despre e-Factura, SAF-T (D406), TVA, relația cu contabilul.
6. Cine face suportul după livrare? Verificați oferta de suport și mentenanță separat de oferta de proiect.

Pentru o grilă mai largă de selecție, vedeți cum alegeți un partener Business Central și ghidul general despre alegerea integratorului ERP.

Cum se prezintă costul unei dezvoltări

Orice sumă concretă depinde de perimetru, de numărul de utilizatori și de complexitatea proceselor; de aceea nu veți găsi aici un tarif de referință. Prețurile licențelor sunt un alt subiect, tratat în pagina despre prețurile Business Central. Microsoft precizează de altfel că prețurile afișate pot diferi de cele reale în funcție de monedă, țară și variantă regională, iar prețul final apare la plată.

O ofertă serioasă de dezvoltare separă:

• analiza și specificația funcțională, validată de dumneavoastră;
• dezvoltarea propriu-zisă;
• testele și corecțiile, cu criterii de acceptare;
• instruirea utilizatorilor;
• întreținerea ulterioară, ca linie distinctă.

Dacă toate acestea apar într-un singur total, nu puteți compara două oferte și nici nu puteți negocia ce contează.

Dezvoltarea într-un proiect de implementare

Personalizările nu se decid la sfârșit. Ele apar în fazele de analiză și de pilot, când utilizatorii văd sistemul pentru prima dată. Un proiect disciplinat păstrează o listă a cererilor, o prioritizează după valoarea de business și lasă la o a doua etapă tot ce nu blochează lansarea. Detaliile fazelor sunt în pagina despre implementarea Business Central.

Dacă preluați un proiect deja început, cu multe module și fără documentație, un audit tehnic al codului existent înaintea oricărei noi cereri vă protejează bugetul.

Cum vă ajutăm

Integrator ERP este un serviciu gratuit de punere în legătură: descrieți proiectul, iar noi vă punem în contact cu un integrator ERP certificat, potrivit perimetrului dumneavoastră. Nu suntem afiliați vreunui editor și nu facem noi proiectul; integratorul îl realizează. Dacă vă interesează în special partea de dezvoltare, menționați-o în cerere: nevoile concrete, sistemele de conectat și modul în care doriți să fie predat codul.

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.