om een gepersonaliseerde navigatie te krijgen.
om een gepersonaliseerde navigatie te krijgen.
Wij hebben de adreswijziging (via de APP) gekoppeld aan een HRSS proces zodat de enkele reisafstand automatisch wordt berekend. Het proces bestaat alleen uit de stap 'indienen medewerker'
Wij zien dat de bewerking voor de automatische afstandsberekening dan niet werkt. Ook niet als de bewerking zowel in de 'pre' als in de 'post' wordt ingericht.
De berekening werkt wel als we er een stap toevoegen aan het proces, bijvoorbeeld 'goedkeuren PSA', maar dat hebben we eigenlijk liever niet.
@Remco te Ronde ik heb onlangs ergens (kan deze niet meer vinden) een bericht van jou gelezen dat dit wel mogelijk zou moeten zijn.
Dus wat doen wij hier verkeerd?
Hi @Marco van den Anker , @Astrid Mulder , @Misty en @GVeen ,
Gisteren hebben we een wijziging doorgevoerd in Self Service. Als je nu vanuit de Youforce App (of het desktop proces vanuit Mijn Youforce) een adres wijziging opstart die een Self Service workflow start die direct naar de status *goedgekeurd gaat wordt ook de bewerking op GF_DistanceBetweenNLZipCodes & GF_DistanceBetweenForeignAddress uitgevoerd.
Zouden jullie willen testen (en bevestigen) of dat inderdaad nu bij jullie ook werkt?
Wij wilden het ook op deze manier inrichten maar het werkt inderdaad niet zonder tussenkomst van iemand die op bevestigen klikt.
De berekeningen worden gewoon niet uitgevoerd lijkt het wel. Heb hier in dec '23 met Bas van der Veen naar gekeken en we hebben het helaas moeten inrichten met onze servicedesk die altijd nog op bevestigen klikt. We willen daar wel vanaf want het is nu gewoon 'dom klikken' voor hen.
Goedemorgen @Misty , @Marco van den Anker en @Astrid Mulder ,
Op basis van jullie reacties heb ik nog e.e.a. verder getest. Allereerst goed om te weten, vanuit de App worden alle relevante velden (zoals postcode, huisnummer, land) aangeleverd op de relevante rubriek.
Maar óók rubriek A00001 krijgt waarde 'Nee' of 'Ja' mee om te bepalen of er een afwijkend postadres is. Dit geldt voor alle A00001 rubrieken in het formulier. Dat beinvloed dus je java-scripts als je daarin verwijst naar een andere (hulp)-rubriek met A00001.
Mijn ervaring is dat als er géén andere A00001-rubriek op het formulier 'gewone' java-scripts zoals return(v_P01020#) of andere scripts werken.
Maar dat java-scripts zoals return GF_DistanceBetweenNLZipCodes(v_PCVAN#,v_PCNAAR#,'') niet werken. Komt dit overeen met jullie test ervaringen? Hoor het graag.
Ik lees graag mee. Bij ons werkt het ook niet. We hebben al een ticket voor aangemaakt. Bij de berekening tussen woonadres en werkadres herkent de huisnummer niet in Self Service.
Hoi @Astrid Mulder en @Marco van den Anker,
Heb nog even dieper gezocht. Mijn huidige test/vermoeden is dat er mogelijk in jullie formulier een script zit wat gebruik maakt van een A00001 rubriek. Dit is niet toegestaan, omdat alleen voor de vraag 'is dit ook uw postadres' de A00001 mag worden gebruikt.
Kunnen jullie nagaan of een van de rubrieken op jullie formulier inderdaad gebruik maakt van een script waarin A00001 zit?
Hoi Remco, We hadden inderdaad een javascript op een A00001 rubriek. Dit was de berekening van huisnummer naar huisnummer. Door deze berekening kregen wij de foutmelding dat de huisnummer formaat niet correct was. We hebben een javascript op eigen rubriek gedaan van postcode naar postcode. Die gaat goed. Alleen willen wij wel graag de afstand bereken tussen huisnummer en huisnummer.
Bedankt @Remco te Ronde . We hadden huisnummer en straatnummer omgewisseld in de javascript.
Hoi @Astrid Mulder , @Marco van den Anker en @Misty,
Bedankt voor jullie aanvullingen. Na het dieper onderzoeken (met o.a. jullie hulp) hebben we kunnen concluderen:
✔️ Adres wijziging uit de app -> Self Service voert bijna alle java-scripts goed uit. Aandachtspunt daarbij is wel om de rubriek A00001 (als 'text', 'datum', 'radio', 'getal' etc.) voor niks anders te gebruiken dan de vraag 'Is dit ook uw postadres ?'
❌ We zien dat de hele specifieke java-scripts (GF_DistanceBetweenNLZipCodes & GF_DistanceBetweenForeignAddress) niet worden uitgevoerd als de workflow rechstreeks uit app -> Self Service workflow eindstatus *goedgekeurd gaat.
Vrijwel alle organisaties gebruiken 'adres wijziging app' -> Self Service workflow omdat de Salarisadminstratie een rol heeft in de workflow. Bijvoorbeeld vanwege de 'reisafstand', maar ook eventueel voor 'garantie reiskosten' of b.v. een NS-abonnement. Daarmee werkt dat helemaal prima.
Maar ik snap jullie ambitie @Astrid Mulder , @Marco van den Anker en @Misty om het volledig helemaal ''dicht te scripten'''. We blijven dat verder onderzoeken voor de genoemde java-scripts, maar dit is voorlopig de huidige status.
@Remco te Ronde schreef:
Maar ik snap jullie ambitie @Astrid Mulder , @Marco van den Anker en @Misty om het volledig helemaal ''dicht te scripten'''. We blijven dat verder onderzoeken voor de genoemde java-scripts, maar dit is voorlopig de huidige status.
Is hier toevallig al nieuws over? 🙂
Hoi @GVeen ,
Ja er is nieuws over. We hebben inderdaad achterhaald dat het starten van een workflow vanuit de Youforce App in Self Service bij een workflow die direct naar de eindstatus gaat zorgt dat de hele specifieke java-scripts (GF_DistanceBetweenNLZipCodes & GF_DistanceBetweenForeignAddress) niet uitvoert.
We weten waar de oorzaak ligt en wat de oplossing is. Maar zoals wel vaker is het niet de kwestie van één vinkje of één regel code. We zijn ons er dus bewust van wat moet gebeuren. Maar de eerlijkheid biedt ook te zeggen dat de prioriteit om dit te verbeteren niet de hoogste is.
Als het is opgelost zal ik zorgen dat er een update komt hier op het forum.
Dank voor je reactie Remco. Het ging inderdaad om het script voor Distancetoforeign wat ie niet oppakt zonder tussenkomst. We hebben er nu ook een team tussen voor het klikken, maar mocht het in de toekomst opgelost worden dan is dat natuurlijk fijn 🙂
@Remco te Ronde dank voor je reactie. We voegen (voorlopig) de SA toe aan dit proces.
Hi @Remco te Ronde ,
Eindelijk de tijd om even te reageren. Ja, ook wij hebben op het 1e formulier bewerkingen met A00001. Zie hieronder de volledige inrichting van het formulier:
Zijn de bewerkingen op regel 200 t/m 280 dan de boosdoeners?
Overigens, als dit proces wordt gestart vanuit de App. Krijgt de vraag op regel 170 altijd de waarde 'nee'. Dus wel 170 als 200 t/m 280 hebben eigenlijk geen nut meer.
Alvast bedankt voor je reactie.
Groet,
Marco
Hoi @Marco van den Anker ,
De scripts die verwijzen naar 'postadres ja/nee' (dus A00001_170) mogen er wel staan en zouden moeten werken.
In jullie formulier zie ik alleen dat A00001 ook op positie 192 als 'getal' op het formulier. Die snap ik in ieder geval niet (ook niet wat de toegevoegde waarde is). Die zou er dus ook niet moeten staan.
Waarschijnlijk kan je die dus sowieso beter opruimen. Maar voor zover ik het heb kunnen reproduceren zal dan nog steeds de functie GF_DistanceBetweenNLZipCodes niet werken. Daar ben ik nog steeds dieper naar aan het kijken en dan kom ik er op terug.
@Remco te Ronde klopt. We hebben inderdaad een script op A00001.
Ik heb net de de script op eigen rubriek gezet, maar blijf de melding krijgen dat de huisnummer formaat niet juist is. Terwijl adres bekend is in BAG.
Hoi @Marco van den Anker ,
Volgens mij ben je op zoek naar de uitleg die ik eerder heb gegeven in:
Youforce app - Wijziging woon-werkverkeer
@Remco te Ronde helaas lijkt dit niet het antwoord op ons probleem 😅
Als het proces wordt opgestart in Self Services (na mutatie adreswijziging Youforce App) hoopte wij dat de afstandsberekening automatisch berekend zou worden. Zeker toen we alle relevante scripts ook in de pre-bewerking hadden geplaatst.
Als we er een extra stap toevoegen aan het proces (bijv. Goedkeuren PSA) wordt de afstand wel berekend.
Vraag is dus, is deze extra stap noodzakelijk voor de berekening of doen wij iets niet goed.
Hoi @Marco van den Anker,
Inderdaad organisaties die kiezen voor de intergratie App -> Self Service doen dit meestal omdat ze aanvullende rubrieken hebben, zoals de reisafstand. In de meeste gevallen wordt het handmatig gemuteerd door de Personeel- of Salarisadministratie. Maar ook in de gevallen dat het wordt gescript vindt er toch vaak een controle plaats via een aparte stap, zoals Goedkeuren PSA.
Op de manier zoals jij het volledig wil automatiseren ben ik het niet eerder tegen gekomen. Maar fijn dat je het hebt getest. Ik ga intern verder uitzoeken of dat theoretisch (met een aanpassing) toch mogelijk zou kunnen zijn.
Ik kom er op terug.
Copyright 2019 Visma Community. All right reserved.