Medlemsnummer og identifikatorer skal gjøre det mulig å følge samme medlem gjennom endring av e-post, telefon, gruppe og betaling. Den viktigste regelen er å skille en stabil intern ID fra kontaktopplysninger som kan endres.
Hvilke identifikatorer finnes?
| Identifikator | Bruk |
|---|---|
| Intern medlems-ID | Stabil teknisk nøkkel som ikke gjenbrukes. |
| Medlemsnummer | Synlig referanse i kommunikasjon og administrasjon. |
| E-post | Kontakt og mulig innlogging, men kan endres eller deles. |
| Fødselsdato | Alder og enkelte rapportbehov; krever tydelig formål og tilgang. |
| Telefon | Kontakt- og kontrollfelt, men ikke en sikker unik nøkkel. |
| Ekstern ID | Kobling til betaling, forbund, regnskap eller annet system. |
Ikke bruk e-post som eneste sannhet
E-post kan byttes, deles i familier eller skrives feil. Hvis e-post er eneste identifikator, kan historikk og betaling havne på feil post. En foresatt kan dessuten være kontaktperson for flere barn. Modellér derfor person, medlemskap, foresattrelasjon og kontaktkanal som forskjellige ting.
Slik ser en robust datamodell ut
| Objekt | Eksempel | Hvorfor det bør være separat |
|---|---|---|
| Person | Kari Hansen | Kontaktdata og identitet kan oppdateres |
| Medlemskap | Medlem i 2026 | Start, slutt, kategori og status har egen historikk |
| Gruppe | J2014 fotball | Et medlem kan flytte eller delta i flere grupper |
| Betalingskrav | Kontingent 2026 | Krav, betaling og refusjon må kunne avstemmes |
| Relasjon | Ola er foresatt for Kari | Én kontakt kan høre til flere medlemmer |
Regler for medlemsnummer
- Generer nummeret automatisk og aldri bruk et gammelt nummer på nytt.
- Ikke bygg personopplysninger som fødselsdato inn i selve nummeret.
- Behold nummeret når kontaktdata og medlemskategori endres.
- Skill mellom intern database-ID og et nummer mennesker bruker.
- Dokumenter hvordan nummer håndteres ved sammenslåing av dubletter.
Finn dubletter uten å slå sammen feil person
Bruk flere signaler, som navn, fødselsdato, telefon, e-post, adresse og foresattrelasjon. Et mulig treff skal bli en kontrolloppgave, ikke en automatisk sammenslåing.
Ved sammenslåing må systemet velge hvilken post som overlever, flytte medlemskap og betalinger, bevare historikk og logge hvem som godkjente endringen. Les guiden til dubletter i medlemsregister før en større opprydding.
Personvern og dataminimering
Hvert identifikatorfelt må ha et formål og et behandlingsgrunnlag. Datatilsynets veiledning om behandlingsgrunnlag bruker medlemsforening som et konkret eksempel. Ikke samle en sterkere identifikator enn oppgaven krever, og begrens tilgang til opplysninger som ikke trengs i den daglige driften.
Import og integrasjoner
Lag en mappingtabell før import:
| Kildesystem | Kilde-ID | Vele-ID | Regel | Kontrollert av |
|---|---|---|---|---|
Behold kilde-ID-en som referanse selv om Vele oppretter en ny intern ID. Da kan importen gjentas og avvik spores. Bruk import av medlemsdata for test, kontrollsummer og tilbakeføringsplan.
Identifikatorer i betalingsflyten
KID eller betalingsreferanse skal peke til riktig krav, mens medlems-ID peker til medlemmet. Ikke bruk bankens fritekst som eneste matching. Når betaling og medlemskap kobles med stabile referanser, blir avstemming av kontingent vesentlig tryggere.
Vele skal bevare samme medlem gjennom endringer og gjøre historikken kontrollerbar. Hvis dere har mange dubletter eller importkilder, kan dere registrere interesse.