Mijn Communities
Help
Raymond_de_Rozario
ACTIVE CONTRIBUTOR ***

Verzoek tot hernieuwd inzicht aangaande veldgrootte rubriek P00301

door Raymond_de_Rozario
Status: Afgewezen

In dit vorige idee werd door @Jeroen de Vree1 gevraagd of er kan worden gekeken naar de veldgrootte van rubriek P00301. Hierin werd in eerste instantie door @Frank JHM Poell op geantwoord dat dit een grote impact zou hebben op het datamodel en dan met name voor de in huis klanten. Een week later krijgt de melding de status afgewezen, zonder reden erbij.

 

Op dit moment heeft het veld een grootte van 25 posities. Er zijn binnen onze organisatie meer dan genoeg medewerkers die de grens van 25 posities bijna aanraken of er echt precies opzitten. Ook zijn er medewerkers die over deze grens heen gaan. De laatste heeft een geboortenaam van 34 posities. Dankzij de maximale grootte van dit veld en ons IAM systeem wat de medewerkersgegevens doorstuurt naar de verschillende systemen, staat deze medewerker nu met een onvolledige achternaam en e-mail adres in alle programma's. 

 

Deze medewerker heeft dan toevallig een deftige meerdelige geboorte naam. Maar er zijn ook veel mensen met een buitenlandse naam die "last" hebben van een meer dan lange achternaam.

 

Ik kan mij voorstellen dat het verkleinen van het veld gevolgen heeft en dat je dan dataverlies krijgt,  maar wat is de impact om het veld groter te maken? Ik denk dat een grootte van 50 posities meer dan genoeg moet zijn.

4 Opmerkingen
Raymond_de_Rozario
ACTIVE CONTRIBUTOR ***
door Raymond_de_Rozario

Bij deze wil ik toch nog aandacht voor deze melding vragen. Ik besef mij ook volledig dat een dergelijke wijziging niet eenvoudig zal zijn, maar vraag alleen of er dieper kan worden gekeken naar het issue. Natuurlijk zal dit ook afgesproken moeten worden met onze eigen ontvangende partijen. Ik heb nu een medewerker waarbij meer dan 25% van de naam wegvalt. En de kans dat iets dergelijks weer gebeurd, is aannemelijk. 

door Frank JHM Poell
Status changed to: Status: Nieuw

@Raymond_de_Rozario 

Bedankt voor dit idee. Helaas is de boodschap niet anders dan die gegeven bij de gerefereerde wens.

 

Het technisch doorvoeren van een datamodelwijziging is technisch idd niet zo spannend, maar de randzaken er omheen in geval de huidige hybride situatie waarin we te maken hebben met onPrem klanten en Online klanten maakt het een complexe actie. 

OnPrem klanten zullen in een dergelijk geval databasebeheer moeten inschakelen of inhuren om de benodigde acties uit te voeren, waarbij deze afgestemd moeten zijn op het moment waarop de betreffende release bij de klant wordt geïnstalleerd.  

Ter illustratie een aantal stappen die in een dergelijk geval uitgevoerd moeten worden:

  • exporteren data uit de betroffen tabel
  • script draaien om de tabel bij te werken
  • nieuwe release van BO4 installeren
  • opnieuw importeren van de data uit de betroffen tabel.

Omdat onPrem klanten zelf hun releases installeren hebben we vanuit Raet geen controle op het overgangsmoment naar de nieuwe versie. Dat zou betekenen dat we een periode 2 versies in de lucht moeten houden.

En tenslotte betreft dit niet alleen een aanpassing in Beaufort maar vooral ook in de systemen die Beaufort bedient. Zo kan in Gemal op dit moment slechts 34 posities worden vastgelegd.  En dat zal ook voor andere partijen als UWV, Arbo, roosterpakketten gecontroleerd en afgestemd moeten worden.

 

Ik hoop je hiermee voldoende geïnformeerd te hebben inzake de complexiteit en de reden waarom we in de huidige hybride onPrem/Online situatie in dit kader nog niet kunnen doen wat we eigenlijk wel zouden willen. 

 

Raymond_de_Rozario
ACTIVE CONTRIBUTOR ***
door Raymond_de_Rozario

Goedemorgen @Frank JHM Poell ,

 

Het is mij duidelijk dat het geen eenvoudige exercitie zal zijn, welke misschien meerdere jaren in beslag kan nemen. Zie ook mij opmerking Rubriek P0104 straatnaam string lengte aanpassen - Visma Community.

 

Wanneer meerdere instanties tegen hetzelfde probleem aanlopen, is er bijvoorbeeld een centraal overleg geweest om naar een gezamenlijke oplossing te kijken?

door Frank JHM Poell
Status changed to: Status: Afgewezen

@Raymond_de_Rozario zodra alle onPrem klanten over zijn naar Online is het inderdaad een goed idee in een breder kader de benodigde datamodelwijzigingen die nu helaas steeds moeten worden geparkeerd in kaart te brengen en te prioriteren.

Voor nu ga ik deze wens in ieder geval sluiten.