PY-rubriek (afwijkende ingangsdatum) kunnen gebruiken wanneer lege waarde wordt geëxporteerd (SLSR-I-587)

[Anonymous]

Het is met de PY-rubrieken mogelijk o een rubriek een afwijkende startdatum te geven. Helaas werkt dit alleen als de betreffende rubriek daadwerkelijk een waarde te exporteren heeft. Wanneer de te exporteren rubriek leeg geëxporteerd moet worden met een afwijkende ingangsdatum, dan lukt dat niet.
Voorbeeld: rubriek P00830 (datum uit dienst) wordt bij omzetting naar contract voor onbepaalde tijd leeg gemaakt. Hierbij is het niet mogelijk om een afwijkende startdatum mee te geven.

Als tijdelijke oplossing kiezen we er nu voor om rubriek P00830 de waarde 31-12-2999 mee te geven, om zo toch gebruik te kunnen maken van een afwijkende startdatum.

Mooier is het als je ook een afwijkende startdatum kunt toepassen wanneer de rubriek leeg wordt aangeleverd.

Zie ook change 1026265.

[Former Member]

Hartelijk dank voor je idee. Het toegekende nummer is: SLSR-I-587

[Anonymous]

Wij lopen hier ook tegenaan! Eigenlijk vind ik dit meer een bug dan een wens, maar lijkt me goed dit nog eens extra onder de aandacht te brengen.

[Anonymous]

Ik heb hem ook ooit ingeschoten als een incident. Dat heeft tot resultaat dat er een change van gemaakt is (zie change nummer in mijn post). Maar dat was in juli 2019. Nog een aantal keren om een status update gevraagd. De laatste update dateert van december 2019: "Er is nog geen oplostermijn bekend. Er zijn nog meerdere high issues, die eerst opgelost moeten worden. Ik zal in ieder geval opnieuw aandacht vragen voor deze request."

[Anonymous]

Herkenbaar verhaal, wij hebben ook al tijden staan als melding. Is toen ook toegevoegd aan de change.

[Anonymous]

Hoi Rianne, zou je me willen mailen op j.h.spoelman@isala.nl? Ik zou graag even met je sparren over dit onderwerp.

[Anonymous]

Wij (Hogeschool Utrecht) hebben dit probleem ook. Ik ben blij om te zien dat we niet de enige zijn. Mijn melding ligt al sinds 1 juli 2019 bij Product development. Misschien goed om de krachten te bundelen zoals Jarik al van plan is. Ik vermoed dat het bij Raet geen prio krijgt, omdat niet heel veel klanten in een formulier meerdere opties combineren. Dan bedoel ik dat je een omzetting naar vast kan doorgeven en tegelijkertijd een urenwijziging of afdelingswijziging. Naar mijn weten is het inderdaad een bug, aangezien het alleen mis gaat als je een lege waarde wilt doorzetten. Dan pakt het systeem automatisch FS0060 en dat wil je niet.

[Anonymous]

Wij herkennen dit probleem ook.

[Anonymous]

Dit geldt ook voor de PZ rubriek. De toekomst mutatie wordt standaard met een 0 gemuteerd. Dit geeft onnodige waardes in het systeem. De wens is om ook de nulstelling te wijzigen in een leeghaling/verwijdering