Extern utläggsregistrering med Microsoft Dynamics AX FREDRIK ANDERSSON

Transkript

1 Extern utläggsregistrering med Microsoft Dynamics AX FREDRIK ANDERSSON Examensarbete Stockholm, Sverige 2009

2 Extern utläggsregistrering med Microsoft Dynamics AX FREDRIK ANDERSSON Examensarbete i datalogi om 30 högskolepoäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2009 Handledare på CSC var Kjell Lindqvist Examinator var Stefan Arnborg TRITA-CSC-E 2009:068 ISRN-KTH/CSC/E--09/068--SE ISSN Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC Stockholm URL:

3 Sammanfattning När företaget Medius de senaste åren har växt i snabb takt, har dess tidigare rutiner börjat bli för långsamma och ineffektiva. Framförallt har det märkts av på ekonomisidan där delar av arbetet fortfarande sker manuellt, vilket beror på att fler anställda har gjort att det vanliga rutinarbetet tar längre tid än tidigare. För att effektivisera sina egna rutiner har man därför valt att använda sig av affärssystemet Microsoft Dynamics AX. Det här arbetet har syftat till att undersöka och utvärdera olika sätt att registrera utlägg utanför Microsoft Dynamics AX klient, samt implementera en prototyp av vald lösning. Den valda lösningen har sedan utvärderas ur ett användarvänlighets perspektiv. Valet av prototyp föll på en webbkontroll till Enterprise Portal som uppfyller de krav som arbetades fram med beställaren innan utvecklingen påbörjades. Genom att en enkätundersökning genomförts med en testgrupp efter utvecklingen har det säkerställt att de anställda är villiga att använda produkten samt anser att den är enkel att använda. För att veta att prototypen underlättar och stödjer ekonomipersonalen i dess arbete har de varit involverade i utvecklingen genom att intervjuer genomförts i slutskedet av utvecklingen. Abstract External expense management with Microsoft Dynamics AX When the company Medius through the last couple of years rapidly has grown, their routines have slipped after and became too slow and inefficient. Especially on the economy side where parts of the work still is handled manually. There the work has begun to take longer time due to the increasing number of employees. To be able to make the routines more efficient they chose to use the business system Microsoft Dynamics AX. This work has been aimed to examine and evaluating different ways to register expenses outside the client of Microsoft Dynamics AX and implement a prototype of chosen solution. That solution has after been evaluated from a user friendly perspective. The selection of prototype fell on a web-control to Enterprise Portal, which fulfills all the demands that were set out from the originator before the development began. Through a survey that was done with a test group after the development was done, it has been ensured that the employees of Medius are willing to use the product and that it is easy to use. To ensure that the prototype facilitates and supports the economy staffs work, they have been involved in the development through interviews that have been done towards the end of implementation phase.

4 Förord Det här är mitt examensarbete inom min utbildning Civilingenjör Datateknik som har utförts vid Kungliga Tekniska Högskolan i Stockholm, på uppdrag av företaget Medius AB. Jag vill tacka de som har ställt upp på frågor, intervjuer samt undersökningar på Medius och har bidragit med sin dyrbara tid för att göra det här arbetet möjligt. Ett varmt tack till Eva Eriksson och Caroline Lindén som har ställt upp på frågor om ekonomiska lagar och regler. Jag vill även tacka mina handledare Kjell Lindqvist, KTH, och Olof Wallin, Medius, för att de har bidragit med råd och hjälp under arbetets gång. Ett tack går även till min pappa Kjell för att han korrekturläst rapporten.

5 Innehållsförteckning 1 Inledning Bakgrund Problem Syfte Litteraturstudie Resursplanering Microsoft Dynamics AX Utvärdering av användarvänlighet Metod Scrum Roller i Scrum För- och nackdelar med Scrum Utrustning Regler att ta hänsyn till Traktamenten Milersättning Val av prototyp Implementering Användningsfall Enterprise Portal Extern Applikation med MS.NET Business Connector Webbkontroll till Enterprise Portal Microsofts lösning Medius lösning Extern Applikation Med MS.NET Business Connector Modifieringar av kärnan i Dynamics AX Modifikationer av befintliga tabeller Nya tabeller Övriga ändringar Utvärdering Första intervjun Andra intervjun Enkätundersökning Resultat Slutsats...29 Litteraturförteckning...30 Appendix A: Enkät...31 Appendix B: Enkätresultat...32

6

7 1 Inledning 1.1 Bakgrund Företaget Medius grundades 2001 och är ursprungligen från Linköping, där även dagens huvudkontor ligger. Det område som företaget framförallt har arbetat med är att ta fram ett workflowsystem, för att underlätta ett företags processer som inte stöds av deras befintliga affärssystem. Den första utgåvan av deras workflowsystem, MediusFlow, kom ut våren 2002 och har sedan dess även anpassats för den internationella marknaden. När företaget öppnade sitt stockholmskontor ökade kundstocken stort, vilket har lett till att kontor även har öppnats i Göteborg och Eskilstuna (Medius, 2009). När företaget Medius de senaste åren har växt i snabb takt, har dess tidigare rutiner börjat bli för långsamma och ineffektiva. Framförallt har det märkts av på ekonomisidan där delar av arbetet fortfarande sker manuellt och har till följd av fler anställda, gjort att det vanliga rutinarbetet tar längre tid än tidigare. För att effektivisera sina egna rutiner har man därför valt att använda sig av affärssystemet Microsoft Dynamics AX (skrivs i fortsättningen, Dynamics AX) (MSDN, 2009a), vilket riktar sig till mellanstora företag. I Dynamics AX finns det sedan tidigare en möjlighet att registrera arbetstimmar och utlägg mot ett projekt. Där definieras ett utlägg som en betalning som en anställd har gjort och för vilken han/hon vill få ersättning för. I standardutförandet av Dynamics AX finns det möjlighet att hantera både arbetstimmar och utlägg via applikationens klient. För att kunna vara flexibla och undvika att behöva installera klienten på alla anställdas datorer, finns här ett behov av att kunna registrera både arbetstimmar och utlägg utanför klienten. Sedan tidigare finns det hantering för att på ett tillfredsställande sätt registrera arbetstimmar utanför klienten men dock inte för utlägg. Hanteringen som finns för att registrera utlägg är inte anpassad till den svenska marknaden, utan programutvecklarna har troligen fokuserat på den amerikanska. I dagens läge skickar därför Medius anställda en utläggsrapport via brev till ekonomiavdelningen, som sedan hanterar rapporten manuellt och matar in de transaktionerna som ska göras i systemet. Den anställde får sedan ersättning vid nästa löneutbetalning. Enligt bokföringslagen (1999:1 078, 4 kap), måste alla bokföringsposter ha verifikationer. Det leder till att den anställde alltid måste skicka in sina kvitton tillsammans med sin utgiftsrapport, innan en transaktion kan bokföras. Därför kan man inte komma ifrån hanteringen av kvitton vid utläggshantering. Däremot skulle registreringen av transaktionen kunna ske elektroniskt, vilket i sig skulle effektivisera arbetet för ekonomipersonalen avsevärt. 1.2 Problem Uppgiften syftar till att undersöka och utvärdera olika alternativa lösningar för hur utlägg ska kunna registreras utanför Dynamics AX egen klient, samt att implementera en prototyp av den valda lösningen. Användarkraven på prototypen ska tas fram med hjälp av företagets ekonomipersonal, eftersom de är huvudbeställarna av uppgiften. 1.3 Syfte Syftet med arbetet är att ta fram en användarvänlig prototyp för extern utläggsregistrering, som både ekonomiansvariga och anställda är nöjda med. 1

8 I första hand syftar uppgiften till att underlätta arbetet för de ekonomiansvariga och i andra hand göra det enkelt för företagets anställda att registrera utlägg, oavsett var de befinner sig med möjlighet att koppla upp sig mot företagets intranät, dvs. antingen vid något av företagets kontor eller via en VPN 1 -anslutning. 2 Litteraturstudie När man gör ett stort arbete som examensarbetet, krävs det att man först gör en studie över vad som tidigare har gjorts inom området för att sätta sig in i uppgiften. De försök som gjordes för att hitta forskning inom området blev dock resultatlösa. Efter att ha funderat på vad en förstudie skulle kunna innehålla, kom jag till sist fram till att det skulle vara bra att läsa in sig på det affärsområdet som arbetet ändå hamnade under, nämligen ERP 2 -system, för att kunna få en övergripande förståelse för vad den typen av system gör för ett företag, samt hur utvecklingsprocessen ser ut för dessa system, se kapitel 2.1. Då systemet som en anpassning skulle skapas för, var Microsoft Dynamics AX 2009, föll det naturligt att läsa in sig på hur den programvaran är konstruerad, samt hur dess olika komponenter var sammankopplade och kommunicerar. Dessvärre släpptes en ny version av Dynamics AX under sommaren 2008 vilket har lett till att det ännu (13 Mars-2009) inte finns något tryckt material om den senaste versionen, utan de böcker som fanns tillgängliga var för en tidigare utgåvor, se kapitel 2.2. Som en avslutning av arbetet ska en utvärdering av en vald prototyp göras med hjälp av en enkätundersökning. Det medförde att jag även behövde läsa in mig på hur en sådan görs på bästa sätt med avseende på användarvänlighet, se kapitel Resursplanering Kapitlet är ett litteraturreferat av (Sumner, 2004). Litteraturen tar upp grunderna över vad ett ERP-system kan göra för att effektivisera ett bolag. Genom att använda ett ERP-system finns en möjlighet att omstrukturera olika affärsprocesser inom en organisation. Framförallt kan processerna förenklas och affärsreglerna förbättras. Att omstrukturera med hjälp av ett ERP-system ger organisationer möjligheten att lättare ta till vara förändringar på marknaden, samt anpassa sig till dessa. Skillnader mellan utveckling av ERP-system och traditionella informationssystem diskuteras i boken. Mitt intryck av boken, är att huvudfrågan för utvecklingsteamet vid utveckling av ERP-system, är att avgöra om systemet ska anpassas till nuvarande affärsprocesser eller om affärsprocesserna istället ska anpassas till systemet. Enligt boken leder den frågan till ett stort ansvar för utvecklarna då de dels måste reda ut fördelarna med de olika lösningsalternativen, dels även försöka övertyga beställaren om fördelarna respektive nackdelarna med den valda lösningen. En utvecklingsprocess av ERP-system följer enligt boken följande steg: A. Planering Skapa ett business case för ERP B. Kravanalys 1 VPN Virtual Private Network 2 ERP - Enterprise Resource Planning 2

9 Analysera affärsprocesser Specificera vilka processer som ska stödjas i systemet C. Design; omstrukturering av affärsprocess kontra anpassning av systemet Ifall processerna omstruktureras kan det leda till att organisationen blir ineffektiv, då det kan innebära ändringar i bland annat arbetsflöden och rutiner, medan en anpassning av systemet kan leda till svårigheter vid uppgraderingar till en nyare version. D. Alternativa designmetoder Ursprungsversionen från tillverkaren utan tillägg Anpassad version Endast göra tillägg för att stödja befintligt system E. Detaljerad design Här väljs designmetod och affärsprocesser samt vilken typ av information som ska stödjas av systemet F. Implementering Genom användning av ERP-system, underlättas arbetet för många olika avdelningar inom ett företag. Exempelvis får ledningen snabbare tillgång till försäljningssiffror, ekonomiavdelningen kan snabbare överblicka företagets finanser, både interna och externa kostnader. Därför att man med hjälp av systemet kan ansluta och publicera information från flera åtskilda databaser, som man tidigare behövde skilda system för att ansluta till. 2.2 Microsoft Dynamics AX Kapitlet är ett litteraturreferat av (Greef, Pontoppidan, & Olsen, 2006). Boken skapade en övergripande förståelse för hur Microsoft Dynamics AX är uppbyggt med dess olika delar: Databasservern, lagrar Dynmiacs AXs data i en databas Klienten, Dynamics AXs egentliga användargränssnitt Filservern, lagrar Dynamics AXs applikationsfiler Application Object Server 3, sköter all kommunikation mellan AXs olika delar Boken gav en inblick över hur applikationens modellager (Application model layering) är strukturerat, vilket beskrivs som den generella principen i Dynamics AX. Principen kan beskrivas som; om olika anpassningar är gjorda för en komponent i skilda lager, körs den anpassningen som är gjord högst upp i lagerstrukturen. Det ger en möjlighet för utvecklare att ändra om och anpassa programmet på ett enkelt sätt, oavsett var i lagerstrukturen anpassningen görs. Varje lager har en förkortning på tre bokstäver, till exempel står lagret USR för User-lagret, som är högst upp i strukturen och kan därför användas av utvecklare för att göra unika anpassningar på olika kundinstallationer. Trots att anpassningar görs, kan man ändå använda sig av en grundinstallation för alla kunder som senare kan anpassas efter specifika krav och önskemål. Kapitlet gav även en snabb förståelse för hur man navigerar efter programmets olika komponenter i AOT 4, se Figur 1. Som nämndes ovan med de olika lagren syns dessa förkortningar i AOT, ifall några ändringar har blivit gjorda för ett specifikt lager. 3 AOS Application Object Server 4 AOT - Application Object Tree 3

10 För att göra det enklare för ovana användare av Dynamics AX finns även en webbportal, Enterprise Portal (skrivs i fortsättningen EP), som bygger på Windows SharePoint Services. Genom EP kan användare komma åt relevant information och genomföra transaktioner utan att behöva använda sig av klienten. I Dynamics AX har varje användare en specifik roll och för varje roll finns det ett fördefinierat tema för EP, som utvecklarna av Dynamics AX tror att en person med en speciell roll efterfrågar. Figur 1: Visar hur Application Object Tree ser ut och visar de olika typerna av komponenter som finns i Microsoft Dynamics AX. 2.3 Utvärdering av användarvänlighet Kapitlet är ett litteraturreferat av (Rogers, Sharp, & Preece, 2002). Enligt boken finns det fyra stycken huvudtyper av intervjuer: öppen, strukturerad, semistrukturerad och grupp. Där gruppintervju innebär att intervjuaren ger en grupp människor ett par ämnen att diskutera, medan de övriga intervjutyperna beror på hur mycket intervjuaren försöker styra konversation med fördefinierade frågor. Tips om hur frågorna bör och inte bör utformas tas upp, bland annat bör man enligt litteraturen undvika långa och sammansatta frågor, samt ledande frågor. Det är istället bättre med kortare entydiga frågor och om det behövs, kan följdfrågor ställas. Intervjuupplägg med olika faser behandlades. Där bör man tänka på att inte börja med intervjun direkt, utan ställa ett par uppvärmande frågor först och några lättare avslutande frågor efter huvudfrågorna. Litteraturen gav även praktiska tips om klädsel, uppförande, utrustning, etc. där grundprincipen är att vara professionell. Man fick även bra tips på hur frågeformulären och frågorna på dessa bör utformas. Generellt kan man säga att principen är densamma som vid en intervju, fast med 4

11 undantaget att försöka få till så pass väldefinierade svarsalternativ som möjligt när det ges. Användande av svarsskalor bör vara konsekvent och följa samma mönster. Ett tydligt exempel är att om 5 är bra på en fråga ska inte 5 vara dåligt på en annan. Vid skapandet av formulären måste man även fundera på hur stora skalor man egentligen behöver. Ju fler svarsalternativ desto svårare blir det för den svarande att ge en korrekt bedömning, vilket även kan uppstå åt motsatt håll, med för få alternativ. Oavsett om det görs en muntlig intervju eller om ett frågeformulär används, bör frågorna testas på ett par personer först: för att undvika att intervjupersonerna inte förstår frågan, att svarsalternativ saknas men även för att upptäcka följdfrågor som inte intervjuaren tänkt på tidigare. Testerna ger även en inblick ifall svarsskalorna är för smala eller breda. 3 Metod Valet av metod föll på Scrum (Wikipedia, 2009c) av den enkla anledningen att företaget Medius har börjat arbeta efter Scrum i sitt utvecklingsarbete. För systemutveckling finns det ett flertal andra metoder som hade kunnat vara tillämpbara i mitt arbete, till exempel Vattenfallsmetoden, RUP 5 eller spiralmodellen (Tonnquist, 2006). Även om det inte var något som helst krav från Medius sida att mitt arbete behövde följa Scrum, valde jag att använda mig av den utvecklingsmodellen. Dels för jag tyckte att det kunde vara intressant att arbeta efter en ny modell, och dels för att jag tyckte att det var lämpligt att använda mig av en modell där fokusen i utvecklingen snabbt kunde ändras ifall det skulle behövas, vilket var ganska troligt att det skulle kunna ske om till exempel någon del av utvecklingen skulle dra ut på tiden. Scrum prioriterar kvalitet före omfattning, vilket leder till att det som levereras oftast håller hög kvalitet men kanske inte med tillräcklig funktionalitet, vilket är bra i många fall. Om vi ser till vårt fall ska två prototyper tas fram, vilket leder till att kvalitén blir viktigare än omfattningen, eftersom vår prototyp syftar till att ge användaren en bild av hur en slutlig produkt eventuellt kan se ut. Därför behöver den inte tillhandahålla all önskad funktionalitet vid projektets slut. Det som talar emot mitt val av metod är att antalet personer som kan räknas till utvecklingsgruppen, inte når upp till det rekommenderade antalet. Däremot kan det tyckas vara en fördel att gruppen blev mindre, då det blev lättare att kommunicera och organisera möten. Även prioriteringar kunde ändras under samma dag ifall något problem uppstod. Om vattenfallsmodellen använts hade inte fokus kunnat ändras lika snabbt, eftersom arbetet då hade utförts seriellt och en del av arbetet hade behövt vara klar innan nästa del av arbetet påbörjats (Wikipedia, 2009a). Däremot hade RUP kunnat används då den metoden är indelad i fyra olika faser: förberedelse, etablering, konstruktion och överlämning. Där varje fas har en eller flera iterationer och avslutas med en väldefinierad milstolpe per fas (Wikipedia, 2009b). Likaså hade spiralmodellen eller någon annan modell/metod som har ett dynamiskt lösningsförfarande i fokus kunnat användas. I en metod med dynamiskt lösningsförfarande, kan fokus ändras snabbt utan att en viss del måste vara avslutad innan nästa påbörjas. 5 RUP - Rational Unified Process 5

12 3.1 Scrum Scrum är en metodik för systemutveckling som ofta används vid agil systemutveckling (Wikipedia, 2009c) och introducerades av Ken Schwaber och Jeff Sutherland. Inom agil (Wikipedia, 2009d) systemutveckling ligger ofta fokuset i utvecklingen på utvecklingsiterationer, samarbete, lagarbete och att kunna anpassa utvecklingsprocessen genom processens livscykel. I Scrum ligger fokus framförallt på utvecklingsarbetet och processen inleds därför med en kravbild, product backlog. Vilken innehåller prioriteringar som är gjorda av verksamheten och grova tidsuppskattningar som är gjorda av projektgruppen. Processen kan beskrivas med hjälp av Figur 2. Utvecklingen sker i iterationer, för Scrum så kallade sprintar, som alla inleds med en planering och avslutas med en demonstration inför projektets intressenter. Innehållet i demon bestäms under planeringen, demon kallas för sprint review(systemvaruhuset, 2008). Under planeringen inför varje sprint läggs prioriteringar för verksamheten fram av produktägaren. Projektgruppen har under planeringen en möjlighet att ställa frågor på de kraven som har lagts fram av produktägaren, för att på ett enklare och bättre sätt kunna uppskatta tidsåtgången per uppgift/aktivitet. Om det visar sig att vissa uppgifter eller aktiviteter troligen kommer ta längre tid, än vad som finns tillgängligt för den aktuella sprinten, får produktägaren välja vilka aktiviteter som ska tas bort för tillfället och avvakta med dessa till nästkommande sprint. Resultatet av planeringen genererar en aktivitetsplan, sprint backlog, för den planerade sprinten. Under en sprint sker korta statusmöten, så kallade daily scrums, där varje deltagare svarar på: Vad har jag gjort sedan igår? Vad ska jag göra tills imorgon? Vad hindrar mig? Som avslutning på en sprint hålls ett förbättringsmöte, sprint retrospective, där arbetet under sprinten utvärderas och analyseras. För att gruppens arbete ska förbättras och för att den inte ska göra samma eventuella misstag i framtiden. 6

13 Figur 2: Beskriver hur Scrum-processen ser ut. Från första planeringen till slutleveransen Roller i Scrum Inom Scrum finns det tre definierade roller som alla är beroende av projektets resultat. De olika rollerna är produktägare, processledare och gruppmedlem. Om en person inte har någon eller några av dessa roller får han eller hon inte utrycka sig vid de olika planerings-, prioriterings- eller statusmötena. En kort beskrivning av de olika rollerna följer nedan: Produktägare (Product owner) Motparten för projektgruppen. Ansvarar för kravbilden, samt hanterar och prioriterar nyinkomna krav och önskemål. Processledare (ScrumMaster, Facilitator) Motparten för produktägaren. Likställs ibland felaktigt med en traditionell projektledare. Då gruppen är självorganiserande finns inte behovet av en traditionell projektledare. Processledaren är ansvarig för att säkerhetsställa processens efterlevnad, samt synkroniserar uppgifterna mellan olika aktörer samt avlägsnar hinder för utvecklarna. Team Ansvariga för att leverera produkten. Då gruppen är självorganiserande finns inte heller några fördefinierade roller. Utan gruppen bestämmer efter hand vem som är ansvarige för vad. Gruppen bör bestå av 5-9 personer För- och nackdelar med Scrum Som med alla olika utvecklingsmetoder finns det för- och nackdelar även med Scrum. Vi ska under denna rubrik lista några av dessa. Fördelar Gruppen blir självständig, vilket förhoppningsvis leder till högre motivation och effektivitet. Bibehållet fokus, alla gruppmedlemmarna vet vad som ska göras under den gällande sprinten. Genom att man utför en planering inför varje sprint, kan inriktningen på utvecklingen ändras mellan varje sprint. 7

14 Nackdelar Inom Scrum görs prioriteringar efter ordningen: kvalitet, leveranstid och omfattning. Det gör att man vid tidsbrist väljer att skära ned på omfattning med bibehållet fokus på kvalitet, vilket är bra. Tyvärr fungerar det inte i vissa fall, där man kan behöva bibehålla omfattning och leveranstid. Ett typiskt sådant fall är när ledningen lovat eller sålt en viss lösning till en kund. Nackdelen blir då att kvaliteten på produkten prioriteras ner till fördel för omfattningen. 3.2 Utrustning Arbetet har utförts på en från företaget tilldelad bärbar PC av märket Lenovo med modellnummer Z61p. Den har haft operativsystemet Microsoft Windows XP Professional med Service Pack 3 installerat. För utvecklingen har det använts en virtuell maskin i form av Microsoft Virtual PC. På den virtuella maskinen har jag använt mig av operativsystemet Microsoft Windows Server 2003 R2 - Standard Edition. I den här miljön har även Microsoft Dynamics AX 2009 och Microsoft SQL Server 2005 varit installerade, samt utvecklingsverktyget Microsoft Visual Studio Regler att ta hänsyn till Under arbetets gång har vi behövt lära oss hur vi ska kunna tillmötesgå de skattereglerna som finns i Sverige vid utbetalning av traktamenten och milersättning. I det här kapitlet ges därför en kortfattad beskrivning av vad som gäller för dessa. Reglerna som beskrivs i kapitlet baseras på information som har hämtats från skatteverkets hemsida (Skatteverket, 2009). 4.1 Traktamenten Arbetsgivaren kan betala ut traktamente till sina anställda vid tjänsteresor, för att täcka en del av de ökade levnadskostnader som uppkommer för den anställde under tjänsteresan. Den anställde kan få en ersättning av tre olika slag: hel- och halvdagstraktamente samt även en så kallad nattschablon. Hel- och halvdagstraktamenten beror på när resan har påbörjats och avslutats, medans nattschablon betalas ut till den anställde om denne har eget boende på orten som besökts. Om resan har påbörjats innan kl eller avslutats efter kl ska ett heldagstraktamente betalas ut. Om däremot resan påbörjats efter kl eller avslutas innan kl ska ett halvdagstraktamente betalas ut. Avdrag för traktamentsersättningen görs om den anställde har haft måltider som ingått och inte har behövt betala för dessa själv. Vid resor inom Sverige är avdragen fasta belopp medans avdragen är en procentdel av dagsersättningen vid utrikesresor. Det skattefria beloppet är olika för olika länder och fastställs av Skatteverket. Ett traktamente kan endast betalas ut ifall tjänsteresan inkluderar en övernattning. (Skatteverket, 2009) 8

15 4.2 Milersättning I Sverige kan arbetsgivaren betala ut en skattefri ersättning till den anställde ifall denne har använt sig av en bil i tjänsten. Arbetsgivaren måste dock även betala för en skattepliktig del. I Sverige beror ersättningen till den anställde på ifall denne har kört en egen bil eller haft tillgång till en tjänstebil. Om den anställde haft tillgång till tjänstebil, beror den skattefria ersättningen på ifall bilen varit bensin- eller dieseldriven. Den skattepliktiga delen för företaget är dock densamma oberoende på typ av tjänstebil. Däremot skiljer sig den skattepliktiga delen åt, beroende på om den anställde har kört en egen bil eller en tjänstebil. (Skatteverket, 2009) 5 Val av prototyp När vi ska välja vilka prototyper som vi ska utveckla gäller det att välja en teknik som är enkel att utveckla grafiska gränssnitt i och som även är enkel att ansluta till den interna nätverketsinstallation av Dynamics AX. Genom att kräva att den anställde måste vara inloggade på det interna nätet innan en utgiftsrapport ska kunna skapas, tar detta bort mycket av säkerhetsfokusen från uppgiften, dels genom att kommunikationen med AOS:n inte behöver krypteras ytterligare då kommunikationen sker internt och dels att vi inte behöver ta hänsyn till yttre hot. Som yttre hot avses att människor utifrån inte ska kunna komma åt den information som finns i den interna AX-databasen. Vi behöver därför då endast fokusera på att personer inte ska kunna se andras rapporter om de inte ska godkänna den Detta är en av anledningarna till att valet av en webbkontroll till EP föll företaget i smaken redan innan arbetet påbörjades. Den andra är att de redan använder sig av EP för att registrera tid, vilket de också måste göra när de är ute på resor, och är alltså redan bekanta med hur EP fungerar och behöver därför inte lära sig allt från början igen, som kan bli fallet ifall ett nytt program introduceras. Om vi tittar på säkerheten med EP, finns det sedan tidigare mycket inbyggd funktionalitet. Bland annat kontrolleras ifall användaren är betrodd och ska ha tillgång till en viss rapport, samt ett par övriga kontroller som till exempel ifall en användare försöker öppna en annans utgiftsrapport genom att mata in adressen till sidan och manuellt ange ett utgiftsrapportnummer. För den externa prototypen har grundkraven varit att den ska byggas med Microsoft.NET Business Connector, vilket är det enda sättet för att utifrån kommunicera med en installation av Dynamics AX. Det leder till att den andra prototypen måste använda sig av ett av de språk som tillhör.net Framework nämligen C# eller VB.NET. Då författaren sedan tidigare inte har någon erfarenhet av VB.NET föll valet naturligt på att utvecklingen skulle ske i C#, där han sedan tidigare har grundkunskaperna om språket. Oavsett vilket språk som hade valts, finns det en möjlighet att använda sig av något av de Frameworks för presentation som Microsoft har tagit fram. De som finns att välja på är Windows Presentation Foundation, WPF, och Microsoft Silverlight, vilket är en nyare version av WPF, alternativt bara använda sig av de vanliga komponenterna som finns för en applikation med Windows Form, WF. WPF ger en möjlighet att skapa grafiska användargränssnitt som kombinerar olika typer av animationer med film och musik. Det kan köras både i en webbläsare och separat i en vanlig applikation. (Wikipedia, 2009e). Microsoft Silverlight är en ny teknik för att presentera information på webbsidor. Den tillhandahåller möjligheterna till att skapa rikare visuella gränssnitt och kan köras på de 9

16 mest använda operativsystemen (Microsoft, 2009). Den bygger på den tidigare varianten av WPF som hade tillägget Everywhere och anses vara en konkurrent till Adobe Flash. (Wikipedia, 2009f). Skillnaden är huvudsakligen att om WPF eller Silverlight används kommer gränssnittet få ett bättre utseende och inte bli lika kantigt som komponenterna för WF har. Däremot är den bakomliggande kodens logik i princip densamma och bygger på C#. Vilket innebär att om man väljer WF kan den i framtiden utvecklas till att använda WPF eller Silverlight. Arbetet råkade utför tidsbrist under utvecklingen vilket ledde till att tiden som kunde läggas på den andra prototypen blev begränsad. Det i sin tur ledde till att möjligheterna att läsa in sig på en ny teknik minskades ner. Till följd av detta valdes prototypen att utvecklas med hjälp av en Windows Form applikation, utan användning av någon ytterligare presentationsteknik. Om mer tid funnits tills förfogande hade prototypen utvecklats med hjälp av Microsoft Silverlight. 6 Implementering Innan implementeringen påbörjades utfördes en intervju med Medius ekonomichef. För att säkerhetsställa vilka krav som produkten i slutändan skulle uppfylla. Efter intervjun skrevs tre användningsfall, Use Cases, två för prototypen till Enterprise Portal och en till den externa applikationen. Det ursprungliga upplägget för implementeringen hade tre skilda implementeringsprocesser: modifiering av kärnan, web control till Enterprise Portal, extern applikation med.net Business Connector (skrivs från nu.net BC). När våra användningsfall var skrivna upptäcktes det att det ursprungliga upplägget inte skulle fungera. Anledningen till att det inte skulle fungera var att det inte direkt gick att urskilja vilken funktionalitet som skulle behöva modifieras eller läggas till i kärnan, genom att endast studera de användningsfall som hade skapats. Arbetet med modifieringar av kärnan har därför utförts parallellt med utvecklingen av den webbkontroll som används i Enterprise Portal. I texten nedan kommer de därför att särskiljas åt, för att göra det enklare för läsaren att se vad som är gjort var. När man arbetar med att modifiera ett så här stort och avancerat program som Dynamics AX är, gäller det att hålla koll på de beroenden som finns mellan de olika komponenterna som finns i kärnan. Detta har under arbetets gång lett till att utvecklingen har dragit ut på tiden och för att inte överskrida den tiden som hade satts upp från början, gavs instruktioner om att fokusera på den ena prototypen och få den så klar som möjligt från handledaren på företaget. Den prototyp som det har fokuserats mest på är webbkontrollen till EP. För de båda prototyperna har programmeringsspråket C# använts. 6.1 Användningsfall För att förstå hur en registrering av ett utlägg tidigare har gått till och hur det i framtiden är tänkt att gå till, skapades tre olika användningsfall. Tanken med att det endast är ett användningsfall för den externa applikationen med.net BC. Är att en utläggsrapport endast kan godkännas ifall du har tillgång till de kvitton som ska finnas för respektive utlägg som finns i en utläggsrapport. Dessa kvitton ska inte lämna kontoret och då kan inte heller en rapport godkännas utanför kontoret. 10

17 I den tidigare varianten av utläggsregistrering för EP, fanns funktionalitet för godkännanden av utlägg och därför finns det nedan ett use case för godkännande av utläggsrapporter i EP Enterprise Portal Vi antar att personen har navigerat till sidan Hantera utgifter. (Startsida > Medarbetare tjänster > Hantera utgifter) Ny utgiftsrapport I. Välj Ny utgiftsrapport i. Mata in: Utgiftssyfte Datum för rapport Plats Eventuell beskrivning Välj projekt för utlägget ii. Klicka på knappen OK. II. Lägg till en ny rad med hjälp av rullgardinslistorna under Traktamente, Milersättning eller Utlägg, bekräfta valet med knappen Gå. i. Mata in: Transaktionsdatum Transaktionsbelopp ii. Bekräfta med bock-tecknet. iii. Om utgiften är av typ Traktamente Mata även in o Utresedatum med klockslag o Ankomstdatum med klockslag o Hemresedatum med klockslag o Hemankomstdatum med klockslag o Land för vistelsen Milersättning Mata även in o Antal mil Utlägg Mata även in o Ytterligare information III. Om rapporten är klar i. välj Skicka samt till vem ni vill skicka i rullgardinlistan bredvid ii. Alternativt Spara om ni vill kunna göra ändringar senare IV. Om inte, upprepa steg II-III Godkännande Av Utgiftsrapport I. Välj Godkänn utgiftsrapporter i. Välj en rapport i listan Välj Godkänn eller Avslå Eller skicka rapporten till någon annan för godkännande 11

18 6.1.2 Extern Applikation med MS.NET Business Connector Ny Utgiftsrapport I. Välj Ny utgiftsrapport i. Mata in: Utgiftssyfte Datum för rapport Plats Eventuell beskrivning Välj projekt för utlägget ii. Klicka på knappen Skapa. II. Lägg till en ny transaktion med hjälp av menyvalen Traktamente, Milersättning eller Utlägg i menyn Utgiftstyp. i. Mata in: Transaktionsdatum Utgiftskategori Transaktionsbelopp ii. Om utgiften är av typ Traktamente Mata även in o Utresedatum med klockslag o Ankomstdatum med klockslag o Hemresedatum med klockslag o Hemankomstdatum med klockslag o Land för vistelsen Milersättning Mata även in o Antal mil Utlägg Mata även in o Ytterligare information III. Om rapporten är klar, välj Skicka samt till vem ni vill skicka i rullgardinlistan bredvid. IV. Annars upprepa steg II-III. 6.2 Webbkontroll till Enterprise Portal Då det följer med en utläggsregistrerare till EP med Dynamics Ax var den ursprungliga tanken att det endast skulle behöva göras modifieringar av denna för att få till en tillfredsställande lösning. Tyvärr var den befintliga webbkontrollens kod i princip helt okommenterad vilket ledde till att den var mycket krånglig och svår att följa. Efter att försökt sätta sig in i den befintliga koden under ett par dagar, togs beslutet tillsammans med handledaren på företaget att vi skulle skapa en helt ny webbkontroll och lyfta ur de delarna som var förståliga från den befintliga webbkontrollen. De delarna som är från den befintliga kontrollen är utmärkta med kommentarer i koden. Gemensamt för de båda lösningarna som vi kommer att gå igenom är att skapandet av en ny rapport, se Figur 3, ser lika ut oberoende av vilken webbkontroll som används. Vid 12

19 skapandet av en ny rapport måste användaren ange ett par grunddata till exempel vilken dag rapporten skapats, varför transaktionerna har gjorts, etc. Figur 3: Visar hur sidan för skapandet av en ny utgiftsrapport ser ut Microsofts lösning Eftersom den befintliga webbkontrollens kod i princip var helt okommenterad var den svår att följa och förstå. De delarna som ställde till störst problem, var framförallt de metoder som såg till att ett utlägg kunde brytas ner i mindre delar, till exempel kunde en utgift för en hotellvistelse delas upp i kostnad per natt, där varje natt kunde behandlas som en separat transaktion i Dynamics AX klient senare. Dessutom gick det att sätta upp olika policys och regler för varje utläggstyp, med olika avsändare. Till exempel kunde det projektet som utlägget registreras mot, ha definierat en kostnadspolicy och sen kunde även ekonomiavdelningen ha satt upp en policy för utgiftstypen. Mycket av det som fanns i den befintliga lösningen var bra och vettigt, som med stor sannolikhet skulle kunna vara till stor nytta för företaget. De delar som inte lyftes ur av de som vi förstod oss på, får räknas som eventuella framtida tillägg. För att ge läsaren en inblick av över hur den lösningen såg ut har Figur 4 tagits med. Den visar att det fanns en så kallad AxGridView som listar de transaktionerna som hör till utgiftsrapporten. En AxGridView kan beskrivas som en komponent som visar information för användaren ifrån en Dynamics AX-specifik datakälla, AxDataSource (MSDN, 2009b). För varje utgift anges en utgiftskategori som är kopplad till en utgiftstyp. Utgiftstyperna är definierade som en enum i Dynamics AX. Det som var intressant med lösningen ovan var att för varje utgiftskategori visades olika fält beroende på vilken utgiftstyp de hade. 13

20 Figur 4: Visar hur den befintliga utläggsregistreraren ser ut och att det endast finns en AxGridView för att visa de olika transaktionerna. För inskickning och godkännande av rapporter används ett Workflow (MSDN, 2009c), tyvärr var den baserad på att olika policys som diskuterats tidigare. Om inte rapporten följer de policys och regler som finns uppsatta, kommer det inte heller gå att skicka in den förrän dessa är åtgärdade Medius lösning Som inledning på kapitlet beskrivs den övergripande idén med den nya lösningen och dess design. Som en grund ville vi få en mer strukturerad uppdelning av transaktionerna baserade på utgiftstypen. Istället för att visa olika fält beroende på vilken utgiftskategori i en AxGridVew, valde vi att ha tre olika AxGridViews: en för traktamenten, en för milersättning och en för övriga utlägg (se Figur 5). Om vi jämför hur den gamla lösningen (Figur 4) och hur den nya lösningen (Figur 5) ser ut, kan vi se att det ändå finns några likheter. I båda lösningarna finns den översiktliga rapportinformationen högst upp på sidan med. I den till höger står rapportens totala belopp. Även några av länkarna nere till vänster på sidorna finns med i båda lösningarna. Vid en första anblick kan det kanske tyckas att den nya layouten ser lite rörig ut. Den har ändå sina fördelar gentemot den gamla. Dels blir det lättare att direkt veta vad en utgift hör till för utgiftskategori och dels har företaget Medius tidigare haft en pappersblankett, för reseräkningar, som har haft en liknande uppdelning och som har varit väldigt omtyckt, för att den har varit enkel att följa och fylla i. 14

21 Figur 5: Översiktlig bild över den nya implementationen av utläggsregistreraren för Enterprise Portal Någonting som även har ändrats är att vi inte har använt oss av ett Workflow som diskuterades kort under 6.2.1, och det kommer inte ske någon automatisk kontroll av de olika transaktionerna innan det är möjligt att skicka iväg rapporten till godkännaren. Istället kommer godkännaren få sköta den kontrollen och är det något som denne är osäker över, kan han eller hon skicka rapporten vidare till exempelvis någon på ekonomiavdelningen. Därför syns den lilla rullgardinslistan nere till höger även om inga transaktioner är ifyllda. Vad som är gemensamt för varje listning samt tillhörande rullgardinslista är att de är filtrerade för att visa en specifik utgiftstyp. Alltså om det skulle skapas en utgiftskategori av en utgiftstyp, som inte finns med i listningen, kommer den inte att vara valbar eller synas i någon av listningarna, för att vissa utgiftstyper kräver att vissa fält måste vara ifyllda. Detta var anledningen till att fälten skiftades på den tidigare lösningen beroende på vilken utgiftstyp som var vald. Något som även är gemensamt för varje transaktion är att de går att koppla till ett specifikt projekt. Med andra ord kan en reseräkning fyllas i och gälla flera olika projekt ifall det skulle behövas. Under kommande rubriker kommer de olika listningarna att gås igenom och vad som är specifikt för dem. 15

22 Traktamente För att användaren ska kunna registrera traktamenten behöver han eller hon inte känna till reglerna (se kapitel 4.1), för vad som krävs för hel- och halvdagstraktamente. Utan behöver endast fylla i vilket land som traktamentet gäller för, samt start- och sluttid för resan. Om den anställde har haft några måltider som har ingått i exempelvis hotellpriset eller ifall han eller hon har blivit bjuden på lunch eller middag av till exempel den besökta kunden, ska även dessa anges. Beräkningen av traktamenten sker inte i webbkontrollen utan i en metod, mdsperdiem, som är knuten till den specifika transaktionstabellen i Dynamics AX, TrvExpTrans. Mer om metoden mdsperdiem kan ni läsa under kapitel Milersättning Som ni kunde läsa under kapitel 4.2 består milersättningen av en skattefri- och en skattepliktig del för företaget. För att det ska vara enkelt för den anställde att se hur mycket denne får tillbaka i milersättning, valdes det att även i EP dela upp en sådan transaktion i två. Alltså när en milersättningstransaktion skapas, skapas två transaktioner i Dynamics AX, men den anställde ser bara den skattefria transaktionen (se Figur 6). Den skattepliktiga transaktionen filtreras bort för den som skapat utläggsrapporten men är synliga för den som godkänner rapporten samt ekonomiavdelningen, se Figur 7. Nackdelen med det här valet av design är att den skattepliktiga transaktionens belopp räknas in i rapportens totala belopp, vilket skulle kunna leda till förvirring hos den anställde. Att skapa ytterligare en transaktion ledde till att ett par modifieringar av kärnan behövde göras. Dels behövde metoden insert för tabellen TrvExpTrans modifieras och dels metoden för delete. Mer om dessa modifieringar kan ni läsa om under kapitel

23 Figur 6: Bilden visar hur listningen av milersättningstransaktioner ser ut för den anställde som har registrerat dem. Figur 7: Bilden visar hur listningen av milersättningstransaktioner ser ut för den som godkänner rapporten Utlägg Under den här kategorin listas de utläggen som inte passar in under de övriga två listningarna, till exempel ifall den anställde har betalat för kontorsmaterial, tågbiljetter, hyrbil, etc. Tanken med den här listningen är att den ska täcka upp så mycket som möjligt. Det är utgifter från den här listningen som i framtiden skulle kunna lyftas ut och ha en egen listning. En tänkbar sådan listning skulle kunna vara Representation som i Sverige har en del extra regler som man måste ta hänsyn till. 6.3 Extern Applikation Med MS.NET Business Connector Den externa applikationen har utvecklats med avseende på att ha samma funktionalitet, som den webbkontrollen som har utvecklats till EP. Med funktionalitet avses möjligheten till att skapa flera transaktioner med olika utgiftstyper, men som hör till samma utläggsrapport. Tyvärr kunde man inte via utvecklingsmiljön, Visual Studio, använda sig av samma kontroller för Dynamics AX, när man arbetade med Windows Forms, som var möjligt när man skapade en webbkontroll. Därför har designen fått ett annat utseende mot EP och fokus har inte legat på att skapa ett användarvänligt gränssnitt, vilket ni kan se på de bilderna som föreställer applikationen, utan funktionaliteten har prioriterats framför designen. Genom att programmet har utvecklats som en Windows Form applikation i Visual Studio. Kommer den om behovet finns kunna läggas till i något av programmen i Microsoft Office i framtiden som en så kallad add-in. Nedan kommer en genomgång över hur man skapar en utgiftsrapport, samt lägger till nya transaktioner. 17

24 Precis som vi skapandet av en ny utgiftsrapport i EP kommer användaren även av den externa applikationen behöva ange ett par grundfakta, Figur 8, för att rapporten ska kunna skapas. Figur 8: Visar hur sidan för att skapa en utgiftsrapport med hjälp av den externa applikationen ser ut. När en ny rapport har skapats, kommer man till vyn i Figur 9. Listningen ska påminna om den som finns i EP. Tyvärr har alla transaktioner samma listning och inte separata som de har i EP som en följd av problemen med kontrollerna i Visual Studio. Genom att använda sig av menyn uppe till vänster kan man skapa en ny transaktion av vald typ. Figur 9: Visar hur man väljer typ av utlägg för transaktionen. Antalet fält som behöver fyllas i för varje transaktion är detsamma som i EP och vyn för att skapa en transaktion av typen Utlägg ser därför ut som i Figur

25 Figur 10: Visar hur vyn för att lägga till en ny transaktion för utlägg ser ut. När en transaktion har lagts till finns det en möjlighet att skicka rapporten till en godkännare eller att spara ned för att senare kunna editera den. När en transaktion har lagts till syns den även i listningen på förstasidan som ni kan se i Figur 11 nedan. Figur 11: Visar de transaktioner som hör till en rapport. Samt att möjligheten att skicka transaktionen finns genom att en anställd väljs i rullgardinslistan nere till höger. Som tidigare nämnts fungerade inte de Dynamics AX-specifika kontrollerna för utvecklingen av applikationen. Det gjorde att vi inte kunde använda oss av befintliga metoder för att populera de olika rullgardinslistorna. Istället fick vi först hämta hela tabellerna och sedan lägga till varje rad för sig till rullgardinslistorna. 19

26 6.4 Modifieringar av kärnan i Dynamics AX För att tillmötesgå den nya funktionaliteten som har lagts till i klienten. Har många ändringar behövt göras i olika formulär och listningar. Jag kommer inte gå in på hur dessa är gjorda utan endast nämna att de har ändrats och varför. Dessa kan ni läsa om i De största ändringarna har gjorts genom att befintliga tabellers metoder har ändrats, samt att nya tabeller har skapats. Vilka dessa är, kan ni läsa om under de två nästföljande rubrikerna; och De komponenter som har skapats eller modifierat syns i Figur 12 nedan. Som ni kan se i bilden står det (usr) efter varje modifierad komponent som syftar till att komponenten är modifierad i användarlagret, vilket diskuterades i kapitel 2.2. Figur 12: Bilden visar de komponenter i Microsoft Dynamics AXs kärna som har skapats och modifierats. Komponenterna har blivit grupperade i ett projekt i AX. Under hela modifieringsprocessen av kärnan har grundidén varit att göra så få modifieringar som möjligt på de befintliga komponenterna. Grundpolicyn har varit att om det går att lösa med att skapa en ny komponent och på ett enkelt sätt använda sig av denna har vi gjort det. Huvudanledningen till detta är att det ska vara enkelt att leverera en anpassning även om Dynamics AX uppgraderas, och om de befintliga komponenterna ändras eller tagits bort, kan det leda till att stora ändringar måste göras innan anpassningen fungerar på den nya versionen. Som läsaren kanske minns från kapitel 2.1 var ett av designvalen ifall man skulle leverera ett anpassat system eller inte. Genom att skapa ett projekt som ni kan se i Figur 12 kan en kundinstallation bestå av en ursprungsinstallation från tillverkaren, utan tillägg till en början. Efter hand kan den sedan anpassas med hjälp av olika paket som består av ett eller flera projekt om kunden önskar Modifikationer av befintliga tabeller Under arbetets gång har det gjorts ändringar i två befintliga tabeller. Huvudsakligen har de största ändringarna gjorts i tabellen TrvExpTrans men det finns även en del småändringar i TrvExpTable. Det som har gjorts i den senare är att det har lagts till en 20

27 extra kolumn Approver för att hålla reda på vem som ska godkänna rapporten, samt en metod för att ta reda vilket namn den anställde har med det lagrade id:et i den tillagda kolumnen. Tabellen TrvExpTrans är den tabellen som håller reda på alla transaktionsrader som hör till de olika utgiftsrapporterna. I den här tabellen har det funnits ett behov av att göra modifieringar av befintliga metoder men även att lägga till ett par nya. De befintliga metoder som har modifierats i TrvExpTrans är framförallt metoderna: insert, delete och calckm, där modifieringar i de två första har handlat om att rader som hör till en viss transaktion även ska behandlas dels i den här tabellen och dels även i tillhörande sidotabeller som har skapats. I den sista av metoderna, calckm, har modifieringen handlat om att milersättningen ska beräknas med hjälp av de nya värdena som har lagrats i en ny sidotabell, samt att den tillhörande milersättningstransaktionen ska uppdateras ifall en transaktion uppdateras. I övriga metoder som har modifierats, har i princip endast länkar och anrop modifierats, för att dessa ska använda sig av de tabeller och metoder som vi har skapat eller modifierat. Som nämndes tidigare har även nya metoder i tabellen skapats för att uppfylla de villkor och funktioner som har efterfrågats. Därför har det skapats ett par så kallade edit-metoder för att kunna editera tillhörande fält i en nyskapad sidotabell, MDS_TrvReduction. De metoderna har använts i EP för att med enkelhet dela samma AxGridView då en sådan metod nämligen visas som ett separat fält i listningen. Dessa metoder har använts vid beräkningen av traktamenten och används inte av de övriga utgiftstyperna. De fälten som syns i listningen som är gjorda med den här tekniken är avdragen för måltider samt ersättningen för nattschablon. För att traktamentena ska bli beräknade på rätt sätt har en helt ny metod skapats nämligen mdsperdiem. Grundidén med metoden är att den ska beräkna traktamentsersättningen enligt skatteverkets regler som kortfattat beskrevs under Det finns en rad olika tillägg och saker, som kan påverka vilken ersättning den anställde ska ha. I metoden finns därför funktionalitet som gör så att beloppet inte alltid beräknas utifrån start- och sluttid, utan även ifrån de värdena som finns i nya sidotabellen MDS_TrvReduction, vars värden även kan ändras från klienten precis innan transaktionen bokförs av ekonomipersonalen om något har blivit fel Nya tabeller Som tidigare nämnts har ett par nya tabeller skapats för att kunna tillmötesgå de behov som har uppkommit genom att applikationen ska följa svenska traktamentsregler. Nedan går vi igenom övergripande varför tabellerna har skapats och vilket eller vilka behov de uppfyller. MDS_TrvReduction: lagrar de värden som är specifika för en viss transaktion vid traktamenten, bland annat antal måltider, hel- och halvdagar samt nattschabloner. Det används för att ekonomipersonalen sedan ska kunna se i klienten att traktamentena har beräknats på rätt sätt. MDS_TrvPerDiemReduction: lagrar de värden som behövs för att veta vilka avdrag som behöver göras vid måltidsavdrag. Dessa skiljer sig åt ifall det är inom Sverige eller utrikes. I Sverige är det fasta belopp medans utrikes är det en procentdel av dagsersättningen. För att dessa värden ska vara enkla att ändra har ett formulär skapats med samma namn som tabellen och en länk till formuläret har lagts till i klienten. MDS_TrvCostTypeParams: håller de värdena som är specifika för olika utlägg. Till exempel hur stora de skattefria och skattepliktiga ersättningarna är per mil vid milersättning. Här lagras även olika länders traktamentsbelopp. 21

28 6.4.3 Övriga ändringar Som ni kunde se i Figur 12 har en rad olika komponenter ändrats. Då vissa endast har ändrats lite tänker vi inte ta upp hur de har ändrats, utan nöjer oss med att endast nämna att de har ändrats. De som har ändrats eller skapats och som vi inte kommer gå in djupare på är: Klassen ProjTableLookup har ändrats. Utskriftsrapporten TrvExpenseList har ändrats. Datakällorna TrvExpTrans och TrvExpTableNew har ändrats. Datakällan MDS_TrvExpApprove har skapats med hjälp av tabellen TrvExpTable för att kunna lista de rapporter som den anställde ska godkänna. Menyalternativet MDS_PerDiemMealReductionItem, har lagts till för att det ska vara möjligt att redigera måltidsavdragen från klienten. Webbmenyobjektet MDS_TrvExpTrans har skapats för att det ska vara möjligt att navigera till den nya sidan i EP som har skapats för webbkontrollen med samma namn. En enum MDS_PerDiemType har skapats och kan ha två värden: inrikes eller utrikes. Det underlättar beräkningen av måltidsavdrag vid traktamenten, då de svenska och utländska avdragen beräknas på olika sätt. En utökad datatyp MDS_MealReduction baserad på enumen MDS_PerDiemType Formulär TrvExpTable: det här formuläret sköter listningen av godkända och bokförda transaktioner, samt de transaktioner som har överförts för bokföring men ännu inte blivit bokförda. Formuläret har ändrats så att det numera är möjligt att ändra i transaktionerna efter att de har blivit godkända, vilket inte var möjligt tidigare. Sedan har även de värden från den sidotabell som skapades, MDS_TrvReduction, länkats in och visas när en traktamentestransaktion har blivit markerad. ProjCategory: namnet kan tyckas lite missvisande men formuläret används både för att skapa projektkategorier och även utgiftskategorier, vilket vi använder den till. De ändringar som har blivit gjorda är att de utgiftsspecifika värdena som finns lagrade (för transaktioner av typ milersättning samt traktamente) i den nya sidotabellen, MDS_TrvCostTypeParams, har länkats in och visas Webbkontroller De kontroller som har ändrats är TrvExpTableNew och TrvExpList. Det som är gemensamt för kontrollerna är att länkarna ändrats så att de nu pekar mot den nya webbkontrollen för utläggsrapporter, MDS_TrvExpTrans istället för den gamla TrvExpTrans. Vad som även har ändrats i TrvExpList är att den anställde tidigare endast såg de rapporter som han eller hon har skapat. Numera syns även de rapporter som den anställde ska godkänna, se Figur 13. Den övre listningen innehåller de rapporter som han eller hon har skapat, medan den nedre innehåller de rapporter som han eller hon ska godkänna. 22

29 Figur 13: Bilden visar hur listningen av utgiftsrapporter ser ut för den anställde. 7 Utvärdering Utvärderingen har skett i tre steg dels genom två intervjuer med ekonomiavdelningen som genomförts under utvecklingens gång, samt en enkätundersökning med testgruppen efter att implementeringen avslutats. Intervjuerna gjordes under slutskedet av implementeringen för att säkerhetsställa dels att traktamentsberäkningarna utfördes på rätt sätt och dels att övriga krav som fanns på applikationen hade uppfyllts. Tillvägagångssättet för dessa intervjuer var att det visades en demo över hur registrering och godkännande skulle gå till, vilket blandades med uppkomna frågor från såväl ekonomipersonalens sida och som från vår sida. Även frågor som var nedskrivna sedan innan mötet med saker som jag och min handledare hade tänkt på under utvecklingens gång behandlades. Genom att utföra utvärderingen på det här sättet, lyckades vi få fram ett par åtgärdspunkter men även en del önskemål om tänkbara utökningar i framtiden. Som nämndes under inledningen av kapitel 6 drog utvecklingen ut på tiden och fokus kom därför att ligga på att få en av de två prototyperna så klar som möjligt, vilket påvisar en av nackdelarna med utvecklingsmetoden Scrum som togs upp under kaptitel Detta ledde tyvärr till att den andra prototypen inte fick den slagkraft, som den kanske hade kunnat få ifall fokus hade legat på den eller om båda prototyperna hade fått lika mycket uppmärksamhet. Försöket med att utveckla en extern prototyp uppskattades dock av de flesta, men i dagsläget var den inte aktuell att fortsätta med. Däremot tyckte de flesta som har medverkat i undersökningen att det är ett väldigt intressant spår och en möjlig framtida utveckling. Den huvudsakliga orsaken till detta är möjligheten att integrera programmet med någon Microsoft Office -applikation och då Microsoft Outlook som den kanske mest intressanta integreringsmöjligheten, till exempel genom att skapa en separat utläggstransaktion genom att skicka en aktivitet från kalendern i Outlook till Dynamics AX. Därför har utvärderingen handlat om webbkontrollen till EP och att få den så användarvänlig och flexibel som möjligt. 23