Tips & tricks er indsamlet fra erfaringer med onboarding og ibrugtagning af FK-OSS i pilotkommuner og Bølge 1-kommuner.

Nogle tips er relevante for jeres onboarding af FK-OSS, mens andre vedrører det daglige arbejde i systemet.

Mange tips indeholder links til relevante afsnit i brugervejledningen.

De indsamlede tips og tricks er inddelt i grupper efter f.eks. forslagstype eller brugergrænsefladeelement:

De første dage med FK-OSS - initiel mapning

Hvordan ved jeg, om der er nye forslag, som jeg skal forholde mig til?

Undervejs i onboardingen med FK-OSS er der formentlig mange forslag at tage stilling til, og der er en naturlig gang i løsningen. Men når man har arbejdet sig igennem den initielle mængde af forslag, så er det kommunens daglige drift i FK-ORG der er afgørende for, hvor mange nye forslag FK-OSS danner.

Man kan sætte FK-OSS op til at sende en notifikation om, at der er nye forslag at forholde sig til. På den måde, så behøver man ikke logge ind hver dag og tjekke selv.

Sæt FK-OSS op til at udsende en notifikation om nye forslag enten dagligt, ugentligt eller månedligt, se mere her: NotifikationerPreview.

Første synkronisering

Når synkroniseringen startes første gang bliver der dannet en hel stribe forskellige forslag, fordi ingen af enhederne endnu er “kædet sammen”.

• Der vil sikkert forekomme mange ”Lukning i SOR”-forslag (Lukning i SORPreview).

  • Disse kommer ved SOR-enheder, som ikke kan matches med nogen ORG-enheder.

  • For hver af disse skal du vurdere, om enheden fortsat skal blive i SOR eller om du ønsker at lukke enheden:

Open

Her skal du vurdere, om enheden fortsat skal blive i SOR (vælg “Behold i SOR”) eller om du ønsker at lukke enheden i SOR (vælg “Luk i SOR”).

• Der vil sikkert komme mange ”Oprettelse i SOR”-forslag (Oprettelse i SORPreview).

  • Disse kommer ved ORG-enheder, som ikke kan matches med nogen SOR-enheder.

    • Hvis der kommer rigtig mange “underlige” Oprettelsesforslag kan det også tyde på, at der med fordel kan laves en lidt snævrere Blackliste.

  • For hver af disse skal du vurdere, om du ønsker at enheden skal oprettes i SOR (og dermed automatisk blive forbundet) eller om enheden ikke skal oprettes i SOR (og dermed blot være en enhed i ORG uden forbindelse til SOR):

Open

Her skal du vurdere, om du ønsker at oprette enheden i SOR (vælg “Opret”) eller ej (vælg “Afvis”). Vælges Opret, så bliver den nye SOR-enhed automatisk forbundet til ORG-enheden.

• Der kan også komme mange ”Fejlede opgaver” (Fejlet OpgavePreview).

  • Disse kommer, hvis der er noget ”galt” med ORG-enhedernes kontaktoplysninger; f.eks. Manglende postadresse, telefonnummer eller (DAR-)invalid adresse.

Open

Start mapning i toppen af jeres organisationshierarki

Når I har sat synkroniseringen i gang, vil I blive mødt med mange forbindelsesforslag første gang I åbner løsningen.

Et tip fra en kommune er at danne jer et overblik over, hvordan jeres organisationshierarki ser ud, og så starte fra toppen af (dog med undtagelse af niveau 1 og 2 (IE- og SI-niveau), da de ikke kan håndteres i OSS pga. forretningsregler i SOR).

Hvorfor er det smart?

På den måde er det jer, der bestemmer hvilken rækkefølge I ønsker at forbinde enhederne, og ikke den lidt tilfældige rækkefølge af forslag, som FK-OSS kommer med.

Hvordan gør man det så?

Det kan være nyttigt at skabe et overblik over kommunens organisation i både FK-ORG og SOR. Husk at tage højde for, hvis dele af organisationen er blacklisted fra FK-ORG.

I SOR kan man nemt se sin træstruktur, f.eks. i SOR-browseren (se et eksempel på Korsbæks træstruktur i SOR-browseren).

Det følgende billede er et eksempel på en simpel organisation fra Korsbæk kommune, hvor der er to blacklistede elementer i Organisation:

Open

Når enhederne skal mappes, så:

• Start med at fremsøge den øverste enhed fra ORG eller SOR i fanen ”Nye forslag”.

  • Hvis den indgår i flere matches, så er det vigtigt at I vælger den rigtige.

    • Vær opmærksom på, at der ikke vil komme forslag, som involverer de to øverste niveauer af SOR-hierarkiet (IE- og SI-niveauerne)

  • Når enheden er blevet matchet, så forsvinder forslaget samt alle de andre forslag, den indgik i.

• Herefter fremsøges den næste i hierarkiet (og så videre)

I det følgende billede er det forsøgt visualiseret, hvordan det kan gribes an. Bemærk, at der ikke er forslag på SI-enheden, heller ikke på de to blacklistede enheder:

Open

Og når man har gennemført de forbindelsesforslag man ønsker, så kan det visuelt se således ud, hvor f.eks. “Ledelse” ikke er forbundet til noget i SOR, da netop den enhed ikke ønskes i SOR:

Open

Hvis matchning ikke kan finde andre forslag …

… så foreslås enten ”Lukning i SOR” el. ”Opret i SOR”.

Matchnings-algoritmen vil altid forsøge at danne matchningsforslag mellem enheder i FK-ORG og SOR. Dvs. FK-OSS forsøger at få håndteret alle enheder, og ”lagt dem på plads”.

Men når der ikke er flere mulige forslag tilbage for en enhed (f.eks. fordi et Forbindelsesforslag er afvist), så vil systemet til sidst foreslå én af to muligheder:

• ”Lukning i SOR”: Dette forslag vil komme, hvis det er en SOR-enhed, som der ikke kan findes flere mulige matches for (se Lukning i SORPreview).

  • Dette gælder ikke, hvis SOR-enheden har lokationsnummer. I dette tilfælde, så parkeres SOR-enheden som ”Fejlet opgave” om, at lokationsnummeret skal håndteres, inden enheden kan lukkes (se Fejlet OpgavePreview).

• ”Opret i SOR”: Dette forslag vil komme, hvis det er en FK-ORG-enhed, som der ikke kan findes flere mulige forbindelsesforslag på (se Oprettelse i SORPreview).

Er der forskel på, hvilken rækkefølge man bør udføre forslag på?

Vær opmærksom på, at der er en afhængighed mellem rækkefølgen på hvordan nogle forslag udføres i.

Hvis der både ligger en SOR-opdatering OG et flytteforslag på samme enhed, så låser flytteforslaget for andre ændringer, hvis flytningen udføres først.

Forklaringen er, at flytningen først er effektueret i SOR dagen efter; dvs. enheden er ”låst” for opdateringer indtil flytningen er gennemført. Dvs. i dette tilfælde er man nødt til at vente med at udføre SOR-opdateringen til flytningen er effektueret i SOR (som oftest vil være dagen efter, med mindre man har valgt en anden dato).

Skal jeg stoppe med at opdatere enheder i SOR, når jeg har taget FK-OSS i brug?

Ja. Når jeres kommune er begyndt at anvende FK-OSS, så bør I stoppe med at opdatere SOR-enheder i SOR-GUI. Dette skyldes, at de forbundne SOR-enheder nu holdes synkrone med deres forbundne enheder i FK-ORG. Og når der skal ske ændringer på nogle af de forbundne enheder, så skal det ske fra FK-ORG. Hvis I alligevel fortsat redigerer enheder i SOR-GUI, som er forbundet til enheder i ORG, så kan I opleve problemer med, at SOR-enhederne bliver låset for opdateringer.

Der er få felter, som kan opdateres på en forbundet SOR-enhed, og det er ‘Specialekode’ og ‘Enhedstype’. Disse felter kan redigeres direkte på en SOR-enhed i Redigering af SOR enhedPreview.

Fælles for de enheder, som enten kun skal være i SOR (og dermed ikke forbundet til en enhed i FK-ORG), eller SOR-enheder med lokationsnummer, så kan disse vedligeholdes i FK-OSS-brugergrænsefladen. Dette gøres fra Redigering af SOR enhedPreview.

Forslagstyper

Forbindelsesforslag

Herunder finder du de Tips & tricks, som er relateret til forslagstypen “Forbindelsesforslag”.

Kan man fortryde en afvisning af et forbindelsesforslag?

Scenariet er som følger:

FK-OSS har på et tidspunkt dannet et ‘Forbindelsesforslag’ mellem en enhed fra FK-ORG og en fra SOR. Dette forbindelsesforslag er blevet afvist, dvs. enhederne er ikke blevet forbundet.

På et senere tidspunkt ønsker kommunen alligevel at forbinde enhederne, men forslaget er “brugt” og findes ikke længere. Og FK-OSS tillader ikke, at man kan finde det gamle forslag frem og fortryde afvisningen.

Hvad gør man så?

Man kan forbinde to enheder manuelt.

Det gør man ved at femsøge enheden i ”FK-ORG Data” (se FK-ORG DataPreview) og klikke på knappen ”Forbind til SOR-enhed”. Herefter skal man udpege den SOR-enhed, som ORG enheden skal forbindes med (man kan gøre det samme fra “SOR Data” - se SOR DataPreview).

Open

Efterfølgende kan man se forbindelsen mellem enhederne, og i ”Godkende forslag” kan man nu også se, at der er skabt en forbindelse.

Hvad gør jeg hvis jeg har godkendt en forkert forbindelse?

Hvis du fortryder at have godkendt et forbindelsesforslag kan du godt rette op på fejlen.

Da forbindelsen blev godkendt, blev SOR enhedens værdier opdateret med navn, adresser, telefonnr. mm. fra FK-ORG enheden. Idet de to enheder blev forbundet ved en fejl, og SOR-enheden blev opdateret med den forkerte FK-ORG-enheds værdier, vil SOR-enheden nu have fejlagtige data. Følgende skal derfor udføres for at rulle ændringerne på SOR-enheden tilbage:

1. Først skal forbindelsen mellem de to enheder afbrydes. Det kan gøres ved at finde enhederne i enten menupunktet SOR Data eller menupunktet FK-ORG Data og her vælge “Afbryd forbindelse”:

   Open

   

2. Derefter skal SOR enhedens værdier manuelt rettes, så den igen får de oprindelige oplysninger. For at se, hvilke værdier, som er blevet (fejlagtigt) opdateret på SOR-enheden, så kan man slå den op i “Log over ændringer” (se Log over ændringerPreview), og finde ændringen. Her vil man kunne se, hvilke felters værdier der er rettet (noter værdierne, da de skal anvendes i næste step):

   Open

   

3. Fremsøg nu SOR-enheden fra menupunktet Redigering af SOR enhed (se Redigering af SOR enhedPreview), og ændr de relevante felter tilbage til deres oprindelige værdier:

   Open

   

4. Efter næste natlige synkronisering med SOR, så vil den opdaterede SOR-enhed indgå i matchningen igen, og du har mulighed for at finde det rigtige forbindelsesforslag med enheden.

Hvorfor kommer der ikke et Forbindelsesforslag?

Der er et par grunde til, at der nogle gange ikke kommer et Forbindelsesforslag:

1. De to øverste lag (IE- og SI-niveau) i organisationshierarkiet kan ikke ændres i SOR. Det betyder at der ikke oprettes Forbindelsesforslag til selve kommunen og dens direkte underenheder, idet man derved ville kunne få opdateret enhederne i SOR.

2. En ORG-enhed kan kun forbindes til en enhed i SOR, hvis den har et telefonnummer og gyldige adresser (dvs. en DAR-valid adresse). Hvis en FK-ORG enhed ikke har et telefonnummer eller ikke har gyldige adresser, bliver der oprettet en Fejlet opgave, som skal håndteres, inden ORG-enheden kan indgå i andre forslag. Når FK-ORG enheden er rettet, kan der blive dannet et forbindelsesforslag.

Oprettelse i SOR

Herunder finder du de Tips & tricks, som er relateret til forslagstypen “Oprettelse i SOR”.

Hvad gør jeg, hvis jeg er kommet til at afvise en Oprettelse i SOR ved en fejl?

Scenariet er som følger:

FK-OSS har på et tidspunkt vist et ‘Oprettelse i SOR-forslag’ på en enhed fra FK-ORG. Dette oprettelsesforslag er blevet afvist, dvs. der er ikke blevet oprettet en ny enhed i SOR på baggrund af enheden fra ORG. På et senere tidspunkt ønsker kommunen alligevel at oprette enheden i SOR, men forslaget er “brugt” og findes ikke længere. Og FK-OSS tillader ikke, at man kan finde det gamle forslag frem og fortryde afvisningen.

Hvad gør man så?

Du kan gøre følgende:

1. Fremsøg ORG enheden i ‘ORG-data’ i OSS.

2. På et andet faneblad i browseren åbnes ‘Manuel oprettelse’.

   1. Du skal nu oprette enheden manuelt i SOR fra OSS-brugergrænsefladen.

3. Indtast nøjagtig de samme oplysninger på den nye SOR-enhed, som ORG-enheden har og gem den nye SOR-enhed.

4. Ved næste synkronisering (eller ved manuel synkronisering) vil OSS foreslå en forbindelse mellem ORG-enheden og den nye SOR-enhed.

   1. På denne måde kan du få knyttet de to enheder sammen.

Hvad gør jeg, hvis jeg har samleenheder i ORG, som ikke findes i SOR?

Der kan være samleenheder i FK-ORG, som f.eks. kun har lederen af den organisatoriske enhed tilknyttet – disse findes i mange tilfælde ikke i SOR.

Medarbejdere ”hænger” på de underliggende enheder, og det er også på disse underenheder hvor borgere tilknyttes.

Disse (samle)enheder i FK-ORG vil medføre 'Oprettelse i SOR'-forslag i FK-OSS, da disse enheder ikke er kendte i SOR. Men de underliggende enheder findes i både ORG og SOR.

Hvad gør man ved disse “samleenheder”?

Der er to veje at gå:  

Løsning 1: Opret samleenhederne i SOR.

Herved opnår man en struktur, som er genkendelig mellem FK-ORG og SOR. Dog har samleenhederne ikke en funktion i SOR, og kan opfattes som unødig støj i SOR.

Løsning 2: Undlade at oprette samleenhederne i SOR.

Enhederne oprettes ikke i SOR, og dermed skal man ikke bruge tid på det.

Man får en struktur som er mindre genkendelig på tværs af FK-ORG og SOR, men til gengæld indeholder SOR ikke enheder, som ikke er relevante.

Hvad gør jeg, hvis jeg ved en fejl har oprettet en SOR enhed?

I menupunktet SOR Data er der mulighed for at lukke SOR enheden:

Open

Læs mere her: SOR DataPreview.

Hvorfor kommer der ikke et Opret i SOR-forslag?

Der er en række grunde til at der ikke oprettes et Opret i SOR forslag:

1. De to øverste lag (IE- og SI-niveau) i organisationshierarkiet kan ikke ændres i SOR. Det betyder at der ikke oprettes Opret i SOR forslag til selve kommunen og dens direkte underenheder.

2. Der dannes ikke et nyt Opret i SOR-forslag, hvis et Opret forslag tidligere er blevet afvist.

3. Hvis FK-ORG enheden indgår i et eller flere forbindelsesforslag, vil der ikke blive dannet Opret i SOR-forslag. Men hvis alle forbindelsesforslag afvises, vil der blive dannet et Opret i SOR forslag næste gang synkroniseringen kører.

4. En enhed kan kun oprettes i SOR hvis den har et telefonnummer og gyldige adresser (dvs. en DAR-valid adresse). Hvis en FK-ORG enhed ikke har et telefonnummer eller ikke har gyldige adresser, bliver der oprettet en Fejlet opgave. Når FK-ORG enheden er rettet, bliver der dannet et Opret i SOR-forslag.

Lukning i SOR

Herunder finder du de Tips & tricks, som er relateret til forslagstypen “Lukning i SOR”.

SOR enheden er ikke forbundet, men jeg kan alligevel ikke finde et Luk i SOR-forslag?

Som udgangspunkt vil FK-OSS forsøge at danne ”Lukning i SOR”-forslag på enheder, hvor den ikke kan finde et passende match til en FK-ORG-enhed.

Der er dog en række grunde til, at der ikke oprettes et Luk i SOR-forslag:

1. Kun SOR enheder med enhedstypen OE (organisatorisk enhed) kan lukkes i SOR, ikke IE og SI.

2. SOR enheder, som har en lokationsnummer, kan ikke lukkes.

3. SOR enheder, som har aktive underenheder (børn), kan ikke lukkes.

   Open

   

   Her kan PPR lukkes i ORG, men der kommer ikke et Luk i SOR-forslag på SOR-enheden ‘PPR’, da den har børn. De skal håndteres først.

4. Der dannes ikke Luk i SOR-forslag til enheder, der er oprettet manuelt i FK-OSS. Det er dog muligt at lukke enheden manuelt. Se hvordan under SOR DataPreview.

5. Hvis et Luk i SOR-forslag tidligere er blevet afvist, bliver der ikke dannet et nyt. Det er dog muligt at lukke enheden manuelt. Se hvordan under SOR DataPreview.

6. Hvis SOR enheden allerede er sat til at blive lukket (har en lukke-dato), bliver der ikke dannet et Luk i SOR-forslag.

7. Hvis SOR enheden indgår i et eller flere ventende forbindelsesforslag, bliver der ikke dannet et Luk forslag.

Hvad gør jeg, hvis jeg har samleenheder i SOR, som ikke findes i ORG?

Nogle gange har man brug for, at en enhed kun skal være i SOR, dvs. der findes ikke en enhed i FK-ORG, som matcher. Et eksempel kunne være, at der findes en samleenhed i SOR (f.eks. ”Område Øst”), som har tre børn (plejecenter A, B og C).

Ønsket er, at:

• Samleenheden findes kun i SOR

• Samleenheden skal ikke være til stede i FK-ORG.

• Men børnene (plejecenter A, B og C) til samleenhed findes i både SOR og FK-ORG og de skal forbindes.

Hvad gør man i dette tilfælde?

Idet samleenheden i SOR ikke findes i FK-ORG, vil FK-OSS matchning foreslå, at samleenheden lukkes i SOR (se forslaget Lukning i SORPreview).

På dette forslag vælges handlingen ”Behold i SOR”, da enheden netop fortsat skal eksistere i SOR. Her skal man give en forklaring på, hvorfor enheden beholdes (det er faktisk en afvisning af forslaget). Denne forklaring kan senere genfindes under ”Afvisningsgrundlag” på det afviste forslag.

Herefter forbindes enhedens børn, som findes i både SOR og FK-ORG.

Open

Hvorfor kommer der uventede “Lukning i SOR”-forslag?

Der er to situationer, som begge kan resultere i, at der kommer uventede “Lukning i SOR”-forslag. Den ene situation er, at man har tilrettet sin blackliste, og i den forbindelse har inkluderet “for meget” (Situation 1). Den anden situation er, at en organisationsændring i ORG har gjort, at ikke-blacklistede enheder bliver flyttet ind under en blacklisted forældre (situation 2).

Situation 1

Denne case kommer fra en kommune, der efter en organisationsændring oplevede, at der dukkede uventet mange ”Lukning i SOR”-forslag op på enheder, som allerede var forbundne. Forventningen var, at der ikke var kommet nye forslag på baggrund af organisationsændringen, så det skabte forvirring med alle disse nye “Lukning i SOR”-forslag.

Hvad gør man?

Det viste sig, at de mange ”Lukning i SOR”-forslag kom efter, at Blacklisten var blevet opdateret.

Ved en fejl var der nemlig blevet blacklistet på et ”for højt” niveau, og derfor var der nu en række underenheder i FK-ORG, som FK-OSS ikke længere havde adgang til. Når FK-OSS ikke længere kan se enhederne i FK-ORG, som en række SOR-enheder var forbundet til, så foreslår matchningen at enhederne i SOR lukkes.

Løsningen var at ændre i blacklisten, så underenhederne ikke længere var omfattet af blacklisten.

På de efterfølgende billeder har vi illustreret dette:

Open

1. Viser udgangspunktet, hvor alle enheder i udsnittet af hierarkierne er forbundne.

Open

2. Viser, at en forældre (Sundhedscenter) bliver blacklisted, og at enhedens børn dermed også bliver omfattet af blacklisten.

Open

3. Viser, at forbindelserne mellem Sundhedscenter og dennes børn bliver fjernet, OG at der dannes Lukning i SOR-forslag.

Open

4. Viser, at hvis FK-ORG-enheden ‘Sundhedscenter’ fjernes fra blacklisten igen, så vil FK-OSS genforeslå forbindelsesforslag på de enheder, som tidligere har været forbundne.

Situation 2

Efter en organisationsændring oplevede kommunen, at der dukkede uventet mange ”Lukning i SOR”-forslag op på enheder, som allerede var forbundne.

Det viste sig, at de mange ”Lukning i SOR”-forslag kom efter, at der ved organisationsændringen var blevet flyttet rundt på enheder i ORG, så en gren var blevet flyttet ind under en allerede blacklisted enhed.

Fordi enhederne nu ”de facto” er blacklisted (fordi forælderen er det) foreslår matchningen, at enhederne i SOR lukkes.

Løsningen var at ændre i blacklisten, så underenhederne ikke længere var omfattet af blacklisten. Men hvordan gør man det, uden at der kommer forkerte forslag pga. “mellemregningerne”?

Når der laves organisationsændringer, så skal ORG-administrator og OSS-administrator koordinere den planlagte ændring:

1. Sæt synkroniseringen på pause

2. Foretag organisationsændringer i ORG

3. Foretag ændringer i Blacklisten, så de modsvarer de ændringer der er foretaget i ORG

4. Sæt synkroniseringen i gang

På denne måde, får man ikke uventede ”Lukning i SOR”

Hvad gør jeg hvis jeg ved en fejl har deaktiveret/lukket en SOR enhed?

Der er desværre ingen måde at gen-aktivere SOR enheden, da det er en forretningsregel hos SOR. Eneste løsning er at oprette en ny SOR enhed. Dette kan gøres i menupunktet Manuel oprettelse (se https://org-sor-sync.atlassian.net/wiki/spaces/FKOSS/pages/68976673).

Fejlet

Herunder finder du de Tips & tricks, som er relateret til forslagstypen “Fejlet”.

Mangler du et forbindelsesforslag? Kig under “Fejlet”

Casen her er, at der er foretaget ændringer på nogle enheder i FK-ORG eller SOR, som gør, at du forventer et nyt forbindelsesforslag.

Ved filtrering på forslagstypen ”Forbindelsesforslag” under ”Nye forslag” dukker den imidlertid ikke op som forventet.

Hvad kan der være galt?

Kig under forslagstypen ”Fejlet”, da det kan være, at der mangler nogle oplysninger på enheden i ORG. Det sker, at der mangler et telefonnummer, en adresse eller at adressen ikke er gyldig (dvs. DAR-valid).

Open

Hvad betyder den fejlede opgave: “SOR enhedens lokationsnummer skal flyttes før enheden kan lukkes”?

Under “Fejlet” ligger der en opgave, hvor OSS beder dig om at flytte enhedens lokationsnummer før du kan lukke enheden. Enheden findes kun i SOR, og har altså ikke forbindelse til en enhed i FK-ORG.

Fordi enheden kun findes i SOR, forsøger OSS i virkeligheden at danne et “Lukning i SOR”-forslag. Men da enheden har eget lokationsnummer, beder OSS dig om at flytte lokationsnummeret, før du kan lukke enheden. Først når lokationsnummeret er flyttet, kan OSS danne et “Lukning i SOR”-forslag, hvor du så kan vælge at lukke enheden eller beholde den i SOR.

Hvad skal du gøre i Fejlede opgaver?

Hvis du faktisk ønsker at lukke enheden i SOR, skal du tage kontakt til SOR, og bede dem om flytte lokationsnummeret. Først når det er sket, vil OSS danne et “Lukning i SOR”-forslag, som du skal forholde dig til.

Hvis du ønsker at beholde enheden i SOR og dermed ikke ændre noget, skal du blot trykke på knappe “Set/afvise” på den fejlede opgave, og opgaven vil forsvinde.

Flytning

Hvad gør jeg, hvis jeg har brug for at flytte en SOR-enhed, som ikke er forbundet?

Flytninger i OSS vil altid være initieret af, at der er sket en ændring i FK-ORG på en forbundet enhed. Dvs: Flytteforslag kun vil komme på enheder, som er forbundne.

Hvis SOR-enheden ikke er forbundet, kan man desværre ikke flytte SOR-enheden fra én parent til en anden parent i SOR-hierarkiet direkte fra OSS. Her er man nødt til at foretage flytningen i SOR i stedet.

Jeg har brug for at flytte en enhed med nedarvet lokationsnummer. Hvad gør jeg?

FK-OSS tillader ikke flytning af en enhed med nedarvet lokationsnummer pga. forretningsregel i SOR.

Så for at flytte enheden, skal man manuelt fjerne nedarvningen (dvs. fjern flueben) på enheden i SOR. Efter næste nats synkronisering kan flytningen af enheden gennemføres i OSS.

Systemindstillinger & Brugergrænseflade

Herunder finder du de Tips & tricks, som er relateret til Systemindstillinger & brugergrænseflade.

Matchning

Hvad gør man, hvis man har “for mange” forbindelsesforslag?

Hvis en kommune har mange enheder, som enten hedder meget enslydende navne, eller er geografisk placeret på næsten samme adresse, vil det resultere i mange matchningsforslag på kryds og tværs. Det gør, at det kan være svært at finde ”de rigtige” matches.

Open

Hvad gør man?

Man kan gøre et par ting:

1. Ændre den totale matchningsscore:

2. Ændre vægten på enkelt matchningsværdi

Manglende forbindelsesforslag? Vær OBS på, om SOR-koder i ORG er korrekte

En kommune i Bølge 1 manglede flere forbindelsesforslag. Det viste sig, at der lå gamle SOR-koder på enhederne i FK-ORG, men SOR-koderne var forkerte. Det var de, da en tidligere eksport fra SOR havde ændret formatet på SOR-koderne, så SOR-koderne på enhederne i ORG ikke længere var fuldstændige.

Hvad kan der være galt?

Grunden til, at der efterfølgende ikke kom forbindelsesforslag var, at SOR-koden vejer tungt i matchningsalgoritmen, da den som udgangspunkt er sat til at vægte 53 %. Så når FK-ORG-enheden har en SOR-kode, som er forskellig fra SOR-koderne på enhederne i SOR, så fremkommer der ingen matchningsforslag.

Hvad gør man ved det?

Kommunen ændrede på vægten for SOR-koden, så den vægtede 0 %. Herefter kom der forbindelsesforslag, og forbindelser mellem enheder blev skabt. Kommunen satte vægten op efterfølgende igen.

Open

Præcisering af ”lille ændring” og ”Stor ændring”

Hvis der sker ændringer på en enheds oplysninger, efter at SOR- og FK-ORG-enheden er forbundet i FK-OSS, så vil der komme én af to mulige forslag. Ændringerne vægtes efter parametre, som angives under Matchning (se https://org-sor-sync.atlassian.net/wiki/spaces/FKOSS/pages/67535135).

Lille ændring

Hvis de to forbundne enheder fortsat matcher med mere end den Totale Matchningsværdi, vil systemet danne et ‘SOR opdatering’-forslag. Dvs. forslaget er, at SOR-enheden skal opdateres med ændringerne, f.eks. et nyt telefonnummer. Hvis man ikke ønsker SOR-enheden opdateret, så bliver forbindelsen brudt.

Stor ændring

Hvis de to forbundne enheder, efter ændringen, nu matcher med mindre end den Totale Matchningsværdi, vil systemet danne et ‘Oprethold forbindelse’-forslag. Dvs. forslaget drejer sig om at tage stilling til, om det fortsat giver mening at de to enheder skal være forbundet, da ændringerne gør, at de er blevet meget forskellige. Ønsker man at opretholde forbindelsen mellem enhederne, så bliver SOR-enheden opdateret med de nye oplysninger. Hvis man ikke ønsker SOR-enheden opdateret, så bliver forbindelsen brudt.

Open

Blacklist

Hvad skal jeg være særlig opmærksom på, når jeg opretter min blackliste?

Der har været flere eksempler på, at kommuner har fået blacklistet uhensigtsmæssigt, og dermed ikke fået de FK-ORG-enheder læst ind i FK-OSS, som de forventede, og FK-OSS kan ikke danne de forslag som forventedes.

Eksempler på uhensigtsmæssig blacklist:

• Blackliste hele kommunen, dvs. alle enheder er blevet blacklisted, og ingen enheder bliver læst ind i FK-OSS.

• Blackliste relevante underdele, dvs. der er relevante enheder, som ikke bliver læst ind i FK-OSS.

Hvordan ser jeg, hvor mange enheder der er blacklisted?

Når man danner sin blackliste, er det vanskeligt at se, hvor mange enheder, som faktisk er omfattet af blacklisten. Dette skyldes, at når man blacklister en enhed, vil alle eventuelle underliggende enheder også komme til at indgå i blacklisten.

Eksempel: I Korsbæk kommune er der tilføjet fire enheder til blacklisten:

Open

Dette resulterer i, at der i praksis bliver blacklisted 27 enheder fra FK-ORG. Dette kan man se under Driftstatus, hvor det natlige udtræk af FK-ORG vises:

Open

Kan man indtaste flere værdier i excelark end blot UUID?

Når man skal arbejde med sin blackliste, kan man inde fra FK-OSS hente en template, som man kan tage udgangspunkt i:

Open

I excdelarket kan man notere alle de UUID’er fra FK-ORG, som man ønsker skal blacklistes (se mere her https://org-sor-sync.atlassian.net/wiki/spaces/FKOSS/pages/68747364), ét UUID på hver række. Det er dog ikke særlig læsevenligt særligt hvis man senere har behov for at genbesøge sin blackliste.

En pilot-kommune har delt følgende tip til upload af blacklistede enheder til FK-OSS, som gør det lidt nemmere: I excelark kan man skrive ”hvad man har lyst til” efter ORG-UUID'et i hver række.

Et eksempel på dette vises i følgende billede:

Open

I ovenstående eksempel fra kommunen følges denne notation:

<ORG UUID>,<evt. Navn på enhed>,<evt. KKORG-nummer>,<evt. forvaltning>

Men man bestemmer selv, hvilke ting man ønsker at notere efter hvert UUID, så længe at det er adskilt med et komma (,).

Generelt

Hvad kan de fire ‘toggle’-knapper under Generelt?

Under Generelt i Systemindstillinger findes der nogle ‘toggle’-knapper:

Open

Vi skal se på, hvad de kan:

SOR-ID opdatering i FK-ORG

Med denne indstilling får man mulighed for at få skrevet SOR-id tilbage til ORG, for enheder der er forbundet. Denne indstilling kan være nyttigt, idet nogle telemedicinske løsninger (pt. Telma og K-Pro) kan læse SOR-id fra ORG. På denne måde kan kommunen slippe for en manuel arbejdsgang, hvor SOR-id og ORG-ider ellers skal vedligeholdes i et separat Excelark.

Der er dog et par ting, som kommunen skal være opmærksom på her:

• Det kræver, at serviceaftale om at OSS må skrive til ORG er godkendt

• Kommunens løsning, som er master for ORG, må ikke slette SOR-id. KOMBIT har været i dialog med flere af leverandørerne, og de kan godt håndtere dette. Derfor er det en god ide, at I tager fat i jeres leverandør og forhører jer, om jeres løsning kan acceptere at en anden løsning skriver SOR-id på enheder i ORG.

Synkronisering aktiv

Med denne indstilling giver I besked til FK-OSS om, at den må danne forslag ud fra nattens data fra SOR og FK-ORG.

Hvis jeres kommune står foran en større organisationsændring, så kan det være nyttigt at følge denne fremgangsmåde:

1. Sæt synkroniseringen på pause

2. Foretag organisationsændringer i FK-ORG

3. Foretag ændringer i Blacklisten, så de modsvarer de ændringer der er foretaget i FK-ORG

4. Sæt synkroniseringen i gang

Automatisk opdatering i SOR

Med denne indstilling slået til, kan FK-OSS selv håndtere og godkende forslagene af typen ”SOR-opdatering”. Dette betyder, at hvis indstillingen er slået til, så vil “små” ændringer på forbundne enheder, f.eks. nyt telefonnummer eller email automatisk blive synkroniseret over i SOR. I fanen Godkendte forslag vil disse forslag fremgå som om, at det er ‘System’, der har godkendt dem.

Opdatering af lokal attribut 2

Med denne indstilling slået til, kan FK-OSS sikre, at den brugervendte nøgle fra FK-ORG synkroniseres til SOR og skrives i feltet ‘Local attribut 2’ på enheden.

Bemærk, at denne indstilling formentlig ikke er relevant for de fleste kommuner, da ikke mange benytter de fem lokale attributter i SOR.

Brugergrænseflade

De 3 prikker … hvad finder man dér?

På fanebladet “SOR Data” kan man se alle kommunens SOR-enheder (se mere på SOR DataPreview). For hver af enhederne har man adgang til et par ekstra funktionaliteter:

• Luk i SOR: Her kan man lukke en enhed i SOR, hvis den ikke har et lokationsnummer eller børn.

• Vis Relation: Her kan man se, hvor enheden hænger i SOR-hierarkiet.

• Vis enhed i SOR: Herfra kan man åbne enheden i SOR-browseren.

Open

Hvad kan “Vis Relation” fra SOR-data?

Inde på SOR-Data kan man få vist, hvor i SOR-hierarkiet en enhed er placeret. Dette finder man ved klik på “Vis Relation” under de tre prikker:

Open

Her vil man få vist følgende vindue, hvor man kan se enheden og alle dens forældre.

Open

Hvis man klikker på ‘Vis Relation’ igen, så kan man få vist hele SOR-hierarkiet, hvor man også kan se søskende og enhedens egne børn:

Open

Hvad kan “Vis Relation” fra ORG-data?

Inde på ORG-Data kan man få vist, hvor i ORG-hierarkiet en enhed er placeret. Dette finder man ved klik på “hierarki-ikonet” ud for enheden:

Open

Her vil man få vist følgende vindue, hvor man kan se enheden og alle dens forældre:

Open

Hvis man klikker på ‘Vis Relation’ igen, så kan man få vist hele ORG-hierarkiet, hvor man også kan se søskende og enhedens egne børn:

Open

Hvor kan man se, at enheder er forbundet?

Der er to steder, hvor man kan se, om enheder er forbundne:

• Fra SOR-Data

• Fra ORG-Data

Herfra vises et ikon ud for alle enheder, der er forbundne.

Open

Man kan sortere på kolonnen, så alle forbundne kommer øverst eller nederst.

Man kan filtrere på kolonnen:

• Vælg Ja: Man ser alle forbundne enheder

• Vælg Nej: Man ser alle ikke-forbundne enheder

Når man åbner detaljevisning på en enhed i SOR-Data og ORG-Data kan man se detaljer om den forbundne enhed:

Open

Adresser

Hvorfor bliver ‘Henvendelsessted’ (VisitingAddress) ikke fjernet i SOR?

I FK-ORG behøver en enhed ikke have et henvendelsessted, men det kan ikke fjernes i SOR. Hvis VisitingAddress fjernes i SOR, vil den automatisk blive sat til enhedens postadresse. Derfor kan forbundne enheder godt se ud til at have forskelligt antal adresser tilknyttet i FK-ORG og SOR.

Institutionsejere og sundhedsinstitutioner må ikke have henvendelssted/visitingaddress i SOR, det er kun organisatoriske enheder der kan have henvendelssted/visitingaddress.

Hvorfor bliver ‘Lokation’ (ActivityAddress) ikke fjernet i SOR?

I FK-ORG behøver en enhed ikke have en lokation, men den kan ikke fjernes i SOR. Hvis ActivityAddress fjernes i SOR, vil den automatisk blive sat til enhedens henvendelsessted (VisitingAddress). Derfor kan forbundne enheder godt se ud til at have forskelligt antal adresser tilknyttet i FK-ORG og SOR.

Institutionsejere må ikke have lokation/activityaddress i SOR, det er kun organisatoriske enheder og sundhedsinstitutioner der kan have lokation/activityaddress.

Hvorfor er adressen ugyldig?

Alle adresser skal have et bestemt format for at være gyldig, dette format er beskrevet her: https://danmarksadresser.dk/om-adresser/saadan-gengives-en-adresse - en detaljeret beskrivelsen af, hvordan adressen skal se ud på én linje, er beskrevet i afsnit A.1.

Derudover har SOR nogle begrænsninger som skal overholdes:

• Vejnavnet må ikke være længere end 40 karakterer

• Postnummeret skal være 4 cifre

Hvorfor er mine ændringer i SOR GUI forsvundet?

Hvis man foretager ændringer i SOR GUI, så kender FK-OSS først til disse data dagen efter ændringerne er foretaget pga. den natlige synkronisering med SOR.

Hvis man så f.eks. godkender en forbindelse på en enhed, som i mellemtiden er blevet opdateret direkte i SOR, så vil man overskrive enheden med gamle værdier. Dette er særligt en udfordring ved LocalAttributes.

Derfor er anbefalingen, at undlade at ændre på enhederne i SOR.