Verlofsysteem vraag

[scosec]

Ik ben nu aan het brainstormen over hoe een werk en verlof systeem in te richten. Nu heb ik wat input nodig hoe ik dit qua database structuur kan inrichten.

Scenario:
Verlof heeft een houdbaarheidsdatum. Niet opgenomen verlof vervalt of wordt uitbetaald na deze datum.

Wettelijk:
Van 2016-01-01 tot 2017-01-01 ( 160 uur )

Overwerk:
2016-01-01 tot 2021-01-01 ( 80 uur )

Totaal 240 uur

---------------------------

Verlof opname
2016-10-10 ( 40 uur )

Totaal 200 uur.

Na 2017-01-01 zou de verlof opname in principe van de ‘overwerk’ uren afgetrokken worden tenzij hij specifiek aan de wettelijk uren gekoppeld is. (omdat de eerdere verlofdagen dan verlopen zijn) Het liefst registreer ik blokjes/records verlof zonder deze specifiek aan de tabel met vrije data te koppelen.

Nu ben ik aan het kijken hoe ik iets dergelijks het beste kan inrichten. Hebben jullie hier bepaalde gedachten over hoe dit het beste is in te richten?

Alvast bedankt!

[Khallouki]

Wat zijn jouw eerste gedachten?

[masterathome]

Volgens mij ben je je niet helemaal bewust van welke enorme bak complexiteit hier achter zit. Je hebt bijv. te maken met wet en regelgeving m.b.t. houdbaarheid van bepaalde uren. Opgespaarde uren kun je tegenwoordig namelijk niet langer dan x aantal maanden gebruiken. Dus je moet denken in de richting van bakjes met saldi met een datum tot wanneer deze te gebruiken zijn of beter, wanneer ze zijn opgebouwd (in het geval dat de regelgeving in de toekomst wijzigt). Wil je dit allemaal hard gaan coderen? Of wil je een modulair systeem waar je nieuwe wetgeving middels een definitie kunt inlezen. Dat is nog maar een fractie van de zaken waar je rekening mee zult moeten houden.

[P.O. Box]

Ik weet niet of je het graag zelf wilt programmeren of dat je gewoon zo'n systeem nodig hebt, maar in het laatste geval kan ik https://reworkapps.nl/verlofapp aanraden...

[ Voor 6% gewijzigd door P.O. Box op 16-02-2016 10:16 ]

[scosec]

Bedankt voor je reactie.

In principe maak ik twee tabellen.

Eentje waarin het verlof geregistreerd staat en een tabel waarin de verlof opname geregisteerd staat. Ik zou zoals ik het nu zie die records met id matchen aan elkaar. Wanneer het verlof verloop kijk je welke uren je kunt matchen en kenmerk je de verlof aanvraag als zijnde ‘verwerkt’ of iets dergelijks.
Dat is wat ik nu in praktijk zou willen brengen. Maar wellicht zijn er betere opties en ben ik benieuwd of jullie hier betere ideeen over hebben.

@masterathome
De regels ben ik van de op de hoogte dat is inderdaad vrij complexe materie. Houdbaarheid varieert inderdaad aangezien je zit met wettelijke dagen, bovenwettelijke dagen en overwerk. (en nog een aantal variaties). Het zijn inderdaad diverse bakjes waar je mee werkt. Alleen het bakjes idee wil ik vanaf omdat het niet flexibel is. Juist door een dergelijke constructie op te zetten met een start en einddatum in verschillende records zou je theorisch gezien voorbereid zijn op elke situatie ongeacht hoe lang de dagen/uren houdbaar zijn

@p.o. box
Een kant en klaar systeem is naar gekeken maar voldoet niet aan de eisen. Dus dat wordt zelf bouwen. En voor ik daar mee begin wil ik graag even sparren met jullie

[masterathome]

Is het een uitbreiding van een bestaand systeem of wil je een nieuw systeem opzetten. Moet dit integreren/koppelen met een bestaand systeem? Welke gegevens zijn er beschikbaar zoals roosterinformatie, dienstverband-/contractinformatie? Moeten er nog controles gedaan worden door bijvoorbeeld de manager/leidinggevende? Dat is informatie die je allemaal moet weten alvorens je iets zinvols kunt zeggen over een database structuur.

Daarnaast ben ik erg benieuwd naar de reden achter dat je van het bakjes idee af wilt, waarom vind je het niet flexibel? Is het alternatief een tabel met alle mutaties? Waarop ga je muteren? Waar staan de saldi per medewerker? Als je een validatieslag wilt doen, waar staan de mutaties alvorens deze zijn goedgekeurd?

[DJMaze]

scosec schreef op dinsdag 16 februari 2016 @ 10:01:
Wettelijk:
Van 2016-01-01 tot 2017-01-01 ( 160 uur )

En wat als ik maar 30 uur per week werk?
En wat als ik ziek ben tijdens mijn verlof?

Die moet je ook allemaal registreren.

[ajakkes]

DJMaze schreef op dinsdag 16 februari 2016 @ 16:01:
[...]

En wat als ik maar 30 uur per week werk?
En wat als ik ziek ben tijdens mijn verlof?

Die moet je ook allemaal registreren.

Ook leuke:
Buitengewoon verlof.
Halverwege het jaar parttime gaan werken.
Maar is het niet zo dat als de houdbaarheid van verlof bijv. 36 maanden is, je alleen hoeft bij te houden hoeveel het max verlof is in die periode met eventuele wijzigingen van contract.

Dus 3 jaar x 192 uur = Max verlof.
Als het opgebouwde verlof > 576 uur. Dan verlof weggooien.

[DJMaze]

Eigenlijk is de basis heel simpel.
Tabel 1 Medewerkers contracten: van, tot, uren per week
Tabel 2 Medewerker werktijden: van, tot, totaaltijd in minuten (dit is je in/uit klok systeem)
Tabel 3 Medewerker verlof: van, tot, totaaltijd in minuten

Je kan daar vanalles mee.
Als iemand dus in januari al op vakantie is, dan is zijn totaal NEGATIEF
Dat werkt hij dan weer weg door de maanden er op te werken.

[Reinier]

DJMaze schreef op dinsdag 16 februari 2016 @ 19:59:
Eigenlijk is het heel simpel.
Tabel 1 Medewerkers contracten: van, tot, uren per week
Tabel 2 Medewerker werktijden: van, tot, totaaltijd in minuten (dit is je in/uit klok systeem)
Tabel 3 Medewerker verlof: van, tot, totaaltijd in minuten

Je kan daar vanalles mee.
Als iemand dus in januari al op vakantie is, dan is zijn totaal NEGATIEF
Dat werkt hij dan weer weg door de maanden er op te werken.

Je zult zoals gezegd ook iets met ziekteverzuim moeten. En dan wordt het ingewikkeld!

[DJMaze]

Klopt, maar je moet toch ergens beginnen.
Tabel 3 kan ook "afwezig" heten dan een kolom "reden" met een enum('verlof', 'ziek') of wat dan ook.
En ja, het kan inderdaad nog complexer
http://www.aedes.nl/conte...iedagen-zieke-werknem.xml

[ Voor 32% gewijzigd door DJMaze op 16-02-2016 20:15 ]

[scosec]

Daarbij ziekteverzuim, bijzonder verlof en ook nog eens voor BE en DE. Regeltjes genoeg dus het huidige systeem werkt met potjes maar dat mag helemaal op de schop. Ik heb vrijheid gekregen het te maken naar eigen inzicht. Nu ben ik dus aan het brainstormen met zoveel mogelijk input. Daarmee wil ik kijken welke weg dat ik ga bewandelen.

[PolarBear]

Doe jezelf een lol en betrek er mensen bij die ook inhoudelijk weten waar het omgaat. Ik heb dit eerder gezien dat een technisch perfecte oplossing is gemaakt voor een verlofadministratie maar niemand het uiteindelijk ook begreep.

Ik heb wel eens verlofuitzichten gekregen uit dat systeem die de maker ook niet binnen 5 minuten uitgelegd kreeg.

[masterathome]

Jij moet als uitvoerende, requirements krijgen van materiedeskundigen op het gebied van HR. Het lijkt erop dat je nu al aan het uitwerken bent wat jou op technisch vlak geschikt lijkt, terwijl er nog helemaal niet duidelijk is waar het functioneel aan moet gaan voldoen.

Als ik jou was zou ik dat wat jij omschrijft als 'vrijheid' niet als zodanig ervaren en zeker niet accepteren. Naar mijn ongezoute mening lijkt het er sterk op dat je het bos ingestuurd bent met een praktisch onuitvoerbaar project. Je staat als je het goed wilt doen aan de start van een project waarbij verschillende partijen betrokken zijn. Je hebt een opdrachtgever, een stuurgroep, een gebruikersgroep, materiedeskundigen, ontwerper(s) etc. Gezien de internationale aard waarbinnen de oplossing toegepast gaat worden zullen sommige partijen zowel in BE als in DE en NL zijn. Daar zal iemand de projectleiding voor zich op moeten nemen. Dan heb je het nog niet eens over of er bij al deze partijen wel draagvlak is om zo'n systeem te willen opzetten. Ik zou niet graag in jouw schoenen staan in ieder geval.

[Fr33z]

ik zou dit absoluut inkopen, dan hoef je de complexe materie niet zelf te onderhouden. Tenzij je graag monsterlijke stukken software jaarlijks naloopt en aanpast, dan is het natuurlijk wel leuk

[scosec]

Alle regels en dergelijke worden door HR aangeleverd. Hier zijn we van op de hoogte. Standaard oplossingen is naar gekeken maar voldoen niet. Aanvulling met maatwerk is ook niet succesvol gebleken. Vandaar de keuze voor inhouse ontwikkeling.

De 'vrijheid' zoals eerder omschreven is puur technische inrichting / programmering van de software. Dat is nog steeds een breedt begrip maar we moeten ergens een start maken.

[Knutselsmurf]

Ik zou om te beginnen met (iemand van) HR om de tafel gaan zitten, om op die manier een beeld te krijgen van alle mogelijke situaties waar je mee te maken krijgt. De regels als een pak papier van HR aangeleverd krijgen is niet voldoende, omdat voor de correcte toepassing aanvullende domeinkennis nodig is. Deze kennis heb jij als programmeur niet, of onvoldoende, maar is wél bij HR bekend.

Je kunt zoiets niet goed opzetten zonder intensief overleg met de klant, in dit geval de eigen HR-afdeling.

[Hydra]

scosec schreef op dinsdag 16 februari 2016 @ 10:23:

@p.o. box
Een kant en klaar systeem is naar gekeken maar voldoet niet aan de eisen.

Als je ze nu zou kunnen laten weten wat dit daadwerkelijk gaat kosten weet ik anders vrij zeker dat de eisen bijgesteld gaan worden.

[ Voor 68% gewijzigd door Hydra op 18-02-2016 19:42 ]

[scosec]

Er is besloten om dit in samenwerking met de BI afdeling aan te gaan pakken. Die zijn gewend te werken met complexere datastructuren dus dat gaat helemaal in orde komen.

Bedankt voor de input en reacties!

[TRON]

Ik ben zelf wel erg nieuwsgierig waarom bestaande pakketten niet voldoen