1 Ontwikkelen dossierbeheersysteem in CRM 2011 Project aangeboden door Serbruyns Matthias voor het behalen van de graad van Bachelor in de New Media a...
Project aangeboden door Serbruyns Matthias voor het behalen van de graad van Bachelor in de New Media and Communication Technology Academiejaar 2012-2013 Stageplaats : Digipolis Gent Stagementor : Piet De Ceuleners Stagebegeleider : Wouter Gevaert
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Woord vooraf Mijn naam is Matthias Serbruyns. Na het behalen van mijn middelbare diploma BoekhoudenInformatica in Visitatie Mariakerke (Gent) besloot ik om New Multimedia & Communication Technology te volgen aan de Hogeschool West-Vlaanderen te Kortrijk. Mijn interesses in alles wat zich in de ICT-wereld afspeelt heeft deze keuze ook versterkt waardoor ik zeer gemotiveerd was. Nu zit ik in de stageperiode en in de laatste fase voor het behalen van een bachelorsdiploma. Tijdens de stage leert de student de verworven kennis te gebruiken in de echte wereld. Niet alleen technisch maar ook methodiek. Het is toch anders werken voor een echt bedrijf, waar een fout gevolgen kan hebben op grotere schaal, tegen over een project voor school waar de gevolgen veel kleiner zijn. Ik heb mijn stage gelopen bij Digipolis gelegen in Gent. Mijn taak was daar om een nieuw dossierbeheersysteem te ontwikkelen voor de Juridische Dienst van de stad Gent. Dit systeem werd ontwikkeld in een Microsoft Dynamics CRM 2011 omgeving. Deze bachelorproef is ook in het kader van mijn stage geschreven. De bedoeling van dit document is om mijn opgedane kennis tijdens mijn stage over Microsoft Dynamics CRM 2011 te delen met geïnteresseerde gebruikers van Microsoft Dynamics CRM 2011. Via dit document wil ik mijn problemen en vooral oplossingen delen die ik heb ondervonden bij het ontwikkelen in een Microsoft Dynamics CRM 2011 omgeving. Ook wil ik de Microsoft Dynamics CRM 2011 omgeving toelichten en het systeem dat ik ontwikkeld heb stap voor stap beschrijven, van analysefase tot eindproduct. Ik wil hier ook even de tijd nemen om Digipolis en mijn stagementor Piet De Ceuleners bedanken voor de opportuniteit die zij mij hebben aangeboden. Dankzij hen heb ik de kans gekregen om te proeven van het echte bedrijfsleven en heb ik mijn kennis kunnen verruimen door het leren van nieuwe technologieën. Bedankt ook aan de Hogeschool West-Vlaanderen voor deze kans en ook bedankt ook aan mijn stagebegeleider Wouter Gevaert, docent aan de Hogeschool West-Vlaanderen. Hij begeleidde mij gedurende de hele periode van mijn stage en controleerde of alles naar behoren verliep. Als laatste wil ik mijn ouders, familie en vrienden bedanken voor de vele steun gedurende mijn opleiding.
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Samenvatting In deze bachelorproef documenteer ik de uitgebreid de verschillende processen en stadia die het project rond de ontwikkeling van een nieuw dossierbeheersysteem voor de Juridische Dienst hebben doorlopen. Deze scriptie gaat dieper in op het ontwikkelen van een Microsoft CRM 2011 systeem en het ontwikkelen van extra functionaliteiten voor CRM 2011 door middel van Javascript, C# plug-ins en web resources. Deze scriptie is opgedeeld op basis van de verschillende stadia. In het eerste deel wordt er meer verteld over het onderzoek dat er gebeurd is om een nieuw dossierbeheersysteem tot stand te brengen. Via een uitgebreide functionele analyse creëren we duidelijk beeld van de probleemstelling, de noden, de vereisten en de wensen. De processen die een dossier doorloopt worden beschreven en het datamodel wordt besproken. Ook wordt aangetoond dat het beschrijven van “use cases” heel wat tijd wordt bespaard tijdens de ontwikkeling van het project. Uiteindelijk wordt ook de keuze van de gebruikte technologie toegelicht als ook Vesta, de nieuwe centrale adressendatabank van Digipolis gebaseerd op CRM. In het tweede deel van de scriptie leert u alles over de ontwikkeling van het project. Er wordt uitgelegd hoe te beginnen aan de ontwikkeling in een CRM-omgeving. Tevens wordt ook getoond hoe het CRM-systeem geconfigureerd werd, welke entiteiten er nodig zijn geweest, hoe men views kan aanpassen, etc. Vervolgens wordt er ook dieper ingegaan op de gebruikte code voor de extra functionaliteiten en automatisaties. Deze gaan over het aanpassen van formulieren via Javascript tot het schrijven van plug-ins in C#. Ook de integratie met Vesta komt uitgebreid aanbod. Het Silverlight project voor de Vesta integratie wordt in detail toegelicht, van design tot gebruikte klassen tot code. Er wordt ook duidelijkheid geschept over de gedachtegang bij de ontwikkeling van bepaalde onderdelen. In het laatste onderdeel leert u hoe het nieuwe systeem in de praktijk zal gebruikt worden. Ook de conclusie over het project en de inhoud van deze scriptie. Als afsluiter geef ik kan u mijn persoonlijke mening over de stage lezen.
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Verklarende woordenlijst
Customer Relation Management
Een Customer Relation management is een werkwijze en technologie waarbij het optimaliseren van alle contacten met de klant centraal staat. Via dit systeem kunnen we contactgegevens verzamelen en combineren. We kunnen ook alle geschiedenis bijhouden van een contact. bv. Microsoft Dynamics CRM 2011
Document Management Systeem
Een DMS is een systeem dat gebruikt wordt voor het opslaan en beheren van documenten. Ook de metadata van een document wordt hier opgeslagen zodat er op deze data kan gezocht worden. bv. SharePoint, Alfresco
Key User
Een key user is iemand die technisch onderlegd is en verstand heeft van de verschillende systemen. Het is een collega op een bepaalde dienst waar andere collega’s terecht kunnen bij problemen.
Metadata
Zijn gegevens die karakteristieken beschrijven van bepaalde gegevens. Het is eigenlijk data over data. De meta data van een document kunnen bijvoorbeeld zijn de auteur, het type document, datum creatie, etc.
Mockup/wireframe
Een mockup is een tijdens de ontwerp- of productiefase op schaal of op ware grootte gemaakt model van een ontwerp of product. In de software-industrie komt het begrip tevens voor om vroeg in het ontwikkelingsproces het software-ontwerp op het niveau van gebruikersinterface te testen.
Optionset
Een type veld in CRM dat bestaat uit een lijst met keuzemogelijkheden. Een Two optionset bestaat uit slechts 2 mogelijkheden
Plug-in
Een plug-in of invoegtoepassing is een extra aanvulling voor een bestaande toepassing. Plug-ins worden vaak gemaakt om een bepaalde toepassing meer functionaliteiten te bezorgen of uit te breiden. Een plug-in heeft altijd de basistoepassing nodig waarvoor het gemaakt is en kan dus niet alleen draaien.
RichTextBox
Een RichTextBox is een term uit de programmeertaal. Het is een tekstveld waar er een grote hoeveelheid tekst kan ingevuld worden. Deze tekst kan ook opgemaakt worden (bv. vet, onderlijnd, cursief, …).
Silverlight
Microsoft Silverlight is een ontwikkelingsplatform voor het ontwerpen van complexe grafische interfaces in webbrowsers.
SQL Server
Microsoft SQL Server is een databasebeheersysteem ontwikkeld door Microsoft. Het ondersteunt SQL, de meest gebruikte databasetaal. Het wordt gebruikt door verschillende organisaties, zowel kleine als grote.
Query
Een query is een tekenreeks die een opdracht bevat die aan een database wordt gegeven om een bepaalde actie uit te voeren, en die ook potentieel gegevens terug geeft.
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Afkortingen
CRAB
Centraal Referentieadressenbestand
CRM
Customer Relation Management
DMS
Document Management system
GRAB
Gemeentelijk Referentie Adressen Bestand
SAP
Duits software bedrijf: Systemen, Applicaties en Producten in gegevensverwerking
SQL
Structured Query Language
UML
Unified Modeling Language
WinLbv
Lokaalbevolkingsbestand in Windows omgeving
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Inleiding
Ik heb mijn stage gelopen bij Digipolis Gent. Digipolis heeft ook een vestiging in Antwerpen. Digipolis is een deskundige ICT-partner die totaaloplossingen biedt voor de verschillende diensten van de steden en OCMW’s van Antwerpen en Gent. Digipolis is geen gewoon bedrijf, zij werken niet met andere klanten, maar enkel voor de stadsdiensten. Digipolis wordt gezien als een soort verlengstuk van de stad en OCMW met bevoegdheid op het vlak van ICT. Digipolis Gent neemt dus alle ICT-gerelateerde zaken van de stad Gent voor zijn rekening. Zij hebben consulenten, adviseurs en ontwikkelaars die actief mee zoeken naar de gepaste ICToplossingen en anticiperen op de behoeften van haar partners. De totaaloplossingen die zij aanreiken omvatten de ontwikkeling van software, implementatie van hardware, netwerken of telefonie-infrastructuur, het ter beschikking stellen van ICT-competenties, begeleiding van de eindgebruiker, enz. Bij het kiezen van de stage heb ik rekening gehouden met 2 belangrijke factoren. Als eerste waren er mijn interesses, wat eigenlijk van zelfsprekend is. Ik zocht iets waar ik vooral kon ontwikkelen in een Microsoft omgeving. Ook het bedrijf zelf sprak mij aan. Een gevarieerd team met zowel jonge mensen als mensen met iets meer ervaring. Ik had ook een zeer positief gesprek met Piet De Ceuleners (mijn stagebegeleider). Ook de bereikbaarheid, wat ons bij factor 2 brengt, was perfect. De stageplaats ligt amper op 5 minuten fietsen van mijn thuis en is zeer vlot bereikbaar. De bedoeling van het stageproject was om een dossierbeheersysteem te maken voor de Juridische Dienst van de stad Gent. Zij hadden hier al langer om gevraagd omdat hun huidige systeem te sterk verouderd is en er zowel technische als functionele problemen waren.
1.1
Het project: dossierbeheersysteem voor Juridische Dienst
Het project waar ik gedurende die 3 maanden aan gewerkt heb was in opdracht voor de Juridische Dienst van de Stad Gent. Om hun dossiers te beheren werken ze met een MS-Access applicatie die niet meer voldoet aan de technische en functionele vereisten. Oorspronkelijk was het de bedoeling om een dossierbeheersysteem te maken via een .NETapplicatie met een achterliggende SQL-database. Om de documenten bij te houden zouden we dan gebruik maken van het DMS-systeem Alfresco. Uiteindelijk zijn we van dit idee afgestapt en hebben we besloten om voor een Microsoft Dynamics CRM 2011 systeem te kiezen in combinatie met SharePoint 2010 (voor de opslag van documenten). De reden waarom we zijn overgestapt naar CRM 2011 omdat ze bij Digipolis zoveel mogelijk uniformiteit willen. Ze willen zoveel mogelijk alle applicaties laten ontwikkelen binnen een zelfde omgeving zodat alle applicatie dezelfde look and feel gebruiken. Eerst stond ik er een beetje weigerachtig tegen over omdat ik geen enkele ervaring had met Microsoft Dynamics CRM 2011. Maar eens ik de voordelen er van in zag was ik onmiddellijk gemotiveerd om er aan te beginnen. Het is altijd aangenaam om nieuwe technologieën te leren en uw kennis te verruimen. Ik volgde tutorials en online opleidingen om de basis en structuur van CRM 2011 en wat het juist inhoud. In latere stadia leerde ik hoe te ontwikkelen in een CRM 2011 omgeving. Het stageproject verliep in verschillende fases. De eerste weken waren vooral analyse-en designfases. Hierna volgde de effectieve ontwikkeling om te eindigen met testen en optimalisatie.
7
Matthias Serbruyns
2 2.1
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Onderzoek Functionele analyse
Elk project begint met een goede voorbereiding. En dit was hier niet anders. Je kan niet aan een project beginnen vooraleer het nodige onderzoek is gebeurd. Hoe beter alles wordt voorbereid in de analyse- en designfase hoe minder werk er moet gebeuren tijdens de ontwikkelingsfase. Het project rond een nieuw dossierbeheersysteem voor de Juridische Dienst lag al een tijdje op de stapel van de te klaren projecten. Er was reeds voor mijn aantrede bij Digipolis al een analyse gebeurd door een externe medewerker rond het project. Mijn eerste taak bestond er dan ook uit op het al reeds bestaande analyse document te bestuderen. De bedoeling hiervan was om zo een totaalbeeld te krijgen van de huidige stand van zaken rond het project. Wat is het doel? Wat zijn de problemen? Waar willen we naartoe? Het zijn allemaal zaken die mij meer inzicht gaven over de doelstelling van het project en de schaal er van.
2.1.1 Situatie schets De Juridische Dienst werkte met een verouderd systeem genaamd Pro Deo om hun dossiers op te volgen die ze binnen krijgen. Het Pro Deo systeem is gebaseerd op MS-Access en heeft belangrijke nadelen zowel technisch als functioneel. Functionele problemen zijn bijvoorbeeld de rapporteringsmogelijkheden die ondermaats zijn. Hieraan gekoppeld zijn ook de verschillende zoekfuncties niet optimaal en al helemaal niet gebruiksvriendelijk. Een technisch probleem is bijvoorbeeld dat het niet mogelijk is om met verschillende personen tegelijkertijd dossiers aan te passen. Ook het financiële venster van Pro Deo laat de wensen over. Er moet een duidelijker overzicht komen tussen de inkomsten en uitgaven. Ook moet het mogelijk zijn om hierover te rapporteren en te exporteren naar bijvoorbeeld een Excel-document. In de toekomst zou er ook een connectie moeten komen met SAP. De doelstelling van het project zijn:
doorlooptijd van een dossier verminderen; betere rapportering (+documentgeneratie) en zoekmogelijkheden; beter financieel overzicht en zoekmogelijkheden op financiële gegevens; link met Vesta (centraal adressenbestand); migratie Pro Deo gegevens; documenten kunnen toevoegen aan dossier.
Vesta is het nieuwe centrale adressenbestand ontwikkeld door Digipolis. Voor meer informatie verwijs ik hier graag voor naar hoofdstuk 2.4. Het systeem zal gebruikt worden door een 30-tal gebruikers. Deze bestaan uit 5 administratieve medewerkers en de overige zijn voor consultatie. Er worden ongeveer 3.000 dossiers per jaar aangemaakt.
2.1.2 Oorspronkelijke toestand Het oorspronkelijke systeem Pro Deo is een MS-Access toepassing. Via Access formulieren en achterliggende VBA-code kunnen er dossiers worden toegevoegd, opgezocht, bewerkt, enz.
8
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Fig. 1: Pro Deo
In de bovenstaande afbeelding kan u zien dat naast het formulier zich de Acces databank bevindt waar alle gegevens worden opgeslagen. Via het formulier zijn deze gegevens toegankelijker en kunnen ze bewerkt of opgezocht worden. Even kort de belangrijkste features bespreken. Eerst is er, vanzelfsprekend, de mogelijkheid om een nieuw dossier aan te maken. Daarvoor klikken we op de knop nieuw dossier.
Fig. 2: Pro Deo nieuw dossier
Zoals u kunt zien oogt dit niet aangenaam en gebruiksvriendelijk. Het is overduidelijk dat er een nieuw, modern en vlotter systeem moest komen. Dit onderdeel werkt wel naar behoren, enkel het vinden van bestaande diensten, partijen of advocaten is niet overzichtelijk. 9
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Op het hoofdscherm vinden we aan de rechterkant het raadpleeg gedeelte. Hier kunnen we zoeken naar bepaalde dossiers. Het zoekgedeelte is helemaal niet optimaal. We kunnen telkens slechts zoeken op 1 filter (bv. enkel zoeken op volgnummer). Er zijn een paar zoekfuncties waar we op meerdere filters kunnen zoeken maar deze zijn ook beperkt in functionaliteit. Het zou moeten mogelijk zijn om zelf een aantal parameters in te geven waarop men moet zoeken. De financiële gegevens worden ook bijgehouden. Er zijn inkomsten en uitgaven. Het financiële overzicht werkt in 2 richtingen:
per dossier: alle financiële verrichtingen per dossier; per advocaat.
Fig. 3: Pro Deo financiële overzicht
Het datamodel (bijlage x) bestaat uit volgende tabellen: Tabel
Omschrijving
tblDossier
Tabel waar de dossiergegevens worden bijgehouden. Kolommen zoals nummer, datums, onderwerp, samenvatting, dossierbeheerder,…
tblPersoneel
Tabel waar personeelsleden van de Juridische Dienst inzitten. Dit zijn dan bijvoorbeeld de registrators (administratie) en de dossierbeheerders (juristen)
tblDienst
Tabel waar diensten van de stad Gent worden opgeslagen.
tblBetrokken
De betrokkenen (derden) bij een dossier staan in deze tabel en zijn gekoppeld aan de tabel tblDossier.
tblAdvocaat
Deze naam is niet toepasselijk. Er zitten niet alleen advocaten in maar ook andere personen (betrokkenen).
tblStraten
Alle straten van Gent
tblGeld
Inkomsten en uitgaven worden hier in opgeslagen
Tabel 1: Pro Deo Tabellen
2.1.3 Processen Wat is het nut van het in kaart brengen van de processen? Wel, het is een goede evaluatiemethode om te zien hoe efficiënt iets is. Hoe komt een product of dienst tot stand en welke personen en 10
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
apparatuur zijn er nodig om dit doel zo efficiënte mogelijk te bereiken. Een procesmodel is een verzameling van methoden en technieken die gebruikt zullen worden. Er zijn verschillende onderzoeken gedaan naar het nut van het beschrijven van processen en daaruit blijkt dat er enkel maar voordelen zijn:
verbetering van de kwaliteit; afname vervelende taken door automatisering; meer efficiëntere stappen in het proces; hogere productiviteit; tijdswinst.
Ook voor ons systeem is er een procesmodel opgesteld. Het aantal processen dat een dossier doorloopt is niet zo uitgebreid. Via het gratis programma Bizagi Process Modeler kon ik eenvoudig een procesmodel opstellen. Dit procesmodel werd opgesteld toen er nog van werd uitgegaan dat er ging ontwikkeld worden in een .NET-applicatie. Uiteindelijk werd er voor een gekozen om CRM 2011 systeem te ontwikkelen. Hierdoor zijn sommige stappen in het proces niet meer 100% van toepassing. Ons dossiersysteem bestaat eigenlijk uit 3 grote processen.
opstart van een dossier; inkomsten; uitgaven.
Fig. 4: proces opstarten dossier 1
Zoals bij elk proces is er hier ook een trigger die er voor zorgt dat het proces van start gaat. In ons geval is dit het binnenkomen van een brief, email, telefoon en dergelijke, afkomstig van bv. de politie, financiële dienst, enz. Na het ontvangen van de trigger kan er een nieuw dossier worden opgemaakt. Dit gebeurt door administratieve medewerkers van de Juridische Dienst. Zij zijn dus ook de registrators van de dossiers en zullen ook het meeste gebruik maken van het systeem. Als er besloten wordt om een nieuw dossier aan te maken, dan wordt er een formulier geopend in een nieuw venster of tabblad. In dit formulier dat ze te zien krijgen moeten er een aantal velden 11
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
verplicht worden ingevuld. Eerst moet er een type worden gekozen. Er kunnen2 types worden gekozen uit een lijst of check box: A (advies) of C (contentieux / betwist). Vervolgens worden de gegevens over de aanleiding ingevuld, de datum en de soort. De aanleiding is het document dat ze binnengekregen hebben dat het proces heeft getriggerd. Aanleidingen zijn bijvoorbeeld een email, fax, telefoon, enz. Hierna wordt er een onderwerp gekozen waarover het dossier gaat. Een onderwerp heeft ook een subonderwerp. Het subonderwerp is gebaseerd op het hoofdonderwerp en de lijst met subonderwerpen zal dan ook aangepast worden bij het selecteren van een hoofdonderwerp. De onderwerpen worden uit een database gehaald. Het is ook verplicht om een samenvatting te geven betreffende het dossier. Hiervoor is een RichTextBox voorzien. Als laatste verplichte stap moet het dossier toegewezen worden aan een dossierbeheerder. De dossierbeheerder of juristen zitten in een database opgeslagen. Via een lijst kan er een dossierbeheerder geselecteerd worden waarna de gegevens worden ingevuld. Een dossier kan nu worden opgeslagen.
Fig. 5: proces opstarten dossier 2
Als een dossier is opgeslagen kunnen er optionele gegevens aan worden toegevoegd. Er kunnen aan een dossier verschillende verzoekers, partijen, locaties en diensten worden aan toegevoegd. Al deze gegevens worden via een zelfde manier opgehaald uit het centrale adressenbestand Vesta en opgeslagen. Via een bepaalde actie of knop wordt er besloten om een van deze gegevens toe te voegen. Er wordt een nieuw formulier geopend waar de gebruiker verschillende parameters kan invullen waarop men wil zoeken in Vesta. Als de persoon gevonden is in Vesta, dan halen we deze gegevens op en steken we ze in ons systeem. De velden (zoals naam, voornaam, adres, …) worden automatisch ingevuld. Dit alles gebeurt via de web service van Vesta.
12
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Fig. 6: proces opstarten dossier 3
Als een dossier wordt opgeslagen gaat het systeem de gegevens wegschrijven naar de achterliggende database. Vervolgens was het ons idee om het systeem een bericht of notificatie te sturen naar de dossierbeheerder om hem/haar te verwittigen dat er een dossier aan hem/haar is toegewezen. Maar na gesprekken met de mensen den de Juridische Dienst waren ze daar toch niet zo enthousiast over. Ze werden namelijk al overspoeld door binnenkomende e-mails en vonden het niet nodig om nog meer mails te krijgen. Ook is het vaak zo dat de dossiers gewoon via papier aan elkaar worden doorgegeven. Een andere optie die ze wel zagen zitten was om bijvoorbeeld in het startscherm van de applicatie enkel de dossiers te zien die aan hen zijn toegewezen. Het proces inkomsten geeft weer hoe de financiële gegevens worden ingevuld en worden bijgehouden in het systeem.
Fig. 7: proces inkomsten 1
13
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Ook hier is er weer een trigger die ervoor zorgt dat het proces van start gaat. De trigger is ditmaal dat er een lijst met rekeninguittreksels ontvangen word van de dienst financiën. De mensen van de Juridische Dienst analyseren deze lijst en zoeken via een parameter, meestal een dossiernummer, in de mededeling van het uittreksel het dossier op in het systeem. Er zijn 2 mogelijkheden om te zoeken op een dossier. Er is een snelzoekfunctie waar er 1 parameter wordt ingevuld en op alles wordt gezocht. Of er is ook een geavanceerde zoekfunctie waar verschillende velden kunnen ingevuld worden om uitgebreid te zoeken op meerdere parameters. Het resultaat van de zoekfuncties zijn bij alle 2 een lijst met dossiers waar we dan een dossier kunnen selecteren en openen.
Fig. 8: proces inkomsten 2
Eens het dossier gevonden en geopend is kunnen we het financiële formulier openen. In het financiële formulier moeten er een aantal velden worden ingevuld. Het bedrag van het rekeninguittreksel kan niet automatisch berekend worden omdat dit voor elk dossier anders is en word dus handmatig uitgesplitst. De uitgesplitste bedragen worden hierna ingevuld in de overeenkomstige velden. De financiële gegevens worden vervolgens door het systeem opgeslagen. Er wordt een Excelbestand gegenereerd op basis van een sjabloon dat dan opgeslagen word op een DMS-systeem.
Fig. 9: proces inkomsten 3
14
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Matthias Serbruyns
2.1.4 Actoren Wie gaat er allemaal gebruik maken of gaat er in contact komen met het nieuwe systeem? Er zijn verschillende personen van verschillende diensten die in contact zullen komen met het systeem. Elk van deze personen behoort tot een groep die een rol zal hebben. Die groepen hebben ook verschillende rechten in de applicatie. Eerst zijn er de administratieve medewerkers van de Juridische Dienst. Zij doen alle administratie van de dossiers die binnenkomen. Zij registreren de nieuwe dossiers en sluiten ze ook af. Zij zullen het meest gebruik maken van het systeem. Zij hebben de meeste rechten. De dossierbeheerders of juristen van de Juridische Dienst beheren dossiers die aan hen zijn toegewezen. Zij hebben ook veel rechten. Zij moeten dossiers kunnen opvragen en kunnen bewerken. Zij kunnen geen dossiers aanmaken. De contactpersoon van Financiën helpt mee met het financiële gedeelte van het systeem. Ze helpen met het uitsplitsen van de bedragen en ingeven van inkomsten en uitgaven. Het management waaronder bv. de directeur moet dossiers kunnen bekijken en overzichten kunnen opvragen van de financiële gegevens. Deze groep moet niets kunnen aanpassen of bewerken. Als laatste is er de key users. Dit zijn de personen die een technisch ondersteunende functie zoals de ICT contactpersoon bij de Juridische Dienst. Die kan bijvoorbeeld personeelsleden zoals dossierbeheerders toevoegen of bewerken, sjablonen toevoegen of bewerken, … Aanmaken Dossier
Bekijken Dossier
Bewerken Dossier
Afsluiten dossier
X
X
X
X
Dossierbeheerder
X
X
X
Contactpersoon FIN
X
Management
X
Administratie
Key user
X
X
X
Instellingen + achterliggende gegevens
X
Tabel 2: Actoren rechten
2.1.5 Use Cases Use cases zijn een beschrijving van een gedrag van een bepaald systeem op een bepaalde actie. De use case beschrijft wie met het betreffende systeem wat kan doen. Deze techniek wordt ook gebruikt voor de bepaling van de requirements van het gedrag van een bepaald systeem. Een use case beschrijft een systeem vanuit het gebruikersperspectief. Het beschrijft de actor en het systeem als een opeenvolging van eenvoudige stappen. Elke use case is een complete serie van events, beschreven vanuit het standpunt van de actor. Ook beschrijft elke use case van hoe een doel of een taak kan worden bereikt. Voor het nieuwe systeem zijn er hier ook een aantal use cases opgesteld.
15
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Matthias Serbruyns
A Use case 1: registratie nieuw dossier De eerste use case is voor het aanmaken/registreren van een nieuw dossier. Deze actie kan enkel worden uitgevoerd door een administratieve medewerker of een key user. Naam
Registratie nieuw dossier
Samenvatting
De registratie van een nieuw juridisch dossier in de applicatie
Actoren
Administratie + key user De gebruiker kan een nieuw dossier aanmaken. Er kan ook een voorlopig dossier worden aangemaakt. Dit is nodig als bijvoorbeeld niet alle elementen gekend zijn maar er toch al een dossiernummer nodig is. Dit wordt dan in de status vermeld als voorlopig. Volgende velden dienen verplicht ingevuld te worden:
type: A/C; aanleiding: brief, telefoon, fax, …; datum Feit; datum Aanleiding; hoofdonderwerp; subonderwerp; samenvatting.
De samenvatting moet een RichTextBox veld zijn waarbij de gebruiker kan werken met bold, italic, lijnspaties en dergelijke.
Beschrijving
De gebruiker dient ook verplicht een dossierbeheerder kiezen. Hiervoor kan de gebruiker kiezen uit een drop down lijstje met namen en voornamen van alle dossierbeheerders in status actief. De gebruiker kiest 1 dossierbeheerder. Het systeem zal automatisch de velden ‘naam beheerder’, ‘initialen’, ‘telefoon’ en ‘email’ invullen. De gebruiker kan optioneel ook een verzoeker, locatie, dienst en één of meerdere partijen toevoegen (zie overige use cases) De gebruiker kan pas opslaan als de verplichte gegevens ingevuld werden. Het systeem maakt een nieuw dossier aan, volgende velden worden automatisch ingevuld:
dossiernummer: type (1 digit) + . + jaar(4 digits) + - + nummer(4 digits) + / + initialen dossierbeheerder(4digits), bv. C.2012-1234/CCLA; status: geregistreerd; registrator: login gegevens van de aangemelde persoon; datum registratie: de huidige datum.
Het systeem zal ook een event in de historiek toevoegen: ‘Registratie dossier’ met de ingelogde gebruiker en de datum Uitzonderingen
De gebruiker kan de aanmaak annuleren door op ‘Annuleren’ te klikken
Resultaat
Het dossier is aangemaakt en alle metadata is aangepast
Tabel 3: Use case 1
16
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Matthias Serbruyns
B Use case 1a: toevoegen activator (verzoeker) uit Vesta Na dat er een dossier is aangemaakt kunnen er optionele gegevens worden toegevoegd. Deze gegevens zijn bijvoorbeeld een partij, een dienst, … Zij worden ook contacten genoemd. Een activator is een persoon of dienst die betrokken partij is en besloten heeft om een actie te ondernemen. Deze Use case is ook van toepassing op het toevoegen van een partij. Naam
Toevoegen activator aan een dossier
Samenvatting
Het toevoegen van activator uit Vesta aan nieuw of een bestaand dossier
Actoren
Administratie + dossierbeheerder + key user (enkel activator) De gebruiker opent een dossier en heeft daar de mogelijkheid om gegevens toe te voegen. De lijst met externe gegevens is opgeslagen in Vesta. De gebruiker komt terecht in een zoekscherm met volgende velden:
naam persoon; voornaam persoon; email; naam bedrijf; straat; postcode; gemeente; land.
De gebruiker vult 1 of meerdere zoekcriteria in en drukt dan op zoeken. Het systeem voert een zoekopdracht uit binnen Vesta door gebruik te maken van de Vesta web service en stuurt een lijst met activators terug. De gebruiker kan uit die zoekresultaten de juiste contact aanduiden. De gebruiker kan steeds de criteria aanpassen en opnieuw zoeken. De criteria en resultaten staan op hetzelfde scherm zodat het eenvoudig is om de criteria aan te passen.
Beschrijving
Ten minste één van de velden ‘Naam persoon’, ‘Email’ of ‘Naam bedrijf’ dient ingevuld te zijn. Om privacy-redenen dient de gebruiker bij het zoeken op basis van de 'Naam persoon' ook nog minstens 1 bijkomend veld in te vullen. Ten minste 2 karakters per veld dienen ingevuld te worden. Bij het zoeken naar een bedrijf wordt zowel gezocht op de commerciële als de maatschappelijke naam. Bij aanduiden van een activator zal het systeem volgende velden kopiëren vanuit Vesta:
aanspreektitel; naam; voornaam; geboortedatum; email; maatschappelijke naam bedrijf; commerciële naam bedrijf; straat; huisnummer; bus; postcode; gemeente; land; telefoon nummer 1; telefoon nummer 2; telefoon nummer 3; Vesta ID. 17
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Matthias Serbruyns
Vesta kan een onbepaald aantal telefoonnummers per contact bevatten, voor dit systeem gaan we de eerste 3 nummers weerhouden. De gebruiker kan nadien manueel een type, een dossiernummer en kan eventueel nog een opmerking toevoegen in het veld Opmerking. Deze 3 velden staan los van Vesta. De gebruiker kan de Vesta ID aanklikken en de gegevens van die contact binnen Vesta bekijken. Er kunnen meerdere activators aan 1 dossier gekoppeld worden. De gebruiker moet een bijkomende activator kunnen toevoegen en reeds gekoppelde kunnen verwijderen. Indien de activator niet beschikbaar is binnen Vesta dient de gebruiker deze eerst aan te maken binnen Vesta. Er is geen synchronisatie tussen gegevens van dit systeem en Vesta voorzien na aanmaak van een activator. Als de gegevens wijzigen in Vesta worden ze niet aangepast in dit systeem. De gebruiker kan door de Vesta ID URL aan te klikken wel steeds de laatste gegevens van de contact raadplegen. Het systeem zal geen event in de historiek toevoegen.
Uitzonderingen
De gebruiker kan het toevoegen van de activator annuleren door op ‘Annuleren’ te klikken
Resultaat
De activator is toegevoegd aan het dossier
Tabel 4: Use case 1a
C Use case 1b: toevoegen locatie Aan een dossier kan ook soms een locatie hangen. Waar is het ongeval gebeurd? Op welk adres? Welke locatie? Het gaat hier met andere woorden over de plaats waar het feit zich heeft afgespeeld. Deze informatie kan ook uit Vesta komen. Alle adressen of straatnamen van Gent staan in Vesta. Als het van een straat buiten Gent is zal deze eerst moeten worden toegevoegd. Als het gaat om bijvoorbeeld een ongeval op een autosnelweg waar geen adres kan aan gekoppeld zijn, dan kunnen we deze niet opzoeken of toevoegen in Vesta. Daarom hebben we ervoor gezorgd dat er een extra veld is waar er vrij iets kan ingevuld worden als omschrijving voor de locatie. Naam
Toevoegen locatie aan dossier
Samenvatting
Het toevoegen van een locatie aan nieuw of een bestaand dossier
Actoren
Administratie + dossierbeheerder + key user De gebruiker opent een dossier en heeft daar de mogelijkheid om een locatie te kiezen. De gebruiker komt terecht in een zoekscherm met volgende velden:
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Matthias Serbruyns
X-coördinaat; Y-coördinaat.
De gebruiker vult 1 of meerdere zoekcriteria in en drukt dan op zoeken. Het systeem voert een zoekopdracht uit binnen Vesta door gebruik te maken van de Vesta web service en krijgt een lijst met locaties terug. De gebruiker kan uit de zoekresultaten de juiste locatie aanduiden. De gebruiker kan steeds de criteria aanpassen en opnieuw zoeken. De criteria en resultaten staan op hetzelfde scherm zodat het eenvoudig is om de criteria aan te passen. Ten minste 2 karakters per veld dienen ingevuld te worden. Bij aanduiden van de locatie zal het systeem volgende velden kopiëren vanuit Vesta:
De gebruiker kan nadien manueel een extra omschrijving toevoegen. Dit veld staat los van Vesta. De gebruiker kan de Vesta ID aanklikken en de gegevens van die contact binnen Vesta bekijken. Er kunnen meerdere locaties aan 1 dossier gekoppeld worden De gebruiker moet een bijkomende locatie kunnen toevoegen en een reeds gekoppelde locatie kunnen verwijderen. Indien de locatie niet beschikbaar is binnen Vesta dient de gebruiker de locatie eerst aan te maken binnen Vesta. Indien de locatie niet gekoppeld kan zijn aan een adres of straatnaam (bv. autosnelweg) dan is er de mogelijkheid om in een extra veld daar de omschrijving in te vullen, bijvoorbeeld E40 Kilometerpaal X. Er is geen synchronisatie tussen gegevens van dit systeem en Vesta voorzien na aanmaak van de locatie. Als de gegevens wijzigen in Vesta worden ze niet aangepast in dit systeem. De gebruiker kan door de Vesta ID URL aan te klikken wel steeds de laatste gegevens van de locatie raadplegen. Het systeem zal geen event in de historiek toevoegen.
Uitzonderingen
De gebruiker kan het toevoegen van de locatie annuleren door op ‘Annuleren’ te klikken
Resultaat
De locatie is toegevoegd aan het dossier
Tabel 5: Use case 1b
19
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Matthias Serbruyns
D Use case 1c: toevoegen rechtbankgegevens aan een dossier Er moeten ook rechtbankgegevens kunnen worden toegevoegd aan een dossier. Een dossier kan meerdere rechtbankgegevens hebben. Naam
Toevoegen rechtbankgegevens aan dossier
Samenvatting
Het toevoegen van rechtbankgegevens aan een nieuw of een bestaand dossier
Actoren
Administratie + dossierbeheerder + key user De gebruiker kan nieuwe rechtbankgegevens toevoegen of bestaande gegevens wijzigen. Volgende velden dienen verplicht ingevuld te worden:
Beschrijving
naam rechtbank; datum; uitspraak.
Per dossier kunnen verschillende rechtbankgegevens ingevuld worden. Het systeem zal ook een event in de historiek toevoegen: ‘Rechtbankgegevens’ met de ingelogde gebruiker en de datum Uitzonderingen
De gebruiker kan het toevoegen annuleren door op ‘Annuleren’ te klikken
Resultaat
De rechtbankgegevens zijn toegevoegd aan het dossier
Tabel 6: Use case 1c
E Use case 2: afsluiten Dossier Als een dossier is afgerond moet het ook kunnen worden afgesloten. Dit dossier zal dan als inactief worden beschouwd en zal niet meer getoond worden in de lijst met actieve dossiers die een dossierbeheerder te zien krijgt. Naam
Afsluiten dossier
Samenvatting
Het afsluiten van een juridisch dossier
Actoren
Administratie of dossierbeheerder
Aannamen
Deze actie is enkel beschikbaar voor actieve dossiers De gebruiker kan een dossier afsluiten.
Beschrijving
Het systeem zal eerst een bevestiging vragen aan de gebruiker of deze het dossier wil afsluiten. Indien de gebruiker confirmeert zal het systeem vragen aan de gebruiker om een reden van afsluiten te kiezen uit een drop down lijst. Bovendien zal het systeem de waarde van het veld ‘Intern klassement’ tonen en is dit verplicht in te vullen. Het systeem sluit het dossier af en volgende velden worden ingevuld:
reden afsluiten: de reden die is aangegeven door de gebruiker bij het 20
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Matthias Serbruyns
afsluiten; intern klassement: waarde die is ingevuld door de gebruiker; datum afsluiting: de huidige datum; status: afgesloten.
Het systeem zal ook een event in de historiek toevoegen: ‘Afsluiten dossier’ met de ingelogde gebruiker en de datum Uitzonderingen
De gebruiker kan het afsluiten annuleren door op ‘Annuleren’ te klikken
Resultaat
Het dossier is afgesloten en alle metadata is aangepast
Tabel 7: Use case 2
F Use case 3: heropenen dossier Een dossier kan ook terug heropend worden als er bijvoorbeeld nieuwe elementen boven zijn gekomen. Naam
Heropenen dossier
Samenvatting
Het heropenen van een juridisch dossier
Actoren
Administratie of dossierbeheerder
Aannamen
Deze actie is enkel beschikbaar voor afgesloten dossiers De actie ‘heropenen dossier’ is beschikbaar voor afgesloten dossiers. Het systeem zal eerst een bevestiging vragen aan de gebruiker of deze het dossier wil heropenen. Indien de gebruiker confirmeert zal het systeem het dossier heropenen en de details tonen.
Beschrijving
Het systeem zal volgende velden aanpassen:
status: heropend.
De velden ‘Reden Afsluiten’ en ‘Datum afsluiting’ worden niet blanco gemaakt. Het systeem zal ook een event in de historiek toevoegen: ‘Heropenen dossier’ met de ingelogde gebruiker en de datum Uitzonderingen
De gebruiker kan het heropenen annuleren door op ‘Annuleren’ te klikken
Resultaat
Het dossier is actief en alle metadata is aangepast
Tabel 8: Use case 3
21
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
G Use case 4: koppelen dossiers Dossiers kunnen ook gekoppeld worden aan elkaar. Het moet mogelijk zijn om meerdere dossiers met elkaar te koppelen. Naam
Koppelen dossiers
Samenvatting
Het koppelen van dossiers aan elkaar
Actoren
Administratie of dossierbeheerder De gebruiker moet de mogelijkheid hebben om dossiers aan elkaar te koppelen. De gebruiker gaat naar de details van een dossier en kiest dan de actie ‘dossier koppelen’. De toepassing opent een zoekscherm waar de gebruiker de naam van het te koppelen dossier kan ingeven. Na bevestiging worden beide dossiers gekoppeld.
Beschrijving
In de details van beide dossier is de koppeling zichtbaar. De gebruikers moeten de gekoppelde dossiers kunnen bekijken en aanklikken om naar de details van dat dossier te gaan. Het systeem zal ook een event in de historiek toevoegen van beide gekoppelde dossiers ‘Gekoppeld dossier’ met de ingelogde gebruiker en de datum + de naam van het gekoppeld dossier in extra informatie. Het moet mogelijk zijn om meerdere dossiers te koppelen aan 1 dossier. De gebruiker moet ook de mogelijkheid hebben om een koppeling te verwijderen.
Resultaat
De dossiers zijn gekoppeld
Tabel 9: Use case 4
H Use case 5: documentgeneratie Er moeten documenten kunnen worden gegenereerd op basis van een sjabloon. Het document moet automatisch vaste velden invullen over het dossier zoals nummer, datum, … Er moet ook nog witruimte zijn om er zelf nog eventueel manueel nog zaken aan toe te voegen. Naam
Document aanmaken op basis van sjabloon
Samenvatting
Een document zoals een ontvangstbevestiging of een aanmaning aanmaken op basis van een sjabloon
Actoren
Dossierbeheerder Een dossierbeheerder moet een document kunnen opstellen via de toepassing. Bij aanklikken van de actie kiest de gebruiker uit een type (aanmaning, ontvangstbevestiging,…).
Beschrijving
Bij bevestiging zal het systeem een reeks velden uit het dossier kopiëren naar het MS-Word of MS-Excel sjabloon en een nieuw document aanmaken. Het nieuwe document wordt toegevoegd aan het dossier en het document wordt geopend. De gebruiker kan manueel nog wijzigingen aanbrengen aan het document. Nadien moet hij het document bewaren in de applicatie, het 22
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
document afdrukken en doorsturen naar de betrokken partij. Het systeem zal ook een event in de historiek toevoegen: ‘Aanmaak document’ met de ingelogde gebruiker en de datum + het type sjabloon in extra informatie Een beheerder moet de mogelijkheid hebben om nieuwe sjablonen op te laden en wijzigingen aan te brengen in de velden die overgebracht moeten worden. Uitzonderingen
De gebruiker kan de aanmaak annuleren door op ‘Annuleren’ te klikken
Resultaat
Het document is aangemaakt, toegevoegd aan het dossier en het event is toegevoegd aan het dossier
Tabel 10: Use case 5
I
Use case 6: zoeken dossier
Dossiers moeten kunnen worden opgezocht. Er moeten 2 zoekfuncties aanwezig zijn. Eerst moet er een snel zoekfunctie zijn. Er wordt 1 parameter ingevuld en vervolgens wordt er op die parameter overal gezocht. Als tweede moet er ook een uitgebreide zoekfunctie zijn. Hier kunnen meerdere velden worden ingevuld waarop gezocht moet worden. Naam
Zoeken
Samenvatting
Functionaliteiten voor het opzoeken van dossiers en documenten Het systeem moet heel flexibele zoekmogelijkheden aanbieden aan de gebruikers. Volgende functionaliteiten moeten voorzien worden:
Beschrijving
alle metadata-gegevens van het dossier moeten kunnen gebruikt worden als zoekcriteria (criteria reeds ingevuld); de verzoeker, locatie, partij en dienst moeten doorzoekbaar zijn; metadata van de documenten moeten doorzoekbaar zijn; de documenten moeten doorzoekbaar zijn op basis van de full tekst van de inhoud; er moet een snelle zoekmogelijkheid voorzien worden op basis van 1 invulveld: het systeem zoekt zowel op ‘dossiernummer’, ‘naam partij (voornaam + achternaam)’, ‘naam verzoeker’, ‘naam locatie’ als ‘datum feit’; de gebruiker moet de mogelijkheid hebben om zoekopdrachten bewaren (optioneel); de zoekcriteria moeten een filtering op speciale karakters (ç, é, à, è, ö, etc.) ondersteunen. Bijv. een zoekopdracht naar ‘Francois’ moet ook ‘François’ teruggeven als resultaat; het moet mogelijk zijn om zoekresultaten te exporteren; de zoekschermen moeten het totaal aantal resultaten tonen; er mag geen beperking voorzien worden op het aantal getoonde resultaten (geen beperking tot vb. 350 of 500).
Tabel 11: Use case 6
23
Matthias Serbruyns
2.2
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Conceptueel datamodel
Bij een datamodel definiëren we welke gegevens in een informatiesysteem vastgelegd kunnen worden, hoe ze gestructureerd zijn en welke verbanden ze met elkaar hebben. Het is een vereenvoudigde weergave van de werkelijkheid en zorgt voor een beter overzicht. Het zorgt ervoor dat de omvang en de complexiteit van het systeem beter te bevatten is. Ook elke doelgroep kan deze modellen eenvoudiger begrijpen en lezen, zo ontstaat er betere communicatie tussen bijvoorbeeld analisten, ontwikkelaars en de business. Er is een relationeel model opgesteld voor een duidelijk overzicht op de database. In een relationeel model hebben we een duidelijk beeld op de verschillende tabellen en de relaties tussen deze tabellen. Bij het nieuwe systeem hebben we een centrale tabel ‘Dossiers’. Aan deze tabel hangen verschillende gerelateerde tabellen zoals ‘Dossierbeheerders’, ‘Activators’, ‘Partijen’, …
2.2.1 Relatie dossier – dossierbeheerder Een dossier heeft altijd 1 dossierbeheerder en kan ook maximaal maar 1 beheerder hebben. Ze hebben een 1 op veel relatie.
Fig. 10: Relatie Dossier - Dossierbeheerder
2.2.2 Relatie dossier – activator / partij Een dossier heeft ook altijd een activator en verschillende partijen. Een dossier kan meerdere activators/partijen hebben en een activator/partij kan aan meerdere dossiers gelinkt zijn. Daarom is er een veel op veel relatie tussen deze tabellen.
24
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Fig. 11: Relatie Dossier - Partij/Activator
2.2.3 Relatie Dossier – locatie Een dossier kan 1 of meerdere locaties hebben waar een feit zich heeft afgespeeld. Daarom is er hier ook een veel op veel relatie. Een dossier kan meerdere locaties hebben maar een locatie kan ook gelinkt zijn aan meerdere dossiers.
Fig. 12: Relatie Dossier – Locatie
25
Matthias Serbruyns 2.2.4
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Relatie Dossier – rechtbankgegevens
Een dossier kan later ook voor de rechtbank verschijnen. Dit kan ook verschijnen voor meer dan 1 rechtbank. Een dossier kan dus meerdere rechtbankgegevens hebben. Een rechtbank behandelt ook meer dan 1 dossier, daarom is er hier een veel op veel relatie.
Fig. 13: Relatie Dossier - Rechtbankgegevens
2.2.5 Relatie Dossier – document Een dossier heeft verschillende documenten. Een dossier kan ook meerdere documenten hebben. Een document kan behoren tot 1 dossier. Daarom maken we gebruik van een 1 op veel relatie.
Fig. 14: Relatie Dossier – Document
26
Matthias Serbruyns
2.3
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Keuze technologie
Na de analyse en het maken van het datamodel was het tijd om te kiezen voor welke technologie we zouden kiezen. Oorspronkelijk was het de bedoeling om alles te maken in een.NET-applicatie en de documenten in Alfresco, een document management systeem. Maar gedurende de analyse periode werd duidelijk dat het eigenlijk veel makkelijker en performanter kan door gebruik te maken van bestaande Microsoft systemen. We wilden ook de look en feel gebruiken van Microsoft Office die de mensen gewoon zijn (ribbon, etc.). Microsoft Dynamics CRM 2011 voldoet perfect aan onze requirements en is eenvoudig te gebruiken. Microsoft Dynamics CRM 2011 is een Customer Relation Management systeem ontwikkeld door Microsoft. We kunnen er verschillende lijsten in bijhouden entiteiten zoals dossiers, dossierbeheerders, partijen, … Via formulieren kunnen we dossiers toevoegen en aanpassen. Voor documenten op te slaan maken we gebruik van SharePoint 2010. Dit is super eenvoudig te integreren en zo blijven we binnen de Microsoft omgeving. Ook voor het ontwikkelen van dit systeem gaat er minder werk moeten gebeuren. Voor het maken van de formulieren kunnen we gebruik maken van een designer en slepen we er gewoon de verschillende velden op. Ook is het mogelijk om via Javascript formulieren aan te passen. Via web resources kunnen we ook Silverlight applicaties toevoegen aan een formulier. Er moet ook niets gedaan worden in SQL. Dit gebeurt allemaal in de achtergrond. Bijvoorbeeld bij het maken van een entiteit (bv. Dossier) wordt er een tabel gemaakt in de achtergrond in SQL. Ook als we velden toevoegen aan een entiteit dan worden er kolommen toegevoegd in SQL aan die tabel. Ook Vesta is gemaakt in een Microsoft Dynamics CRM 2011 systeem. Daardoor is het nog eenvoudiger om ons systeem te koppelen met Vesta. Op vlak van security moet er niets meer gedaan worden. Alles gebeurt via de Active Directory en er kunnen rechten worden toegekend in het CRM systeem voor de verschillende rollen. Met andere woorden: door met CRM 2011 te werken wordt er al veel gedaan voor de ontwikkelaar.
2.4
Vesta
Ondertussen is de term Vesta al een paar keer aanbod gekomen. Maar wat is Vesta nu juist? Vesta is een centrale databank met contactgegevens. Dit zijn gegevens van personeel, burgers, bedrijven, verenigingen, instellingen, enz. Er is ook een scheiding tussen privé- en professionele contacten. De databank is gebouwd in een Microsoft Dynamics CRM 2011 systeem. Vesta haalt zijn gegevens van authentieke bronnen zoals WinLbv, GRAB/CRAB, enz. Er worden wettelijke basisgegevens bijgehouden zoals het rijksregisternummer, aanvullende contactgegevens. Ook gebeurt er een dagelijkse update in Vesta om steeds correcte gegevens te garanderen. Momenteel zitten alleen de personen die gedomicilieerd zijn in Gent in de database alsook de organisaties die relaties hebben met de Stad Gent. Er was dringend nood aan een centrale databank met contactgegevens omdat er teveel applicaties zijn die gebruik maakten van verschillende (niet-gevalideerde) adresnotaties. Nu kunnen alle applicaties authentieke en correcte contactgegevens ophalen en zullen dubbele en fout gegevens vermeden worden. Vesta zal dus ook zorgen voor een betere dienstverlening. Dit systeem zal voornamelijk gebruikt worden door de verschillende diensten van de stad Gent. Vesta is ontwikkeld door RealDolmen in opdracht van Digipolis.
27
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Matthias Serbruyns
Toepassing om lijsten van contacten te beheren
Update vanuit authentieke bronnen
Adressen
Scheiding tussen privé en professionele contacten
Fig. 15: Vesta
Vesta bevat is naast een databank voor contactgegevens van personen en organisaties ook een lijsten-toepassing. Bovenop de contactgegevens kunnen er specifieke lijsten worden aangemaakt die vaak zullen gebruikt worden. Aan deze lijsten kunnen dan personen of organisaties worden aan toegevoegd. Via een extra beveiliging zullen deze lijsten toegankelijk worden gemaakt voor een aantal mensen en niet voor iedereen. Het Vesta datamodel ziet er als volgt uit:
Fig. 16: Vesta Datamodel
Een privépersoon, professionele persoon of een organisatie haalt zijn contactgegevens uit de adressentabel. Deze adressen zijn allemaal authentiek en dus correct. Een professionele persoon is altijd gekoppeld aan een privépersoon en aan een organisatie. Bovenop de standaard web service van CRM is er door RealDolmen een extra web service aan toegevoegd, de Vesta Connector genaamd. 28
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Fig. 17: Vesta Connector
Bovenop de standaard validatie van CRM is er nog extra validatie aan toegevoegd via de Vesta Digipolis web service. De connector maakt gebruik van een Soap web service. De toegang gebeurt via een systeemaccount per toepassing. Deze moeten worden beheerd door applicatiebeheer bij Digipolis. De eindgebruiker wordt via een parameter doorgegeven zodat alle acties kunnen worden gelogd. In de connector zit alle logica geïmplementeerd: rechten voor bepaalde acties, formattering van datums, getallen, validatie van input, enz. Ook zijn er een aantal tussenschermen ontwikkeld door RealDolmen die gebruikt kunnen worden voor verschillende acties zoals het zoeken van een contact, toevoegen van een contact, bewerken van een contact, etc. Deze schermen zijn bedoeld om vooral gebruikt te worden door niet CRM gebaseerde toepassingen. De schermen zijn niet ontwikkeld voor een specifieke applicatie maar zijn bedoeld om globaal te gebruiken binnen de diensten van Stad Gent voor snel bijvoorbeeld een contact toe te voegen. Het systeem van de Juridische Dienst heeft een aantal extra velden nodig voor het toevoegen van een contact uit Vesta en daarom kunnen deze schermen niet gebruikt worden binnen mijn applicatie.
29
Matthias Serbruyns
3
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Ontwikkeling Juridoc
Omdat ze bij Digipolis gebruik maken voor verschillende omgevingen voor de verschillende fases van de ontwikkeling van een product moest er eerst een naam worden gekozen voor het CRM systeem zodat het in een later stadium makkelijker is om de toepassing over te zetten van een ontwikkelomgeving naar een productieomgeving. In bijlage 1 kan u Na dat de Juridische Dienst de naam Juridoc op de proppen kwam kon er worden gestart met het opzetten van de basisstructuur van het systeem.
3.1
Opzetten basisstructuur
3.1.1 Aanmaken solution Een CRM-systeem bestaat uit solutions. Een solution is eigenlijk een soort van pakket dat alle componenten bevat die ondersteund worden door CRM en die een specifieke bijdrage leveren aan de functionaliteit van de toepassing. Deze componenten kunnen gaan van plug-ins tot afbeeldingen die gebruikt worden. Een solution wordt gezien als een software die geïnstalleerd kan worden op andere plaatsen. Eens een solution is aangemaakt kan deze eenvoudig op een ander CRM-systeem worden geïnstalleerd, zowel op CRM online als op CRM On-Premises. Dit is zorgt ervoor dat de solution van de ontwikkelomgeving eenvoudig kan geëxporteerd worden naar de productieomgeving. Een solution kan ook geüpdatet worden en er worden versies bijgehouden. Ook kan een solution verwijderd worden van een CRM-systeem.
Fig. 18: Componenten Solution
Om een solution aan te maken gaan we naar de instellingen van het CRM-systeem en kiezen we voor solutions of oplossingen. Hier kiezen we voor een nieuwe solution aan te maken.
30
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Fig. 19: Solution Juridoc
Een solution kan un-managed of managed zijn. Een un-managed solution is een solution die aanpasbaar is. Meestal zijn deze solutions nog in ontwikkeling. Een managed solution is een solution die af is. Dit is een un-managed solution die geëxporteerd is als een managed solution en daardoor afgesloten is voor aanpassingen aan de solution. Deze worden meestal gebruikt voor in productieomgevingen. Via bepaalde configuratie mogelijkheden is het echter wel mogelijk om bepaalde velden of instellingen aan te passen in een managed solution. Dit zijn echter meestal alleen visuele aanpassingen zoals het aanpassen van een view of de naam van een veld. Aanpassingen aan belangrijke kern functionaliteiten zijn niet mogelijk.
3.1.2 Aanmaken entiteiten In een solution bevinden zich meestal ook een aantal entiteiten. Een entiteit in CRM 2011 wordt gebruikt om te modelleren en om data te beheren. Een entiteit heeft ook een aantal attributen en elk attribuut staat voor een data item van een bepaald type. Een entiteit contact heeft bijvoorbeeld een naam als attribuut. Een entiteit is eigenlijk een object-georiënteerd begrip voor een databasetabel en de attributen zijn de kolommen. Een entiteit aanmaken in CRM 2011 is eigenlijk hetzelfde als het aanmaken van een tabel in een database. In CRM 2011 kunnen er zelf entiteiten worden aangemaakt. Maar er zitten ook standaard entiteiten in CRM 2011. Entiteiten zoals contacten, accounts, etc. zitten er allemaal al in. Als er bijvoorbeeld een entiteit moet aangemaakt die lijkt op een standaard entiteit dan kan je evengoed de standaard entiteit gebruiken in plaats van een entiteit vanaf nul op te bouwen. Voor het Juridoc systeem heb ik meestal zelf mijn entiteiten opgebouwd omdat er geen enkele standaard entiteit bestond die ik kon hergebruiken zonder al teveel aanpassingen te moeten doen. Om een entiteit aan te maken, openen we onze solution en gaan we naar entiteiten. Daar kunnen we een nieuwe entiteit aanmaken. Het is belangrijk om bij “Ownership” te kiezen voor “User or Team” en niet voor “Organization”. Als er wordt gekozen voor “Organization” dan is die entiteit toegankelijk voor de hele organisatie en kunnen er geen rechten worden ingesteld voor die entiteit. Dit is een fout die ik gemaakt heb en pas achteraf ontdekt hebben toen we de rollen wilden instellen voor de gebruikers. Aangezien de Ownership eigenschap van de entiteit niet kan aangepast worden na creatie moest ik alle entiteiten die als Ownership “Organization” hadden verwijderen en opnieuw aanmaken. A Entiteit dossier Omdat het Juridoc systeem draait rond dossiers, wordt de entiteit dossier onze belangrijkste entiteit. Deze entiteit zal een lijst bijhouden van alle dossiers.
Fig. 20: Entiteit Dossier
31
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
De entiteit dossier moet zichtbaar zijn in de werkruimte van CRM. Sommige entiteiten moeten soms niet zichtbaar zijn voor iedereen en moeten dus enkel getoond worden in het instellingen venster of helemaal niet.
Fig. 21: Gebieden entiteit zichtbaar is
Ook kan er geconfigureerd worden of een entiteit moet kunnen gekoppeld worden aan een documentenbeheersysteem zoals bijvoorbeeld SharePoint. Als we de functie auditing of controlegeschiedenis aanvinken dan gaat het CRM-systeem ook automatisch alle wijzigingen die een record van de entiteit dossier heeft ondergaan bijhouden. Via de controlegeschiedenis houdt het systeem mooi bij welke aanpassingen er zijn gebeurd aan een dossier en welke gebruiker de aanpassingen heeft uitgevoerd.
Fig. 22: Entiteit opties
Een entiteit heeft ook een hoofdveld. Dit is een standaard veld dat altijd aanwezig zal zijn. Je kunt er niet veel aan aanpassen behalve de naam en of het al dan niet vereist is. Ook het type kan niet worden aangepast. Dit hoofdveld zal het veld zijn dat zichtbaar is bij het resultaat van een lookup veld. In het geval van de entiteit dossier is mijn hoofdveld het dossiernummer.
Fig. 23: Entiteit hoofdveld
Nadat we alle basisinstellingen van een entiteit hebben geconfigureerd kunnen we de entiteit opslaan. De prefix “new” toont aan dat deze entiteit om een aangepaste entiteit gaat. Deze prefix kan aangepast worden door naar “Customizations” of aanpassingen te gaan en te klikken op “Publishers”. Vervolgens kies je de publisher van de solution waar je in werkt en kan je daar de prefix aanpassen.
Fig. 24: Aanpassen prefix publisher
32
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
De volgende stap is om de attributen of velden toe te voegen aan de entiteit. Standaard worden al een aantal standaard velden toegevoegd aan een entiteit zoals “datum aangemaakt”, “aangemaakt door”, etc. Een aangepast veld toevoegen ziet er hetzelfde uit als het aanpassen van een hoofdveld met het verschil dat we dit veld wel volledig kunnen aanpassen naar onze wensen.
Fig. 25: Velden Dossier
De entiteit dossier heeft heel wat velden dus zullen we beginnen bij het begin. Een dossier heeft altijd een naam nodig. Dit is het dossiernummer. Het dossiernummer is een gewoon tekst veld dat bestaat uit 20 karakters. Dit is tevens ook het hoofdveld dat we daarnet hebben besproken. Het dossiernummer wordt samengesteld op basis van een aantal parameters. Deze parameters zijn: het type van het dossier, het jaar van creatie van het dossier, een nummer dat oploopt en terug vanaf 0 begint bij een nieuw jaar en de initialen van de dossierbeheerder. Het veld type is een keuze veld met 2 opties. Een dossier kan ofwel een type A zijn (advies) of type C (contentieux). Dit is een verplicht veld dus zetten we “Requirement level” op “Business Required”. Ook moet het mogelijk zijn om op dat veld te kunnen zoeken. Auditing staat aangevinkt omdat we willen bijhouden wie of wanneer er iemand het type van een dossier heeft gewijzigd. Het type van het veld is een 2-keuze veld. Het woord zegt het zelf: er zijn maar 2 mogelijkheden die je zelf kan instellen.
Fig. 26: veld Type dossier
Het veld “jaar creatie” en “nummer” zijn respectievelijk een datum veld en een nummer veld. Deze zullen niet zichtbaar zijn en worden enkel bewaard in de achtergrond. Deze velden zijn nodig om het dossiernummer te vormen via een plug-in. 33
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Het veld “dossierbeheerder” is een veld gebaseerd op een record van het type entiteit dossierbeheerder. Dit is een lookup veld. Ook dit veld is verplicht en er zal worden gecontroleerd op wijzigingen. Het type is een lookup. Dit wil zeggen dat we een record kunnen opzoeken van een bepaald type entiteit. In dit geval gaat het om een record van het type dossierbeheerder. Automatisch wordt voor ons ook al de relatie gelegd tussen de entiteit dossier en de entiteit dossierbeheerder. Uiteraard moet de entiteit dossierbeheerder al reeds aangemaakt zijn vooraleer we deze lookup kunnen aanmaken. Ik verwijs graag naar punt B waar de entiteit dossierbeheerder wordt aangemaakt.
Fig. 27: veld Dossierbeheerder dossier
Een dossier wordt ook pas geregistreerd als er een aanleiding is. Een aanleiding kan gaan van een telefoon, fax, email, etc. Eerst had ik nog gekozen voor een option set maar het probleem van dit type is dat de lijst met mogelijkheden niet meer aangepast kan worden door de administratie van de Juridische Dienst als er bijvoorbeeld een extra keuze mogelijkheid toegevoegd moet worden aan die lijst (bv. Facebook bericht). Daarom heb ik dit een extra entiteit genaamd aanleiding voorzien. Via deze entiteit kan er gemakkelijk een extra aanleiding worden toegevoegd aan de lijst. En via het lookup veld “aanleiding” in de entiteit dossier kan dan snel een aanleiding uit die lijst worden geselecteerd.
Fig. 28: veld Aanleiding dossier
34
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Dossiers worden ook gecategoriseerd via hun onderwerp. Een dossier heeft altijd een hoofdonderwerp en kan een subonderwerp hebben. Een hoofdonderwerp kan bijvoorbeeld zijn invordering en een subonderwerp is dan bijvoorbeeld onderwijs. Een subonderwerp is gebaseerd op de selectie van het hoofdonderwerp. Omdat deze velden net als bij dossierbeheerder en aanleiding uit een aan te passen lijst moeten komen zijn ook deze velden van het type lookup. Ook is er een veld samenvatting. Dit is een tekstveld waar meerdere lijnen tekst in kunnen komen te staan. Het aantal karakters dat toegelaten is ook veel grotere dan een normaal tekstveld namelijk 3000. Er zijn nog een aantal datum velden zoals datum van de feiten, datum van de aanleiding, etc. die voor zichzelf spreken en die ik hier niet zal aanhalen. Na het aanmaken van de verschillende velden kunnen we nu het formulier opmaken. Het formulier opmaken gebeurt heel eenvoudig met de ingebouwde designer. Aan de rechterkant kunnen we alle velden zien die we hebben aangemaakt binnen de entiteit dossier. We kunnen een veld selecteren en verslepen naar een gewenste plaats op het formulier. Er kunnen witruimtes worden toegevoegd, extra tabbladen, web resources, etc. Ook kunnen er scripts worden toegevoegd aan een formulier maar hier ga ik later dieper op in (zie punt 3.2).
Fig. 29: Design formulier
Het dossiernummer en nummer bovenaan zijn beiden read-only velden. Deze mogen niet worden aangepast. Ook is ervoor gezorgd dat er in de lookup velden niet kan worden getypt om ongewenste waarden te voorkomen (zie fig. 30).
Fig. 30: field behaviour lookup
35
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Het lookup veld subonderwerp moet ook gebaseerd zijn op de geselecteerde waarden van het veld hoofdonderwerp. Dit passen we aan door te dubbelklikken op het veld of eenmaal te klikken op het veld en bovenaan in de ribbon te klikken op “Change properties”. De subgrid mag alleen maar de subonderwerpen tonen die in een hoofdonderwerp zitten (zie fig. 31).
Fig. 31: subonderwerp gebaseerd op hoofdonderwerp
B Entiteit dossierbeheerder De naam dossierbeheerder heeft niet veel verduidelijking meer nodig. Het is de persoon, meestal een jurist(e), die het dossier gaat beheren. Elk dossier heeft verplicht een dossierbeheerder toegewezen gekregen. De dossierbeheerders zijn allemaal werkzaam bij de Juridische Dienst en zijn geen externen. Deze entiteit zal een lijst bijhouden van alle dossierbeheerders. De entiteit zal enkel zichtbaar zijn bij de instellingen waar niet iedereen toegang toe heeft. Het hoofdveld heet initialen. Als er bij een dossier dus een dossierbeheerder wordt geselecteerd via het lookup veld dan zal het resultaat van de geselecteerde dossierbeheerder zijn initialen zijn.
Fig. 32: resultaat lookup dossierbeheerder
De initialen van een dossierbeheerder worden samengesteld op basis van de naam en de voornaam. Dit gebeurt via een plug-in die een actie uitvoert na het aanmaken van een nieuwe dossierbeheerder (zie punt 3.4). De entiteit dossierbeheerder bevat niet veel meer informatie dan enkel de naam en de voornaam van de dossierbeheerder. Eventueel ook extra informatie kan ingevuld worden maar deze is niet vereist.
Fig. 33: lijst dossierbeheerder
Entiteit aanleiding De entiteit aanleiding is een zeer eenvoudige entiteit om een lijst bij te houden van aanleidingen. Het heeft maar 1 veld en dat is het hoofdveld “naam”. Het is enkel zichtbaar onder de instellingen.
Fig. 34: lijst aanleidingen
36
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
C Entiteit hoofdonderwerp en subonderwerp De entiteiten hoofdonderwerp en subonderwerp bestaan elk uit 2 velden: een veld naam (verplicht) en een veld omschrijving (niet verplicht). Een hoofdonderwerp heeft verschillende subonderwerpen en een subonderwerp kan behoren tot meerdere hoofdonderwerpen. Daarom ligt er een veel-op-veel relatie tussen beiden entiteiten. Deze kunnen eenvoudig gelegd worden door te klikken op “N:N Relationships” onder de entiteit hoofdonderwerp. Vervolgens klikken we op “Nieuw” en selecteren we de andere entiteit waar we mee een relatie willen leggen. In ons geval is dit de entiteit subonderwerp. Uiteindelijk slaan we dit op en hebben we een relatie gelegd tussen beide entiteiten. Op het formulier van een hoofdonderwerp plaatsen we een subgrid. Dit is een lijst van een entiteit die gerelateerd is met de entiteit van het formulier. Hier plaatsen we een subgrid van de entiteit subonderwerpen. Zo kunnen we als er een hoofdonderwerp wordt geopend snel zien welke subonderwerpen deze allemaal heeft. Om dit te doen klikken we bovenaan de ribbon op “Insert” en vervolgens op “Subgrid”. Vervolgens kunnen we de entiteit selecteren die we willen zien in deze subgrid.
Fig. 35: Subgrid Hoofdonderwerp
We doen ook het omgekeerde maar dan voor subonderwerpen zodat we kunnen zien tot welke hoofdonderwerpen een subonderwerp behoort. Het resultaat is een mooi en snel overzicht tussen de verschillende onderwerpen.
Fig. 36: subgrid resultaat hoofdonderwerp
37
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
D Entiteit activator, partij en dienst Om vanuit Vesta contacten toe te voegen aan een bepaald dossier moeten deze contacten ook worden opgeslagen in het Juridoc systeem. Daarom maken we 3 entiteiten aan voor de verschillende types. Alle 3 de entiteiten hebben als hoofdveld “fullname”. Dit is een combinatie van de naam en voornaam van een persoon of de naam van de organisatie. Deze entiteiten zijn ook enkel zichtbaar onder de instellingen. De entiteiten hebben naast de namen ook velden die de adresgegevens bij houden die uit Vesta worden gehaald. De entiteiten activator en partijen hebben ook extra velden zoals type en subtype. Een type bestaat uit 2 mogelijkheden: een persoon of een organisatie. Een subtype is dan afhankelijk van het type en kan meerdere mogelijkheden zijn: is het een privé of een professionele persoon, gaat het hier om een stadsdienst of een onderwijsinstelling, etc. Dit zijn gegevens die uit Vesta komen. Een contact of organisatie behoort ook tot een categorie. Deze categorieën komen uit een lijst van Juridoc. Een categorie is bijvoorbeeld advocaat, gerechtsdeurwaarder, derden, enz.
Fig. 37: formulier activator
Het formulier ziet ervoor de 3 entiteiten identiek uit op uitzondering van een aantal velden. Via Javascript maak ik bepaalde velden niet zichtbaar gebaseerd op de waarde van de velden type (persoon/organisatie) en subtype (privé/professioneel). Verder in het document ga ik hier dieper op in (zie punt 3.3). Geen enkel veld is aanpasbaar. Dit zijn gegevens die uit Vesta komen en deze mogen niet aangepast worden. Enkel het veld categorie mag aangepast worden. Alle 3 de entiteiten worden gebruikt in het formulier dossier als een subgrid. Zo kan er per dossier een mooi overzicht worden getoond welke contacten of organisaties er gekoppeld zijn aan dat dossier. Ook leggen we bij de 3 entiteiten een N:N relatie met de entiteit dossier.
38
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Fig. 38: subgrids activator/partij/dienst
E Entiteit categorie Een contact of organisatie wordt toegewezen aan een categorie. Dit is een eenvoudige entiteit met als hoofdveld naam. Dit is ook meteen het enige veld.
Fig. 39: lijst categorie
F Entiteit Rechtbank + Rechtbank informatie Bij sommige dossiers moeten er rechtbankgegevens worden ingegeven. Omdat dit ook meerdere kunnen zijn per dossier is zal ook dit via een subgrid worden getoond op het formulier dossier. De entiteit rechtbank is de entiteit die de verschillende rechtbanken zal bijhouden. De naam, omschrijving en adresgegevens zijn velden die hiervoor gebruikt worden. De entiteit rechtbank informatie zal gebruikt worden om rechtbankgegevens toe te voegen aan een dossier. Rechtbank informatie bevat 3 velden: Een lookup veld voor het zoeken van een rechtbank, een veld uitspraak en een veld datum zitting. Beide entiteiten zijn alleen zichtbaar onder instellingen. 39
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Fig. 40: rechtbank gegevens
3.1.3 Aanpassen views Views voor entiteiten zijn aangepaste query’s die data ophalen van een entiteit door gebruik te maken van specifieke filters. Ze kunnen ook bepaalde data op een specifieke manier weergeven. Er zijn verschillende soorten views:
public; advanced find; quick find; lookup.
De public view wordt meestal gebruikt om gewoon lijsten weer te geven van een bepaalde entiteit. Er kunnen meerdere public views zijn per entiteit. Bij de entiteit dossier is er bijvoorbeeld een view dat alle actieve dossiers weergeeft en een view dat alle afgesloten dossiers weergeeft. Ook zijn er views die de dossiers weergeven per dossierbeheerder.
Fig. 41: public views
De advanced find view zijn views die gebruikt worden bij een geavanceerde zoek op een entiteit. Een quick find view is een view die gebruikt wordt wanneer er een snelzoek gebeurd op een entiteit.
Fig. 42: quick find view
40
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Een lookup view wordt gebruikt bij een lookup veld.
Fig. 43: lookup view
Een view kan eenvoudig worden aangepast. Om een view aan te passen gaan we naar de entiteit waarop de view wordt toegepast. In ons voorbeeld de entiteit dossier. Onder de geselecteerde entiteit vinden we een aantal views terug. De meeste zijn standaard views en kunnen ook niet verwijderd worden.
Fig. 44: views voor dossier
De view actieve dossiers is de standaard view. Deze view toont alle dossiers die actief zijn. De view afgesloten dossiers toont alle dossiers waarvan de status op non-actief staat. Per view kan je instellen welke kolommen er als resultaat moeten worden weergegeven en hoe breed de kolommen moeten zijn. Je kunt ook instellen op welke kolom er moet gesorteerd worden. Als laatste is er de filter criteria. De filter criteria zijn argumenten die de resultaten filteren. Het enige verschil tussen de “actieve dossiers view” en de “afgesloten dossiers view” zijn de filter criteria.
Fig. 45: filter criteria actieve dossiers
Fig. 46: filter criteria afgesloten dossiers
41
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
De quick find view van dossiers zoekt op basis van de ingevulde parameter binnen de entiteit dossier of er een record is met deze eigenschappen. De velden waarop de quick find zoekt moeten wel zelf ingesteld worden. We kunnen deze aanpassen door de quick find view te openen en klikken op “Add find columns”. Daarna krijgen we een lijst met al onze velden van de entiteit dossier waarop we kunnen zoeken. Selecteer vervolgens de velden waarop moet worden gezocht. Als er een veld niet tussen staat maar toch in de entiteit zit, dan is de eigenschap “Searchable” niet geactiveerd op dat veld.
Fig. 47: add find column
3.2
SharePoint integratie
Aan een bepaald dossier moeten er kunnen documenten worden gekoppeld. Deze documenten moeten dus ergens kunnen worden opgeslagen. En hier komt SharePoint in het spel. In SharePoint kunnen er bibliotheken en folders worden gecreëerd voor het opslaan van documenten, e-mails, bestanden, etc. Het voordeel van werken binnen een Microsoft omgeving is dat alles eenvoudig aan elkaar te koppelen is. SharePoint integreren met CRM is kinderspel. Eerst en vooral moet er een listcomponent worden geïnstalleerd op de SharePoint site. Deze is af te halen op de Microsoft site. De listcomponent zorgt ervoor dat we in onze CRM-applicatie de SharePoint documenten kunnen beheren met dezelfde look and feel als in SharePoint. Ook zorgt deze component ervoor dat automatisch de juiste folders worden aangemaakt voor de entiteiten en voor de records om documenten in op te slaan. Als de listcomponent is geïnstalleerd kunnen we in ons CRM-systeem onder instellingen kiezen voor Documentenbeheer. Als we dan klikken op Documentenbeheer instellingen, dan opent er een nieuw venster waar we de entiteiten kunnen selecteren die documenten moeten kunnen beheren. In ons geval is dit enkel voor de entiteit dossier. Bij URL vullen we de URL in van onze SharePoint site en klikken we op volgende. De site zal nu gevalideerd worden door CRM die controleert of de listcomponent wel degelijk is geïnstalleerd. Als de URL gevalideerd is kan CRM de juiste structuur aanmaken in de SharePoint site.
Fig. 48: Sharepoint Integratie
42
Matthias Serbruyns
3.3
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Javascript in formulieren
Formulieren in CRM zijn eigenlijk gewone HTML-pagina’s. Deze kunnen aangepast worden met een CSS of met Javascript. Op sommige formulieren moeten er een aantal velden zichtbaar of verborgen zijn op basis van een bepaalde waarde van een veld. Formulieren programmeren zorgt ervoor dat we kunnen communiceren met onze entiteiten formulier door gebruik te maken van Javascript dat wordt uitgevoerd wanneer er een bepaald event geactiveerd wordt. Het voordeel van het gebruik van Javascript in formulieren is dat het onmiddellijk uitgevoerd wordt. Er moet geen data worden verstuurd naar de server of opgehaald worden en daarom geeft het de beste performantie in vele scenario’s. Taken waarvoor veel Javascript gebruikt wordt in CRM zijn:
data validatie; automatisatie; formattering.
Om Javascript te gebruiken moeten we eerst een Javascript web resource toevoegen aan de solution. Hiervoor gaan we naar onze solution en openen we het web resources venster. Daar kunnen we een nieuwe web resource toevoegen. Bij het klikken op nieuw opent er een nieuw venster waar we de informatie over onze web resource kunnen ingeven. Het belangrijkste hier is het type van de web resource. Het type dat we gaan gebruiken voor onze Javascript is Script (JScript). We kunnen een bestaand Javascript bestand opladen of we kunnen ook via de ingebouwde tekst editor zelf een Javascript schrijven.
Fig. 49: toevoegen web resource Javascript
Eenmaal het Javascript bestand toegevoegd kunnen we alle methodes die in dit bestand zitten gaan gebruiken. We keren terug naar de formulier designer van onze entiteit dossier. Bovenaan in de ribbon kiezen we voor “Form properties”. Er opent een nieuw venster waar we verschillende eigenschappen van het formulier kunnen aanpassen. In het tabblad Events kunnen we ons Javascript bestand toevoegen aan het formulier door te klikken op “Add Library”. We krijgen vervolgens een lijst met al onze web resources te zien waaruit we ons Javascript bestand kunnen halen. Na het toevoegen van ons Javascript bestand aan de bibliotheek van het formulier dossier gaat er nog niet veel gebeuren. Eerst moeten we de methodes oproepen in een bepaalde actie op het formulier. De verschillende acties zijn:
form: OnLoad 43
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Bij elk van deze events kunnen we een methode toevoegen die moet worden uitgevoerd bij het activeren van dat event. Om een methode te koppelen aan een formulier event klikken we bij “Event handlers” op “Add”. Vervolgens kiezen ons Javascript bestand en geven we exacte naam in van de functie uit dat Javascript bestand.
Fig. 50: add functie event handler
3.3.1 Formulier dossier Het formulier dossier maakt gebruik van een aantal Javascript methodes. Bij het OnLoad event roep ik de functie “EnableDisableOnLoadOnderwerp” op. Deze functie kijkt bij het opstarten van het formulier of er een waarde is geselecteerd voor het veld hoofdonderwerp. Als dit niet het geval is, dan mag het veld subonderwerp niet bruikbaar zijn. Het veld subonderwerp is namelijk gebaseerd op het veld hoofdonderwerp en kan niet alleen bestaan. Er moet altijd eerst een hoofdonderwerp worden gekozen vooraleer er een subonderwerp wordt gekozen. Het Xrm.Page object voorziet een hiërarchie aan objecten die we kunnen gebruiken om te communiceren met CRM 2011 formulieren. De eerste lijn code haalt het veld “new_dossierhoofdonderwerp” op. Vervolgens kijken we of de waarde van het veld hoofdonderwerp gelijk is aan “null”, of met andere woorden, leeg is. Als het veld leeg is dan zetten we de eigenschap “setDisabled” van het veld “new_dossiersubonderwerp” op “true”. Als het hoofonderwerp niet leeg is, dan mag er wel een subonderwerp kunnen worden geselecteerd.
Fig. 51: Javascript onderwerp OnLoad
Dit wordt enkel uitgevoerd bij het OnLoad event van het formulier. Maar wat als nu het veld hoofdonderwerp veranderd wordt naar een lege waarde of een andere waarde. Dan klopt het veld subonderwerp niet meer want dat is gebaseerd op het vorige hoofonderwerp. Daarom moet er nog een extra methode komen die bij het OnChange event van het veld hoofdonderwerp de waarde van het subonderwerp reset. 44
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
In de eerste 2 lijnen code halen we de velden hoofonderwerp en subonderwerp op. Vervolgens kijken we of het veld hoofdonderwerp veranderd is naar een lege waarde. Als dit zo is, dan maken we de waarde van het veld subonderwerp leeg en zorgen we ervoor dat er geen subonderwerp kan gekozen worden zolang de waarde van het hoofdonderwerp leeg blijft. Als het hoofdonderwerp niet leeg is dan maken we ook de waarde van het subonderwerp leeg omdat dit niet meer overeenstemt met het hoofdonderwerp, maar we laten wel de mogelijkheid om een nieuw subonderwerp te kiezen omdat het hoofdonderwerp niet leeg is.
Fig. 52: Javascript onderwerp OnChange
Het veld dossiernummer is een veld dat samengesteld is uit een aantal parameters: type (1 digit) + . + jaar(4 digits) + - + nummer(4 digits) + / + initialen dossierbeheerder(4digits), bv. C.2012-1234/CCLA; De parameters type en dossierbeheerder kunnen altijd na het aanmaken van een dossier worden gewijzigd. Als 1 van deze parameters wijzigt moet ook het dossiernummer wijzigen. Daarom wordt er bij het OnSave event van het formulier dossier een methode opgeroepen die altijd het dossiernummer aanpast naar de geselecteerde parameters type en dossierbeheerder. Ook als bijvoorbeeld het type of de dossierbeheerder niet wijzigt en er wordt op save geklikt dan zal het toch altijd het dossiernummer updaten maar het resultaat zal het zelfde zijn als het vorige dossiernummer. Een voorbeeld. We hebben een dossier met als dossiernummer “C.2013-0006/MASE”. Het type van het dossier is “C” en de dossierbeheerder zijn initialen zijn “MASE”. Als we het type van het dossier wijzigen naar “A” en op save klikken, dan zal het dossiernummer wijzigen naar “A.20130006/MASE”. Als we daarna ook nog eens de dossierbeheerder veranderen naar “PIDE” en opnieuw op save klikken dan gaat het dossiernummer wijzigen naar “A.2013-0006/PIDE”. Het is ook mogelijk om beiden tegelijkertijd te wijzigen.
Fig. 53: Update dossiernummer OnSave form
45
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Eerst halen we het huidige dossiernummer op. Vervolgens kijken we of het dossiernummer verschillend is van “null”. Als het dossiernummer leeg is, dan wil dit zeggen dat het hier om een nieuw dossier gaat dat nog moet worden aangemaakt. Een nieuw dossier krijgt zijn dossiernummer pas toegewezen als het is opgeslagen voor de eerste keer. Na dat het is opgeslagen wordt er via een plug-in een dossiernummer toegekend. Als het dossiernummer niet leeg is, dan halen we de waarden van het type en het dossiernummer op. Via een substring neem ik enkel het middenstuk van het dossiernummer (.2013-0006/) omdat dit toch nooit verandert. Vervolgens plak ik de parameters van de nieuwe waarden aan het middenstuk op hun overeenkomstige plaats. De eigenschap “setSubmitMode” veranderen naar “always” is nodig zodat de nieuwe data opgeslagen wordt. Als laatste stap zetten we de waarde van het dossiernummer naar de nieuwe waarde.
3.3.2 Formulier activator en partij De entiteiten activator en partij zijn eigenlijk zo goed als identiek. Ze kunnen beiden records bevatten die een persoon of een organisatie kunnen zijn. Omdat die verschillende records elk andere velden moeten kunnen tonen gebruiken we ook hier een Javascript functie om een aantal velden zicht- of onzichtbaar te maken op basis van een aantal waarden uit andere velden. Een organisatie kan bijvoorbeeld geen geboortedatum of rijksregisternummer hebben. En een persoon met subtype “privé” moet geen veld “organisatie” hebben. In ons formulier gaan we werken met secties. Secties zijn een soort van containers die we kunnen beheren. We kunnen een container op onzichtbaar zetten en alle velden die zich in die container bevinden zullen dan onzichtbaar zijn. Eerst maken we een aantal secties aan in het tabblad “Algemeen” binnen de formulieren activator en partij. De eerste sectie is de sectie “General”. Deze sectie zal altijd getoond worden voor welk record dan ook. Hierin kunnen we de velden tonen die zowel gelden voor een persoon als voor een organisatie. De volgende sectie is “Contact”. In deze sectie steek ik alle gegevens die met een record persoon te maken hebben en niets met een organisatie. Een andere sectie is de sectie “Adres”. Deze sectie is voor alle records zichtbaar. We geven ook onze secties een naam zodat ze gemakkelijk kunnen worden aangesproken in code.
Fig. 54: werken met secties
Ik gebruik een andere Javascript bestand voor deze formulieren dus moet ik dit Javascript bestand ook weer toevoegen aan de bibliotheek van het formulier. In het OnLoad event roep ik de methode “enabledisable” op. Eerst haal ik de waarde van het type van de record op. Als het type gelijk is aan “organisatie” dan verbergen we de secties “Contact” en “Organisatie”. De sectie “Organisatie” wordt enkel gebruikt voor een record van het type 46
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
professionele persoon. Als het type een persoon is dan controleren we het subtype. Als het een privé persoon is dan verbergen we de sectie “Organisatie”. Is het een professionele persoon dan verbergen we het veld van het rijksregisternummer.
Fig. 55: enabledisable activator/partij velden
3.4
Plug-ins
Sommige velden in het CRM-systeem moeten automatisch worden ingevuld of moeten op basis van andere parameters worden samengesteld. Deze zaken kunnen worden opgelost door gebruik te maken van plug-ins. Een plug-in is een aangepast stukje logica (code) die kan geïntegreerd worden met CRM 2011. Ze behandelen events die geactiveerd zijn door CRM zoals het opslaan van een entiteit. Plug-ins zijn aangepaste klassen die gebruik maken van de IPlugin interface. Om een plug-in te schrijven voor CRM 2011 installeren we eerst de CRM Developer Toolkit. Na de installatie van de Toolkit kunnen in Visual Studio verbinden met onze CRM organisatie.
Fig. 56: Visual studio verbinden CRM
In het CRM explorer venster krijgen we dan onze solution te zien met al onze entiteiten.
47
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Fig. 57: Entiteiten CRM Explorer
Eerst maken we een nieuw Visual Studio project aan van het type “Plug-in Library”. We gaan een plug-in maken voor de entiteit dossier. We klappen het tab item entiteiten open en klikken rechtermuisknop op de entiteit dossier en kiezen voor “create plug-in”. Er opent een nieuw venster voor de eigenschappen te selecteren van de plug-in. We maken een plug-in die zal worden uitgevoerd nadat er een nieuw dossier is aangemaakt. Nadat het dossier is aangemaakt gaat de plugin via een aantal parameters het dossiernummer opstellen. Bij “Message” kiezen we voor “Create”. “Run in Context” wil zeggen bij welke gebruikers we de plug-in mogen uitvoeren. We kiezen voor alle gebruikers, “Calling User”. De waarde bij “Pipeline Stage” geeft aan wanneer de plug-in moet uitgevoerd worden. Er zijn 3 mogelijkheden:
pre-validation; pre-operation; post-operation.
Pre-validation gebeurt voor de hoofdoperatie. Plug-ins met deze eigenschap kunnen worden uitgevoerd buiten de database transactie. Pre-operation gebeurt ook voor de hoofdoperatie maar deze plug-in wordt wel uitgevoerd binnen de database transactie. Als laatste is er de postoperation. Deze plug-in wordt uitgevoerd na dat de hoofdoperatie is uitgevoerd en worden uitgevoerd binnen de database transactie. Onze plug-in mag pas worden uitgevoerd na dat alle data is opgeslagen in de database en kiezen dus voor post-operation. Vervolgens klikken we op OK. De CRM Developer Toolkit maakt voor ons al de klassen “Plugin” en “PostDossierCreate” aan. De klasse “PostDossierCreate” erft over van de klasse “Plugin”. Aan de klasse “Plugin” moeten we zelf niet komen. In de klasse “PostDossierCreate” komt de business logica waar we onze actie gaan uitvoeren.
Fig. 58: create plug-in
48
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
In de “ExecutePostDossierCreate” methode, die automatisch werd aangemaakt, schrijven we onze functie die een bepaalde actie moet uitvoeren. Het eerste wat we doen is de context ophalen van de plug-in en van onze organisatie.
Fig. 59: Ophalen context
Via de “crmsvcutil.exe” tool heb ik ook een klasse gegenereerd dat alle data contexten, objecten en entiteiten ophaalt van mijn de organisatie Juridoc. Dit stelt mij in staat om entiteiten makkelijker te declareren en is ook performanter. Dankzij de gegenereerde klasse kan ik entiteiten declareren in “Early Bound”. Via “Early Boud” is het makkelijker coderen omdat er Intellisense is voor alle entiteiten die “Early Bound” zijn. Ook is het daadwerkelijk sneller omdat de code niet meer moet worden geconverteerd naar het echte type. Early Bound
Late Bound
new_dossier dossiers = new_dossier()
entity dossier = new entity(“new_dossier”)
sneller: geen conversie nodig
trager: conversie naar juiste type
intellisense
geen intellisense
Tabel 12: early bound vs late bound
Via de code in fig. 59 halen we uit alle dossiers, waar het veld “jaar creatie” gelijk is aan de huidige dag en geordend op het nummer in dalende volgorde, de eerste record op. Het resultaat is als volgt: Dossier nummer 2 (dit is de record die we terug krijgen) Dossier nummer 1 Dossier nummer null Tabel 13: resultaat filter jaar creatie en nummer
Het hoogste nummer staat bovenaan en is ook de record die we nemen. Dit is het laatste dossier dat is toegevoegd aan Juridoc na het dossier dat deze plugin heeft geactiveerd. Het dossier met nummer null staat als laatst. Dit is het dossier dat net is toegevoegd en nog geen nummer heeft toegekend gekregen.
Fig. 60: code ophalen laatste nummer
49
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
We behandelen de opgehaalde record als een lijst, ook al is het maar 1 record dat er zal in zitten. We controleren of de lijst een waarde bevat. Als de lijst leeg is dan wil dit zeggen dat er geen dossier gevonden is waar het jaar van creatie gelijk is aan het huidige jaar en waar het een nummer heeft toegekend gekregen. Als dit zo is, dan is het nieuw toegevoegde dossier het eerste dossier in een nieuw jaar, of zit er gewoon nog geen enkel dossier in het systeem. Het nummer van het nieuwe dossier zal dan 1 zijn. Als de lijst niet leeg is, dan gebruiken we het record dat we hebben opgehaald met het hoogste nummer. We nemen het nummer van dat record en tellen dat op met 1.
Fig. 61: controle nummer
Fig. 62: ophalen inputparameters
De volgende stap is om de data op te halen van de record deze plug-in heeft geactiveerd en dat zojuist werd aangemaakt. Dit kunnen we ophalen via de InputParameters eigenschap. De InputParameters bevatten de data dat zich in het request bericht bevindt dat momenteel wordt uitgevoerd. Het “Target” is van het type “Entity”. Omdat ik weet dat het record waarop de operatie wordt uitgevoerd van het type “new_dossier” is, converteer ik de “Target” entiteit naar het type “new_dossier”. Hierna halen we de gegevens op van de dossierbeheerder. Omdat dossierbeheerder een referentie is naar een dossier moeten we een extra zoek doen naar die dossierbeheerder om de informatie zoals het veld “initialen” te kunnen ophalen.
Fig. 63: ophalen dossierbeheerder
De laatste stap is om het alle opgehaalde parameters samen te gooien en aan elkaar te plakken. Het type zit in de data van het “Target”. Het resultaat is dan uiteindelijk: Type . jaarcreatie-nummer/initialen beheerder A.2013-0001/MASE
50
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Fig. 64: samenstellen dossiernummer
Ik heb ook een plug-in ontwikkeld voor de entiteit dossierbeheerder. Deze plug-in gaat na dat er een nieuwe dossierbeheerder record is opgeslagen de eerste 2 letters van naam en voornaam nemen en deze samensmelten tot de initialen.
Fig. 65: initialen dossierbeheerder
Ook heb ik voorzien dat er automatisch een view wordt aangemaakt die enkel de dossiers toont die behoren aan die dossierbeheerder. Deze view wordt aangemaakt in dezelfde plug-in die de initialen samenstelt van de dossierbeheerder. Views bestaan eigenlijk uit 2 XML’s: een XML voor de lay-out en een XML voor de query. De eerste stap is om de entiteit type code op te halen van de entiteit dossier. Dit is meta data van een entiteit. Dit nummer is nodig omdat de lay-out XML dit nummer gebruikt om na te gaan over welke entiteit het hier gaat. Elke entiteit heeft een uniek type code. Oorspronkelijk zette ik het nummer van de entiteit “new_dossier” er manueel in maar als ik de solution exporteerde naar een andere organisatie dan kreeg de entiteit “new_dossier” een ander type code en klopte de view niet meer.
Fig. 66: ophalen entity type code
De lay-out XML zorgt ervoor welke kolommen er moeten zichtbaar zijn. De belangrijkste onderdelen zijn “object” en de cel namen. Het object is het opgehaalde entiteit type code dat ik er via een parameter heb ingestoken. De cel namen moeten gelijk zijn aan de namen van de velden van de entiteit.
Fig. 67: lay-out XML
51
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
De 2de XML, de fetch XML, is de XML die de query verzorgt en dus de gewenste data gaat ophalen. De attributen die we gebruiken om te zoeken moeten net dezelfde naam hebben als in de entiteit.
Fig. 68: attributen fetch XML
We kunnen ook de resultaten sorteren. We sorteren de dossiers op datum van aanmaak en op nummer.
Fig. 69: sorteer fetch XML
Als laatste is er de filter criteria. Dit zijn parameters waarop moet gefilterd worden.
Fig. 70: filter criteria fetch XML
We filteren op de status van het dossier en op de dossierbeheerder. De view mag alleen dossiers tonen die actief zijn en enkel van de dossierbeheerder die we net hebben toegevoegd. De parameters van de dossierbeheerder haal ik uit de InputParameters “Target”. Ik filter dus op initialen van de dossierbeheerder als op de ID van de dossierbeheerder.
Fig. 71: parameters dossierbeheerder
De laatste stap is om deze view op te slaan. Een aangepaste view wordt ook wel een SavedQuery genoemd. We geven onze view een naam met de initialen van de dossierbeheerder in. De “ReturnedTypeCode” eigenschap is de naam van de entiteit die getoond zal worden in de view.
Fig. 72: Opslaan SavedQuery
52
Matthias Serbruyns
3.5
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Vesta integratie
De taak waar de meeste tijd is ingekropen is de integratie met Vesta. Het moest mogelijk zijn om vanuit het Juridoc systeem een scherm te openen dat de gebruiker in staat stelt om te zoeken naar contacten of organisaties binnen Vesta en deze dan toe te voegen aan Juridoc om uiteindelijk gekoppeld te worden aan een dossier. Ook de contacten en organisaties die al reeds eerder zijn opgehaald uit Vesta en zijn toegevoegd aan Juridoc moeten worden getoond. Dus het moet ook mogelijk zijn om een contact te selecteren die er al reeds in zit. Een dossier formulier bevat 3 subgrids die contactgegevens kunnen bevatten. De eerst subgrid is Activator. Hierin komen de contactgegevens van een persoon of organisatie die ervoor gezorgd heeft dat dit dossier is aangemaakt. Een 2de subgrid is Partij. In de subgrid Partij komen alle partijen die betrokken zijn bij het dossier. Dit kan gaan van organisaties tot advocaten tot derden. Een laatste subgrid is Dienst. Hier kunnen we bijvoorbeeld betrokken stadsdiensten aan toevoegen. Als een van deze subgrids op het formulier is geselecteerd, is er een mogelijkheid om via de knop op de ribbon, “Voeg X toe”, het zoekscherm te openen. Afhankelijk van de welke subgrid is geselecteerd, zal een parameter met de naam van de entiteit van die subgrid meegegeven worden. Deze parameter hebben we nodig om contacten op te zoeken in Juridoc en om de juiste subgrid op het formulier dossier te hernieuwen. Vervolgens kan een contact worden opgezocht en worden toegevoegd aan die subgrid en is het ook onmiddellijk gekoppeld aan het dossier.
3.5.1 Start De eerste stap is om een nieuw Visual Studio project aan te maken. We kiezen hiervoor een Silverlight-applicatie. Vervolgens voeg ik 2 service references toe. De eerste is de Vesta service. We vullen het adres in waar de service zich bevindt, geven deze de naam “VestaDataMaster” en klikken op OK. Deze web service verbind ons met het Vesta systeem en is een SOAP web service. De volgende Service Reference is “IOrganizationService” web service. Deze web service voorziet ons van alle objecten en berichten die gebruikt worden in de Organization service van CRM en zorgt voor de verbinding met ons Juridoc systeem. Dit is ook een SOAP web service. In ons CRMsysteem vinden we onder Ontwikkelaar Bronnen (Instellingen, Aanpassingen) verschillende Service Endpoints van onze organisatie. We voegen in ons Silverlight project de Organization Service toe en geven het de naam “CrmSdk”.
Fig. 73: Sevice endpoints
Er moeten ook een aantal extra klassen worden toegevoegd aan het project om gebruik te kunnen maken van de Organization Service in Silverlight. We voegen de SilverlightExtensionMethods klasse toe aan ons project. Deze is te vinden op MSDN. Vervolgens passen we het bestand “Reference.cs” aan van de Organization Service. Dit bestand wordt gegeneerd als er een Service Reference wordt toegevoegd. In het bestand vervangen we de regel “System.Collections.Generic.KeyValuePair<” met “KeyValuePair<”. Dit zal de referentie wijzigen van “System.Collections.Generic.KeyValuePair” naar de “keyValuePair” beschreven in de nieuwe SilverlightExtensionMethods klasse. We voegen ook een klasse SilverlightUtility toe. Deze klasse haalt de informatie van de organisatie op zoals de URL van de organisatie, de URL van de organisatie service, de context van de organisatie enz.
53
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
3.5.2 Design Om zo weinig mogelijk klikacties nodig te hebben om een contact op te halen uit Vesta heb ik besloten om 1 venster te gebruiken met daarop een tab control. Op de Mainpage.xaml staat een tab control met 2 tab items: personen en organisaties. De reden hiervoor is omdat het anders te verwarrend zou zijn om alles op 1 plaats te tonen: een mix van personen en organisaties zou te veel verwarring met zich meebrengen.
Fig. 74: mainpage.xaml
Als het tab item personen is aangeklikt dan wordt de pagina Contacten.xaml getoond. Als het tab item organisaties is aangeklikt wordt er gesurft naar Organisatie.xaml. De pagina’s personen en organisaties zijn gelijkaardig opgebouwd. Behalve de zoekvelden die verschillen zijn ze nagenoeg identiek. Om alle verschillende velden en resultaten op 1 pagina te krijgen maak ik gebruik van een accordion control. De control is een Silverlight uitbreiding die moet gedownload worden. De control bestaat uit 3 accordion items: Zoeken, Resultaten uit Juridoc en resultaten uit Vesta.
Fig. 75: tab control
In het accordion item “Zoeken” zitten alle zoekvelden. Elk zoek veld heeft een binding. Via binding kunnen we eenvoudig de ingevulde parameter ophalen en gebruiken.
Fig. 76 voorbeeld zoek veld
In het accordion item “Resultaten uit Juridoc” zit een datagrid die de resultaten zal weergeven die gevonden zijn binnen Juridoc. Ook zit er een combobox in die de waarden 5, 10, 20 en 50 bevat. Deze waarden geven aan hoeveel items er op 1 pagina mogen verschijnen in de datagrid.
54
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Fig. 77: datagrid xaml
De datagrid is gebonden aan een “PagedCollectionView”. Dit element zorgt ervoor dat de items kunnen weergegeven worden op meerdere pagina’s in een datagrid.
Fig. 78: datagrid
De datagrid is gebonden aan een “PagedCollectionView”. Dit element zorgt ervoor dat de items kunnen weergegeven worden op meerdere pagina’s in een datagrid. De “PagedCollectionView” wordt opgevuld met een “ObservableCollection” van de klasse “DisplayContact” of “DisplayOrganisatie” die de resultaten bevat van de zoekopdracht. De kolommen van de datagrid zijn gebonden aan een eigenschap van die “DisplayContact”. Het geselecteerde item wordt via binding opgeslagen in het object “SelectedJuridoc” van het type “DisplayContact” of “DisplayOrganisatie”.
Fig. 79: datagrid xaml
Onderaan de datagrid plaatsen we ook een datapager control. Deze control stelt ons in staat om de resultaten weer te geven op meerdere pagina’s. Zo kan de eindgebruiker vlot zoeken tussen de honderden resultaten door gebruik te maken van de pagina’s en via de combobox “aantal per pagina” kan de eindgebruiker zelf kiezen hoeveel resultaten hij per pagina zichtbaar wil zien.
55
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Fig. 80: datapager
Als laatste is er ook een progressbar control. Deze control geeft de status van de zoekopdracht weer. Als een zoekopdracht nog niet is afgelopen dan zal de progressbar dit aangeven dat de zoekopdracht nog bezig is. Dit is gekoppeld aan een boolean die in de code-behind op “true” of op “false” wordt gezet naargelang de status van de zoekopdracht. Via een converter zetten we deze control zijn visibility op “true” of “false.
Fig. 81: progressbar xaml
Onder het accordion item “Resultaten uit Vesta” zitten er 2 datagrids. De eerst datagrid zijn de resultaten uit Vesta. De 2de datagrid toont alle adressen van de geselecteerde contact of organisatie uit de eerste datagrid. Zo kan de eindgebruiker onmiddellijk zien of een persoon meerdere adressen heeft en een ander adres selecteren om toe te voegen aan Juridoc. Onderaan het scherm zijn er 3 knoppen en een combobox. Een knop om te annuleren, een knop om een nieuw contact toe te voegen in Vesta en een knop om de geselecteerde contact uit de resultaten lijst toe te voegen aan Juridoc. Als er een contact niet in Vesta zit, dan kan de eindgebruiker via de knop “Nieuw in Vesta” een CRM-formulier uit Vesta openen om een nieuwe contactpersoon toe te voegen aan Vesta. De combobox bevat een lijst met categorieën die uit het Juridoc systeem komen. Om een contact te kunnen toevoegen moet eerst een contact geselecteerd zijn uit een datagrid en er moet een categorie zijn geselecteerd.
Fig. 82: knoppen scherm
3.5.3 Klassen A DisplayContact en DisplayOrganisatie De “DisplayContact” klasse wordt gebruikt om de resultaten van de zoekopdracht naar personen en organisaties op te slaan die uit Juridoc komen. De klasse erft over van “INotifyPropertyChanged”. Dit zorgt ervoor dat er een soort van melding is wanneer er een eigenschap van waarde is veranderd. Omdat we overerven van “INotifyPropertyChanged” moet er ook een “PropertyChangedEventHandler” zijn die het event wanneer er een waarde veranderd is afhandelt.
56
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Matthias Serbruyns
Fig. 83: klasse DisplayContact
De klasse bestaat uit verschillende eigenschappen met verschillende types: Naam
Type
Id
Guid
Naam
String
Voornaam
String
Geboortedatum
DateTime
Winlbv
String
Adresstraat
String
Adresnummer
String
Adrespostcode
String
Adresgemeente
String
Type
String
Tabel 14: klasse DisplayContact eigenschappen
De “DisplayOrganisatie” klasse wordt gebruikt om de resultaten van de zoekopdracht naar organisaties op te slaan. De klasse erft ook over van “INotifyPropertyChanged”. Naam
Type
Id
Guid
Naam
String
Adresstraat
String
Adresnummer
String
Adrespostcode
String
Adresgemeente
string
Tabel 15: klasse DisplayOrganisatie eigenschappen
57
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Matthias Serbruyns
B Klasse JsonContact en JsonOrganisatie Sommige zoekopdrachten uit Vesta kunnen soms tot 1000 records als resultaat terugsturen. De Vesta web service heeft gelukkig een methode om het resultaat als JSON terug te sturen. Het formaat van JSON ziet er als volgt uit:
Fig. 84: resultaat json
Om deze data te kunnen deserializeren naar een object moest het object er net hetzelfde uitzien als de JSON. De JSON geeft 4 velden terug. Total en Records hebben dezelfde waarde: het aantal records dat het resultaat bevat. Rows bevat de verzameling van resultaten. Dus in de klasse deelde ik dit op dezelfde manier in. Ik definieerde 3 string eigenschappen en een eigenschap dat bestond uit een verzameling objecten met als type Contact. De eigenschappen van de klasse Contact moeten allemaal net dezelfde naam als die uit de JSON hebben.
Fig. 85: JSONContact
De JsonOrganisaties zag er net hetzelfde uit behalve dat het daar een verzameling van Organisaties was in plaats van Contacten. C Klasse Addressen Er is ook een klasse voor de extra adressen op te slaan die behoren tot een persoon of organisatie. Een adres heeft altijd een bepaald type: een domicilieadres, een vestigingsadres, etc. Naam
Type
Id
Guid
Adresstraat
String
Adresnummer
String
Adrespostcode
String 58
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Matthias Serbruyns
Adresgemeente
String
TypeAdres
String
Tabel 16: klasse addressen
D Klasse Categorie In de klasse Categorie sla ik de categorieën op die afkomstig zijn van Juridoc uit de entiteit Categorieën die we eerder hebben aangemaakt. Deze klasse bevat 2 eigenschappen: een ID van het type Guid en een naam van het type string.
Fig. 86: klasse Categorie
3.5.4 Code Zoals ik al eerder vermeld heb bestaat het zoekscherm uit 2 tabbladen: een voor de personen en een voor de organisaties. Dit zijn 2 afzonderlijk XAML pagina’s en moeten dus ook elk afzonderlijk gecodeerd worden. Ik ga enkel de zoekfuncties voor de personen verduidelijken omdat de zoekfuncties van organisaties heel erg gelijkaardig zijn op een paar details na. A Zoeken binnen Vesta Het eerste wat we voorzien hebben van functionaliteit is het zoeken naar personen in Vesta en deze weergeven in een datagrid. De resultaten zullen worden opgeslagen in een ObservableCollection van het type Contact.
Fig. 87: ObservableCollection
59
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Ook vullen we de Security gegevens in die nodig zijn om gebruik te maken van de Vesta web service. Security is een referentie afkomstig van de Vesta web service.
Fig. 88: Security Vesta
De methode “EncodeBase64” is een herbruikbare methode die een string omzet naar Base64.
Fig. 89: Base64 converter
Vervolgens creëren we onze zoekfunctie. Eerst maken we een nieuwe instantie aan van de Vesta client. De IsLoading variabele is de variabele die gebonden is aan de progressbar. Als deze op “true” springt dan gaat de progressbar zichtbaar worden voor de eindgebruiker en ziet die dat de zoekactie is begonnen. Vervolgens stellen we onze filters op. Dit zijn criteria waarop moeten worden gezocht in Vesta.
Fig. 90: Zoekfunctie
Via de ContructFilter methode vullen we de filters op. Deze methode geeft als resultaat een verzameling van FilterRules terug.
Fig. 91: construct filter
60
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
In de ConstructFilter methode controleren we de waarde van de ingevulde zoekvelden die via binding gebonden zijn aan een object. Als de waarde van het zoekveld leeg is of enkel witruimtes bevat dan moet er niet worden gezocht op dit veld en voegen we geen nieuwe FilterRule toe. Als het veld daarentegen wel is ingevuld voegen we een nieuwe FilterRule toe. De FilterRule is ook een referentie van de Vesta web service. De FilterRule heeft 5 eigenschappen:
field: het veld in Vesta waarin moet worden gezocht; op: equals of contains; data: de parameter; type: welke type is de parameter; linkedentity: Voor zoeken op velden met relaties.
Als het zoekveld naam dus niet leeg is, dan gaan we in Vesta zoeken op het veld “lastname” waar de het veld “lastname” de data bevat uit het zoekveld. Via dezelfde manier zoeken we ook op voornaam, adresgegevens, etc. Om enkel professionele personen te vinden is er ook een checkbox voorzien. Deze kunnen we aanof uitklikken. Als de checkbox is aangevinkt dan zoekt de web service enkel op professionele personen. We gebruiken daarvoor volgende filter:
Fig. 92: filter professionele personen
Als de checkbox op “true” staat of met andere woorden is aangevinkt, dan mag de Veste web service enkel de personen terugsturen waar het veld “ves_type” gelijk is aan “true”. Het veld “ves_type” in Vesta is van het type “TwoOption”. Dit wil zeggen dat er maar 2 mogelijkheden kunnen zijn: false (privé persoon) of true (professionele persoon). Ook is het mogelijk om personen te zoeken die gekoppeld zijn aan een organisatie. Organisatie is een relatieveld binnen een personenrecord. Om op dit veld te kunnen zoeken maken we gebruik van de eigenschap LinkedEntity.
Fig. 93: filter organisatie
Om de waarde van de eigenschap LinkedEntity beter te begrijpen toon ik eerst hoe de Vesta web service omspringt met de LinkedEntity die het ontvangt van de client.
61
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Matthias Serbruyns
Fig. 94: Vesta service linkedentity
De Vesta web service splitst de ontvangen string op basis van het “;” karakter en vult deze dan in een variabele. Dus in ons geval is dit: entityFrom
contact
attributeFrom
Parentcustomer (vb accountID = 5)
entityTo
account
attributeFrom
Accountid (vb ID = 5)
Tabel 17: LinkedEntity tabel
De entityFrom is de naam van de hoofdentiteit. Het attributeFrom is de naam van het attribuut of veld op de hoofdentiteit dat de relatie bevat met de andere entiteit. Dit is het ID van een record van een andere entiteit. EntityTo is de naam van de gerelateerde entiteit. Als laatste is het attributeFrom de naam van het attribuut die zich op de gerelateerde entiteit bevindt. Als we de relatie hebben gedefinieerd kunnen we binnen die gerelateerde entiteit zoeken naar de naam van een organisatie en zal de Vesta web service enkel de personen terug sturen die gekoppeld zijn aan een organisatie met die naam.
Fig. 95: uitvoeren Search
Nadat we onze filters hebben gedefinieerd kunnen we de zoek starten. We initialiseren een nieuw event dat zal geactiveerd worden als de web service klaar is om de resultaten terug te sturen naar de client. Vervolgens starten we de echt zoek die 3 parameters vereist: de security credentials, de naam van de entiteit waar in moet gezocht worden en de filters. Als de Vesta web service klaar is met zoeken en de resultaten heeft dan gaat de service een antwoord terug sturen naar de client en gaat het event “SearchContactenJsnoComplete” geactiveerd worden.
Fig. 96: antwoord Vesta web service
In het event maken we eerst de verzameling van resultaten van een eventueel vorige zoekopdracht leeg zodat oude resultaten die niet meer relevant zijn verwijderd worden. Vervolgens 62
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
maken we gebruik van het framework JSON.Net om de ontvangen JSON om te zetten naar het juiste object. We stellen de waarde van de nu lege “VestaList” gelijk aan de verzameling van records die zich in de eigenschap “Rows” bevinden. Na deserialisatie ziet ons object JsonContact er als volgt uit:
Fig. 97: resultaat deserializatie
De eigenschap “Rows” bevat al onze data in een verzameling. Deze verzameling stellen we gelijk aan de lijst VestaList. De laatste stap is om de progressbar te doen laten verdwijnen aangezien onze zoekopdracht compleet is en om de VestaList in onze datagrid te krijgen.
Fig. 98: disable progressbar en koppel vestalist
Onze datagrid is gekoppeld aan een PagedCollectionView en niet rechtstreeks aan de “VestaList”. Deze stelt ons in staat om de resultaten te kunnen groeperen, filteren, sorteren en navigeren via pagina’s.
Fig. 99: PagedCollectionView eigenschap
Het resultaat is dat we op vrij snelle manier duizenden contactpersonen kunnen ophalen uit Vesta.
Fig. 100: resultaat Vesta
63
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
B Meerdere adressen uit Vesta Een contact heeft altijd een domicilieadres. Maar een contact kan ook meerdere adressen hebben. Deze moeten ook opgehaald worden en kunnen toegevoegd worden aan Juridoc. De adressen worden in een datagrid “meerdere adressen” getoond die zich onder de opgehaalde contacten uit Vesta bevind. Als een contact geselecteerd word dan voeren we een actie uit die de andere adressen van die contact ophaalt en in de datagrid “meerdere adressen” opvult.
Fig. 101: getalleadressen
Omdat Silverlight soms moeilijk doet en het event SelectionChanged om welke reden dan ook toch uitvoert terwijl er geen selectie is gebeurd, heb ik een extra if-clausule gebruikt. De eerst ifclausule gaat na of alle contacten zijn geladen en ingevuld in de datagrid. Als dit zo is dan controleert hij of er wel degelijk een contact geselecteerd is in de datagrid. Als er een contact geselecteerd is dan mag de functie die de adressen ophaalt worden uitgevoerd. De adressen ophalen gebeurt op eenzelfde manier als een contact ophalen namelijk via filters. De adressen van een contact komen uit een andere entiteit namelijk “ves_meeradressen”. Een record uit die entiteit heeft een veld “ves_persoonid” dat gerelateerd is aan een contact.
Fig. 102: filter adressen
Op basis van het ID van de geselecteerde contact uit de datagrid halen we de adressen die gerelateerd zijn aan die contactpersoon.
Fig. 103: resultaat adressen contact
64
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
C Zoeken binnen Juridoc Contactpersonen die al een keer zijn opgehaald uit Vesta en zijn toegevoegd aan een dossier zitten vanaf dan ook opgeslagen in Juridoc. Dus als er een contact moet worden toegevoegd aan een dossier, dan moeten deze ook uit de Juridoc kunnen gehaald worden. Deze resultaten worden opgeslagen in een andere datagrid dan de resultaten uit Vesta. Bij het klikken op de knop zoeken gaat er simultaan gezocht worden naar resultaten binnen Vesta en Juridoc. Eerst initialiseren we een nieuw object dat de verzameling van resultaten uit Juridoc gaat bijhouden.
Fig. 104: Juridoclist
Vervolgens stellen we een OrganizationRequest op. Dit is een request die verstuurd wordt naar de Organization Service om data op te halen of toe te voegen. De RequestName is “RetrieveMultiple”. Zo weet de service over welke request het gaat. We willen dus informatie ophalen. De request heeft een query nodig om te kunnen zoeken.
Fig. 105: query juridoc
De EntityName in onze query is de naam van de entiteit waarin we willen zoeken. De ColumnSet zijn de kolommen die we willen terugkrijgen als resultaat. Net als bij de Vesta web service moet er ook hier een verzameling van filters zijn om te kunnen zoeken op bepaalde velden. De code ziet er een beetje anders uit dan bij de Vesta web service maar het principe is hetzelfde. De AttributeName is de naam van het veld waarop moet gezocht worden. De Operator is de vergelijking die moet gebeuren (contains, like, equals, enz.). De value is de waarde die moet gezocht worden in het veld dat werd ingegeven bij AttributeName.
65
Matthias Serbruyns
Juridoc De ontwikkeling van een dossierbeheersysteem in CRM
Fig. 106: filterexpression Juridoc
Nadat we onze request hebben gedefinieerd kunnen we deze sturen naar onze Organization Service. We zetten ook de progressbar op “true”.
Fig. 107: BeginExecute Juridoc
De parameter “getJuridocContacten.getContacten(selecedSubgrid, FilterParameters)” is een functie die de request opstelt en dan terugstuurt. Er is ook een AsyncCallback. Dit event zal geactiveerd worden wanneer de Organization Service een antwoord met de resultaten terugstuurt naar de client. In het “SearchJuridocContactenDone” event ontvangen we het antwoord van de service en steken het in een variabele van het type OrganizationResponse en sluiten we de execute af. Uit de response kunnen we een EntityCollection halen dat de resultaten bevat. Dit is een ObservableCollection van het type Entity. Vervolgens gaan we de datagrid opvullen met de data.
Fig. 108: Response Juridoc
In de PopulateGrid methode vullen we de datagrid op met de resultaten. We maken eerst de lijst met eventueel vorige resultaten leeg zodat er geen oude en niet relevante resultaten blijven hangen. Vervolgens overlopen we de collectie met resultaten en steken we elk item in een DisplayContact object. Via GetAttributeValue
