Prilagoditve Microsoft Dynamics 365 Business Central: od nastavitev do lastnega modula

Razvoj Business Central je pogosto prvo, na kar pomislijo podjetja, ko ugotovijo, da standardni program ne pokriva vsega, kar počnejo. A med »program ne zna« in »napišimo kodo« leži več poceni in varnejših korakov. Ta stran pojasnjuje, kako si sledijo, kaj prinaša vsak in kako ravnati, da posodobitve ostanejo preproste.

Za slovenske MSP je ta tema še posebej pomembna, ker se prilagoditve pogosto dotikajo lokalnih zahtev: davčnega potrjevanja računov pri FURS, e-računov in obračuna DDV prek eDavkov. O njih podrobneje pišemo na straneh o davčni blagajni in ERP ter o e-računih in obračunih DDV.

Tri stopnje prilagajanja Business Central

Pri prilagoditvah velja preprosto pravilo: začnite pri najnižji stopnji, ki reši težavo.

Prva stopnja: nastavitve in konfiguracija

Večina potreb se reši brez kode. Sem sodijo plan kontov, knjižbene skupine, številčenje, odobritvena pravila, uporabniške vloge, prilagojeni pogledi in polja na straneh. Business Central ima Designer, vgrajen v odjemalca: strani oblikujete z vlečenjem in spuščanjem, prerazporejate ali dodajate polja ter si ogledate predogled, ne da bi zapustili uporabniški vmesnik. Računovodja ali vodja projekta lahko tako sam uredi zaslon, ki ga uporablja vsak dan.

Nastavitve so tudi najcenejše za vzdrževanje, saj jih Microsoftove posodobitve ne zlomijo. Kako se plan kontov in dimenzije povezujejo z vašim knjigovodstvom, razlagamo na strani o računovodstvu in financah v Business Central.

Druga stopnja: obstoječe aplikacije in razširitve

Če nastavitve ne zadoščajo, poiščite že narejeno rešitev. Business Central se v oblaku razširja z aplikacijami, ki se namestijo iz Microsoft Marketplace. Strani »Connectivity Apps« in »Banking Apps« ponujajo aplikacije za povezavo z zunanjimi storitvami, na primer za uvoz bančnih transakcij.

Primer iz prakse spletne trgovine: povezava s Shopify je že narejena. Konektor sinhronizira izdelke, zaloge, kupce, naročila, odpreme, transakcije in izplačila, podpira več trgovin ter uvaža naročila iz spletnih trgovin, Shopify POS in B2B. Sinhronizacijo je mogoče avtomatizirati v ozadju prek čakalnice opravil (job queue) z natančnim beleženjem za odpravljanje napak. Lasten konektor bi bil nesmiseln strošek. Več o povezavah piše na strani o integracijah Business Central.

Za slovenski trg je ključno vprašanje lokalizacije. Microsoft sam zagotavlja lokalizacijo za izbrane države in jih navaja kot primere; Slovenije med navedenimi nismo zasledili. Za druge države so na voljo lokalizacijske aplikacije partnerjev v Marketplace. Pri izbiri izvajalca zato vedno preverite, katera lokalizacija pokriva slovenske zahteve in kdo jo vzdržuje. Podrobnosti so na strani Business Central v Sloveniji.

Tretja stopnja: razvoj po meri v jeziku AL

Ko ni ne nastavitve ne gotove aplikacije, pride na vrsto lastna razširitev. Business Central se prilagaja z razširitvami, napisanimi v jeziku AL v Visual Studio Code. Z njimi dodajate ali spreminjate tabele, strani, codeunite in poročila, ne da bi spreminjali osnovno kodo; rezultat se prevede v datoteke .app.

To je bistvena razlika od starejših ERP-jev, kjer se je spreminjala sama izvorna koda in je vsaka nadgradnja pomenila ponovno usklajevanje. Pri razširitvah ostane Microsoftova koda nedotaknjena, vaša pa živi ločeno.

Kdaj je modul po meri upravičen

Modul po meri na Business Central ima smisel, kadar je postopek vaša konkurenčna prednost ali ko ga standard resnično ne pozna. Nekaj tipičnih primerov:

Panožne rešitve opisujemo na strani Business Central po panogah, za proizvodna podjetja pa posebej v razdelku o proizvodnji.

Razvoj in povezave: kaj morate vedeti o API-jih

Večina razvojnih potreb v resnici ni nov zaslon, ampak izmenjava podatkov z drugim sistemom: spletno trgovino, skladiščem, bančnim portalom ali orodjem za poročanje. Business Central za to ponuja REST API (v2.0), ki je v spletni različici privzeto vklopljen.

Dve podrobnosti pogosto presenetita:

• Standardnemu API-ju ni mogoče dodati polj. Če potrebujete polje, ki ga standard ne vsebuje, je treba kodo AL kopirati in ustvariti lasten API.
• Obstajajo omejitve klicev. Omejitve OData V4 veljajo na uporabnika: pet hkratnih zahtev, sto povezav in drseče okno šest tisoč zahtev v petih minutah. Nad mejo storitev odgovori s kodo HTTP 429. Microsoft priporoča API ali OData namesto SOAP, ki naj bi bil v prihodnje opuščen.

Izvajalec, ki načrtuje množičen uvoz ali pogosto sinhronizacijo, mora to upoštevati že v zasnovi. Sicer boste vzorec odkrili šele, ko bodo naročila obtičala sredi sezone.

Okolje Business Central je mogoče povezati z okoljem Power Platform enake vrste (produkcija ali peskovnik). Povezava je izključna in je privzeta tarča za integracije s Power Platform in drugimi izdelki Dynamics 365. Če načrtujete avtomatizacije, ki segajo čez več aplikacij, to odločitev sprejmite zgodaj.

Kako prilagoditve vplivajo na posodobitve

Prilagoditev v obliki razširitve je zasnovana tako, da posodobitev preživi, vendar to ni samodejno zagotovilo. Tveganja so tri:

• razširitev se opira na dele sistema, ki jih Microsoft v naslednji izdaji spremeni;
• razširitev ni dokumentirana in jo razume samo ena oseba, ki je odšla;
• nihče ne preveri razširitve v peskovniku pred posodobitvijo produkcije.

Zadnja točka je najlažja za odpravo. Okolja peskovnika so namenjena razvoju in preizkusom: razhroščevalna točka je privzeto odprta, razširitve se objavljajo iz Visual Studio Code, odhodni klici HTTP pa so blokirani, dokler jih ne odobrite za posamezno razširitev. Posodobitev najprej preizkusite tam, v produkcijo šele nato. O izdajah in posodobitvenih ciklih beremo na strani o različicah in izdajah Business Central, o dolgoročni skrbi pa na strani o podpori in vzdrževanju.

Dobre prakse pri prilagajanju

Ostanite pri standardu, kjer le gre

Vsaka prilagoditev je dolg, ki ga plačujete ob vsaki posodobitvi. Preden naročite razvoj, se vprašajte, ali lahko prilagodite postopek, ne programa. Pogosto se izkaže, da je standardni tok enakovreden, le drugače poimenovan. Splošna pravila o tem, kako se izogniti pretiranemu razvoju, najdete v vodniku napake pri ERP projektih.

Dokumentirajte vse, kar ni standardno

Za vsako razširitev naj obstajajo: namen, naročnik v podjetju, opis zahtev, seznam prizadetih tabel in strani ter navodilo za preizkus. Dokumentacija je last vašega podjetja, ne izvajalca. Če izvajalca zamenjate, mora nov razvijalec razumeti, kaj je bilo narejeno in zakaj.

Testirajte v peskovniku in z resničnimi scenariji

Preizkus naj poteka z resničnimi dokumenti: ponudba, naročilo, dobavnica, račun, knjižba, plačilo. Računovodja naj preveri rezultate knjiženja, skladiščnik pa tok blaga. Pri računih in DDV je preizkus nujen tudi za potrjevanje pri FURS.

Pisno določite zahteve

Razvoj po meri brez opisa zahtev se konča z dvomom, kdo je kriv, ko nekaj ne deluje. Pripravite kratek dokument s ciljem, vhodnimi podatki, rezultatom in sprejemnimi merili. Pomaga predloga iz vodnika o predlogi zahtev za ERP.

Kako oceniti razvijalca ali izvajalca Business Central

Vprašanja, ki jih postavite izvajalcu, naj bodo konkretna:

• Kakšen je vaš pristop: ali najprej predlagate nastavitve in obstoječe aplikacije ali takoj ponudite razvoj?
• Katere razširitve ste že naredili in kako so dokumentirane (brez razkritja imen strank)?
• Kako razvoj testirate in kje poteka objava pred produkcijo?
• Kdo vzdržuje razširitev po posodobitvi in kako se to obračuna?
• Kdo vzdržuje slovensko lokalizacijo, vključno z davčnim potrjevanjem in e-računi?
• Ali boste izvorno kodo in dokumentacijo predali nam?

Dobro znamenje je izvajalec, ki zna reči »tega ne bi razvijali«. Slabo znamenje je ponudba razvoja za vsako željo, ne da bi omenil posledice za vzdrževanje.

Celovit pristop k izbiri opisuje stran izbira partnerja za Business Central in splošen vodnik kako izbrati ERP integratorja. Če izvajalca še nimate, je naš postopek povezovanja brezplačen: opišete projekt, mi pa vas povežemo z izvajalcem, ki ustreza vaši panogi in regiji. Projekt nato izvede izvajalec, ne mi.

Kaj to pomeni za proračun

Stroški razvoja se ne dajo oceniti brez opisa zahtev, zato številk ne navajamo. Zapomnite si, da se skupni strošek sestavlja iz licenc, uvedbe, razvoja in kasnejšega vzdrževanja razširitev. Microsoft za Business Central na ameriški strani navaja za različico Essentials 80 USD, za Premium 110 USD in za Team Members 8 USD na uporabnika na mesec ob letnem obračunu, pri čemer opozarja, da se cene lahko razlikujejo po valuti, državi in regionalni različici. Končna cena se pokaže pri plačilu. Podrobnosti so na strani o cenah Business Central, splošen okvir pa v vodniku cena ERP.

Razvoj po meri tej vsoti prinese strošek, ki se ponavlja: vsaka razširitev zahteva preizkus ob posodobitvi. Zato sprašujte tudi po stroških vzdrževanja, ne le po ceni prvotnega razvoja.

Povzetek: pot do zmerne prilagoditve

Najprej nastavitve, potem obstoječe aplikacije in šele nato razširitev v jeziku AL. Vsako stopnjo utemeljite z vprašanjem, ali bi isto lahko dosegli z nižjo. Razširitve razvijajte v peskovniku, dokumentirajte jih in zahtevajte, da jih izvajalec preizkusi ob vsaki posodobitvi. Tako ostane Business Central posodobljiv, vaša dodana vrednost pa v vaših rokah.

Imena programske opreme so blagovne znamke njihovih izdelovalcev in so navedena zgolj informativno. Spletno mesto je neodvisno in ni povezano z nobenim izdelovalcem.