informatievlaanderen / oslothema-loongegevens Goto Github PK

De relatie {Persoon inkomsten Inkomst} zou enkelvoudig, i.e. "inkomst", moeten zijn in lijn met de OSLO conventie.

Alle eigenschappen van de klasse Arbeidsloon zijn verplicht. Is het dan het idee om steeds een nulwaarde mee te geven bij die velden die vaak niet gebruikt worden? Dit kan de payload nogal "onnodig" verbose maken, bv.

"Arbeidsloon.premie": {
  "type": "Geldbedrag",
  "Geldbedrag.valuta": "http://publications.europa.eu/resource/authority/currency/EUR",
  "Geldbedrag.waarde": 0
},
"Arbeidsloon.supplementaireBelastbareBedragen": {
  "type": "Geldbedrag",
  "Geldbedrag.valuta": "http://publications.europa.eu/resource/authority/currency/EUR",
  "Geldbedrag.waarde": 0
},
"Arbeidsloon.supplementaireNettoBedragen": {
  "type": "Geldbedrag",
  "Geldbedrag.valuta": "http://publications.europa.eu/resource/authority/currency/EUR",
  "Geldbedrag.waarde": 0
},
"Arbeidsloon.vakantiegeld": {
  "type": "Geldbedrag",
  "Geldbedrag.valuta": "http://publications.europa.eu/resource/authority/currency/EUR",
  "Geldbedrag.waarde": 0
},

Een andere mogelijkheid zou zijn om deze velden optioneel te maken. Dan is het natuurlijk wel minder duidelijk of de waarde niet gekend is, dan wel nul is. Anderzijds is het weglaten van nulwaardes ook wel hoe het vandaag gebeurt in de praktijk op de fysieke (PDF) loonfiches, als ik me niet vergis.

Een aantal zaken die bvb bij OCMW Gent ook wel mee bekeken worden om "loon" te berekenen vinden we niet terug in het model. Ik lijst ze hieronder op met kort een woordje uitleg hoe deze bij de berekening van het leefloon vervat worden.

- wijk-werken: Wijk-werken is de vervanger van PWA in het Vlaams Gewest
Het gedeelte van het loon ten laste genomen door de uitgever van de Wijk-werkcheques en de eruit voortvloeiende vergoedingen zijn vrijgesteld voor een bedrag van 4,10 EUR per niet-ontwaarde Wijk-werkcheque. Hiervoor moeten deze voorwaarden wel voldaan zijn:
• betaald aan betrokkene;
• voor werkzaamheden verricht in het kader van een Wijk-werkovereenkomst;
• overeenkomstig de terzake geldende reglementering.
Let op: dienstencheques zijn niet vrijgesteld en beschouwen we volledig als loon

- opzegvergoeding
• Heeft jouw cliënt recht op een opzegvergoeding na ontbinding van zijn arbeidscontract? Het bedrag van de opzegvergoeding neem je in rekening als inkomen voor de periode waarop de opzegvergoeding betrekking heeft.

- inkomen uit sportactiviteiten
Professionele sportbeoefenaars vallen onder een arbeidscontract of overeenkomst en komen daarom niet in aanmerking voor financiële hulpverlening. Eerste klasse voetbalclubs (Jupiler Pro League) zijn profclubs en tweede klasse voetbalclubs (Proximus League) zijn prof en semi-profclubs. Deze clubs hebben contractuele verplichtingen ten aanzien van spelers. Als jouw cliënt speelt voor een eerste of tweede klasse club dan heeft hij een arbeidscontract of -overeenkomst en verleen je hem geen financiële hulp.

- inkomen uit zelfstandige arbeid

- inkomen als onthaalouder
De volgende regels gelden niet voor zelfstandige onthaalouders, maar voor onthaalouders gekoppeld aan een Organisator Gezinsopvang die een onkostenvergoeding krijgen i.p.v. loon.
Het inkomen als onthaalouder is niet vrijgesteld en neem je dus in rekening voor het berekenen van het leefloon. Let op: het deel van dit inkomen dat jouw cliënt besteedt aan beroepskosten (maaltijden, speelgoed…) is vrijgesteld. Vraag hiervan bewijs aan jouw cliënt

- Inkomen uit leercontract of leervergoeding
- inkomen uit tewerkstelling in de deeleconomie (vb deliveroo)

De relatie {Persoon arbeidsrelatie Arbeidsrelatie} en de inverse {Arbeidsrelatie werknemer Persoon} komen niet door in de spec (noch HTML noch JSON-LD).

Mogelijks door het ontbreken van de package-tag.

Er is een boolean voor een bedrijfswagen, maar blijkbaar niet een mobiliteitsbudget. Het lijkt erop dat de bedrijfswagen een speciale status heeft, en de rest van de mobiliteit vergeten wordt.

Dit lijkt me ook anders dan maaltijdchecks, waar de "looncomponent" eigenlijk exact gekend is, terwijl de impact vaan een bedrijfswagen toch erg variable is. Ik zou verwachten dat er dan een mobiliteit looncomponent zou moeten toevoegd worden:
fietsvergoeding,
tankkaart,
openbaar vervoer,
speedelec lease, ...

en dus niet het beperkte "bedrijfswagen" :boolean.
Maar mobiliteitslooncomponent: { fietsvergoeding, mobiliteitsbudget, .... }

(opmerking verzameld bij OCMW Gent)
"Aangezien het hier gaat over een vocabularium mbt loongegevens, vermoed ik dat ze eigenlijk “collectieve schuldenregeling” en niet “schuldbemiddeling” bedoelen. Zeker omdat er verwezen wordt naar een schuldbemiddelaar, wat een begrip is dat normaal gezien enkel gebruikt wordt in het kader van een collectieve schuldenregeling.

Schuldbemiddeling heeft in principe betrekking op het onderhandelen over schulden met schuldeisers (al dan niet in combinatie met budgetbegeleiding of budgetbeheer) en heeft op zich niets te maken met het uitbetalen van loon. In de praktijk wordt die term soms wel gebruikt voor een collectieve schuldenregeling maar dat is eigenlijk niet correct.

Het zou dan ook beter zijn dat om de term “schuldbemiddeling” te vervangen door “collectieve schuldenregeling”. De omschrijving kan dan in principe wel behouden worden. Ik zou dan enkel nog “een instantie” wijzigen naar “een schuldbemiddelaar”."

Bankrekeningnummer kan overgenomen worden van OSLO-Generiek (gelijkaardig aan hoe het bij OSLO Feitelijke Verenigingen gebeurde)

Is de definitie “Gezinshoofd” (“Persoon die standaard het gezin vertegenwoordigt”) gelijk aan “Referentiepersoon”, is er nog een aparte definitie van Referentiepersoon nodig, of is dat gewoon een andere term?

Bij Stad Gent gebruiken we nu eerder "referentiepersoon", ook bij MAGDA en authentieke bronnen wordt steeds naar de referentiepersoon verwezen. Maar met beide bedoelen we contactpersoon van het gezin.

Het datatype Identificator wordt gebruikt in het AP maar staat niet op de figuur en ook niet in de spec.

Kunnen we een onderscheid maken tussen maaltijdcheques die wel of niet belastbaar zijn? Is er een mogelijkheid dit op te splitsen in het model?

"Maaltijdcheques worden beschouwd als een voordeel dat vrijgesteld is van sociale bijdragen en belastingen indien de voorwaarden bepaald in artikel 19bis van het Koninklijk besluit van 28 november 1969 en artikel 38/1, §2 van het Wetboek van de inkomstenbelastingen 1992 worden nageleefd."

https://werk.belgie.be/nl/themas/verloning/maaltijdcheques

Via @bertvannuffelen
er is de eigenschap "inkomsten" / "begunstigde" dat niet voorkomt in de tabellen. Maar wel op de UML staat. Het lijkt erop dat het model niet volledig is gepubliceerd.

Zou de kardinaliteit van alle eigenschappen van Persoon op optioneel gezet kunnen worden? In de use case van de MBP Solid Pod, wordt een persoon geïdentificeerd aan de hand van zijn/haar webID en zijn de andere attributen overbodig.

De klasse Periode vereist een xsd:DateTime als start en einde. Deze klasse mapt op de URI http://data.europa.eu/m8g/PeriodOfTime, die doorverwijst naar http://www.w3.org/2006/time#ProperInterval.

In het kader van een loonbrief is het echter meestal (altijd?) geen DateTime die erop vermeld staat, maar enkel een Date, bv. loonbrief november slaat op een periode van 01/11/2022 - 30/11/2022.

Ik zou daarom willen voorstellen om in het AP Loongegevens de de klasse Periode te mappen op de klasse Interval van de Time Ontology met hasBeginning en hasEnd attributen, bv.

ex:Loonbrief123Periode
    a time:Interval ;
    time:hasBeginning [
        a time:Instant ;
        time:inXSDDate '2022-11-01' ;
    ] ;
    time:hasEnd [
        a time:Instant ;
        time:inXSDDate '2022-11-30' ;
    ] ;
.

Merk op dat in CCCEV hasBeginning en hasEnd rechtstreeks verbonden worden aan een xsd:Date, maar ik vind niet meteen terug dat de Time Ontology dit zo toelaat. Dit zou de payload wel minder verbose maken.

ex:Loonbrief123Periode
    a time:Interval ;
    time:hasBeginning '2022-11-01' ;
    time:hasEnd '2022-11-30' ;
.

Als laatste opmerking zou ik geen ProperInterval gebruiken (wat CCCEV wel doet), omdat hiervoor het begin en het einde moeten verschillen, wat, bij een granulariteit van een dag, niet het geval is voor loonfiches van 1 dag lang (bv. jobstudent of laatste werkdag valt op de eerste dag van de maand).