Actuele data op reeds opgestarte formulieren (SLSR-I-267)

[Anonymous]

Wanneer een formulier wordt opgestart, wordt de op dat moment bekende informatie getoond op het formulier. Wanneer het formulier vervolgens ergens in de workflow blijft hangen, wordt de informatie niet meer bijgewerkt. Stel dat informatie inmiddels veranderd is (bv. door een andere mutatie die wel sneller het proces heeft doorlopen of door handmatige aanpassingen in Beaufort) dan geeft het formulier dus verouderde informatie door en wordt soms zelfs nieuwe informatie overschreven.

Casus die si voorgekomen bij ons: Een medewerker had een mutatie voor een adreswijziging opgestart, maar nog niet verzonden. Enkele dagen daarna start de leidinggevende een overplaatsingsmutatie op, waarbij door de personeelsadministratie een opmerking is geplaatst omtrent de reiskosten (i.v.m. doorlopend sociaal plan). Deze mutatie heeft vervolgens iedere stap doorlopen en dus zijn de gegevens (incl. opmerking) geëxporteerd naar Beaufort. Enige weken later heeft de medewerker de adresmutatie alsnog verzonden. Ook in dit formulier kan het opmerkingenveld m.b.t. reiskosten gevuld worden. Dit was nu leeg (immers: de mutatie was al opgestart voordat de overplaatsingsmutatie was gefiatteerd) en bleef ook leeg. De adresmutatie wordt goedgekeurd en geëxporteerd naar Beaufort en daarmee wordt de opmerking over de meerkilometers i.v.m. doorlopend sociaal plan overschreven.

Onze wens is dus dat een reeds opgestarte (maar nog niet afgeronde) mutatie altijd de actuele informatie uit de database laat zien.

[Anonymous]

Helemaal mee eens, Soortgelijke zaken komen bij ons ook regelmatig voor.

[Anonymous]

Prima idee. Ik sta er achter.

[Remco te Ronde]

Hoi @Anonymous , @Anonymous en @Anonymous ,

Zoals jullie mogelijk hebt gelezen het bericht Youforce Cleanup ideeën zullen meerdere Visma|Raet collega's de aankomende tijd helpen in de beoordeling van de ideeën. In eerste opzicht lijkt dit idee extreem complex, maar het levert bij mij wel een aantal vervolgvragen op:

• Sinds het indienen van dit idee (in 2017) is er mogelijk e.e.a. veranderd. Is het wellicht zo dat de doorlooptijd van workflows sneller is geworden (omdat er minder stappen voorkomen)? Of omdat minder personen rechten hebben gekregen op rechtstreeks muteren in HR Core Beaufort? Kunnen jullie dat toelichten, of komt het nog even vaak voor?

Daarnaast zien we dat er veel maatwerk controles gebouwd zijn. Neem als voorbeeld een controle op of het veld ''functie'' inderdaad een andere waarde heeft als daarvoor. (via controles met GF_WRB). Om zo te zorgen dat een manager bij een contract wijziging wel écht een andere functie selecteert.

In het voorbeeld kan het voorkomen dat medewerker functie A heeft en naar B gaat. De workflow is opgestart met functie B. Maar vanwege ''gedoe'' past de salarisadministratie alvast handmatig de functie aan naar B in HR Core Beaufort. Dit betekent:

• Dat je mogelijk niet meer de gewenste template kan genereren. Want je kunt niet meer zeggen je gaat van functie A naar functie B.
• De workflow kan bij een latere activiteit (b.v. controleren SA) volledig vastlopen. Omdat de controle ''je moet het veld functie wijzigen'' blijft afgaan.

Graag hoor ik jullie mening daarop. Mede op basis van jullie feedback kunnen we vragen om de ontwikkelaars van Self Service te laten kijken of het in de verre toekomst met een rechtstreekse API verbinding met HR Core Beaufort technisch haalbaar kan zijn. Maar ik zie wel wat hobbels in deze.

Hoor het graag.

[Jar1k]

@Remco te Ronde @Anonymous @Anonymous @Anonymous  

De javascriptfunctie die Remco noemt, is volgens mij de oplossing. Als je GF_WRB('Rubriek') gebruikt om actuele informatie op te halen van de betreffende rubrieken loop je vermoedelijk niet tegen het door Rianne ervaren probleem aan.

Je kunt dan wel tegen het probleem aanlopen, wat Remco schetst met die controles, maar dan zou ik mijn controles anders inrichten. Je kunt de initiële waarde van een rubriek bijv. ook vastleggen door in een tweede rubriek in de pre-bewerking het volgende script te gebruiken.

var a=v_P01107#; //de functierubriek

var b=v_A00001[100]#; //dit is de onderhavige rubriek waar je de initiële waarde in wilt vastleggen

if (b=='') return(a)

else return(b)

Vervolgens kun je voor je controle vergelijken of P01107 en A00001[100] dezelfde waarde hebben (zo ja, fout, zo nee, goed).

[Rianne van der Linden]

@Remco te Ronde  De wens is afgelopen maandag (27-6) besproken met Ana Maria Nichitelea en Christel Witte. Misschien goed om met hen contact te zoeken. Ana Maria gaf in ieder geval aan onze wens te begrijpen. 

[Timo van Son - AAG]

Ik kan onderschrijven dat dit soort problemen blijven voorkomen. 

Recent voorbeeld betreft een adreswijziging ingediend door een medewerker, voor wie de administratie een nieuw dienstverband had aangemaakt. Het nieuwe dienstverband was opgestart vóór de adreswijziging, maar i.v.m. het (digitaal) ondertekenen van het contract pas later verwerkt. Met als gevolg dat de adreswijziging ongedaan gemaakt wordt na de verwerking van het nieuwe dienstverband.

Wat betreft feedback op aangedragen voorbeeld: 

In het voorbeeld kan het voorkomen dat medewerker functie A heeft en naar B gaat. De workflow is opgestart met functie B. Maar vanwege ''gedoe'' past de salarisadministratie alvast handmatig de functie aan naar B in HR Core Beaufort. Dit betekent:

1) Dat je mogelijk niet meer de gewenste template kan genereren. Want je kunt niet meer zeggen je gaat van functie A naar functie B.
2) De workflow kan bij een latere activiteit (b.v. controleren SA) volledig vastlopen. Omdat de controle ''je moet het veld functie wijzigen'' blijft afgaan.

1) Als de SA op voorhand handmatig ingrijpt moeten ze ook handmatig ingrijpen wanneer er een overeenkomst ontbreekt. 

2) Als de SA op voorhand handmatig ingrijpt moeten ze er niet vreemd van opkijken dat een mutatie vastloopt. 

In beide gevallen redeneer ik dat degene die ingrijpt in Beaufort, dit ook maar ongedaan moet maken als e.e.a. wel op een juiste wijze binnenkomt. 

De benoemde javascript oplossing werkt niet 100 procent. De gepresenteerde "waarde oud" kun je niet beïnvloeden. En de "actuele waarde" die wordt gepresenteerd in het formulier kun je niet met GF_WRB inladen. Daarmee doe je de aangebrachte mutaties namelijk weer teniet bij de eerstvolgende verwerkingsstap in de workflow. 

[Remco te Ronde]

Hoi @Anonymous  en @Timo van Son - AAG ,

Inderdaad meerdere collega's helpen met het analyseren van ideeen. En dit idee had wat andere toelichting nodig. Bedankt voor jullie aanvullingen.

Ik ga verder in overleg met mijn collega @Ana Maria Nichitelea of onze Self Service collega's nu op basis van dit idee en het overleg met @Anonymous voldoende informatie hebben voor de nadere analyse.

[Remco te Ronde]

Hoi @Timo van Son - AAG , @Jar1k en @Rianne van der Linden ,

Vandaag hebben mijn collega's @Ana Maria Nichitelea en @Daniel_van_Bendegem nogmaals dit idee besproken. Mede omdat we onlangs ook het idee 'Rubrieken op bestaande formulieren aanpassen op basis van beaufort' beoordeeld hebben. Na dit overleg komen we tot dezelfde conclusie, namelijk:

Wat betreft 'Wanneer er een formulier is aangemaakt en wordt behandeld, worden er geen wijziging meer doorgevoerd hierop'. Dit is inderdaad de werking van Self Service. Op het moment dat een gebruiker een workflow opstart dan worden alle ''oude gegevens'' gevuld. Op die manier is het helder welke verandering deze gebruiker heeft gemaakt bij 'nieuwe gegevens'. Je zou het haast als een soort van bewaking van de 'integriteit' kunnen zien. Immers daarmee weet je dat deze gebruiker akkoord was met b.v. de wijziging van 24 uur (oude waarde) naar 32 uur (nieuwe waarde).

Als we zouden zorgen dat bij een lopende workflow ''ineens'' de oude waarde uit HR Core Beaufort wordt geüpdatet kan dit veel onduidelijkheid creëren. Ook zouden wellicht controles zoals (huidige uren <> oude uren) ineens vast kunnen lopen.

Hopende je daarmee toegelicht te hebben waarom wij dit idee de status 'afgewezen' hebben gegeven.