Systeemdocumentatie: verschil tussen versies

Uit ZaaksysteemWiki
Ga naar: navigatie, zoeken
(Nieuwe pagina aangemaakt met '==')
 
Regel 1: Regel 1:
==
+
__TOC__
 +
 
 +
== De zaaktypecatalogus+ ==
 +
=== Uitleg ===
 +
 
 +
[[Bestand:wiki_ztc+.png|thumbnail|left]]
 +
ghgh
 +
* Zaaktypen
 +
 
 +
<br clear="all" />
 +
 
 +
=== Kenmerken ===
 +
 
 +
Kenmerken zijn informatieobjecten die centraal worden opgeslagen, maar meervoudig kunnen worden gebruikt. Het verschil met een kenmerk uit de Gemma ZTC is dat ze niet voor alle zaaktypen gelden. Een voorbeeld. Elke zaak heeft registratiedatum of een zaaknummer, maar niet elke zaak heeft het kenmerk 'Meldingencategorie'. Dit is een specifiek kenmerk voor het zaaktype Melding Openbare Ruimte. Desondanks zijn er kenmerken die meervoudig te gebruiken zijn, zoals het kenmerk 'subsidiebedrag'.
 +
 
 +
[[Bestand:wiki_kenmerken1.png|thumbnail|right]]
 +
 
 +
Wanneer een kenmerk wordet aangemaakt dat moet er een <b>invoertype</b> worden bepaald voor dit kenmerk. Het invoertype geeft aan wat het zaaksysteem moet doen wanneer dit kenmerk wordt gebruikt bij een zaaktype. Voorbeelden van invoertypen zijn:
 +
* Tekstveld
 +
* Keuzemenu (dropdown)
 +
* Meervoudige keuze (Checkbox)
 +
* Maps (Google prikkaart)
 +
* Valuta
 +
* Etc.
 +
 
 +
Tevens wordt er voor elk kenmerk direct een <b>'magic sting'</b> aangemaakt. Dit is een variable die het systeem voor verschillende doeleinden gebruikt. Deze kunnen bijvoorbeeld gebruikt worden in de sjablonen en de berichten die naar aanvragers worden verstuurd. Uiteraard vult het zaaksysteem dan de inhoudt in van het betreffende kenmerk.
 +
<br clear="all" />
 +
<br />
 +
 
 +
=== Zaaktypen ===
 +
 
 +
[[Bestand:wiki_ztb_editmilestones.png|thumbnail|right]]
 +
 
 +
Een zaaktype is een andere, algemene term voor een proces dat als zaak wordt behandeld, bijvoorbeeld het behandelen van een aanvraag voor een nieuw paspoort. Bij een feitelijke aanvraag van een paspoort door een persoon ontstaat dan een zaak: Paspoort aanvragen door X in het jaar Y’. Elke zaak leidt tot één dossier, een zaakdossier dus. Het onderscheid tussen het begrip ‘proces’, zoals het meestal wordt gebruikt, en het begrip zaaktype is erg belangrijk. Bij zaaktypen spelen het bewaken van de doorlooptijd èn documenten een belangrijke rol. (Passage uit de stukken van Egem)
 +
 
 +
Binnen een zaaktype worden uiteindelijk alle legoblokjes (zwaaronder kenmerken en sjablonen)  bij elkaar gebracht en gemodelleerd tot een werkend iets waarmee burgers een aanvraag kunnen en behandelaars de aanvraag af kunnen handelen. Binnen een zaaktype wordt bijvoorbeeld aangegeven welke fasen een aanvraag doorloopt, wat de controlemomenten zijn, welke documenten verplicht zijn en wordt een koppeling met DigiD geactiveerd.
 +
 
 +
=== Regels ===
 +
Het toevoegen en instellen van regels is even eenvoudig als het toevoegen van een kenmerk. Maar het goed gebruiken van een regel, en met name het goed gebruiken van meerdere overlappende regels, kan een moeilijke aangelegenheid zijn.
 +
 
 +
Zie daarom het voorbeeld hieronder, waarin een zeer begrijpelijke doch complexe situatie in regels wordt gegoten.<br />
 +
<br />
 +
<br />
 +
<b>Het voorbeeld:</b><br />
 +
Een kraampje waar drankjes worden verkocht.<br />
 +
Bij zo’n kraampje heb je de keuze uit verschillende soorten drankjes, en bij sommige van die drankjes heb je vervolgens weer verdere keuzes. Keuzes die voor andere drankjes weer niet gelden. Zo kun je wel cola met ijs bestellen, maar niet bier met ijs.
 +
 
 +
De keuze bij zo’n kraampje zal het over het algemeen wel goed gaan, en zelfs al maakt de klant een keuze die niet mogelijk is, dan is er directe feedback van de verkoper. Maar bij een online-aanvraag voor een subsidie of parkeerkaart is het wenselijk dat ongewenste keuzes onmogelijk gemaakt worden. Het eenvoudigst is om alle mogelijke opties in één lange lijst te zetten, maar erg klantvriendelijk is dat niet.<br />
 +
<br />
 +
<br />
 +
Dus stel dat er bij het kraampje het volgende verkocht wordt:<br />
 +
Amstelbier 20cc - 30cc - 40cc<br />
 +
Heinekenbier 20cc - 30cc - 40cc<br />
 +
Cola met ijs 20cc - 30cc - 40cc<br />
 +
Cola zonder ijs 20cc - 30cc - 40cc<br />
 +
Warme koffie 20cc - 30cc - 40cc<br />
 +
Koude koffie met ijs 20cc - 30cc - 40cc<br />
 +
Koude koffie zonder ijs 20cc - 30cc - 40cc<br />
 +
Warme thee 20cc - 30cc - 40cc<br />
 +
Koude thee 20cc - 30cc - 40cc<br />
 +
Kippensoep<br />
 +
Tomatensoep<br />
 +
<br />
 +
<br />
 +
Dan moet er eerst bepaalt worden welke vragen er gesteld kunnen worden en deze in keuze-kenmerken gezet worden.
 +
 
 +
<b>1. Wat voor soort drinken wil ik?</b><br />
 +
Bier - Cola - Koffie - Thee - Cup-a-soup
 +
 
 +
<b>2. Warm of koud?</b><br />
 +
Warm - Koud
 +
 
 +
<b>3. Met ijs, zonder ijs?</b><br />
 +
IJsblokjes - Geen ijsblokjes
 +
 
 +
<b>4. Wat voor soort bier?</b><br />
 +
Amstel - Heineken
 +
 
 +
<b>5. Wat voor soort soep?</b><br />
 +
Kip - Tomaat
 +
 
 +
<b>6. Hoe groot glas?</b><br />
 +
20cc - 30cc - 40cc<br />
 +
<br />
 +
<br />
 +
Vervolgens kunnen de standaard ‘toon/verberg’ kenmerken opgesteld worden.<br />
 +
Het beste kan hiervoor in omgekeerde volgorde gedacht worden.<br />
 +
Dus niet: “Ik bestel koffie, wat moet er gevraagd worden?”<br />
 +
Maar: “Ik vraag of iets warm of koud moet zijn.., waarom stel ik die vraag?”<br />
 +
<br />
 +
<b>Kenmerk 1:</b><br />
 +
Vraag: Waarom wil ik weten wat voor soort drinken ik ga drinken?<br />
 +
Antwoord: Omdat ik een aanvraag voor drinken doe.<br />
 +
Regel: Dit is de start van het zaaktype, dus hier is geen regel nodig.
 +
 
 +
<b>Kenmerk 2:</b><br />
 +
Vraag: Waarom vraag ik of het warm of koud moet zijn?<br />
 +
Antwoord: Omdat iemand koffie of thee besteld.<br />
 +
Regel: Als kenmerk 1 = koffie/thee, dan toon kenmerk 2, anders verberg kenmerk 2.<br />
 +
 
 +
<b>Kenmerk 3:</b><br />
 +
Vraag: Waarom wil ik weten of er ijs of geen ijs in moet?<br />
 +
Antwoord: Omdat iemand een [koude][koffie] wil, of omdat iemand [cola] wil.<br />
 +
De keuze voor [koud] zit onder een stap later dan die voor [koffie] of [cola], dus laten we de regel op [koud] reageren. (uitleg voor deze keuze volgt)<br />
 +
Regel: Als kenmerk 2 = koud, dan toon kenmerk 3, anders verberg kenmerk 3.
 +
 
 +
<b>Kenmerk 4:</b><br />
 +
Vraag: Waarom wil ik weten wat voor bier iemand wil?<br />
 +
Antwoord: Omdat iemand bier besteld.<br />
 +
Regel: Als kenmerk 1 = bier, dan toon kenmerk 4, anders verberg kenmerk 4.
 +
 
 +
<b>Kenmerk 5:</b><br />
 +
Vraag: Waarom wil ik weten wat voor soep iemand wil?<br />
 +
Antwoord: Omdat iemand soep besteld.<br />
 +
Regel: Als kenmerk 1 = soep, dan toon kenmerk 5, anders verberg kenmerk 5.
 +
 
 +
<b>Kenmerk 6:</b><br />
 +
Vraag: Waarom wil ik weten hoe groot iemands glas moet zijn?<br />
 +
Antwoord: Omdat diegene bier/cola/koffie/thee besteld.<br />
 +
Regel: Als kenmerk 1 = bier/cola/koffie/thee, dan toon kenmerk 6, anders verberg kenmerk 6.<br />
 +
<br />
 +
<br />
 +
Nu is een groot gedeelte van de regels erin. Een hoop aanvragen zullen juist worden verwerkt.<br />
 +
Probleem 1: Maar één product kan niet worden aangevraagd, namelijk de cola met ijs.<br />
 +
Probleem 2: En één niet-bestaand product kan worden aangevraagd, namelijk, koude thee met ijs.<br />
 +
<br />
 +
<b>Probleem 1:</b><br />
 +
Nu komt naar voren waarom kenmerk 3 op kenmerk 2 reageert, en niet op 1.<br />
 +
Want er kan nu simpelweg een regel worden toegevoegd:<br />
 +
Als kenmerk 1 = cola, dan vul bij kenmerk 2 ‘koud’ in.<br />
 +
Als iemand dan cola kiest, wordt er koud ingevuld, en verschijnt het kenmerk voor ijsklontjes.
 +
 
 +
(als kenmerk 3 op 1 had gereageerd, dan zou de vraag voor ijsklontjes ook verschijnen bij warme thee, en omdat deze uit het begin van de regelboom komt, kan dit niet met een andere regel worden afgevangen, want dan zouden de twee regels met elkaar conflicteren. Als thee, dan toon. Als warm, dan verberg.)<br />
 +
<br />
 +
<b>Probleem 2:</b><br />
 +
Om probleem 1 oplosbaar te houden, is ervoor gekozen om het kenmerk voor ijsklontjes te laten tonen bij de keuze voor koud. Dit veroorzaakt echter de situatie dat als iemand koude thee besteld, deze ook de vraag voor ijsklontjes te zien krijgt. Een tweede forceer-regel biedt eenvoudig uitkomst.<br />
 +
Als kenmerk 1 = thee, dan vul bij kenmerk 3 ‘geen ijsklontjes’ in.<br />
 +
<br />
 +
Nu werkt de gehele aanvraag naar behoren.<br />
 +
<br />
 +
<br />
 +
Een schematisch overzicht:<br />
 +
[[Bestand:Schematisch overzicht regelvoorbeeld Drankjesverkoop.png]]
 +
 
 +
<br clear="all" />
 +
<br />
 +
 
 +
== Beheeracties ==
 +
 
 +
=== Algemene tips voor zaaktypebeheer ===
 +
 
 +
<p>Het zaaksysteem heeft een eenvoudig zaaktypebeheer wat volledig webbased te gebruiken is. Dit heeft een hoop voordelen. Zo is het niet nodig om software te installeren op je computer en werkt het bijvoorbeeld ook op een iPad. Helaas zijn er ook wat beperkingen. Zo is ook het zaaksysteem gebonden aan de mogelijkheden van de verschillende webbrowsers zoals Internet Explorer, Chrome of Firefox. Om er zeker van de zijn dat je met vol enthousiasme zaaktype kan blijven configureren, hieronder wat tips:</p>
 +
 
 +
<p>
 +
* '''Publiceer tussentijds.''' Het kan gebeuren dat je sessie verloopt binnen het zaaksysteem. Als je een behoorlijke tijd bezig bent met het bouwen van een zaaktype, is het erg vervelend om te ontdekken dat daardoor je wijzigingen zijn verloren. Vergeet niet zo nu en dan je wijzigingen te publiceren. Op die manier worden de wijzigingen opgeslagen en voorkom je tevens dat je sessie verloopt.
 +
</p>
 +
 
 +
<p>
 +
* '''Test tussentijds.''' Er zijn veel mogelijkheden binnen het zaaksysteem. Met name bij complexe zaaktypen is het mogelijk dat je door de bomen het bos niet meer ziet. Als je dan een configuratiefout moet opzoeken, kan het een aardige zoektocht worden. Dit is deels te voorkomen door tussentijds je resultaten te testen en je zaaktype stapje voor stapje te bouwen. Als er dan iets gout zit, zie je dit direct en kan je het aanpassen.
 +
</p>
 +
 
 +
<p>
 +
* '''Werken met tabbladen.''' Werken met tabbladen in een browser is geen probleem, maar het is te adviseren om niet meerdere tabbladen met hetzelfde zaaktype tegelijk open te hebben. Omdat het zaaksysteem met sessies werkt, kan het voorkomen dat bepaalde instellingen door elkaar worden gehaald. Mocht je dus hetzelfde zaaktype in twee vensters willen, open dit dan in twee verschillende browsers.
 +
</p>
 +
 
 +
<p>
 +
* '''Kenmerken publiceren voor gebruik regels.''' Een mooie functionaliteit is het kunnen toepassen van regels op de kenmerken. Om een regel te kunnen gebruiken moet eerst alle kenmerken zijn gepubliceerd. Als je dus een paar nieuwe kenmerken in een fase zet, zul je het zaaktype eerst moeten publiceren.
 +
</p>
 +
 
 +
<p>
 +
* '''Werkende sjablonen.''' Het zaaksysteem maakt gebruik van OpenOffice voor het gebruiken van documentsjablonen. Het formaat wat hiervoor gebruikt wordt is ODF. Om een sjabloon te maken in het ODF-formaat heb je niet per definitie OpenOffice nodig. Ook Microsoft Office 2010 is in staat om in ODF-bestanden op te slaan. Dit betekent dat de documenten in XML worden opgeslagen. Het wil wel eens voorkomen dat met 'Copy-paste' acties of uitwisseling tussen programma's de xml net even anders wordt gezet. Het resultaat is dat het kan voorkomen dat Magic Strings niet goed worden ingevuld. Geen paniek. Verwijder de tekst en vul de Magic String handmatig in, sla opnieuw op. Naar alle waarschijnlijkheid werkt het nu wel.
 +
</p>
 +
 
 +
<br clear="all" />
 +
 
 +
=== Een kenmerk aanmaken ===
 +
 
 +
[[Bestand:wiki_youtubevideo2.png|left|link=http://www.youtube.com/watch?v=EbBrljvHE-U]]
 +
 
 +
1. Zorg ervoor dat je in het dashboard zit<br />
 +
2. Klik in het menu op Zaaktypecatalogus <br />
 +
3. Ga naar de map waarin je het kenmerk wilt aanmaken <br />
 +
4. Klik op nieuw kenmerk <br />
 +
5. Vul de benodigde gegevens in van het kenmerk <br />
 +
6. Klik op Opslaan <br /> <br />
 +
 
 +
Bekijk eventueel de instructievideo voor een voorbeeld.
 +
 
 +
<br clear="all" />
 +
 
 +
=== Een sjabloon aanmaken en testen ===
 +
 
 +
[[Bestand:wiki_youtubevideo2.png|left|link=http://www.youtube.com/watch?v=R1Zyv4UH1SM]]
 +
 
 +
1. Zorg ervoor dat je in het dashboard zit<br />
 +
2. Klik in het menu op Zaaktypecatalogus <br />
 +
3. Ga naar de map waarin je het sjabloon wilt aanmaken <br />
 +
4. Klik op nieuw sjabloon <br />
 +
5. Vul de benodigde gegevens in van het sjabloon <br />
 +
6. Klik op Opslaan <br /> <br />
 +
7. Voeg het sjabloon toe binnen een fase in het zaaktype
 +
8. Publiceer het zaaktype<br />
 +
9. Start een nieuwe zaak<br />
 +
10. Klik vanuit het zaakdossier op het tabblad Documenten<br />
 +
11. Klik op de knop Sjabloon<br />
 +
12. Start de magic...<br /><br />
 +
 
 +
Bekijk eventueel de instructievideo voor een voorbeeld.
 +
 
 +
<br clear="all" />

Versie van 5 mrt 2012 om 14:21

De zaaktypecatalogus+

Uitleg

ghgh

  • Zaaktypen


Kenmerken

Kenmerken zijn informatieobjecten die centraal worden opgeslagen, maar meervoudig kunnen worden gebruikt. Het verschil met een kenmerk uit de Gemma ZTC is dat ze niet voor alle zaaktypen gelden. Een voorbeeld. Elke zaak heeft registratiedatum of een zaaknummer, maar niet elke zaak heeft het kenmerk 'Meldingencategorie'. Dit is een specifiek kenmerk voor het zaaktype Melding Openbare Ruimte. Desondanks zijn er kenmerken die meervoudig te gebruiken zijn, zoals het kenmerk 'subsidiebedrag'.

Wanneer een kenmerk wordet aangemaakt dat moet er een invoertype worden bepaald voor dit kenmerk. Het invoertype geeft aan wat het zaaksysteem moet doen wanneer dit kenmerk wordt gebruikt bij een zaaktype. Voorbeelden van invoertypen zijn:

  • Tekstveld
  • Keuzemenu (dropdown)
  • Meervoudige keuze (Checkbox)
  • Maps (Google prikkaart)
  • Valuta
  • Etc.

Tevens wordt er voor elk kenmerk direct een 'magic sting' aangemaakt. Dit is een variable die het systeem voor verschillende doeleinden gebruikt. Deze kunnen bijvoorbeeld gebruikt worden in de sjablonen en de berichten die naar aanvragers worden verstuurd. Uiteraard vult het zaaksysteem dan de inhoudt in van het betreffende kenmerk.

Zaaktypen

Een zaaktype is een andere, algemene term voor een proces dat als zaak wordt behandeld, bijvoorbeeld het behandelen van een aanvraag voor een nieuw paspoort. Bij een feitelijke aanvraag van een paspoort door een persoon ontstaat dan een zaak: Paspoort aanvragen door X in het jaar Y’. Elke zaak leidt tot één dossier, een zaakdossier dus. Het onderscheid tussen het begrip ‘proces’, zoals het meestal wordt gebruikt, en het begrip zaaktype is erg belangrijk. Bij zaaktypen spelen het bewaken van de doorlooptijd èn documenten een belangrijke rol. (Passage uit de stukken van Egem)

Binnen een zaaktype worden uiteindelijk alle legoblokjes (zwaaronder kenmerken en sjablonen) bij elkaar gebracht en gemodelleerd tot een werkend iets waarmee burgers een aanvraag kunnen en behandelaars de aanvraag af kunnen handelen. Binnen een zaaktype wordt bijvoorbeeld aangegeven welke fasen een aanvraag doorloopt, wat de controlemomenten zijn, welke documenten verplicht zijn en wordt een koppeling met DigiD geactiveerd.

Regels

Het toevoegen en instellen van regels is even eenvoudig als het toevoegen van een kenmerk. Maar het goed gebruiken van een regel, en met name het goed gebruiken van meerdere overlappende regels, kan een moeilijke aangelegenheid zijn.

Zie daarom het voorbeeld hieronder, waarin een zeer begrijpelijke doch complexe situatie in regels wordt gegoten.


Het voorbeeld:
Een kraampje waar drankjes worden verkocht.
Bij zo’n kraampje heb je de keuze uit verschillende soorten drankjes, en bij sommige van die drankjes heb je vervolgens weer verdere keuzes. Keuzes die voor andere drankjes weer niet gelden. Zo kun je wel cola met ijs bestellen, maar niet bier met ijs.

De keuze bij zo’n kraampje zal het over het algemeen wel goed gaan, en zelfs al maakt de klant een keuze die niet mogelijk is, dan is er directe feedback van de verkoper. Maar bij een online-aanvraag voor een subsidie of parkeerkaart is het wenselijk dat ongewenste keuzes onmogelijk gemaakt worden. Het eenvoudigst is om alle mogelijke opties in één lange lijst te zetten, maar erg klantvriendelijk is dat niet.


Dus stel dat er bij het kraampje het volgende verkocht wordt:
Amstelbier 20cc - 30cc - 40cc
Heinekenbier 20cc - 30cc - 40cc
Cola met ijs 20cc - 30cc - 40cc
Cola zonder ijs 20cc - 30cc - 40cc
Warme koffie 20cc - 30cc - 40cc
Koude koffie met ijs 20cc - 30cc - 40cc
Koude koffie zonder ijs 20cc - 30cc - 40cc
Warme thee 20cc - 30cc - 40cc
Koude thee 20cc - 30cc - 40cc
Kippensoep
Tomatensoep


Dan moet er eerst bepaalt worden welke vragen er gesteld kunnen worden en deze in keuze-kenmerken gezet worden.

1. Wat voor soort drinken wil ik?
Bier - Cola - Koffie - Thee - Cup-a-soup

2. Warm of koud?
Warm - Koud

3. Met ijs, zonder ijs?
IJsblokjes - Geen ijsblokjes

4. Wat voor soort bier?
Amstel - Heineken

5. Wat voor soort soep?
Kip - Tomaat

6. Hoe groot glas?
20cc - 30cc - 40cc


Vervolgens kunnen de standaard ‘toon/verberg’ kenmerken opgesteld worden.
Het beste kan hiervoor in omgekeerde volgorde gedacht worden.
Dus niet: “Ik bestel koffie, wat moet er gevraagd worden?”
Maar: “Ik vraag of iets warm of koud moet zijn.., waarom stel ik die vraag?”

Kenmerk 1:
Vraag: Waarom wil ik weten wat voor soort drinken ik ga drinken?
Antwoord: Omdat ik een aanvraag voor drinken doe.
Regel: Dit is de start van het zaaktype, dus hier is geen regel nodig.

Kenmerk 2:
Vraag: Waarom vraag ik of het warm of koud moet zijn?
Antwoord: Omdat iemand koffie of thee besteld.
Regel: Als kenmerk 1 = koffie/thee, dan toon kenmerk 2, anders verberg kenmerk 2.

Kenmerk 3:
Vraag: Waarom wil ik weten of er ijs of geen ijs in moet?
Antwoord: Omdat iemand een [koude][koffie] wil, of omdat iemand [cola] wil.
De keuze voor [koud] zit onder een stap later dan die voor [koffie] of [cola], dus laten we de regel op [koud] reageren. (uitleg voor deze keuze volgt)
Regel: Als kenmerk 2 = koud, dan toon kenmerk 3, anders verberg kenmerk 3.

Kenmerk 4:
Vraag: Waarom wil ik weten wat voor bier iemand wil?
Antwoord: Omdat iemand bier besteld.
Regel: Als kenmerk 1 = bier, dan toon kenmerk 4, anders verberg kenmerk 4.

Kenmerk 5:
Vraag: Waarom wil ik weten wat voor soep iemand wil?
Antwoord: Omdat iemand soep besteld.
Regel: Als kenmerk 1 = soep, dan toon kenmerk 5, anders verberg kenmerk 5.

Kenmerk 6:
Vraag: Waarom wil ik weten hoe groot iemands glas moet zijn?
Antwoord: Omdat diegene bier/cola/koffie/thee besteld.
Regel: Als kenmerk 1 = bier/cola/koffie/thee, dan toon kenmerk 6, anders verberg kenmerk 6.


Nu is een groot gedeelte van de regels erin. Een hoop aanvragen zullen juist worden verwerkt.
Probleem 1: Maar één product kan niet worden aangevraagd, namelijk de cola met ijs.
Probleem 2: En één niet-bestaand product kan worden aangevraagd, namelijk, koude thee met ijs.

Probleem 1:
Nu komt naar voren waarom kenmerk 3 op kenmerk 2 reageert, en niet op 1.
Want er kan nu simpelweg een regel worden toegevoegd:
Als kenmerk 1 = cola, dan vul bij kenmerk 2 ‘koud’ in.
Als iemand dan cola kiest, wordt er koud ingevuld, en verschijnt het kenmerk voor ijsklontjes.

(als kenmerk 3 op 1 had gereageerd, dan zou de vraag voor ijsklontjes ook verschijnen bij warme thee, en omdat deze uit het begin van de regelboom komt, kan dit niet met een andere regel worden afgevangen, want dan zouden de twee regels met elkaar conflicteren. Als thee, dan toon. Als warm, dan verberg.)

Probleem 2:
Om probleem 1 oplosbaar te houden, is ervoor gekozen om het kenmerk voor ijsklontjes te laten tonen bij de keuze voor koud. Dit veroorzaakt echter de situatie dat als iemand koude thee besteld, deze ook de vraag voor ijsklontjes te zien krijgt. Een tweede forceer-regel biedt eenvoudig uitkomst.
Als kenmerk 1 = thee, dan vul bij kenmerk 3 ‘geen ijsklontjes’ in.

Nu werkt de gehele aanvraag naar behoren.


Een schematisch overzicht:
Bestand:Schematisch overzicht regelvoorbeeld Drankjesverkoop.png



Beheeracties

Algemene tips voor zaaktypebeheer

Het zaaksysteem heeft een eenvoudig zaaktypebeheer wat volledig webbased te gebruiken is. Dit heeft een hoop voordelen. Zo is het niet nodig om software te installeren op je computer en werkt het bijvoorbeeld ook op een iPad. Helaas zijn er ook wat beperkingen. Zo is ook het zaaksysteem gebonden aan de mogelijkheden van de verschillende webbrowsers zoals Internet Explorer, Chrome of Firefox. Om er zeker van de zijn dat je met vol enthousiasme zaaktype kan blijven configureren, hieronder wat tips:

  • Publiceer tussentijds. Het kan gebeuren dat je sessie verloopt binnen het zaaksysteem. Als je een behoorlijke tijd bezig bent met het bouwen van een zaaktype, is het erg vervelend om te ontdekken dat daardoor je wijzigingen zijn verloren. Vergeet niet zo nu en dan je wijzigingen te publiceren. Op die manier worden de wijzigingen opgeslagen en voorkom je tevens dat je sessie verloopt.

  • Test tussentijds. Er zijn veel mogelijkheden binnen het zaaksysteem. Met name bij complexe zaaktypen is het mogelijk dat je door de bomen het bos niet meer ziet. Als je dan een configuratiefout moet opzoeken, kan het een aardige zoektocht worden. Dit is deels te voorkomen door tussentijds je resultaten te testen en je zaaktype stapje voor stapje te bouwen. Als er dan iets gout zit, zie je dit direct en kan je het aanpassen.

  • Werken met tabbladen. Werken met tabbladen in een browser is geen probleem, maar het is te adviseren om niet meerdere tabbladen met hetzelfde zaaktype tegelijk open te hebben. Omdat het zaaksysteem met sessies werkt, kan het voorkomen dat bepaalde instellingen door elkaar worden gehaald. Mocht je dus hetzelfde zaaktype in twee vensters willen, open dit dan in twee verschillende browsers.

  • Kenmerken publiceren voor gebruik regels. Een mooie functionaliteit is het kunnen toepassen van regels op de kenmerken. Om een regel te kunnen gebruiken moet eerst alle kenmerken zijn gepubliceerd. Als je dus een paar nieuwe kenmerken in een fase zet, zul je het zaaktype eerst moeten publiceren.

  • Werkende sjablonen. Het zaaksysteem maakt gebruik van OpenOffice voor het gebruiken van documentsjablonen. Het formaat wat hiervoor gebruikt wordt is ODF. Om een sjabloon te maken in het ODF-formaat heb je niet per definitie OpenOffice nodig. Ook Microsoft Office 2010 is in staat om in ODF-bestanden op te slaan. Dit betekent dat de documenten in XML worden opgeslagen. Het wil wel eens voorkomen dat met 'Copy-paste' acties of uitwisseling tussen programma's de xml net even anders wordt gezet. Het resultaat is dat het kan voorkomen dat Magic Strings niet goed worden ingevuld. Geen paniek. Verwijder de tekst en vul de Magic String handmatig in, sla opnieuw op. Naar alle waarschijnlijkheid werkt het nu wel.


Een kenmerk aanmaken

1. Zorg ervoor dat je in het dashboard zit
2. Klik in het menu op Zaaktypecatalogus
3. Ga naar de map waarin je het kenmerk wilt aanmaken
4. Klik op nieuw kenmerk
5. Vul de benodigde gegevens in van het kenmerk
6. Klik op Opslaan

Bekijk eventueel de instructievideo voor een voorbeeld.


Een sjabloon aanmaken en testen

1. Zorg ervoor dat je in het dashboard zit
2. Klik in het menu op Zaaktypecatalogus
3. Ga naar de map waarin je het sjabloon wilt aanmaken
4. Klik op nieuw sjabloon
5. Vul de benodigde gegevens in van het sjabloon
6. Klik op Opslaan

7. Voeg het sjabloon toe binnen een fase in het zaaktype 8. Publiceer het zaaktype
9. Start een nieuwe zaak
10. Klik vanuit het zaakdossier op het tabblad Documenten
11. Klik op de knop Sjabloon
12. Start de magic...

Bekijk eventueel de instructievideo voor een voorbeeld.