Controle op niet verwerkte mutaties vanuit HRSS naar Bo4 omdat de rubriekwaarden gelijk zijn echter ingangsdatum vanuit HRSS eerder was dan de laatste mutatie op deze rubriek (HCB4-I-50)

[Former Member]

Situatiebeschrijving:

Er zijn twee mutaties langs elkaar heen gelopen en daardoor niet goed verwerkt in Bo4
Medewerker gaat minder uren werken per in eerste instantie 1 oktober 2016. Deze mutatie staat al wel klaar in Selfservice echter de flow is niet op tijd afgerond. Begin oktober is de urenwijziging handmatig (om wat voor reden dan ook) in Bo4 gezet. Vervolgens is de mutatie in Selfservice wel afgerond, echter is de ingangsdatum veranderd van 1 oktober naar 1 september. Bo4 verwerkt deze mutatie vervolgens niet.

De reden dat Bo4 deze mutatie niet verwerkt komt omdat B04 als eerste kijkt of de waarde aangepast moet worden en als dat zo is, dan pas kijkt B04 naar de ingangsdatum van de mutatie.

Er zijn natuurlijk heel veel rubriekwaarden op een formulier die niet verwerkt hoeven te worden omdat ze niet gewijzigd zijn. Echter wanneer de rubriekwaarde niet verwerkt wordt terwijl er na de ingangsdatum van de mutatie in HRSS de waarden in Bo4 veranderd is, zou ik dat wel graag willen weten. Zodat het bovenstaande incident ondervangen kan worden.

Mochten er vragen, opmerkingen of oplossingen  op het bovenstaande probleem zijn, dan hoor ik die graag!

Met vriendelijke groet,

Sandra van den Nieuwendijk

[Former Member]

Voor de geschetste situatie is geen functionele oplossing beschikbaar. De standaard werking van Beaufort is al sinds jaar en dag: als de actuele waarde niet verandert dat is er ook geen actie nodig. Zo werkt niet alleen Indirect muteren, maar ook het onderhoudsscherm in Beaufort reageert op dezelfde wijze. Deze keuze is destijds gemaakt om het aantal regels voor logging, historie en salarismutaties te beperken.

Er is wel een work-around, waarbij de waarde eerst moet worden gewijzigd en daarna op de juiste waarde moet worden teruggezet voorzien van de juiste ingangsdatum.

Een eenvoudige oplossing (altijd alles verwerken en dus ook loggen) heeft hier een ongewenst neveneffect.

Een idee is hier wellicht de introductie van een nieuwe soort STAM mutatie, waarbij het actuele gegeven niet wordt gewijzigd. Alleen de historie, de mutatieverantwoording en de salarismutatie worden dan aangepast met de opgegeven ingangsdatum. Deze verandering is wel ingrijpend en heeft ook effect op HR Self Service en andere aanleverende systemen. De kans dat dit wordt gerealiseerd is momenteel niet groot.

[Frank JHM Poell]

Wij realiseren ons dat het weer even geleden is dat er een update op dit idee is geweest.

Inhoudelijk is de gegeven opmerking correct.Omdat er in de tussentijd geen extra kudo's van andere klanten zijn toegevoegd, gaan we er van uit dat dit idee op dit moment niet (meer) relevant is.
Om die reden wordt dit idee afgewezen en gesloten.