πFP: Onboarding AGB and APB
To comment on a FP:
Date, name: comment
Status Feature Passport
STATUS | OWNER | DATE |
---|---|---|
In proposal | Sofie | 12/10/2022 |
In refinement - Design Research | ||
In refinement - Technical Research/Feedback | ||
In development | ||
In QA/ Testing | ||
In Final state |
πANALYSIS
This part of the feature passport is owned by the analyst
Data sources
1. SharePoint (one time data conversion)
The data is available in different SharePointlists:
LSV SharePoint list verzelfstandiging > view 'Alle gegevens'
A new view needs to be created to view all the items because the views 'Alle gegevens' or 'Alle items' don't show all the data. Contact Sofie for more information.
In the LSV SharePoint list of LSV we have 4 types of organisations
AGB (= 'bestuurseenheid')
APB (= 'bestuurseenheid')
PEVA gem (= 'bestuurseenheid'?, TO BE CHECKED by legal expert)
PEVA prov (= 'bestuurseenheid'?, TO BE CHECKED by legal expert)
We know that the data of AGB and APB is not complete. One reason is that the creation of AGB's no longer (since 1/1/2019) needs to be approved by ABB.
2. Other sources
That's why we need to compare with other sources:
KBO
We need to do a regular check to see if there are new AGB's or APB's available in other sources.
3. Improve data quality in the future
read discussion point: 1. How can we capture new AGB's and APB's in the OP
Organisation Classification
AGB
Local government (bestuurseenheid) with two governing bodies (Raad van bestuur en DirectiecomitΓ©). We will NOT create the governing bodies in OP and we will NOT capture 'mandaten' or 'bestuursleden'. This might change in the future.
We will capture 'Leidinggevenden'.
APB
= idem as AGB
Full overview in Miro: https://miro.com/app/board/o9J_liK62Ew=/?moveToWidget=3458764527105216489&cot=14
New fields
The business requests for 3 new fields.
https://binnenland.atlassian.net/browse/OP-1834
Applicable to all administrative units
Naam volgens KBO
Verkorte naam
Naam volgens statuten
Name discussion
We will use the name they use in their SharePoint list and later we will add the official name.
We have a meeting on WE 5/4/2023 with Boris and the other PMβs to check how names are used in the other applications.
Refinement needed, read discussion point: 1. Organisations: different names
- Types of names
wettelijke naam = http://www.w3.org/ns/regorg#legalName
alternatieve naam = http://www.w3.org/2004/02/skos/core#altLabel
voorkeursnaam = http://www.w3.org/2004/02/skos/core#prefLabel
(korte naam) = requested by LSVP and Kalliope
E-mailThis field was already added after creation of this feature passport, so no action needed.Bestuurseenheden > KerngegevensEditable fieldNot mandatory field
Please add this field to all current and future administrative units we have in OP:
bestuur van de eredienstcentraal bestuur van de eredienstgemeenteOCMWdistrictprovincieand all future administrative units
Only for AGB and APB?
Oprichtingsdatum (start date)
To discuss:
we don't register the governing bodies so we can not use the start date for there
when we enter an organisation with status 'in oprichting', we have the start date via the change events. Can we show the start date when we don't register a change event?
Add this date to page 'kerngegevens'?
Editable field
Not mandatory field
_______________________________________________________
π MODULE Bestuurseenheden
Search page
https://organisaties.abb.lblod.info/bestuurseenheden
Filters
Soort eredienst Don't show this filter when one of the new administrative units is selected.
Type bestuur: add the options
Autonoom gemeentebedrijf
Autonoom provinciebedrijf
Apply contextual filters where possible.
Columns in results table
Naam (default sorting)
Type bestuur
Provincie
Gemeente
Status
Kerngegevens
TO DO: Change and replace image
Fields
Field | Mandatory | Editable | Comments |
---|---|---|---|
Naam* | β | β | |
Type bestuur* | β | β | |
Status* | β | β | |
KBO nummer | β | β | |
SharePoint identificator | β | β | |
OVO-nummer | auto | β | Do not show on edit page |
Adres* | β | β | CRAB functionality |
Straat* | β | β | Manual input of address |
Huisnummer* | β | β | Manual input of address |
Busnummer | β | β | Manual input of address |
Postcode* | β | β | Manual input of address |
Gemeente* | β | β | Manual input of address |
Provincie* | β | β | Manual input of address |
Primair telefoonnummer | β | β | Add standard helptext under input field |
Secundair telefoonnummer | β | β | Add standard helptext under input field |
β | β | Add standard helptext under input field | |
Website | β | β | Add standard helptext under input field |
Vestigingen (sites)
maatschappelijke zetel
correspondentieadres
The address of the 'maatschappelijke zetel' should be the address that is in the LF list, but in reality, it is a combination of 'maatschappelijke zetel' and 'correspondentieadres'.
β Betrokken Lokale Besturen (local involvements)
Betrokken lokale besturen where created specifically for worship services.
We will extend the related organisations with different type of relationships so we can display the relationship with local governments in the related organisation's menu-item
This can be re-used from worship services.
1. AGB's are founded by one and only one municipality and it is the municipality where the AGB is located.
Columns
Naam = Name of municipalityType instelling = Gemeente(with an AGB the type is always 'Gemeente')Type betrokkenheid = Toezichthoudend(with an AGB the type is always 'Toezichthoudend')Financieel percentage = 100%(with an AGB the percentage is always 100)
2. APB's are founded by one and only one province, and it is the province where the APB is located.
Columns
Naam = Name of the provinceType instelling = Provincie(with an APB the type is always 'Provincie')Type betrokkenheid = Toezichthoudend(with an APB the type is always 'Toezichthoudend')Financieel percentage = 100%(with an APB the percentage is always 100)
Question: Is it possible to auto-populate the data via a script, since the local involvement data of AGB's and APB's have a fixed/predictable pattern?
β Bestuursorganen
We will NOT create the governing bodies in OP and we will NOT capture 'mandaten' or 'bestuursleden', see organisation classification.
Leidinggevenden
No MVP, will be added later.
Veranderingsgebeurtenissen
Oprichting > Actief [double check by Boris via ticket OP-1834, should we do start date of the organisation (= oprichtingsdatum) via change events or not]
Naamswijziging > Actief
In ontbinding > Actief
In vereffening > Actief
Ontbonden en vereffend > Niet-actief
Fields change events
Foresee the fields on the printscreen for all 5 change events.
The business is discussing of they need the following fields:
Link naar besluit
Datum ministerieel besluit
Datum publicatie BS
So they might be deleted later.
Gerelateerde organisaties
AGB and APB are both related to
a province
a municipality
We will extend the related organisations so we can add more type of relationships (see epic OP-2272).
_______________________________________________________
π MODULE Personen (no MVP)
Search page
https://organisaties.abb.lblod.info/personen
Filters
Organisatie: add all the new organisations
Positie: add the new related position (Leidend ambtenaar) = already DONE out of scope: add the other positions of contact persons.
Apply contextual filters where possible.
Columns in results table
Voornaam (default sorting)
Achternaam
Organisatie
Positie
Status (default: only show active positions)
Contactgegevens
Posities
_______________________________________________________
OTHER impacts or things to know
π€© Expectations
π΅οΈββοΈ Use Cases
π€ Discussion points
_______________________________________________________
SOLUTION
The next two parts of the FP can [sometimes] be worked on simultaneously
Design
This part of the feature passport is owned by the designer
User research
[If there is any user research preceding the wireframe mock-up stage, it needs to be documented here]
Mock-ups
[link to figma mockups + any explanation or extra documentation]
Technical
This part of the feature passport is owned by the technical team
[Information about the technical solutions for expectations that need it - e.g. using mu-search for showing all types of positions in one table.]
After the designer and/or the technical team finish their task, a meeting follows where the solutions are presented. The team exchanges feedback and amends the feature passport where necessary.
Last updated