HOLYERP
← Nazad na blog

AI razvoj AL ekstenzija za Business Central

8 min čitanja
Zahtev običnim jezikom pretvara se u AL kod za Business Central

Zahtev poput „na računu želimo upozorenje kada kupac pređe kreditni limit” često pokrene niz poruka, specifikacija i čekanja na procenu. AI razvoj AL ekstenzija menja taj početak: poslovni korisnik može da opiše potrebu običnim jezikom, a sistem i konsultant je pretvaraju u predlog izmene za Microsoft Dynamics 365 Business Central. Rezultat nije samo brže pisanje koda, već kraći put od problema u finansijama ili operativi do bezbedno testiranog rešenja.

To ne znači da svaki zahtev treba automatski pretvoriti u kod. Business Central je centralni sistem za knjigovodstvo, nabavku, prodaju, projekte, odobravanja i izveštavanje. Mala promena u jednom procesu može uticati na dozvole, dimenzije, knjiženje ili integracije. Zato je prava vrednost AI pristupa u kombinaciji brzine mašine i odgovornosti stručnog konsultanta.

Šta AI razvoj AL ekstenzija zapravo menja

AL je programski jezik za razvoj ekstenzija u Business Centralu. Ekstenzija dodaje ili prilagođava funkcionalnosti bez izmene standardnog Microsoft koda: nova polja, kontrole, poslovna pravila, izveštaje, API integracije ili automatizovane tokove odobravanja.

U tradicionalnom modelu, konsultant prvo prikuplja zahtev, zatim piše funkcionalnu specifikaciju, programer tumači dokument, razvija kod i vraća ga na testiranje. Taj model može biti opravdan za velike i složene projekte, ali za manje operativne izmene često uvodi nepotrebno čekanje. Problem nije samo cena razvoja. Dok se zahtev prevodi između poslovnog korisnika, konsultanta i programera, lako se izgubi kontekst zbog kog je promena uopšte tražena.

AI može da skrati taj ciklus. On analizira opis zahteva, prepoznaje objekte i procese Business Centrala koje promena može da zahvati, predlaže AL strukturu i generiše početnu verziju koda. Konsultant zatim proverava da li predlog zaista odgovara poslovnom procesu, da li poštuje postojeću arhitekturu i da li uvodi rizik u knjiženje, odobravanje ili izveštavanje.

Važna razlika je sledeća: AI ne treba posmatrati kao zamenu za ERP odgovornost. Njegova snaga je da ubrza analizu, pripremu i razvoj ponovljivih izmena. Odluku o tome šta promena sme da uradi u produkciji i dalje donose ljudi koji razumeju poslovanje kompanije.

Od zahteva običnim jezikom do test okruženja

Dobar AI proces počinje kvalitetnim opisom, a ne komandom „napravi ekstenziju”. Finansijski direktor, nabavka ili IT ne moraju da znaju AL, ali treba da objasne okidač, pravilo, korisnike i očekivani ishod.

Na primer, umesto zahteva „dodajte kontrolu faktura”, korisnije je navesti: „Kada se ulazna faktura unese sa iznosom većim od 300.000 RSD, ne sme da bude knjižena dok je ne odobre rukovodilac nabavke i finansijski direktor. Odobrenje mora da ostane vidljivo na dokumentu i u evidenciji.” Takav zahtev sadrži poslovni događaj, prag, učesnike, zabranu akcije i trag kontrole.

1. Analiza procesa i postojećeg rešenja

Pre generisanja koda potrebno je utvrditi gde se pravilo uklapa. Da li kompanija već koristi standardni workflow odobravanja? Da li iznos treba posmatrati sa PDV-om ili bez njega? Da li se prag razlikuje po dimenziji, sektoru, lokaciji ili vrsti troška? Da li korisnik može da izmeni fakturu nakon prvog odobrenja?

Ova pitanja nisu usporavanje. Ona sprečavaju da se brzo napravi pogrešna ekstenzija. AI može predložiti relevantne tabele, stranice i događaje u standardnoj aplikaciji, dok konsultant proverava da li je bolje prilagoditi postojeći workflow ili razviti posebno pravilo.

2. Predlog rešenja pre pisanja koda

Pre razvoja treba dobiti jasan predlog: koja polja se dodaju, kada se pokreće validacija, ko dobija zahtev za odobrenje, šta korisnik vidi ako pravilo nije ispunjeno i kako se promena testira. Za zahtev sa ulaznim fakturama, to može značiti dodatni status odobrenja, proveru pre knjiženja i zapis o tome ko je i kada doneo odluku.

Ovaj korak je posebno važan za rukovodioce. Oni ne moraju da pregledaju svaku AL funkciju, ali moraju da potvrde da se poslovno pravilo pravilno tumači. Tek tada kod postaje sredstvo za sprovođenje dogovorene kontrole, a ne tehnički eksperiment.

3. Generisanje AL koda i automatske provere

Kada je rešenje potvrđeno, AI priprema AL ekstenziju: objekte, ekstenzije tabela ili stranica, event subscribere, validacije i eventualno testove. To može značajno smanjiti vreme potrebno za rutinske delove razvoja, naročito kada se radi o poznatim obrascima kao što su nova polja, kontrolne poruke, proširenja dokumenata ili povezivanje sa odobravanjem.

Ipak, generisan kod nije automatski spreman za produkciju. Potrebno je proveriti kompajliranje, kompatibilnost sa verzijom Business Centrala, nazive objekata, dozvole i ponašanje u postojećim procesima. Kod koji radi tehnički može i dalje biti poslovno pogrešan ako, na primer, blokira knjiženje dokumenata koje ne bi trebalo da budu obuhvaćene pravilom.

4. Testiranje, pregled i kontrolisano puštanje

Ekstenzija se najpre objavljuje u test okruženju. Tamo se prolaze realni scenariji: faktura ispod praga, faktura iznad praga, odbijeno odobrenje, izmena iznosa nakon odobrenja, korisnik bez potrebne dozvole i eventualno poništavanje ili korekcija dokumenta.

Konsultant zatim pregledava kod i rezultate testa. HOLY BC Agent je zamišljen upravo za takav način rada: AI ubrzava analizu i izradu, dok stručni konsultanti validiraju svaku promenu pre produkcije. Time kompanija zadržava pregled nad tim šta se menja, zašto se menja i ko je promenu odobrio.

Gde AI najbrže donosi poslovnu vrednost

Najveći efekat obično dolazi kod čestih, jasno definisanih izmena koje su ranije čekale razvojni termin. U finansijama to mogu biti kontrole pre knjiženja, obavezna popunjenost dimenzija, upozorenja za prekoračenje budžeta, nova polja na dokumentima i prilagođeni pregledi otvorenih stavki.

U nabavci, AI podržan razvoj može da poveže status zahteva, narudžbenice, prijem robe i ulazne fakture sa preciznijim pravilima odobravanja. Umesto da finansije ručno proveravaju da li faktura ima odgovarajuću narudžbenicu ili odobrenje, ekstenzija može prikazati nedostajući korak pre nego što dokument stigne do knjiženja.

Projektne organizacije često traže izmene oko ugovora, budžeta, resursa i profitabilnosti. Primer je obavezno vezivanje troška za projekat i fazu projekta, uz upozorenje kada planirani budžet nema dovoljno raspoloživog iznosa. To nije samo tehničko polje na dokumentu - kvalitet te kontrole direktno utiče na tačnost projektnog izveštavanja.

Kod izveštavanja, AI može ubrzati pripremu novih upita, dodatnih kolona i logike za klasifikaciju podataka. Ipak, definicije pokazatelja moraju doći iz biznisa. Ako finansije i prodaja različito tumače „realizovan prihod”, nijedna količina automatski generisanog koda neće rešiti problem.

Brzina nije razlog da se preskoči upravljanje promenom

AI razvoj smanjuje vreme izrade, ali ne uklanja potrebu za pravilima. Naprotiv, što se izmene brže generišu, to kompanija mora jasnije da odredi ko podnosi zahtev, ko potvrđuje poslovno pravilo, ko testira i ko odobrava produkciju.

PitanjeRizik bez kontrolePraktična kontrola
Da li je zahtev dovoljno jasan?Kod rešava pogrešan problemPotvrda poslovnog scenarija i kriterijuma uspeha
Da li promena utiče na knjiženje?Pogrešni podaci u glavnoj knjiziTest primeri sa stvarnim dokumentima
Da li su dozvole ispravne?Neovlašćene izmene ili blokade radaPregled korisničkih uloga i test pristupa
Da li je kod održiv?Teže nadogradnje i skrivena zavisnostKonsultantski pregled i dokumentovan dizajn

Posebnu pažnju traže integracije, obračuni, masovna knjiženja i izmene koje utiču na zakonske ili interne kontrole. Tu AI može pomoći u pripremi i analizi, ali odluka o implementaciji mora biti zasnovana na kompletnom procesu, uključujući izuzetke i odgovornost vlasnika procesa.

Kako pripremiti zahteve za AI podržan razvoj

Kompanije koje dobijaju najbolje rezultate ne šalju samo ideju, već kratak poslovni scenario. Dovoljno je opisati ko radi radnju, na kom dokumentu, pod kojim uslovom, šta sistem treba da uradi i šta se ne sme dogoditi. Korisno je dodati dva ili tri realna primera, uključujući izuzetak.

Na primer: „Kada komercijalista kreira prodajnu ponudu za kupca sa dospelim dugom starijim od 60 dana, sistem treba da prikaže upozorenje. Ponuda može da se sačuva, ali ne može da se pretvori u nalog bez odobrenja kreditnog kontrolora.” Takav opis odmah otvara prava pitanja: iz koje evidencije se računa dug, da li se gledaju sva povezana preduzeća, gde se čuva odobrenje i da li pravilo važi za sve kupce.

Najbolja AI ekstenzija nije ona sa najviše koda. To je ona koja uklanja konkretan zastoj, ostavlja jasan trag odluke i nastavlja da radi pouzdano kada se poslovanje promeni. Kada poslovni korisnici precizno opišu potrebu, a stručni tim proveri rešenje pre produkcije, Business Central može da prati tempo kompanije bez gubitka kontrole.

Želite da vidite kako HOLY BC Agent razvija AL ekstenzije u Vašem Business Central okruženju?

Povezani tekstovi