@Sylvia Schilt bedankt voor je aanvullende informatie. Zou een daadwerkelijke oplossing dan niet meer liggen in het in sync brengen van Beaufort en HRSS qua personenpopulatie? Of bijvoorbeeld personen zonder actief dienstverband op enig moment in HRSS te verwijderen? ... Meer weergeven

Bedankt voor de aanvullende input, nemen we mee in de analyse! ... Meer weergeven

Ik kan hier helaas nog geen concreet tijdspad mbt implementatie benoemen. Dit geldt feitelijk ook voor de kosten: de File API zal in verschillende varianten (mogelijkheden) worden aangeboden, waarbij de basisvariant kostenloos is. Op dit moment wordt er hard gewerkt aan communicatie voor op de Community. Voor meer informatie kun je ook contact opnemen met jullie eigen Customer Success Manager. Wel kan ik aangeven dat de File API gereed is voor de volgende bestandstypen: -BINT bestanden -DPIA100 bestanden -Raet Betaalmanager -Datafeed -Gemal exports Deze set kan in de nabije toekomst op basis van behoefte worden uitgebreid. ... Meer weergeven

Hartelijk dank voor dit idee. Je noemt een specifieke concrete situatie waarbij P02273 een waarde 1 moet krijgen. We voorzien echter ook situaties waarbij een andere waarde dan 1 wenselijk is. Bovendien geeft een waarde 0 of leeg van P02273 aan dat Gemal terugvalt op een default waarde van deze code op werkgever niveau. Omdat deze redenen denken we dat dit niet eenduidig te automatiseren is.  ... Meer weergeven

Verkoop van verlof is niet aan een specifiek tijdvak verbonden maar aan het verlofrecht zelf. Om die reden is de huidige systematiek valide. Tevens is ons niet helder wat nou precies het verwarrende in deze is. Als een verlofrecht volledig wordt verkocht is het logisch dat het resterende recht 0 is. ... Meer weergeven

Hartelijk dank voor dit idee. We hebben de betreffende beschrijving er op nageslagen (Gemal release notes 06-2021) en die bevat met name werkgever codes welke niet worden onderhouden in Beaufort. Er is sprake van een beperkte set rubrieken op werknemerniveau. In die context is het standaard beleid om deze niet op standaard Raet schermen te plaatsen maar dit aan de klant zelf over te laten. Zowel qua daadwerkelijk gebruik van de rubrieken als samenstelling van de (eigen) schermen.   Wat betreft de opmerking over het scherm  "Transitie- / Ontslagvergoeding": in het kader van de IKV ontwikkelingen sluiten we niet uit dat dit soort gegevens wel op een apart scherm (niet gecombineerd!) geplaatst gaan worden.  ... Meer weergeven

Hartelijk dank voor dit idee. Voor eigen rubrieken is het sinds release 2021-09 al mogelijk referentiewaarden met een omschrijving van (maximaal) 50 karakters vast te leggen. ... Meer weergeven

Hartelijk dank voor dit idee. De wens is helder en we gaan onderzoeken wat de impact is om dit te realiseren. Op basis daarvan zullen we dit onderwerp inplannen. ... Meer weergeven

Hartelijk dank voor dit idee. We gaan dit onderzoeken en op basis daarvan bepalen we of en zo ja op welk moment we dit gaan realiseren. ... Meer weergeven

Hartelijk dank voor dit idee. In het verlengde van wat Karl al aangeeft is het mogelijk om dit soort gegevens uit externe systemen (bv AD) als indirecte mutatie te importeren. Als alternatief op de genoemde RVM route zou dit ook eenvoudig via de IKM (Import Kolom Mutaties) functionaliteit kunnen plaatsvinden. ... Meer weergeven

Hartelijk dank voor dit idee.  Omdat deze wens al geruime tijd bestaat en het een beperkt aantal of geen kudo's heeft, zal deze wens niet ingepland worden.   ... Meer weergeven

In de huidige Arbo berichtdefinities geven we zowel geboortenaam als partnernaam door. Deze specificaties geven echter geen ruimte om een voorkeur daarin uit te spreken.  Aanpassingen in deze Arbo berichtdefinities worden niet wenselijk geacht. Dit met name omdat we vanuit Visma|Raet inzetten op de nieuwere SIVI standaard. Op het moment dat Beaufort ook op deze SIVI standaard aansluit kunnen we deze wens -voor zover dan nodig- alsnog in overweging nemen.  ... Meer weergeven

Hartelijk dank voor dit idee. Omdat deze wens al geruime tijd bestaat en het een beperkt aantal kudo's heeft, zal deze wens niet ingepland worden. Daarnaast is de impact ook groot te noemen. We kennen in Beaufort geen constructie waarbij de werking gebaseerd is op werkgeverniveau waarbij incidenteel op werknemerniveau kan worden afgeweken.   ... Meer weergeven

Hartelijk dank voor dit idee. Helaas zien wij binnen afzienbare tijd geen plek op de roadmap voor dit idee. Dit in verband met andere prioriteiten. Daarom zal het idee niet ingepland worden. ... Meer weergeven

Hartelijk dank voor dit idee. De functionaliteit inzake 'zenden en ontvangen' wordt voor Online gebruikers op termijn vervangen door de file API.  Onderdeel van deze file API oplossing is dat het handmatig verplaatsen van DPIA100 bestanden niet meer nodig is. ... Meer weergeven

Hartelijk dank voor dit idee. We zien dat de juiste mutaties worden weggeschreven in de database. We gaan dit verder in onderzoek nemen om de impact op de exportlogica in kaart te brengen. Op basis daarvan kunnen we bepalen of en zo ja in welke vorm we dit idee kunnen gaan implementeren. ... Meer weergeven

Hartelijk dank voor dit idee. Ons is niet helemaal helder wat exact bedoeld wordt. Het is mogelijk om direct na actualiseren van TMT mutaties de verlofrechtberekening uit te voeren (obv stuurgeven BER_VRLF). Ook bij invoer in de Beaufort schermen zelf zullen bij aanpassing van de uren per week dan wel percentage deelbetrekking de verlofrechten opnieuw berekend worden. @Anonymous : kun je je idee wat meer toelichten? ... Meer weergeven

Hartelijk dank voor dit idee. De probleemstelling is niet helemaal helder in de zin wat de relatie is tussen de reiskosten die op 0,00 staan en de gevraagde verzuimduur. Wat dat laatste betreft: dat is een berekend gegeven wat niet wordt opgeslagen in een rubriek. Om die reden kan deze ook niet worden gebruikt in condities.   ... Meer weergeven

@Nicoline Koene Vos het overgangsmoment is nog niet bekend. Om die reden het vriendelijke verzoek te zijner tijd de wens opnieuw op te voeren (als deze dan nog steeds van toepassing is c.q. nog niet standaard in de SIVI implementatie is opgenomen). ... Meer weergeven

Uit de analyse is gebleken dat aanpassing in de huidige EDI oplossing (obv EDIFACT) niet wenselijk wordt geacht. Dit met name omdat we vanuit Visma|Raet inzetten op de nieuwere SIVI standaard. Op het moment dat Beaufort ook op deze SIVI standaard aansluit kunnen we deze wens -voor zover dan nodig- alsnog in overweging nemen.  ... Meer weergeven

Hartelijk dank voor dit idee. Je kunt de omschrijving aanpassen via functie 'Standaard rubrieken'. Bij de start van deze functie verschijnt een waarschuwing die je kunt wegklikken. Wel wordt geadviseerd zo veel mogelijk de Raet inrichting te blijven volgen. Het aanpassen van de omschrijving kan echter weinig kwaad. Overigens zal een aanpassing van de rubriekomschrijving dan wel vensteromschrijving niet in alle gevallen leiden tot een andere weergave in het venster zelf. ... Meer weergeven

Hartelijk dank voor dit idee. De gewenste situatie is al mogelijk op de volgende wijze: Definieer eigen rubriek van gegevenssoort FU waarmee u het opleidingsniveau wilt registreren. Dit kan zowel met als zonder referentietabel Definieer een eigen scherm van het type A en gegevenssoort FU en voeg daar de nieuwe eigen rubriek aan toe. Autoriseer het eigen scherm Ga naar de onderhoudsfunctie functie (203001) Je ziet daar dan een extra knop 'Vrije geg.' Als je daar op klikt verschijnt een scherm waarin je het opleidingsniveau per functie kunt vastleggen   ... Meer weergeven

Hartelijk dank voor je idee. Er is in Beaufort rubriek P00323 (Startdatum AOW pensioen) aanwezig. Deze is terug te vinden op het tabblad 'Overige gegevens' in het scherm 'In- en uitdienst gegevens'. Hier kan uiteraard ook op gesignaleerd worden.     ... Meer weergeven

Hartelijk dank voor dit idee. We zullen dit idee op de roadmap plaatsen. De functie 700010 Roltoewijzing persoon zal worden uitgebreid met de mogelijkheid om ook collectief een einddatum door te voeren bij alle afdelingen van de geselecteerde persoon. Het moment van opleveren zal op standaard wijze in de release notes worden gemeld.   ... Meer weergeven

Hartelijk dank voor dit idee. We zouden dit veld op het scherm 'Bevalling' muteerbaar kunnen maken. Hiermee wordt de kans op foute invoer uiteraard wel vergroot. @Anonymous @Anonymous : voorzien jullie hier significante problemen in? Los daarvan: het veld is een berekend veld wat op basis van andere invoer weer herberekend kan worden. Dit is op zich een legitieme actie waardoor de eerdere handmatige wijziging overschreven wordt. ... Meer weergeven

Hartelijk dank voor dit idee. We zullen de impact van deze wijziging analyseren. Op basis daarvan kunnen we bepalen of en op welk moment we dit idee gaan implementeren. ... Meer weergeven

Hartelijk dank voor dit idee. We hebben technisch bekeken wat de impact zou zijn om dit te kunnen ondersteunen. Helaas vereist dit o.a. datamodelwijzigingen wat op dit moment blokkerend is voor daadwerkelijke realisatie. Huidige mogelijkheden zijn inderdaad een kopie van de signaaldefinitie dan wel het gebruik maken van de externe ontvangers (vast te leggen in de signaaldefinitie). Bijkomend voordeel van dat laatste is dat de actienemer eenduidig blijft.  ... Meer weergeven

Hartelijk dank voor dit idee. Waarschijnlijk bedoel je in Gemal het automatisch ontkoppelen van dienstverbanden uit dienst in salarisperiode 1?  In Beaufort zijn we niet voornemens dit proces ook automatisch te gaan ondersteunen ivm andere prioriteiten. Een workaround zou kunnen zijn: Definitie eigen scherm met de rubriek P02950 (gekoppeld DV) Procedure aanmaken met het selectiescherm DV en bovengenoemde eigen scherm Selectie maken op datum uit dienst en P02950=1 Voor het selectieresultaat in het eigen scherm de rubriekwaarde van P02950 op 0 zetten ... Meer weergeven

Hartelijk dank voor dit idee. We zijn in de hele keten een onderzoek gestart naar de impact van deze wijzigingen. Op basis daarvan wordt bepaald of en wanneer we de uitbreiding van de opties kunnen realiseren. ... Meer weergeven