↓

Razvoj in prilagajanje NetSuite: kaj naj bo po meri, kaj pa standard

Razvoj NetSuite ni samo programiranje: najprej so nastavitve, nato obstoječe razširitve in šele nazadnje koda po meri. Pojasnjujemo, kje je meja, kaj to pomeni za posodobitve in kako presoditi razvijalca.

Posodobljeno 28. oktober 2026

Kdor v podjetju sliši besedo »razvoj« v zvezi z NetSuite, pogosto pomisli na zajeten programerski projekt. V resnici je razvoj NetSuite lestvica z več stopnjami in večina slovenskih podjetij mora po njej splezati le do druge ali tretje prečke. Cilj ni čim več kode, temveč sistem, ki ustreza vašemu poslovanju in ostane vzdrževljiv, ko se enkrat spremenijo zakonodaja, računovodja ali poslovni model.

Ta stran je namenjena direktorjem, finančnim vodjem in vodjem informatike, ki se odločajo, koliko prilagajanja je smiselno, in iščejo ponudnika, ki to zna narediti brez nepotrebnih tveganj.

Tri ravni prilagajanja NetSuite

Smiselno je razlikovati tri ravni. Vsaka naslednja je dražja za vzdrževanje, zato jo izberite šele, ko prejšnja ne zadošča.

1. Nastavitve in orodja brez kode

NetSuite ima v platformi SuiteCloud vgrajena orodja za prilagajanje brez programiranja: dodatna polja, obrazce, vrste zapisov po meri in predloge dokumentov. S tem lahko na primer na prodajno naročilo dodate podatek, ki ga zahteva vaš način dela, ali prilagodite videz računa za slovenskega kupca.

Pomembna prednost: po dokumentaciji se prilagoditve, narejene z orodji brez kode, ob nadgradnjah NetSuite prenesejo samodejno. Tu je tveganje najmanjše.

2. Delovni tokovi v SuiteFlow

SuiteFlow je grafični pogon delovnih tokov. Po dokumentaciji je primeren za avtomatizacijo brez kode: privzete vrednosti polj, zahtevnejše potrditvene poti, opomnike za potrditev, ravnanje s potencialnimi strankami, dejanja na povezanih zapisih in obdelavo shranjenih iskanj.

Praktičen primer iz slovenskega podjetja: nabavni nalog nad določenim pragom mora pred potrditvijo videti vodja oddelka, nato še finančni direktor. Takšno pot nastavite v SuiteFlow in je ne boste programirali.

3. Razvoj po meri v SuiteScriptu

Ko nastavitve in tokovi ne zadostujejo, nastopi SuiteScript. Gre za razvojno okolje, zasnovano na JavaScriptu. Po dokumentaciji je potreben za strežniške poizvedbe po meri, klice spletnih storitev, skriptirane portlete in aplikacije po meri. Šele tukaj lahko govorimo o pravem modulu po meri za NetSuite.

Raven Orodje Potreben razvijalec Vpliv na nadgradnje
Nastavitve Polja, obrazci, zapisi, predloge Ne, običajno zadostuje svetovalec Najmanjši, prenos je samodejen
Delovni tokovi SuiteFlow Redko Majhen, a tokove je treba preizkusiti
Skripte SuiteScript Da Večji, zahteva testiranje po izdajah
Aplikacije in povezave SuiteScript, SuiteTalk, SuiteApps Da Odvisen od zasnove in dokumentacije

Kaj vsebuje razvojna platforma SuiteCloud

Za razumevanje ponudb je koristno poznati sestavne dele, ker se v predračunih pogosto pojavljajo:

  • SuiteScript (različici 1.x in 2.x) za skripte v JavaScriptu;
  • SuiteFlow za delovne tokove;
  • SuiteCloud Development Framework (SDF) za upravljanje prilagoditev kot projekta, ki ga je mogoče prenašati med okolji;
  • SuiteCloud SDK z vtičnikom za razvojno okolje, ukazno vrstico in razširitvami;
  • SuiteApps, ki omogočajo, da se rešitev pakira in porazdeli kot dodatek;
  • SuiteTalk, spletne storitve SOAP in REST za povezovanje z drugimi sistemi.

Dokumentacija med orodji omenja tudi SuiteCloud Developer Assistant, pomočnika za kodiranje z umetno inteligenco, vgrajenega v VS Code, ter AI Connector Service, ki temelji na protokolu Model Context Protocol (MCP) za varno vključevanje umetne inteligence. Prilagoditve se med računi prenašajo z ukazom »Copy to Account«. Ta orodja pospešijo delo razvijalca, ne nadomestijo pa njegove presoje: pregled kode in testiranje ostajata človeška naloga.

Obstoječe razširitve ali razvoj po meri?

Preden naročite kodo, preverite tri stvari.

  1. Ali zahtevo pokriva standardna funkcija? Pogosto se izkaže, da je ustrezna možnost že v NetSuite, le da je nihče ni vključil. Oglejte si module NetSuite in njihove nastavitve.
  2. Ali obstaja SuiteApp? Če rešitev že obstaja kot distribuiran dodatek, je običajno cenejša od lastnega razvoja, a morate preveriti, kdo jo vzdržuje in kako se odziva na nove izdaje.
  3. Ali gre za vašo konkurenčno prednost? Koda po meri se splača tam, kjer se način dela res razlikuje od običajnega, ne tam, kjer zgolj ni navade na standardni postopek.

Pri omejitvah, ki izvirajo iz lokalnih zahtev, bodite posebej pozorni. Slovenski računovodski in davčni postopki, kot so e-računi, obračun DDV prek eDavkov in po potrebi davčno potrjevanje računov pri FURS, se ne rešujejo z improvizirano skripto. O tem, kaj od tega NetSuite pokriva v praksi in kaj zahteva dodatno delo, preberite na strani NetSuite v Sloveniji ter v vodniku o e-računih in obračunu DDV v ERP.

Povezave z drugimi sistemi: REST namesto SOAP

Velik del razvoja v praksi niso moduli, temveč povezave: spletna trgovina, banka, skladišče, sistem za plače ali portal za e-račune. Tu je pomembna sprememba, ki jo mora upoštevati vsak načrt.

Spletne storitve REST v SuiteTalk omogočajo operacije CRUD nad zapisi, dostop do metapodatkov, filtriranje zbirk, dejanja in pretvorbe zapisov, asinhrono obdelavo ter izvajanje podatkovnih nizov delovnih zvezkov SuiteAnalytics in poizvedb SuiteQL. Za razliko od skriptov RESTlet za to ni treba nameščati skripte.

Spletne storitve SOAP so v umikanju. WSDL 2025.2 je zadnja predvidena točka dostopa SOAP; od izdaje 2027.1 bo podprta samo ta, po izdaji 2028.2 pa SOAP ne bo več na voljo. Dokumentacija za vsako novo integracijo priporoča REST z OAuth 2.0. Praktični nasvet: če vam kdo ponudi novo povezavo na osnovi SOAP, vprašajte, zakaj, in zahtevajte pisno obrazložitev.

SOAP v SuiteTalk sicer deluje s kodiranjem Document (sporočilno usmerjena izmenjava XML, RPC ni podprt), samo prek HTTPS, z nadzorom dostopa po vlogah (obstaja vloga »Web Services Only«) ter s sinhronimi ali asinhronimi zahtevami. To je pomembno pri pregledu obstoječih povezav. Več o tej temi najdete na strani o integracijah NetSuite.

Kako prilagoditve vplivajo na posodobitve

NetSuite se posodablja v rednih izdajah, zato prilagoditve niso enkratna zadeva. Načeloma velja:

  • prilagoditve brez kode se ob nadgradnjah prenašajo samodejno, kot navaja dokumentacija;
  • skripte, ki uporabljajo dokumentirane vmesnike, so običajno stabilne, a jih je treba po izdaji preizkusiti;
  • skripte, ki se naslanjajo na nedokumentirane lastnosti vmesnika ali ki spreminjajo standardno vedenje na zapleten način, so najbolj ranljive;
  • povezave, ki uporabljajo opuščeno tehnologijo (SOAP), imajo znan rok izteka.

Zato je pomembno, da razumete izdaje in različice NetSuite ter da imate dogovorjeno, kdo po vsaki izdaji preizkusi vaše prilagoditve. To ni dodatek, temveč del podpore in vzdrževanja.

Dobre prakse: ostanite čim bližje standardu

Dokazano pomagajo naslednja pravila, ki veljajo za vse ERP, ne le za NetSuite.

  • Najprej prilagodite postopek, šele nato sistem. Pogosto je cenejše spremeniti navado v podjetju kot napisati skripto.
  • Ena prilagoditev, en razlog. Vsaka skripta ima zapisan poslovni namen, lastnika in datum zadnjega pregleda.
  • Dokumentacija je del dobave. Brez opisa delovanja, vhodov in izhodov se koda po odhodu razvijalca spremeni v črno skrinjo.
  • Ločeno okolje za preizkuse. Prilagoditve se preizkusijo v peskovniku, nato prenesejo v živo okolje prek SDF ali ukaza »Copy to Account«, ne ročno.
  • Nadzor različic. Koda spada v repozitorij, ne zgolj v račun NetSuite.
  • Preizkus s pravimi podatki in pravimi uporabniki. Računovodja mora potrditi obračun, skladiščnik prevzem, prodajalec ponudbo.
  • Redni pregled. Skripte, ki jih nihče več ne uporablja, se odstranijo; za to je koristen pregled in reševanje projekta.

Pogoste pasti so zbrane v vodniku o napakah pri ERP projektih; med najpogostejšimi je prav pretirano prilagajanje že v prvi fazi.

Kako oceniti razvijalca ali integratorja NetSuite

Ker ne zastopamo nobenega ponudnika, vam lahko povemo, kaj sami preverjamo pri predstavitvi. Vprašanja, ki ločijo zrel pristop od prodajnega:

  1. Kdaj bi predlagal nastavitev namesto skripte? Če odgovor ni takojšen in konkreten, je to opozorilo.
  2. Kako dokumentira in predaja rešitev? Prosite za vzorec dokumentacije brez podatkov strank.
  3. Kako preizkuša prilagoditve po izdajah? Pričakujte opisan postopek, ne obljubo.
  4. Katero tehnologijo predlaga za povezave? Pri novih povezavah mora biti odgovor REST z OAuth 2.0, ne SOAP.
  5. Kdo je lastnik kode? Dogovorite se, da vam pripada ali da jo lahko dobite v celoti.
  6. Ali razume slovenske zahteve? Vprašajte, kako bi rešil e-račune, obračun DDV in po potrebi potrjevanje računov, ter kako bi to uskladil z vašim računovodjo.
  7. Ali je pripravljen povedati, česa ne naredi? Dober ponudnik meje svojega dela zna opisati.

Širši okvir izbire najdete v vodniku kako izbrati ERP integratorja in na strani izbira partnerja za NetSuite. Opis poteka projekta od zahtev do zagona je na strani o uvedbi NetSuite.

Kako poteka naše posredovanje

Mi ne razvijamo in ne uvajamo. Brezplačno vas povežemo z integratorjem, ki se je že srečal s podobnim projektom. Vi opišete, kaj morate prilagoditi in zakaj; integrator poda oceno, ki naj vsebuje ločeno to, kar je nastavitev, in to, kar je koda po meri. Primerjajte vsaj dve ponudbi in zahtevajte, da jo ponudnik razdeli na te sklope. Tako boste takoj videli, kje se skriva največji delež dela in tveganja.

Pogosta vprašanja

Ali je za razvoj NetSuite vedno potrebno programiranje?

Ne. Veliko prilagoditev se opravi brez kode: dodatna polja, obrazci, vrste zapisov, predloge in delovni tokovi v SuiteFlow. Programiranje v SuiteScriptu pride na vrsto, ko nastavitve ne zadostujejo, na primer pri posebnih strežniških poizvedbah, klicih spletnih storitev ali aplikacijah po meri.

Ali prilagoditve ovirajo posodobitve NetSuite?

Po dokumentaciji se prilagoditve, narejene z orodji brez kode na platformi SuiteCloud, ob nadgradnjah NetSuite prenesejo samodejno. Pri skriptah je več odgovornosti na vaši strani, zato jih po vsaki večji izdaji preizkusite v ločenem okolju, preden jih uporabite v živo.

V katerem jeziku se razvija za NetSuite?

Skripte so napisane v JavaScriptu v okolju SuiteScript, ki obstaja v različicah 1.x in 2.x. Za pakiranje in prenos med okolji se uporablja SuiteCloud Development Framework, za povezave z drugimi sistemi pa spletne storitve SuiteTalk, pri novih povezavah priporočeno v obliki REST.

Ali lahko obstoječo povezavo SOAP še uporabljam?

Za zdaj da, vendar je SOAP v umikanju. WSDL 2025.2 je zadnja predvidena točka dostopa SOAP, od izdaje 2027.1 naprej bo podprta le ta, po izdaji 2028.2 pa SOAP ne bo več na voljo. Za vsako novo integracijo dokumentacija priporoča REST z OAuth 2.0, obstoječe povezave pa je smiselno načrtno preseliti.

Kako ugotovim, ali je razvijalec ali integrator NetSuite res usposobljen?

Prosite za opis dosedanjih projektov brez imen strank, za način dokumentiranja in testiranja ter za pojasnilo, kdaj bi predlagal nastavitev namesto skripte. Dober ponudnik bo najprej poskusil ostati pri standardu in vam bo jasno povedal, kaj bo koda po meri pomenila za vzdrževanje.

Viri

  1. Oracle NetSuite — SuiteCloud Platform (spletna pomoč)
  2. Oracle NetSuite — SuiteFlow ali SuiteScript (spletna pomoč)
  3. Oracle NetSuite — SuiteTalk REST Web Services (spletna pomoč)
  4. Oracle NetSuite — SuiteTalk SOAP Web Services (spletna pomoč)

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