We hebben voor ticketverwerking AFAS gekozen als de te gebruike applicatie met zowel een Outsite als (uiteraard) een Insite omgeving. Nu willen we eigenlijk dat tickets die vanuit een door ons aangemaakte statustabel (vrije tabel) de tickets die langer dan 1 dag open staan van de status resolved (opgelost) naar closed (gesloten) gaan.
Ik wil alleen even zeker stellen dat ik dit op de juiste manier heb ingericht dus deel ik even wat screenshots. Alvast heel erg dank!
Op het eerste oog ziet de inrichting er logisch uit! Mijn toevoeging/tip zou zijn om de actie in ieder geval alleen intern zichtbaar te maken. Dan is de workflow actie in ieder geval nooit zichtbaar voor je klanten in OutSite.
Het lijkt er in eerste oogopslag inderdaad logisch uit te zien. Het enige dat we niet zien is je conditie. Ik neem aan dat deze staat ingesteld op Datum wijziging externe status >= vandaag - 7 dagen?
Verder inderdaad de opmerking van Jonathan goed om nog aan te passen.
Je workflowactie heet sluiten na 7 dagen, wellicht goed om dit in lijn te trekken met de daadwerkelijke conditie. Die sluit nu na 1 dag.
Is het veld LaatsteWijziging een vrij veld? Je kunt hier anders ook het veld âLaatste wijziging externe statusâ voor gebruiken als je zorgt dat de Externe (Outsite) status wordt gemuteerd in de vorige stap.
Uiteindelijk is hiervoor het makkelijkst om gewoon even een test ticket in te sturen, deze direct af te handelen en te kijken of deze maandag gesloten is
Helaas heeft het conditioneel afhandelen niet gewerkt. Het gaat om de omlijnde actie. De andere 2 (Ticket gesloten / Oplossing niet akkoord) ziet de instuurder van het ticket wel en hieruit kan gekozen worden.
Op de achtergrond verander ik niet alleen de workflowstatus, maar ook via de waarde (ticketstatus) pas ik deze aan. Iemand enig idee wat ik hier nog mis Ăłf is het zo simpel dat het gewoonweg niet mogelijk is om een actieknop te hebben die conditioneel via een geplande taak afgehandeld wordt terwijl de andere knop(pen) als zichtbare actieknop(pen) bij de taakafhandelaar liggen?
Technisch kan het wel, ik heb dit zelf wel gebouwd.
Er zal een andere oorzaak zijn; je kunt de conditie testen om te zien of deze waar/onwaar is zonder dat je de actie conditioneel laat afhandelen om eenvoudig die oorzaak uit te sluiten.
Bij de test komt als resultaat âonwaarâ. Het lastige is dat ik nu niet weet welk veld ik nu het beste kan kiezen vanuit de gegevensverzameling van het dossier die de laatste wijziging in de workflow laat zien.
Ik hĂĄd gedacht dat onderstaand veld het juiste veld was om de conditie (naast de status) op te maken:
Kun je je conditie eens per onderdeel testen? bijv. eerst alleen de voorwaarde van de status, en daarna alleen de voorwaarde van je wijzigdatum? Dan kun je daaraan verder herleiden wat er mis gaat.
Ben je toevallig aan het filteren op de workflowstatus code i.p.v. omschrijving?
Wijzig je in de vorige stap wel de externe status? Of wordt alleen de interne status gewijzigd naar Resolved?
Klinkt allemaal logisch en ik heb inmiddels al een 20-tal varianten geprobeerd en slechts 1 conditie toegepast, maar ze zijn allemaal âonwaarâ. De status waar ik op wil filteren (buiten de datum, wat ik wel geloof) is de zgn. ticketstatus die wij vullen vanuit een gekoppeld veld van een vrije tabel met al deze statussen. Maar ik ben een beetje lost ondertussenâŠ
Omdat ik niet de standaard workflowstatussen-tabel gebruik waar ik de status op de actieknoppen toeken bleek het niet noodzakelijk om deze ook nog via âWaarde toekennenâ bij âvrije velden bij dossierâ te vullen.
In de conditie dus dit vrije veld weggelaten en enkel gekeken naar de laatste wijzigingsdatum, omdat in de workflow bij âIntiĂ«le statusâ , resp. âInitiĂ«le status externâ de waarde al opgevoerd was.
Na het draaien van de geplande taak âWorkflowtaken conditioneel afhandelenâ werd eindelijk de status omgezet naar de gewenste âClosedâ status.
