IN3405 Bachelor project 2012

Transcriptie

1 IN3405 Bachelor project 2012 ERP Systeem voor Bokstijn Feestartikelen Datum 27 juni 2012 Studenten n-willem van Velzen David Hoepelman Bart van Vuuren Bedrijf Bokstijn Feestartikelen Universiteit - Faculteit Technische Universiteit Delft, Faculteit Electrotechniek, Wiskunde en Informatica Commissie Opdrachtgever: Guido Bokstijn TU Begeleider: Koen Hindriks Coördinator BSC: Peter van Nieuwenhuizen Coördinator BSC: Gerd Gross

2 Pagina 1 Voorwoord Aan het eind van de bachelor opleiding aan de Technische Universiteit Delft staat het bachelor project op het programma. Het doel van het project is het zelfstandig uitvoeren van een opdracht in een projectteam. In dit project wordt van studenten verwacht om zelfstandig een project uit te voeren. Dit kan in de vorm van een stage of het uitvoeren van een opdracht voor een interne of eterne opdrachtgever. Dit document doet verslag van ons bachelor project bij Bokstijn Feestartikelen, te Den Haag. De planning van dit project liep 11 weken, beginnend in eind mei 2012 tot aan het begin van juli Bokstijn Feestartikelen voorzag ons van de opdracht om een ERP systeem te leveren welke het huidige, en sterk verouderde, ERP systeem te kunnen vervangen. Onze opdrachtgever vanuit Bokstijn Feestartikelen is G. Bokstijn en wij willen hem bedanken voor de tijd die hij in het project gestoken heeft. De begeleidende rol vanuit de TU Delft werd tijdens de gehele projectduur vervuld door K. Hindriks, waar wij hem dan ook voor willen bedanken. Delft, 2012 David Hoepelman, n-willem van Velzen en Bart van Vuuren.

3 Pagina 2 Inhoudsopgave Voorwoord... 1 Inhoudsopgave... 2 Samenvatting... 4 Inleiding... 5 Bokstijn Feestartikelen... 5 Overzicht Probleemstelling & Analyse Huidige situatie Gewenste situatie Voorraadbeheer Koppeling met de webshop Ontwerp Ontwerpkeuzes Eigen systeem of bestaand systeem Van Longlist naar Shortlist Ontwerp Gebruikstechnisch ontwerp Softwaretechnisch ontwerp Hardwaretechnisch ontwerp Implementatie & Migratie Planning Server Boekhoudingtermen Configureren ADempiere Configureren product- en relatiebeheer Configureren documentbeheer Configureren toegangsbeheer/menu s Migratie Magento Koppeling Magazijn Interface Bijdragen aan Open source software Magento koppeling Magja Nederlandse vertaling ADempiere Resultaat Evaluatie requirements Werking Adempiere Inloggen Rollen & Rechten Schermen Tabblad Menu Internet Server... 26

4 Pagina 3 5 Conclusie(s) Aanbevelingen Voordelen van ADempiere boven KassaMatic Nadelen van ADempiere t.o.v. KassaMatic Reflectie Keuze zelf ontwikkelen of baseren op een bestaand pakket Keuze voor ADempiere en uitsluitingscriteria Planning en evaluatie Bijlagen Originele planning Gevolgde planning Klassendiagram Magento converter Sequence diagram normale conversie van ADempiere naar Magento Uiteindelijk Requirement Overzicht... 35

5 Pagina 4 Samenvatting Het doel van ons bachelor project is een systeem op te leveren dat het huidige ERP systeem van de opdrachtgever Bokstijn Feestartikelen kan vervangen. Daarnaast zijn twee etra functionaliteiten wenselijk: namelijk een koppeling met de Magento webshop en de implementatie van voorraadbeheer voor het hoofdmagazijn. Na het verzamelen van de requirements zijn wij tot de conclusie gekomen dat wij geen compleet pakket konden afleveren indien wij dit vanaf de grond wilden opbouwen. Wij hebben daarom gekozen om onze oplossing te baseren op het open source ERP pakket ADempiere. Dit is een groot, uitgebreid en stabiel pakket dat veel functionaliteit biedt. Aangezien ADempiere een client-server infrastructuur gebruikt is er een server nodig om de ERP software op te draaien. Na het evalueren van verschillende opties hebben wij gekozen om initieel te starten op een Amazon EC2 Virtual Private Server omdat dit kostentechnisch zeer interessant was. Op de lange termijn is dit echter niet de beste keuze. Wij hebben hierom aanbevelingen gedaan over wat de beste in de toekomst te volgen koers is. Om ADempiere geschikt te maken voor Bokstijn Feestartikelen moest er veel configuratie aan ADempiere plaatsvinden. Verder moesten wij ons inlezen in de boekhoudtechnische achtergrond van ERP systemen. Om deze redenen duurde het configureren van ADempiere langer dan wij gepland hadden. Na het configureren van ADempiere hebben wij aan een interface voor het voorraadbeheer van het hoofdmagazijn gewerkt en een koppeling van ADempiere met de Magento webshop gerealiseerd. Wegens tijdgebrek is het ons echter niet gelukt een werkende interface voor voorraadbeheer te maken. Uiteindelijk hebben wij 36 van de 49 verplichte, 13 van de 22 gewenste en 4 van de 11 optionele requirements gerealiseerd in het eindproduct. Onze uiteindelijke conclusie is dan ook dat het door ons opgeleverde ERP systeem niet volledig aan de eisen van de opdrachtgever voldoet. Aangezien het systeem echter zowel voor- als nadelen ten opzichte van het huidige ERP bevat raden wij Bokstijn Feestartikelen aan het door ons opgeleverde systeem grondig te evalueren en hierna te beslissen over welke ERP software zij in de toekomst zullen gaan gebruiken.

6 Pagina 5 Inleiding Hieronder volgt een korte introductie van Bokstijn Feestartikelen, gevolgd door een kort overzicht van dit document. Bokstijn Feestartikelen Bokstijn Feestartikelen is een in 1908 opgericht bedrijf, dat zich specialiseert in de verkoop van feestartikelen (denk hierbij aan carnavalskostuums, accessoires, fopartikelen en een gevarieerd aanbod van feestdecoraties) en op maat gemaakte ballondecoraties. Er zijn fysieke winkels in drie steden in Nederland. Daarnaast is er sinds 5 jaar een webwinkel. De hoofdwinkel staat in Den Haag, met in dezelfde straat nog drie andere panden die gebruikt worden voor kledingverkoop, productopslag en fabricage van ballondecoraties. Naast de winkel(s) in Den Haag is er een winkel in Leiden en zijn er twee winkels in Attractiepark Duinrell. De software die op dit moment gebruikt wordt om alle producten, relaties en bestellingen te beheren is, heeft de naam KassaMatic. De huidige versie van KassaMatic die gebruikt wordt is al een aantal jaar niet ge-update en begint tekenen van ouderdom te vertonen, zoals bijvoorbeeld het niet functioneren op 64 bit Windows-systemen. Overzicht In dit document presenteren we onze opdracht, de afwegingen die we gemaakt hebben bij het ontwerpen van een oplossing en het uiteindelijke resultaat van ons bachelor project. Hoofdstuk één beschrijft het ons gegeven problemen en onze analyse hiervan. Hierna, in hoofdstuk twee, bespreken we onze afwegingen bij het ontwerpen van een oplossing en de oplossing zelf. Hoofdstuk drie beschrijft onze ervaringen met de implementatie en de migratie van de data uit KassaMatic naar het nieuwe systeem. Vervolgens bespreken we het resultaat in hoofdstuk vier, gevolgd door onze in hoofdstuk vijf. Dit wordt gevolgd door onze aanbevelingen in hoofdstuk zes en onze eigen reflectie op dit bachelor project in hoofdstuk zeven.

7 Pagina 6 1 Probleemstelling & Analyse Na onze introductie met het probleem, zijn we begonnen deze specifieker te definiëren. Al deze specificaties hebben we verwerkt in het oriëntatieverslag, welke als bijlage is bijgevoegd. 1.1 Huidige situatie Bokstijn Feestartikelen maakt op dit moment gebruik van twee systemen om producten te beheren. De eerste is een website met het ecommerce systeem Magento voor alle producten van de webshop, de tweede is in de vorm van het programma KassaMatic. KassaMatic voorziet in het beheer van alle producten, het beheer van relaties (crediteuren en debiteuren) en het opstellen van documenten, zoals inkooporders en facturen. Echter is de versie van KassaMatic die op dit moment gebruikt wordt, al een lange tijd in gebruik, in geen jaren meer bijgewerkt en wordt ook niet meer ondersteund door de leverancier. Als gevolg hiervan werkt de software ook niet op 64-bit Windows installaties. Het online zetten van producten gebeurt op dit moment door handmatig alle informatie per product in het KassaMatic systeem op te zoeken en deze in Magento in te voeren. Dit heeft tot gevolg dat hooguit 20% van alle artikelen in de webshop te vinden is. 1.2 Gewenste situatie Bokstijn Feestartikelen ziet graag een systeem met dezelfde functionaliteit als KassaMatic, maar met de toegevoegde functionaliteiten van voorraadbeheer en het gemakkelijk online zetten van een product Voorraadbeheer Onder voorraadbeheer wordt verstaan dat wordt bijgehouden wat de huidige voorraad van elk product in het hoofdmagazijn is, en het gemakkelijk kunnen aanpassen van deze voorraad. Voorraden in de winkels zelf hoeven op dit moment niet bijgehouden te worden, al zijn hier wel plannen voor. Door voorraadbeheer over te laten aan het systeem, wordt het eenvoudiger om tijdig producten te bestellen. Ook zal het minder vaak voorkomen dat een product besteld wordt, terwijl het al aanwezig was, maar tijdelijk kwijt. Verder heeft de opdrachtgever op deze manier een beter inzicht in de omzet in een bepaalde periode Koppeling met de webshop Onder de koppeling met de webshop wordt verstaan dat alle informatie die bij een product aangepast wordt in de database van het hoofdkantoor, ook meteen aangepast wordt in de webshop. Verder moet het product gemakkelijk (on)zichtbaar gemaakt kunnen worden in de webshop. De koppeling met de webshop heeft als voordeel dat de gegevens niet verschillend kunnen zijn in verschillende systemen. Bovendien hoeven gegevens dan niet twee keer te worden ingevoerd. Om de wensen van de opdrachtgever zo nauwkeurig mogelijk vast te leggen hebben we in het bijgevoegde oriëntatieverslag de requirements opgenomen die precies de gestelde eisen aan het gewenste systeem beschrijven.

8 Pagina 7 2 Ontwerp Voor het ontwerp van ons systeem zijn een aantal afwegingen de revue gepasseerd, welke we hieronder toe zullen lichten. 2.1 Ontwerpkeuzes Eigen systeem of bestaand systeem De eerste keuze die gemaakt moest worden bij het ontwerpen van het gewenste systeem was om te bepalen of we een nieuw of een bestaand systeem zouden gaan gebruiken. We hebben hiervoor de vooren nadelen van de verschillende opties tegen elkaar afgewogen. Bij het maken van een eigen systeem: + Specifiek voor de situatie: Het systeem bevat geen onnodige features. Workflows en schermen kunnen precies worden ingericht zoals dat naar de mening van onszelf of de opdrachtgever het beste is. - Haalbaarheid: Bij het vanaf de grond af opbouwen van een eigen systeem moet ontworpen, geprogrammeerd en getest worden, echter is de omvang van dit systeem dusdanig groot dat wij niet verwachten dit te kunnen voltooien in de 11 weken die voor dit project gepland staan. Als we gebruik maken van een bestaand systeem: + Grotere kans van slagen: door voort te bouwen op een bestaande oplossing is er een grotere kans dat het resultaat bruikbaar voor Bokstijn Feestartikelen is. Verder is waarschijnlijk een groter deel van de software compleet/bruikbaar indien het project niet volledig afgerond kan worden. + Minder bugs: Door gebruik te maken van een bestaand platform dat in de praktijk gebruikt wordt, zijn meer bugs gevonden en opgelost. + Onderhoudbaarheid: Het is makkelijker voor de opdrachtgever om iemand te vinden om een generiek pakket te onderhouden dan een maatwerk applicatie. + Uitbreidbaarheid: bij uitbreiding kunnen delen van het framework (her)gebruikt worden. - Overbodige features: Een bestaand pakket heeft vaak veel features die wij niet zullen gebruiken, die het systeem comple en langzamer kunnen maken Van Longlist naar Shortlist Gezien de aard en de omvang van de opdracht hebben we op basis van bovenstaande afwegingen gekozen voor het gebruiken van een bestaand softwarepakket. Omdat er veel bestaande pakketten zijn die mogelijk gebruikt zouden kunnen worden, hebben we een longlist opgesteld van ongeveer 25 mogelijke pakketten die we vergeleken hebben op basis van criteria zoals platform, database en gebruiksvriendelijkheid. Uit deze vergelijking kwamen we tot een shortlist van vier pakketten welke we verder onderzocht hebben. Hiervan viel een pakket af vanwege de grote compleiteit en een ander pakket omdat het alleen commerciële support verzorgd en enkele andere nadelen heeft. De overblijvende opties waren JFire en Adempiere. JFire heeft meer voordelen dan ADempiere, wat ons tot onze keuze voor JFire bracht. Het risico van een inadequate documentatie vonden we aanvaardbaar omdat JFire ons wel beter in staat stelde om een product op te leveren dat goed voldoet aan de wensen van de klant. Bij het oriënteren op JFire (het doorlezen van de documentatie en het opzetten van de ontwikkelomgeving) kwamen wij echter snel tot de conclusie dat de staat van het project onvoldoende stabiel was voor ons om op voort te bouwen. Enkele problemen die wij tegenkwamen was de beknopte en vaak verouderde documentatie en een niet werkende SDK. Na 8 onsuccesvolle pogingen om de SDK werkbaar te krijgen, waaronder een Eclipse distributie direct van de ontwikkelaar zelf, hebben wij besloten om over te stappen naar ADempiere.

9 Pagina Ontwerp Na het maken van de keuze voor ADempiere moest het beoogde systeem ontworpen worden. Dit ontwerpen hebben we opgedeeld in drie delen: Het gebruikstechnisch ontwerp, het softwaretechnisch ontwerp en het hardwaretechnisch ontwerp Gebruikstechnisch ontwerp Deze paragraaf geeft een overzicht van de verschillende actoren binnen ons systeem, de gebruikersscenario s en de interface die de gebruiker te zien krijgt Actoren Omdat niet alle gebruikers van het systeem toegang mogen hebben tot alle gegevens en functionaliteiten, hebben we voor de verschillende actoren verschillende rollen aangemaakt in het systeem. We onderscheiden vier soorten actoren, met verschillende rechten. De actor met de minste rechten in het systeem is de medewerker winkel, die het systeem alleen zal gebruiken om informatie over producten op te zoeken. Een magazijnmedewerker kan net als een winkelmedewerker productinformatie bekijken, maar kan daarnaast ook producten kunnen in- en uitscannen in/uit het magazijn. De kantoormedewerker heeft, behalve de rechten van de magazijnmedewerker, de mogelijkheid om producten, relaties en documenten te beheren en om de instellingen van het programma te veranderen. Gebruikers die de rol beheerder systeem hebben, hebben alle rechten die een medewerker kantoor heeft, en kunnen het toegangsbeheer uitvoeren Use Cases Om te testen of ons systeem aan de gestelde eisen voldoet hebben we een aantal use cases opgesteld die uitgevoerd moeten kunnen worden op ons systeem. Deze use cases dekken de functionele eisen aan het systeem, en kunnen daarom ook gebruikt worden voor acceptance tests. De mate van uitvoerbaarheid van de use cases bepaalt in hoeverre we er in geslaagd zijn om aan de wensen van de opdrachtgever te voldoen op het gebied van functionaliteit. De volledig uitgewerkte use cases staan beschreven in het paragraaf 1.3 van het Ontwerpverslag welke opgenomen is in de bijlage. Voor de verduidelijking staat op de volgende pagina in Tabel 1 per actor aangeduid welke use cases deze wel of niet uit mag voeren. Medewerker winkel Medewerker magazijn Medewerker kantoor Beheerder systeem Authenticatie Inloggen in het systeem Productbeheer Informatie van een product bekijken Product toevoegen aan het systeem Informatie van een product bewerken Magazijnbeheer Product inscannen in het magazijn Product uitscannen uit het magazijn

10 Pagina 9 Relatiebeheer Informatie van een relatie bekijken Relatie toevoegen Relatie bewerken Documentbeheer Inkooporder maken Inkooporder printen of mailen Offerte maken Aanmaning maken Openstaande facturen raadplegen Voorraadbeheer Voorraad van een product handmatig aanpassen Overzicht bekijken van producten met negatieve voorraad Dymo Label Writer Kledinglabel printen Ballonlabel printen Toegangsbeheer Gebruiker toevoegen Gebruiker bewerken Tabel 1 Use Case-Actor Matri Ontwerp User interface Omdat gebruik wordt gemaakt van het al bestaande ERP pakket ADempiere, betekend dit dat het ontwerp van de GUI al grotendeels vast staat. Dit komt doordat ADempiere gebaseerd is op een model-driven architectuur 1. Dit houdt in dat de structuur van ADempiere en de hierbij komende functionaliteiten gedefinieerd worden in een data model. Dit model wordt automatisch getransformeerd in een werkende software applicatie, door a.d.h.v. het model code te genereren en/of het model zelf uit te voeren. Dit heeft bijvoorbeeld als voordeel, dat doordat het model op een veel hoger abstractie niveau ligt, het een stuk compacter is dan als je hetzelfde model in code uit zou moeten drukken. De Model-driven Architectuur komt in ADempiere tot uiting, doordat de meeste schermen/tabbladen een visualisatie zijn van de achterliggende database tabel. ADempiere heeft de functionaliteit om alle waarden uit een rij overzichtelijk in één scherm weer te geven. De volgorde van deze velden, en wat voor etra functionaliteiten hier verder nog aan gekoppeld kunnen worden, zijn in te stellen in het zogenaamde Application Dictionairy waar nagenoeg de hele configuratie van ADempiere in is opgeslagen de interface van ADempiere op draait. Application Dictionary Structuur 1 Poole J.D. Model-Driven Architecture: Vision, Standards And Emerging Technologies April

11 Pagina 10 Omdat ADempiere vanaf de eerste installatie al een volledig te gebruiken GUI bevat, vol met functionaliteiten die niet gedefinieerd zijn in onze requirements, hebben we besloten om een groot aantal hiervan niet weer te geven. De functionaliteiten worden niet verwijderd, maar de toegang zal niet weergegeven worden. De schermen die bijvoorbeeld een overzicht geven van de product eigenschappen, bevatten ook veel velden die voor ons op dit moment niet van toepassing zijn, maar later misschien wel weer interessant worden. Naast het opschonen van deze interfaces zijn de schermen ook opnieuw ingedeeld, deels omdat de nu verborgen velden gaten achterlieten. Origineel aantal opties Aangepast aantal opties Daarnaast hebben we het verbergen van functionaliteiten en velden vooral gedaan omdat de interface met alle opties zichtbaar op het eerst aanzicht heel erg comple en onoverzichtelijk leek, en dus de drempel verhogen om snel en gemakkelijk met het pakket aan de slag te gaan. Als laatste hebben wij een nieuwe interface ontworpen voor gebruik in het magazijn, waarmee de actuele voorraad van de aanwezige producten snel aangepast kan worden. De gebruiker zou met een barcode scanner een barcode van een product kunnen scannen, dan zou ADempiere hierbij automatisch het goede product vinden en hier bijvoorbeeld de naam, beschrijving en huidige voorraad van weergeven. De gebruiker kon dan aangeven hoeveel producten er van de voorraad afgehaald moesten worden, of aan de voorraad toegevoegd moeten worden. Hierna zou met een druk op de knop de voorraad aangepast worden aan de hand van de ingevoerde specificaties Softwaretechnisch ontwerp Services ADempiere is gebouwd bovenop de open-source JBoss va-ee Application Server. Verder vereist ADempiere een ANSI SQL Database. Hiervoor komen MySQL, PostgreSQL en Oracle (normaal of XE) in aanmerking. Oracle viel af vanwege de hoge kosten en lastige configuratie. MySQL is meer in gebruik dan PostgreSQL, wat MySQL voor ons iets aantrekkelijker maakte. Bij ADempiere wordt echter vaker PostgreSQL gebruikt, omdat de ondersteuning van MySQL bij ADempiere nog vrij jong is. Verder moet MySQL in ANSI modus gezet worden waardoor deze anders reageert op queries dan in de standaardmodus, wat verwarring zou kunnen veroorzaken in de toekomst. Om deze twee redenen hebben wij gekozen voor PostgreSQL. Verder heeft ADempiere een SMTP server nodig. De benodigde services zijn dus ADempiere, JBoss, PostgreSQL en SMTP. Het is nodig dat deze services op een centrale plek staan en benaderbaar zijn via internet zodat elke terminal met dezelfde gegevens werkt.

12 Pagina PotgreSQL replicatie ADempiere heeft gelimiteerde (read-only) capaciteiten als alleen de database beschikbaar is. Dit kan gebruikt worden om als oplossing voor als het systeem geen verbinding kan maken met internet. Uit de PostgreSQL documentatie komt in onze situatie Slony als beste replication solution in naar voren, omdat deze over slow-links (i.e. het internet) kan replicaten en de slaves read-only queries kunnen draaien. Wij hebben vanwege tijdgebrek besloten deze oplossing niet te implementeren. Echter is deze relatief eenvoudig later toe te voegen. Terminals kunnen dan een slave PostgreSQL database installeren en hier lokaal mee verbinding maken. Deze lokale database zal dan gesynchroniseerd worden wanneer internetverbinding wel beschikbaar is Magento koppeling Voor de koppeling van producten naar Magento hadden wij verschillende opties bedacht: Een module in Magento die de database of API van ADempiere uitleest Een losstaand programma dat met dat database/api van ADempiere uitleest en de Magento API aanspreekt Een module van ADempiere die de Magento API aanspreekt Tijdens de ontwerpfase hebben wij besloten om de keuze nog niet te maken, omdat wij ADempiere nog niet goed genoeg kenden en hierdoor dus nog niet konden beredeneren wat handig is. De Magento koppeling is verder uitgewerkt in Hardwaretechnisch ontwerp Het hardwaretechnische ontwerp is uitgebreid beschreven in hoofdstuk 3 van het ontwerpverslag. Daarin worden de voor- en nadelen van de verschillende mogelijkheden tegen elkaar afgewogen en wordt een aanbeveling gedaan aan Bokstijn. We geven hier een beknopt overzicht van dit hoofdstuk Server ADempiere is gebaseerd op het klassieke client-server model. Voor ADempiere is dus minimaal één server nodig. Hiervoor zijn de volgende opties: 1. Een server op locatie in het hoofdpand a. Een geavanceerde server met mogelijkheden tot uitbreiding en virtualisatie b. Een basisserver met proactief support contract c. Een basisserver zonder proactief support contract support contract d. Een desktopcomputer op locatie in het hoofdpand al server 2. Een server in een datacentrum a. Een dedicated server op colocatie b. Een dedicated server in lease c. Een Virtual Private Server (VPS) Ter ondersteuning van deze opties zijn infrastructuur diagrammen gemaakt. Deze kunnen gevonden worden in Bijlage C en Bijlage D van het ontwerpverslag. Voordelen van optie 1 zijn o.a. een lagere netwerklatency (binnen het hoofdpand) en onafhankelijkheid van internetverbinding (binnen het hoofdpand). Nadelen zijn o.a. dat de epertise voor het onderhoud van een server niet aanwezig is binnen Bokstijn Feestartikelen en de benodigde hoge initiële investering.

13 Pagina 12 Voordelen van optie 2 zijn o.a. dat het onderhoud van de server en infrastructuur verzorgd wordt door eterne professionals, zodat Bokstijn Feestartikelen hier geen kennis voor hoeft te ontwikkelen of in te huren. Een ander voordeel is dat er per maand betaald wordt in plaats van een hoge initiële investering. Het belangrijkste nadeel is de afhankelijkheid van de internetverbinding: het was onzeker of ADempiere alle functionaliteit over internet kon bieden en wat een internet- in plaats van netwerkverbinding voor impact had op de snelheid. Optie 1a) viel af omdat de kosten niet opwegen tegen de baten voor Bokstijn Feestartikelen. Optie 1d) hebben wij na de initiële analyse buiten beschouwing gelaten: desktop hardware is te gevoelig om als server (en Single Point of Failure) bij een bedrijfskritische applicatie in te zetten. Optie 2a) viel af omdat deze geen voordelen boven 2b) en 2c) bood, maar wel enkele nadelen van 1) meenam. De overige opties (1b, 1c, 2b en 2c) zijn met elkaar vergeleken en verwerkt in een investeringsvoorstel Internetverbindingen Omdat ADempiere gebruik maakt van een client-server model moeten clients verbinding kunnen maken met de ADempiere server. De meest logische keuze om dit te doen is het internet, aangezien alternatieven als dedicated lijnen niet interessant zijn voor Bokstijn Feestartikelen vanwege de hoge kosten. Bij de panden in Den Haag was echter enkel in het hoofdpand internet aanwezig. Omdat twee andere panden wel gebruik moesten gaan maken van ADempiere hebben wij in gang gezet dat deze panden een ADSL zakelijke internetverbinding kregen van KPN. Verder hebben wij in gang gezet dat het hoofdpand van een KPN ISDN+ADSL verbinding overgezet wordt naar een Ziggo DOCSIS3 kabelverbinding. Deze verbinding faciliteert snelle toegang tot de server en maakt opties 1b en 1c realistisch, over de ADSL verbinding konden andere panden namelijk niet snel genoeg verbinding maken met de ADempiere server. Als bijkomend voordeel zijn de 3 nieuwe aansluiting samen goedkoper dan de ISDN+ADSL verbinding van het hoofdpand, omdat KPN een naar huidige maatstaven absurd hoog bedrag vroeg voor de ISDN verbinding (waarschijnlijk het gevolg van dat de ISDN lijn in de jaren 90 is aangeschaft). 3 Implementatie & Migratie Na het ontwerpen van hoe het systeem zou moeten gaan functioneren werd het tijd voor het daadwerkelijk implementeren hiervan. We zullen achtereenvolgens beschrijven hoe onze planning is gelopen, wat onze activiteiten omtrent servers is geweest, boekhoudstermen waar we tegenaan zijn gelopen, de configuratie van ADempiere, de migratie van alle oude data, de Magento Koppeling, de Magazijn Interface en onze bijdragen aan de open-source gemeenschap. 3.1 Planning In het begin van dit bachelor project hebben wij een planning opgesteld, waarmee we met de huidige kennis destijds verwachtten dit project succesvol af te sluiten. Deze planning hebben we om de twee weken her-beoordeeld, met de bedoeling zo min mogelijk voor verrassingen te komen staan. De originele planning en de uiteindelijke planning zijn te zien in respectievelijk Bijlage 8.1 en Bijlage 8.2. De originele planning gaat nog uit van het gebruik van JFire. Ook is te zien dat er nog geen rekening wordt gehouden met het evalueren van de planning. Nadat we overgestapt zijn van JFire naar ADempiere was er meteen noodzaak om de planning te evalueren, en hierbij is ook beslist dat het verstandig was om dit elke twee weken uit te voeren.

14 Pagina 13 Week één en twee De eerste twee weken stonden in teken van de oriëntatiefase. Allereerst zijn we begonnen met het verzamelen van de requirements. Daarnahebben we gekeken of we dit project vanaf de grond op wilde gaan bouwen, of dat een bestaand pakket configureren een beter eindresultaat gaf voor Bokstijn Feestartikelen. We besloten voor het tweede, aangezien een volledig ERP pakket een bijhoorlijke uitdaging is en het niet nuttig is om het wiel opnieuw uit te vinden als deze al bestaat. Na een aantal ERP pakketten geëvalueerd te hebben, zette we JFire op de eerste plaats, met ADempiere als tweede keus. JFire bleek niet zo gemakkelijk op te zetten als gehoopt, en na een aantal mislukte pogingen om een werkende development omgeving op te zetten werd besloten JFire aan de kant te zetten. Hier kwam ADempiere voor in de plaats. Week drie De derde week richtten we ons op het maken van de use-cases en het her-evalueren van de planning. Dit was nodig door de eerder opgelopene vertraging. Week vier en vijf In de twee weken die hierop volgden hebben we ons bezig gehouden met het ontwerpen van de infrastructuur. Dit na een bezoek aan de fysieke vestiging in Den Haag. Ook zijn we iets verder in het datamodel van ADempiere gedoken. De hierop volgende week is gestart met het schrijven van het ontwerpverslag en er is ook gekeken naar welke vrijheden we hadden om de GUI naar onze hand te zetten. We hebben de boekhouding van onze opdrachtgever onderzocht en hebben een virtuele server bij Amazon opgezet, zodat we hierop ADempiere konden configureren. Week zes en zeven Volgens de originele planning zou de week ervoor ADempiere volledig geconfigureerd zijn, en zouden we deze weken besteden aan het schrijven van de Magento koppeling en Magazijn Interface. Echter bleek ADempiere een stuk lastiger in elkaar te configureren dan we dachten. Verder haden we moeite met de Engelse boekhoudkundige termen, wat niet ten goede kwam aan het doorgronden van de functionaliteiten die ADempiere bezit. Deze week realiseerden we ons de noodzaak van de vertaling naar het Nederlands, en zijn begonnen met het opzetten van een Nederlandse vertaling. Verder zijn we doorgegaan met het uitbreiden van de server en het aanvragen van internetverbindingen voor de andere panden in Den Haag, waar ook met internet verbonden terminals moeten komen te staan volgens ons ontwerpverslag. Als laatste zijn we deze weken begonnen met de Migratie van de data uit KassaMatic naar ADempiere. Het SIG code review dat aan het eind van deze weken gepland stond was voor ons onmogelijk om te halen, omdat er alleen nog maar een kleine opzet gemaakt voor de Magento Koppeling en er nog geen enkele werkende code was. Onze vraag aan SIG of wij, mede door een laag aantal Lines Of Code, onze code voor de eerste review een week later op mochten leveren werd positief beantwoord. Week acht en negen Deze weken waren oorspronkelijk gepland als migratie weken. Hiermee liepen we nog volgens planning. Hiernaast is verder gewerkt aan de Magento Koppeling en is begonnen met het uitzoeken van hoe de Magazijn Interface als functionaliteit toegevoegd kan worden als functionaliteiten aan ADempiere. Verder is in de afgelopen weken bij het gebruik van ADempiere altijd de dekstop client gebruikt, omdat we dit als vereiste hadden gesteld aan het begin van het project. Echter kwamen we er deze week achter dat ADempiere niet gebouwd is om te werken met een Server die niet op de locatie zelf staat. Er gaan een grote hoeveelheid queries heen en weer voor het laden van elk scherm, die de GUI onwerkbaar straag

15 Pagina 14 maken. We hebben hierom besloten om de originele eis van een Desktop Client te laten vallen en over te stappen naar de web client die ADempiere gelukkig wel had. Deze werkt in principe hetzelfde als de dekstop client, met ongeveer dezelfde functionaliteiten, maar was een stuk sneller. Het is echter wel zo dat de web client van ADempiere de LabelPrinter niet aan kan sturen. Deze weken zijn we ook bezig geweest met het vertalen van (de meest gebruikte schermen van) ADempiere, het schrijven van userdocumentatie en het overzetten van nieuwe gegevens van KassaMatic die in de afgelopen weken in de winkel in Den Haag bijgewerkt waren. ADempiere is op dit moment grotendeels gebruiksklaar, al begint het wel te dringen voor de magazijn interface en de Magento koppeling. Er is de laatste week ook gezorgd dat er internet aangelegd is in de twee panden in Den Haag die dit nog niet hadden. Week tien en elf De laatste weken van het bachelor project zijn aangebroken en het oordeel wordt geveld dat de Magazijn Interface en Magento koppeling niet af gaan komen voor het inleveren van het eindverslag. De Magento Koppeling is wel in een dusver gevorderd stadium dat deze hoogstwaarschijnlijk voltooid wordt voor de eindpresentatie. De Magazijn Interface zal deze week nog aan gewerkt worden, maar het gebrek aan documentatie, de late start en de compleiteit van ADempiere geven geen goede hoop. De planning voor de rest van de week is het afmaken van de Magento koppeling, en toch nog een poging blijven doen voor de magazijn interface. Daarnaast zullen we de eindpresentatie gaan voorbereiden, evenals een acceptence test die we aanstaande zaterdag gepland hebben. Verder zal a.s. zaterdag ook de on-site installatie plaatsvinden, waarbij onder andere de certificaten geinstalleerd moeten worden om de computer zonder problemen met de web client te laten verbinden zonder authenticatieproblemen. 3.2 Server Het in besproken investeringsvoorstel is voorgelegd aan de opdrachtgever. Uiteindelijk hebben wij in samenspraak met de opdrachtgever ervoor gekozen om in ieder geval, voor de duur van ons bachelor project, optie 2c (VPS) te kiezen, en wel een Amazon EC2 VPS. Dit omdat de Amazon Cloud services relatief goedkoop zijn en zeer fleibel zijn, waardoor wij de snelheid van de VPS konden vergroten aan de hand van de behoefte van ADempiere. Na latency tests met verschillende zogenaamde availability zones is gekozen voor een server in de euwest-1c zone in Ierland. Op deze server is een installatie gemaakt van de Amazon Linu distributie, welke gebaseerd is op Red Hat Enterprise Linu. Initieel was gekozen voor een small instantie (1,7GB RAM met 1 EC CPU Een 1Ghz Operton/Xeon uit 2007). Op deze server zijn OpenJDK 1.6 en PostgreSQL 9.1 geïnstalleerd. Vervolgens is ADempiere 3.7.0LTS geïnstalleerd. Na tuning van PostgreSQL en ADempiere bleek dat de server bij opstarten al 1,4 GB gebruikte en bij één gebruiker die actief bezig was in ADempiere gebruikte deze server al een deel van zijn swap space. Om deze reden is gekozen om de instantie te upgraden naar een medium instantie (3,75GB RAM met 2 EC CPU Een 2Ghz Operton/Xeon uit 2007). Bij deze instantie hebben wij geen performance problemen meer gedetecteerd. Mocht de huidige hardware na verloop van tijd toch niet voldoen, dan kan de instantie eenvoudig geupgrade worden naar grotere hardware met slechts enkele minuten down time. Voor de beste oplossingen na het afronden van het bachelor project verwijzen wij naar hoofdstuk 6: Aanbevelingen.

16 Pagina Boekhoudingtermen Om alle transacties in Adempiere boekhoudkundig goed te kunnen verwerken is het nodig dat er wordt gespecificeerd welke grootboekrekeningen Adempiere voor welke handelingen moet gebruiken. Dit moet worden aangegeven door een Chart of Account (COA) te importeren. Hierin staan de nummers en omschrijvingen van de verschillende grootboekrekeningen en ook voor welke acties in Adempiere deze gebruikt dienen te worden. Adempiere levert enkele standaard sjablonen van COA s aan. Geen daarvan is echter in het Nederlands. Omdat het systeem mogelijk in de toekomst ook gebruikt zal worden voor de financiële boekhouding van Bokstijn, hebben we de namen van de grootboekrekeningen uit een Engelstalig sjabloon vertaald. Dit bleek nog niet mee te vallen omdat het vertalen van boekhoudkundige termen meer boekhoudkundige kennis vereiste dan aanwezig was in onze projectgroep. Bij het gebruik van een standaard vertaalsite kregen we soms voor verschillende Engelse termen dezelfde Nederlandse vertaling. We hebben dit opgelost door op Engelstalige boekhoudkundige sites te zoeken en door sommige woorden niet te vertalen. 3.4 Configureren ADempiere De configuratie van ADempiere vond deels in het Front-end plaats, en deels in het Back-end. De aanpassingen aan het front-end waren grotendeels het invoeren van alle gegevens zoals ze ook ongeveer in KassaMatic stonden. Denk hierbij aan alle producten en relaties, aanheffingen voor brieven, aanmaning typen enzovoorts. De aanpassingen in het back-end besloegen het aanpassen van de gebruikerservaring en dit zal hieronder beschreven worden Configureren product- en relatiebeheer Zoals beschreven in hoofdstuk : Ontwerp User interface zijn de schermen van de product- en relatieoverzichten opgeschoond en opnieuw ingericht. Zoals de meeste schermen in ADempiere bestaan ook deze uit een aantal tabbladen, waarbij elk tabblad een weergave is van het achterliggende database model. Nu volgt een lijst van alle tabbladen en hun uitleg, waarbij aangegeven is of deze wel of niet terug zijn gekomen in de uiteindelijke GUI. De Tabbladen die we uitgezet zijn, zijn in het grijs. Naam Product Related Replenish Price Transactions Located At Costs BOM Components Substitute Functie Algemene product informatie Hier kun je gerelateerde producten aangeven. Dit is een feature in de webshop. Hier kun je informatie geven voor het (automatisch) laten bijvullen van de voorraad van het product als deze op begint te raken. Hier kun je de prijslijsten bekijken waar dit product in voorkomt, en welke prijzen er in deze prijslijsten gegeven is voor dit product. Dit is een overzichtscherm van alle transacties waarin dit product voor is gekomen. Hier is te zien hoeveel voorraad van het geselecteerde product. er is in welk magazijn. Hierin kunnen de kosten van een product gegeven worden. Dit zijn bijvoorbeeld kosten om het product in het magazijn te stallen. Niet de kosten om het in te kopen. Bill Of Material, Informatie over de sub-producten van een product. Informatie over de ingrediënten van een product. Hier kan je aangeven welke producten dit ene product zou kunnen vervangen.

17 Pagina 16 Business Partner Download Accounting Translation UOM Conversions Hier kun je Relatie-specifieke informatie kwijt. Als een product een downloadbaar product is, kun je er hier informatie over kwijt. Hier kan je de informatie bij het product aangeven welke gebruikt wordt als het product voorkomt in een verkoop- of inkooporder. Dit tabblad is alleen in de de web interface zichtbaar en hierin kan je dit specifieke scherm vertalen. Hier zijn de eenheden van de producten te converteren naar andere. Omdat er geen geavanceerde eenheden worden gebruikt was deze tab niet nodig. Hieronder geven we een voorbeeld van het opschonen van het tabblad Product. In de linker kolom staan alle velden, waarbij de grijsgekleurde wederom de velden zijn die we verborgen hebben. Zoekcode Organisatie Document notitie Self-Service Naam Actief Drop Shipment Shelf-Depth Beschrijving Eclude Auto Shipment Shelf Heigth Commentaar Freight Category Shelf Width Barcode P-nummer (SKU) Group1 Sold Product Categorie BTW Categorie Group2 Stocked Aanbevolen in Webshop Eenheden Gaurantee Days Subscription Type Print details op factuur Print details op paklijst Locator Summary Level Stopgezet Stopgezet Op Mail Template Epense Type Kopieër van Product Resouce Units Per Pallet Min Guarantee Days Verified Afbeelding URL Bedrijfs agent Product Verified BOM Attribuut Set Beschrijving URL Product Type Version No Attribuut Set Instantie Classificatie Purchased Volume BOM Client Revenu Recognition Weigth De bovenstaande aanpassingen aan de Tabbladen en Velden geven de volgende, veel overzichtelijkere, user interface. Product - User interface na aanpassingen

18 Pagina 17 De meeste belangrijke tabbladen en vensters zijn op deze manier opgeschoond, elementen die op dit moment voor Bokstijn Feestartikelen niet van belang zijn hebben we verborgen, zodat er een strakke en overzichtelijke interface overblijft Configureren documentbeheer Voor het plaatsen van bestellingen bij leveranciers en het maken van facturen, worden verschillende schermen gebruikt. In deze schermen hebben we verschillende ongebruikte velden en tabbladen verwijderd. Om goed facturen te kunnen maken hebben we de standaard lay-out van de facturen zo aangepast, dat deze voldoet aan de gestelde eisen van de opdrachtgever. Zo hebben we de kolom korting verwijderd, het logo van Bokstijn toegevoegd, en het adres van de klant op dezelfde positie op het papier gezet als bij KassaMatic, zodat dit zichtbaar is als er een envelop wordt gebruikt met een venster links. Om de staffelprijzen goed te verwerken bij het maken van een factuur, moesten de staffelkortingen uit KassaMatic worden overgenomen. Deze moesten handmatig worden ingevoerd omdat hiervoor geen importfunctie beschikbaar was. Het invoeren van meerdere staffelprijzen bij een product gaf soms niet het gewenste kortingspercentage. Dit komt omdat de verschillende kortingspercentages van hoog naar laag moeten worden ingevoerd in het overzicht met staffelprijzen, omdat het systeem het eerste kortingspercentage gebruikt wat van toepassing is op een bepaald product Configureren toegangsbeheer/menu s Het toegangsbeheer van ADempiere is opgebouwd uit rollen en gebruikers. Elke relatie kan in principe toegang tot het systeem krijgen, mist deze minstens een wachtwoord heeft en minstens één toegewezen rol. Aan rollen kunnen ook hoofdmenu s toegewezen worden, waarmee we voor elke actor uit hoofdstuk 2.2 een hoofdmenu hebben kunnen maken die de toegang voor deze gebruiker beperkt tot wat er in hoofdstuk 2.2 voor deze persoon gedefinieerd is. 3.5 Migratie Om Adempiere te kunnen gebruiken, was het nodig dat de gegevens van onder andere producten en leveranciers ingevoerd zouden worden. De bron voor deze gegevens KassaMatic. We hebben daarom een eport gemaakt van alle relevante data uit KassaMatic. Voor het invoeren van de gegevens in Adempiere hebben we gebruik gemaakt van de standaard importfunctionaliteit van Adempiere. De data uit KassaMatic was echter niet rechtstreekst geschikt voor import in KassaMatic. We hebben daarom deze data ingeladen in Ecel, en daar de nodige bewerkingen op de data toegepast. Omdat het importeren van dergelijke hoeveelheden gegevens erg tijdrovend was (het importeren van alle artikelen kostte ongeveer een half uur), hebben we het importeren eerst getest op kleine hoeveelheden data, bijvoorbeeld 10 artikelen. Hierbij liepen we tegen allerlei problemen aan, zoals landcodes die verplicht waren. Bij het importeren van de relaties bleek dat veel klanten als Search Key DEB hadden, terwijl wij verondersteld hadden dat deze Search Key uniek was. We hebben daarom in onze Ecelsheet deze klanten de Search Keys DEB1, DEB2, enz. gegeven. Verder bleek dat sommige velden, zoals URL en BTW-nummer niet konden worden geïmporteerd. Omdat deze gegevens van slechts enkele relaties bekend waren, hebben we deze handmatig ingevoerd.

19 Pagina 18 De openstaande facturen konden eveneens niet worden geïmporteerd, en moesten handmatig worden ingevoerd. De eport die we gebruikten was aan het begin van het project gemaakt, en aan het eind van het project dus alweer verouderd. Om te zorgen dat we de juiste gegevens in Adempiere kregen hebben we de gegevens in Adempiere geëporteerd en deze m.b.v. Ecel vergeleken met een nieuwe eport uit KassaMatic. De nieuwe artikelen en leverancier hebben we vervolgens geïmporteerd en de gegevens die gewijzigd waren hebben we handmatig aangepast. 3.6 Magento Koppeling Na het bestuderen en tijdens de configuratie van ADempiere concludeerden wij dat ADempiere geen API had om etern data in ADempiere te veranderen. Deze functionaliteit is in het verleden wel toegevoegd aan ADempiere door een bedrijf, maar de beschikbare patches waren geschreven voor een oudere versie van ADempiere. Verder zouden deze patches upgraden naar een latere versie van ADempiere bemoeilijken, aangezien deze patches bij een upgrade opnieuw geïntegreerd moeten worden. Wij hebben om deze reden gekozen om geen gebruik te maken van de patches. De enige andere optie om een module buiten ADempiere te bouwen is om de SQL database van ADempiere direct uit te lezen. Wij hebben echter besloten dit niet te doen omdat de ADempiere databasestructuur kan veranderen bij een upgrade. Om deze redenen was het uitgesloten om een module van Magento of een etern programma te schrijven die het synchroniseren voor zijn rekening kwam. Wij hebben gekozen om een module voor ADempiere te schrijven die de Magento SOAP API aanspreekt. De module start als een ADempiere Process. Door een subklasse te maken van de beschikbare Process klasse kan met een process maken dat eigen java code uitvoert met (instelbare) parameters die het meekrijgt van ADempiere. Dit process maakt vervolgens gebruik van door ons geschreven conversieklassen die de ADempiere objecten omzetten naar Magento objecten. De Magento object worden vervolgens met behulp van de library magja 2 naar de Magento API gestuurd, welke ze opslaat in de Magento database. Een gesimplificeerd klassendiagram is te vinden in bijlage 8.3. Een gesimplificeerd sequence diagram van een succesvolle conversie in bijlage Magazijn Interface Voor het laten draaien van eigen code voorziet ADempiere in een aantal mogelijkheden, namelijk via Callouts, Processes en Modellen. Callouts zijn bedoelt om aanpassingen in een detail scherm zelf te doen als er een aanpassing is aan een bepaald veld of een bepaalde knop. Processen zijn vooral bedoelt om in één keer grote hoeveelheden data te verwerken, zoals bijvoorbeeld het synchroniseren met een CMS. Een eigen model is wat er nodig was. Allereerst definieer je via SQL een tabel in de database op de server. Daarna log je in bij ADempiere en voeg je de net aangemaakte tabel toe. Vanuit deze tabel genereer je met ADempiere een scherm met velden en knoppen. Het scherm dat voor de Magazijn Interface ontworpen wordt hieronder weergegeven. Om nu ook te zorgen dat je dit soort rijen in de database op kunt slaan, dien je vanuit Eclipse een eigen model te genereren met de SDK van 2 Magento Connector for va Gebruikte versie SNAPSHOT van

20 Pagina 19 ADempiere. Dit zal een interface en een stub klasse voor je genereren. In deze klasse dien je je eigen code te stoppen, zodat deze aangeroepen kan worden vanuit ADempiere. Hierna pack je deze klassen in een patch.jar-file, zodat je deze wijzigingen op de server zelf toe kan passen. Het ontwerp voor de Magazijn interface staat in de afbeelding hieronder weergegeven. Ontwerp Magazijn interface 3.8 Bijdragen aan Open source software Bij ons bachelor eindproject hebben wij gebruik gemaakt van een groot aantal Open-Source tools en softwarepakketten. Tijdens het bachelorproject hebben wij aanpassingen en toevoegingen gemaakt aan enkele van deze softwarepakketten. Wij hebben er voor gekozen om zoveel mogelijk van onze aanpassingen en code te delen met de community Magento koppeling De Magento koppeling zal gereleased worden onder GPLv2 (dezelfde licentie als ADempiere) via github en het ADempiere forum na anonimisatie. Wij verwachten niet dat de koppeling in zijn huidige form direct bruikbaar zal zijn voor andere configuraties, aangezien de koppeling vrij specifiek voor Bokstijn Feestartikelen is ontwikkeld en ingesteld. Echter verwachten wij wel dat deze een goede basis of voorbeeld kan geven aan bedrijven of ontwikkelaars die gelijkende functionaliteit willen implementeren Magja Zoals eerder genoemd gebruikt onze Magento koppeling de Magja library, een va interface voor de Magento SOAP API. Deze library cached op een aantal punten de gegevens die het van Magento ontvangt en maakte daarvoor gebruik van het Infinispan 3 caching systeem. Dit caching systeem heeft uitgebreide mogelijkheden maar is bedoeld voor high-performance caching, voornamelijk verdeeld over meerdere computers (bijv. in clustercomputers). Magja gebruikte deze capaciteiten niet. Verder 3

21 Pagina 20 conflicteerde Infinispan (dat op JBoss gebouwd is) met ADempiere (dat ook op JBoss gebouwd is maar een andere versie gebruikt). Om deze reden hebben wij de caching vervangen door de Cache systeem van Google Guava 4, waar de library al gebruik van maakte. Door deze verandering is de opstarttijd van de koppeling als deze nog niet in het geheugen geladen is verkleint met 6 seconden (getest op de eerdergenoemde VPS). Dit is vooral te merken bij de eerste keer dat een product wordt gesynchroniseerd na het opstarten van de ADempiere daemon op de server. De patches werden enthousiast ontvangen door een van de auteurs van Magja en zijn inmiddels geïntegreerd in de master git branch van het magja repository Nederlandse vertaling ADempiere ADempiere wordt standaard in het Engels geleverd, echter zijn de werknemers van Bokstijn Feestartikelen gewend aan de Nederlandstalige interface van KassaMatic en hebben over het algemeen moeite met Engels. Om deze reden hebben wij besloten een Nederlandse vertaling van ADempiere aan te maken. Door aan te sluiten op het al bestaande Launchpad Adempiere Translation project 5 hebben wij dubbel werk voorkomen en het makkelijk gemaakt voor anderen om verder te gaan met vertaling in het Nederlands. Wij hebben echter maar een zeer klein deel van ADempiere vertaald, omdat het ons aan tijd ontbrak om een volledige vertaling te doen. Verder ligt dit naar onze mening eigenlijk buiten de scope van ons bachelor project. 4 Een collectie van library en utility classes van Google voor va, vergelijkbaar met Apache Commons. 5

22 Pagina 21 4 Resultaat In dit hoofdstuk geven we een overzicht van het resultaat van ons project. We beschrijven de mogelijkheden en beperkingen van het gemaakte systeem en leggen uit hoe het systeem werkt. Verder wordt het resultaat geanalyseerd aan de hand van de requirements die aan het begin van het project zijn opgesteld. 4.1 Evaluatie requirements Om te analyseren in hoeverre het resultaat voldoet aan de wensen van de opdrachtgever geven we in bijlage 8.5 aan welke requirements wel, en welke requirements niet gehaald zijn. Van de 49 verplichte requirements hebben we er 36 gehaald, van de 22 gewenste requirements hebben we er 13 gehaald. Verder hebben we ook nog 4 van de 11 optionele requirements gehaald. Een groot deel van de belangrijkste categorie requirements hebben we gehaald. Daarmee is de functionaliteit van KassaMatic bijna volledig terug te vinden in Adempiere. Ook zijn er enkele dingen die met Adempiere wel kunnen, maar niet met KassaMatic. De belangrijkste features van ons systeem zijn: Producten en Relaties kunnen worden gemaakt, bekeken en aangepast. Het is mogelijk om inkooporders te maken en te printen, en om de binnengekomen bestelling in te boeken in het magazijn. Er kunnen offertes worden gemaakt en facturen, en deze passen indien van toepassing automatisch de voorraad aan. Ook kan er worden bijgehouden of de facturen al betaald zijn en kunnen er aanmaningen worden gestuurd horende bij een geselecteerde factuur. Verschillende actoren hebben toegang tot verschillende gegevens en functionaliteit. Er worden automatisch backups gemaakt, en dit kan ook handmatig worden gedaan. Backups kunnen worden teruggezet Er zijn echter ook enkele features die we wel hadden moeten en willen implementeren, maar die we niet gehaald hebben: Artikelen kunnen niet worden ingescand en uitgescand. Het is niet mogelijk om labels te printen. Het is niet mogelijk om creditnota s te maken. Er waren ook nog enkele zaken die niet epliciet beschreven zijn in de requirements, maar welke we wel belangrijk genoeg vonden om onder handen te nemen. Dit komt grotendeels neer op het vertalen van de User Interface. Andere dingen die we hebben gedaan, die niet direct terug te zien zijn door de gebruikers, zijn het regelen van een betere (en veel goedkopere) internetverbinding voor de hoofdvestiging in Den Haag, waarbij er nu ook een internetaansluiting is in het magazijn en de kledingwinkel. Verder is er een server opgezet bij Amazon waarop het systeem kan draaien. 4.2 Werking Adempiere Adempiere is een erg groot en krachtig systeem met ontzettend veel mogelijkheden. Een vrijwel onvermijdelijk gevolg hiervan is dat het systeem niet gemakkelijk is om te begrijpen zonder het gebruik van een handleiding. We geven daarom een kleine inleiding in het gebruik van Adempiere.

23 Pagina Inloggen Na het starten van ADempiere wordt de gebruiker gevraagd om in te loggen via het Inlogscherm(zie Figuur 1). De gebruiker dient nu de Gebruikersnaam en het Wachtwoord in te vullen en op het vinkje rechtsonder te klikken. Hiermee komt de gebruiker, als de ingevulde gegevens correct waren, kan de gebruiker kiezen met welke Rol, Client, Organisatie en Magazijn er ingelogd moet worden. Figuur 1 Inlogscherm De beschikbare rollen verschillen per gebruiker en de velden eronder passen zich aan a.d.h.v. de geselecteerde rol. De Client is standaard voor elke gebruiker Bokstijn Feestartikelen en hoeft niet veranderd te worden. Bij Organisatie kan de vestiging gekozen worden waarvoor de aanpassingen in het systeem gemaakt gaan worden (* betekend hier Alle ). Verder kan nog het Magazijn gekozen worden waarmee gewerkt moet worden, en onderaan de printer waarmee je de documenten wilt printen. Als de selecties zijn gemaakt, kun je in het systeem inloggen door op het vinkje rechtsonder te klikken Rollen & Rechten Standaard heeft ADempiere een gebruikers-systeem, waarbij aan elke gebruiker, die in kan loggen, een aantal rollen toegewezen kan krijgen. Een rol bepaalt onder andere tot welke schermen de gebruiker toegang heeft. ADempiere voorziet vanaf de eerste installatie al in een drietal rollen, namelijk een rol voor de normale gebruiker, een administratieve rol en een SystemAdministrator rol. De eerste twee rollen geven alleen toegang tot de normale en administratieve taken van de applicatie (het Front-end), terwijl de SystemAdministrator rol toegang geeft tot het achterliggende model van het geïnstalleerde pakket (het Back-end). De enige gebruiker met toegang tot deze rol is de SuperUser.

24 Pagina Schermen De structuur in de schermen van ADempiere wordt gegenereerd en is overal dus grotendeels hetzelfde. Dit type scherm wordt aangeduid als een Lijst/Detail-scherm. Een uitzondering hierop is het Menuscherm (zie Figuur 2). Figuur 2 Menuscherm Menuscherm Nadat de gebruiker in heeft gelogd, zal hij/zij terecht komen in het Menuscherm. Dit scherm heeft de volgende onderdelen: Aan de linkerkant de boom met alle beschikbare schermen voor deze rol. Boven deze boom staat een zoekveld waarmee gezocht kan worden naar beschikbare schermen. Rechts bovenin staat informatie over de ingelogde gebruiker, kunnen de voorkeuren aangepast worden en kan uitgelogd worden. In het midden staat het tabblad Menu. Als er meerdere schermen geopend worden komen deze als tabbladen naaste het tabblad Menu te staan.

25 Pagina 24 Tabblad Menu In het menu tabblad staan bovenin verwijzingen naar verschillende soorten systeemmeldingen. Daar onder staat een lijst met snelkoppelingen naar veel favoriete functies/schermen, en onderin staan links naar read-only schermen. Snelkoppelingen zijn toe te voegen door een scherm/functie uit de boom naar het vak met favorieten te slepen. Snelkoppelingen zijn te verwijderen door er met de rechtermuis op te klikken en dan aan te geven dat je deze wilt verwijderen Lijst/Detail-scherm Na het doorklikken in het menuscherm, naar bijvoorbeeld het scherm producten, zal vaak Lijst/Detailscherm geopend worden. Dit type scherm komt het meest voor en heeft ook de meeste opties. Bovenin het scherm is de taakbalk te vinden. Hieronder bevindt zich de actiebalk, waarbij de meest gebruikte acties benaderbaar zijn door op het bijbehorende icoon te drukken. Deze iconen zijn als volgt: Ongedaan maken Lijst/Detail wissel Rapporteer Help Geschiedenis Archief Nieuw Hoofdmenu Printvoorbeeld Verwijder enkel Tab niveau hoger Print Verwijder meer Tab niveau dieper Zoek in systeem Opslaan Bovenste lijstelement Actieve Workflows Verversen Hoger lijstelement Aanvragen bekijken Zoeken Lager lijstelement Product informatie Bijlage Onderste lijstelement Scherm afsluiten Chat Een belangrijk scherm is het scherm Product Informatie (zie Figuur 3). Er kunnen meerder filtercriteria worden ingegeven om producten te zoeken. De gevonden product kunnen op iedere kolom gesorteerd worden door eenvoudigweg op de kolomtitel te klikken. Figuur 3 Product Informatie scherm

26 Pagina 25 Een typisch scherm om informatie aan te passen is het scherm Relaties (zie Figuur 4). Aan de linkerkant van dit scherm staat een aantal tabbladen onder elkaar. Deze tabbladen representeren de achterliggende tabellenstructuur van Adempiere. In deze verschillende tabbladen kan aangegeven worden of deze relatie bijvoorbeeld een leverancier, klant of werknemer is. En kan hier ook specifieke informatie worden ingevoerd, gewijzigd en bekeken. Figuur 4 Relaties scherm In het scherm Inkooporder (zie Figuur 5) kan een bestelling worden gemaakt die geprint kan worden of rechtstreeks naar de leverancier g d kan worden. In het bovenste tabblad kan de algemene informatie van de order worden ingevuld. Iedere inkooporder kan verschillende instanties hebben van het type PO Line (factuurregel). Een PO Line heeft een product en een aantal. De prijs wordt automatisch door het systeem ingevuld, maar kan worden overschreven door de gebruiker. Figuur 5 Inkooporder scherm

27 Pagina Internet Ons uiteindelijke ontwerp vereiste een fysieke aanpassing van de huidige ICT infrastructuur aan de panden van de opdrachtgever. Zo moesten o.a. 2 panden van internet voorzien worden. We hebben onderzoek gedaan naar de benodigde internetverbindingen, en hebben gekeken welke providers dit onder welke voorwaarden konden leveren. Ziggo kwam hierbij als beste keus uit de bus, en we hebben een abonnement afgesloten. 4.4 Server Voor het draaien van Adempiere hebben we een server geconfigureerd bij Amazon. Op deze server hebben we ook een nieuwe instantie van het Magento systeem geplaatst. Deze instantie zal de huidige versie van het Magento systeem vervangen. Hiervoor moet nog wel de data van de huidige Magento instantie worden overgezet naar de Magento instantie bij Amazon. Dit valt echter buiten de scope van ons project.

28 Pagina 27 5 Conclusie(s) Bij het begin van het project hebben we vastgesteld dat het vooral erg belangrijk was om, ook als het systeem niet helemaal af zou komen, in ieder geval een systeem af te leveren waar Bokstijn Feestartikelen van gebruik zou kunnen doen. Om dat te doen moest het nieuwe systeem in ieder geval de functionaliteit van KassaMatic bevatten, en verder ook de voorraad kunnen bijhouden. De functionaliteit van KassaMatic grotendeels terug te vinden in ADempiere. Naast de functionaliteit van KassaMatic, houdt het Adempiere wel de voorraad bij van producten. Ook kunnen producten vanuit Adempiere eenvoudig in de webshop gezet worden, wat een serieuze verbetering is ten opzichte van de huidige situatie. Het grootste gemis aan ons resultaat is het ontbreken van een magazijn scan interface, waarmee producten die het magazijn in- of uit gaan makkelijk geregistreerd kunnen worden. Op deze manier wordt het een stuk minder realistisch dat het voorraadbeheer in de praktijk gebruikt zal worden. Behalve het opzetten van Adempiere, hebben we ook betere internetverbindingen gerealiseerd voor Bokstijn voor een lagere prijs. Dit is iets waar Bokstijn Feestartikelen zonder meer direct voordeel van heeft. Onze conclusie is dat het opgeleverde producten verbeteringen heeft ten opzichte van KassaMatic, maar waarschijnlijk niet aan de verwachtingen voldoet. De periode die voor het bachelor eind project stond, 11 weken, bleek te kort te zijn om volledig aan deze requirements te kunnen voldoen.

29 Pagina 28 6 Aanbevelingen Het uiteindelijke resultaat van ons Bachelor Eindproject in een ADempiere installatie toegespitst op gebruik binnen Bokstijn Feestartikelen. In dit hoofdstuk zullen wij een aanbeveling doen over het wel of niet in gebruik nemen van dit ERP pakket en de mogelijke vervolgstappen die Bokstijn Feestartikelen kan nemen. 6.1 Voordelen van ADempiere boven KassaMatic Producten kunnen worden gesynchroniseerd naar de Magento webwinkel ADempiere, een va programma, is nauwelijks afhankelijk van het besturingssysteem op de computer: Windows 64-bit, Mac OS X en Linu worden ondersteund door ADempiere maar niet door KassaMatic ADempiere is een zeer compleet pakket wat uitgebreid kan worden om aan de toekomstige wensen van Bokstijn te voldoen ADempiere ondersteund voorraadbeheer ADempiere bevat kassasoftware (Point of Sale software) en kan dus gebruikt worden om kassa s te digitaliseren en moderniseren ADempiere is goedkoop aangezien enkel voor de hardware betaald wordt, de software is gratis 6.2 Nadelen van ADempiere t.o.v. KassaMatic ADempiere werkt in de huidige opstelling niet zonder internetverbinding De functionaliteit van ADempiere wordt beperkt doordat deze over internet gebruikt moet worden De interface van ADempiere verschilt sterk van KassaMatic, wat training en gewenning bij medewerkers vereist ADempiere werkt niet samen met labelprinters ADempiere is niet volledig naar Nederlands vertaald ADempiere heeft geen support en de documentatie is beperkt In onze ogen is blijven werken met KassaMatic over enkele jaren geen optie meer. 32-bit Windows systemen worden langzaam uitgefaseerd en onze verwachting is dan ook dat 32-bit Windows niet meer mogelijk zal zijn binnen 5-10 jaar. Na deze periode kan KassaMatic niet meer gebruikt worden. Dit geeft Bokstijn Feestartikelen de volgende opties: 1. ADempiere in gebruik nemen 2. ADempiere in gebruik nemen, maar een andere lange-termijn ERP oplossing zoeken 3. KassaMatic houden en een andere lange-termijn ERP oplossing zoeken Wij raden aan Bokstijn Feestartikelen aan om enkele weken ADempiere te evalueren en te bekijken wat haar nadelen in de praktijk voor impact hebben. Hierna kan gekozen worden voor een van de 3 opties. Indien voor optie 1 gekozen wordt raden wij wel aan om te overwegen een server aan te kopen, deze in het hoofdpand te instaleren en ADempiere hier naar toe over te zetten. Op deze manier kan ADempiere (binnen) het hoofdpand met volledige functionaliteit (bijv. labelwriter) en zonder internetverbinding gebruikt worden. Dit bespaard op de lange termijn ook kosten.

30 Pagina 29 7 Reflectie In dit hoofdstuk zullen wij reflecteren op het verloop van het project en de belangrijkste van de door ons gemaakte keuzes. 7.1 Keuze zelf ontwikkelen of baseren op een bestaand pakket Na het verzamelen van de requirements werd ons duidelijk dat het project groter was dan wij initieel ingeschat hadden. De verwachting was dat wij niet succesvol binnen het gestelde tijdslimiet software zouden kunnen ontwikkelen. Hierom hebben wij gekozen om een bestaand pakket te nemen en dit te configureren, en waar nodig uit te breiden. Wij zijn zeer tevreden over deze keuze en denken nog steeds dat dit verstandig was. Hoewel ons huidige resultaat niet volledig aansluit op de wensen van de opdrachtgever is het alsnog een compleet, getest en goed bruikbaar ERP pakket. Indien wij zelf hadden geprobeerd een ERP pakket te ontwikkelen dan was dit waarschijnlijk op dit moment niet bruikbaar genoeg geweest om enig voordeel voor de opdrachtgever te hebben. Conclusie: De keuze om niet zelf software te ontwikkelen was de juiste keuze 7.2 Keuze voor ADempiere en uitsluitingscriteria Wij hebben uitgebreid onderzocht welke ERP pakketten er beschikbaar waren op de markt. Deze tijdens de oriëntatiefase gemaakte vergelijking is opnieuw te vinden als Bijlage X: ERP / CRM longlist. Uit deze longlist is een shortlist gemaakt, te vinden als Bijlage X: ERP / CRM shortlist. Uit deze shortlist hebben wij initieel voor JFire gekozen, maar na het onmiddellijk tegenkomen van enkele grote risicofactoren die wij al eerder geïdentificeerd hadden (slecht geteste software, gebrekkige documentatie en gebrekkige ontwikkelaarstools). Wij zijn dan ook na 2 dagen overgeschakeld naar onze 2 de keuze, ADempiere, welke wij hebben aangehouden. Uit onze shortlist hebben wij naar ons idee de beste keuze gemaakt, en ook de overschakeling naar ADempiere is een verstandige keuze geweest. Wij zijn echter minder tevreden over het uitsluiten van enkele keuzes uit onze longlist. Keuzes zijn voornamelijk uitgesloten op de volgende 3 criteria: voldoet niet aan de Business requirement, heeft enkel een webinterface (geen desktopclient) of is niet geprogrammeerd in va, C# of PHP. Het eerste criteria vinden wij nog steeds verstandig. Van ons tweede criteria hebben wij echter achteraf spijt: uiteindelijk hebben wij namelijk de webinterface van ADempiere gebruikt als primaire User Interface. Een desktop client bleek dus uiteindelijk geen harde eis. Over de eis aan programmeertalen zijn wij neutraal: enkele veelbelovende pakketten waren geprogrammeerd in Python, waar geen van ons ervaring in had. Achteraf hadden wij deze waarschijnlijk toch moeten meenemen in onze schortlist en serieus moeten overwegen. Echter was het voor ons onmogelijk geweest om veel development te doen als wij in de korte tijd die voor het project stond ook nog een nieuwe programmeertaal moesten leren. Conclusie: De keuze om pakketten niet te overwegen omdat deze webgebaseerd waren of vanwege de programmeertaal waren onjuist, alle pakketten die aan de business requirements voldoen hadden overwogen moeten worden in de shortlist

31 Pagina Planning en evaluatie Zoals in 3.1 beschreven is hebben wij besloten om elke twee weken de planning te evalueren en te besluiten wat te doen voor de komende 1 à 2 weken. Dit had als gevolg dat wij op de hoogte waren van wat er nog moest gebeuren en heeft ervoor gezorgd dat wij op enkele momenten besloten hebben dingen te laten vallen, omdat het niet realistisch was dat wij deze nog gingen voltooien. Een nadeel hiervan is dat het niet Conclusie: De keuze om elke twee weken de planning te evalueren was een goede keuze: het stelde ons in staat om te allen tijde een accurate en realistische planning te hebben.

32 Pagina 31 8 Bijlagen 8.1 Originele planning Week Start Planning v1 Bezigheden Oriën. Ontw. Impl. Migr. Afr apr Oriëntatieverslag 2 30-apr Oriëntatieverslag Oriëntatie op JFire Systeem ontwerpen 3 7-mei Systeem ontwerpen Productbeheer Relatiebeheer Documentbeheer 4 14-mei Productbeheer Relatiebeheer Documentbeheer Voorraadbeheer 5 21-mei Voorraadbeheer 6 28-mei Magento koppeling 7 4-jun Magento koppeling SIG code review jun Refactoring m.b.v. SIG commentaar Magento koppeling Overzetten gegevens KassaMatic 9 18-jun Overzetten gegevens KassaMatic jun Acceptance testing SIG code review jul Omstreeks eindpresentatie Eindverslag en presentatie

33 Pagina Gevolgde planning Week Start Planning v5 Bezigheden Oriën. Ontw. Impl. Migr. Afr apr Oriëntatieverslag 2 30-apr Oriëntatieverslag Oriëntatie op ERP systemen Oriëntatie op JFire 3 7-mei Orientatie op ADempiere Use cases Evaluatie planning 4 14-mei Ontwerpen infrastructuur Internet upgrade onderzoeken Onderzoeken ADempiere datamodel 5 21-mei Ontwerpverslag Ontwerpen GUI Boekhouding Bokstijn onderzoeken Opzetten Amazon virtuele server Opstellen plan tot configuratie Adempiere Configureren productbeheer Configureren relatiebeheer Configureren documentbeheer Configureren toegangbeheer Evaluatie planning 6 28-mei Configureren ADempiere (zie wk 5) Goedkeuring ontwerp Opzetten NL vertaling Adempiere Opzetten Servers Aanvragen internetverbinding 7 4-jun Configureren ADempiere (zie wk 5) Vertalen Adempiere Date import uit Kassamatic (SIG code review 1) Evaluatie planning 8 11-jun Magento koppeling Magazijn interface Vertalen Adempiere Schrijven user-documentatie Installatie internetverbinding panden 9 18-jun Magento koppeling Magazijn interface User documentatie schrijven Overzetten Δ van KassaMatic Evaluatie planning jun Acceptance testing On-site installatie van software Magento koppeling Magazijn interface Aanpassingen a.d.v. wensen opdrachtgever Schrijven eindrapport SIG code review jul Installatie Ziggo internetverbinding Eindpresentatie

34 8.3 Klassendiagram Magento converter

35 8.4 Sequence diagram normale conversie van ADempiere naar Magento

36 8.5 Uiteindelijk Requirement Overzicht Prioriteit Gehaald Requirement Gewenst Optioneel Gewenst Gewenst Gewenst Gewenst Gewenst Nee Nee, hoofdfoto Nee Nee 1) Producten a) Er moet een overzicht komen van alle producten, dat gemakkelijk en snel te filteren/doorzoeken is naar een product met bepaalde eigenschappen. b) Als er op een product geklikt wordt moet er een overzichtspagina zichtbaar worden met daarin eigenschappen van het product. c) Op elke overzichtspagina kunnen de eigenschappen van een product worden aangepast. i) Elk product heeft een aantal verplichte eigenschappen. ii) Van elk product moet de actuele voorraad in het hoofdmagazijn worden weergegeven. iii) Elk product moet een minimale voorraad hebben. d) Elk product moet de optie hebben automatisch gesuggereerd te worden bij een nieuwe inkooporder van de betreffende leverancier (als de voorraad minder is dan een minimale voorraad). e) Elk product moet een lijst met staffelprijzen hebben, elk met een begin- en einddatum. f) Het zou handig zijn om aan elk product een magazijn-locatie toe te kunnen wijzen. g) Bij elk product moet er (een knop/link naar) een overzicht van alle documenten zijn waarin dit product voorkomt. i) Dit overzicht moet o.a. sorteerbaar/filterbaar zijn op document-type. h) Een product moet een datum hebben, waarop het voor het laatst geleverd (binnengekomen in het hoofdmagazijn) is. i) Producten moeten één van de volgende statussen hebben. i) Online (zichtbaar in de webshop, zichtbaar in de overzichtslijsten, zichtbaar in documenten) ii) Offline (zichtbaar in de overzichtslijsten, zichtbaar in documenten) iii) Non-actief (nergens zichtbaar, behalve in documenten) j) De status van de producten moet in de overzichtslijsten zichtbaar zijn. Bijvoorbeeld: Producten die op Non-actief staan met een grijze arcering. k) Elk product moet de mogelijkheid hebben een hoofdfoto te hebben en meerdere sub-foto's. i) Producten kunnen alleen 'Online' (en dus actief op de webshop) gezet worden als deze minstens één afbeelding hebben. l) De voorraad van een product moet negatief kunnen zijn. m) Er moet een overzicht zijn van alle producten die een negatieve voorraad in het hoofdmagazijn hebben. Gewenst Nee 2) Relaties a) Relaties kunnen onder één of meer van de volgende groepen vallen: i) Crediteur (leveranciers). ii) Debiteur (klanten). b) Relaties hebben een nationale status: i) Binnenland. ii) Buitenland. c) Er moet een overzicht komen van alle leveranciers. Met van elke leverancier een aantal eigenschappen in kolommen. d) Als er op een leverancier geklikt wordt moet er een overzichtspagina zichtbaar worden, met daarin de eigenschappen van de leverancier. e) Er moet ook (een knop/link naar) een overzicht van alle inkooporders van de betreffende leverancier komen.

37 Pagina 36 Gewenst Optioneel Gewenst Gewenst Gewenst Gewenst Gewenst Optioneel Gewenst Nee Nee Nee Nee Nee Nee Nee N.V.T. 3) Documenten a) Er moet een overzichtslijst zijn voor elk type document. Namelijk: Offertes, Inkooporders, Facturen, Creditnota s, en Aanmaningen. b) De overzichtslijst moet filterbaar/sorteerbaar zijn op bepaalde eigenschappen. c) Bij het klikken op een document in de betreffende overzichtslijst, moet er een overzichtsscherm zichtbaar worden van het betreffende document. d) Documenten moeten gegenereerd kunnen worden i) De layout van deze documenten moet zelf te definiëren zijn. e) Documenten moeten na het voltooien g d kunnen worden naar een ontvanger. f) Documenten moeten een standaard oplopende nummering krijgen. Voorstel: [jaartal]_[type]_[nummer] b.v. 2012_O_0001, 2012_I_0001, 2012_F_0001, 2012_C_0001, 2012_A_0001 g) De status van de documenten moet in de overzichtslijsten zichtbaar zijn. Bijvoorbeeld: Documenten die nog onvoltooid zijn met een rode/oranje arcering. Requirements voor Offertes: h) Kortingen op producten moeten gegeven kunnen worden over elk product apart, maar ook in één keer op een selectie producten. i) Hiervan mag geen kolom-kop zichtbaar zijn in het lijst-overzicht. Requirements voor Inkooporders: i) Inkooporders moeten open kunnen staan, totdat de producten geleverd zijn. j) Inkooporders moeten op 'onvoltooid' kunnen staan. k) In het overzicht moet duidelijk zichtbaar zijn of een inkooporder al voltooid is, en of deze nog open staat of niet. l) Bij buitenlandse crediteuren komt er geen BTW op de inkooporder. m) Er moeten automatische suggesties selecteerbaar zijn van producten waarvan de voorraad onder de minimale voorraad zit. n) Bestaande producten moeten gemakkelijk, vanuit een lijst van producten van deze leverancier, toe te voegen zijn aan een inkooporder. i) Deze lijst moet filterbaar/sorteerbaar zijn op de eigenschappen van de producten. o) Als een product wel besteld moet worden, maar deze nog niet voorkomt in de producten-database, moet deze gemakkelijk toe te voegen zijn. p) Het zou handig zijn als de inkooporder eenvoudig vanuit het systeem naar de leverancier g d kan worden. Requirements voor Facturen: q) In het overzicht moet duidelijk zichtbaar zijn of een factuur nog open staat of niet. r) Facturen moeten zowel 'Inclusief-BTW' als 'Eclusief-BTW' te genereren zijn, voor respectievelijk bedrijven en particulieren. s) Kortingen op producten moeten gegeven kunnen worden over elk product apart, maar ook in één keer op een selectie producten. Hiervan mag geen kolom-kop zichtbaar zijn in het lijst-overzicht. t) Elke factuur heeft een uniek nummer en Relatie, welke niet te veranderen zijn. Het is heel belangrijk voor de belasting dat de relatie en factuur nummer van een factuur niet te veranderen zijn. u) Facturen moeten open kunnen staan, zolang deze nog niet betaald zijn. v) De inhoud van een factuur is altijd aan te passen, zelfs als deze al voltooid is. i) Op het moment dat een voltooide factuur aangepast moet worden, moet de gebruiker een waarschuwing krijgen.

38 Pagina 37 Gewenst Nee Nee Nee Nee Nee w) De volgende betalingsmogelijkheden moeten per factuur beschikbaar zijn: i) Betaald per bank, met een geselecteerd bankrekeningnummer. ii) Contant betaald. ) Bij het opstarten van het programma moet er een melding komen als er nog facturen al een aantal dagen op staan. i) Bij deze facturen moet een aanmaning gestuurd kunnen worden. Requirements voor Creditnota s y) Creditnota's kunnen, maar zijn niet verplicht gelinkt zijn aan een bestaande factuur. Requirements voor Aanmaningen z) Aanmaningen moeten per Relatie gegroepeerd worden. aa) Aanmaningen moeten in een drietal varianten gedefinieerd kunnen worden, elk met een verschillende toon. 4) Printen a) Het moet mogelijk zijn om (een lijst van) documenten, in een zelf gedefinieerde lay-out, met een standaard printer te printen. b) Er moeten etiketten geprint kunnen worden met een DynoLabelWriter. i) Labels voor kleding, welke per product, voor elke bestaande kledingsvariant, de eigenschappen van het kledingstuk bevatten. ii) Labels voor ballonnen, welke meestal alleen de kleur en het aantal stuks per verpakking bevatten. 5) Toegangsbeheer a) Bij het opstarten van het programma moet de gebruiker inloggen in het systeem, waarbij hij bepaalde rechten toegewezen krijgt. b) Schermen moeten zichtbaar zijn a.d.h.v. toegangsbeheer. i) Werkvloer-rechten geven recht tot: (1) Productoverzicht. ii) Magazijn-rechten geven recht tot: (1) Productoverzicht. (2) Product inscannen en uitscannen. iii) Kantoor-rechten geven recht tot: (1) Productoverzicht. (2) Product inscannen en uitscannen. (3) Producten toevoegen. (4) Producten aanpassen. (5) Relatieoverzicht. (6) Documentoverzicht. (7) Programma instellingen wijzigen. iv) Admin-rechten geven recht tot: (1) Productoverzicht. (2) Product inscannen en uitscannen. (3) Producten toevoegen. (4) Producten aanpassen. (5) Relatieoverzicht. (6) Documentoverzicht. (7) Programma instellingen wijzigen. (8) Toegangsbeheer.

39 Pagina 38 Gewenst Gewenst Gewenst Optioneel Optioneel Gewenst Gewenst Gewenst Optioneel Optioneel Optioneel Optioneel Gewenst Gewenst Optioneel Optioneel Nee Nee Nee Nee Nee Nee Nee Nee Nee Nee c) Na een instelbaar aantal minuten van inactiviteit moet de gebruik opnieuw inloggen. i) Dit geldt niet als er ingelogd is met de magazijn rechten. d) De gebruikersnamen en wachtwoorden zijn gelinkt aan het toegangsbeheer van de Magento webshop Database. e) De gebruikersnamen en wachtwoorden moeten versleuteld opgeslagen worden. 6) Stabiliteit a) Het is handig om een logboek systeem te hebben bij het geval van crashes. b) De databases moeten reserve kopieën van zichzelf maken. i) Het is handig als dit ook handmatig gestart kan worden. ii) Voor disaster recovery moet data uit het systeem plaintet uitleesbaar zijn vanuit een backup. iii) Backups moeten teruggezet kunnen worden. 7) Webshop a) Op het moment dat er een nieuw product aangemaakt wordt, moet deze op de webshop gezet worden. b) Als een producteigenschap aangepast wordt, moet dit ook meteen in de webshop database aangepast worden. 8) Gebruiksvriendelijkheid a) Er moet een oplossing zijn voor als het programma geen verbinding kan maken met internet. b) De applicatie moet bij product- en voorraadbeheer geen zichtbare vertraging hebben. c) Het systeem moet draaien op de nu aanwezige Windows 7 computers. d) Het systeem moet communiceren met de huidige aanwezige webserver waar Magento op draait. e) Voor de boekhouder moeten de volgende lijsten geëporteerd kunnen worden: i) Een overzichtslijst van alle facturen van een bepaalde datum, tot een bepaalde datum. ii) Een overzichtslijst van alle facturen die tot moment van eporteren nog open staan. f) Het is handig om een Document lay-out manager te hebben, waarin op een visuele manier de lay-out van de verschillende documenten gemakkelijk aan te passen is. g) Het is handig om in te kunnen stellen, in welk zoekveld de cursor start bij een overzichtslijst. h) Het is handig om bij filtervelden voor numerieke waarden operators te kunnen gebruiken, zoals b.v. '<', '>', '<=' en '>='. i) Het is handig om kolombeheer te hebben, waarbij je in kan stellen welke kolommen in de overzichtslijsten zichtbaar zijn, en de volgorde waarin ze staan. j) De kolommen van de overzichten moeten vast gezet kunnen worden, zodat deze niet kunnen verdwijnen, als de tabel naar rechts gescrold wordt. k) Overzichtslijsten moeten zich sorteren op een eigenschap, als er bij de kolomtitel van deze eigenschap wordt gedrukt. l) Het is handig om een help menu te tonen als er op F1 gedrukt wordt. m) Het is handig als er een overzicht is met alle producten waar op dit moment een staffel voor geldt. i) Klikken op het product zal naar de detail pagina van het product gaan. ii) De aanbiedingsprijs is de staffelprijs van de hoeveelheid van 1.

40 Pagina 39 Nee Nee Nee Nee 9) Voorraadbeheer a) Met de magazijnrechten moet het systeem een in- en uitscanmodus hebben. b) Barcodes moeten gescand kunnen worden en herkend door het systeem. c) Het product wordt dan aan een in- of uitscanlijst gezet op het scherm met beperkte productinformatie. i) Het aantal wordt standaard op 1 gezet. ii) Dit aantal moet handmatig veranderd kunnen worden. iii) Het zou handig zijn als producten gegroepeerd worden als er meerdere malen hetzelfde product wordt gescand. iv) Met een druk op de knop kunnen alle artikelen uit de lijst in of uit het hoofdmagazijn worden geboekt. d) Als een product niet bekend is in het systeem, moet de gebruiker hiervan een mededeling krijgen, en kan het niet worden ingescand, het product moet eerst op het kantoor worden ingevoerd.

41 IN3405 Bachelor project Opdracht Bokstijn Feestartikelen Over Bokstijn Feestartikelen Bokstijn Feestartikelen is een in 1908 opgericht bedrijf, dat zich specialiseert in de verkoop van feestartikelen (denk hierbij aan carnavalskostuums, accessoires, fopartikelen en een gevarieerd aanbod van feestdecoraties) en op maat gemaakte ballondecoraties. Naast onze webshop, hebben we fysieke winkels op drie plaatsen in de Randstad. Onze hoofdwinkel staat in Den Haag, met in dezelfde straat nog drie andere panden die gebruikt worden voor kledingverkoop, productopslag en fabricage van ballondecoraties. Naast onze winkel(s) in Den Haag hebben we een winkel in Leiden en twee winkels op Attractiepark Duinrell. Huidige stand van zaken Op dit moment maken we gebruik van twee losse databases voor onze producten. De eerste is nieuwer (ten opzichte van de tweede) SQL database, met Magento als CMS, welke wordt gebruikt voor onze webshop op De tweede database is een offline database, totaal los van de online database voor de webshop, welke beheerd wordt door het computer programma KassaMatic. Deze database is toegankelijk voor drie computers met KassaMatic-Licentie op het bekabelde netwerk van onze hoofdwinkel in Den Haag. Dit systeem draait als sinds de oertijd en wordt voor de volgende doeleinden gebruikt: - Overzicht van alle producten met hun eigenschappen (prijs incl.-/ecl. btw, inkoop/verkoop/staffel/aanbieding prijs, voorraad, afbeelding, beschrijving, leverancier). - Overzicht van alle aankopen die gedaan zijn bij een bepaalde leverancier. - Printen van inkooporders, welke dan naar leveranciers gestuurd kunnen worden. (post/mail) - Printen van offertes voor facturen voor de klanten. Deze moeten zelf instelbare offerte- /factuurnummers hebben, welke wel (standaard) oplopend zijn. - Het uitprinten van kleding labels middels een DynoWriter printer. - Layoutmanager, om de layout van deze inkooporders, offertes, facturen, etc. naar eigen wens te kunnen genereren. Deze database is op andere computers toegankelijk, doordat de hoofdcomputer een netwerkmap deelt, waarin de database opgeslagen staat. De andere computers op het netwerk kunnen bij deze netwerkmap, en KassaMatic staat op deze computers zo ingesteld dat ze de database van de netwerkmap gebruiken. Pagina 1

42 Onze opdracht Wat wij vragen van de studenten, is dat zij een systeem maken dat deze functionaliteiten ook heeft, maar ook voor al onze filialen in de Randstad toegankelijk is, en verder ook de voorraden van de artikelen bij kan houden, als producten verplaats worden tussen filialen. Verder willen wij graag meer inzicht in de statistieken van de aankopen van onze leveranciers. Hiernaast nog vragen wij dat het systeem alvast zo ingericht kan worden, dat er in een later stadia (of misschien al tijdens het project, als het voorspoedig verloopt) de volgende functionaliteiten gemakkelijk toegevoegd kunnen worden: - Het systeem zou bij voorkeur het webshop-database systeem moeten vervangen, zodat er maar één database met producten is, welke dan (door bijvoorbeeld een vinkje te zetten) gemakkelijk aangezet kunnen worden op de webshop. - Het scannen van producten met een barcode scanner bij levering, zodat deze gemakkelijk aan het voorraad beheer toegevoegd kunnen worden. De hardware is hier al voor aanwezig. - Een verkoop systeem, waarbij er een speciale kassa GUI gebruikt word en aan het eind van de dag een overzicht beschikbaar is van alle verkochte producten. Dit zou bij voorkeur gecombineerd kunnen worden met de barcode scanners. Etra Informatie De gebruikte omgeving/taal die voor dit project gebruikt moet worden staat niet vast. De studenten kunnen zelf kiezen wat zij hier het best van toepassing vinden. Contactpersonen Contactpersoon Bokstijn Feestartikelen: - Guido Bokstijn info@bokstijn.nl Student, al werkend bij Bokstijn Feestartikelen: - n-willem van Velzen jan.willem.van.velzen@gmail.com Pagina 2

43 Orie ntatieverslag IN3405 Bachelor project - Bokstijn Feestartikelen Studenten: David Hoepelman n-willem van Velzen Bart van Vuuren Begeleiders: Guido Bokstijn Bokstijn Feestartikelen Koen Hindriks Technische Universiteit Delft, Faculteit EWI Coördinator Bachelor Project: Peter Nieuwenhuizen

44 Voorwoord Voor het bachelor eindproject van de studie Technische Informatica doen wij, David Hoepelman, n- Willem van Velzen en Bart van Vuuren, een opdracht voor het bedrijf Bokstijn Feestartikelen. Dit document is het oriëntatieverslag dat wij aan het begin van de opdracht opstellen, met als doel het specificeren van de opdracht voor onszelf, de projectbegeleiders en de opdrachtgever. Hiermee willen wij een duidelijk beeld scheppen van de precieze inhoud van de opdracht. Naast het specificeren van de opdracht, zullen we de eisen waar ons systeem aan dient te voldoen zo precies mogelijk formuleren. Door dit te doen, kunnen we een oplossing ontwikkelen waarvan we zeker kunnen zijn dat deze voldoet aan de wensen van de opdrachtgever. We schrijven dit verslag met de volgende structuur: In hoofdstuk één omschrijven we de opdrachtgever, de probleemstelling en onze doelstellingen, aangevuld met een lijst van requirements en een risico analyse. In hoofdstuk twee zullen we ons plan van aanpak uit de doeken doen, waarbij we onze methoden, technieken en planning zullen beschrijven. Hoofdstuk drie beschrijft de projectinrichting. Hieronder vallen de betrokkenen en de faciliteiten die door ons gebruikt zullen worden. Als laatste hoofdstuk zullen we ingaan op de kwaliteitswaarborging van het beoogde systeem. Hierbij kan gedacht worden aan documentatie, versiebeheer en evaluaties. Samenvatting Bokstijn Feestartikelen maakt op dit moment gebruik van een tweetal product beheer systemen. De eerste is een online database met het ecommerce systeem Magento voor alle producten van de webshop, de tweede is in de vorm van het programma KassaMatic. KassaMatic voorziet in het beheer van alle producten, het beheer van relaties en het opstellen van documenten, zoals inkooporders en facturen. Echter is de versie van KassaMatic die op dit moment gebruikt wordt, al een lange tijd in gebruik, in geen jaren meer bijgewerkt en wordt ook niet meer ondersteund door de leverancier. Als gevolg hiervan werkt de software ook niet op 64-bit Windows installaties. Het online zetten van producten gebeurt op dit moment door handmatig alle informatie per product in het KassaMatic systeem op te zoeken en deze in Magento in te voeren. Dit heeft tot gevolg dat hooguit 20% van alle artikelen in de webshop te vinden is. Bokstijn Feestartikelen ziet graag een systeem met dezelfde functionaliteit, maar met de toegevoegde functionaliteiten van voorraadbeheer en het gemakkelijk online zetten van een product. De oplossing die wij aan Bokstijn Feestartikelen willen leveren is een nieuw systeem, welke KassaMatic totaal vervangt, en zelf communiceert met de Magento webshop. Verder zal ons systeem de voorraad uit het hoofdmagazijn bijhouden. Met dit nieuwe systeem hoeven nieuwe artikelen slechts één keer ingevoerd te worden, waarna het product met een simpele statuswijziging in de webshop geactiveerd zal worden. Verder wordt er in de webshop automatisch aangegeven of een product op voorraad is. Ook kan er in het nieuwe systeem de voorraad van artikelen bekeken worden. Verder zal er gemakkelijker gezocht kunnen worden naar een bepaald product. En zal er in het hoofdmagazijn een gebruikersinterface aanwezig zijn om, samen met een barcode-scanner, producten gemakkelijk het hoofdmagazijn in en uit te kunnen scannen. Pagina 2 van 20

45 Inhoudsopgave Voorwoord... 2 Samenvatting Opdrachtomschrijving Inleiding Contactpersonen Schets van de opdrachtgever Probleemachtergrond en aanleiding van de opdracht Doelstelling en opdrachtformulering Voorraadbeheer Koppeling met de webshop Op te leveren producten en requirements Requirements Afbakening opdracht Randvoorwaarden Plan van aanpak Inleiding Methodiek en Technieken Scrum Test Driven Development Keuze: bestaand of eigen pakket? Risicofactoren Planning Projectinrichting Inleiding Betrokkenen Faciliteiten Dagplanning Kwaliteitswaarborging Inleiding Documentatie Versiebeheer Evaluatie Bijlage A: Planning Bijlage B: ERP / CRM Longlist Bijlage C: ERP / CRM Shortlist Bijlage D: Literatuurlijst Pagina 3 van 20

46 1 Opdrachtomschrijving 1.1 Inleiding In dit hoofdstuk zullen we de opdracht die we gekregen hebben specificeren en uitdiepen. We geven eerst een beschrijving van de opdrachtgever, Bokstijn Feestartikelen, de redenen om dit project op te zetten. Daarna volgen een specificatie van de opdracht zelf, de randvoorwaarden voor het project en een risico analyse. 1.2 Contactpersonen De contactpersoon voor Bokstijn Feestartikelen is Guido Bokstijn, de eigenaar en bedrijfsleider van het bedrijf. 1.3 Schets van de opdrachtgever De opdrachtgever voor dit Bachelor eindproject is het bedrijf Bokstijn Feestartikelen. Dit bedrijf specialiseert zich in de verkoop van feestkostuums, feestartikelen, make-up, decoraties en alles wat daar mee te maken heeft. Het bedrijf heeft vestigingen in Den Haag, Leiden en Wassenaar, waarbij de vestiging in Den Haag het hoofdkantoor is. Naast deze fysieke vestigingen heeft Bokstijn Feestartikelen ook een webshop, waarbij een gedeelte van het volledige assortiment online te bestellen is. Bokstijn Feestartikelen verkoopt ruim 7000 verschillende feestartikelen, waarvan er ongeveer 20% ook via de webshop te bestellen is. Deze feestartikelen worden ingekocht en verkocht bij een kleine 200 geregistreerde zakenrelaties. Het werknemersbestand telt ongeveer 25 personen. De vestiging in Wassenaar betreft twee winkeltjes in attractiepark Duinrell, waarbij er in één van deze winkeltjes een kantoor is. Deze kleine winkels hebben een gezamenlijk magazijn met beperkte capaciteit. De vestiging in Leiden betreft één winkel in een winkelstraat, welke tevens het kantoor bevat. Deze vestiging heeft ook een eigen magazijn, wederom met een beperkte capaciteit. De vestiging in Den Haag omvat een viertal panden in dezelfde straat, waarvan één het hoofdmagazijn. Hier vanuit worden de andere vestigingen bevoorraad. Verder komen hier ook alle leveringen van leveranciers binnen. De andere panden in de straat zijn ingericht voor het blazen van ballonnen, de verkoop van kleding en het hoofdpand, waarin accessoires en ballonnen verkocht worden. Dit laatste hoofdpand bied tevens onderdak voor het hoofdkantoor. Bij het binnenkomen van producten in het hoofdmagazijn worden de aantallen vergeleken met de pakbonnen en de bestellings-lijsten, en worden er een aantal apart gelegd om vervoerd te worden naar de andere vestigingen. De resterende hoeveelheid wordt in het hoofdmagazijn zelf opgeslagen. Voor het beheren van alle producten en relaties wordt op dit moment het softwarepakket KassaMatic gebruikt. Dit pakket is oorspronkelijk ontwikkeld voor DOS en daarna geport naar een Windows interface. KassaMatic geeft een overzicht van alle ingevoerde producten in de database, alle relaties van het bedrijf (crediteuren en debiteuren) en geeft de mogelijkheid tot samenstellen van verschillende documenten, zoals offertes, inkooporders, facturen, creditnota s en aanmaningen. De versie van KassaMatic die op dit moment gebruikt wordt is echter al lange tijd niet bijgewerkt naar een nieuwe versie en wordt niet meer ondersteund door de leverancier. Verder werkt het niet op 64-bit Windows installaties. Pagina 4 van 20

47 KassaMatic werkt offline, daarmee bedoelen we dat per vestiging één computer een gedeelde netwerkmap heeft met daarin de databasebestanden, en dat andere computers op het interne netwerk deze bestanden hierdoor ook kunnen benaderen. Databases in andere vestigingen worden op dit moment up-to-date gehouden door eenmaal per maand de gegevens van de gedeelde netwerkmap van het hoofdkantoor middels een usb-stick te kopiëren naar de KassaMatic installaties in de andere vestigingen. Voor de webshop wordt er op dit moment een losse database bijgehouden, welke middels het Magento ecommerce systeem bijgehouden wordt. In Magento wordt naast de producten ook de webshop-bestellingen en betalingen beheerd. Deze twee databases hebben geen connectie met elkaar, en op het moment dat een product online in de webshop gezet moet worden, moet er handmatig de gegevens opgezocht worden in KassaMatic, deze moeten genoteerd worden en daarna handmatig worden ingevoerd in Magento. Dit is een erg tijd-intensieve stap, wat onder andere tot gevolg heeft dat er op dit moment maar 20% van het totale producten aanbod via de webshop te bestellen en bekijken is. Magento voldoet qua mogelijkheden prima aan de eisen, alhoewel de snelheid van de beheer interface niet optimaal is. Voorraadbeheer wordt op dit moment zowel in KassaMatic als Magento niet aan gedaan, al ondersteunen beidde pakketten het wel. En een koppeling tussen KassaMatic en Magento is niet mogelijk, wat tot gevolg heeft dat de informatie op de webshop soms verouderd is. 1.4 Probleemachtergrond en aanleiding van de opdracht Doordat de bedrijfsleider, Guido Bokstijn, tot voor kort vaak aanwezig was op het hoofdkantoor en in het hoofdmagazijn, had hij een goed overzicht op de actuele voorraad. De laatste tijd is hij hier echter minder vaak aanwezig, waardoor hij soms voor verrassingen komt te staan als het gaat om voorraad. Om een beter overzicht te hebben is het daarom van belang dat de voorraad bijgehouden wordt in een systeem. Ook zou het een grote verbetering zijn als een artikel niet in twee verschillende systemen ingevoerd hoeft te worden. 1.5 Doelstelling en opdrachtformulering Bokstijn Feestartikelen ziet graag een systeem met dezelfde functionaliteit als het KassaMatic, maar met de toegevoegde functionaliteiten van voorraadbeheer en het gemakkelijk aanpassen en online zetten van een product in de webshop Voorraadbeheer Onder voorraadbeheer wordt verstaan dat wordt bijgehouden wat de huidige voorraad van elk product in het hoofdmagazijn is, en het gemakkelijk aanpassen van deze voorraad als er bijvoorbeeld producten geleverd worden van een leverancier, of als er producten van het hoofdmagazijn naar één van de winkels verplaatst wordt. Voorraden in de winkels zelf hoeven niet bijgehouden te worden, al zijn hier wel plannen voor. Door voorraad beheer te laten doen door het systeem, wordt het eenvoudiger om tijdig producten te bestellen. Verder zal het veel minder vaak voorkomen dat een product besteld wordt, terwijl het al aanwezig was, maar tijdelijk kwijt. Verder heeft de opdrachtgever op deze manier een beter inzicht van de verkopen in een bepaalde periode. Pagina 5 van 20

48 1.5.2 Koppeling met de webshop Onder de koppeling met de webshop wordt verstaan dat alle informatie die bij een product aangepast wordt in de database van het hoofdkantoor, ook meteen aangepast wordt op de webshop. Verder moet het product gemakkelijk (on)zichtbaar gemaakt kunnen worden in de webshop, waarbij deze standaard onzichtbaar zijn. De koppeling met de webshop heeft als voordeel dat de gegevens niet verschillend kunnen zijn in verschillende systemen. Bovendien hoeven gegevens niet handmatig twee keer te worden ingevoerd, wat tijd bespaart. Alle vestigingen zullen zelf nog wel een eigen cache-database moeten hebben, voor het geval dat internet niet werkt. 1.6 Op te leveren producten en requirements Het op te leveren product is een softwarematige oplossing die, naast de functionaliteit die KassaMatic nu biedt, zorgt voor het beheer van de voorraad van het hoofdmagazijn bij de hoofdvestiging. Verder moet deze een koppeling met de Magento-database omvatten, waarmee de webshop veel gemakkelijker up-to-date te houden is en de voorraadinformatie in de webshop beschikbaar is Requirements Het systeem dat wij beogen systeem heeft de volgende onderverdeling: 1. Producten 2. Relaties (Crediteuren, Debiteuren, Crediteuren/Debiteuren) 3. Documenten (Offertes, Inkooporders, Facturen, Creditnota's en Aanmaningen) 4. Printen 5. Toegangsbeheer 6. Stabiliteit 7. Webshop 8. Gebruiksvriendelijkheid 9. Beheerbeheer Prioriteit Gewenst Optioneel Gewenst Gewenst Requirement 1) Producten a) Er moet een overzicht komen van alle producten, dat gemakkelijk en snel te filteren/doorzoeken is naar een product met bepaalde eigenschappen. b) Als er op een product geklikt wordt moet er een overzichtspagina zichtbaar worden met daarin eigenschappen van het product. c) Op elke overzichtspagina kunnen de eigenschappen van een product worden aangepast. i) Elk product heeft een aantal verplichte eigenschappen. ii) Van elk product moet de actuele voorraad in het hoofdmagazijn worden weergegeven. iii) Elk product moet een minimale voorraad hebben. d) Elk product moet de optie hebben automatisch gesuggereerd te worden bij een nieuwe inkooporder van de betreffende leverancier (als de voorraad minder is dan een minimale voorraad). e) Elk product moet een lijst met staffelprijzen hebben, elk met een begin- en einddatum. f) Het zou handig zijn om aan elk product een magazijn-locatie toe te kunnen wijzen. g) Bij elk product moet er (een knop/link naar) een overzicht van alle documenten zijn waarin dit product voorkomt. i) Dit overzicht moet o.a. sorteerbaar/filterbaar zijn op document-type. h) Een product moet een datum hebben, waarop het voor het laatst geleverd (binnengekomen in het hoofdmagazijn) is. Pagina 6 van 20

49 Gewenst Gewenst Gewenst Gewenst Gewenst Optioneel Gewenst Gewenst Gewenst Gewenst Gewenst i) Producten moeten één van de volgende statussen hebben. i) Online (zichtbaar in de webshop, zichtbaar in de overzichtslijsten, zichtbaar in documenten) ii) Offline (zichtbaar in de overzichtslijsten, zichtbaar in documenten) iii) Non-actief (nergens zichtbaar, behalve in documenten) j) De status van de producten moet in de overzichtslijsten zichtbaar zijn. Bijvoorbeeld: Producten die op Non-actief staan met een grijze arcering. k) Elk product moet de mogelijkheid hebben een hoofdfoto te hebben en meerdere sub-foto's. i) Producten kunnen alleen 'Online' (en dus actief op de webshop) gezet worden als deze minstens één afbeelding hebben. l) De voorraad van een product moet negatief kunnen zijn. m) Er moet een overzicht zijn van alle producten die een negatieve voorraad in het hoofdmagazijn hebben. 2) Relaties a) Relaties kunnen onder één of meer van de volgende groepen vallen: i) Crediteur (leveranciers). ii) Debiteur (klanten). b) Relaties hebben een nationale status: i) Binnenland. ii) Buitenland. c) Er moet een overzicht komen van alle leveranciers. Met van elke leverancier een aantal eigenschappen in kolommen. d) Als er op een leverancier geklikt wordt moet er een overzichtspagina zichtbaar worden, met daarin de eigenschappen van de leverancier. e) Er moet ook (een knop/link naar) een overzicht van alle inkooporders van de betreffende leverancier komen. 3) Documenten a) Er moet een overzichtslijst zijn voor elk type document. Namelijk: Offertes, Inkooporders, Facturen, Creditnota s, en Aanmaningen. b) De overzichtslijst moet filterbaar/sorteerbaar zijn op bepaalde eigenschappen. c) Bij het klikken op een document in de betreffende overzichtslijst, moet er een overzichtsscherm zichtbaar worden van het betreffende document. d) Documenten moeten gegenereerd kunnen worden i) De layout van deze documenten moet zelf te definiëren zijn. e) Documenten moeten na het voltooien g d kunnen worden naar een ontvanger. f) Documenten moeten een standaard oplopende nummering krijgen. Voorstel: [jaartal]_[type]_[nummer] b.v. 2012_O_0001, 2012_I_0001, 2012_F_0001, 2012_C_0001, 2012_A_0001 g) De status van de documenten moet in de overzichtslijsten zichtbaar zijn. Bijvoorbeeld: Documenten die nog onvoltooid zijn met een rode/oranje arcering. Requirements voor Offertes: h) Kortingen op producten moeten gegeven kunnen worden over elk product apart, maar ook in één keer op een selectie producten. i) Hiervan mag geen kolom-kop zichtbaar zijn in het lijst-overzicht. Requirements voor Inkooporders: i) Inkooporders moeten open kunnen staan, totdat de producten geleverd zijn. j) Inkooporders moeten op 'onvoltooid' kunnen staan. k) In het overzicht moet duidelijk zichtbaar zijn of een inkooporder al voltooid is, en of deze nog open staat of niet. l) Bij buitenlandse crediteuren komt er geen BTW op de inkooporder. m) Er moeten automatische suggesties selecteerbaar zijn van producten waarvan de voorraad onder de minimale voorraad zit. Pagina 7 van 20

50 Optioneel Gewenst Gewenst n) Bestaande producten moeten gemakkelijk, vanuit een lijst van producten van deze leverancier, toe te voegen zijn aan een inkooporder. i) Deze lijst moet filterbaar/sorteerbaar zijn op de eigenschappen van de producten. o) Als een product wel besteld moet worden, maar deze nog niet voorkomt in de productendatabase, moet deze gemakkelijk toe te voegen zijn. p) Het zou handig zijn als de inkooporder eenvoudig vanuit het systeem naar de leverancier g d kan worden. Requirements voor Facturen: q) In het overzicht moet duidelijk zichtbaar zijn of een factuur nog open staat of niet. r) Facturen moeten zowel 'Inclusief-BTW' als 'Eclusief-BTW' te genereren zijn, voor respectievelijk bedrijven en particulieren. s) Kortingen op producten moeten gegeven kunnen worden over elk product apart, maar ook in één keer op een selectie producten. Hiervan mag geen kolom-kop zichtbaar zijn in het lijstoverzicht. t) Elke factuur heeft een uniek nummer en Relatie, welke niet te veranderen zijn. Het is heel belangrijk voor de belasting dat de relatie en factuur nummer van een factuur niet te veranderen zijn. u) Facturen moeten open kunnen staan, zolang deze nog niet betaald zijn. v) De inhoud van een factuur is altijd aan te passen, zelfs als deze al voltooid is. i) Op het moment dat een voltooide factuur aangepast moet worden, moet de gebruiker een waarschuwing krijgen. w) De volgende betalingsmogelijkheden moeten per factuur beschikbaar zijn: i) Betaald per bank, met een geselecteerd bankrekeningnummer. ii) Contant betaald. ) Bij het opstarten van het programma moet er een melding komen als er nog facturen al een aantal dagen op staan. i) Bij deze facturen moet een aanmaning gestuurd kunnen worden. Requirements voor Creditnota s y) Creditnota's kunnen, maar zijn niet verplicht gelinkt zijn aan een bestaande factuur. Requirements voor Aanmaningen z) Aanmaningen moeten per Relatie gegroepeerd worden. aa) Aanmaningen moeten in een drietal varianten gedefinieerd kunnen worden, elk met een verschillende toon. 4) Printen a) Het moet mogelijk zijn om (een lijst van) documenten, in een zelf gedefinieerde lay-out, met een standaard printer te printen. b) Er moeten etiketten geprint kunnen worden met een DynoLabelWriter. i) Labels voor kleding, welke per product, voor elke bestaande kledingsvariant, de eigenschappen van het kledingstuk bevatten. ii) Labels voor ballonnen, welke meestal alleen de kleur en het aantal stuks per verpakking bevatten. 5) Toegangsbeheer a) Bij het opstarten van het programma moet de gebruiker inloggen in het systeem, waarbij hij bepaalde rechten toegewezen krijgt. b) Schermen moeten zichtbaar zijn a.d.h.v. toegangsbeheer. i) Werkvloer-rechten geven recht tot: (1) Productoverzicht. ii) Magazijn-rechten geven recht tot: (1) Productoverzicht. (2) Product inscannen en uitscannen. Pagina 8 van 20

51 Gewenst Gewenst Gewenst Optioneel Optioneel Gewenst Gewenst Gewenst Optioneel Optioneel Optioneel Optioneel Gewenst Gewenst iii) Kantoor-rechten geven recht tot: (1) Productoverzicht. (2) Product inscannen en uitscannen. (3) Producten toevoegen. (4) Producten aanpassen. (5) Relatieoverzicht. (6) Documentoverzicht. (7) Programma instellingen wijzigen. iv) Admin-rechten geven recht tot: (1) Productoverzicht. (2) Product inscannen en uitscannen. (3) Producten toevoegen. (4) Producten aanpassen. (5) Relatieoverzicht. (6) Documentoverzicht. (7) Programma instellingen wijzigen. (8) Toegangsbeheer. c) Na een instelbaar aantal minuten van inactiviteit moet de gebruik opnieuw inloggen. i) Dit geldt niet als er ingelogd is met de magazijn rechten. d) De gebruikersnamen en wachtwoorden zijn gelinkt aan het toegangsbeheer van de Magento webshop Database. e) De gebruikersnamen en wachtwoorden moeten versleuteld opgeslagen worden. 6) Stabiliteit a) Het is handig om een logboek systeem te hebben bij het geval van crashes. b) De databases moeten reserve kopieën van zichzelf maken. i) Het is handig als dit ook handmatig gestart kan worden. ii) Voor disaster recovery moet data uit het systeem plaintet uitleesbaar zijn vanuit een backup. iii) Backups moeten teruggezet kunnen worden. 7) Webshop a) Op het moment dat er een nieuw product aangemaakt wordt, moet deze op de webshop gezet worden. b) Als een producteigenschap aangepast wordt, moet dit ook meteen in de webshop database aangepast worden. 8) Gebruiksvriendelijkheid a) Er moet een oplossing zijn voor als het programma geen verbinding kan maken met internet. b) De applicatie moet bij product- en voorraadbeheer geen zichtbare vertraging hebben. c) Het systeem moet draaien op de nu aanwezige Windows 7 computers. d) Het systeem moet communiceren met de huidige aanwezige webserver waar Magento op draait. e) Voor de boekhouder moeten de volgende lijsten geëporteerd kunnen worden: i) Een overzichtslijst van alle facturen van een bepaalde datum, tot een bepaalde datum. ii) Een overzichtslijst van alle facturen die tot moment van eporteren nog open staan. f) Het is handig om een Document lay-out manager te hebben, waarin op een visuele manier de lay-out van de verschillende documenten gemakkelijk aan te passen is. g) Het is handig om in te kunnen stellen, in welk zoekveld de cursor start bij een overzichtslijst. h) Het is handig om bij filtervelden voor numerieke waarden operators te kunnen gebruiken, zoals b.v. '<', '>', '<=' en '>='. i) Het is handig om kolombeheer te hebben, waarbij je in kan stellen welke kolommen in de overzichtslijsten zichtbaar zijn, en de volgorde waarin ze staan. j) De kolommen van de overzichten moeten vast gezet kunnen worden, zodat deze niet kunnen verdwijnen, als de tabel naar rechts gescrold wordt. k) Overzichtslijsten moeten zich sorteren op een eigenschap, als er bij de kolomtitel van deze eigenschap wordt gedrukt. Pagina 9 van 20

52 Optioneel Optioneel l) Het is handig om een help menu te tonen als er op F1 gedrukt wordt. m) Het is handig als er een overzicht is met alle producten waar op dit moment een staffel voor geldt. i) Klikken op het product zal naar de detail pagina van het product gaan. ii) De aanbiedingsprijs is de staffelprijs van de hoeveelheid van 1. 9) Voorraadbeheer a) Met de magazijnrechten moet het systeem een in- en uitscanmodus hebben. b) Barcodes moeten gescand kunnen worden en herkend door het systeem. c) Het product wordt dan aan een in- of uitscanlijst gezet op het scherm met beperkte productinformatie. i) Het aantal wordt standaard op 1 gezet. ii) Dit aantal moet handmatig veranderd kunnen worden. iii) Het zou handig zijn als producten gegroepeerd worden als er meerdere malen hetzelfde product wordt gescand. iv) Met een druk op de knop kunnen alle artikelen uit de lijst in of uit het hoofdmagazijn worden geboekt. d) Als een product niet bekend is in het systeem, moet de gebruiker hiervan een mededeling krijgen, en kan het niet worden ingescand, het product moet eerst op het kantoor worden ingevoerd Afbakening opdracht De opdracht omvat het totaal vervangen van het huidige KassaMatic systeem. Dit betekend dat we moeten voorzien in een systeem dat minstens voorziet in het beheer van producten, het beheer van relaties en het opstellen van documenten, zoals inkooporders en facturen. Als toegevoegde functionaliteit willen we voorraadbeheer voor toevoegen en de communicatie met de Magento webshop. Functionaliteiten die buiten de opdracht vallen, en niet terug zullen komen in het te bouwen systeem zullen hieronder in een overzicht weergegeven worden. Waar mogelijk zal in het systeem wel rekening worden gehouden met een uitbreiding. Ons system houdt de voorraad in de winkels zelf niet bij, alleen de voorraad in het hoofdmagazijn. heeft geen kassasysteem, en kan dus geen aankopen van klanten in de winkel verwerken. geeft geen overzicht van de dagelijkse omzet van de winkels. 1.7 Randvoorwaarden Het beoogde systeem moet gemaakt worden onder de volgende voorwaarden: 1. Uitsluiten dataverlies: Verlies van gegevens mag niet voorkomen, zowel niet bij migratie als daarna. 2. Windows-compatibel: De software moeten draaien op Windows cliënt computers met de bestaande hardware 3. Tijdslimiet: De opdracht moet uiterlijk vrijdag 6 juli afgerond zijn. Pagina 10 van 20

53 2 Plan van aanpak 2.1 Inleiding Het project bestaat voor ons uit drie fasen. Tijdens de eerste fase, de oriëntatiefase, proberen we een goed beeld te krijgen van de huidige situatie en de gewenste toekomstige situatie. We zullen dit zo specifiek mogelijk beschrijven in het oriëntatieverslag, zodat er een duidelijk beeld ontstaat bij alle betrokken partijen over de precieze inhoud van de opdracht. Vervolgens zullen we in de ontwerpfase het te bouwen systeem ontwerpen. Ten slotte zullen we het systeem daadwerkelijk implementeren in de implementatiefase. 2.2 Methodiek en Technieken Scrum Onze aanpak is gebaseerd op de Agile Programming (AP) variant Scrum 1 in combinatie met Test- Driven Development (TDD). Deze variant van AP kenmerkt zich door een korte feedback cyclus gerepresenteerd in een sprint. Aan het begin van iedere sprint wordt vastgesteld welke features er die sprint geïmplementeerd dienen te worden. Omdat wij niet enkel programmeren, hebben wij gekozen de definitie van een feature uit te breiden: wij bedoelen hierbij een te voltooien taak. Dit omvat dus ook het schrijven van unit-, integration- en acceptance-tests, of het configureren van een bepaalde module. Vanwege de korte ontwikkelcyclus (ca. 10 weken) hebben wij gekozen voor een sprint lengte van 1 week (1 tot 4 weken wordt aanbevolen). Een belangrijk voordeel van de Scrum methodiek is dat de opdrachtgever tijdens het ontwikkelen van het programma de mogelijkheid heeft om input te geven over zijn wensen voor het programma. Features worden geordend in een product backlog waar aan het begin van elke sprint features uit gekozen worden om te implementeren. Slechts eenmaal per sprint (vlak voor het begin van de volgende sprint) kunnen requirements veranderd worden en entries worden toegevoegd aan het product backlog. Verder wordt aan het begin van elke dag een korte (15 min. wordt aanbevolen) meeting gehouden over de hoogtepunten van gisteren en het werk voor vandaag Test Driven Development Test Driven Development (TDD) kenmerkt zich door het eerst schrijven van tests a.d.h.v. use-cases en daarna pas code te implementeren. Onderzoek wijst uit dat dit overbodige code bespaart, echter ten koste van meer test-code. De tests blijken echter nuttig voor stabielere software en het voorkomen van regressies. Om deze redenen hebben wij gekozen voor TDD. We zullen echter, in tegenstelling tot puur TDD, eerst een globaal ontwerp maken van ons design en interfaces en dit vervolgens het TDD principe implementeren Keuze: bestaand of eigen pakket? Na het opstellen van de requirements ontstonden er twijfels of het project gegarandeerd af te ronden was in 10 weken door 3 ontwikkelaars. Hierop is het idee geopperd om niet zelf volledig van de grond af software te ontwikkelen, maar een bestaand pakket te implementeren en uit te breiden om aan de wensen van de opdrachtgever te voldoen. 1 The Scrum Guide, door Ken Schwaber and Jeff Sutherland Pagina 11 van 20

54 Deze aanpak heeft diverse voordelen: Grotere kans van slagen: door voort te bouwen op een bestaande oplossing is er een grotere kans dat het project succesvol is. Verder is waarschijnlijk een groter deel van de software compleet/bruikbaar indien het project niet volledig afgerond kan worden. Minder bugs: Door gebruik te maken van een bestaand platform dat in de praktijk gebruikt wordt zijn meer bugs gevonden en opgelost. Onderhoudbaarheid: Het is makkelijker voor de opdrachtgever om iemand te vinden om een generiek pakket te onderhouden dan een maatwerk applicatie. Uitbreidbaarheid: bij uitbreiding kunnen delen van het framework (her)gebruikt worden. De begeleider van de TU Delft was het hier mee eens, omdat het wiel niet opnieuw uitgevonden hoeft te worden en er door het nemen van een bestaand pakket meer tijd overblijft voor implementatie en migratie. Voor het maken van een shortlist zijn de volgende criteria meegenomen: Client platform: Windows. Server platform: Windows of Linu. Database: Bij voorkeur MySQL (i.v.m. bestaande serverfaciliteiten). Taal: Nederlands of eenvoudig te vertalen. Fleibiliteit: Het pakket moet mogelijkheden hebben voor eigen aanpassingen/plugins, bijvoorbeeld voor de Magento koppeling. Stabiliteit: Het project moet een zekere volwassenheid hebben en bij voorkeur een goede documentatie en actieve community. Support: Kwaliteit van de documentatie en grootte/bruikbaarheid van de community. Licentie: Bij voorkeur open-source, anders low-cost. Gebruiksvriendelijkheid: Het pakket moet te begrijpen zijn voor medewerkers en een snelle UI hebben. Voldoen aan requirements: In hoeverre het pakket de requirements ondersteunt. Voldoen aan uitbreidbaarheid: In hoeverre het pakket mogelijke latere uitbreiding van het systeem ondersteund. Na het opstellen van een longlist ongeveer 50 ERP en CRM oplossingen, zijn deze vergeleken aan de hand van de net genoemde criteria met een shortlist als resultaat. Deze lijsten zijn uitgewerkt in respectievelijk Bijlage B: 'ERP / CRM Longlist' en Bijlage C: 'ERP / CRM Shortlist'. Opentaps 2 valt af doordat er enkel commerciële support is en door enkele andere nadelen. OFBiz 3 is erg groot en ingewikkeld, waarschijnlijk te groot voor deze toepassing. Verder zijn er twijfels of de Magento koppeling goed zou lukken en is het enkel hebben van een web UI geen voordeel. 2 Opentaps Documentation 3 Apache OFBiz Documentation Pagina 12 van 20

55 De keuze tussen JFire 4 en Adempiere 5 was lastiger. Uiteindelijk is er voor JFire gekozen. De volgende overwegingen speelden hierbij een rol: Database: Hier wint JFire, MySQL is al beschikbaar en het is onwenselijk om een tweede databasesysteem te gaan draaien. Taal: Hier wint Adempiere, maar een gedeeltelijk Engelse interface is te overzien. Gebruiksvriendelijkheid: Hier wint JFire overduidelijk. De interface is gebaseerd op Eclipse RCP en eenvoudig aan te passen, terwijl dat bij Adempiere nauwelijks mogelijk is. Support: Dit is de grootste risicofactor bij JFire. De community is vrij klein. De documentatie lijkt redelijk goed, maar dit is niet te garanderen. Adempiere heeft een goede documentatie en grote community. Uitbreidbaarheid: Hier wint JFire duidelijk 6 door het modulair design en de moderne (standaard) technieken. JFire heeft dus meer voordelen dan Adempiere, wat ons tot onze keuze voor JFire brengt. Het risico van een inadequate documentatie vinden we aanvaardbaar omdat JFire ons wel beter in staat stelt om een product op te leveren dat goed voldoet aan de wensen van de klant. In de risicofactoren die onder het volgende kopje omschreven zullen worden, wordt er gesproken over het risico dat JFire door de geringe ondersteuning een probleem kan worden, waardoor misschien toch een andere oplossing gekozen moet worden. Na een dag lang proberen een ontwikkelomgeving op te zetten met de JFire SDK, is ons dit niet gelukt. We hebben dit in het weekend nog even geprobeerd, wederom zonder succes. Dit heeft ons doen besluiten om toch over te stappen op Adempiere en hiermee een ontwikkelomgeving op te zetten. 2.3 Risicofactoren Bij het maken van de planning houden we rekening met de volgende risicofactoren: Beperkt pakket support: Bij de keuze van JFire kan het voorkomen dat we op een probleem stuiten dat we mogelijk niet zelf snel op kunnen lossen. Als de community niet actief is, zal een roep om hulp wel eens onbeantwoord kunnen blijven. Dit zou betekenen dat we een andere oplossing moeten vinden, hoogstwaarschijnlijk door te gaan kijken naar de 1-na beste oplossing in de shortlist. Migratieproblemen: Bij het overzetten van het oude systeem naar het nieuwe systeem zouden er problemen kunnen optreden doordat de data in het huidige systeem niet consistent of volledig is. We hebben al een ge-eporteerde versie van de huidige database, welke we al van tevoren kunnen controleren op inconsistentie, een zogenaamde early-scan. Hiermee zullen we last-minute problemen proberen te voorkomen. Hardware problemen bij vestigingen: Mogelijk moeten er bepaalde delen van de hardware gerepareerd of vervangen worden om het nieuwe systeem te laten draaien. Dit zal hoogstwaarschijnlijk niet het geval zijn, al kan het geen kwaad er rekening mee te houden. 4 JFire Wiki Documenation 5 Official Adempiere wiki 6 JFire vadoc Pagina 13 van 20

56 Bugs in gebruikte pakketten: Als er bugs in de door ons gebruikte pakketten blijken te zitten, zullen we ons moeten verdiepen in de code van de gebruikte pakketten om dit op te lossen. Dit kan mogelijk veel tijd kosten. 2.4 Planning Bij het maken van de planning houden we rekening met de eis dat de opdracht binnen 11 weken moet worden afgerond. Om beter voorbereid te zijn op eventuele tegenvallers, zullen we het op te leveren systeem zoals beschreven in hoofdstuk opdelen in twee delen. We zullen de hoogste prioriteit leggen op het maken van een systeem waarin ook de voorraad beheerd wordt. We hebben dan een systeem dat KassaMatic vervangt. Hierna zal gewerkt worden aan de koppeling met Magento. Op deze manier hebben we al vroeg in het project een systeem waar opdrachtgever profijt van heeft. De planning is in meer detail uitgewerkt in Bijlage A: Planning. Doordat we overgestapt zijn op Adempiere, betekend dit dat we vooral het systeem zullen moeten configuren. De koppeling met Magento zal wel zelf geschreven moeten worden. Dit zal niet heel veel tijd kosten, aangezien de Magento API 7 goed gedocumenteerd is. Verder is het nog niet duidelijk wat er precies wel en niet geïmplementeerd moet worden in het Adempiere framework, dus houden we hier tijd voor vrij. Verder wordt ook tijd vrijgehouden voor het verwerken van het SIG commentaar. 3 Projectinrichting 3.1 Inleiding Voor dit project zijn er een aantal betrokkenen en deze betrokkenen hebben elk een aantal verantwoordelijkheden voor dit project. Deze verantwoordelijkheden zullen hieronder zullen genoemd worden. Verder zullen we ingaan op de faciliteiten die we gebruiken tijdens dit project en de planning van de werkdagen. 3.2 Betrokkenen Om de beschreven opdracht goed uit te kunnen voeren is het nodig dat de opdrachtgever en de projectleden zich aan bepaalde regels houden: De opdrachtgever, Guido Bokstijn, heeft de volgende verantwoordelijkheden: Requirements goedkeurgen. Regelmatige feedback op de staat van het programma, in ieder geval iedere twee weken. Beantwoorden van vragen over de huidige staat van het systeem en over het te maken systeem. Aanwezigheid bij de eindpresentatie. Ook de projectleden hebben verantwoordelijkheden, namelijk: Aanwezigheid en actieve betrokkenheid bij de dagelijkse bijeenkomsten. Aanwezigheid bij de eindpresentatie. Nakomen van gemaakte afspraken m.b.t. planning. 7 Magento API Documentatie Pagina 14 van 20

57 Begeleiders informeren over de voortgang van het project. o Wekelijkse voortgangsrapportage per mail in de vorm van een ingevuld progressreport van Blackboard. o Tijdig op de hoogte stellen van problemen en wijzigingen in aanpak, planning, deliverables of requirements. o Tweewekelijkse voortgangsgesprekken met begeleider Koen Hindriks. Het opsturen van de code naar de Software Improvement Group voor 10 juni. Het opsturen van de code naar de Software Improvement Group minimaal 5 werkdagen voor de presentatie. Verantwoordelijkheden begeleider vanuit TU, Koen Hendriks: Advies geven tijdens het project. Houden van tweewekelijkse voortgangsgesprekken. Aanwezigheid bij de eindpresentatie. Eindbeoordeling geven. Verantwoordelijkheden Software Improvement Group: Uiterlijk 17 juni feedback geven op de code, per mail of mondeling. Voor de presentatie een beoordeling van de code geven en deze meedelen aan de projectgroep. 3.3 Faciliteiten De vestigingen van Bokstijn Feestartikelen bieden geen ruimte voor ons om het systeem in te ontwikkelen. We zullen ons daarom beroepen op de studieruimten die ons door de TU Delft worden aangeboden. 3.4 Dagplanning Zoals eerder beschreven beginnen we elke dag om 9:30 met een vergadering waarin de voortgang tussen de vorige vergadering en deze besproken wordt. Halverwege de dag wordt er een half uur geluncht tussen ongeveer 12:00 en 12:30. Werkdagen duren verder tot ongeveer 17:00. 4 Kwaliteitswaarborging 4.1 Inleiding De opdrachtgever heeft eisen gesteld aan het op te leveren product. In dit hoofdstuk geven we aan wat wij zullen doen om deze kwaliteit te waarborgen. De opdrachtgever kan de maatregelen die wij treffen gebruiken om feedback te geven, en daardoor bijdragen aan het waarborgen van de kwaliteit. 4.2 Documentatie Om tot een goed product te komen, zullen we tijdens dit project een aantal documenten produceren. Van deze documenten is een deel alleen voor intern gebruik. Allereerst hebben we dit oriëntatieverslag wat ook voor de begeleiders bestemd is. Pagina 15 van 20

58 Daarna zullen we een aantal (onder andere UML-) diagrammen maken. Deze zijn voor intern gebruik bestemd en zullen niet ter goedkeuring aan de opdrachtgever worden voorgelegd. Verder zal tijdens het ontwerp en de implementatie van het systeem documentatie worden bijgehouden voor stukken die bij onderhoud of uitbreiding relevant zijn. De code zal ook passende documentatie krijgen. Voor de begeleider vanuit de TU Delft zullen we een eindrapport maken, en voor de opdrachtgever een gebruikershandleiding voor het systeem. 4.3 Versiebeheer Aan het einde van iedere sprint zorgen we ervoor dat we een werkend programma hebben met een stukje nieuwe functionaliteit. Deze versies zullen gemarkeerd worden in de source control en de binaries zullen opgeslagen worden, zodat we altijd de beschikking hebben over een werkend product. We zijn op dit moment niet van plan na oplevering van het product nog nieuwere versies uit te brengen. 4.4 Evaluatie Tijdens de ontwikkeling zullen we regelmatig contact houden met de opdrachtgever om de voortgang van het systeem te bespreken. We sturen iedere week de voortgangsrapportage per mail, en zullen proberen om ten minste iedere twee weken feedback te krijgen van de opdrachtgever. Pagina 16 van 20

59 Bijlage A: Planning Week Start Voortgang en bezigheden Oriëntatie Ontwerp Implementatie Migratie Oriëntatieverslag Oriëntatieverslag - Oriëntatie op JFire - Systeem ontwerpen Systeem ontwerpen - Implementeren productbeheer - Implementeren relatiebeheer - Implementeren documentbeheer Implementeren productbeheer - Implementeren relatiebeheer - Implementeren documentbeheer - Implementeren voorraadbeheer Implementeren voorraadbeheer Implementeren van de koppeling met Magento Implementeren van de koppeling met Magento SIG code review code herzien a.d.h.v. SIG commentaar. - Implementeren van de koppeling met Magento - Overzetten van gegevens oude database Overzetten van gegevens oude database Acceptance testing SIG code review Omstreeks eindpresentatie - Eindverslag en presentatie Een tekstuele aanvulling aan de planning is te vinden in hoofdstuk 2.4 Planning. Pagina 17 van 20

60 Bijlage B: ERP / CRM Longlist Requirements Desktop client Windows client Database 8 Vertaling Licentie & Support Ontwikkeling 9 Adampiere + ~ + (GPL) (fork Compiere) Adaa + ~ (GPL+comm.) (fork Adempiere) Apache OFBiz ~ + (Apache) BlueERP Compiere ~ (GPL+comm.) Dolibarr ~ ERP5 + (GPL) + / Fedena FreedomERP _ FrontAccounting ~ + (WebERP fork) GNU Enterprise _ ~ HeliumV _ JFire + + ~ (GPL+comm.) + Kuali LedgerSMB (SQL-Ledger fork) Openbravo ~ OpenERP (AGPL+comm.) 10 Opentaps ~ ~ ~ (GPL+comm.) ~ Postbooks OSS _ ~ (CPAL) (C++) SQL-Ledger Tryton ~ + (GPLv3) + / (OpenERP fork) WebERP ~ Legenda: + Voldoet uitstekend Voldoet ~ Voldoet naar alle waarschijnlijkheid _ Voldoet waarschijnlijk niet Voldoet niet De volgende pakketten zijn afgevallen wegens het ontbreken van een gratis of goedkope versie: 24SevenOffice, A1 ERP, AIVA 9001, Acumatica ERP, Batchmaster ERP, CGram ERP, Clear Enterprise ERP, Comarch Suite, Epicor ERP, Eact Globe, LOG-NET, Microsoft Dynamics, OpenMFG, Openpro, Oracle Peoplesoft ERP, Oracle e-business Suite, Ple ERP, ProfitKey, QAD ERP, SAP Business Suite, SAP ERP, SSA Global ERP, Sage Accpac ERP, Taskhub, Unit4 ERP, WorkPLAN Enterprise : MySQL, ~: OSS/gratis databasesysteem (bijv. PostgreSQL, Firebird), : non-free databasesysteem (bijv. Oracle) 9 In tegenstelling tot de andere Business-oriented criteria wordt ontwikkeling wordt bekeken vanuit ons perspectief: Heeft de software mogelijkheid tot aanpassing (modulariteit of plugin-framework)? Is de taal OOP en bij voorkeur va, C# of PHP? Wat is de kwaliteit van de code? 10 Python 11 De + markering is omdat dit pakket een uitstekende code-opzet heeft. Door de gebruikte programmeertaal valt het echter af. Pagina 18 van 20

61 Bijlage C: ERP / CRM Shortlist JFire ADempiere 12 OFBiz Opentaps Developer Redhat Apache Client platform va, Web va (delen ook web) Web Web Server platform va va va va Database MySQL (JDO 13 ) PostgreSQL & Oracle Alle met JDBC driver MySQL e.a. Taal Engels & Duits. Te vertalen. Veel, maar geen Nederlands. Eenvoudig te vertalen. Een aantal beschikbaar. Goed te vertalen. Engels, Chinees & Frans. Onbekend of het te vertalen is. Fleibiliteit Zeer groot. Modulair en uitbreidbaar met OSGi 14 plug-ins. Klein. Two-tier met GUI en business logic verstrengeld Onbekend Zeer beperkt plugin systeem Stabiliteit Uit 2006 en gebaseerd op zeer veel grote en stabiele frameworks Zeer hoog. Het is een fork van een pakket uit Uit 2001 en van Apache sinds Er zijn veel (commerciële) pakketten op gebaseerd. Uit Verder geen informatie bekend. Support Volledige javadoc, redelijke highlevel Zeer grote en actieve community Actieve community Commerciële support documentatie. Kleine en inactieve community Licentie Open-source: LGPLv2 Open-source: GPLv2 Open-source: Apache license 2 Open-source: AGPLv1 Commercieel Gebruiksvriendelijkheid OK. UI aanpasbaar (gebaseerd op Eclipse RCP) OK. Ingewikkelde, web-gebaseerde UI. Gegenereerd uit non-triviale JSP s Overzichtelijke, maar starre (weinig aanpasbare) UI en workflow. Requirements Uitbreidbaarheid Modules voor alle requirements behalve Magento koppeling. Zwak productbeheer Bekend modulair framework met vele modules. Stock modules komen mondjesmaat uit, idem community contributes modules. Zeer compleet. Integratie met andere pakketen mogelijk via SOAP API. Alleen indien geïntegreerd. Uitgebreid pakket Zeer compleet. Integratie lijkt mogelijk via SOAP of eigen services. Alleen indien geïntegreerd. Wel zeer uitgebreid pakket Heeft al Magento integratie. Zwak in inventory en productenbeheer Alleen indien geïntegreerd. 12 ADempiere is een fork (2006) van Compiere. ADempiere is zelf enkele malen geforked of dient als basis voor andere paketten. Besloten is om ADempiere te overwegen boven Compiere, omdat de laatste niet meer actief ontwikkeld wordt (laatste release is uit maart 2009). ADempiere is overwogen in plaats van een van de forks omdat de documentatie bij ADempiere beter lijkt en de community vele malen groter is dan bij de forks/uitbreidingen. 13 va Data Objects Een Apache project voor persistent data in va omgevingen. Kan o.a. als basis SQL databases gebruiken. Bij JFire wordt enkel MySQL actief ondersteund Open Services Gateway initiative framework. Een systeem voor module- en servicebeheer voor va. Wordt onder andere gebruikt voor Eclipse - Pagina 19 van 20

62 De criteria voor deze shortlist zijn te vinden in Hoofdstuk 2.3.3: Keuze: bestaand of eigen pakket? Bijlage D: Literatuurlijst Datum Literatuurnaam Bron The Scrum Guide, door Ken Schwaber and Jeff Sutherland OpenTaps Apache OFBiz Documentation JFire Wiki Documenation Official Adempiere wiki JFire vadoc Magento API Documentatie Pagina 20 van 20

63 Ontwerpverslag IN3405 Bachelorproject - Bokstijn Feestartikelen Studenten: David Hoepelman n-willem van Velzen Bart van Vuuren Begeleiders: Guido Bokstijn Bokstijn Feestartikelen Koen Hindriks Technische Universiteit Delft, Faculteit EWI Coördinator Bachelor Project: Peter Nieuwenhuizen

64 Voorwoord Dit document dient als vervolg op het eerdere Oriëntatieverslag van het bachelorproject in opdracht van het bedrijf Bokstijn Feestartikelen. Het doel van dit document is om te tonen welke ontwerpbeslissingen wij maken en waarom. Wij hebben het ontwerp gesplitst in een gebruikstechnische kant en een hardwaretechnische kant. De gebruikstechnische kant wordt verder uitgewerkt via use-cases, die vervolgens worden omgezet in mock-ups voor de user interface. Bij de hardwaretechnische kant worden eerst de requirements aan hardware verzameld, welke vervolgens worden uitgewerkt in scenario s met verschillende kosten, baten en risico s. Dit document is opgesteld voor lezers met een goede technologische kennis. Er wordt jargon gebruikt uit ERP systemen, uit het netwerkvakgebied en domeinspecifiek jargon van Bokstijn Feestartikelen. Hierom is een begrippenlijst opgenomen als Blijlage A: Begrippenlijst. Wij hebben besloten om een samenvatting te maken in de vorm van een investeringsvoorstel. Deze bevat enkel onze conclusies en slechts een deel van de onderbouwing. Dit document is primair bedoeld als naslagwerk. Pagina 2 van 32

65 Inhoudsopgave Voorwoord Gebruikstechnisch ontwerp Inleiding Actoren Use cases... 4 Authenticatie... 4 Artikelbeheer... 5 Relatiebeheer... 5 Inkooporders... 6 Magazijnbeheer... 7 Voorraadbeheer... 7 Dyno Label Writer... 8 Toegangbeheer GUI ontwerp Softwaretechnisch ontwerp Services PostgreSQL replicatie Magento koppeling Hardwarematig ontwerp Serverhardware Internetverbinding filialen Den Haag Totaal-overzicht kosten en investeringen Bijlage A: Begrippenlijst Bijlage B: Netwerksituatie huidig Bijlage C: Netwerksituatie Scenario Bijlage D: Netwerksituatie Scenario Bijlage E: Netwerksituatie Scenario Bijlage F: Logisch Netwerk Scenario Bijlage G: Logisch netwerk scenario Bijlage H: Vergelijking internet- en telefonieverbinding Bijlage I: Vergelijking servers etern Bijlage J: Voorbeeld server intern Bijlage K: Aangehaalde Requirements Pagina 3 van 32

66 1 Gebruikstechnisch ontwerp 1.1 Inleiding In dit hoofdstuk zullen de opgestelde use cases uitgewerkt worden, waarna het gui ontwerp besproken wordt. In het GUI ontwerp zal teruggekoppeld worden naar de eerder beschreven use cases. 1.2 Actoren Er zijn vier verschillende actoren bij ons systeem. Per actor is als volgt vastgesteld welke mogelijkheden de actor heeft in het systeem: Medewerker winkel Medewerker magazijn Medewerker kantoor Beheerder systeem Productoverzicht Product in- en uitscannen Producten toevoegen Producten aanpassen Relatieoverzicht Documentoverzicht Programmainstellingen wijzigen Toegangsbeheer 1.3 Use cases Hieronder wordt met de actor bedoelt: De genoemde actor en de actoren die hier rechts van staan in het bovenstaande diagram. Authenticatie 1. Inloggen in het system Actor: Willekeurig type medewerker. Pre-condities: 1. Het programma toont het inlogscherm. Events: 1. De actor voert inloggegevens in. 2. Het systeem bevestigt dat de actor is ingelogd Alternatief: Het systeem geeft aan dat de inloggegevens onbekend zijn in het systeem en blijft in het inlogscherm. Post-condities: 1. De actor is ingelogd 2. De actor heeft toegang tot de mogelijkheden die horen bij zijn rol. Pagina 4 van 32

67 Artikelbeheer 2. Een artikel toevoegen aan het systeem Actor: Medewerker kantoor Pre-condities: 1. De actor is ingelogd. Events: 1. De actor navigeert naar het scherm waarin producten kunnen worden toegevoegd. 2. De actor kiest voor het toevoegen van een nieuw artikel. 3. De actor voert de gegevens van het artikel in. 4. Het systeem bevestigt dat het artikel is opgeslagen. Post-condities: 1. Het artikel is ingevoerd in het systeem. 3. Informatie van een artikel bekijken Actor: Medewerker winkel Pre-condities: 1. De actor is ingelogd. 2. Het betreffende artikel staat in het systeem. Events: 1. De actor navigeert naar het productoverzichtsscherm. 2. De actor zoekt het gewenste artikel op. 3. Het systeem toont informatie over het artikel Post-condities: - 4. Informatie van een artikel bewerken Actor: Medewerker kantoor Pre-condities: 1. De actor is ingelogd. 2. Het betreffende artikel staat in het systeem. Events: 1. De actor zoekt het betreffende artikel op in het systeem. 2. De actor wijzigt informatie over het artikel. 3. Het systeem bevestigt dat de informatie van het artikel gewijzigd is. Post-condities: 1. De informatie van het artikel is gewijzigd. Relatiebeheer 5. Een relatie toevoegen Actor: Medewerker kantoor Pre-condities: 1. De actor is ingelogd. Events: 1. De actor navigeert naar het scherm relatiebeheer. 2. De actor kiest voor het toevoegen van een nieuwe relatie. 3. De actor voert de gegevens van de relatie in. 4. Het systeem bevestigt dat de nieuwe relatie is opgeslagen in het systeem. Post-condities: 1. De nieuwe relatie is opgeslagen in het systeem. Pagina 5 van 32

68 6. Een relatie bewerken Actor: Medewerker kantoor Pre-condities: 1. De actor is ingelogd. Events: 1. De actor navigeert naar het scherm relatiebeheer. 2. De actor selecteert een bestaande relatie. 3. De actor past de eigenschappen van de relatie aan. 4. Het systeem bevestigt dat de eigenschappen van de relatie aangepast zijn. Post-condities: 1. De eigenschappen van de relatie zijn aangepast in het systeem. Inkooporders 7. Inkooporder aanmaken Actor: Medewerker kantoor Pre-condities: 1. De actor is ingelogd. 2. De leverancier van de inkooporder staat in het systeem. Events: 1. De actor navigeert naar inkooporders. 2. De actor maakt een nieuwe inkooporder aan. 3. De actor kiest de leverancier en voegt artikelen toe aan de order. 4. Het systeem bevestigt dat de order is opgeslagen. Post-condities: 1. De inkooporder is opgeslagen in het systeem. 8. Inkooporder printen Actor: Medewerker kantoor Pre-condities: 1. Er is een inkooporder gemaakt. Events: 1. Actor zoekt betreffende inkooporder op. 2. Actor kiest de optie printen. 3. Systeem drukt de inkooporder af op de standaardprinter van de computer. Post-condities: 1. De inkooporder is geprint. 9. Inkooporder naar leverancier mailen Actor: Medewerker kantoor Pre-condities: 1. Er is een inkooporder gemaakt. 2. Het adres van de leverancier staat in het systeem. Events: 1. Actor zoekt betreffende inkooporder op. 2. Actor kiest de optie mailen naar leverancier. 3. Systeem verzendt de inkooporder naar de leverancier. Post-condities: 1. De inkooporder is naar de leverancier g d. Pagina 6 van 32

69 Magazijnbeheer 10. Artikel inscannen in het magazijn Actor: Medewerker magazijn Pre-condities: 1. Het in te scannen artikel staat in het systeem. 2. Actor is ingelogd. Events: 1. Actor navigeert naar inscanscherm. 2. Actor scant het artikel met barcodescanner. 3. Het systeem toont het gescande artikel op het scherm. 4. Actor geeft aan hoeveel artikelen in gescand moeten worden. 5. Systeem bevestigt dat het artikel is ingevoerd. Post-condities: 1. De hoogte van de voorraad van het betreffende artikel is verhoogd met de ingevoerde hoeveelheid. 11. Artikel uitscannen uit het magazijn Actor: Medewerker magazijn Pre-condities: 1. Actor is ingelogd. 2. Het uit te scannen artikel staat in het systeem. Events: 1. Actor navigeert naar inscanscherm. 2. Actor scant het artikel met barcodescanner. 3. Het systeem toont het gescande artikel op het scherm. 4. Actor geeft aan hoeveel artikelen in gescand moeten worden. 5. Systeem bevestigt dat het artikel is ingevoerd. Post-condities: 1. De hoogte van de voorraad van het betreffende artikel is verhoogd met de ingevoerde hoeveelheid. Voorraadbeheer 12. Voorraad van artikel handmatig aanpassen Actor: Medewerker kantoor Pre-condities: 1. Actor is ingelogd. 2. Het betreffende artikel staat in het systeem. Events: 1. Actor navigeert naar artikelscherm. 2. Actor wijzigt de voorraad van het artikel. 3. Systeem bevestigt dat de voorraad gewijzigd is. Post-condities: 1. De hoogte van de voorraad van het betreffende artikel is gewijzigd naar de ingevoerde waarde. Pagina 7 van 32

70 13. Overzicht bekijken van artikelen met negatieve voorraad Actor: Medewerker kantoor Pre-condities: 1. Actor is ingelogd. Events: 1. Actor navigeert naar productoverzicht. 2. Actor zoekt op artikelen met negatieve voorraad. 3. Systeem toont artikelen met een negatieve voorraad. Post-condities: - Dyno Label Writer 14. Een kledinglabel printen Actor: Medewerker kantoor Pre-condities: 1. Actor is ingelogd. 2. Het betreffende kledingstuk staat in het systeem. Events: 1. Actor navigeert naar scherm om kledinglabels te printen. 2. Actor selecteert een artikel. 3. Actor geeft de opdracht op het kledinglabel te printen. 4. Systeem verzendt printopdracht naar Dyno Label Writer. Post-condities: 1. Er is een kledinglabel geprint. 15. Een ballonlabel printen Actor: Medewerker kantoor Pre-condities: 1. Actor is ingelogd. 2. De betreffende ballon is ingevoerd in het systeem. Events: 1. Actor navigeert naar scherm om ballonlabels te printen. 2. Actor geeft de opdracht om ballonlabel te printen. 3. Systeem verzendt printopdracht naar Dyno Label Writer Post-condities: 1. Er is een ballonlabel geprint. Toegangsbeheer 16. Een gebruiker toevoegen Actor: Beheerder systeem Pre-condities: 1. Actor is ingelogd. Events: 1. Actor navigeert naar toegangsbeheer. 2. Actor voert gegevens van nieuwe gebruiker in. 3. Actor geeft nieuwe gebruiker de benodigde rechten. 4. Systeem bevestigt dat de nieuwe gebruiker is aangemaakt. Post-condities: 1. De nieuwe gebruiker kan inloggen met eigen inloggegevens en heeft de benodigde rechten in het systeem. Pagina 8 van 32

71 17. Een gebruiker bewerken Actor: Beheerder systeem Pre-condities: 1. Actor is ingelogd. Events: 1. Actor navigeert naar toegangsbeheer. 2. Actor selecteert een bestaande gebruiker. 3. Actor past de eigenschappen van de gebruiker aan. 4. Systeem bevestigt dat de gebruiker de nieuwe eigenschappen heeft. Post-condities: 1. De eigenschappen van de gebruiker zijn gewijzigd in het systeem. 1.4 GUI ontwerp De getallen achter de schermnamen geven aan welke use cases met dit scherm uitgevoerd kunnen worden. 1. Inlogscherm (1) a. Inloggegevens moeten ingevuld kunnen worden. b. Het scherm moet aan kunnen geven dat inloggegevens incorrect zijn. 2. Producten overzicht scherm (2,13) a. Van elk bekend product moet een aantal eigenschappen in een tabel weergegeven worden. b. Er moet een nieuw product toegevoegd kunnen worden. c. Product moet verwijderd kunnen worden. d. Producten moeten gefilterd en gesorteerd kunnen worden op hun eigenschappen. i. Bijvoorbeeld een negatieve voorraad. Pagina 9 van 32

72 Pagina 10 van 32

73 3. Product detail scherm (3,4,12,14,15) a. Product eigenschappen moeten ingevuld en aangepast kunnen worden. i. Bijvoorbeeld de voorraad. b. Bij bepaalde producten (ballonnen en kledingstukken) moet er geprint kunnen worden naar een DynoLabel Writer. 4. Relatie overzicht scherm (5) a. Van elk bekend product moet een aantal eigenschappen in een tabel weergegeven worden. b. Er moet een nieuwe relatie toegevoegd kunnen worden. c. Er moet een relatie verwijderd kunnen worden. Pagina 11 van 32

74 5. Relatie detail scherm (6) a. Relatie eigenschappen moeten ingevuld en aangepast kunnen worden. 6. Inkooporder (PO: Purchase Order) overzicht scherm (7,8,9) a. Van elke bekende inkooporder moet een aantal eigenschappen in een tabel weergegeven worden. b. Er moet een nieuwe inkooporder aangemaakt kunnen worden. c. Inkooporders moeten verwijderd kunnen worden. 7. Inkooporder detail scherm (7,8,9) a. Er moet een leverancier gekozen kunnen worden voor de huidige inkooporder. b. Inkooporder eigenschappen moeten ingevuld en aangepast kunnen worden. c. Producten moeten toegevoegd aan en verwijderd van de inkooporder kunnen worden. d. De inkooporder moet naar een printer gestuurd kunnen worden om uitgeprint te worden. e. De inkooporder moet met een druk op de knop naar de leverancier gestuurd kunnen worden. Pagina 12 van 32

75 8. Factuur (SO: Sales Order) overzicht scherm (7,8,9) a. Van elke bekende factuur moeten een aantal eigenschappen in een tabel weergegeven worden. b. Er moet een nieuwe factuur aangemaakt kunnen worden. c. Facturen moeten verwijderd kunnen worden. 9. Factuur detail scherm (7,8,9) a. Er moet een leverancier gekozen kunnen worden voor de huidige factuur. b. Factuur eigenschappen moeten ingevuld en aangepast kunnen worden. c. Producten moeten toegevoegd aan en verwijderd van de factuur kunnen worden. d. De factuur moet naar een printer gestuurd kunnen worden om uitgeprint te worden. Pagina 13 van 32

76 10. Magazijn beheer scherm (10,11) a. Er moet geselecteerd kunnen worden of er voorraad bij- of afgescand moet worden. b. Er moet aangegeven kunnen worden met hoeveel artikelen de voorraad aangepast moet worden. 11. Toegangsbeheer scherm (16,17) a. Er moet een selectie kunnen worden gemaakt uit de bestaande gebruikers en hier moeten rechten aan toegekend kunnen worden. b. Er moeten nieuwe gebruikers gedefinieerd kunnen worden. Pagina 14 van 32

77 Pagina 15 van 32