PY/PZ rubrieken altijd mogelijk maken voor elke rubriek

[Misty]

Op dit moment kun je voor rubrieken die NIET beginnen met een 0, geen PY/PZ rubrieken aanmaken en dus ook geen begin en einddatum vastleggen. Dit is heel onhandig. 
Ook in de toekomst zullen er steeds meer rubrieken zijn die niet met een 0 starten dus wordt dit probleem alleen maar groter. In Self Service worden niet meer dan 6 tekens toegestaan.

Ik zou dit graag opgelost zien. 

[Anonymous]

Heel onhandig, zeker voor de rubriek P13205

[Anonymous]

Erg jammer en zeker onhandig dat bij deze rubriek niet gewerkt kan worden met de PY en PZ mogelijkheid.

[Daniel_van_Bendegem]

Beste @Misty 

Bedankt voor het indienen van dit idee. Ik heb dit met mijn collega's besproken. De P-rubrieken worden aangeleverd door HR Core Beaufort. Zij hebben ook ingezien dat voor sommige rubrieken het nodig is om de PY en PZ waardes door te kunnen geven. Zij zijn daarom nu bezig dit aan te passen. Ik zal daarom voor nu deze melding hier afsluiten met de status Gerealiseerd.

HR Core Beaufort is bezig om verschillende P-rubrieken aan te passen, waaronder de P15013 en P13205. Deze wijzigingen zullen begin volgend jaar uitgebracht worden. Mochten er andere rubrieken zijn waarvoor dit ook nodig is wil ik u vragen dit te bespreken met HR Core Beaufort team. U kan hun bereiken door een ITRP ticket bij hun aan te maken. Op deze wijze kan u ook verder op de hoogte gehouden worden van de voortgang hierop.

[Frank JHM Poell]

Goedemorgen @Misty,

Ik wil graag een kleine nuance op de reactie van Daniel toevoegen.
De huidige werking m.b.t. PY/PZ rubrieken kent een aantal beperkingen. De PY/PZ functionaliteit is destijds opgezet ten behoeve van een beperkt aantal Raet salarisrubrieken (P*) van gegevenssoort PS en/of DV. In mei 2021 hebben we op basis van klantinput de beperking m.b.t. 'aanleveren aan Gemal' opgeheven.

Echter de overige beperkingen zijn nog steeds van kracht. Omdat we 1 positie van de rubriekcode na de 'P' nodig hebben om het onderscheid tussen startdatum (Y) en einddatum (Z) nodig hebben werkt deze functionaliteit - zoals jezelf al aangeeft- alleen voor rubrieken in de P0xxxx range. Dus P00001 t/m P09999 kunnen gebruikt worden voor PY/PZ omdat we c.q. HRSS dan eenduidig kunnen achterhalen bij welke rubriek die PY/PZ equivalenten horen. Die positie staat in de echte rubriek immers altijd voor de '0'.

We hebben een analyse uitgevoerd of we in een alternatieve vorm deze beperking kunnen omzeilen. Dergelijke alternatieven kennen echter weer hun eigen beperkingen. Vooralsnog helaas dus nog geen volwaardig alternatief.

We snappen echter de toegevoegde waarde van deze functionaliteit bij andere relevante stamrubrieken. We houden daar dan ook (daar waar mogelijk) rekening mee bij de uitgifte van nieuwe rubrieken. Ook zullen we selectief rubrieken die niet in de P0-range vallen maar die wél een breed draagvlak hebben, transformeren naar de P0-range zodat de PY/PZ functionaliteit toegepast kan worden. Dit zullen we doen op basis van input op het Ideeën portaal van HR Core Beaufort.

[Misty]

@Frank JHM Poell dank voor je toelichting.
Ik wist inderdaad dat het alleen mogelijk was voor rubrieken die beginnen met P0, vandaar dat ik ook dit idee had aangemaakt en dat is gehonoreerd en door ons nu in gebruik genomen.

Ik heb hetzelfde gevraagd voor de rubrieken m.b.t. aanvullend geboorteverlof via de SD, (#33130487), maar tot op heden wordt daar geen gehoor aan gegeven. Dit is toch ook een verlofvorm die alle organisaties aanbieden en dus voor meer organisaties praktisch is om aan te passen? Wij zijn bij de HU wellicht wat verder met digitaliseren en hebben er daarom meer 'last' van dat dit er nog niet is omdat wij geen maar weinig mensen meer hebben die handmatig zaken invoeren. 

Kun je zorgen dat het voor aanvullend geboorteverlof ook geregeld wordt?

[Misty]

@Frank JHM Poell , heb je nog een respons voor me?

[Frank JHM Poell]

Hallo @Misty, rubriek P12146 (Uren aanvullend geboorteverlof) is gekoppeld aan exportcode (c.q. Gemal invoercode) 02146.

In Gemal kan deze code alleen variabel worden opgegeven: stam opgave vanuit BO4 wordt dus afgekeurd. 

De optie 'stam' wordt vanuit Gemal bewust niet ondersteund omdat het functioneel vooral tot vragen zal leiden. Met de variabele code geef je het absoluut aantal uur verlof op dat is opgenomen in die maand. De ene maand duurt langer dan de andere, dus ook bij een vast verlofpatroon schommelt het aantal uur automatisch.