Hi @BasvandeVeen, hartelijk dank voor dit idee. Het was voorheen technisch idd mogelijk om ook voor P1xxxx rubrieken PY en PZ rubrieken te genereren. Maar omdat een juiste werking voor andere dan de P0xxxx rubrieken niet te garanderen was hebben we dat in de 2024-06 release aangepast.   Uit de releasenotes van 2024-06: De keten HRSS-HR Core Beaufort kent PY/PZ rubrieken waarmee in HRSS startdatums (Y) en einddatums (Z) aangestuurd kunnen worden. Een willekeurig voorbeeld is rubriek P00006 (Eindejaarsuitkering 1) waarbij PY0006 de startdatum van die rubriek vormt en PZ0006 de einddatum. Deze  PY/PZ-functionaliteit is alleen van toepassing op P0xxxx-rubrieken. Dit omdat 1 positie van de rubriekcode na de 'P' nodig is om het onderscheid tussen startdatum (Y) en einddatum (Z) te bewerkstelligen én de keten eenduidig moet kunnen achterhalen bij welke rubriek de PY/PZ equivalenten horen.  Het was echter wel mogelijk om voor andere Pxxxxx-elementen PY/PZ-rubrieken aan te maken en dat is niet gewenst.   We hebben de mogelijkheden om dit ook voor de niet P0xxxx rubrieken zoals P1xxxx en bijvoorbeeld eigen rubrieken open te stellen verkend, maar de impact daarvan is in relatie tot andere prioriteiten op de roadmap te groot. Daarom is de realisatie vooralsnog onwaarschijnlijk.   Wel zullen we zoveel als mogelijk rekening houden met deze behoefte aan PY/PZ rubrieken door bij de uitgifte van nieuwe rubrieken waarbij de waarde mogelijk een tijdelijk karakter heeft, deze in de P0xxxx range te laten vallen. ... View more

Ter informatie: we zijn intern aan het heroverwegen of Reporting -in tegenstelling tot wat we eerder dachten- voor dit onderwerp de best plek is om binnen Youforce te implementeren.  Mogelijk gaat dit toch binnen HR Core Beaufort plaatsvinden. Zodra we meer weten zullen we dat hier delen. ... View more

@René van Dijk, in dit geval komt dat doordat voor Youforce een nieuwe Recruitment API is ontwikkeld. Dit is een flinke verbetering t.o.v. de werking van de huidige integratie.   Bij Visma.net is geen nieuwe techniek beschikbaar, daar zou het gaan om het uitbreiden van de huidige integratie. Daarover lopen wel gesprekken met Peple.  ... View more

@BasvandeVeen (en @MHoekstra ) tenzij "het nieuwe aantal" natuurlijk 0 is... Voor een aantal "0" wordt geen variabele mutatie aangemaakt. Dus in het voorbeeld dat 5 thuiswerkdagen, 5 woon-werk bewegingen hadden moeten zijn, moet je dus echt ingrijpen en zelf de correctie toepassen. ... View more

Als de medewerker op het moment van indienen wel een actief dienstverband heeft, maar in de periode waarin het wordt aangevraagd is zelf de foutmelding "De medewerker heeft geen actief dienstverband" incorrect, maar dat zijn details. Beter zou zijn "In de aangevraagde periode heb je geen actief dienstverband" of "De medewerker beschikt in de aangevraagde periode niet over een actief dienstverband". Ik ben het met je eens dat de eerste melding eerder op een foutmelding lijkt waarbij er geen contact kan worden gemaakt met een server o.i.d. Dan krijg je de situatie dat medewerkers blijven proberen en op een gegeven moment gefrustreerd met een P&O Servicedesk of soortgelijke afdeling bellen ... View more

@PGorji ik zou je adviseren om in de workflow 2 startactiviteiten te maken. Eén die gestart wordt door actieve signalering en een mogelijkheid voor de manager (of een andere persoon) die dit handmatig opstart.  Wel is het goed om te achterhalen wat de reden is dat het signaal de workflow niet gestart heeft, als je dat niet kunt verklaren is er wellicht iets met het ingerichte signaal niet correct. ... View more

Hoi @BasvandeVeen Klopt dit had ik gelezen als oplossing en ook uitgevoerd maar het blijft toch staan helaas. Ik heb het geprobeerd met ADV en wettelijk verlof, maar er gebeurt niks.     ... View more

Beste @BasvandeVeen  Flex Benefits heeft de flexpakket parameter PARR_VerlofKopen_MaxSaldoInDagen. De standaardwaarde is 250 dagen. Deze parameter wordt gebruikt in de controle op het maximum verlofsaldo. Misschien kun je deze parameter gebruiken. De berekening is als volgt: Het programma berekent de som van de verlofsaldo's van de bronnen Verlofsoort 1 t/m Verlofsoort 4 plus de som van de keuzes voor verlof kopen voor alle toekomstige maanden. Het programma berekent het maximum verlofsaldo voor een medewerker door waarde van parameter PARR_VerlofKopen_MaxSaldoInDagen te vermenigvuldigen met de waarde van parameter PARR_WerkUrenPerWeek / 5 en met de deeltijdfactor van de medewerker. Als het berekende totale verlofsaldo groter is/wordt dan het berekende maximum verlofsaldo, dan toont het programma een rode stoplichtmelding.   Met vriendelijke groet, André Visschers ... View more

Lijkt hier opgelost met de release van 29-11 ... View more

@BasvandeVeen  Dat betekend dus alle KM woon-werk tegen een zelfde tarief vergoeden? ... View more

@Bastiaan Friederichs dank voor de terugkoppeling en uitleg! ... View more

Dit zou een goede toevoeging zijn in de app. Veel toezichthouders reizen naar locaties waarbij er niet altijd een huisnummer gekoppeld is aan de te bezoeken locatie.  ... View more

Zo te zien goed nieuws @BasvandeVeen: https://community.visma.com/t5/Releases-Youforce-Self-Service/Self-Service-September-2022/ta-p/518377#toc-hId--1629870028 ... View more

Beste @Former Member en @HeleenMogezomp ,   Inderdaad zoals @BasvandeVeen al heeft geopperd is het inderdaad wel mogelijk met de genoemde PY-rubrieken. Misschien kan @Jeroen Coret  vanuit zijn expertise nog toelichten of onderstaande inderdaad technisch mogelijk is (ook voor het veld uren) maar inderdaad ook onwenselijk voor veel organisaties vanwege onderstaande argumentatie.     Denk bijvoorbeeld aan het volgende scenario: Medewerker heeft vandaag (14-06-2022) een contract voor 24 uur Medewerker gaat vanaf 01-07-2022 32 uur werken tot en met volgend jaar 30-06-2023   In Self Service kan je inrichten: Reguliere uren mutatie (P01109) die wordt aangestuurd met  ingangsdatum (FS0060)  van 01-07-2022: 32 uur Via script met PY-rubriek (PY1109) en nogmaals rubriek voor uren  (P01109) per ingangsdatum 01-07-2023: 24 uur --> Op die manier komt in ''indirect muteren'' van HR Core Beaufort een mutatie voor 24 uur per 01-07-2023 te staan. Deze wordt pas verwerkt zodra de salarisproductie 07-2023 aanbreekt   Maar overleg goed met je consultant of dit voor jullie organisatie een gewenste situatie is. Want de praktijk leert dat er allerlei redenen kunnen zijn dat de afspraak met de medewerker veranderd. Bijvoorbeeld: Medewerker gaat naar andere afdeling/functie waarbij andere afspraken worden gemaakt (b.v. vast 36 uur) Medewerker gaat tussentijds met b.v. ouderschapsverlof waardoor afspraken rondom contract-uren ook weer wijzigen De afspraak leek tijdelijk, maar per 01-07-2023 worden er toch andere uren afgesproken In dergelijke gevallen wil je niet dat de geplande mutatie per 01-07-2023 naar 24 uur automatisch worden verwerkt vanuit ''indirect muteren'' zodra salarisperiode 07-2023 aanbreekt.   Dus een proces rondom tijdelijke uren met b.v. actieve signalering (in combinatie met starten van een workflow / rapportage) kan voor veel organisaties een beter passende oplossing zijn. Overleg dus vooral met je vaste consultant/ Customer Success Manager wat voor jouw organisatie de beste aanpak is.   Note: naast de overwegingen hierboven is het als organisatie die géén gebruik maakt van de HR Core Beaufort functie ''synchroniseren inzet 170150'' maar het inzet-scherm handmatig laat vullen in Self Service een extra aandachtspunt om na te gaan of het begrijpelijk is hoe het inzet-scherm gevuld moet worden. ... View more