150 deler, og hva hver av dem er til for.

Å komme inn i appen, og aldersporten som avgjør om en konto i det hele tatt kan brukes.

• Oppstartsskjerm og ruting ved første kjøring, så en som kommer tilbake, lander der de sluttet
• Registrering og pålogging mot gatewayen, med poletter i sikker lagring
• Tilbakestilling av passord på e-post
• Aldersporten for 18+, vist før noe kan kjøpes

Kontrollen som lar noen handle, også tilstandene en person sitter i mens et menneske vurderer det det automatiske steget ikke kunne avgjøre.

• Veiledet innledning som forklarer hva som blir spurt om, og hvorfor
• Ansiktsskanning, og dokumentkontroll som alternativ vei
• Tilstander for grensetilfeller og under vurdering, så personen aldri må gjette
• Verifiseringsstatus ført videre til hva kontoen får gjøre

Den første fanen. En rangert strøm av artikler, videoer og oppdateringer, pluss utgiverne bak dem.

• En rangert innholdsstrøm levert av gatewayen
• Innholdsdetaljer med bilder og formatert tekst
• Utgiverprofiler, så en leser kan følge en kilde

Selvstyrte verktøy: kartlegginger en person gjør selv, resultatene, og partnerfunksjonene bygget rundt dem.

• Ta en kartlegging, og les resultatene
• Gledeskartet — et personlig bilde, og et delt
• Legg til, bli med, inviter og sammenlign partnere
• Partnerdetaljer, så en sammenligning er til å lese heller enn en poengsum

Katalogen slik en klient møter den: å bla, sammenligne, lagre, spørre, og samtalen som følger.

• Bla og filtrer i katalogen over behandlere
• En profil med kvalifikasjoner, språk, tjenester og omtaler
• Lagrede behandlere — Mine behandlere
• Samtale med en behandler, og listen over de samtalene
• Forespørsel om en rådgivende prat, for et spørsmål som ennå ikke er en bestilling

Hva som faktisk kan bestilles, med pris, varighet og om det er på nett eller på stedet.

• Bla i tjenestene klinikken tilbyr
• Tjenestedetaljer med pris, varighet og leveringsform
• Rett til bestilling eller kjøp fra tjenesten

Å kjøpe — én time, en pakke, eller et produkt. Det er her klippet en klient senere bruker, kommer fra.

• Produktkatalog og produktdetaljer
• Handlekurv, kasse og tjenestevilkårene som godtas ved kjøpet
• Ordrebekreftelse, og ordrehistorikken bak den
• Betaling håndtert av gatewayen, aldri av appen

Å bruke et klipp på en bestemt tid i en bestemt kalender — og alt klienten ser om den etterpå.

• Lag en bestilling mot virkelig ledig tid, i klientens egen tidssone
• Bestillingslisten, med hver tilstand en time kan ha
• Bestillingsdetaljer: lenke inn, sted og rom, flytting og avbestilling
• Kjøpte timer — klipp eid, brukt, og ennå å bestille

Å spørre offentlig, å spørre privat, og folkene en klient velger å dele framgang med.

• En offentlig spørsmålsstrøm, og å spørre før man binder seg til noe
• Spørsmålsdetaljer med behandlerens eget svar
• Supportsaker — meld en, følg den, les svarene
• Partnerinvitasjoner og partnerlisten

Den tredje fanen, og svaret på de fleste supportspørsmål. Alt appen vet om personen, på én skjerm.

• Bestilte møter og møtehistorikk, med tilbakemelding og omtaler av timer
• Klipp, kjøpte timer og favoritter
• Fakturaadresse, fakturaer, fakturadetaljer, betalingsmåter
• Varsler, samtaler med behandlere, partnersamtaler og spørsmål som er stilt
• Mine tjenester og mitt innhold, for dem som publiserer
• Rediger profil, endre passord, og kontoskjermene

Samme fane, sett av en behandler. Dette er det som gjør en hel praksis mulig å drive fra en telefon heller enn fra en pult.

• Ledig tid: timer per uke, og daterte unntak i timeplanen
• Klientenes samtaler, og klienthistorikken bak hver samtale
• Lever en timerapport fra timen den hører til
• Behandleranalyse — bestillingstrakten, ledetid og tall per klient
• Inntekt og de fire bøttene, skjult og erstattet av antall på en fastlønnsavtale

En samtaleassistent i appen, strømmet gjennom gatewayen så ingen modellnøkkel noen gang kommer til enheten.

• En samtaleskjerm med strømmede svar
• Samtalehistorikk, så en tråd kan tas opp igjen senere
• Rutet gjennom gatewayens KI-grensesnitt, som løses til en virkelig leverandør eller en attrapp

Kontrollene en person venter å finne, også de et tilsyn venter at de skal kunne finne.

• Appinnstillinger og språkvalg på tvers av 23 språk
• Personverninnstillinger, og hvilke varsler som kommer på hvilken kanal
• Sikkerhetsinnstillinger, også enhetssesjoner
• Vilkår, personvernerklæring og juridiske dokumenter i appen heller enn på et nettsted
• Sletting av konto, som en vei personen kan gå selv

Det hver funksjon over er bygget på. Ikke en skjerm, men grunnen til at skjermene oppfører seg likt.

• Nettverk mot gatewayen, med fornyelse av poletter og feilhåndtering på ett sted
• Sikker lagring for poletter og sikker enhetstilstand
• Ruting, så et varsel kan åpne nøyaktig den skjermen det gjelder
• Ett tema som bærer 7DaysCare-designsystemet
• 23 oversettelsesfiler, med kalendersystemet som følger personen, ikke virksomheten
• Delte komponenter, så en liste, en tom tilstand og en feil ser like ut overalt

Formidler pålogging mot forretningskjernen og utsteder sine egne kortlevde poletter. Appen holder aldri en nøkkel til kjernen.

• Pålogging, registrering, fornyelse og utlogging, med JWT utstedt av gatewayen
• Den påloggede brukeren og profilen deres
• Enhetsregistrering, så push-varsler kommer til rett telefon
• Juridiske dokumenter og godtakelsen notert mot en person

Alt en klient blar i før de bruker penger, levert raskt og mellomlagret der det er dyrt.

• Behandlere, profilene deres, ledig tid og tjenester
• Tjenestekategorier og produkter til å bestille
• Omtaler og vurderinger, med modereringstilstanden respektert
• Mellomlagrede oppslag for alt katalogen treffer gjentatte ganger

Den transaksjonelle halvdelen. Kjøp, klipp, bestilling, faktura og betaling, hver av dem lagt mot forretningskjernen heller enn bygget på nytt.

• Lag, flytt og avbestill en time, med regelen brukt av kjernen
• Ordrer og klippene de gir
• Fakturaer og fakturadokumenter
• Igangsetting og bekreftelse av betaling, bak et betalingsgrensesnitt

Den lesetunge halvdelen: hva en person blar i når de ikke bestiller.

• Den rangerte innholdsstrømmen og innholdsdetaljene
• Offentlige spørsmål og svar
• Utforsking, kartlegging og resultatene
• Partnerfunksjoner og sammenligningene bygget på dem

WebSocket-navet. Samtale, tilstedeværelse, KI-strømming og signalering for lyd og video, på én tilkobling.

• Styring av WebSocket-tilkobling og tilstedeværelse
• Samtale mellom klient og behandler, og gruppekanaler
• Signalering for lyd- og videosamtaler
• Levering av varsler og varslingsvalg per person
• Push-varsler gjennom Firebase Cloud Messaging

Filer, holdt slik at appen aldri snakker med lageret direkte og ingenting leveres fra en URL som kan gjettes.

• Sikker dokumenttilgang, som følger kjernens tilgangsregler heller enn å bestemme dem på nytt
• Opplasting og henting av medier, via gatewayen
• Bilder skalert og mellomlagret, så en katalogliste er billig på en telefon

Resten: å melde en sak, å be om en rådgivende prat, å si til appen hva dette oppsettet har slått på, og å snakke med en modell.

• Supportsaker og svarene på dem
• Forespørsler om rådgivende prat
• Oppsett i drift, så appen viser bare funksjonene denne virksomheten slo på
• KI-forespørsler, strømmet, med modellnøkkelen holdt her og ingen andre steder

Fire funksjonsbrytere, hver av dem løst til en virkelig leverandør eller en attrapp. Det er derfor hele boet kan vises, utvikles og testes uten en ekstern konto i det hele tatt.

• DATA_SOURCE — Odoo-forretningskjernen, eller et attrappdatasett
• PAYMENTS — en virkelig leverandør, eller en attrapp som oppfører seg som en
• NOTIFICATIONS — Firebase Cloud Messaging, eller en attrapp
• AI — en virkelig modelleverandør, eller en attrapp
• Ratebegrensning og polettbøtter i Redis, så en grense holder på tvers av arbeidere
• Ingen enkelt ekstern leverandør kan stoppe klinikken fra å selge, levere og notere en time

Timeplanmotoren under alt annet — kalendere, ledig tid, rom og reglene som avgjør hvilke tider en klient faktisk får se.

• En motor for ledig tid som løser timer per uke, daterte unntak og bestillinger som finnes, til ledige tider
• Timeplanleggere, verter, steder og rom, med kapasitet og kollisjonsoppdaging
• Regler for tider, ventelister og automatiske tilbud når en bestilling frigjøres
• Kartleggingsspørsmål stilt ved bestillingen, med svarene bevart på bestillingen
• Påminnelser på e-post og SMS, med sperrelister per person
• Kalenderpublisering som ICS, og lenker inn i eksterne kalendersystemer
• Oppmøteregistreringer, en bestillingstrakt og analysen bak tallene per behandler
• Ratebegrensning på offentlige bestillingsruter, og en slettevei for bestillingsdata

Selger en-til-en-timer som klipp. Dette er modulen som gjør kjøp og bestilling til to atskilte steg, som er det som lar en pakke selges i dag og settes opp over måneder.

• Timer solgt som klipp mot et produkt, enkeltvis eller som pakke
• Tjenestevilkår for pakker godtatt ved kjøpet og bevart i den versjonen som ble godtatt
• Trinnvise avbestillingsregler med varslingsfrister, gebyrer og en nådetid
• Flytting og avbestilling som gir klippet tilbake der regelen sier det
• Behandlerbøttene — kjøpt, bestilt, gjennomført, ikke bestilt — og framgang per behandler
• Bestillingslenker i portalen, og porter i nettbutikken som stopper et kjøp som ikke kan bestilles
• En sømløsning for lønn: timen låser sin egen andel ved bestillingen uten å vite hva en avtale er
• Tilbakemelding etter timen, og sporet av ikke møtt som påliteligheten trenger

Applikasjonslaget: behandlere og deres offentlige profiler, mobil-API-et, innhold og fellesskap, varsler, og kontoen klienten ser.

• Behandlerprofiler med et verifiseringsforløp, kvalifikasjoner, tjenester og kalendere
• Omtaler, vurderinger, offentlige spørsmål og behandlertavlen bak dem
• REST-endepunkter for mobilappen, JWT-autentisering, og WebSocket-sesjoner
• Sanntidssamtale — klient til behandler, partnersamtaler og gruppekanaler — brolagt til sesjonene
• Innhold og publisering: utgiverprofiler, en rangert strøm og utforsking
• Fakturaer, betalingsmåter og broen fra ordre til time
• Varsler på push, e-post og i appen, med en spredning for timevarsler
• Alders- og identitetskontroll, supportsaker, forespørsler om rådgivende prat og enhetsregistrering

Odoo-programClinic

De sytten ledelsesrapportene. Tolv spør om klinikkens register stemmer med det som skjedde; fire sammenligner hvordan behandlere har det; én står over dem alle.

• Samsvarslister: fastlåste timer, ubestilte klipp, dekning mot etterspørsel, betalingskjeden, gebyrbok
• Klar til utbetaling, avbestillingsatferd, etterlevelsesmappe, kontinuitet for klientene og modereringskøen
• Timer uten rapport, og avbestilte timer lest sammen med atferd
• Prestasjon: resultatkortet for behandleren, tabellen, pålitelighet og utfall for klientene
• Én omfangskontroll — hele virksomheten, utvalgte personer, én person — med en sammenligningsperiode
• Lagrede visninger og CSV-eksport på hver rapport
• En rapport skriver aldri: å avinstallere fjerner rapportene og endrer ingen drift

Det kliniske notatet en behandler arkiverer etter en gjennomført time — lagret som et sikkert dokument om klienten heller enn som et vedlegg på et møte.

• En rapport arkivert mot timen og notert som å være om klienten
• Kryptert i ro på tjenesten for sikre dokumenter, med en nøkkel per versjon
• Tilgangen avgjort bare av behandlingsteamet, aldri av en rolle eller av ansiennitet
• Rettinger arkivert som nye versjoner; den forrige versjonen blir nøyaktig som den var
• Hvert oppslag loggført, så det å purre på en manglende rapport aldri betyr å lese en

En løpende ordning heller enn et kjøp hver gang: en plan solgt i butikken, og én klients medlemskap mot den.

• Planer er butikkprodukter med bilde og beskrivelse; den offentlige katalogen er på /memberships
• Et medlemskap bærer klipp, samtaletilgang og minutter til rådgivende prat utenom nett
• Klipp blir vanlige klipp, så bestilling aldri lærer en annen regelbok
• Perioder med fornyelse og overføring, og hva som overføres avgjort av planen
• En behandler ser hvilke av sine klienter som er medlemmer, og av hva

Behandlertid kjøpt som minutter heller enn som en time, brukt i samtale og gjort opp til minuttet.

• En tjeneste kan selge et budsjett av behandlerminutter, med et valgfritt gyldighetsvindu
• Prisliste på selskapet, mulig å overstyre per tjeneste
• En bokføringspost per belastning, og et utdrag både klienten og behandleren kan åpne
• Budsjettet sjekkes der meldingen sendes, ikke der noen husker å sjekke det

Spørreskjemaet en klient fyller ut før den første timen, lagret som klinisk innhold heller enn som svar i en spørreundersøkelse.

• En tjeneste navngir spørreskjemaet som hører til den
• Klienten fyller det ut før timen, fra sine egne sider
• Svarene skrives rett til et kryptert dokument — aldri latt bli i undersøkelsens eget lager
• Klinikeren åpner det fra timen, under de vanlige reglene for dokumenttilgang

Bankoverføring som betalingsvei, for klinikker som vil at et menneske skal se på hver ordre før og etter at pengene flytter seg.

• Godkjenn ordren, fakturer den, ta imot kvitteringen, godkjenn kvitteringen, og lag så klippene
• Klipp kommer først når kvitteringen er godkjent, så en ubetalt ordre ikke kan bestille en time
• Et avslag bærer grunnen sin, og ordren går tilbake til den som kan rette den
• Hvert steg er en tilstand på ordren heller enn et notat noen la igjen

Den halvdelen klienten ser av veien utenom nett: hvor de betaler, hva de laster opp, og hva ordren venter på.

• Hver tilstand har sin egen farge og sitt merke på Mine ordrer, så å vente er synlig forskjellig fra avslått
• Betal og last opp kvitteringen i én dialog, uten å forlate ordren
• Grunnen til avslaget vises der den som må handle på det, vil lese den
• Et tavlekort for ordrer som trenger noe fra klienten

Bøkene, på sin egen tavle: hva som kom inn, hva som skyldes, hva leveringen kostet og hva som ennå kommer. Atskilt fra administratorens med vilje — å purre en ubetalt faktura i drift er én jobb, og å føre regnskapet er en annen.

• En startside med fire pengefliser, seks helsetall, seks diagrammer og en flaggliste
• Tjueen rapporter: kontanter, inntekt, leveringskostnad, prognose, lekkasje og to kontrollister
• Periodisert eller kontant, fem perioder og et eget intervall, ført gjennom hver nedboring
• Snevre inn hver rapport på tjeneste, behandler eller klient; en diagramvisning og CSV på hver side
• Ingenting nettet, ingen rate uten en nevner, prognoselag aldri summert
• En sjekkliste for månedsslutt der alle haker er den gode avslutningen
• Leser regnskapet og aldri klinisk innhold — en egen tildeling, på en intern konto

Hva som må gjøres, for de fire teamene rundt virksomheten. Salg, personal, marked og leveranse får hver sin side, og hver side åpner med samme spørsmål: hva er forsinket, hva er nå, hva kommer, og hva har ingen lovet å gjøre noe med.

• Fire oversikter, hver av dem en post heller enn kode, slik at en bransjepakke kan legge til en
• Aktivitetsraden på hver side: forsinket · i dag · planlagt · ikke satt opp · trenger oppmerksomhet
• «Ikke satt opp» er båndet Odoo ikke har noen tilstand for: en åpen post ingen har lovet å gjøre noe med, og som ikke vises på noen annen skjerm
• Oppmerksomhetsregelen står under sitt eget antall, for en grense leseren ikke kan se, er en grense hen slutter å tro på
• Tjueseks rapporter, hver med koden til den kravlinjen den oppfyller
• Et tall hvis modell ikke er installert, melder «ikke relevant», aldri null
• Lister som skal være tomme, med et nattlig varsel som leveres avslått
• Hver andel skriver ut nevneren sin, og en tankestrek under fem poster
• Dagens tilstedeværelse og fravær — fortsatt stemplet inn, stemplet inn i dag, fri i dag
• Avhenger av base, mail og web og ingenting annet: den rapporterer om CRM-, personal-, utsendings-, prosjekt- og avtaledata uten å kreve noen av dem

Hvordan det går, i den appen lederne allerede åpner. Fire sider i Odoos egne oversikter, i en egen seksjon «Klinikkens team», bygget slik sidene for Salg og Utlegg der er bygget.

• Fire sider — CRM, salg, leveranse, personal — ved siden av Odoos egne
• Fire nøkkeltallsfliser per side, hver med forrige periode ved siden av
• To diagrammer og to til fire topplister per side, hver av dem åpner postene bak seg
• Et tall som beskriver en tilstand i verden tar ingen periode og viser ingen sammenligning: en bemanning filtrert til nitti dager er ikke en bemanning
• Et diagram gruppert på en dato tar perioden; et gruppert på et trinn gjør det ikke
• Arbeidsbøkene genereres og kryssreferansene deres valideres før noe skrives
• Hver side er synlig for den Odoo-gruppen som eier dataene sine, så ingenting ekstra gis

Tre sider til i samme seksjon, holdt for seg fordi hver av dem krever en app virksomheten kanskje ikke kjører.

• Tilstedeværelse: stemplet inn nå, poster, arbeidede timer, ekstra timer, per person og per avdeling
• Fravær: søknader uten svar, godkjente dager, avslag, og hvor fraværet faller per måned, type og avdeling
• Utbetalinger til ansatte: å melde, å godkjenne, å refundere, og hva som er krevd i perioden
• Skilt fra de andre oversiktene fordi hver side tvinger fram en app — tilstedeværelse, fravær, utlegg
• Tilstedeværelse teller poster, ikke mennesker: en lunsjpause gjør én person til to rader, og siden sier det
• «Stemplet inn nå» er et tilstedeværelsestall i arbeidsdagen og etter den en liste over dem som glemte å stemple ut

Et offentlig skjema som gjør et spørsmål til en oppgave noen eier.

• Et skjema på /support/ticket som hvem som helst kan bruke, pålogget eller ikke
• Hver innsending åpner en oppgave, tildelt butikkadministratoren
• Den som sendte inn, følger sin egen sak, og administratoren varsles i Discuss

Et behandlingsforløp med en start, en slutt og en plan — ryggraden alt annet i den kliniske journalen henger fra. Behandling er ikke en strøm av timer, og journalen sier det.

• En episode åpner på den første gjennomførte timen, og en klient har én åpen om gangen
• En behandlingsplan per episode: problem → mål → delmål, tre nivåer og ikke mer
• Et mål bærer en tittel, en måldato og et resultat — hva det ble arbeidet mot, og hvordan det gikk
• Løpende eller Avsluttet som den klientvennlige tilstanden, holdt fra de seks kliniske utfallene så de to aldri deler en skjerm
• En plan gjennomgås eller erstattes, aldri redigeres på stedet: versjonen som ble avtalt, blir som den var
• Å lukke en episode ber om et utfall på hvert åpent mål, fordi det er det eneste øyeblikket noen vet svaret — og sier hvor mange som ville lukket uten et
• Lukkingen starter oppbevaringsklokken dokumenttjenesten regner fra
• Hver behandler som har møtt klienten, ser episoden; å lese en kollegas rapport er en egen forespørsel, godkjent av en klinikkadministrator og skrevet til loggen uansett
• Klienten leser samme episode på sine egne sider, i ord som aldri vurderer dem

Notatmaler som en ordnet liste typede felter, så et notat er svar heller enn prosa ingen kan søke i.

• En mal er en versjonert, publisert liste typede felter — tekst, tall, skala, valg, dato
• Et ferdig notat er svarene pluss et gjengitt sikkert dokument
• Svarene kan leses nøyaktig når dokumentet deres kan: én tilgangsregel, ikke to som glir fra hverandre
• Synlighet per felt, så en privat observasjon er fraværende fra klientens kopi heller enn skjult i den
• Maler valgt på skjemaet for timerapporten, etter fagfelt

Startinnholdet til malmotoren: tusen navngitte notatformater, så en klinikk ikke begynner med et tomt bibliotek.

• Over tusen navngitte maler — SOAP, DAP, BIRP, kartlegging, gjennomgang — gruppert etter fagfelt
• Installert som data, til å redigere etterpå som enhver mal klinikken skriver selv

Hva en klient noterer mellom timene, knyttet til målet det måler. Et program som rapporterer mot ingenting, er hvordan oppfølging blir hjemmearbeid.

• Et programbibliotek med seks typer poster: spørreskjema, måling, valg, dagbok, opplasting, oppgave
• Et program sendes til et mål, så hver oppføring rapporterer mot noe planen faktisk ba om
• Klienten noterer på sin egen plan: det som skal gjøres i dag først, så hvert mål og hva som er åpent mot det
• Ingenting på en klientflate teller eller vurderer dem — noe som ikke er notert, leses som ikke notert, og det finnes ingen rate, ingen poengsum og ingen rekke
• Klinikerens liste, verst først: risikoflagg å bekrefte, aldri startet, stille i fjorten dager, slutter denne uken
• En rate med færre enn fem å måle vises som en strek, og et antall som ikke lot seg beregne vises som utilgjengelig — aldri som null
• «Jeg synes dette er vanskelig», som når klinikeren uten et tall knyttet til seg
• Rapporter arkivert på et mål heller enn på en time, kryptert, under samme tilgangsregler som hver annen klinisk rapport
• Program gjennomgått i en time, telt av klinikkrapporten som spør om noen så på det
• Hver flate som bærer observasjoner, sier at oppføringer ikke følges i sanntid

Skåringsverktøy klinikken eier. Ingen verktøyinnhold leveres, og ingen lisens hevdes: klinikken legger inn det den har rett til å bruke.

• En skår lagres med den versjonen av verktøyet som ga den, og beregnes aldri på nytt
• Bånd og terskler per verktøy, der et risikobånd hever et flagg noen må bekrefte
• Fylt ut av klienten i portalen eller i timen, og kanalen notert uansett
• Tidslinjer per verktøy med retning; skårer fra ulike verktøy slås aldri sammen til ett tall, fordi de måler ulike ting på ulike skalaer
• Et spørreskjema er en type programpost, ikke en egen funksjon med sin egen liste

Ett notat skrevet én gang og arkivert til hver deltaker som deres eget dokument.

• Én skrevet kilde, ett arkivert dokument per deltakende klient
• Et privat felt er fraværende fra en annen deltakers dokument, ikke skjult inne i det
• Arkivert til dem som møtte, ikke til alle som var bestilt
• Timen regnes som dokumentert bare når hver deltaker har sin kopi

En dato en kliniker setter når en time slutter, handlet på når den kommer.

• En innkalling er en dato og en grunn, laget ved slutten av en time
• Den inviterer; den bestiller aldri
• Innkallinger som forfaller, står i klinikkens daglige oppsummering før noen melding sendes automatisk
• Automatisk invitasjon står av med mindre klinikken slår det på

Diagnosekoder der faktureringen trenger dem, til å søke i heller enn å skrive fra hukommelsen.

• Søkbare ICD-10-CM-kapitler og koder
• En kode notert på klienten og ført videre til ordrer og fakturaer

Én spørsmålsliste i produktet, og de tre tingene den ikke bærer med seg av seg selv: en stabil svarnøkkel, synlighet per spørsmål, og en markering for det ene tallet som får forlate det krypterte.

• I produktet hadde fire byggere vokst fram: notatmalens innskrevne felter, timebokens egne spørsmål, oppfølgingspunktene og spørreskjemaet bak inntaksskjemaet
• Fire byggere er fire steder å legge til en spørsmålstype, fire framvisninger og fire svar på «hvor ble det svaret av?»
• En spørsmålsliste skrives i survey.survey og ingen andre steder
• Det opprettes aldri en svarrad i spørreskjemaet: det lageret er vanlige Postgres-kolonner, riktig for «hvordan gikk timen?» og galt for en sykehistorie
• Svarene i et sikret skjema finnes bare inne i et kryptert dokument, som en JSON-versjon og en HTML-versjon
• Det eneste unntaket er et tall forfatteren har merket som diagrammerbart, for et diagram kan ikke lese kryptert tekst
• Et privat spørsmål er fraværende i det delte dokumentet og ligger i sitt eget, i stedet for å være skjult på en skjerm noen kan endre
• Når et skjema først er fylt ut, slutter spørsmålene, svaralternativene og alternativpoengene å flytte seg
• Hvem som får lese et inntaksskjema er ikke hvem som får lese et strukturert notat: dokumenttyper hører derfor til modulen som bruker skjemaet

Spørsmålene til en timeplan utformes i spørreskjemaet og arkiveres kryptert, slik at timeboken kan fortsette å være en timebok.

• En timeplan navngir et spørreskjema, og den offentlige bookingsiden viser det med den ene framvisningen
• Svarene arkiveres i et kryptert dokument knyttet til bookingen
• Timebokens egen spørsmålsmodell blir værende, og bør det: et telefonnummer, en referanse, en samtykkeavkrysning, og de som skriver rett på kontaktposten der resepsjonen må kunne lese dem
• Det den hadde feil form for, er en virksomhet som spør «hva bringer deg hit i dag?»
• Det svaret lå tidligere i en vanlig kolonne helt uten tilgangskontroll, i klartekst på bekreftelsessiden, og kopiert inn i beskrivelsen av kalenderhendelsen — som synkroniseres utover og følger med i hver invitasjon
• Ingenting i denne modulen skriver til noen av dem, og det er formålet med den snarere enn en bivirkning
• Avhengigheten til dokumenttjenesten bor i denne broen, slik at en installasjon som bare vil ha en bookingside, får bare det

Den innskannede samlingen psykologiske verktøy som søkbare poster, med et valgfritt levende skjema så snart en skanning gjøres om til ett.

• Den innskannede samlingen lastet som poster som bærer OCR-teksten sin, slik at et verktøy kan finnes på det som står på det
• En inndeling etter det systemet hvert verktøy retter seg mot
• Et valgfritt spørreskjema, opprettet når en skanning blir et levende skjema
• Spørsmål skrives aldri her — det er den ene byggerens oppgave
• Bygges om fra kilde-PDF-ene med skript i stedet for å redigeres for hånd

Lønnsbetingelser for timer på ansettelsesavtalen, og utbetalingssyklusen som gjør dem opp. Ingenting beregnes på nytt ved utbetalingen — hver time låste sin egen andel da den ble bestilt.

• Fire lønnstyper: månedslønn, timesats, fast honorar per time, eller en prosent av hver time
• Betingelser holdt på avtaleversjonen, så historikken er datert og én gjelder om gangen
• Utbetalingssykluser — ukentlig, hver fjortende dag, månedlig eller kvartalsvis — festet til kalenderen eller avtalestarten
• En daglig jobb som åpner en utbetaling i utkast morgenen en syklus lukkes
• Å bekrefte en utbetaling skriver én leverandørregning per behandler fra de låste beløpene
• En bevart utbetalingshistorikk behandleren kan se, også avbrutte utbetalinger
• Å forhandle på nytt i dag skriver aldri om hva som ble skyldt forrige måned

Sender engasjementsavtaler til signering fra registreringen de hører til, og bevarer den signerte historikken på den registreringen.

• Send en avtale til signering fra avtalen selv
• Hver forespørsel bevart mot den registreringen som dens historikk
• Timelønn kan holdes tilbake under en avtale ingen har signert ennå
• Installerer seg bare når begge sider er der, så ingen av modulene bærer en avhengighet den ikke trenger

Selvstendige behandlere leier plattformen på et abonnement vi bygger. Denne modulen holder abonnementsformene, abonnementene og reglene for hva tilstanden til et abonnement lar en behandler gjøre.

• Abonnementsformer bærer en kanal — egen praksis, markedsplass eller begge —, måneds- og årspriser, og vilkårslinjer skrevet som setninger
• Funksjonsbryterne til en form leses ut av de installerte modulene i stedet for å skrives inn
• Et abonnement kopierer formens vilkår og funksjoner ved signering og leser dem aldri tilbake, så en prisendring i morgen lar dagens abonnementer være i fred
• Ett gjeldende abonnement per behandler og høyst ett på vei, håndhevet av to delvise unike indekser i stedet for av en sjekk noen kan glemme
• Hver ny selvstendig behandler starter på den innebygde prøveperioden — sju dager som standard, satt i innstillingene
• Når prøveperioden er over, venter nye bookinger og behandlerens lenke på at et abonnement velges, signeres og betales. Poster lukkes aldri
• De ansatte kan tildele en form nettstedet ikke viser — på kort, på faktura eller helt vederlagsfritt —, med avtalen sendt eller et signert eksemplar vedlagt, og grunnen nedtegnet
• Abonnement og fakturering på behandlerens egen konto, og et banner i arbeidsflaten under prøveperioden eller etter at den er løpt ut
• Ansatte behandlere, knyttet gjennom arbeidsavtale, står aldri på et abonnement og sperres aldri

Hvem som brakte hvilken klient til hvilken behandler — det ene faktum hvert gebyr en selvstendig behandler betaler henger på, og det ene plattformen ikke nedtegnet.

• Én rad per par av behandler og klient, med opphavet og tilhørigheten: behandlerens klient, eller plattformens klient
• Tilhørigheten settes ved første kontakt og endres av ingenting annet enn en overføring fra de ansatte, med grunn
• Behandlerens korte lenke, /e/<kode>: den som følger den, registrerer seg og blir den behandlerens klient
• Allerede registrert og ny hos den behandleren: trykker «Bli med». Allerede den behandlerens klient gjennom plattformen: personen forblir plattformens klient, og klikket loggføres
• Hvert besøk på lenken, og hva det ble av det
• Hvordan en person i det hele tatt kom til plattformen — direkte, eller innført av en behandler — holdes atskilt fra tilhørigheten, for det ene er et faktum om et menneske og det andre om et par

Tar behandleren imot klientens penger, skylder hen selskapet dets andel. En månedlig kjøring som fakturerer den og følger den til betalt.

• Når behandlere godkjenner ordrer og sender betalingslenker, bærer tilbudet, fakturaen og betalingssiden behandlerens eget firmanavn, adresse og organisasjonsnummer for merverdiavgift som selger
• Om behandleren tok imot betalingen, låses fast på timen ved bookingen, ved siden av fordelingen av andelen, slik at å endre innstillingen i morgen ikke rekker tilbake til forrige måned
• Ingen ny formel: selskapets andel sier allerede hva selskapet beholder, og holder behandleren pengene, er det nettopp det beløpet hen skylder
• En behandler på lønn beholder ingenting av en time og skylder derfor det hele; en frilanser på 70/30 skylder de 30
• Én innkrevingskjøring per syklus, som speilbilde av utbetalingskjøringen — én kundefaktura per behandler for summen av de andelene hen tok imot
• Å bokføre den fakturaen med en gang eller vente på at noen ser på den, er en innstilling, slått på som standard
• «Betalt» er Odoos egen betalingstilstand: denne modulen iakttar den og oppretter aldri en betaling
• Behandlerens arbeidsflate får en side Betalinger — tjent, mottatt, skyldig, og hver faktura med sin tilstand
• Oversiktene for administrasjon og regnskap får den andre siden: åpent mot betalt, tellet og summert, med månedens inntekter ved siden av

Listen over hva de installerte modulene kan, meldt inn av hver modul selv, slik at abonnementer kan slå den av og på.

• Ingen skriver inn katalogen: en modul med noe verdt å selge leverer én funksjonspost per evne
• Odoo oppretter de postene når modulen installeres og sletter dem når den avinstalleres, slik at katalogen alltid beskriver hva denne databasen faktisk kan
• Ingen gjennomsøking, ingen synkroniseringsjobb og ingen andre liste ved siden av modullisten å komme i utakt med
• Avhenger med vilje av ingenting annet enn base, slik at det å melde inn en funksjon aldri trekker en klinisk modul inn i en avhengighet til plattformskallet
• Hva en funksjon betyr for én behandler — om abonnementet hens har den på, og opp til hvilken grense — hører til abonnementet, ikke hit

Tjenesten selv. En modell tar den i bruk på én linje og får sine dokumenter, et antall, og en arkiveringsdialog som i klart språk sier hvem som vil kunne åpne resultatet, før det lagres.

• Kryptert i ro med en egen nøkkel, lagret utenfor Odoos fillager og aldri levert gjennom /web/content
• Tilgang etter uttrykkelige regler, nektet som standard: en tillatelsesregel som passer og ingen avvisningsregel som passer, hver gang
• Å være administrator, leder, eller den som arkiverte det, gir ingenting i seg selv
• Hvert oppslag så vel som hver skriving loggført, i en hashlenket logg som bare legges til og ingen kan redigere
• Versjonert og bare tilføyende: en retting er en ny versjon, den forrige er uberørt
• Oppbevaring og sletting etter relative regler, gjennomført ved å ødelegge nøkkelen
• Søker bevisst ikke inne i dokumenter — kryptert innhold kan ikke fritekstsøkes

Det kryptografiske laget, holdt som en egen modul så nøkkelhåndteringen kan gjennomgås og revideres uten å lese resten av programmet.

• AES-256-GCM-konvoluttkryptering: en tilfeldig datanøkkel per dokumentversjon, pakket under en driftsnøkkel
• Nøkkelkrypteringsnøkkelen lagres aldri i databasen
• Kryptotekst i en egen mappe, utenfor fillageret
• Nøkkelrotasjon som pakker nøkler på nytt uten å skrive om en byte kryptotekst
• Kryptoknusing: å ødelegge nøkkelen sletter dokumentet og lar revisjonssporet stå
• Nekter å starte hvis nøkkelen mangler, er lesbar for alle, eies av gal bruker, eller er lagret der den ville reise med dataene

Der en person leser dokumentene som er delt med dem om dem selv, på /my/documents — og bare dem.

• En person ser et dokument når en regel for den det gjelder tillater det og ingenting avviser det — aldri bare fordi det er om dem
• Psykoterapinotater, forseglede dokumenter og dokumenter under en gjeldende beslutning om å holde tilbake, vises aldri, uansett hva reglene sier
• Ett filter brukt av hver rute, så det finnes bare én definisjon av hvem som får se hva
• Innhold dekryptert i minnet og strømmet; ingenting skrevet til disk
• Et dokument brukeren ikke får se, gir 404, aldri 403 — å gjette referanser må ikke avsløre hvem det finnes journaler om
• Hver visning og nedlasting loggført, også personens egen, og siden sier det
• Oppslag ratebegrenset per bruker, regnet fra tilgangsloggen så grensen holder på tvers av arbeidere

Arkiverer sikre dokumenter mot kontakter — det vanligste subjektet, siden den et dokument er om, vanligvis er den det arkiveres mot.

• Legger tjenesten for sikre dokumenter til res.partner
• Installerer seg når begge sider er der, og avinstalleres uten å røre noen av dem
• En bro per program, så å ta tjenesten i bruk på en kontakt ikke trekker inn urelaterte program

Arkiverer sikre dokumenter mot salgsmuligheter — en pakke for aktsomhetsvurdering er ikke noe klinisk, og har nøyaktig samme krav.

• Legger tjenesten for sikre dokumenter til crm.lead
• Kryptert, regelstyrt og loggført ved hvert oppslag, som hvert annet sikkert dokument
• Installeres og avinstalleres rent og uavhengig av de andre broene

Arkiverer sikre dokumenter mot ansattregistreringer — en personalsak eller en bedriftshelserapport er noe en leder arkiverer og de fleste i HR ikke skal kunne åpne.

• Legger tjenesten for sikre dokumenter til hr.employee
• Tilgang nektet som standard, så en HR-rolle ikke åpner en mappe i kraft av å være en HR-rolle
• Installeres og avinstalleres rent og uavhengig av de andre broene

Arkiverer sikre dokumenter mot oppgaver — en fortrolig kontrakt eller en signert leveranse bevart der arbeidet følges.

• Legger tjenesten for sikre dokumenter til project.task
• Installerer seg når begge sider er der, og avinstalleres uten å røre noen av dem

Arkiverer sikre dokumenter mot ordrer — en signert avtale, eller en kundes identitetsdokumenter, bevart mot salget de hører til.

• Legger tjenesten for sikre dokumenter til sale.order
• Installerer seg når begge sider er der, og avinstalleres uten å røre noen av dem

Valgfritt: flytt nøkkelkrypteringsnøkkelen bort fra Odoo-verten, så en kopi av databasen ikke er en kopi av dokumentene.

• Dokumentnøkler pakket og åpnet gjennom en fjern myndighet heller enn lokalt
• Nøkkelkrypteringsnøkkelen ligger aldri på maskinen som kjører programmet
• Slås på per oppsett; det lokale alternativet blir tilgjengelig og uendret
• En myndighet som ikke er å nå, nekter å åpne dokumenter heller enn å falle stille tilbake

Avgjør behandlingsteamet. En terapeut når journalene til folkene på sin egen liste, ikke klinikkens — som er det som gjør kravet om minste nødvendige mulig å håndheve heller enn en ambisjon.

• Behandlingsforhold — kliniker til klient, med en type, en start og en slutt
• Tilgangen slutter når forholdet gjør det, etter en nådetid lang nok til å gjøre ferdig utestående notater
• Kliniske roller som avgjør hvilken del av programmet noen når, aldri hva de kan åpne
• En profil bare for ledelsen for hendelser, klager og meldinger av bekymring — lukket også for den som meldte
• Utleveringsregisteret: hva som forlot tjenesten, til hvem, og på hvilket grunnlag
• Rettigheter for den det gjelder: innsynskrav med sin lovbestemte klokke, rettinger som legger til heller enn overskriver, begrensninger som forsegler
• Ankerpunkter for oppbevaring — siste kontakt, fødselsdato, dødsdato — for at grunnlaget skal regne mot dem
• Avviksregistreringen selv — hva som skjedde, hvem som ble berørt, og om den som tok det kunne lese det — med jurisdiksjonslagene som legger sine egne klokker til én hendelse heller enn at hvert holder sin egen
• Fortrolig kommunikasjon: en klient kan be om at en kanal aldri brukes, og det nektes der meldinger går ut heller enn der noen husker — e-post til en sperret adresse avbrytes, aldri stille sendt til adressen på fil
• Ingen felt noe sted for å notere hvorfor de ba om det, fordi å kreve en forklaring er det regelen forbyr
• Én utsettelse på et innsynskrav og bare én, målt mot datoen som følger heller enn mot tallet som ble skrevet — en måned fra mars og en måned fra juli er ikke like lange
• Gebyret delt opp i komponentene forskriften tillater, fordi «rimelig, kostnadsbasert» er en påstand, og en påstand med ett tall bak er en ingen kan sjekke
• En kopi til noen personen navnga, nektet til deres signerte skriftlige instruks er på fil
• Et avslag gjennomgått av noen andre enn den som avslo — håndhevet, ikke overlatt til rutine
• En nektet retting personen er uenig i: deres erklæring, et eventuelt tilsvar, og begge som reiser med hver senere utlevering av den omstridte journalen — lagt ved av registeret, ikke av noen som husker
• Den nedstrøms som alt har opplysningene, navngitt og varslet, fordi en retting ingen hører om, retter én kopi av en journal

GDPR-laget: rettighetene og styringsmaskineriet HIPAA ikke har noen ekvivalent for, som er derfor en utgave bygget etter amerikansk standard ikke dekker EU.

• Rettslig grunnlag notert per dokumenttype — art. 9 nr. 2 bokstav h for behandlingsjournaler, ikke samtykke
• Sletting (art. 17) gjennomført ved å ødelegge nøkkelen, så retten oppfylles uten å slette beviset for hva som ble holdt
• En slettevurdering, og ingenting ødelagt mens et rettslig hold eller en oppbevaringstid står
• Dataportabilitet (art. 20) som en strømmet zip — metadata som JSON, innhold som arkivert, hvert dokument loggført for seg
• Avviksmelding (art. 33/34): 72 timer til tilsynet, og krypteringsunntaket etter art. 34 nr. 3 bokstav a
• DPIA- og protokollregistreringer bevart som del av styringsmappen

En bro, ikke en utbygging — knytter en signert personvernmelding til bekreftelsesregistreringen, så mappen kan svare på hvilken versjon de faktisk så.

• En fullført signatur skriver bekreftelsen, én gang — en webhook levert to ganger må ikke gjøre antallet utestående feil
• Signaturforespørselen navngir meldingsversjonen, fordi det er det eneste spørsmålet en bekreftelse blir stilt
• En penn på et skjema i resepsjonen er fortsatt en skriftlig bekreftelse; broen legger til en vei heller enn å erstatte den vanlige
• En forespørsel signert av en kliniker på en klients vegne er ikke den klientens bekreftelse, og telles ikke som en

UK GDPR og Data Protection Act 2018 på samme tekniske kjerne — med testen om alvorlig skade bygget som et arbeidsforløp heller enn som et flagg.

• Testen om alvorlig skade (DPA 2018 Sch. 3 Pt. 2) notert med hvem som bestemte, når, over hvilke dokumenter og hvorfor
• Bare til å ta av noen med et gjeldende behandlingsforhold, som systemet sjekker heller enn antar
• Kommer i en gjennomgangskø før den utløper, og faller bort av seg selv etter seks måneder
• Å løfte den setter tilbake merkingen dokumentet hadde før, ikke «vanlig»
• Å holde tilbake er fra den det gjelder, ikke fra behandlingsteamet — de som behandler personen, leser det fortsatt
• Oppbevaringsplanen i NHS Records Management Code of Practice 2021 som startdata
• Håndtering etter Access to Health Records Act for journaler etter døde

De administrative sikringstiltakene — halvdelen av HIPAA som ikke handler om kryptering, og halvdelen håndhevingen nevner mest.

• Risikoanalysen som en øvelse med en periode, et omfang og en metode, atskilt fra registeret over hva den fant — så neste år kan sammenlignes med dette
• Hver risiko ført videre til neste vurdering med en lenke tilbake, fordi et register som starter blankt hvert år, mister historikken over hva som ble bestemt
• Den iboende vurderingen beregnet og den gjenstående bevisst ikke — en gjenstående risiko regnet ut ved å trekke fra en kontrollpoengsum er en fiksjon som sier det samme om en kontroll testet forrige uke og en skrevet i en policy
• Å godta en risiko krever en notert grunn; avgjørelsen er ofte riktig, og ingen kan si i etterkant hvilken det var
• Aktivitetsgjennomgangen med spørsmålene navngitt — ingen behandlingsforhold, nødtilgang, likt etternavn, utenfor arbeidstid, et volumavvik — fordi «gå gjennom loggene» uten å si hva man skal se etter, er hvordan gjennomganger blir en signatur på ingenting
• Å fullføre en gjennomgang bekrefter hver hashlenke som er rørt i perioden, som er det som gjør en logg der tukling kan oppdages, til en der tukling blir oppdaget
• Utpekinger holdt som datointervaller med hullene beregnet, fordi kravet ikke er hvem som har den i dag, men at noen har hatt den uten brudd
• Sanksjonsregistreringer lesbare bare for en gruppe ingen blir med i underforstått — en sanksjonsregistrering som lekker, er sin egen hendelse
• En avslutningssjekkliste og en daglig jobb som reiser en for alle hvis sluttdato er passert: at kontoer lever lenger enn ansettelsen, er kontrollen som oftest svikter
• Opplæring med utløp, fordi opplæring som er utløpt, ikke er opplæring
• En kritikalitetsanalyse som sjekker sin egen regning: et system hvis database gjenopprettes saktere enn systemet selv, har et gjenopprettingsmål noen skrev ned, og de to tallene bor på ulike rader i et regneark
• Beredskapsplaner som sier når de sist ble testet, og en liste over dem som aldri ble det — det eneste som skiller en virksomhet med en plan fra en som tror den har en
• En test som ikke nådde målene sine, må si hva som gikk galt, fordi en test som ikke lærte noen noe, ikke er bevis
• Overføringssikkerhet som en historikk heller enn en påstand: «vi bruker HTTPS» handler om nåtid, og disse registreringene sier at det var sant de dagene noen spør om
• Sjekker som ikke kan redigeres eller slettes, fordi poenget med en historikk er at den ikke kan ryddes

HIPAA-laget. Skillet for psykoterapinotater holder i lagringen heller enn å hvile på at tilgangsreglene er riktige.

• Det utpekte journalsettet (45 CFR 164.501) merket per dokumenttype, så et svar på et innsynskrav ikke kan ta med det som er utenfor
• Psykoterapinotater i sitt eget nøkkelrom — nøkkelen som åpner den vanlige journalen, åpner ikke dem
• En tildeling til den det gjelder på notater nektes på hver sti, også en direkte skriving til regeltabellen
• Et dokument som alt er skrevet, kan ikke merkes om til notatenes nøkkelrom
• 42 CFR Part 2: varselet om forbud mot videre utlevering laget heller enn skrevet
• Seks år med utleveringer i registeret, etter underdelen
• Avviksmelding (164 Subpart D): en utlevering uten grunnlag antas å være et avvik til vurderingen av de fire faktorene sier noe annet, med resonnementet notert
• Seksti dager til personene fra oppdagelsen, beregnet heller enn skrevet, og varslet om før den løper ut
• De to fem hundrene holdt fra hverandre — pressemelding over 500 innbyggere i én delstat, HHS-melding ved 500 eller mer i alt
• Individuelle meldinger som bærer alle fem elementene 164.404(c) krever, så ingen kan stille utelates fra et brev som leses godt
• Årsloggen over små avvik laget som et dokument, ikke satt sammen fra hukommelsen i februar
• Notice of Privacy Practices versjonert, med bekreftelser notert mot den versjonen noen faktisk fikk
• Halvdelen som er lett å hoppe over: der ingen signatur ble innhentet, kreves forsøket og grunnen — en perm med signerte skjemaer kan ikke svare på det spørsmålet
• En arbeidsliste over klienter med ingenting notert mot meldingen som gjelder
• Grunnene for å nekte innsyn som en lukket liste, hver med om personen får en gjennomgang av den — å tilby en som ikke finnes og å nekte en som gjør det, er begge funn
• De fire grunnene for å nekte en retting, lukket også, og den som er et faktum om dokumentet, sjekket mot dokumentet
• Part 2-regelen fra 2024: ett samtykke som dekker behandling, betaling og drift, nektet med mindre det kan trekkes tilbake — ett samtykke uten vei tilbake er det noen glemmer at de ga
• En Part 2-begrensning på de formålene behandlet som en rett heller enn en forespørsel, og sjekket før den generelle — en sjekk som kjørte motsatt vei, ville tillatt utleveringen før den nådde spørsmålet
• Et avvik som gjelder journaler om rusbruk, sier det i meldingen, heller enn å begrave det under «behandlingsopplysninger»
• 164.410 som to klokker: business associate har seksti dager fra sin egen oppdagelse og våre starter når de sier det til oss, så et avvik kan være 118 dager gammelt uten at noen har brutt en frist
• Part 2-pasientmeldingen versjonert ved siden av personvernmeldingen, heller enn en konstant i Python ingen versjonerer

Den tyske oppbevaringstiden, som en regel dokumenttjenesten regner heller enn en linje i en policy ingen bruker.

• § 630f BGB: ti år etter siste kontakt, lagt inn som en oppbevaringsregel
• Avgrenset til denne modulen heller enn til hele EU-pakken, fordi perioden er nasjonal

De norske reglene GDPR-laget ikke dekker, hver av dem plassert der handlingen skjer heller enn i en policy: å publisere en profil, å bekrefte en utbetaling, å utlevere noe til en forelder.

• Pasientjournalforskriften § 14: pasienten leser hvert oppslag i hver journal om seg, også de journalene de ikke får se — etter type, aldri etter tittel
• En oppbevaringstype uten slettedato i det hele tatt, fordi Norge bevarer journaler så lenge de trengs; årene er et gjennomgangsintervall, og et menneske bestemmer, med en grunn
• En journaloverføring til en etterfølger, Norsk helsearkiv eller Nasjonalarkivet, bygget i det øyeblikket den lastes ned, notert som en utlevering per dokument, og til å laste ned én gang
• Helsepersonelloven § 74: en profil som bruker en beskyttet tittel, kan ikke publiseres uten et sjekket HPR-nummer, og sjekken kjører ved skriving så synkroniseringen ikke kan komme rundt den
• Nærmeste pårørende, forelder, verge og framtidsfullmakt, med aldersreglene i §§ 3-4 og 4-3 håndhevet i utleveringsregisteret heller enn som et filter på en side
• Arbeidsmiljøloven § 1-8: en utbetaling som betaler per time, bekreftes ikke uten en gjeldende vurdering, og fakta bak vises uvektet fordi spørsmålet er rettslig
• Personvernombud og informasjonssikkerhetsansvarlig som utpekinger, sjekket bare for norske selskaper

Rollene finsk rett krever at en tilbyder navngir, og pliktene som henger av hver av dem. Uavhengig av den norske pakken — begge slås på av selskapets land, så én database kan holde begge.

• Utøvere med lisens og med beskyttet tittel holdt fra hverandre, fordi de er ulike rettigheter: psykoterapeutti er en beskyttet tittel i Finland og et fritt ord i Norge
• Terhikki-nummer, datoen for arbeidsgiverens sjekk, og om det var et registeroppslag eller vedtaksdokumentet; et skrevet nummer regnes som oppgitt, ikke sjekket
• En tjenesteenhet med sin egen registrering, og vastuuhenkilö som en utpeking per enhet, så en fjortendag uten noen ansvarlig blir rapportert
• Den offentlige egenkontrollplanen og den fortrolige sikkerhetsplanen holdt fra hverandre av konstruksjon: én policyregistrering kan ikke flagges som begge
• Asiakastietolaki § 11: to år med logginformasjon med mottakeren og grunnlaget, en skriftlig forespørsel med en tomånedersklokke, og en tilbakeholdelse notert med grunnen sin
• Potilaslaki § 9(2) har ingen alder, så en mindreårig er en notert vurdering: uten en nektes en utlevering til en verge, og avslaget sier at vurderingen mangler
• Tolv år etter død, og der dødsfallet ikke er kjent, 120 år fra fødselen

Sveits skiller kvalifikasjonen fra tillatelsen til å praktisere, teller forsikrede timer mot en legehenvisning, og binder leverandøren til samme straffbare taushetsplikt som behandleren. Tre ting kjernen ikke kan uttrykke, og ingenting mer.

• Den føderale tittelen er ikke tillatelsen: praksistillatelsen er kantonal, én per kanton, hver med sin egen utløpsdato — en behandler kan altså bære navnet i Sveits og ha rett til å arbeide på bare ett sted
• En profil med beskyttet tittel publiseres ikke uten både et kontrollert PsyReg-nummer og en gjeldende, kontrollert kantonal tillatelse — og avslaget sier hvilken av de to som mangler
• Der en tittel er kontrollert og ingen tillatelse er det, sier den offentlige statusen det i stedet for å antyde én; et ukontrollert marked er ikke tjent med en oppføring som leses som en kontrollert
• Anordnungsmodell: femten timer på legehenvisning, fornybare én gang til tretti, og forsikringsselskapet utover det — tellet gjennom kjeden av fornyelser, varslet før den timen som ikke ville blitt betalt, og avslått ved den andre fornyelsen uten en godkjenning i saken
• Bare en gjennomført time teller; en booket gjør det ikke, for å telle den ville stanse en henvisning to timer for tidlig
• Artikkel 321 binder hjelpepersoner til samme straffbare plikt som behandleren, så registeret stiller det ene spørsmålet artikkelen henger på: kan de lese dataene i klartekst?
• Ti år etter siste kontakt, sådd på den oppbevaringsklokken dokumenttjenesten allerede hadde — ingen andre måte å si det samme på
• Kantonene hver behandler har tillatelse i, avgjør hvilket språk myndighetene deres korresponderer på, vist på behandleren og på hver tillatelse
• Forsikret fakturering har formen sin her og ingen av katalogene sine: en tariffutgave, posisjoner i taksetpoeng, poengverdier per kanton og forsikringsklasse. Posisjonene og poengverdiene er lisensierte data en installasjon leser inn, for en troverdig oppdiktet kode er en kode noen fakturerer på
• En time som ikke kan prises, sier hvilken kanton som mangler innlest poengverdi, og viser ingen beløp i det hele tatt — null franc ville betydd at timen ikke koster noe, som er en annen påstand
• Tysk, fransk og italiensk gjennom hele grensesnittet, i sveitsiske termer: en Berufsausübungsbewilligung heller enn en oversatt «kantonal lisens», og en Hilfsperson heller enn en «hjelpekraft»

En fast liste spørsmål stilt til oppsettet selv. Det meste av sjekkingen fantes alt og lå spredt; dette er siden som leser den på ett sted.

• Et register over sjekker, en kjører på en plan, og en rapport over begge
• Bare det som er galt, rapporteres: en sjekk som går bra, sier ingenting, så siden er tom når oppsettet er sunt
• Hvert funn navngir regelen det kom fra og registreringen det ble funnet på
• Kjøringer bevares, så et funn som stadig kommer tilbake, er synlig som et mønster heller enn som nyhet

Signaturtjenesten selv: en signeringsseremoni i portalen, jurisdiksjonsregler, og et hashlenket revisjonsspor. Selvdriftet, så ingen dokumenter forlater huset for å bli signert.

• En signeringsseremoni i portalen med identitet og hensikt fanget i signeringsøyeblikket
• Et hashlenket revisjonsspor ingen kan redigere eller slette
• Jurisdiksjonsregler som styrer hva en gyldig signatur krever
• Signaturforespørsler som registreringer, med sin egen status og historikk

Hvem som hadde fullmakt til å signere for en motpart, og om legitimasjonen deres fortsatt er gyldig — sjekket heller enn antatt.

• Fullmakt til å binde fulgt per signatar hos motparten
• Signerte avtaler bevart som registreringer med en varighet
• Utøverlegitimasjon fulgt opp før den går ut

Hva en klinisk signatur trenger utover et navn: samtykkekompetanse, fullmakt til å signere på noens vegne, veiledning, og samtykke som kan trekkes tilbake.

• Bekreftelse av samtykkekompetanse notert ved signeringen
• Å signere på en klients vegne, med fullmakten notert
• Medsignatur fra veileder der tjenesten krever det
• Et samtykkeforløp som kan trekkes tilbake heller enn en engangsavkrysning

Elementene HIPAA krever av en fullmakt, validert heller enn overlatt til en mal.

• Validering av de påkrevde elementene i en HIPAA-fullmakt
• 42 CFR Part 2-materiale skilt fra resten
• Oversikten over utleveringer en dekket virksomhet må lage på forespørsel

En Be om signatur-handling på søkere og ansatte, så et tilbud eller en policy signeres der personen alt er.

• Be om signatur på en søkerregistrering
• Be om signatur på en ansattregistrering
• Forespørsler bevart mot registreringen som dens historikk

En Be om signatur-handling på tilbud og innkjøpsordrer.

• Be om signatur på en salgsordre
• Be om signatur på en innkjøpsordre
• Det signerte dokumentet bevart mot ordren

Setter signaturmaler der klinikken selger: festet til en behandler eller en tjeneste, sendt automatisk ved kjøp, og synlig som en status.

• E-signaturmaler festet til en behandler eller til en tjeneste
• Sendt ved kjøp, uten at noen må huske å sende den
• Signeringsstatus vist til behandlere i portalen og i mobilappen

Avslutter en sesjon ingen bruker. 45 CFR 164.312(a)(2)(iii) ber om avslutning etter en forhåndsbestemt periode uten aktivitet, og lar perioden være opp til deg — så det er en innstilling, med håndhevingen på serveren heller enn i nettleseren.

• Periode uten aktivitet, varselperiode og et absolutt tak, satt per selskap
• Sjekket på serveren ved hver autentisert forespørsel, så å slå av nettlesertimeren gir ingenting
• Et varsel før sesjonen avsluttes, så ingen mister et halvskrevet notat til en kontroll som skal beskytte dem
• Et absolutt tak så vel som et for inaktivitet, fordi en sesjon holdt levende av et skript, fortsatt er en sesjon som burde avsluttes
• Hver avslutning notert — hvem, hvilken flate, og hvilken regel som avsluttet den
• Registreringen legges bare til: bevis for at en kontroll virket, er verdt det det koster å endre det
• Sett perioden til null for å slå den av, som er en avgjørelse spesifikasjonen tillater og risikoanalysen din noterer

Kobler Odoo Community til enhver stor språkmodell, bak et grensesnitt — så leverandøren kan skifte uten at forretningslogikken vet det.

• Leverandører satt opp per oppsett, med nøkkelen holdt utenfor programkoden
• Agenter definert som ledetekster med verktøyene de får kalle
• Verktøykall, så en modell kan handle heller enn bare svare
• Kjøringer notert, så hva som ble spurt om og hva som kom tilbake, er til å granske etterpå
• Serverhandlinger som kan drives fra en ledetekst
• Diagnostikk for å sjekke at en leverandør er å nå og satt opp riktig

Å gjøre en bruker om mellom intern og portal for hånd betyr å redigere rettigheter i rett rekkefølge og huske bivirkningene. Dette gjør det til en knapp.

• Et Brukertype-felt på brukerskjemaet, listen og søkefiltrene
• Knappene Gjør til intern og Gjør til portal på brukerskjemaet
• En Endre brukertype-handling på brukerlisten, for flere brukere om gangen
• Sikringer: systembrukeren, din egen bruker og den siste administratoren kan aldri endres ved uhell

Topptekst, bunntekst og innloggingssiden på én utforming, oppkalt etter selskapet i denne databasen.

• Én utforming for toppteksten, bunnteksten og innloggingssiden
• Navnet som vises, er selskapet i denne databasen, ikke en verdi skrevet inn i en mal
• Logoens adresse og en egen opphavsrettslinje er systemparametere, også redigerbare under Innstillinger → Nettsted → Offentlig merke
• Lenkene i toppteksten kommer fra hovedmenyen til dette nettstedet, og redigeres altså der hver annen meny redigeres

Selskaper, brukere, grupper, kontakter, språk og registerreglene som avgjør hvem som ser hva. Vises ikke i applisten fordi alt avhenger av den.

• Selskaper og avgrensning på flere selskaper
• Brukere, grupper og tilgangsregler på registernivå
• Kontakter som én modell delt av klienter, behandlere og leverandører
• Språk, oversettelser og eget språkvalg per bruker
• Planlagte handlinger — jobbkøen bak hver nattlige oppgave

Grensesnittet i backoffice de ansatte arbeider i, og redigeringsverktøyene bak hvert rikt tekstfelt og hver nettstedsblokk.

• Liste-, skjema-, kanban-, kalender-, pivot- og diagramvisninger
• Filtre, grupperinger og lagrede søk på hver skjerm
• Eksport til CSV og XLSX fra hvilken som helst liste
• HTML Editor — det rike tekstfeltet som brukes på tvers av registreringer
• HTML Builder — blokkeditoren med dra og slipp
• Web Routing — URL-laget hver portal- og nettstedsside leveres gjennom

Odoo-programWebWeb RoutingHTML EditorHTML Builder

Meldinger, og meldingstråden knyttet til hver registrering — som er hvordan en avgjørelse beholder historikken sin istedenfor å bo i noens innboks.

• Meldingstråden på hver registrering: meldinger, notater, følgere og sporede feltendringer
• Interne kanaler og direktemeldinger
• Utgående e-post med maler, og ruting inn
• Aktiviteter — en oppgave tildelt mot en registrering heller enn til noens hukommelse
• OdooBot, og HR-varianten for spørsmål ved oppstart

Odoo-programDiscussOdooBotOdooBot - HR

Det påloggede området en klient, en behandler eller en motpart når uten å være en intern bruker — alt under /my.

• Portalbrukere uten tilgang til backoffice
• Dokumenter, ordrer og fakturaer delt med den de hører til
• Rammen hver egen portalside i denne plattformen er bygget inne i
• En tilpasset registreringsside, så registrering passer merkevaren heller enn Odoos standard

Odoo-programCustomer PortalCustomize Signup Page

Adresseboksprogrammet: personer, virksomheter, og forholdene mellom dem.

• Personer og selskaper, med underkontakter
• Adresser, organisasjonsnummer og bankopplysninger
• Merkelapper og kategorier brukt til segmentering
• Registreringen en klient, en behandler og en leverandør alle løses til

Odoo-programContacts

Hva som selges. I en klinikk er det timer og pakker, men modellen under er den vanlige.

• Produktmaler og varianter
• Måleenheter, og tjenesteprodukter for tid
• Prislister, så en pakke eller et segment kan prises ulikt
• Produktkategorier brukt til rapportering per tjenestelinje

Arbeidskalendere, kapasitet og fravær — modellen en behandlers timer per uke og daterte unntak uttrykkes i.

• Arbeidsplaner per person, med tidssoner
• Ressurskapasitet og fravær
• Kalenderen utnyttelsen beregnes mot

Odoo-programResource

De små installerte modulene ingen åpner med vilje, og som hver fjerner en bestemt kategori supportsaker.

• Onboarding Toolbox — veiledet framgang i oppsettet av et nytt miljø
• Phone Numbers Validation — numre normalisert ved inntasting, så SMS faktisk kommer fram
• Google reCAPTCHA — spambeskyttelse på offentlige skjemaer
• Google Gmail — utgående post gjennom en Google-konto uten et SMTP-passord

Odoo-programOnboarding ToolboxPhone Numbers ValidationGoogle reCAPTCHA integrationGoogle Gmail

Tilbud og salgsordrer — registreringen hver kjøpt time henger av, og enden lengst til venstre i betalingskjeden.

• Tilbud, bekreftelse og salgsordrer
• Ordrelinjer som bærer timene eller pakkene som ble kjøpt
• Leverings- og faktureringsstatus per linje
• Tilbudsmaler, for en pakke som selges gjentatte ganger
• Salgsteam og rapporteringen som følger dem
• Ordren et klipp, en faktura og en betaling alle spores tilbake til

Odoo-programSales

Hovedboken. Fakturaer, regninger, betalinger, avgifter og avstemming — der klinikkens bøker faktisk bor.

• Kundefakturaer og kreditnotaer, med utstedte fakturaer uforanderlige
• Leverandørregninger — også de en utbetaling lager for behandlere
• Betalinger, bankutdrag og avstemming
• Avgifter, avgiftsposisjoner og kontoplanen
• Journaler, journalposteringer og revisjonssporet bak dem
• Balanse, resultat, aldret kundefordring og aldret leverandørgjeld

Odoo-programInvoicing

Kostnad og inntekt tilskrevet noe annet enn en konto — et prosjekt, en tjenestelinje, en behandler.

• Analytiske kontoer og fordelinger
• Kostnad og inntekt fulgt per prosjekt eller per tjenestelinje
• Dimensjonen marginrapportering beregnes på tvers av

Rammeverket betalingsmåter kobles inn i, så å legge til eller endre en leverandør er oppsett heller enn utvikling.

• Betalingsleverandører satt opp per selskap
• Betalingspoletter, for et lagret kort en klient bruker om igjen
• Transaksjoner med sin egen tilstand, avstemt mot fakturaer
• Sømmen gatewayens PAYMENTS-bryter sitter bak

Tre leverandører er slått på: en aktiv kortbehandler, en demo til opplæring, og manuelle måter for penger som kommer utenom en gateway.

• Stripe — kort, lommebøker og lagrede betalingsmåter
• Demo — en leverandør som oppfører seg som en virkelig, til opplæring og øving
• Custom Payment Modes — bankoverføring, kontanter og alt som avstemmes for hånd
• Sytten flere leverandører leveres med Odoo og er én bryter unna

Odoo-programPayment Provider: StripePayment Provider: DemoPayment Provider: Custom Payment Modes

Rabatter, kampanjer, gavekort og lojalitetsprogram — brukt på en salgsordre og i nettbutikkens kasse likt.

• Kupongkoder og automatiske kampanjer
• Lojalitetskort og opptjening av poeng
• Gavekort, og saldo i e-lommebok
• Programregler etter produkt, tjenestelinje eller kundesegment

Odoo-programCoupons & LoyaltySale LoyaltySale Loyalty - Delivery

Hva de ansatte bruker, og den delen av det som faktureres videre til en klient heller enn å bæres selv.

• Utgiftskrav, godkjenning og refusjon
• Utgifter postert rett i regnskapet
• Å fakturere en utgift videre ved å sette salgsordren på den
• Kostnadssiden av et levert oppdrag

Odoo-programExpensesSales Expense

Innkjøpsordrer og leverandørstyring — siden med bundet kostnad, og hvordan leverandørregninger kommer inn.

• Forespørsler om tilbud og innkjøpsordrer
• Leverandørregistreringer og prislister
• Leverandørregninger matchet mot ordrer
• Ordren en signatur kan bes om på

Odoo-programPurchase

Leads og salgsmuligheter — brukt her for henvendelser som ennå ikke er klienter, og for forespørslene om rådgivende prat som kommer fra appen.

• Leads, salgsmuligheter og en tilpassbar trakt
• Aktiviteter og neste handlinger mot hver salgsmulighet
• Tapsgrunner og rapportering av vinnerrate
• Modellen sikre dokumenter kan arkiveres mot til en pakke for aktsomhetsvurdering

Odoo-programCRM

Å fylle inn hva et lead ikke fortalte deg, å finne leads som aldri tok kontakt, og å gi et salgsteam noe å konkurrere om.

• Lead Enrichment — selskapsopplysninger fullført automatisk fra et e-postdomene
• Lead Generation — leads hentet etter bransje, størrelse og sted
• CRM Gamification — mål, merker og resultatlister på trakten

Odoo-programLead EnrichmentLead GenerationCRM Gamification

En samtalewidget på det offentlige nettstedet, bemannet av virkelige folk, og koblet både til trakten og til HR-hjelpen.

• Live Chat — operatører, kanaler og ferdige svar
• Website Live Chat — widgeten på det offentlige nettstedet og i katalogen
• CRM Livechat — en samtale gjort om til et lead uten å taste noe på nytt
• HR - Livechat — samme kanal brukt internt til spørsmål fra ansatte
• Utskrifter bevart mot den besøkende og, når de er kjent, mot kontakten

Odoo-programLive ChatWebsite Live ChatCRM LivechatHR - Livechat

Kanalen med høyest åpningsrate, koblet inn der en klinikk faktisk trenger den. Timepåminnelser bruker den alt.

• SMS-gateway — sendeinfrastrukturen og leveringsstatus
• SMS i CRM — å sende melding til et lead fra salgsmuligheten
• Send SMS to Visitor — og varianten som virker fra et lead
• Recruitment - SMS — å sende melding til en søker om et intervju
• Sperring per person, så en avmelding etterleves overalt

Odoo-programSMS gatewaySMS in CRMSend SMS to VisitorSend SMS to Visitor with leadsRecruitment - SMS

En egen utvidelse på leads og kontakter: send en forhåndsdefinert WhatsApp-melding uten å forlate registreringen.

• Hurtigsending som handling på et lead og på en kontakt
• Forhåndsdefinerte meldingsmaler
• Kanalen mange klienter i dette markedet faktisk leser

Odoo-programCRM Extension v2 - WhatsApp Quick Send

Jevnlige tall sendt til dem som bør se dem, og attribusjon for hver lenke virksomheten publiserer.

• KPI Digests — et planlagt sammendrag sendt på e-post til ledere
• Link Tracker — korte lenker med UTM-merking og klikkstatistikk
• Kampanje, medium og kilde notert mot den besøkende som konverterte

Odoo-programKPI DigestsLink Tracker

Sidebyggeren bak det offentlige nettstedet — sidene markedsføringen redigerer uten en utvikler.

• Sider med dra og slipp og blokker som kan brukes om igjen
• Flerspråklige sider og SEO-metadata
• Menyer, temaer og sideversjonering
• Den offentlige katalogen og profilsidene til behandlerne

Odoo-programWebsite

Å selge på det offentlige nettstedet: katalogen, handlekurven og kassen en klient går gjennom før de noen gang holder et klipp.

• Offentlig produktkatalog og produktsider
• Handlekurv, kasse og betaling på nettstedet
• Kundekontoer og ordrehistorikk
• Portene i handlekurven som stopper et kjøp som ikke kan bestilles

Odoo-programeCommerce

Publiseringssiden: artiklene som kommer i appens innholdsstrøm og på det offentlige nettstedet.

• Blogger, innlegg, merkelapper og kommentarer
• Flerspråklige innlegg
• Kilden den rangerte innholdsstrømmen leser fra

Odoo-programBlog

De tre stedene en besøkende kan lage en registrering uten en konto — hver av dem lander et sted et menneske faktisk arbeider.

• Contact Form — en henvendelse som kommer som et lead, ikke som en e-post
• Online Task Submission — et nettstedsskjema som lager en prosjektoppgave
• Online Jobs — stillinger publisert, og søknader som kommer inn i Recruitment

Odoo-programContact FormOnline Task SubmissionOnline Jobs

Tre små moduler som kobler det offentlige nettstedet til resten av systemet. Ingen åpner dem; alt går i stå uten dem.

• Website Mail — abonnement og meldingstråder på offentlige sider
• Website Partner — en offentlig side for en kontakt, som er hva en behandlerprofil er
• Website Payment — betaling på nettstedet koblet til betalingsrammeverket

Odoo-programWebsite MailWebsite PartnerWebsite Payment

Ansattregistreringer og avtaler. I Odoo 19 er en avtale en versjon av den ansatte, og den versjonstidslinjen er det som bærer en behandlers lønnsbetingelser.

• Ansattregistreringer, avdelinger og stillinger
• Avtaleversjoner med en datert historikk, én gjeldende om gangen
• Arbeidsplan per ansatt
• Registreringen behandlerlønn og utbetalinger er bygget på

Odoo-programEmployees

Hva hver behandler er kvalifisert til, når den kvalifikasjonen går ut, og hvem som rapporterer til hvem.

• Skills Management — kompetanse, nivåer og utvikling per ansatt
• Skills Certification — sertifikater med utløp, som er det som gjør en kvalifikasjon mulig å følge opp
• HR Org Chart — rapporteringslinjer på ansattregistreringen
• HR Gamification — interne mål og merker

Odoo-programSkills ManagementSkills CertificationHR Org ChartHR Gamification

Søkere og ansettelser — og grunnen til at et tilbud er ett av dokumentene e-signaturstakken blir bedt om å håndtere.

• Stillinger, søkere og en ansettelsestrakt
• Intervjuplanlegging og vurderingsskjemaer
• Kompetanse matchet mot kravene i rollen
• Søkerregistreringen en signatur kan bes om fra

Odoo-programRecruitmentRecruitment - Skills Management

Hvor hver person arbeider fra en gitt dag — som for en klinikk betyr å vite hvem som er på stedet for å ta imot en klient.

• Hjemme- og kontordager per ansatt
• Samme opplysning vist på teamkalenderen
• Synlig ved siden av romkalenderen når timer på stedet planlegges

Odoo-programRemote WorkRemote Work with calendar

Prosjekter og oppgaver. Brukt til leveringsarbeid og, i avtalevertikalen, til å holde kostnaden av å vinne en avtale fra kostnaden av å levere under den.

• Prosjekter, oppgaver og trinn
• Tildeling, frister og framgang
• Dokumentarkivering på oppgavenivå, også sikre dokumenter
• Prosjektet avtalekostnad og margin rapporteres mot

Odoo-programProject

En personlig oppgaveliste per bruker, atskilt fra prosjektarbeid — der de små tingene en leder plukker opp under morgenrutinen, havner.

• Private huskepunkter med forfallsdatoer
• Til å gjøre om til en prosjektoppgave når det viser seg å være virkelig arbeid

Odoo-programTo-Do

Møter og hendelser. Hver time er en kalenderhendelse under, som er det som gjør rom- og teamkalendere virkelige heller enn en gjengivelse.

• Hendelser med deltakere, gjentakelse og påminnelser
• Ledig tid synlig på tvers av et team
• Synkronisering med eksterne kalendere
• Hendelsen en bestilt time er knyttet til

Odoo-programCalendar

Spørreskjemaer. Brukt her til kartleggingsspørsmål stilt ved bestilling og til den private tilbakemeldingen etter en time.

• Spørreskjemaer med betingede spørsmål
• Svar lagret mot den som svarte
• Skåring, der et spørreskjema er en kartlegging
• Kartleggingsspørsmålene knyttet til en tjeneste som kan bestilles

Odoo-programSurveys

Tid notert mot et prosjekt eller en oppgave. Tilgjengelig og slått av i referansemiljøet — det er en avhengighet av avtalevertikalen heller enn av klinikkarbeid.

• Tidsposter mot prosjekter og oppgaver
• Kostnad per time fra ansattregistreringen
• Godkjenning og rapportering av timelister
• Timene avtalefakturering gjør om til tall for dekning og utnyttelse

En kursvirksomhet: arrangementer med eller uten betaling, nettkurs, og et offentlig forum — alt solgt gjennom samme handlekurv og rapportert inn i samme bøker.

• Arrangementer med påmelding, billetter, spor og utstillere
• Arrangementer solgt som produkter gjennom kassen som finnes
• Direktespor og quizer for økter på nett
• Nettkurs, med kompetanse opptjent ved fullføring
• Et offentlig forum, og arrangementer koblet inn i CRM-trakten

Odoo-programEventsEvents OrganizationEvents ProductEvents SalesEvent CRMEvent CRM SaleEvent ExhibitorsLive Event TracksQuizzes on TracksSMS on EventsEvent Attendees SMS MarketingTrack Speakers SMS MarketingWebsite Events CRMeLearningSkills e-learningForum

Kampanjer til lister virksomheten alt har. Klinikken sender transaksjonell e-post og SMS i dag; dette er markedsføringshalvdelen av samme infrastruktur.

• Email Marketing — kampanjer, maler, A/B-testing og statistikk
• SMS Marketing — det samme, på kanalen med høyest åpningsrate
• Massesending rettet mot leads, salgsmuligheter, deltakere eller foredragsholdere
• Marketing Card — personlige delingsbilder til en kampanje
• Knapper for å melde seg på nyhetsbrev på nettstedet, på e-post eller SMS

Odoo-programEmail MarketingSMS MarketingMass mailing on attendeesMass mailing on lead / opportunitiesMass mailing on track speakersMass mailing sms on lead / opportunitiesMarketing CardNewsletter Subscribe ButtonNewsletter Subscribe SMS Template

For en klinikk som også selger noe fysisk over en disk — bøker, kosttilskudd, testsett — eller driver en kasse i resepsjonen.

• Inventory — lager, plasseringer, etterfylling og verdsetting
• Point of Sale — en kasse som virker uten nett og synkroniserer
• Rabatter i kassepunktet, og lojalitetsprogrammene som alt er satt opp

Odoo-programInventoryPoint of SalePoint of Sale - Coupons & LoyaltyPoint of Sale Discounts

Personaladministrasjonssiden. Relevant når en klinikk har nok ansatte at fravær og tilstedeværelse slutter å passe i en delt kalender.

• Time Off — søknader, godkjenning, saldoer, og virkningen på lønnsslipper
• Attendances — inn- og utstempling, med tilstedeværelseskontroll
• Oppmøterapportering ved siden av timelister
• Timelønn for ansatte, til å kostnadsberegne leverte timer
• Bilpark og bilparkhistorikk, der kjøretøy stilles til rådighet
• Lunch — kantinebestillingsappen

Odoo-programTime OffTime Off in PayslipsAttendancesTimesheets/attendances reportingEmployee Presence ControlHR Attendance HolidaysEmployee Hourly WageFleetFleet HistoryLunch

Stripe er slått på. Hvilken som helst av disse kan legges til eller byttes inn som oppsett — som er det som gjør å gå inn i et nytt marked til en innstillingsendring heller enn et prosjekt.

• Europa — Mollie, Buckaroo, Worldline, Redsys, Adyen
• Amerika — Authorize.Net, Mercado Pago, PayPal, Nuvei
• Midtøsten og Afrika — Amazon Payment Services, Paymob, DPO, Flutterwave
• Asia — AsiaPay, Razorpay, Xendit
• Tyrkia — Iyzico

Odoo-programPayment Provider: AdyenPayment Provider: Amazon Payment ServicesPayment Provider: AsiaPayPayment Provider: Authorize.NetPayment Provider: BuckarooPayment Provider: DPOPayment Provider: FlutterwavePayment Provider: IyzicoPayment Provider: Mercado PagoPayment Provider: MolliePayment Provider: NuveiPayment Provider: PaymobPayment Provider: PaypalPayment Provider: RazorpayPayment Provider: RedsysPayment Provider: WorldlinePayment Provider: Xendit

Valgfrie eksterne tjenester. Alle er av som standard, og det er med vilje: hver av dem sender noe ut av huset, og det bør være en avgjørelse heller enn en standard.

• Google Calendar — toveis synkronisering for ansattes kalendere
• Google Maps og stedsutfylling på nettstedet
• Google Address Autocomplete på kontaktskjemaer
• Google Users — pålogging med en Google-arbeidskonto
• Skylagring på Azure eller Google, for vedlegg i stor skala

Odoo-programGoogle CalendarGoogle MapsGoogle places autocompletionGoogle Address AutocompleteGoogle UsersCloud StorageCloud Storage AzureCloud Storage Google

Løst og fast som hver løser ett smalt problem. Listet for fullstendighetens skyld heller enn fordi en klinikk trenger dem på dag én.

• Posttillegg for Outlook og Gmail, på CRM og på Project
• Mail Group — en diskusjon i stil med en e-postliste, med et arkiv på nettstedet
• Data Recycle — finner dupliserte og foreldede registreringer
• Website profile — en offentlig side for en portalbruker
• Intervjuskjemaer i rekruttering, og marginrapportering for utgifter i salg
• En telefoniintegrasjon i CRM (Issabel)

Odoo-programMail PluginCRM Mail PluginProject Mail PluginMail GroupWebsite Mail GroupData RecycleWebsite profileHr Recruitment Interview FormsSales Expense MarginCRM Issabel Integration

Avtalen, partene, de strukturerte vilkårene med opphav, versjonene, og et forløp av tilpassbare trinn lagt mot fem faste faser.

• Avtaler med parter, strukturerte vilkår og vilkårsopphav
• Versjoner, så «hva sto det i mars?» blir til å svare på
• Tilpassbare trinn lagt mot fem faste faser
• Ingen bransjesjargong og ingen avhengighet av e-signatur, kryptert lagring eller prosjekter
• Bransjer kommer som pakker med oppsett heller enn som forgreininger av koden

Bygget slik at gjennomgangen rettes mot hva som er endret og hva som avviker, og aldri mot uendret standardtekst — som er der avtalesystemer vanligvis forlates.

• Et klausulbibliotek knyttet til strukturerte vilkår, så å godta en reserveløsning setter vilkåret den bærer
• Spilleplaner, runder, saker og noterte avvik
• Møter som forhandlingsrunder i seg selv, som bevarer resonnementet og posisjonene
• Et møteutfall lager foreslåtte endringer og endrer aldri avtalen av seg selv
• En logg som knytter hvert trinn fra forespørsel til gjennomføring sammen, med hvert hull synlig

Godkjenning avgjort på mer enn én akse. Å behandle det som ansiennitet alene er den vanlige designfeilen: en standard taushetserklæring trenger ingen på toppen, uansett verdi.

• Godkjenning på verdi, avvik, avtaletype og risiko
• Avvik som en akse i seg selv heller enn en justering av verdi
• Godkjenning av en stedfortreder alltid notert som det — «på vegne av» er et annet faktum
• Virker på Odoo Community, der Approvals-appen ikke er tilgjengelig

Noterer hva en endring endret, ikke bare at den finnes.

• Å gjennomføre en endring lukker vilkårsradene den endrer og åpner nye på virkningsdatoen
• Alt som er utledet av et endret vilkår, beregnes på nytt, og bevegelsen vises før gjennomføringen
• Motstridende endringer oppdaget ved gjennomføringen
• En avkall som faller bort, gjenoppliver vilkåret som gjaldt ved bortfallet, ikke det opprinnelige

Signatur er begynnelsen på plikten, ikke slutten på et arbeidsforløp. Dette bærer det som skjer etterpå.

• Plikter i begge retninger, med dokumentasjon der dokumentasjon kreves
• Utledede datoer beregnet fra vilkår heller enn skrevet, og flyttet når vilkårene som driver dem, flytter seg
• En eskaleringstrapp som ikke hviler på å minne den som alt ikke har handlet
• Fornyelsesavgjørelsen lagt fram med de pliktene motparten ikke har oppfylt

To kostnader, holdt fra hverandre: hva en avtale kostet å vinne, og hva den koster å levere. Å slå dem sammen gir et tall som ikke svarer på noen av spørsmålene.

• Forhandlingsinnsats notert som overhead, enten avtalen signeres eller ikke
• Leveringskostnad dekket mot avtaleverdien
• Avtaler knyttet til prosjekter mange-til-mange med en rolle, fordi ett prosjektfelt brekker på den første rammeavtalen
• En signert leverandøravtale er bundet kostnad fra gjennomføringen, ikke fra den første fakturaen

Hva en time er verdt, hva honoraret tillater, og de fire tallene som trenger begge.

• Timesatser, et fakturerbart flagg og en fakturert tilstand på notert tid
• Honorargrunnlag oppgitt på avtalen
• Dekning — fakturert mot verdien av tiden som er notert
• Utnyttelse — fakturerbare timer mot tilgjengelige timer, fra personens egen arbeidskalender
• Bundet kapital — ufakturert arbeid pluss uinnkrevde regninger, og hvor mange dagers fakturering det er
• Et varsel om honorartak drevet av framskrevet kostnad, fordi et som utløses på taket, utløses for sent

Den fjerde utvekslingskanalen: motparten leser den gjeldende versjonen her, kommenterer, og laster opp sine endringer som en runde inn.

• Motparten åpner den gjeldende versjonen, kommenterer den og sender tilbake sine endringer
• Endringene kommer som en runde inn med filen vedlagt, ikke som en e-post noen må huske å arkivere
• Ingenting internt er synlig — ikke posisjoner, avvik, godkjenninger, spilleplanen eller interne notater
• Valgfritt, fordi et design som antar at motparten vil bruke vår portal, feiler på den første store kunden

Hvordan en avtale bruker signaturtjenesten. Fullføringen er hendelsen som starter alt annet.

• Godkjenninger må være fullført før en versjon kan sendes
• Signatarens fullmakt til å binde sjekket mot legitimasjonen deres
• Versjonen låst når den går ut, så hver senere påstand om hva som ble signert, er til å bevise
• Ved fullføring gjennomføres versjonen, avtalen flytter seg, vilkår trer i kraft og utledede datoer følger
• Å avinstallere etterlater et system som virker — papirsignaturer noteres med en metode og ser fullstendige ut

Å kryptere hver avtale gjør systemet ubrukelig; å kryptere ingen gjør det utrygt. Så fortrolighet er et nivå på avtalen.

• Bare avtaler merket som sikre ruter dokumentene sine inn i tjenesten for sikre dokumenter
• Kryptering per versjon under en nøkkel holdt utenfor databasen
• Tilgang nektet som standard, og hvert oppslag loggført før innhold gis
• Sletting ved å ødelegge nøkkelen
• Sier ved endringen at å oppgradere til sikker ikke gjør ugjort at noe ble lagret ukryptert

Flagglister som bør være tomme, og ledelsesvisningene det er verdt å diskutere.

• En flaggliste holder bare det som ikke stemmer — en tom liste er det gode utfallet
• Et flagg hvis modell ikke er installert, rapporteres som ikke aktuelt heller enn å feile
• Ubegrenset ansvar vist som en liste, aldri som et tall lagt inn i en sum
• Syklustid delt etter side, fordi dager motparten holdt utkastet, ikke er avtaleteamets prestasjon
• Avhenger bare av kjernen, og å fjerne den etterlater et system som virker

Tre lesere, én regning. De samme tallene beregnet én gang og gjengitt tre måter, heller enn utledet på nytt per skjerm, der de ville glidd fra hverandre.

• Én fristvisning: utledede avtaledatoer, plikter begge veier, handlinger avtalt i møter og leveringsfrister
• Prosjektkontroll: inntekt, arbeid, bundet kostnad, margin og avvik mot estimat, som en lagret visning så den kan grupperes
• En visning mot klienten av hvor arbeidet har kommet og hva som skyldes
• En visning mot advokaten av hva som ligger på dem denne uken og om de er innenfor estimatet

To regler, og bare to — de som sammenligner registreringer og derfor ikke kan uttrykkes som oppsett.

• En underlisens sitt område må ligge innenfor morlisensens
• To eksklusive lisenser må ikke overlappe
• Holdt atskilt fra IP-pakken, så en virksomhet kan installere avtaletypene uten sjekkene
• Størrelsen er et bevisst mål på hvor godt grunnlagets utvidelsespunkter virker

Konfliktsjekk ved avtaleinntak, på samme måte som ved åpning av en sak. Den sperrer trinnovergangen; den varsler ikke.

• En motpart sjekket mot eksisterende klienter, motparter i løpende saker, og kjente tilknyttede selskaper
• Sperrer trinnovergangen heller enn å heve et varsel som kan avvises
• Selve sjekken uforanderlig når den er notert — hvem som kjørte den, over hvilket omfang, og hva de fant

Startpakken. Installer kjernen og denne, og en virksomhet kan drive avtaler på dag én uten å sette opp noe.

• Taushetserklæringer, rammeavtaler, arbeidsbeskrivelser, tjenester, rådgivning, leveranse og innkjøp
• Vilkårene hver type bærer og forløpet den går gjennom
• Porter som stopper en avtale fra å nå signatur halvferdig
• Ingen Python — og spesialiserte pakker avhenger av denne heller enn å erklære på nytt hva alle trenger

Ansettelse, oppdragsengasjement, rådgivning og sluttavtaler.

• Avtaletyper, vilkårstyper, klausulbibliotek og spilleplan for ansettelsesavtaler
• Pliktmaler for oppsigelsestid, prøvetid og vilkår etter opphør
• Sluttavtaler er sikre som standard — hvert ord betyr noe, og et tilsyn spør om dem senere
• Bare data, og ingen regelmodul

Advokatfirmaer — avtaler for klienter og med dem — og interne juridiske avdelinger. Samme system tjener begge jobbene med skarpt ulike standarder.

• Oppdragsbrev, løpende oppdrag og instrukser til prosessfullmektig
• Et klausulbibliotek med den regulerte ordlyden merket som obligatorisk
• Et firmas oppdragsbrev er fortrolig og oppdelt som standard
• Avtaler om betingede honorarer bærer ordlyd som ikke kan fjernes
• Konfliktsjekk bor i contract_legal_rules, fordi den sammenligner parter på tvers av saker

Lisensgivere, patent- og varemerkeinnehavere, kontorer for teknologioverføring, universiteter og merkevareeiere.

• Lisenser, overdragelser og opsjoner som avtaletyper, med lisensvilkårstyper
• Klausulbibliotek, spilleplan og pliktmaler
• Ingen eiendelsregister, med vilje — et patents saksbehandlingshistorikk hører til porteføljesystemet som alt har den
• De to reglene en pakke ikke kan uttrykke, bor i den valgfrie contract_ip_rules

Leieavtaler, avtaler om leie, bruksrett, salg, servitutter og dokumentene som henger av en leieavtale.

• Oppsigelsesdatoer som vilkår som driver datoer, fordi en oppsigelsesrett går ut i stillhet
• Varslingsvinduet som en plikt utledet av oppsigelsesdatoen, og begge eskalerer
• Vilkår om leiejustering, felleskostnader og tilbakestilling
• Bare data, og ingen regelmodul

Gjeldsdokumenter: låneavtaler, garantier, sikkerhet, avtaler mellom kreditorer og etterstillelse.

• Finansielle vilkår som strukturerte vilkår, med utledede testdatoer
• Etterlevelseserklæringen som en plikt med dokumentasjon påkrevd
• «Hvilke lån testes dette kvartalet, og på hvilke tall?» blir et spørsmål med et svar
• Den dokumenterer gjeld; den bokfører den ikke — saldoer og påløpte poster blir i regnskapet
• Bare data, og ingen regelmodul

Hovedkontrakter, underkontrakter, rådgiveroppdrag, tilleggsgarantier og instrumentene rundt dem.

• Bygget rundt kjeden: en hovedkontrakt lover en dato bare underkontraktene kan levere
• Speilede vilkår holdt som strukturerte vilkår så de kan sammenlignes nedover kjeden
• Ansvar underkontraktene og rådgiveransvarsforsikringen må bære
• Bare data, og ingen regelmodul

Databehandleravtaler, business associate-avtaler og vilkår for underleverandører.

• Avtaletypene DPA, BAA og underleverandøravtale med vilkårene de bærer
• Varslingsvinduet ved avvik som sitt eget vilkår, fordi det måles i timer
• Svar på revisjon og varsel om underleverandør som utledede datoer
• Bare data, og ingen regelmodul