När systemstatus larmar om "Överföring till [databas] (prioritetsstyrd)" innebär det att informationen inte kunnat skickas ner från Alliera till undersystemet. Klicka på "Analysera överföringsfel" för att utläsa vad det handlar om.
Nedan följer några vanliga fel, vad de innebär, och hur de åtgärdas.
RCO
Cardidentity
Förklaring: En kortkrock - numret på taggen som Alliera försöker skicka ner finns redan i passersystemet, vilket inte accepteras och orsakar ett fel.
Antingen har kortet lagts till direkt i passersystemet och inte synkats in till Alliera (vilket måste göras manuellt), eller så är kombinationen av konfiguration i undersystemet och typen av DESFire-taggar problematisk. Det finns ett utvecklingsärende på att komma runt detta, men inget skarpt datum på när det kan vara löst.
Åtgärd: Om DESFire-taggar används - byt ut taggen mot en ny. Den krockande taggen kan sparas undan och användas när bekymret är löst.
Om kortet lagts till direkt i passersystemet - då behöver det raderas i passersystemet; alternativt synkas in till Alliera för att kunna arkiveras därifrån.
Kontakta oss i supporten, alternativt installatör, för hjälp med det.
Lastname
Förklaring: Något på kortägarens namn/objektsnummer felar. Antingen är det en dubblett, eller så saknas efternamn (om det är en person).
Åtgärd: Börja med att titta på objektets benämning under "Korrigera namn":
Om det bara står objektkod, så är det sannolikt en dubblett av objektsnumret. Sök på objektsnumret i Alliera. Om du får en träff, döp om ett av dem. Om inte, kontakta oss i supporten, alternativt installatör - det kan ligga i undersystemet utan länkning till Alliera.
Om det är en person - se till att fältet "Efternamn" är ifyllt. Om det är det, och felet kvarstår, kontakta oss i supporten.
Phoneshort
Förklaring: I Porttelefonifliken är något fel med anropsnumret. Man kan inte fylla i både anrops- och telefonnummer - det måste vara antingen eller.
Åtgärd: Om HG ska ha telefonnummer - ta bort anropsnumret och spara.
Om HG ska ha anropsnummer och det inte står något telefonnummer, och det larmar ändå - testa att tillfälligt ta bort anropsnumret, spara, vänta tills felet släpper - och lägg till det och spara igen.
Axema
Could not connect exception
Förklaring: Alliera kan inte nå passersystemet och kan inte skicka ner informationen.
Inloggningen är lite speciell i Axema Vaka; man kan bara vara inloggad en person i taget. Om en installatör är inne kan inte Alliera logga in.
Åtgärd: Om inte felet släpper efter några minuter (beroende på en tillfällig inloggning) måste uppkopplingen felsökas av installatör, då är det troligtvis något nätverksrelaterat som gått ner.
Not exclusive on data field - database already contains token/person xxxx
Förklaring: Dubblett - Alliera kan inte skicka ner ett kort/namn som redan finns i Axema. Beror
oftast på att man lagt in kortet direkt i VAKA istället för Alliera. Kort och personer skall endast
administreras i Alliera.
Åtgärd: Sök upp taggen/personen i Axema och ta bort den. Felet borde släppa, men ibland kan man
behöva hjälpa Alliera på traven genom att t.ex arkivera och återaktivera kortet igen så att det
skickas ner på nytt. Kontakta oss i supporten om du inte har tillgång till Axema.
Multiple location grants for person
Förklaring: Vissa Axemor med porttelefon är konfigurerade med ‘locations’. En sådan
behövs för att Axema ska veta vilken adress porttelefonkopplingen går till. Man kan dock
bara ha en sådan location - annars får man det här felet. I Alliera ser det ut som en vanlig
behörighet.
Åtgärd: Gå igenom behörigheterna i Alliera och ta bort den adress som inte stämmer.
Tips: Är man osäker på vilken det är kan man kika under Behörighetsobjekt i Alliera och
klicka ut behörigheterna - håll muspekaren över de blåa ikonerna. Det är dem det står
AxemaLocation på som gäller här.
Person can have at most 5 access entries
Förklaring: Axema tillåter max 5 behörigheter.
Åtgärd: Frånta behörigheter i Alliera tills max 5 återstår.
Tips: Kika under Behörighetsobjekt om några av de befintliga behörigheterna innehåller
samma dörrar - i så fall kan en av dem tas bort utan att någon access påverkas.
Multiaccess
Cannot insert duplicate key
Förklaring: Namnet på objektet finns redan i undersystemet, och det kan inte vara en dubblett.
Åtgärd: Sök upp kortägarens namn i Alliera - finns det redan ett objekt som kan användas? Om inte, byt namn på kortägaren till något unikt genom att klicka på "Korrigera namn".
