Tarjouspyyntömoduulin kehitys NetSuiteen

Harjoittelupaikkani esihenkilö oli jo ennen harjoittelun alkua lähettänyt minulle ehdotuksia opinnäytetyöni aiheeksi. Vaihtoehtoina oli uusien toimintojen kehitystä ProMartin käyttämälle ERP-järjestelmälle. Suunnitelmana oli aloittaa opinnäytetyö, kun saisin suoritettua harjoitteluni loppuun. Sain lopulta suoritettua harjoitteluni syyskuussa 2023. Aiheita oli yhteensä neljä, joista kolme oli pienempiä ja helpompia tehdä, neljäs taas oli laajempi ja työläämpi. Laajempi oli tarjouspyyntömoduulin kehitys, jota ProMart tarvitsi kovasti esihenkilöni mukaan. Minulle tämä sopi mainiosti, joten se oli lopullinen valinta aiheeksi. Tässä blogissa kuvataan opinnäytetyön prosessia ja siitä saatuja kokemuksia.

Tarjouspyyntömoduulin tarkoitus

Liiketoimintaprosessit jakaantuvat monelle osastolle yrityksessä. Yhä enemmän yhden prosessin vaiheet suoritetaan jopa eri maissa, mikä tekee liiketoimintaprosessien hallitsemisesta hankalampaa. Tätä varten on kehitetty ERP-järjestelmät [1]. Opinnäytetyöni aloitukseen mennessä ProMart Oy:n toiminta oli muuttunut ja tarpeet kasvanut, minkä vuoksi yrityksessä tarvittiin tarjouspyyntömoduulia ProMartin käyttämään ERP-järjestelmään. Tarjouspyyntömoduulin tarkoituksena on antaa työntekijöille mahdollisuus ensin tiedustella, millä yrityksellä on sillä hetkellä työntekijöiden tarvitsemat resurssit, ennen kuin he lähettävät virallisen ostotilauksen. Kyseinen liiketoimintaprosessi on oikeasti olemassa yritysten toiminnassa, joten on luonnollista, että tähän soveltuva toiminto kehitettäisiin ProMartille.

ERP-järjestelmät eli Enterprise Resource Planning on nimensä mukaisesti suunniteltu hallinnoimaan yritysten toimintaa yhdeltä alustalta. ProMartin käyttämä ERP-järjestelmä on NetSuite. NetSuite on pilviteknologiaan pohjautuva alusta yrityksenhallintaan, joka koostuu sovellusryhmästä. Tämä sovellusryhmä sisältää toimintoja erilaisille liiketoimintaprosesseille, kuten tilaamiseen, kirjanpitoon ja raportointiin [2]. Valitettavasti NetSuitessa ei ole toimintoa tarjouspyynnön tekemiseen, minkä vuoksi minua pyydettiin tekemään sellainen.

Moduulin kehitystä varten esihenkilöni oli lähettänyt minulle Excelin (kuva 1), jossa moduulin teko oli jaettu eri soluihin. Jokainen solu oli yksi vaihe tarjouspyynnön liiketoimintaprosessissa, jotka olivat tarjouspyynnön teko, tulosteen teko ja tarjouspyynnön konvertointi ostotilaukseksi. Aloitin heti ensimmäisestä vaiheesta eli tarjouspyynnön teosta. Tiesin jo valmiiksi mitä teknologiaa minun piti käyttää. NetSuitessa eri liiketoimintaprosessit ovat erilaisia Record Type -tyyppejä, joille järjestelmä automaattisesti luo oman lomakkeen. Tämä lomake oli tärkeä, sillä niihin pystyi luomaan omia tietokenttiä. Tiesin jo valmiiksi, että tarjouspyynnön tulisi olla transaktiotyyppiä, joten loin uuden tyypin transaktiolle. Odotetusti tälle uudelle tyypille oli samalla luotu lomake, joten jäljelle jäi luoda jonkinlainen tapa lisätä tuotteita tarjouspyynnölle ja samalla lisätä oletustoimittaja.

Kuva 1. Kuvakaappaus Excelistä, jossa on vaatimusmäärittelyt tarjouspyyntömoduulille.

Tavoitteena oli luoda tapa, jolla voisi lisätä jopa monta tuotetta samaan aikaan. Tämän vuoksi yritin aluksi luoda oman tietokentän, jota kutsuin Tuotteet-kentäksi. Tämä ei kuitenkaan toiminut, joten päätin luopua Tuotteet-kentästä. Lopullinen ratkaisu löytyi NetSuiten sisäänrakennetusta toiminnosta. Tarjouspyyntö-lomakkeen muokkaussivulla on mahdollista valita Allow Add Multiple -valintalaatikko. Tämän valinnan avulla voi luoda Items-välilehdelle Add Multiple -painikkeen (kuva 2), jota painamalla voi yhdellä kertaa lisätä monta tuotetta yhtä aikaa. Tämä ratkaisu oli yksinkertaisempi, joten päädyin käyttämään sitä. Oletustoimittajan lisääminen ei ollut vaikeaa. Käytin Workflow-teknologiaa, jonka avulla ohjeistin tarjouspyynnön täyttämään ylempänä olevan Vendor-kentän aina ensin oletustoimittajalla.

Kuva 2. Kuvakaappaus Tarjouspyyntö-sivun Items-alalistasta.

Seuraavaksi oli tulostelomakkeen muokkaus. Tämä lomake ei näyttänyt oikeita sarakkeita Items-alalistasta. Minua neuvottiin näyttämään Quantity eli tuotemäärä, Item eli tuotenimi ja EAN-koodi, joka oli lisätty Items-alalistaan myöhemmin. Määrä ja tuotenimi olivat jo valmiiksi, joten niitä piti vain siirtää lähdekoodissa. Vaikein osuus oli EAN-koodin, sillä se ei ollut järjestelmän luoma. Tämän lisääminen lähdekoodiin oli vaikeaa, koska en ollut varma, miten sen tunnus piti kirjoittaa. Lopulta sain selville, missä muodossa Items-alalistan sarakkeiden tietokentät pitää lisätä.

Seuraavaksi piti tehdä konvertointi. Jotta tämä saataisiin tehtyä, aloitin itse painikkeen teosta. Tässä vaiheessa siirryin käyttämään pelkästään SuiteScriptiä. Kuten muidenkin vaiheiden kanssa, tämäkään ei sujunut ongelmitta. Minulla oli suurin vaikeus saada painike ilmestymään oikealla tavalla. Konvertoinnin kohdalla piti saada painike ilmestymään ennen kuin kyseinen sivu latautuu käyttäjälle eli piti käyttää beforeLoad-funktiota (kuva 3). Tätä varten tarvitsin myös oman funktion. Ongelmana tässä oli, että tekemääni funktiota ei ollut määritelty järjestelmän mukaan. Lopulta tutkin mallikoodia tarkemmin ja sain selville, että oma funktio piti lisätä toiseen tiedostoon ja kutsua se beforeLoad-funktiossa käyttämällä kyseisen tiedoston tunnusta.

Kuva 3. Kuvakaappaus mallikoodista konvertointipainikkeen tekemiseen. Koodissa on if-lauseen alla metodi, jota myös käytin omassa koodissa kutsuakseni omaa funktiota.

Sain lopulta painikkeen näkyville, mutta se oli vielä toimintoa vailla. Aloin sitten kehittämään konvertointia, jonka pitäisi käynnistyä, kun painiketta painetaan. Tätä varten kokeilin ensin transform-metodia (kuva 4), jonka avulla voi muuttaa yhden ilmentymän yhdestä Record Type -tyypistä toiseen tyyppiin. Tämä olisi todennäköisesti muuten toiminut, mutta tässä vaiheessa tuli selväksi kuinka erilaisia tarjouspyyntö ja ostotilaus ovat. Ostotilaus vaikutti olevan Record Type -tyyppiä, mutta tarjouspyyntö oli Transaction Type -tyyppiä. Tämän vuoksi päädyttiin käyttämään toista keinoa eli siirtämään yksitellen eri tiedot ostotilaukseen setValue-metodilla. Aloin jo ymmärtää miten kyseinen koodi olisi pitänyt kirjoittaa, mutta valitettavasti minulta loppui aika. Tämä tarkoittaa sitä, että en saanut konvertointia kokonaan tehtyä ja lopullinen testaus jäi tekemättä. Olin kyllä koko prosessin aikana testannut yksittäisiä toimintoja, joten moduuli ei jäänyt kokonaan testaamatta.

Kuva 4. Kuvakaappaus mallikoodista, jossa on käytetty transform-metodia.

Kokemukset opinnäytetyöstä

Tämän opinnäytetyön tekeminen oli monella tapaa uutta ja haastavaa. Opinnäytteessä käytin teknologioita NetSuitesta, joita olin käyttänyt aiemmin. Haaste tuli siinä, että niitä piti käyttää vähän eri tavalla tällä kertaa. Samalla tuli enemmän käytettyä SuiteScript-koodikieltä, joka muistuttaa JavaScript-kieltä, joka helpotti SuiteScriptin ymmärtämistä. Mielestäni etenin tehtävissä muuten ihan hyvin, mutta kokemuksen puute hidasti prosessia, mikä vaikutti aikatauluun. Myös opinnäytteen aloitus ajoittui myöhemmäksi kuin mitä olisin halunnut, koska aiheen hyväksynnässä tuli mutkia matkaan. Tämä lyhensi tekoaikaa varmaan jopa kuukaudella tämän vuoksi, mikä jäi minua harmittamaan. Sain kuitenkin suurimman osan tehtyä kaikesta huolimatta, mikä on hyvä saavutus. Ensi kerralla samankaltaisen prosessin alkaessa huolehdin, että samanlaisia viivästyksiä ei tulisi. Näin saisin varmasti kaikki tehtyä.

Tekstin kirjoitti,

Jenni-Maria Juurikka

Tradenomin tutkinto-ohjelman opiskelija (TIK20SP)

Lähteet:

[1] Magal, Simha & Word, Jeffrey 2011. Integrated Business Processes with ERP Systems. New Jersey: John Wiley & Sons. Hakupäivä 19.9.2023. O’Reilly.

[2] McCue, Ian 2023. What is NetSuite ERP & How Does It Work? Hakupäivä 18.9.2023. https://www.netsuite.com/portal/resource/articles/erp/what-is-netsuite.shtml.