8🏢 PadelOS Clubs, Locaties & Organisaties

1. Introductie

PadelOS Clubs, Locaties & Organisaties vormt de centrale organisatielaag van PadelOS. Deze module brengt clubs, padelscholen, verenigingen, bedrijven, stichtingen, exploitanten, vestigingen, padellocaties, banen en contactpersonen samen in één beheersbare structuur.

Een organisatie is binnen PadelOS meer dan alleen een naam en adres. Zij kan bestaan uit meerdere vestigingen, verschillende soorten locaties, interne afdelingen, contactpersonen, trainers, banen, contracten en samenwerkingsrelaties. Door deze gegevens centraal te registreren, ontstaat één betrouwbare basis voor planning, communicatie, lesorganisatie, facturatie, betalingen, rapportages en toegangsbeheer.

De module wordt stapsgewijs ontwikkeld: van een centrale administratie in Google Sheets en Google Apps Script naar een professionele multi-tenant architectuur binnen CAMTESI: Cloud Architecture & Multi-Tenant Engine – System International.

2. Visie

De visie van PadelOS is dat iedere organisatie haar eigen digitale werkruimte moet kunnen krijgen, zonder dat gegevens onnodig worden gekopieerd of van elkaar losraken.

Een persoon hoeft maar één keer centraal geregistreerd te worden en kan vervolgens meerdere rollen vervullen. Dezelfde persoon kan bijvoorbeeld:

• bestuurder van een vereniging zijn;

• contactpersoon van een locatie zijn;

• trainer bij een padelschool zijn;

• speler bij een club zijn;

• facturatiecontact voor een organisatie zijn;

• beheerrechten binnen een PadelOS-werkruimte hebben.

Op dezelfde manier kan één organisatie meerdere locaties beheren, terwijl één locatie verschillende organisaties, trainers of samenwerkingspartners kan bedienen.

PadelOS maakt daarom onderscheid tussen personen, organisaties, rollen, locaties, banen en onderlinge relaties.

3. Het probleem

Gegevens over clubs en locaties worden in de praktijk vaak verspreid bijgehouden in spreadsheets, agenda’s, telefoons, e-mails, contractmappen en boekhoudsystemen. Daardoor ontstaan verschillende versies van dezelfde informatie.

Veelvoorkomende problemen zijn:

• dezelfde organisatie staat meerdere keren geregistreerd;

• contactpersonen komen voor in verschillende tabbladen;

• oude telefoonnummers en e-mailadressen blijven in gebruik;

• onduidelijkheid over hoofdvestigingen en nevenlocaties;

• trainers worden rechtstreeks aan tekstnamen gekoppeld in plaats van aan unieke ID’s;

• banen hebben geen uniforme naamgeving;

• openingstijden en baanbeschikbaarheid worden door elkaar gebruikt;

• contracten zijn niet gekoppeld aan de betrokken locatie of organisatie;

• een persoon met meerdere rollen wordt meerdere keren aangemaakt;

• wijzigingen worden niet automatisch doorgevoerd in planning, facturatie en communicatie;

• verschillende organisaties kunnen elkaars gegevens mogelijk zien wanneer rechten onvoldoende zijn ingericht.

PadelOS lost dit op met centrale registraties, unieke identificatienummers, relatietabellen, validatie en gecontroleerde toegangsrechten.

4. Doelgroepen

De module is bedoeld voor:

• padelclubs;

• tennis- en padelverenigingen;

• commerciële padelcentra;

• padelscholen en zelfstandige trainers;

• locatie-exploitanten;

• sportbedrijven;

• gemeenten en onderwijsinstellingen;

• maatschappelijke organisaties;

• stichtingen, waaronder Stichting GODOGOOD.eu;

• sponsors en samenwerkingspartners;

• planners en administrators;

• receptie- en locatiemedewerkers;

• financieel administrateurs;

• data-architecten en ontwikkelaars;

• bestuurders, managers en toezichthouders.

Iedere doelgroep krijgt alleen toegang tot de informatie en handelingen die voor de eigen functie noodzakelijk zijn.

5. Doelstellingen

PadelOS Clubs, Locaties & Organisaties heeft de volgende hoofddoelen:

1. Eén centrale registratie van alle organisaties realiseren.

2. Meerdere locaties en vestigingen per organisatie ondersteunen.

3. Meerdere contactpersonen en rollen per organisatie mogelijk maken.

4. Personen slechts één keer centraal registreren.

5. Dubbele gegevens herkennen en waar mogelijk voorkomen.

6. Locaties en banen bruikbaar maken voor planning en reserveringen.

7. Contracten, lessen, trainers, spelers en facturen aan organisaties koppelen.

8. Samenwerkingsrelaties tussen organisaties inzichtelijk maken.

9. Rechten en gegevens per organisatie kunnen afschermen.

10. Organisaties voorbereiden op een eigen CAMTESI-werkruimte.

Het uiteindelijke doel is een betrouwbare organisatieregistratie die door alle andere PadelOS-modules kan worden gebruikt.

6. Belangrijkste functies

De module ondersteunt of voorziet in functies voor:

• organisaties aanmaken, bekijken, wijzigen en archiveren;

• onderscheid maken tussen clubs, verenigingen, bedrijven, stichtingen en andere organisatietypen;

• moederorganisaties, dochterorganisaties en afdelingen registreren;

• hoofdvestigingen en nevenvestigingen beheren;

• bezoek-, post- en factuuradressen opslaan;

• locaties aan organisaties koppelen;

• banen per locatie beheren;

• faciliteiten en toegankelijkheid registreren;

• reguliere en afwijkende openingstijden beheren;

• meerdere contactpersonen toevoegen;

• contactrollen en geldigheidsperioden vastleggen;

• primaire contactpersonen aanwijzen;

• trainers, spelers en medewerkers aan organisaties verbinden;

• contracten en samenwerkingsafspraken registreren;

• documenten en externe referenties koppelen;

• zoeken, filteren, sorteren, importeren en exporteren;

• duplicaten signaleren;

• wijzigingen vastleggen in een auditlog;

• gegevens per tenant of werkruimte afschermen.

7. Organisatiestructuren

Een organisatie kan binnen PadelOS verschillende vormen aannemen, zoals:

• padelclub;

• padelschool;

• tennis- en padelvereniging;

• commerciële exploitant;

• besloten vennootschap;

• eenmanszaak;

• stichting;

• gemeente;

• onderwijsinstelling;

• sportbond;

• sponsor;

• leverancier;

• maatschappelijke partner;

• holding of koepelorganisatie.

De organisatiestructuur kan hiërarchisch worden ingericht. Een landelijke exploitant kan bijvoorbeeld meerdere regionale vestigingen hebben. Een vereniging kan verschillende sportafdelingen bevatten. Een padelschool kan actief zijn op locaties die eigendom zijn van andere organisaties.

Daarom wordt een organisatie niet automatisch gelijkgesteld aan een locatie. De organisatie is de juridische, bestuurlijke of commerciële entiteit. De locatie is de fysieke of eventueel digitale plaats waar activiteiten plaatsvinden.

8. Centrale gegevensmodellen

De organisatielaag bestaat uit een aantal samenwerkende registraties.

Registratie

Functie

PERSONEN

Centrale persoonsgegevens van natuurlijke personen

ORGANISATIES

Juridische, commerciële en maatschappelijke entiteiten

ORGANISATIE_PERSONEN

Relaties en rollen tussen personen en organisaties

CLUBCONTACTEN

Operationele contactregistratie voor clubs en locaties

CONTACTS

Centraal contactoverzicht voor zoeken en communicatie

LOCATIES

Fysieke vestigingen en sportlocaties

BANEN

Individuele padel-, tennis- of multifunctionele banen

CONTRACTEN

Afspraken met organisaties, locaties en betrokken partijen

GEBRUIKERS

Accounts met toegang tot PadelOS

GEBRUIKER_PERSONEN

Koppeling tussen een account en een centrale persoon

Iedere registratie krijgt een eigen unieke ID. Relaties worden op basis van deze ID’s gelegd en niet uitsluitend op basis van namen of e-mailadressen.

9. PERSONEN

PERSONEN bevat de centrale identiteit en contactgegevens van natuurlijke personen. Voorbeelden van velden zijn:

• PersoonID;

• voornaam;

• tussenvoegsel;

• achternaam;

• roepnaam;

• geboortedatum;

• e-mailadres;

• telefoonnummer;

• adresgegevens;

• voorkeurscommunicatie;

• taal;

• status;

• opmerkingen;

• datum van aanmaak;

• datum van laatste wijziging.

Een persoon wordt niet opnieuw aangemaakt omdat die een extra functie krijgt. Rollen worden afzonderlijk vastgelegd.

Een trainer die ook bestuurder en speler is, blijft dus één persoon. De rollen Trainer, Bestuurder en Speler worden via profielen en relatietabellen aan deze persoon gekoppeld.

Dit vermindert dubbele gegevens en zorgt ervoor dat een wijziging van telefoonnummer niet op meerdere plaatsen handmatig hoeft te worden verwerkt.

10. ORGANISATIES

ORGANISATIES bevat de centrale registratie van iedere organisatie. Mogelijke gegevens zijn:

• OrganisatieID;

• officiële naam;

• handelsnaam;

• organisatietype;

• rechtsvorm;

• registratienummer;

• btw-nummer;

• website;

• algemeen e-mailadres;

• algemeen telefoonnummer;

• bezoekadres;

• postadres;

• factuuradres;

• moederorganisatie;

• hoofdvestiging;

• status;

• verantwoordelijke administrator;

• facturatie-instellingen;

• contractstatus;

• tenant- of werkruimte-ID;

• opmerkingen en metadata.

Gevoelige fiscale of juridische gegevens worden alleen opgeslagen wanneer dit noodzakelijk en rechtmatig is. Toegang wordt beperkt tot bevoegde gebruikers.

Een organisatie kan actief, in voorbereiding, tijdelijk geblokkeerd, beëindigd of gearchiveerd zijn. Archiveren heeft de voorkeur boven definitief verwijderen wanneer gegevens onderdeel zijn van historische lessen, betalingen, contracten of rapportages.

11. ORGANISATIE_PERSONEN en contactrollen

ORGANISATIE_PERSONEN vormt de verbinding tussen een persoon en een organisatie. Deze relatietabel maakt het mogelijk dat meerdere personen aan één organisatie zijn verbonden en dat één persoon bij verschillende organisaties actief is.

Per relatie kunnen onder meer worden vastgelegd:

• RelatieID;

• OrganisatieID;

• PersoonID;

• rol;

• afdeling;

• functienaam;

• primaire contactpersoon: ja of nee;

• tekenbevoegdheid;

• facturatiecontact;

• planningscontact;

• veiligheidscontact;

• startdatum;

• einddatum;

• status;

• opmerkingen.

Mogelijke contactrollen zijn:

• bestuurder;

• voorzitter;

• penningmeester;

• secretaris;

• eigenaar;

• locatiemanager;

• clubmanager;

• hoofdtrainer;

• trainer;

• planner;

• receptiemedewerker;

• baanbeheerder;

• financieel contact;

• contractbeheerder;

• technisch contact;

• privacycontact;

• veiligheidscoördinator;

• sponsorcontact;

• algemeen aanspreekpunt.

Een persoon kan binnen dezelfde organisatie meerdere rollen hebben. Iedere rol kan eigen rechten, communicatievoorkeuren en geldigheidsperioden krijgen.

12. CLUBCONTACTEN en CONTACTS

CLUBCONTACTEN is bedoeld voor operationele contactinformatie die specifiek bij een club, locatie of samenwerkingsverband hoort. CONTACTS biedt een centraal overzicht waarmee bevoegde gebruikers snel personen en organisaties kunnen zoeken.

Deze tabellen mogen niet uitgroeien tot losstaande kopieën van persoonsgegevens. Waar mogelijk verwijzen zij naar:

• PersoonID;

• OrganisatieID;

• LocatieID;

• OrganisatiePersoonID.

Hierdoor kan een contactkaart informatie tonen zonder dezelfde naam, hetzelfde e-mailadres en hetzelfde telefoonnummer telkens opnieuw als onafhankelijk gegeven op te slaan.

In het centrale contactoverzicht kan worden gezocht en gefilterd op:

• naam;

• organisatie;

• locatie;

• rol;

• plaats;

• telefoonnummer;

• e-mailadres;

• actieve status;

• primaire contactpersoon;

• communicatiecategorie.

Contactgegevens mogen uitsluitend worden gebruikt voor het doel waarvoor zij zijn verzameld. Exportfuncties en massacommunicatie vereisen daarom aanvullende rechten en controle.

13. Locaties en vestigingen

LOCATIES registreert de fysieke plaatsen waar lessen, trainingen, wedstrijden, evenementen of andere activiteiten worden georganiseerd.

Een locatie kan gekoppeld zijn aan:

• de eigenaar;

• de exploitant;

• een club of vereniging;

• één of meer padelscholen;

• een gemeente;

• een onderwijsinstelling;

• trainers en locatiebeheerders;

• contracten en samenwerkingsafspraken.

Mogelijke locatievelden zijn:

• LocatieID;

• locatienaam;

• OrganisatieID;

• eigenaar-ID;

• exploitant-ID;

• vestigingstype;

• bezoekadres;

• postcode;

• plaats;

• land;

• geografische coördinaten;

• tijdzone;

• algemeen telefoonnummer;

• algemeen e-mailadres;

• website;

• route- en parkeerinformatie;

• toegankelijkheidsinformatie;

• openingstijden;

• faciliteiten;

• noodinformatie;

• status;

• opmerkingen.

Een organisatie kan meerdere locaties hebben. Andersom kan een locatie door meerdere organisaties worden gebruikt. Deze situaties worden vastgelegd via relaties, contracten en gebruiksrechten.

14. Banen en faciliteiten

BANEN bevat de individuele speelvelden binnen een locatie. Iedere baan krijgt een eigen BaanID, zodat planning en rapportage niet afhankelijk zijn van vrije tekst zoals “baan 1” of “binnenbaan links”.

Per baan kunnen worden geregistreerd:

• BaanID;

• LocatieID;

• baannaam of baannummer;

• sporttype;

• binnen- of buitenbaan;

• enkel- of dubbelbaan;

• ondergrond;

• panoramisch of traditioneel kooitype;

• verlichting;

• verwarming;

• overkapping;

• rolstoeltoegankelijkheid;

• onderhoudsstatus;

• operationele status;

• maximale groepsgrootte;

• reserveringsinformatie;

• beschikbaarheidsvensters;

• prijs- of tariefcategorie;

• opmerkingen.

Ook algemene faciliteiten kunnen worden geregistreerd, zoals:

• kleedkamers;

• douches;

• toiletten;

• horeca;

• vergaderruimtes;

• winkel of verhuurpunt;

• EHBO-voorzieningen;

• AED;

• parkeerplaatsen;

• fietsvoorzieningen;

• laadpalen;

• tribunes;

• materiaalopslag;

• wifi;

• receptie.

Openingstijden van een locatie zijn niet automatisch hetzelfde als de beschikbaarheid van een baan. Onderhoud, competities, evenementen en vaste reserveringen kunnen de baanbeschikbaarheid beperken.

15. Samenwerkingsrelaties en contracten

PadelOS ondersteunt verschillende relaties tussen organisaties, zoals:

• een padelschool huurt banen bij een exploitant;

• een trainer werkt voor meerdere clubs;

• een vereniging organiseert activiteiten op een gemeentelijke locatie;

• een stichting verzorgt een maatschappelijk sportprogramma;

• een sponsor ondersteunt een evenement;

• een leverancier levert materiaal aan meerdere vestigingen;

• een opleidingsorganisatie werkt samen met een praktijklocatie.

Per samenwerkingsrelatie kunnen het type relatie, de betrokken organisaties, contactpersonen, looptijd, status en afspraken worden geregistreerd.

Contracten kunnen worden gekoppeld aan:

• één of meer organisaties;

• een specifieke locatie;

• geselecteerde banen;

• contactpersonen;

• tarieven;

• lesreeksen;

• reserveringsblokken;

• facturen;

• betaalafspraken;

• documenten;

• start- en einddata;

• opzegtermijnen.

Contractregistratie vervangt niet automatisch juridisch of financieel advies. Definitieve overeenkomsten moeten door bevoegde personen worden opgesteld en gecontroleerd.

16. Werkwijze en gegevensbeheer

Een nieuwe organisatie kan volgens een gecontroleerd proces worden toegevoegd:

1. Er wordt gezocht of de organisatie al bestaat.

2. Officiële naam, handelsnaam en contactgegevens worden gecontroleerd.

3. De organisatie krijgt een uniek OrganisatieID.

4. Vestigingen en locaties worden toegevoegd of gekoppeld.

5. Contactpersonen worden eerst in PERSONEN gecontroleerd.

6. Rollen worden via ORGANISATIE_PERSONEN vastgelegd.

7. Banen en faciliteiten worden aan de juiste locatie gekoppeld.

8. Contracten en samenwerkingsrelaties worden toegevoegd.

9. Gebruikersaccounts en rechten worden afzonderlijk toegekend.

10. Een bevoegde administrator controleert en activeert de registratie.

Wijzigingen worden bij voorkeur eerst gevalideerd. Belangrijke aanpassingen, zoals een nieuwe juridische naam, fiscale registratie of tenantbeheerder, kunnen een extra goedkeuringsstap vereisen.

17. Rollen, rechten en beveiliging

Niet iedere gebruiker mag alle organisatiegegevens bekijken of wijzigen. PadelOS werkt daarom toe naar toegangsbeheer op verschillende niveaus:

• module;

• tabel;

• record;

• organisatie;

• locatie;

• veld;

• handeling.

Voorbeelden:

• een locatiemanager beheert alleen de eigen locatie en banen;

• een trainer ziet de locaties waar lessen zijn ingepland;

• een planner ziet baanbeschikbaarheid, maar geen gevoelige contractgegevens;

• een financieel medewerker ziet factuuradressen en betaalafspraken;

• een speler ziet alleen relevante openbare locatie-informatie;

• een tenantadministrator beheert gebruikers binnen de eigen organisatie;

• een centrale PadelOS-beheerder ondersteunt meerdere tenants zonder onbeperkte operationele toegang.

Beveiligingsmaatregelen omvatten onder andere authenticatie, sessiebeheer, minimale rechten, auditlogs, back-ups, toegangscontrole, beveiligde API’s en periodieke controle van actieve accounts.

Google Sheets en Apps Script bieden een bruikbare ontwikkel- en testbasis, maar vormen niet zonder aanvullende maatregelen de volledige beveiligingsarchitectuur voor een professioneel multi-tenant cloudplatform.

18. Koppelingen met andere PadelOS-modules

Clubs, locaties en organisaties vormen een basis voor vrijwel alle andere onderdelen van PadelOS.

PadelOS-module

Koppeling

Accounts en security

Gebruikers krijgen rechten binnen een organisatie of locatie

Spelers

Spelers kunnen lid of deelnemer zijn bij meerdere organisaties

Trainers

Trainers worden gekoppeld aan werkgevers, opdrachtgevers en werklocaties

Planning

Lessen worden gekoppeld aan een locatie en BaanID

Lesvoorbereiding

Locatie, baan, materiaal en groepscontext worden meegenomen

Aanwezigheid

Registratie per les, organisatie en locatie

Facturatie

Facturen worden gekoppeld aan organisaties, contracten en locaties

Betalingen

Betalingen worden toegewezen aan de juiste financiële entiteit

Contracten

Afspraken worden gekoppeld aan partijen, locaties en banen

Communicatie

Contactpersonen en rollen bepalen de juiste ontvangers

Rapportages

Resultaten worden per organisatie, vestiging en locatie geanalyseerd

Materialen

Voorraad en uitgifte kunnen per locatie worden beheerd

Horeca en verhuur

Bestellingen en verhuur kunnen later aan locaties worden toegevoegd

Deze koppelingen worden gelegd met unieke ID’s en relationele registraties. Namen blijven zichtbaar voor gebruikers, maar zijn niet de technische sleutel.

19. Huidige status en ontwikkelroadmap

De bestaande PadelOS-omgeving bevat al tabbladen en gegevensstructuren voor onder andere CLUBS, LOCATIES, BANEN, PERSONEN, ORGANISATIES, ORGANISATIE_PERSONEN, CLUBCONTACTEN en CONTACTS.

De basis voor centrale registraties en dynamische CRUD-processen is aanwezig of in ontwikkeling. Niet alle onderdelen zijn echter al productierijp of volledig gekoppeld.

De verdere ontwikkeling bestaat uit de volgende fasen:

Fase 1 – Datamodel en registratie

• definitieve velden en unieke ID’s vaststellen;

• bestaande tabbladen behouden;

• organisaties, locaties en banen normaliseren;

• relatietabellen controleren.

Fase 2 – Personen en contacten

• spelers en trainers aan PERSONEN koppelen;

• contactpersonen dedupliceren;

• meerdere rollen per persoon ondersteunen;

• primaire en tijdelijke contactrollen beheren.

Fase 3 – Organisatiebeheer

• formulieren en overzichten voor organisaties bouwen;

• vestigingen, locaties en banen beheren;

• validatie en duplicaatcontrole toevoegen;

• import- en exportprocessen beveiligen.

Fase 4 – Operationele integratie

• planning aan LocatieID en BaanID koppelen;

• contracten en tarieven verbinden;

• facturatie per organisatie ondersteunen;

• rapportages per vestiging en locatie ontwikkelen.

Fase 5 – Security en tenantbeheer

• rechten per organisatie invoeren;

• auditlogs en goedkeuringsprocessen uitbreiden;

• tenantgrenzen testen;

• back-up- en herstelprocedures documenteren.

Fase 6 – CAMTESI-cloudarchitectuur

• afzonderlijke werkruimtes activeren;

• centrale en lokale configuratie scheiden;

• schaalbare API’s en gegevensopslag implementeren;

• organisaties gecontroleerd migreren naar tenants.

Functies worden pas als beschikbaar gepresenteerd nadat ze aantoonbaar zijn gebouwd, getest en beveiligd.

20. CAMTESI: organisaties als zelfstandige werkruimtes

Binnen de toekomstige CAMTESI-architectuur kan iedere organisatie functioneren als een afzonderlijke tenant of digitale werkruimte.

Een tenant kan beschikken over:

• een eigen organisatieprofiel;

• eigen administrators;

• eigen gebruikers en rollen;

• eigen locaties en banen;

• eigen spelers en trainers;

• eigen planning;

• eigen lessen en lesreeksen;

• eigen contracten en tarieven;

• eigen facturen en betalingen;

• eigen communicatie-instellingen;

• eigen rapportages;

• eigen huisstijl en configuratie;

• eigen bewaartermijnen en privacy-instellingen.

Gegevens van verschillende tenants worden logisch en technisch van elkaar gescheiden. Gedeelde personen of samenwerkingsrelaties mogen niet automatisch leiden tot toegang tot elkaars volledige administratie.

Wanneer organisaties samenwerken, kan PadelOS gecontroleerde relaties gebruiken. Alleen specifiek goedgekeurde informatie wordt dan gedeeld, bijvoorbeeld:

• beschikbaarheid van banen;

• afgesproken reserveringsblokken;

• toegewezen trainers;

• gezamenlijke activiteiten;

• contractreferenties;

• facturatiegegevens voor een opdracht;

• geautoriseerde contactpersonen.

CAMTESI moet daarnaast voorzien in tenantidentificatie, autorisatie, logging, gegevensisolatie, back-ups, herstelprocedures, migraties en centrale platformcontrole. Voor wereldwijd gebruik zijn ook taal, tijdzone, valuta, fiscale inrichting en regionale privacywetgeving van belang.

Met deze architectuur kan PadelOS doorgroeien van één centrale beheeromgeving naar een schaalbaar platform waarin clubs, padelscholen, verenigingen, exploitanten, bedrijven en maatschappelijke organisaties veilig zelfstandig werken én gecontroleerd met elkaar samenwerken.

PadelOS Clubs, Locaties & Organisaties brengt de mensen, organisaties en fysieke sportomgeving samen. Het vormt daarmee de verbindende laag tussen administratie, planning, trainingen, communicatie, contracten, facturatie en toekomstige zelfstandige CAMTESI-werkruimtes.