Aptusmall_namngivning med områdesnummer.pdf

MULTIACCESS
NAMNSTRUKTURMALL _VERSION 6
fastighetssystem med områdesnummer

INNEHÅLL
Sidan
Inledning............................................................................... .............................................. 3
System .................................................................................. .............................................. 4
Dörrgrupp............................................................................................................................ 4
Centralenhet, namn och dörrar............................................................................................ 5
Centralenhet, ingångar ........................................................................................................ 6
Centralenhet, reläer ............................................................................................................. 7
Centralenhet, bokningslista ................................................................................................. 8
Tidzon.................................................................................................................................. 9
Behörighet ........................................................................................................................... 10
Kund.................................................................................................................................... 12
Användare ........................................................................................................................... 13
2

Namngivningsstandard för fastighetssystemprogrammering
Eftersom de flesta menyer i MultiAccess är gemensamma för samtliga system, är det av
yttersta vikt att ha en välstrukturerad lättförståelig namngivningsstandard i databasen.
Den person som programmerar en ny anläggning bör därför redan när första systemet tas i
drift, använda en enhetlig standard som tillåter vidare utbyggnad med flera system i
databasen. Således bör samtliga benämningar alltid inledas med samma information om
områdes och systemtillhörighet. Detta för att användare av MultiAccess enkelt skall kunna
knyta samman t ex ingående dörrar och bokningsobjekt till tidzoner för respektive system och
funktion. Har man t ex 20 tvättstugor där alla entrédörrar endast är namngivna som
”tvättstuga” blir det onekligen lite svårt att veta vilket system respektive dörr tillhör.
Vidare så måste även informationen om hyresgäster/personal/entreprenörer och deras brickor
enkelt kunna sökas fram och förstås i databasen. Därför bör man även här använda en
standardiserad namngivning, i menyerna ”kund” och ”användare”.
Följande namngivningsmall för programmering av MultiAccess, är en bra och väl fungerande
nivå som används av flera bostadsbolag. Smärre avvikelser och egna anpassningar
förekommer givetvis. Detta är dock en nivå som passar de flesta systemlösningar där
områdesnumrering används genomgående inom bostadsbolaget.
Namnfälten i de olika menyerna har plats för max 50 tecken. Av utrymmesskäl är inte alla
namnfält breda nog att visa samtliga tecken, utan scrollning. Detta medför att man i
möjligaste mån bör försöka förkorta allt för långa gatuadresser och dylikt.
Namngivningsexempel vid användning av områdesnummer
Områdesnummer: 426 (Tillhandahålles av bostadsbolaget/föreningen)
Systemlöpnummer: 01 (01 för första systemet i det området. 02 för andra osv.)
Gatuadress: Fiolvägen 1-9 (Gatuadressen där systemet är installerat)
3

System
Systemnamnet i MultiAccess skrivs då i likhet med följande exempel:
Dörrgrupp
Eftersom det alltid bör skapas en dörrgrupp för varje enskild dörr (läsare). Är det lämpligt att
det även går att utläsa av namnet, vilket utrymme på respektive underliggande gatuadress
läsaren styr tillträde till.
Dörrgruppsnamnen skrivs då i likhet med följande exempel:
4

Centralenhet namn
I centralenhetens namnfält skrivs samma namn som för systemet, samt om det är master eller
slavcentral 1, 2, 3, 4 osv. Är det en bokningscentral, går det även att bestämma hur mycket av
centralnamnet som skall visas i wwwash bokningsmeny. Använd hakparentes [ ] framför och
bakom det textavsnitt som skall synas i wwwashbilden
Centralenhet dörrar
I namnfältet för dörrarna är det väldigt viktigt att skriva samma namn som på dörrgruppen.
Eftersom det är dörrgruppsnamnet som används för att lägga till dörrar i tidzonerna, men
dörrens namn från centralenhetsbilden som används i händelsehanteringen blir det väldigt
rörigt om det inte är konsekvent namngivet här.
Centralenhetens namn och namnet på dörrarna skrivs då i likhet med följande exempel:
Tips!
Eftersom det inte går att kopiera dörrgruppsnamnet i centralenhetsbilden, underlättar det en
hel del att öppna dörrgruppsbilden parallellt och därifrån kopiera namntexten till dörrens
namnkolumn i centralenhetsbilden. På så vis slipper man skriva samma sak igen och
dessutom blir alla dörrnamn alltid identiska med dörrgruppsnamnet.
5

Centralenhet ingångar
Ingångar behöver inte namnges så länge dom behåller sina standardfunktioner. Om man
däremot ändrar funktion på en ingång skall den alltid namnges för att lättare kunna
identifieras i bl.a. händelsehanteringen. Samma inledande namngivningsstruktur används även
här.
Det är dessutom viktigt att ange vad som styr ingången (t ex en öppnaknapp) för att få en så
tydlig information som möjligt.
Ingångsnamnet skrivs då i likhet med följande exempel:
6

Centralenhet reläer
Reläer behöver inte namnges så länge dom behåller sina standardfunktioner och tillhör en
dörr. Om man använder reläerna till att styra andra funktioner än vad standardnamnet antyder
så skall givetvis reläet namnges för tydlighetens skull.
Relätyperna för bokningsfunktioner måste däremot alltid namnges. Eftersom dom inte tillhör
någon specifik dörr, skulle dom annars inte gå att identifiera i systemet. Namngivning sker
enligt samma struktur som övrigt och man anger även vad reläet styr (t ex tvättstugedörr).
Relänamnet skrivs då i likhet med följande exempel:
7

Centralenhet bokningslista
I bokningslistan är det lika viktigt att inte avvika från namngivningsstrukturen. Varje
bokningslista tilldelas ett eget namn och knyts sedan till tidzoner i tidzonsbilden som
”inkluderade objekt”. I en databas med flera tvättstugor skulle det annars bli svårt att välja rätt
objekt om alla bara hade namnet ”fintvätt” eller ”grovtvätt”.
Namnfälten för bokningslistorna tillåter 20 tecken och det kan därför behövas en förkortad
version av gatuadress och funktion som påverkas.
Bokningslistorna namnges då i likhet med följande exempel:
Till varje bokningslista knyts respektive relä som skall påverkas vid öppning av bokat pass.
I exemplet ovan, kan ni se att en tydlig namngivning underlättar vid val av ingående reläer.
8

Tidzon
Det är oftast till stor fördel att skapa egna tidzoner för respektive dörr. På så sätt kan enskilda
dörrar lättare knytas till behörigheterna i behörighetsbilden. För att skapandet av behörigheter
sedan skall bli så enkelt som möjligt, skall man självfallet fortsätta hålla namnstrukturen även
i tidzonsbilden.
I de fall där det kanske behövs fler tidzoner för samma dörr pga. olika tillträdestider, eller
styrning av olika funktioner. Kan man med fördel ange tidsintervallet (t ex 06.00-22.00) eller
den avvikande funktionen sist i namnet.
Tidzonerna namnges då i likhet med följande exempel:
Tips!
Även här underlättar det en hel del att öppna dörrgruppsbilden parallellt och därifrån kopiera
namntexten till tidzonens namnkolumn.
9

Behörighet
När behörigheten skall knytas till en bricka/kort i användarbilden så underlättar det avsevärt
om det går att förstå av namnet på behörigheten var den ger tillträde. Eftersom det inte går att
skriva alla dörrar den ger tillträde till i namnet på behörigheten, bör man istället namnge
behörigheter utifrån vilka användarkategorier som skall få dom tilldelade till sina brickor/kort.
Här kommer man inte alltid att kunna använda sig av områdesnummer och adress i början på
namnet för behörigheten. Dock skall man alltid sträva efter att följa samma
namngivningsstruktur som övrigt, även i behörighetsbilden.
Alla behörigheter som innehåller tidzoner till ett och samma område, går med fördel att
namnge med områdesnummer i början på namnet. Samma sak gäller för behörigheter som
innehåller tidzoner från olika områden, men som skall tilldelas boende i ett specifikt område.
Då använder man numret på området (utan systemlöpnummer) där hyresgästerna som skall
tilldelas behörigheten bor. På så sätt blir det väldigt enkelt och lättöverskådligt att lägga till
behörigheter på hyresgästernas brickor/kort.
Behörigheterna namnges då i likhet med följande exempel:
10

Behörigheter som skall tilldelas fastighetsbolagets egen personal eller olika entreprenörer,
innehåller ofta tidzoner tillhörande en mängd olika områden och i vissa fall samtliga områden.
Det man lättast gör i dessa fall är att avstå från att använda områdesnummer i början på
behörighetsnamnet. Istället skriver man fastighetsbolagsnamnet följt av personalkategori, eller
företagsnamnet på entreprenören.
Behörigheterna namnges då i likhet med följande exempel:
11

Kund
Denna funktion nyttjas för att kunna knyta flera brickor/kort till samma hyresgäst eller företag
och samtidigt använda en gemensam identitet för dessa brickor/kort i t.ex.
tvättbokningssammanhang.
Kundknytningen skall användas även om det inte finns bokningsfunktioner i systemet. Detta
för att underlätta hanteringen av brickor/kort.
I kundbilden anger man hyresgästens lägenhetsnummer eller entreprenörens företagsnamn
som identitet. Oftast skiljer det sig lite mellan olika bostadsbolag hur man skriver
lägenhetsnummer. Vanligtvis innehåller dock lägenhetsnumret även information om vilket
område lägenheten tillhör. Utöver detta så kan det även ingå information om t.ex. uppgång
och våningsplan. Viktigast är dock att alltid vara konsekvent i namngivningen samt att inte
inkludera uppgifter som förändras, t.ex. kontraktslöpnummer eller namn på nuvarande
hyresgäst.
Kundidentitet för hyresgäster namnges då i likhet med följande exempel:
Kundidentitet för företagskunder namnges i likhet med följande exempel:
12

Användare
I användarbilden är det kundidentiteten som skall ligga till grund för vad som skrivs i
användaridentitetsfältet.
För hyresgästernas brickor/kort börjar man med att skriva samma lägenhetsnummer som
användes i kundbilden. Lägg sedan till ett kolontecken följt av brickans identitet (denna
namnstruktur bygger på att beröringsfria brickor med graverad löpnummersiffra används 1, 2,
3 osv.). På så vis blir det väldigt enkelt att ändra eller spärra rätt bricka när hyresgästen skall
få ändrat tillträde eller har tappat brickan.
Om porttelefoner används i systemet skall en identitet skapas för anrop till respektive
hyresgäst. Denna namnges enligt samma princip. Löpnummersiffran efter kolontecknet byter
man däremot ut till PT istället (förkortning av porttelefon).
Användare som är hyresgäster namnges då i likhet med följande exempel:
Företagsbrickornas identitet namnges enligt samma princip och då börjar man med samma
namn som användes i kundbilden. Sedan är det dock lämpligare att efter kolontecknet skriva
namnet på personen som skall ha brickan. I de fall man inte får vetskap om vem som blir
tilldelad respektive bricka, använder man löpnumret istället. Användare som är från företag
namnges då i likhet med följande exempel:
13