Mijn Communities
Help
PaulvanAchteren
CHAMPION *

Release 2025-05 - Herreken van verlof bij intrekken van verlof

door PaulvanAchteren (Bijgewerkt ‎29-04-2025 09:08 door Nathalie Scheidt VISMA )
Status: Gerealiseerd

Goedemorgen,

 

Ik heb dit idee al eens eerder ingediend en probeer het nogmaals, omdat ik het van zeer groot belang acht dat dit gebeurt.

 

Situatie

Wanneer een medewerker verlof aanvraagt wordt dit automatisch afgeboekt van het verlofpotje met de eerste vervaldatum. Dat is heel fijn en is ook de bedoeling.

 

Stel, een medewerker dient aan het begin van 2024 alle verlofaanvragen in voor het hele jaar dan wordt eerst afgeboekt van het wettelijk verlof wat per 1-7-24 vervalt (restant uit 2023), daarna van bv. ADV en/ of Bovenwettelijk verlof met een vervaldatum van 1-1-25.

 

Medewerker had op 1-1-24 nog een wettelijk verlofsaldo met vervaldatum 1-7-24 van 100 uren.

 

Medewerker heeft het volgende aangevraagd:

- 2-1-24 t/m 5-1-24: 32 uur van Wettelijk verlof met vervaldatum 1-7-24

- 12-2 t/m 16-2: 40 uur van Wettelijk verlof met vervaldatum 1-7-24

- 22-4 t/m 26-4: 40 uur, waarvan 28 uur van Wettelijk verlof met vervaldatum 1-7-24 en 12 uur van ADV met vervaldatum 1-1-25

- 17-6 t/m 21-6: 40 uur van ADV met vervaldatum 1-1-25

 

Wanneer de medewerker nu het verlof weer intrekt voor de periode 12-2 t/m 16-2, wat was afgegaan van het potje wettelijk verlof met vervaldatum 1-7-24, dan worden deze uren weer bijgeboekt in dit potje. Hierdoor komt het voor dat er vervolgens uren vervallen per 1-7-24 wat niet correct is, omdat de medewerker de uren wel heeft genoten, maar deze zijn van een ander potje afgegaan (17-6 t/m 21-6 van ADV en ook 22-4 t/m 26-4 12 uur van ADV met vervaldatum 1-1-25).

 

Wens

Door bovenstaande situatie vervallen er onterecht uren bij medewerkers. De medewerker heeft de uren immers wel genoten. Ik zie dit als een fout binnen de applicatie en wij worden er regelmatig mee geconfronteerd. Dit vraagt dan altijd om handmatig ingrijpen.

 

Ik zou graag zien dat Self Service/ HR Core zelf gaat herreken. Dus wanneer er verlof wordt ingetrokken, dient het systeem ook te gaan kijken naar alle reeds gedane en geëxporteerde verlofaanvragen in het jaar en de afboeking aanpassen naar de nieuwe situatie.

 

Ik ben benieuwd of er meerdere hr professionals tegen dit probleem aanlopen en de vraag is dan ook om dit idee te liken.

 

Groet,

Paul

4 Opmerkingen
Erik83
CONTRIBUTOR **
door Erik83

Naar mijn mening een terecht opmerking en dit zou zeker automatisch herrekend moeten worden als je het mij vraagt. Een verlofregistratiesysteem anno 2024 moet dit makkelijk automatisch kunnen. 

 

 

MandyBottelberghs
CONTRIBUTOR ***
door MandyBottelberghs

Zeer goed idee, gaat heel veel werk schelen met correcties

PaulvanAchteren
CHAMPION *
door PaulvanAchteren

Ik heb vorige week t.a.v. dit probleem een ticket ingediend en ben weer hiernaartoe verwezen.

Dit probleem speelt nu al een aantal jaren en naar mijn mening kan dit echt niet langer zo. Er vervallen onterecht uren bij medewerkers, als aanbieder en verantwoordelijke (Visma) van de applicatie kun je dat echt niet accepteren en dient dat met spoed te worden opgelost.

 

Inmiddels heeft dit ticket 14 likes en het wordt dan ook hoognodig tijd dat dit wordt opgepakt. Ik verwacht dan ook dat dit probleem met spoed wordt opgelost door Visma.

 

Inhoud vanuit het ticket:

 

  1. Ticket Unica

Goedenavond,

 

Ik wil hiervoor verwijzen naar mijn ingediend idee d.d. 27-6-2024, https://community.visma.com/t5/Ideeen-YouServe/Herreken-van-verlof-bij-intrekken-van-verlof/idi-p/66.... Dit idee heeft inmiddels 12 'likes' en het wordt de hoogste tijd dat hier een keer wat mee gebeurt. Ik heb dit nl. al een aantal jaren aangegeven en ook met de afsluiting van 2024 is weer geregeld naar voren gekomen dat er verlof onterecht bij medewerkers is vervallen. Bij zo'n 80 medewerkers is dit gebleken en ik vind het eigenlijk onbestaanbaar dat hier na al die jaren nog steeds niets mee is gedaan.

 

Er zijn bij ons gevallen bij waar er bij een medewerker ruim 100 uren onterecht waren vervallen. Je praat dan wel, wanneer je dat omzet naar geld, over een bedrag van rond de 3.000 euro. Ik vind dat je als leverancier van het systeem dat niet kunt verkopen en dat jullie ervoor verantwoordelijk zijn dat het systeem op de juiste wijze afboekt en dat het systeem bij het intrekken van verlof dus ook de reeds gedane aanvragen gaat 'herrekenen'/ afboeken van het juiste potje.

 

Ik hoor graag van jullie wat jullie hiermee gaan doen. Ik heb hier al eens eerder een ticket voor ingediend en op jullie advies hiervoor een idee ingediend. Zoals aangegeven, het idee heeft nu 12 likes. Wanneer wordt het gepland om door jullie te worden opgepakt?

 

Graag een reactie.

 

2. Reactie Visma

Ik heb dit besproken met product ontwikkeling en daar werd aangegeven dat ze druk bezig zijn om te kijken naar alle ideeen op de community. Ik kan niet zeggen wanneer dit opgepakt zal worden. Wat je hiervoor kan doen is een reactie geven op jouw idee. Dit zal sneller werken dan een ticket indienen.

Wij bij het service center kunnen helaas niks met tickets wat eigenlijk een wens is.

 

3. Reactie Unica

Bedankt voor je reactie.

 

Ik ga echter niets meer doen met het Idee gebeuren. Daar ben ik totaal niet tevreden over. Puur om het idee ook weer te kunnen terugvinden op de Community vind ik al een behoorlijke crime....

 

Dit probleem signaleer ik nu al een aantal jaren en feitelijk is het helemaal geen idee, maar een (grote) fout in de applicatie (waar de medewerker de dupe van wordt).

 

Ik verwacht dan ook van Visma dat dit nu eens op korte termijn wordt opgelost en laat dit ticket dan ook open staan totdat dit probleem is opgelost. Graag hoor ik wat jij / jullie hierin verder kunnen betekenen of dat ik beter bv. kan escaleren richting onze Customer Service Manager.

 

4. Reactie Visma

Ik heb te horen gekregen van product development dat op dit moment het systeem zo werkt. Hiervoor moet dus echt een idee ingeschoten worden via de community. Het is zo dat er de laatste tijd echt wel meer mee gedaan wordt, dit was in het begin inderdaad niet zo.

 

Ik kan dit helaas niet snel oplossen dus dan zou je dit in dit geval beter kunnen gaan escaleren via jullie customer delivery manager.

 

5. Reactie Unica

Dank voor je reactie!

 

Ik snap heus dat jij er verder niets mee kan hoor, maar ik wil het ticket wel laten open staan, totdat dit issue is opgelost, op deze manier verlies ik het dan ook niet uit het oog.

 

De reactie van Product Development ben ik het niet mee eens. Zeggen dat het systeem op dit moment zo werkt is voor mij allang geen optie meer, die reactie heb ik nl. 2 a 3 jaar geleden ook al gehad. Dat constateren is 1, maar de praktijk is dat hierdoor uren bij mensen onterecht vervallen. Ik vind dat Visma als leverancier en dus verantwoordelijke van de applicatie dat niet moet accepteren en dat dus met spoed oplossen. Aangezien dit een aantal jaren geeleden door mij al is aangegeven en er nog nooit wat mee is gedaan, heb ik het idee dat Visma het niet belangrijk vind ofzo en dat vind ik raar, want je pakt eigenlijk onterecht wat van mensen af, dat is een kwalijke zaak.

 

 

door Nathalie Scheidt
Status changed to: Status: Gerealiseerd

Je wens heeft de status "Gerealiseerd" gekregen. Tot ons genoegen kunnen we mededelen dat de gewenste functionaliteit reeds gereleased is. De realisatie is onderdeel van Release 2025-05.

 

Releasenotes:

Verlof - Verlofsaldi herverdelen in de juiste potjes (Core)

Oorzaak

Het kon voorkomen dat bij een verlofaanvraag of verlof intrekking met terugwerkende kracht, de opgenomen verloven onterecht uit een potje met een latere expiratiedatum waren opgenomen. Hierdoor was het mogelijk dat een verlofsaldo onterecht (op een eerdere datum) verviel. Deze verkeerde manier van afboeken hebben wij in deze release opgelost. 

Oplossing

Na deze release wordt bij elke verlofaanvraag (welke op automatisch afboeken is gezet) of verlof intrekking bij een medewerker gecontroleerd of de opname uit het juiste verlofpotje wordt gedaan. Dit is het potje dat als eerste vervalt. Uiteraard is dit alleen van toepassing op verlofsoorten binnen de regeling waarbij is aangegeven dat deze automatisch afgeboekt mogen worden. Ook als een nieuw verlofjaar wordt gestart, zullen de reeds gedane verlof opnames voor het nieuwe jaar worden getoetst en vanuit het juiste potje worden afgeboekt.

Indien een verlofaanvraag niet op automatisch afboeken is gezet, maar bewust een verlofsoort is gekozen, zal deze altijd van de gekozen verlofsoort worden afgeboekt. Voor aanvragen die op automatisch afboeken gebeurt dit altijd uit het potje met de expiratiedatum die als eerste vervalt voor deze verlofsoort. Hierdoor kan het dus nog wel voorkomen dat er verlofsaldo beschikbaar is uit een ander verlofsoort-potje, met een vroegere expiratiedatum. 

Reeds bestaande verlofaanvragen worden niet automatisch herverdeeld. Dit gebeurt alleen bij een nieuwe verlofopname of een verwijdering. Op de pagina Medewerker > Verlof > Verlofsaldo is de knop ‘herverdelen’ geïntroduceerd. Met deze knop kunnen alle verlofaanvragen van een medewerker vanaf het gekozen verlofjaar opnieuw worden beoordeeld en herverdeeld. Dit geldt voor het geselecteerde jaar en de daaropvolgende jaren voor deze medewerker. Let op: na de herverdeling kan dit niet meer ongedaan worden gemaakt.

Ook is het mogelijk om het huidige verlofjaar te corrigeren voor een bedrijf. Dit kan door op de plus knop te klikken en vervolgens te kiezen voor ‘Huidig verlofjaar corrigeren’ bij: Instellingen > Verlof > Verlofrecht toekennen. Hierdoor zullen alle verlofaanvragen van de medewerkers van dit bedrijf worden beoordeeld en herverdeeld. Deze actie kan enige tijd in beslag nemen. Tijdens dit proces is het mogelijk dat een verlofsaldo bij een medewerker tijdelijk op 0 staat, omdat de herberekening wordt uitgevoerd. Als er op datzelfde moment vanuit de app of vanuit Self Serve een verlofopname wordt toegevoegd, zal deze uitvallen omdat er geen saldo beschikbaar is. Wij adviseren dan ook om deze actie uit te voeren op een moment wanneer de kans op nieuwe verlofaanvragen minimaal is.