Ik ben bang dat je hetzelfde antwoord gaat krijgen als deze melding en deze
Er zijn mensen die hetzelfde probleem hebben met hun eigen naam. Ook dit veld mag maar 24 karakters bevatten. Dit zorgt er voor dat mensen met een onvolledige naam in verschillende systemen komen te staan. Dit gaat dan om rubriek P00301
Dat ben ik helemaal met je eens. Het "probleem" zit hem bij de "on prem" klanten. BoL klanten zou relatief eenvoudig kunnen zijn. Alleen schijnt de uitdaging in geval van de eigennaam te liggen in de samengestelde velden (getrouwde naam + eigennaam e.d.) die moeten dan ook worden vergroot. En dan werd als argument gegeven dat het exporteren naar derde partijen ook nog moet worden onderzocht. Maar de top 5 van langste straatnamen (en die zijn extreem, ik weet het) beginnen vanaf 46 karakters. Ik had laatst een medewerker met een eigen naam die meer dan 34 karakters was. Dit moet ook op een bijzondere manier worden afgekapt.
Hoe meer mensen reageren en kudo's geven hoe beter
Hoi @Raymond_de_Rozario@Mark Foster, bij de NP lopen we ook tegen dit probleem aan, maar dan op het gebied van plaatsnamen. In YFSS wordt op basis van een postcode en huisnummer combinatie een plaatsnaam aangemaakt en gevuld uit een Raet tabel, in die tabel zitten op dit moment 5 plaatsnamen die langer zijn dan 24, het maximale bereik op dit moment in Beaufort. Beaufort keurt deze mutatie af daardoor, maar dat is dus op basis van een waarde uit een eigen tabel 🤔
Als ik de help lees dan staat er omschreven dat een mutatie lengte kan worden opgerekt naar 50...dus ik zie het probleem niet.
@Mark Foster het is inderdaad zo zoals @Raymond_de_Rozario het zegt. Helaas kunnen we door onPrem klanten geen datamodelwijzigingen doorvoeren. Zodra alle klanten over zijn op Beaufort Online geeft ons dat veel meer mogelijkheden.
@Raymond_de_Rozario het migreren van onPrem naar Online heeft hoge prioriteit en er worden in dat kader grote stappen gezet. Het blijft echter een intensieve exercitie waarbij we -naast bijvoorbeeld de intern beschikbare migratie capaciteit- o.a. ook afhankelijk zijn van de timing op klantniveau zelf. Daarom is het lastig een harde deadline vast te stellen.
CSM is in de lead om de overgang met de klant te bespreken en in te plannen.
Zie eerdere opmerking mbt het kunnen doorvoeren van de benodigde datamodelwijzigingen.
Daarnaast is het zo dat niet alle partijen in de keten met Beaufort (zowel intern als extern (bv UWV), een langere straatnaam dan 24 posities ondersteunen. Het is dus niet afdoende alleen Beaufort hierop aan te passen.
@Frank JHM Poell Dat er moet worden gewacht tot iedere klant over is op BOL vind ik nog een goed argument, en die kan ik ook nog technisch "verwerken".
Ik vind het moeilijk te bevatten dat een overheidsinstelling als het UWV, de belasting of andere externe instellingen die moeten kunnen vertrouwen op o.a. correcte NAW gegevens tegen hetzelfde probleem aanlopen, waarbij een straatnaam niet langer mag zijn dan 24 posities.
Zoals ik ook al in andere posts heb aangegeven is niet alleen de straatnaam, maar ook de geboortenaam is een probleem. Deze mag in Beaufort niet langer zijn dan 25 posities. Ik kan mij gewoonweg niet voorstellen dat bijvoorbeeld een belastingdienst akkoord gaat met een veldlengte in hun systemen waarin een onvolledige geboortenaam komt te staan.
Je bent altijd super actief op de community, dus ik deel graag nog wat aanvullende achtergrond informatie (of gewoon een leuk weetje😊).
In de Youforce app kan je ook het adres wijzigen. Daarin komt soms de vraag 'hoe makkelijk was het om je adres te wijzigen'. Daarin gaf iemand aan dat hij/zij het vervelend vond dat de lange straatnaam niet paste. Op basis daarvan heb ik ook samen met mijn collega @Frank JHM Poell gekeken naar de lengte van de rubriek P0104 straatnaam (dit idee).
Daarnaast heb ik ook wat onderzoek gedaan naar de overheidsregelingen. En er is zelfs een officiële NEN normering uit de overheid. Deze is te vinden via:
Wat je hierin dus ziet dat de overheid het BAK (met een link naar Kadaster) verplicht om iedere straatnaam ook af te korten tot 24 posities. Het is dus niet alleen iets in HR Core Beaufort Online, maar dus in alle systemen van de overheid.
Dus met een knipoog😏, iedere keer als een Gemeente bedenkt om een nieuwe lange straatnaam te maken is die gemeente (vanuit de overheid) verplicht om ook een afgekorte versie van deze straatnaam te maken conform de NEN-norm 5825. Het is meer een leuk weetje, maar het laat zien dat een aanpassing die ook voor ons als Visma|Raet simpel lijkt (maak het veldje iets langer) soms veel verbanden heeft met voorschriften van de overheid en uitwisseling van gegevens met systemen van de overheid.
Ik probeer inderdaad mijn steentje bij te dragen aan de community. Deze informatie is niet alleen interessant voor mij, maar ik denk dat wanneer je er een kennisartikel van maakt, dat iedereen er wat aan heeft. Een "welke velden kunnen we de lengte niet van aanpassen vanwege overheidsredenen" document. Korte uitleg zoals bovenstaande, met daar de velden waarom het gaat.
Graag gedaan. Helaas is het niet zo makkelijk dat mijn collega Product Owners en ik één lijst hebben met al dit soort NEN Normeringen. Zoals in dit voorbeeld speelt het pas als we onderzoek doen naar de wens/feedback van de gebruiker om de straatnaam langer te maken. Misschien ook wel omdat het nu iets vaker voorkomt met nieuwbouw straten. Immers straatnamen zijn tegenwoordig vaak mooier dan 'kerkstraat, hoofdstraat en schoolstraat'.
Maar inderdaad goede feedback aan ons om dergelijke informatie misschien samen te vatten in een kennisartikel.
U moet een geregistreerde gebruiker zijn om hier een opmerking toe te voegen. Als u al geregistreerd bent, moet u zich aanmelden. Als u zich nog niet hebt geregistreerd, moet u zich registreren en aanmelden.
Visma Denemarken
Visma Finland
Visma Letland
Visma Nederland
Visma Noorwegen
Visma Zweden
Visma Developers & Partners
Visma Latijns-Amerika