150 delar, och vad var och en är till för.

Att komma in i appen, och ålderskontrollen som avgör om ett konto alls får användas.

• Startskärm och vägledning vid första start, så att en återkommande användare hamnar där de slutade
• Registrering och inloggning mot gatewayen, med token i säker lagring
• Återställning av lösenord via e-post
• Ålderskontrollen för 18+, som visas innan något kan köpas

Kontrollen som låter någon genomföra köp, inklusive de lägen en person befinner sig i medan en människa granskar det som det automatiska steget inte kunde avgöra.

• En guidad introduktion som förklarar vad som efterfrågas och varför
• Ansiktsskanning, och dokumentkontroll som alternativ väg
• Lägen för gränsfall och granskning, så att personen aldrig lämnas att gissa
• Kontrollstatus som följer med till vad kontot får göra

Den första fliken. Ett rangordnat flöde av artiklar, videor och uppdateringar, plus avsändarna bakom dem.

• Ett rangordnat innehållsflöde som serveras av gatewayen
• Innehållsdetaljer med bilder och formaterad text
• Avsändarprofiler, så att en läsare kan följa en källa

Självstyrda verktyg: bedömningar en person gör själv, deras resultat och partnerfunktionerna som byggts runt dem.

• Gör en bedömning, och läs resultaten
• Delights-kartan – en personlig vy, och en delad
• Lägg till, gå med i, bjud in och jämför partner
• Partnerdetaljer, så att en jämförelse är läsbar snarare än en poäng

Katalogen som en klient möter den: bläddra, jämföra, spara, fråga, och chatten som följer.

• Bläddra och filtrera i katalogen över behandlare
• En profil med kvalifikationer, språk, tjänster och omdömen
• Sparade behandlare – Mina behandlare
• Chatta med en behandlare, och listan över de samtalen
• Konsultationsförfrågningar, för en fråga som ännu inte är en bokning

Det som faktiskt kan bokas, med pris, längd och om det sker online eller på plats.

• Bläddra bland tjänster som erbjuds på mottagningen
• Tjänstedetaljer med pris, längd och form
• Direkt vidare till bokning eller köp från tjänsten

Att köpa – ett enstaka samtal, ett paket eller en produkt. Det är härifrån samtalet en klient senare använder kommer.

• Produktkatalog och produktdetaljer
• Varukorg, kassa och tjänsteavtalet som godkänns vid köpet
• Orderbekräftelse, och orderhistoriken bakom den
• Betalningen hanteras av gatewayen, aldrig av appen

Att lägga ett köpt samtal på en bestämd tid i en bestämd kalender – och allt klienten ser om det efteråt.

• Skapa en bokning mot verklig tillgänglighet, i klientens egen tidszon
• Bokningslistan, med varje status ett samtal kan ha
• Bokningsdetaljer: anslutningslänk, plats och rum, boka om och avboka
• Köpta samtal – ägda, använda och kvar att boka

Att fråga öppet, att fråga privat, och de personer en klient väljer att dela sina framsteg med.

• Ett öppet frågeflöde, och att ställa en fråga innan man bestämmer sig för något
• Frågedetaljer med behandlarens eget svar
• Supportärenden – skapa ett, följ det, läs svaren
• Partnerinbjudningar och partnerlistan

Den tredje fliken, och svaret på de flesta supportfrågor. Allt appen vet om personen, på en skärm.

• Bokade möten och möteshistorik, med återkoppling och omdömen om samtal
• Köpta samtal, köpta tjänster och favoriter
• Faktureringsadress, fakturor, fakturadetaljer, betalsätt
• Aviseringar, chattar med behandlare, partnerchattar och ställda frågor
• Mina tjänster och mitt innehåll, för dem som publicerar
• Redigera profil, byt lösenord och kontovyerna

Samma flik, sedd av en behandlare. Det är det som gör en hel mottagning möjlig att driva från telefonen i stället för från ett skrivbord.

• Tillgänglighet: veckotider och daterade undantag i schemat
• Klienters chattar, och klienthistoriken bakom varje samtal
• Lämna en samtalsrapport från det samtal den hör till
• Behandlaranalys – bokningstratten, framförhållning och siffror per klient
• Ersättning och de fyra korgarna, dolda och ersatta av antal vid fast lön

En samtalsassistent i appen, strömmad genom gatewayen så att ingen modellnyckel någonsin når enheten.

• En chattvy med strömmade svar
• Samtalshistorik, så att en tråd kan tas upp senare
• Går via gatewayens AI-gränssnitt, som pekar på en riktig leverantör eller en attrapp

Kontrollerna en person förväntar sig att hitta, inklusive de som en tillsynsmyndighet förväntar sig att de ska kunna hitta.

• Appinställningar och val av språk bland 23 språkversioner
• Integritetsinställningar, och vilka aviseringar som kommer i vilken kanal
• Säkerhetsinställningar, inklusive enhetssessioner
• Villkor, integritetspolicy och juridiska dokument i appen i stället för på en webbplats
• Radering av kontot, som en väg personen kan ta själv

Det som varje funktion ovan är byggd på. Ingen skärm, men skälet till att skärmarna beter sig konsekvent.

• Nätverkskommunikation mot gatewayen, med förnyelse av token och felhantering på ett ställe
• Säker lagring för token och säkert enhetstillstånd
• Navigering, så att en avisering kan öppna exakt den skärm den gäller
• Ett enda tema som bär 7DaysCares designsystem
• 23 översättningsfiler, med kalendersystemet som följer personen, inte verksamheten
• Gemensamma komponenter, så att en lista, ett tomt läge och ett fel ser likadana ut överallt

Förmedlar inloggning mot affärskärnan och utfärdar egna kortlivade token. Appen håller aldrig någon inloggningsuppgift till kärnan.

• Logga in, registrera, förnya och logga ut, med JWT utfärdade av gatewayen
• Den aktuella användaren och deras profil
• Registrering av enheter, så att push-aviseringar når rätt telefon
• Juridiska dokument och godkännandet som registreras mot en person

Allt en klient bläddrar i innan de lägger ut något, serverat snabbt och cachat där det är dyrt.

• Behandlare, deras profiler, tillgänglighet och tjänster
• Tjänstekategorier och bokningsbara produkter
• Omdömen och betyg, med hänsyn till modereringsstatus
• Cachade läsningar för allt katalogen hämtar upprepade gånger

Den transaktionella halvan. Köp, köpt samtal, bokning, faktura och betalning, var och en mappad mot affärskärnan i stället för återimplementerad.

• Skapa, boka om och avboka en bokning, med villkoren tillämpade av kärnan
• Ordrar och de köpta samtal de ger upphov till
• Fakturor och fakturadokument
• Start och bekräftelse av betalningar, bakom ett betalgränssnitt

Den läsintensiva halvan: det en person bläddrar i när de inte bokar.

• Det rangordnade innehållsflödet och innehållsdetaljer
• Öppna frågor och svar
• Utforska, bedömningar och deras resultat
• Partnerfunktioner och jämförelserna som bygger på dem

WebSocket-navet. Chatt, närvaro, AI-strömning och signalering för röst och video, på en anslutning.

• Hantering av WebSocket-anslutningar och närvaro
• Chatt mellan klient och behandlare, och gruppkanaler
• Signalering för röst- och videosamtal
• Leverans av aviseringar och aviseringsinställningar per person
• Push-aviseringar via Firebase Cloud Messaging

Filer, hållna så att appen aldrig talar direkt med lagringen och inget serveras från en URL som går att gissa.

• Säker åtkomst till dokument, som respekterar kärnans åtkomstregler i stället för att avgöra dem på nytt
• Uppladdning och hämtning av media, via gatewayen
• Bilder som skalas om och cachas, så att en kataloglista är billig på en telefon

Resten: att skapa ett ärende, be om en konsultation, tala om för appen vad den här driftsättningen har slagit på, och att prata med en modell.

• Supportärenden och deras svar
• Konsultationsförfrågningar
• Konfiguration vid körning, så att appen bara visar de funktioner verksamheten slagit på
• AI-förfrågningar, strömmade, med modellnyckeln förvarad här och ingen annanstans

Fyra funktionsflaggor, som var och en pekar på en riktig leverantör eller en attrapp. Det är därför systemet kan demonstreras, utvecklas och testas utan något externt konto alls.

• DATA_SOURCE – affärskärnan i Odoo, eller en attrappdatamängd
• PAYMENTS – en riktig leverantör, eller en attrapp som beter sig som en
• NOTIFICATIONS – Firebase Cloud Messaging, eller en attrapp
• AI – en riktig modellleverantör, eller en attrapp
• Hastighetsbegränsning och token buckets i Redis, så att en gräns gäller över flera processer
• Ingen enskild extern leverantör kan hindra mottagningen från att sälja, leverera och dokumentera ett samtal

Schemamotorn under allt annat – kalendrar, tillgänglighet, rum och reglerna som avgör vilka tider en klient faktiskt får se.

• En tillgänglighetsmotor som omvandlar veckotider, daterade undantag och befintliga bokningar till lediga tider
• Schemaläggare, värdar, platser och rum, med kapacitet och upptäckt av krockar
• Regler för tider, väntelistor och automatiska erbjudanden när en bokning frigörs
• Intagsfrågor som ställs vid bokningen, med svaren sparade på bokningen
• Påminnelser via e-post och sms, med spärrlistor per person
• Publicering av kalendern som ICS, och länkar till externa kalendersystem
• Närvaroposter, en bokningstratt och analysen bakom siffrorna per behandlare
• Hastighetsbegränsning på öppna bokningsvägar, och en väg för radering av bokningsdata

Säljer enskilda samtal som köpta samtal. Det är modulen som gör köp och bokning till två separata steg, vilket är det som gör att ett paket kan säljas i dag och bokas över flera månader.

• Samtal sålda mot en produkt, styckvis eller som paket
• Tjänsteavtal för paket som godkänns vid köpet och sparas i den version som godkändes
• Avbokningsvillkor i nivåer med varselfönster, avgifter och en frist
• Flöden för ombokning och avbokning som ger tillbaka samtalet där villkoren säger det
• Behandlarens korgar – köpt, bokat, genomfört, inte bokat – och framsteg per behandlare
• Bokningslänkar i portalen, och spärrar i webbutikens varukorg som stoppar ett köp som inte går att boka
• En skarv för ersättningsberäkning: samtalet låser sin egen fördelning vid bokningen utan att veta vad ett avtal är
• Återkoppling efter samtal, och spåret av uteblivna besök som rapporteringen om pålitlighet behöver

Applikationslagret: behandlare och deras offentliga profiler, mobil-API:t, innehåll och gemenskap, aviseringar och kontot som klienten möter.

• Behandlarprofiler med ett arbetsflöde för kontroll, behörigheter, tjänster och kalendrar
• Omdömen, betyg, öppna frågor och behandlarens översikt bakom dem
• REST-endpoints för mobilappen, JWT-autentisering och WebSocket-sessioner
• Chatt i realtid – klient till behandlare, partnerchattar och gruppkanaler – kopplad till samtal
• Innehåll och publicering: avsändarprofiler, ett rangordnat flöde och utforskning
• Fakturor, betalsätt och bryggan från order till samtal
• Aviseringar via push, e-post och i appen, med spridning för larm om samtal
• Ålders- och identitetskontroll, supportärenden, konsultationsförfrågningar och registrering av enheter

Odoo-apparClinic

De sjutton ledningsrapporterna. Tolv frågar om mottagningens uppgifter stämmer med det som hände; fyra jämför hur det går för behandlarna; en står över dem alla.

• Avstämningslistor: samtal som inte avslutats, obokade samtal, utbud mot efterfrågan, betalningskedjan, avgiftsliggaren
• Utbetalningsberedskap, avbokningsmönster, handlingsakten, klienternas kontinuitet och granskningskön
• Samtal utan anteckning, och avbokade samtal lästa tillsammans med avbokningsmönstren
• Prestationer: behandlarens resultatkort, jämförelsetabellen, pålitlighet och klientutfall
• Ett omfångsval – hela verksamheten, valda personer, en person – med en jämförelseperiod
• Sparade vyer och CSV-export i varje rapport
• En rapport skriver aldrig: att avinstallera tar bort rapporterna och ändrar inget operativt beteende

Journalanteckningen en behandlare lämnar efter ett genomfört samtal – sparad som ett säkert dokument om klienten i stället för som en bilaga till ett möte.

• En rapport lämnad mot samtalet och registrerad som gällande klienten
• Krypterad i vila i tjänsten för säkra dokument, med en nyckel per version
• Åtkomst avgörs bara av upplösningen av vårdteamet, aldrig av en roll eller hierarkisk ställning
• Rättelser lämnas som nya versioner; den tidigare versionen förblir exakt som den var
• Varje läsning loggas, så att jaga en saknad rapport aldrig innebär att läsa en

Ett stående upplägg i stället för ett köp varje gång: en plan som säljs i butiken, och en klients medlemskap mot den.

• Planer är butiksprodukter med en bild och en beskrivning; den öppna katalogen finns på /memberships
• Ett medlemskap innehåller köpta samtal, tillgång till chatt och minuter för konsultation utanför appen
• De köpta samtalen förblir vanliga köpta samtal, så bokningen behöver aldrig lära sig en andra regelbok
• Perioder med förnyelse och överföring, där planen avgör vad som förs över
• En behandlare ser vilka av deras klienter som är medlemmar, och i vad

Behandlartid köpt som minuter i stället för som en tid, använd i chatten och redovisad på minuten.

• En tjänst kan sälja en budget av behandlarminuter, med ett valfritt giltighetsfönster
• Prislista på företaget, som kan ersättas per tjänst
• En post i liggaren per debitering, och ett kontoutdrag som både klienten och behandlaren kan öppna
• Budgeten kontrolleras där meddelandet skickas, inte där någon kommer ihåg att kontrollera den

Frågeformuläret en klient fyller i före första samtalet, sparat som kliniskt innehåll i stället för som enkätsvar.

• En tjänst anger vilket frågeformulär som hör till den
• Klienten fyller i det före samtalet, från sina egna sidor
• Svaren skrivs direkt till ett krypterat dokument – de lämnas aldrig kvar i enkätens egen lagring
• Behandlaren öppnar det från samtalet, enligt de vanliga åtkomstreglerna för dokument

Banköverföring som betalväg, för mottagningar som vill att en person tittar på varje order före och efter att pengarna rör sig.

• Godkänn ordern, fakturera den, ta emot underlaget för överföringen, godkänn underlaget och skapa sedan de köpta samtalen
• Köpta samtal dyker upp först när underlaget godkänts, så en obetald order kan inte boka ett samtal
• Ett avslag har sitt skäl, och ordern går tillbaka till den person som kan rätta den
• Varje steg är ett läge på ordern snarare än en anteckning någon lämnat

Klientens halva av vägen utanför appen: var de betalar, vad de laddar upp och vad ordern väntar på.

• Varje läge har en egen färg och markering under Mina ordrar, så att väntar syns tydligt skilt från avslaget
• Betala och ladda upp underlaget i en dialog, utan att lämna ordern
• Skälet till avslaget visas där den person som måste agera på det kommer att läsa det
• Ett kort på översikten för ordrar som behöver något från klienten

Böckerna, på en egen översikt: vad som kom in, vad som är skyldigt, vad leveransen kostade och vad som återstår. Skild från administratörens med avsikt – att jaga en obetald faktura på golvet är ett jobb, och att föra huvudboken är ett annat.

• En startsida med fyra pengarutor, sex hälsotal, sex diagram och en avvikelselista
• Tjugoen rapporter: kassa, intäkter, leveranskostnad, prognos, läckage och två kontrollistor
• Periodiserat eller kassa, fem perioder och ett eget intervall, som följer med genom varje nedborrning
• Avgränsa varje rapport per tjänst, behandlare eller klient; en diagramvy och CSV på varje sida
• Inget nettat, ingen andel utan nämnare, prognoslager summeras aldrig
• En checklista för månadsbokslutet där idel bockar är det goda bokslutet
• Läser huvudboken och aldrig kliniskt innehåll – en separat behörighet, på ett internt konto

Vad som behöver göras, för de fyra teamen runt verksamheten. Försäljning, personal, marknad och leverans får var sin sida, och varje sida öppnar med samma fråga: vad är sent, vad är nu, vad kommer, och vad har ingen lovat att göra något åt.

• Fyra översikter, var och en en post i stället för kod, så ett branschpaket kan lägga till en
• Aktivitetsraden på varje sida: sent · i dag · planerat · inget inbokat · behöver uppmärksamhet
• ”Inget inbokat” är bandet som Odoo inte har något tillstånd för: en öppen post som ingen har lovat att göra något med, och som inte syns på någon annan skärm
• Uppmärksamhetsregeln står under sitt eget antal, för en gräns som läsaren inte kan se är en gräns hen slutar lita på
• Tjugosex rapporter, var och en med koden för den kravrad den uppfyller
• Ett tal vars modell inte är installerad rapporterar ”ej tillämpligt”, aldrig noll
• Listor som borde vara tomma, med en nattlig avisering som levereras avstängd
• Varje andel skriver ut sin nämnare, och ett tankstreck under fem poster
• Dagens närvaro och frånvaro — fortfarande instämplad, instämplad i dag, ledig i dag
• Beror på base, mail och web och inget annat: den rapporterar om CRM-, personal-, utskicks-, projekt- och avtalsdata utan att kräva någon av dem

Hur det går, i den app chefer redan öppnar. Fyra sidor i Odoos egna översikter, i en egen sektion ”Klinikens team”, byggda så som dess sidor för Försäljning och Utlägg är byggda.

• Fyra sidor — CRM, försäljning, leverans, personal — vid sidan av Odoos egna
• Fyra nyckeltalsrutor per sida, var och en med föregående period intill
• Två diagram och två till fyra topplistor per sida, var och en öppnar posterna bakom sig
• Ett tal som beskriver ett tillstånd i världen tar ingen period och visar ingen jämförelse: en personalstyrka filtrerad till nittio dagar är inte en personalstyrka
• Ett diagram grupperat på ett datum tar perioden; ett grupperat på ett skede gör det inte
• Arbetsböckerna genereras och deras korsreferenser valideras innan något skrivs
• Varje sida är synlig för den Odoo-grupp som äger dess data, så inget extra beviljas

Tre sidor till i samma sektion, hållna isär eftersom var och en kräver en app som verksamheten kanske inte kör.

• Närvaro: instämplade just nu, poster, arbetade timmar, extra timmar, per person och per avdelning
• Frånvaro: ansökningar utan svar, godkända dagar, avslag, och var ledigheten faller per månad, typ och avdelning
• Personalutbetalningar: att redovisa, att godkänna, att ersätta, och vad som begärts under perioden
• Skilda från de övriga översikterna eftersom varje sida tvingar fram en app — närvaro, frånvaro, utlägg
• Närvaro räknar poster, inte människor: en lunchrast gör en person till två rader, och sidan säger det
• ”Instämplade just nu” är ett närvarotal under arbetsdagen och efter den en lista över dem som glömt stämpla ut

Ett öppet formulär som gör en fråga till en uppgift som någon äger.

• Ett formulär på /support/ticket som vem som helst kan använda, inloggad eller inte
• Varje inskick öppnar en uppgift, tilldelad butiksadministratören
• Den som skickat in följer sitt eget ärende, och administratören aviseras i Discuss

Ett vårdförlopp med en början, ett slut och en plan – ryggraden som allt annat i journalen hänger på. Vård är inte en ström av bokningar, och journalen säger det.

• En episod öppnas vid det första genomförda samtalet, och en klient har en öppen åt gången
• En behandlingsplan per episod: problem → mål → delmål, tre nivåer och inte fler
• Ett mål har en rubrik, ett måldatum och ett resultat – vad som arbetades mot, och hur det gick
• Pågår eller Avslutad som det läge som är säkert för klienten, skilt från de sex kliniska utfallen så att de två aldrig delar en skärm
• En plan ses över eller ersätts, den ändras aldrig på plats: versionen som man kom överens om förblir som den var
• Att avsluta en episod kräver ett utfall för varje öppet mål, eftersom det är det enda ögonblick någon vet svaret – och anger hur många som skulle stängas utan ett
• Avslutet startar lagringsklockan som dokumenttjänsten räknar från
• Varje behandlare som har träffat klienten ser episoden; att läsa en kollegas rapport är en separat begäran, godkänd av en administratör och skriven till loggen oavsett utfall
• Klienten läser samma episod på sina egna sidor, med ord som aldrig betygsätter dem

Anteckningsmallar som en ordnad lista av typade fält, så att en anteckning är svar snarare än prosa som ingen kan söka i.

• En mall är en versionshanterad, publicerad lista av typade fält – text, tal, skala, val, datum
• En ifylld anteckning är svaren plus ett renderat säkert dokument
• Svaren är läsbara exakt när deras dokument är det: en åtkomstregel, inte två som glider isär
• Synlighet per fält, så att en privat iakttagelse saknas i klientens kopia i stället för att döljas i den
• Mallar väljs i formuläret för samtalsrapporten, efter disciplin

Startinnehållet för mallmotorn: tusen namngivna anteckningsformat, så att en mottagning inte börjar med ett tomt bibliotek.

• Över tusen namngivna mallar – SOAP, DAP, BIRP, intag, uppföljning – grupperade efter disciplin
• Installeras som data, och kan ändras efteråt som vilken mall mottagningen själv skriver

Det en klient registrerar mellan samtalen, kopplat till målet det mäter. Ett program som inte rapporterar mot något är hur uppföljning blir till läxor.

• Ett programbibliotek med sex slags punkter: frågeformulär, mätning, val, dagbok, uppladdning, uppgift
• Ett program skickas till ett mål, så att varje post rapporterar mot något planen faktiskt bad om
• Klienten registrerar i sin egen plan: det som ska göras i dag först, sedan varje mål och det som är öppet mot det
• Inget på klientens sidor räknar eller betygsätter dem – något som inte registrerats står som inte registrerat, och det finns ingen andel, ingen poäng och ingen svit
• Behandlarens klientlista med de mest angelägna först: riskflaggor att kvittera, aldrig påbörjat, tyst i över fjorton dagar, slutar den här veckan
• En andel med färre än fem att mäta visas som ett streck, och en räkning som misslyckades visas som otillgänglig – aldrig som noll
• ”Jag tycker det här är svårt”, som når behandlaren utan en siffra kopplad till sig
• Rapporter lämnade mot ett mål i stället för mot en bokning, krypterade, enligt samma åtkomstregler som varje annan klinisk rapport
• Program som gås igenom vid ett samtal, räknade av mottagningsrapporten som frågar om någon tittade
• Varje yta med observationer säger att posterna inte övervakas i realtid

Poängsatta instrument som mottagningen äger. Inget instrumentinnehåll levereras och ingen licens hävdas: mottagningen lägger in det den har rätt att använda.

• En poäng sparas med den instrumentversion som gav den, och räknas aldrig om
• Intervall och tröskelvärden per instrument, där ett riskintervall ger en flagga som någon måste kvittera
• Fylls i av klienten i portalen eller under samtalet, och kanalen registreras i båda fallen
• Tidslinjer per instrument med riktning; poäng från olika instrument slås aldrig ihop till en siffra, eftersom de mäter olika saker på olika skalor
• Ett frågeformulär är en sorts programpunkt, inte en separat funktion med en egen lista

En anteckning skriven en gång och arkiverad hos varje deltagare som deras eget dokument.

• En skriven källa, ett arkiverat dokument per deltagande klient
• Ett privat fält saknas i en annan deltagares dokument, det är inte dolt i det
• Arkiverad hos dem som deltog, inte hos alla som var bokade
• Samtalet räknas som dokumenterat först när varje deltagare har sin kopia

Ett förfallodatum en behandlare anger när ett samtal slutar, som man agerar på när det kommer.

• En återkallelse är ett datum och ett skäl, skapade i slutet av ett samtal
• Den bjuder in; den bokar aldrig
• Förfallna återkallelser syns i mottagningens sammanfattning innan något meddelande skickas automatiskt
• Automatisk inbjudan förblir avslagen om inte mottagningen slår på den

Diagnoskoder där faktureringen behöver dem, sökbara i stället för inskrivna ur minnet.

• Sökbara kapitel och koder i ICD-10-CM
• En kod registrerad på klienten och överförd till ordrar och fakturor

En enda frågelista i produkten, och de tre sakerna den inte bär med sig av sig själv: en stabil svarsnyckel, synlighet per fråga, och en markering för det enda tal som får lämna det krypterade.

• I produkten hade fyra byggare vuxit fram: anteckningsmallens inskrivna fält, bokningens egna frågor, uppföljningspunkterna och enkäten bakom inskrivningsformuläret
• Fyra byggare är fyra ställen att lägga till en frågetyp på, fyra återgivningar och fyra svar på ”vart tog det svaret vägen?”
• En frågelista skrivs i survey.survey och ingen annanstans
• Ingen svarsrad i enkäten skapas någonsin: det lagret är vanliga Postgres-kolumner, rätt för ”hur gick sessionen?” och fel för en sjukdomshistoria
• Svaren i ett säkert formulär finns bara inne i ett krypterat dokument, i en JSON-version och en HTML-version
• Det enda undantaget är ett tal som författaren märkt som diagrambart, för ett diagram kan inte läsa krypterad text
• En privat fråga saknas i det delade dokumentet och ligger i sitt eget, i stället för att vara gömd på en skärm som någon kan ändra
• När ett formulär en gång har fyllts i slutar dess frågor, svarsalternativ och alternativpoäng att röra sig
• Vem som får läsa ett inskrivningsformulär är inte vem som får läsa en strukturerad anteckning: dokumenttyper hör därför till den modul som använder formuläret

En bokningsmalls frågor utformas i enkäten och arkiveras krypterade, så att bokningen kan fortsätta vara en bokning.

• En bokningsmall anger en enkät, och den publika bokningssidan visar den med den enda återgivningen
• Svaren arkiveras i ett krypterat dokument kopplat till bokningen
• Bokningens egen frågemodell blir kvar, och bör det: ett telefonnummer, en referens, en samtyckesruta, och de frågor som skriver rakt på kontaktposten där receptionen måste kunna läsa dem
• Vad den hade fel form för är en verksamhet som frågar ”vad för dig hit i dag?”
• Det svaret låg tidigare i en vanlig kolumn helt utan åtkomstkontroll, i klartext på bekräftelsesidan, och kopierat in i kalenderhändelsens beskrivning — som synkroniseras utåt och följer med i varje inbjudan
• Inget i den här modulen skriver till någon av dem, och det är dess syfte snarare än en sidoeffekt
• Beroendet av dokumenttjänsten bor i den här bryggan, så en installation som bara vill ha en bokningssida får bara det

Den inskannade samlingen psykologiska instrument som sökbara poster, med ett valfritt levande formulär så snart en skanning görs till ett.

• Den inskannade samlingen inläst som poster med sin OCR-text, så att ett instrument kan hittas på det som står på det
• En indelning efter det system varje instrument riktar sig mot
• En valfri enkät, skapad när en skanning blir ett levande formulär
• Frågor skrivs aldrig här — det är den enda byggarens uppgift
• Byggs om från käll-PDF:erna med skript i stället för att redigeras för hand

Ersättningsvillkor per samtal på anställningsavtalet, och utbetalningsperioden som reglerar dem. Inget räknas om vid utbetalningen – varje samtal låste sin egen fördelning när det bokades.

• Fyra ersättningsformer: månadslön, timarvode, fast arvode per samtal eller en procent av varje samtal
• Villkoren hålls på avtalsversionen, så historiken är daterad och en gäller åt gången
• Utbetalningsperioder – varje vecka, varannan vecka, varje månad eller varje kvartal – förankrade i kalendern eller i avtalets start
• Ett dagligt jobb som öppnar ett utkast till utbetalning samma morgon som en period stängs
• Att bekräfta en utbetalning skapar en leverantörsfaktura per behandlare från de låsta beloppen
• En sparad utbetalningshistorik som behandlaren kan se, inklusive makulerade utbetalningar
• Att omförhandla i dag skriver aldrig om vad som var skyldigt förra månaden

Skickar uppdragsavtal för signering från den post de hör till, och sparar den signerade historiken på den posten.

• Skicka ett avtal för signering från själva avtalet
• Varje begäran sparas mot posten som dess historik
• Ersättningen för samtal kan hållas inne enligt ett avtal som ingen ännu har undertecknat
• Installeras bara när båda sidor finns, så att ingen av modulerna bär ett beroende den inte behöver

Fristående behandlare hyr plattformen i ett abonnemang som vi bygger. Den här modulen håller abonnemangsformerna, abonnemangen och reglerna för vad ett abonnemangs tillstånd låter en behandlare göra.

• Abonnemangsformer bär en kanal — egen mottagning, marknadsplats eller båda —, månads- och årspriser, och villkorsrader skrivna som meningar
• En forms funktionsbrytare läses ur de installerade modulerna i stället för att skrivas in
• Ett abonnemang kopierar formens villkor och funktioner vid undertecknandet och läser dem aldrig igen, så en prisändring i morgon lämnar dagens abonnemang i fred
• Ett gällande abonnemang per behandlare och högst ett på väg, upprätthållna av två partiella unika index i stället för av en kontroll någon kan glömma
• Varje ny fristående behandlare börjar på den inbyggda provperioden — sju dagar som standard, ställbart i inställningarna
• När provperioden tar slut väntar nya bokningar och behandlarens länk på att ett abonnemang väljs, undertecknas och betalas. Poster stängs aldrig
• Personalen kan tilldela en form som webbplatsen inte visar — på kort, på faktura eller helt utan kostnad —, med avtalet skickat eller ett undertecknat exemplar bifogat, och skälet antecknat
• Abonnemang och fakturering på behandlarens eget konto, och en banner i arbetsytan under provperioden eller efter att den löpt ut
• Anställda behandlare, knutna genom anställningsavtal, har aldrig ett abonnemang och blockeras aldrig

Vem som förde vilken klient till vilken behandlare — det enda faktum som varje avgift en fristående behandlare betalar hänger på, och det enda plattformen inte antecknade.

• En rad per par av behandlare och klient, med härkomsten och tillhörigheten: behandlarens klient, eller plattformens klient
• Tillhörigheten sätts vid första kontakten och ändras av ingenting utom en överföring från personalen, med skäl
• Behandlarens korta länk, /e/<kod>: den som följer den registrerar sig och blir den behandlarens klient
• Redan registrerad och ny hos den behandlaren: trycker ”Gå med”. Redan den behandlarens klient genom plattformen: personen förblir plattformens klient, och klicket loggas
• Varje besök på länken, och vad det ledde till
• Hur en person över huvud taget kom till plattformen — direkt, eller införd av en behandlare — hålls skilt från tillhörigheten, för det ena är ett faktum om en människa och det andra om ett par

Tar behandlaren emot klientens pengar är hen skyldig företaget dess andel. En månatlig körning som fakturerar den och följer den till betald.

• När behandlare godkänner ordrar och skickar betallänkar bär offerten, fakturan och betalsidan behandlarens eget företagsnamn, adress och momsnummer som säljare
• Om behandlaren tog emot betalningen låses fast på sessionen vid bokningen, intill andelens fördelning, så att ändra inställningen i morgon inte sträcker sig tillbaka till förra månaden
• Ingen ny formel: företagets andel säger redan vad företaget behåller, och håller behandlaren pengarna är det precis det beloppet hen är skyldig
• En anställd behandlare behåller inget av en session och är därmed skyldig hela; en frilans på 70/30 är skyldig de 30
• En indrivningskörning per cykel, som spegelbild av utbetalningskörningen — en kundfaktura per behandlare för summan av de andelar hen tagit emot
• Att bokföra fakturan direkt eller vänta på att någon tittar på den är en inställning, påslagen som standard
• ”Betald” är Odoos egen betalningsstatus: den här modulen iakttar den och skapar aldrig en betalning
• Behandlarens arbetsyta får en sida Betalningar — intjänat, mottaget, skyldigt, och varje faktura med sin status
• Översikterna för administration och ekonomi får andra sidan: öppet mot betalt, räknat och summerat, med månadens intäkter intill

Listan över vad de installerade modulerna kan, anmäld av varje modul själv, för att abonnemang ska slå på och av den.

• Ingen skriver in katalogen: en modul med något värt att sälja levererar en funktionspost per förmåga
• Odoo skapar posterna när modulen installeras och tar bort dem när den avinstalleras, så katalogen beskriver alltid vad den här databasen faktiskt kan
• Ingen genomsökning, inget synkroniseringsjobb och ingen andra lista vid sidan av modullistan att komma ur steg med
• Beror med avsikt på inget annat än base, så att anmäla en funktion aldrig drar en klinisk modul in i ett beroende av plattformsskalet
• Vad en funktion betyder för en enskild behandlare — om hens abonnemang har den på, och upp till vilken gräns — hör till abonnemanget, inte hit

Själva tjänsten. En modell tar den i bruk med en rad och får sina dokument, en räkning och en inlämningsdialog som med vanliga ord säger vem som kommer att kunna öppna resultatet innan det sparas.

• Krypterat i vila med en egen nyckel, lagrat utanför Odoos filarkiv och aldrig serverat via /web/content
• Åtkomst genom uttryckliga regler, nekad som standard: en tillåtande regel som matchar och ingen nekande regel som matchar, varje gång
• Att vara administratör, chef eller den som lämnade in dokumentet ger i sig ingenting
• Varje läsning liksom varje skrivning loggas, i en hashkedjad logg med endast tillägg som ingen kan ändra
• Versionshanterat och med endast tillägg: en rättelse är en ny version, den föregående är orörd
• Lagring och gallring enligt relativa regler, genomförd genom att nyckeln förstörs
• Söker medvetet inte inuti dokument – krypterat innehåll kan inte fritextsökas

Det kryptografiska lagret, i en egen modul så att nyckelhanteringen kan granskas och revideras utan att man läser resten av applikationen.

• Kuvertkryptering med AES-256-GCM: en slumpmässig datanyckel per dokumentversion, inslagen under en driftsättningsnyckel
• Nyckeln som krypterar nycklar sparas aldrig i databasen
• Chiffertext i en egen katalog, utanför filarkivet
• Nyckelrotation som slår in nycklarna på nytt utan att skriva om en enda byte chiffertext
• Kryptografisk radering: att förstöra nyckeln gallrar dokumentet och lämnar granskningskedjan orörd
• Vägrar att starta om nyckeln saknas, är läsbar för alla, ägs av fel användare eller förvaras där den skulle följa med data

Där en person läser de dokument om sig själv som har delats med dem, på /my/documents – och bara dem.

• Den registrerade ser ett dokument när en regel för den registrerade beviljar det och inget nekar det – aldrig bara för att det gäller dem
• Psychotherapy notes, förseglade dokument och dokument under ett gällande beslut om undanhållande visas aldrig, vad deras regler än säger
• Ett filter som varje väg använder, så att det bara finns en definition av vem som får se vad
• Innehållet dekrypteras i minnet och strömmas; inget skrivs till disken
• Ett dokument användaren inte får se ger 404, aldrig 403 – att gissa referenser får inte avslöja vem som har journaler
• Varje visning och nedladdning loggas, även den registrerades egna, och sidan säger det
• Läsningar hastighetsbegränsas per användare, räknat från åtkomstloggen så att gränsen gäller över flera processer

Arkiverar säkra dokument mot kontakter – det vanligaste subjektet, eftersom den person ett dokument handlar om oftast är den det arkiveras mot.

• Lägger till tjänsten för säkra dokument på res.partner
• Installeras av sig själv när båda sidor finns, och avinstalleras utan att röra någon av dem
• En brygga per applikation, så att tjänsten på en kontakt inte drar in orelaterade appar

Arkiverar säkra dokument mot affärsmöjligheter – ett due diligence-paket är inget kliniskt, och har exakt samma krav.

• Lägger till tjänsten för säkra dokument på crm.lead
• Krypterat, regelstyrt och loggat vid varje läsning, som vilket annat säkert dokument som helst
• Installeras och avinstalleras rent och oberoende av de andra bryggorna

Arkiverar säkra dokument mot personalposter – ett disciplinärende eller en rapport från företagshälsovården är något en chef arkiverar och som det mesta av HR inte ska kunna öppna.

• Lägger till tjänsten för säkra dokument på hr.employee
• Åtkomst nekad som standard, så att en HR-roll inte öppnar en akt bara för att den är en HR-roll
• Installeras och avinstalleras rent och oberoende av de andra bryggorna

Arkiverar säkra dokument mot uppgifter – ett konfidentiellt avtal eller en undertecknad leverans, förvarad där arbetet följs upp.

• Lägger till tjänsten för säkra dokument på project.task
• Installeras av sig själv när båda sidor finns, och avinstalleras utan att röra någon av dem

Arkiverar säkra dokument mot ordrar – ett undertecknat avtal, eller en kunds identitetshandlingar, förvarade mot den försäljning de hör till.

• Lägger till tjänsten för säkra dokument på sale.order
• Installeras av sig själv när båda sidor finns, och avinstalleras utan att röra någon av dem

Valfritt: flyttar nyckeln som krypterar nycklar bort från Odoo-servern, så att en kopia av databasen inte är en kopia av dokumenten.

• Dokumentnycklar slås in och packas upp via en fjärrmyndighet i stället för lokalt
• Nyckeln som krypterar nycklar finns aldrig på maskinen som serverar applikationen
• Slås på per driftsättning; den lokala backenden förblir tillgänglig och oförändrad
• En myndighet som inte går att nå vägrar öppna dokument i stället för att i tysthet falla tillbaka

Löser upp vårdteamet. En terapeut når journalerna för personerna på sin egen lista, inte mottagningens – och det är det som gör kravet på minsta nödvändiga möjligt att upprätthålla snarare än ett ideal.

• Vårdrelationer – behandlare till klient, med en typ, en början och ett slut
• Åtkomsten upphör när relationen gör det, efter en frist som räcker för att göra klart utestående anteckningar
• Kliniska roller som avgör vilken del av applikationen någon når, aldrig vad de kan öppna
• En profil bara för ledningen med incidenter, klagomål och skyddsanmälningar – stängd även för den som lämnade in dem
• Registret över utlämnanden: vad som lämnade verksamheten, till vem och på vilken grund
• Den registrerades rättigheter: begäranden om tillgång med sin lagstadgade klocka, rättelser som läggs till i stället för att skriva över, begränsningar som förseglar
• Lagringsankare – senaste kontakt, födelsedatum, dödsdatum – som baslagret räknar från
• Själva incidentposten – vad som hände, vilka som berördes och om den som tog det kunde läsa det – där jurisdiktionslagren lägger sina klockor på en enda incident i stället för att var och en håller sin egen
• Konfidentiell kommunikation: en klient kan be att en kanal aldrig används, och det nekas där meddelanden lämnar systemet snarare än där någon kommer ihåg – ett mejl till en spärrad adress avbryts, det skickas aldrig i tysthet till adressen som finns registrerad
• Inget fält någonstans för att registrera varför de bad om det, eftersom att kräva en förklaring är just det regeln förbjuder
• En förlängning av en begäran om tillgång och bara en, begränsad mot det resulterande datumet snarare än mot det inskrivna antalet – en månad från mars och en månad från juli är inte lika långa
• Avgiften specificerad i de delar förordningen tillåter, eftersom ”skälig, kostnadsbaserad” är ett påstående, och ett påstående med en enda siffra bakom sig är ett som ingen kan kontrollera
• En kopia till någon som individen utsett, nekad tills deras undertecknade skriftliga instruktion finns registrerad
• Ett nekande granskat av någon annan än den som nekade – upprätthållet, inte lämnat åt rutinerna
• En nekad rättelse som personen inte håller med om: deras redogörelse, eventuellt svar, och båda följer med varje senare utlämnande av den omstridda uppgiften – bifogade av registret, inte av att någon kommer ihåg
• De som längre fram redan har informationen namnges och informeras, eftersom en rättelse ingen hör talas om rättar en enda kopia av en journal

GDPR-lagret: maskineriet för rättigheter och styrning som HIPAA saknar motsvarighet till, och därför täcker en installation byggd efter amerikansk standard inte EU.

• Rättslig grund registrerad per dokumenttyp – art. 9.2 h för journaler, inte samtycke
• Radering (art. 17) genomförd genom att nyckeln förstörs, så att rättigheten respekteras utan att beviset för vad som fanns raderas
• En bedömning inför radering, och inget förstörs medan ett rättsligt kvarhållande eller en lagringstid gäller
• Dataportabilitet (art. 20) som en strömmad zip – metadata som JSON, innehåll som det lämnades in, varje dokument loggat för sig
• Anmälan av incidenter (art. 33/34): 72 timmar till myndigheten, och krypteringsundantaget i art. 34.3 a
• Konsekvensbedömning och registerförteckning som en del av styrningsakten

En brygga, inte ett bygge – kopplar ett undertecknat integritetsmeddelande till kvitteringsposten, så att akten kan svara på vilken version de faktiskt såg.

• En slutförd signatur skriver kvitteringen en gång – en webhook som levereras två gånger får inte göra räkningen av vilka som saknas fel
• Signaturbegäran anger meddelandets version, eftersom det är den enda fråga en kvittering får
• En penna på ett formulär i receptionen är fortfarande en skriftlig kvittering; bryggan lägger till en väg i stället för att ersätta den vanliga
• En begäran som undertecknats av en behandlare för en klients räkning är inte den klientens kvittering, och räknas inte som en

UK GDPR och Data Protection Act 2018 på samma tekniska kärna – med prövningen av allvarlig skada byggd som ett arbetsflöde snarare än som en flagga.

• Prövningen av allvarlig skada (DPA 2018 Sch. 3 Pt. 2) registrerad med vem som beslutade, när, om vilka dokument och varför
• Kan bara fattas av någon med en aktuell vårdrelation, vilket systemet kontrollerar i stället för att anta
• Hamnar i en granskningskö innan den löper ut, och upphör av sig själv efter sex månader
• Att häva den återställer den etikett dokumentet hade tidigare, inte ”normal”
• Undanhållandet gäller den registrerade, inte vårdteamet – de som behandlar personen läser det fortfarande
• Lagringsschemat i NHS Records Management Code of Practice 2021 som startdata
• Hantering enligt Access to Health Records Act för journaler om avlidna

De administrativa skyddsåtgärderna – den halva av HIPAA som inte handlar om kryptering, och den halva som tillsynen citerar mest.

• Riskanalysen som en övning med period, omfång och metod, skild från registret över vad den fann – så att nästa år kan jämföras med det här
• Varje risk förs vidare till nästa bedömning med en länk bakåt, eftersom ett register som börjar tomt varje år förlorar det som beslutades
• Den inneboende risken beräknas och den kvarvarande medvetet inte – en kvarvarande risk framräknad genom att dra av en kontrollpoäng är en fiktion som säger samma sak om en kontroll som testades förra veckan och en som står i en riktlinje
• Att acceptera en risk kräver ett registrerat skäl; beslutet är ofta rätt och ingen kan efteråt säga vilket det var
• Granskningen av aktivitet med sina frågor namngivna – ingen vårdrelation, nödåtkomst, ett gemensamt efternamn, utanför arbetstid, en avvikande volym – eftersom ”granska loggarna” utan att säga vad man ska leta efter är hur granskningar blir en underskrift på ingenting
• Att slutföra en granskning verifierar varje hashkedja som berörts under perioden, vilket är det som gör en manipuleringssäker logg till en där manipulering upptäcks
• Utnämningar som datumintervall med luckorna beräknade, eftersom kravet inte är vem som har rollen i dag utan att någon har haft den utan avbrott
• Sanktionsposter som bara kan läsas av en grupp som ingen hamnar i indirekt – en sanktionspost som läcker är en incident i sig
• En checklista vid avslut och ett dagligt jobb som skapar en för alla vars slutdatum har passerat: konton som överlever anställningen är den kontroll som oftast misslyckas
• Utbildning med utgångsdatum, eftersom utbildning som gått ut inte är utbildning
• En kritikalitetsanalys som kontrollerar sin egen aritmetik: ett system vars databas återställs långsammare än systemet självt har ett återställningsmål som någon skrev ner, och de två siffrorna finns på olika rader i ett kalkylark
• Kontinuitetsplaner som säger när de senast testades, och en lista över dem som aldrig testats – det enda som skiljer en organisation med en plan från en som tror att den har en
• Ett test som inte nådde sina mål måste säga vad som gick fel, eftersom ett test som inte lärde någon något inte är ett underlag
• Överföringssäkerhet som en historik snarare än ett påstående: ”vi använder HTTPS” talar i presens, och de här posterna säger att det var sant de dagar någon frågar om
• Kontroller som inte kan ändras eller raderas, eftersom poängen med en historik är att den inte går att snygga till

HIPAA-lagret. Separationen av psychotherapy notes vilar på lagringen i stället för på att åtkomstreglerna är rätt.

• Designated record set (45 CFR 164.501) markerat per dokumenttyp, så att ett svar på en begäran om tillgång inte kan innehålla det som ligger utanför
• Psychotherapy notes i ett eget nyckelområde – nyckeln som öppnar den vanliga journalen öppnar inte dem
• En beviljning till den registrerade på anteckningarna nekas på varje väg, inklusive en direkt skrivning till regeltabellen
• Ett dokument som redan skrivits kan inte etiketteras om till anteckningarnas nyckelområde
• 42 CFR Part 2: varningen mot vidareutlämnande genereras i stället för att skrivas in
• Sex år av utlämnanden i registret, enligt delparten
• Anmälan av incidenter (164 Subpart D): ett otillåtet utlämnande presumeras vara en incident tills bedömningen i fyra faktorer säger annat, med resonemanget registrerat
• Sextio dagar till individerna från upptäckten, beräknat i stället för inskrivet, och med varning innan tiden löper ut
• De två femhundratalen hålls isär – meddelande till medier över 500 invånare i en delstat, meddelande till HHS vid 500 eller fler totalt
• Individuella meddelanden med alla fem delar som 164.404(c) kräver, så att ingen i tysthet kan utelämnas ur ett brev som läses bra
• Den årliga loggen över små incidenter tas fram som ett dokument, den sätts inte ihop ur minnet i februari
• Notice of Privacy Practices versionshanterat, med kvitteringar registrerade mot den version någon faktiskt fick
• Den halva som är lätt att hoppa över: där ingen underskrift erhölls krävs försöket och skälet – en pärm med undertecknade formulär kan inte besvara den frågan
• En arbetslista över klienter utan något registrerat mot det gällande meddelandet
• Grunderna för att neka tillgång som en sluten lista, var och en med uppgift om individen har rätt till granskning – att erbjuda en som inte finns och att neka en som finns är båda fynd
• De fyra grunderna för att neka en rättelse, också slutna, och den som är ett faktum om dokumentet kontrollerad mot dokumentet
• Part 2-regeln från 2024: ett samtycke som täcker behandling, betalning och verksamhet, nekat om det inte går att återkalla – ett enda samtycke utan väg tillbaka är det som någon glömmer att de gav
• En begränsning enligt Part 2 för de ändamålen behandlas som en rättighet snarare än en begäran, och kontrolleras före den allmänna – en kontroll i omvänd ordning skulle tillåta utlämnandet innan den nådde frågan
• En incident som rör journaler om substansbruk säger det i meddelandet, i stället för att begrava det under ”behandlingsinformation”
• 164.410 som två klockor: business associate har sextio dagar från sin egen upptäckt och våra börjar när de berättar det för oss, så en incident kan vara 118 dagar gammal utan att någon har missat en frist
• Part 2-meddelandet till patienten versionshanterat bredvid integritetsmeddelandet, i stället för en konstant i Python som ingen versionshanterar

Den tyska lagringstiden, som en regel dokumenttjänsten räknar snarare än en rad i en riktlinje som ingen tillämpar.

• § 630f BGB: tio år efter senaste kontakt, inlagt som lagringsregel
• Avgränsat till den här modulen snarare än hela EU-paketet, eftersom tiden är nationell

De norska reglerna som GDPR-lagret inte täcker, var och en placerad där handlingen sker i stället för i en policy: publicera en profil, bekräfta en utbetalningskörning, lämna ut något till en förälder.

• Pasientjournalforskriften § 14: patienten läser varje åtkomst till varje journal om hen, även de journaler hen inte visas — efter typ, aldrig efter titel
• En bevarandetyp helt utan gallringsdatum, eftersom Norge behåller journaler så länge de behövs; åren är ett omprövningsintervall och en människa beslutar, med ett skäl
• En journalöverlämning till en efterträdare, till Norsk helsearkiv eller Nasjonalarkivet, byggd i nedladdningsögonblicket, antecknad som utlämnande per dokument, och nedladdningsbar en gång
• Helsepersonelloven § 74: en profil med skyddad yrkestitel kan inte publiceras utan kontrollerat HPR-nummer, och kontrollen körs vid skrivning, så synkroniseringen kan inte gå runt den
• Närmast anhörig, förälder, vårdnadshavare och framtidsfullmakt, med åldersreglerna i §§ 3-4 och 4-3 upprätthållna vid utlämnanderegistret i stället för som ett filter på en sida
• Arbeidsmiljøloven § 1-8: en utbetalningskörning som betalar per session bekräftas inte utan en gällande bedömning, och fakta bakom den visas oviktade, eftersom frågan är rättslig
• Personvernombud och informationssäkerhetsansvarig som utseenden, kontrollerade bara för norska bolag

De roller finsk rätt kräver att en vårdgivare utser, och de skyldigheter som hänger på var och en. Oberoende av det norska paketet — båda slås på utifrån bolagets land, så en databas kan hålla båda.

• Legitimerade yrken och skyddade yrkestitlar hållna isär, för det är olika rättigheter: psykoterapeutti är en skyddad titel i Finland och ett fritt ord i Norge
• Terhikki-nummer, datumet för arbetsgivarens kontroll och om den var en registerslagning eller beslutsdokumentet; ett inskrivet nummer räknas som uppgivet, inte som kontrollerat
• En verksamhetsenhet med egen registrering, och vastuuhenkilö som utseende per enhet, så att två veckor utan ansvarig rapporteras
• Den offentliga egenkontrollplanen och den konfidentiella säkerhetsplanen är skilda genom konstruktionen: en och samma policypost kan inte märkas som båda
• Asiakastietolaki § 11: två år av logguppgifter med mottagare och grund, en skriftlig begäran med två månaders frist, och ett nekande antecknat med sitt skäl
• Potilaslaki § 9(2) anger ingen ålder, så en underårig är en antecknad bedömning: utan den nekas ett utlämnande till vårdnadshavaren, och nekandet säger att bedömningen saknas
• Tolv år efter dödsfallet och, där dödsfallet inte är känt, 120 år från födelsen

Schweiz skiljer kvalifikationen från tillståndet att praktisera, räknar försäkrade sessioner mot en läkarordination, och binder leverantören till samma straffrättsliga tystnadsplikt som behandlaren. Tre saker kärnan inte kan uttrycka, och inget mer.

• Den federala titeln är inte tillståndet: yrkesutövningstillståndet är kantonalt, ett per kanton, vart och ett med egen giltighetstid — en behandlare kan alltså bära namnet i Schweiz och ha rätt att arbeta på bara en plats
• En profil med skyddad titel publiceras inte utan både ett kontrollerat PsyReg-nummer och ett gällande, kontrollerat kantonalt tillstånd — och nekandet säger vilket av de två som saknas
• Där en titel är kontrollerad och inget tillstånd är det, säger den publika statusen det i stället för att antyda ett; en okontrollerad marknad är inte betjänt av en annons som läses som en kontrollerad
• Anordnungsmodell: femton sessioner på läkarordination, förnybara en gång till trettio, och försäkringsbolaget därutöver — räknade genom kedjan av förnyelser, med varning före den session som inte skulle betalas, och nekade vid den andra förnyelsen utan ett godkännande i akten
• Bara en genomförd session räknas; en bokad gör det inte, för att räkna den skulle stoppa en ordination två sessioner för tidigt
• Artikel 321 binder hjälppersoner till samma straffrättsliga plikt som behandlaren, så registret ställer den enda fråga artikeln hänger på: kan de läsa uppgifterna i klartext?
• Tio år efter sista kontakten, sådda på den bevarandeklocka dokumenttjänsten redan hade — inget andra sätt att säga samma sak
• De kantoner varje behandlare har tillstånd i avgör vilket språk deras myndigheter skriver på, visat på behandlaren och på varje tillstånd
• Försäkrad fakturering har sin form här och ingen av sina kataloger: en tariffutgåva, positioner i taxpoäng, poängvärden per kanton och försäkringsklass. Positionerna och poängvärdena är licensierade data som en installation läser in, för en trovärdigt påhittad kod är en kod någon fakturerar på
• En session som inte kan prissättas säger vilken kanton som saknar inläst poängvärde, och visar inget belopp alls — noll franc skulle betyda att sessionen inte kostar något, vilket är ett annat påstående
• Tyska, franska och italienska genom hela gränssnittet, i schweiziska termer: en Berufsausübungsbewilligung snarare än en översatt ”kantonal licens”, och en Hilfsperson snarare än en ”hjälpkraft”

En fast lista med frågor som ställs till själva driftsättningen. Det mesta av kontrollen fanns redan och var utspridd; det här är sidan som läser den på ett ställe.

• Ett register över kontroller, en körning enligt schema och en rapport över båda
• Bara det som är fel rapporteras: en kontroll som går igenom säger ingenting, så sidan är tom när driftsättningen är frisk
• Varje fynd anger regeln det kom från och posten det hittades på
• Körningar sparas, så att ett fynd som återkommer syns som ett mönster snarare än som en nyhet

Själva signaturtjänsten: en signeringsceremoni i portalen, policyer per jurisdiktion och en hashkedjad granskningskedja. Egen driftad, så inget dokument lämnar systemet för att signeras.

• En signeringsceremoni i portalen som fångar identitet och avsikt i ögonblicket för underskriften
• En hashkedjad granskningskedja som ingen kan ändra eller radera
• Policyer per jurisdiktion som styr vad en giltig underskrift kräver
• Signaturbegäranden som poster, med egen status och historik

Vem som var behörig att skriva under för en motpart, och om deras behörighet fortfarande gäller – kontrollerat i stället för antaget.

• Behörighet att förplikta följs upp per undertecknare hos motparten
• Undertecknade avtal sparade som poster med en löptid
• Behandlares behörigheter påminns om innan de går ut

Vad en klinisk underskrift behöver utöver ett namn: beslutsförmåga, behörighet att skriva under för någon annans räkning, handledning och ett samtycke som kan återkallas.

• Intygande av beslutsförmåga registrerat i ögonblicket för underskriften
• Underskrift för en klients räkning, med behörigheten registrerad
• Handledarens medunderskrift där tjänsten kräver det
• En livscykel för samtycke som kan återkallas i stället för en engångsbock

De delar HIPAA kräver av ett tillstånd, validerade i stället för överlåtna åt en mall.

• Validering av de obligatoriska delarna i ett HIPAA-tillstånd
• Material enligt 42 CFR Part 2 hållet åtskilt från resten
• Redovisningen av utlämnanden som en covered entity måste ta fram på begäran

En åtgärd Begär underskrift på sökande och anställda, så att ett erbjudande eller en riktlinje undertecknas där personen redan finns.

• Begär underskrift på en sökandes post
• Begär underskrift på en anställds post
• Begäranden sparade mot posten som dess historik

En åtgärd Begär underskrift på offerter och inköpsordrar.

• Begär underskrift på en försäljningsorder
• Begär underskrift på en inköpsorder
• Det undertecknade dokumentet sparat mot ordern

Placerar signaturmallar där mottagningen säljer: knutna till en behandlare eller en tjänst, skickade automatiskt vid köp och synliga som en status.

• E-signaturmallar knutna till en behandlare eller en tjänst
• Skickas vid köp, utan att någon behöver komma ihåg att skicka dem
• Signeringsstatus synlig för behandlare i portalen och i mobilappen

Avslutar en session som ingen använder. 45 CFR 164.312(a)(2)(iii) kräver att den avslutas efter en förutbestämd period av inaktivitet och överlåter perioden åt er – så det är en inställning, med upprätthållandet på servern snarare än i webbläsaren.

• Period för inaktivitet, varningstid och ett absolut tak, inställda per företag
• Kontrolleras på servern vid varje autentiserad förfrågan, så att stänga av webbläsarens timer ger ingenting
• En varning innan sessionen avslutas, så att ingen förlorar en halvskriven anteckning till en kontroll som är tänkt att skydda dem
• Ett absolut tak utöver det för inaktivitet, eftersom en session som hålls vid liv av ett skript fortfarande är en session som borde avslutas
• Varje avslut registreras – vem, vilken yta och vilken regel som avslutade den
• Posten har endast tillägg: belägg för att en kontroll fungerade är värt vad det kostar att ändra dem
• Sätt perioden till noll för att stänga av den, ett beslut som specifikationen tillåter och som er riskanalys registrerar

Kopplar Odoo Community till vilken stor språkmodell som helst, bakom ett gränssnitt – så att leverantören kan bytas utan att affärslogiken märker det.

• Leverantörer konfigurerade per driftsättning, med inloggningsuppgiften utanför applikationskoden
• Agenter definierade som prompter med de verktyg de får anropa
• Verktygsanrop, så att en modell kan agera och inte bara svara
• Körningar registreras, så att vad som frågades och vad som kom tillbaka går att granska efteråt
• Serveråtgärder som kan styras från en prompt
• Diagnostik för att kontrollera att en leverantör går att nå och är rätt konfigurerad

Att omvandla en användare mellan intern och portal för hand innebär att ändra behörigheter i rätt ordning och komma ihåg bieffekterna. Det här gör det till en knapp.

• Ett fält Användartyp i användarformuläret, listan och sökfiltren
• Knapparna Omvandla till intern och Omvandla till portal i användarformuläret
• En åtgärd Omvandla användartyp i användarlistan, för flera användare på en gång
• Skyddsräcken: systemanvändaren, din egen användare och den sista kvarvarande administratören kan aldrig omvandlas av misstag

Sidhuvud, sidfot och inloggningssidan på en enda layout, uppkallad efter bolaget i den här databasen.

• En layout för sidhuvudet, sidfoten och inloggningssidan
• Namnet som visas är bolaget i den här databasen, inte ett värde inskrivet i en mall
• Logotypens adress och en egen upphovsrättsrad är systemparametrar, redigerbara även under Inställningar → Webbplats → Publikt varumärke
• Länkarna i sidhuvudet kommer från den här webbplatsens huvudmeny och redigeras alltså där varje annan meny redigeras

Företag, användare, grupper, kontakter, språk och postreglerna som avgör vem som ser vad. Visas inte i applistan eftersom allt beror på den.

• Företag och avgränsning mellan flera företag
• Användare, grupper och åtkomstregler på postnivå
• Kontakter som en enda modell som delas av klienter, behandlare och leverantörer
• Språk, översättningar och språkinställning per användare
• Schemalagda åtgärder – jobbkön bakom varje nattlig uppgift

Backoffice-gränssnittet personalen arbetar i, och redigeringsverktygen bakom varje fält med formaterad text och varje webbplatsblock.

• Vyer för lista, formulär, kanban, kalender, pivot och diagram
• Filter, grupperingar och sparade sökningar på varje skärm
• Export till CSV och XLSX från vilken lista som helst
• HTML Editor – fältet för formaterad text som används i alla poster
• HTML Builder – blockredigeraren med dra och släpp
• Web Routing – URL-lagret som varje portal- och webbsida serveras genom

Odoo-apparWebWeb RoutingHTML EditorHTML Builder

Meddelanden, och meddelandetråden som hör till varje post – vilket är hur ett beslut behåller sin historik i stället för att leva i någons inkorg.

• Chatter på varje post: meddelanden, anteckningar, följare och spårade fältändringar
• Interna kanaler och direktmeddelanden
• Utgående e-post med mallar, och routning av inkommande
• Aktiviteter – en uppgift tilldelad mot en post i stället för åt någons minne
• OdooBot, och dess HR-variant för påminnelser vid introduktion

Odoo-apparDiscussOdooBotOdooBot - HR

Det inloggade området en klient, en behandlare eller en motpart når utan att vara intern användare – allt under /my.

• Portalanvändare utan åtkomst till backoffice
• Dokument, ordrar och fakturor delade med den person de tillhör
• Ramen som varje egen portalsida i den här plattformen är byggd inuti
• En anpassad registreringssida, så att registreringen följer varumärket snarare än Odoos standard

Odoo-apparCustomer PortalCustomize Signup Page

Adressboksapplikationen: personer, organisationer och relationerna mellan dem.

• Privatpersoner och företag, med underordnade kontakter
• Adresser, skatteidentifierare och bankuppgifter
• Etiketter och kategorier för segmentering
• Posten som en klient, en behandlare och en leverantör alla pekar på

Odoo-apparContacts

Det som säljs. På en mottagning är det samtal och paket, men modellen under är standardmodellen.

• Produktmallar och varianter
• Måttenheter, och tjänsteprodukter för tid
• Prislistor, så att ett paket eller ett segment kan prissättas annorlunda
• Produktkategorier för rapportering per tjänsteområde

Arbetskalendrar, kapacitet och ledighet – modellen som en behandlares veckotider och daterade undantag uttrycks i.

• Arbetsscheman per person, med tidszoner
• Resursernas kapacitet och ledigheter
• Kalendern som beläggningen beräknas mot

Odoo-apparResource

De små installerade modulerna som ingen öppnar med avsikt, som var och en tar bort en bestämd sorts supportärenden.

• Onboarding Toolbox – guidad uppsättning av en ny driftsättning
• Phone Numbers Validation – nummer normaliseras vid inmatning, så att sms faktiskt kommer fram
• Google reCAPTCHA – skydd mot skräp i öppna formulär
• Google Gmail – utgående e-post via ett Google-konto utan SMTP-lösenord

Odoo-apparOnboarding ToolboxPhone Numbers ValidationGoogle reCAPTCHA integrationGoogle Gmail

Offerter och försäljningsordrar – posten som varje köpt samtal hänger på, och den vänstra änden av betalningskedjan.

• Offerter, bekräftelse och försäljningsordrar
• Orderrader med de samtal eller paket som köpts
• Leverans- och faktureringsstatus per rad
• Offertmallar, för ett paket som säljs om och om igen
• Säljteam och rapporteringen som följer dem
• Ordern som ett köpt samtal, en faktura och en betalning alla spåras tillbaka till

Odoo-apparSales

Huvudboken. Fakturor, leverantörsfakturor, betalningar, moms och avstämning – där mottagningens bokföring faktiskt finns.

• Kundfakturor och kreditnotor, där utfärdade fakturor inte kan ändras
• Leverantörsfakturor – inklusive de som en utbetalning skapar för behandlare
• Betalningar, kontoutdrag och avstämning
• Moms, skattepositioner och kontoplan
• Journaler, verifikationer och verifikationskedjan bakom dem
• Balansräkning, resultaträkning, åldersfördelade kundfordringar och leverantörsskulder

Odoo-apparInvoicing

Kostnader och intäkter tillskrivna något annat än ett konto – ett projekt, ett tjänsteområde, en behandlare.

• Analytiska konton och fördelningar
• Kostnader och intäkter följda per projekt eller per tjänsteområde
• Dimensionen som marginalrapporteringen beräknas över

Ramverket betalsätten ansluts till, så att lägga till eller byta en leverantör är konfiguration snarare än utveckling.

• Betalleverantörer konfigurerade per företag
• Betaltoken, för ett sparat kort som en klient återanvänder
• Transaktioner med eget läge, avstämda mot fakturor
• Skarven som gatewayens flagga PAYMENTS sitter bakom

Tre leverantörer är påslagna: en riktig kortinlösare, en demo för utbildning och manuella sätt för pengar som kommer utanför en betalväg.

• Stripe – kort, plånböcker och sparade betalsätt
• Demo – en leverantör som beter sig som en riktig, för utbildning och övning
• Custom Payment Modes – banköverföring, kontanter och allt som stäms av för hand
• Sjutton leverantörer till följer med Odoo och är ett reglage bort

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

Rabatter, kampanjer, presentkort och lojalitetsprogram – tillämpade på en försäljningsorder och i e-handelns kassa lika.

• Kupongkoder och automatiska kampanjer
• Lojalitetskort och poängintjäning
• Presentkort och saldon i e-plånbok
• Programregler per produkt, tjänsteområde eller kundsegment

Odoo-apparCoupons & LoyaltySale LoyaltySale Loyalty - Delivery

Det personalen spenderar, och den del som faktureras vidare till en klient i stället för att bäras.

• Utläggsanspråk, godkännande och ersättning
• Utlägg bokförda direkt i redovisningen
• Vidarefakturering av ett utlägg genom att ange försäljningsordern på det
• Kostnadssidan av ett levererat uppdrag

Odoo-apparExpensesSales Expense

Inköpsordrar och leverantörshantering – den bundna kostnadssidan, och hur leverantörsfakturor kommer in.

• Offertförfrågningar och inköpsordrar
• Leverantörsposter och prislistor
• Leverantörsfakturor matchade mot ordrar
• Ordern som en underskrift kan begäras på

Odoo-apparPurchase

Leads och affärsmöjligheter – använda här för förfrågningar som ännu inte är klienter, och för konsultationsförfrågningar som kommer från appen.

• Leads, affärsmöjligheter och en konfigurerbar pipeline
• Aktiviteter och nästa steg för varje affärsmöjlighet
• Förlustorsaker och rapportering av vinstandel
• Modellen som säkra dokument kan arkiveras mot för ett due diligence-paket

Odoo-apparCRM

Att fylla i det en lead inte berättade, hitta leads som aldrig tog kontakt och ge ett säljteam något att tävla om.

• Lead Enrichment – företagsuppgifter kompletteras automatiskt från en e-postdomän
• Lead Generation – leads hämtade efter bransch, storlek och plats
• CRM Gamification – mål, märken och topplistor på pipelinen

Odoo-apparLead EnrichmentLead GenerationCRM Gamification

En chattwidget på den öppna webbplatsen, bemannad av riktiga människor, och kopplad till både pipelinen och HR:s interna helpdesk.

• Live Chat – operatörer, kanaler och färdiga svar
• Website Live Chat – widgeten på den öppna webbplatsen och i katalogen
• CRM Livechat – ett samtal omvandlat till en lead utan att något behöver skrivas om
• HR - Livechat – samma kanal använd internt för personalens frågor
• Utskrifter sparade mot besökaren och, när den är känd, mot kontakten

Odoo-apparLive ChatWebsite Live ChatCRM LivechatHR - Livechat

Kanalen med högst öppningsgrad, kopplad på de ställen där en mottagning faktiskt behöver den. Påminnelser om samtal använder den redan.

• SMS gateway – infrastrukturen för utskick och leveransstatus
• SMS in CRM – skicka sms till en lead från affärsmöjligheten
• Send SMS to Visitor – och varianten som fungerar från en lead
• Recruitment - SMS – skicka sms till en sökande om en intervju
• Spärr per person, så att ett avregistrerande respekteras överallt

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

Ett eget tillägg på leads och kontakter: skicka ett fördefinierat WhatsApp-meddelande utan att lämna posten.

• Snabbutskick från en lead och från en kontakt
• Fördefinierade meddelandemallar
• Kanalen många klienter på den här marknaden faktiskt läser

Odoo-apparCRM Extension v2 - WhatsApp Quick Send

Periodiska siffror skickade till dem som borde se dem, och tillskrivning för varje länk verksamheten publicerar.

• KPI Digests – en schemalagd sammanfattning mejlad till chefer
• Link Tracker – korta länkar med UTM-taggar och klickstatistik
• Kampanj, medium och källa registrerade mot besökaren som konverterade

Odoo-apparKPI DigestsLink Tracker

Sidbyggaren bakom den öppna webbplatsen – sidorna marknadsföringen ändrar utan en utvecklare.

• Sidor med dra och släpp och återanvändbara block
• Flerspråkiga sidor och SEO-metadata
• Menyer, teman och versionshantering av sidor
• Den öppna katalogen och behandlarnas profilsidor

Odoo-apparWebsite

Att sälja på den öppna webbplatsen: katalogen, varukorgen och kassan en klient går igenom innan de ens har ett köpt samtal.

• Öppen produktkatalog och produktsidor
• Varukorg, kassa och betalning på webbplatsen
• Kundkonton och orderhistorik
• Spärrarna i varukorgen som stoppar ett köp som inte går att boka

Odoo-appareCommerce

Publiceringssidan: artiklarna som visas i appens innehållsflöde och på den öppna webbplatsen.

• Bloggar, inlägg, etiketter och kommentarer
• Flerspråkiga inlägg
• Källan som det rangordnade innehållsflödet läser från

Odoo-apparBlog

De tre ställen där en besökare kan skapa en post utan konto – vart och ett landar där en person faktiskt arbetar.

• Contact Form – en förfrågan som kommer som en lead, inte som ett mejl
• Online Task Submission – ett webbformulär som skapar en projektuppgift
• Online Jobs – lediga tjänster publicerade, och ansökningar som kommer in i Recruitment

Odoo-apparContact FormOnline Task SubmissionOnline Jobs

Tre små moduler som kopplar den öppna webbplatsen till resten av systemet. Ingen öppnar dem; allt går sönder utan dem.

• Website Mail – prenumerationer och meddelandetrådar på öppna sidor
• Website Partner – en öppen sida för en kontakt, vilket är vad en behandlarprofil är
• Website Payment – betalning på webbplatsen kopplad till betalramverket

Odoo-apparWebsite MailWebsite PartnerWebsite Payment

Personalposter och avtal. I Odoo 19 är ett avtal en version av den anställda, och den versionstidslinjen är det som bär en behandlares ersättningsvillkor.

• Personalposter, avdelningar och befattningar
• Avtalsversioner med daterad historik, en gällande åt gången
• Arbetsschema per anställd
• Posten som behandlarnas ersättningsvillkor och utbetalningar bygger på

Odoo-apparEmployees

Vad varje behandlare är kvalificerad att göra, när den kvalifikationen går ut, och vem som rapporterar till vem.

• Skills Management – kompetenser, nivåer och utveckling per anställd
• Skills Certification – certifikat med utgångsdatum, vilket är det som gör en behörighet möjlig att påminna om
• HR Org Chart – rapporteringsvägar på personalposten
• HR Gamification – interna mål och märken

Odoo-apparSkills ManagementSkills CertificationHR Org ChartHR Gamification

Sökande och anställning – och skälet till att ett erbjudande är ett av dokumenten e-signaturstacken ombeds hantera.

• Befattningar, sökande och en rekryteringspipeline
• Schemaläggning av intervjuer och bedömningsmallar
• Kompetenser matchade mot rollens krav
• Den sökandes post, som en underskrift kan begäras från

Odoo-apparRecruitmentRecruitment - Skills Management

Varifrån varje person arbetar en viss dag – vilket för en mottagning innebär att veta vem som är på plats för att ta emot en klient.

• Hemma- och kontorsdagar per anställd
• Samma information visad i teamkalendern
• Synligt bredvid rumskalendern när samtal på plats planeras

Odoo-apparRemote WorkRemote Work with calendar

Projekt och uppgifter. Används för leveransarbete och, i avtalsvertikalen, för att hålla kostnaden för att vinna ett avtal skild från kostnaden för att leverera enligt det.

• Projekt, uppgifter och etapper
• Tilldelning, frister och framsteg
• Arkivering av dokument per uppgift, inklusive säkra dokument
• Projektet som avtalets kostnad och marginal rapporteras mot

Odoo-apparProject

En personlig uppgiftslista per användare, skild från projektarbetet – där de små saker en chef plockar upp under morgonrutinen hamnar.

• Privata uppgifter med förfallodatum
• Kan omvandlas till en projektuppgift när det visar sig vara verkligt arbete

Odoo-apparTo-Do

Möten och händelser. Varje samtal är en kalenderhändelse under ytan, vilket är det som gör rums- och teamkalendrarna verkliga snarare än en återgivning.

• Händelser med deltagare, upprepning och påminnelser
• Tillgänglighet synlig i ett helt team
• Synkronisering med externa kalendrar
• Händelsen som ett bokat samtal är knutet till

Odoo-apparCalendar

Frågeformulär. Används här för intagsfrågor vid bokning och för den privata enkäten om återkoppling efter ett samtal.

• Frågeformulär med villkorade frågor
• Svar sparade mot den person som svarade
• Poängsättning, där ett frågeformulär är en bedömning
• Intagsfrågorna som hör till en bokningsbar tjänst

Odoo-apparSurveys

Tid registrerad mot ett projekt eller en uppgift. Tillgänglig och avslagen i referensdriftsättningen – den är ett beroende för avtalsvertikalen snarare än för mottagningsarbetet.

• Tidsposter mot projekt och uppgifter
• Kostnad per timme från personalposten
• Godkännande och rapportering av tidrapporter
• Timmarna som avtalsfaktureringen gör om till siffror för täckning och beläggning

En utbildningsdel: betalda eller gratis evenemang, onlinekurser och ett öppet forum – allt sålt genom samma varukorg och rapporterat i samma bokföring.

• Evenemang med anmälan, biljetter, spår och utställare
• Evenemang sålda som produkter genom den befintliga kassan
• Livespår och quiz för onlinesessioner
• Kurser i e-lärande, med kompetenser som erhålls när de slutförs
• Ett öppet forum, och evenemang kopplade till CRM-pipelinen

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

Kampanjer till listor verksamheten redan har. Mottagningen skickar transaktionella mejl och sms i dag; det här är marknadsföringshalvan av samma infrastruktur.

• Email Marketing – kampanjer, mallar, A/B-tester och statistik
• SMS Marketing – detsamma, i kanalen med högst öppningsgrad
• Massutskick riktade till leads, affärsmöjligheter, deltagare eller talare vid evenemang
• Marketing Card – personliga delningsbilder för en kampanj
• Knappar för att prenumerera på nyhetsbrev på webbplatsen, via e-post eller sms

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

För en mottagning som också säljer något fysiskt över disk – böcker, kosttillskott, testkit – eller har en kassa i receptionen.

• Inventory – lager, platser, påfyllning och värdering
• Point of Sale – en kassa som fungerar offline och synkroniserar
• Rabatter i kassan, och de lojalitetsprogram som redan är konfigurerade

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

Personaladministrationens sida. Relevant när en mottagning har så många anställda att ledighet och närvaro inte längre ryms i en delad kalender.

• Time Off – ansökningar, godkännande, saldon och effekten på lönebesked
• Attendances – in- och utstämpling, med närvarokontroll
• Närvarorapportering vid sidan av tidrapporter
• Timlön per anställd, för att räkna fram kostnaden för levererade timmar
• Fordonsflotta och fordonshistorik, där fordon tillhandahålls
• Lunch – appen för att beställa från personalmatsalen

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

Stripe är påslaget. Vilken som helst av dessa kan läggas till eller bytas in som konfiguration – vilket är det som gör inträde på en ny marknad till en ändring av inställningar snarare än ett projekt.

• Europa – Mollie, Buckaroo, Worldline, Redsys, Adyen
• Nord- och Sydamerika – Authorize.Net, Mercado Pago, PayPal, Nuvei
• Mellanöstern och Afrika – Amazon Payment Services, Paymob, DPO, Flutterwave
• Asien – AsiaPay, Razorpay, Xendit
• Turkiet – Iyzico

Odoo-apparPayment 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

Valfria externa tjänster. Alla är avslagna som standard, med avsikt: var och en skickar något utanför systemet, och det ska vara ett beslut snarare än ett standardval.

• Google Calendar – tvåvägssynkronisering av personalens kalendrar
• Google Maps och autokomplettering av platser på webbplatsen
• Google Address Autocomplete i kontaktformulär
• Google Users – inloggning med ett Google Workspace-konto
• Molnlagring hos Azure eller Google, för bilagor i stor skala

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

Småsaker som var och en löser ett smalt problem. Listade för fullständighetens skull snarare än för att en mottagning behöver dem första dagen.

• E-posttillägg för Outlook och Gmail, i CRM och i Project
• Mail Group – en diskussion i stil med en e-postlista, med ett arkiv på webbplatsen
• Data Recycle – hittar dubbletter och inaktuella poster
• Website profile – en öppen sida för en portalanvändare
• Intervjuformulär i Recruitment, och rapportering av marginal på försäljningsutlägg
• En telefonintegration för CRM (Issabel)

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

Avtalet, dess parter, dess strukturerade villkor med ursprung, dess versioner och ett arbetsflöde med konfigurerbara etapper kopplade till fem fasta faser.

• Avtal med parter, strukturerade villkor och villkorens ursprung
• Versioner, så att ”vad stod det i mars?” fortfarande går att besvara
• Konfigurerbara etapper kopplade till fem fasta faser
• Inget branschspecifikt ordförråd och inget beroende av e-signatur, krypterad lagring eller projekt
• Branscher kommer som paket med konfiguration snarare än som förgreningar av koden

Byggt så att granskningen riktas mot det som ändrats och det som avviker, och aldrig mot oförändrad standardtext – vilket är där avtalssystem oftast överges.

• Ett klausulbibliotek kopplat till strukturerade villkor, så att accepterad reservformulering sätter villkoret den bär
• Förhandlingsmanualer, rundor, frågor och registrerade avvikelser
• Möten som förhandlingsrundor i sig, med resonemanget och positionerna bevarade
• Ett mötesutfall skapar föreslagna ändringar och ändrar aldrig avtalet av sig självt
• En logg som knyter ihop varje etapp från begäran till undertecknande, med varje lucka synlig

Godkännande som avgörs längs mer än en axel. Att behandla det bara som hierarki är det vanliga designfelet: ett standardsekretessavtal behöver ingen i hög position, vilket värde det än har.

• Godkännande efter värde, avvikelse, avtalstyp och risk
• Avvikelse som en egen axel snarare än en justering av värdet
• Godkännande av en ersättare registreras alltid som sådant – ”för räkning av” är ett annat faktum
• Fungerar på Odoo Community, där appen Approvals inte finns

Registrerar vad en ändring ändrade, inte bara att den finns.

• Att genomföra en ändring stänger de villkorsrader den ändrar och öppnar nya från ikraftträdandet
• Allt som härleds ur ett ändrat villkor räknas om, och förändringen visas före genomförandet
• Motstridiga ändringar upptäcks vid genomförandet
• Ett avstående som upphört återupplivar det villkor som gällde när det upphörde, inte det ursprungliga

Underskriften är början på åtagandet, inte slutet på ett arbetsflöde. Det här bär det som händer efteråt.

• Åtaganden i båda riktningarna, med underlag där underlag krävs
• Härledda datum beräknade från villkor snarare än inskrivna, och flyttade när villkoren de bygger på flyttas
• En eskaleringstrappa som inte förlitar sig på att påminna den som redan låtit bli att agera
• Beslutet om förlängning presenterat tillsammans med de åtaganden motparten har missat

Två kostnader, hållna isär: vad ett avtal kostade att vinna, och vad det kostar att leverera. Att slå ihop dem ger en siffra som besvarar ingen av frågorna.

• Förhandlingsarbete registrerat som omkostnad, oavsett om avtalet undertecknas
• Leveranskostnad täckt mot avtalets värde
• Avtal kopplade till projekt i många-till-många med en roll, eftersom ett enda projektfält går sönder vid första ramavtalet
• Ett undertecknat leverantörsavtal är bunden kostnad från undertecknandet, inte från dess första faktura

Vad en timme är värd, vad arvodet tillåter och de fyra siffror som behöver båda.

• Timpriser, en markering för debiterbar och ett fakturerat läge på registrerad tid
• Arvodesgrunder angivna i avtalet
• Täckning – fakturerat mot värdet av registrerad tid
• Beläggning – debiterbara timmar mot tillgängliga timmar, från personens egen arbetskalender
• Bundet kapital – ofakturerat arbete plus obetalda fakturor, och hur många dagars fakturering det motsvarar
• En varning för takpris som styrs av prognostiserad kostnad, eftersom en som slår till vid taket slår till för sent

Den fjärde kanalen för utbyte: motparten läser den aktuella versionen här, kommenterar och laddar upp sina ändringsförslag som en inkommande runda.

• Motparten öppnar den aktuella versionen, kommenterar den och skickar tillbaka sina ändringsförslag
• Ändringsförslagen kommer som en inkommande runda med filen bifogad, inte som ett mejl som någon måste komma ihåg att arkivera
• Inget internt syns – inte positioner, avvikelser, godkännanden, förhandlingsmanualen eller interna anteckningar
• Valfritt, eftersom en design som förutsätter att motparten använder vår portal faller vid första stora kunden

Hur ett avtal använder signaturtjänsten. Slutförandet är händelsen som sätter igång allt annat.

• Godkännandena måste vara klara innan en version kan skickas
• Undertecknarens behörighet att förplikta kontrolleras mot deras behörighetsbevis
• Versionen låses när den skickas, så att varje senare påstående om vad som undertecknades går att bevisa
• Vid slutförande genomförs versionen, avtalet går vidare, villkoren aktiveras och de härledda datumen följer
• Att avinstallera lämnar ett fungerande system – underskrifter på papper registreras med en metod och ser kompletta ut

Att kryptera varje avtal gör systemet oanvändbart; att inte kryptera något gör det osäkert. Därför är konfidentialitet en nivå på avtalet.

• Bara avtal markerade som säkra skickar sina dokument till tjänsten för säkra dokument
• Kryptering per version under en nyckel som förvaras utanför databasen
• Åtkomst nekad som standard, och varje läsning loggas innan innehållet returneras
• Gallring genom att nyckeln förstörs
• Säger i ögonblicket för ändringen att en uppgradering till säker inte ogör att något sparats okrypterat

Avvikelselistor som borde vara tomma, och de ledningsvyer som är värda att diskutera.

• En avvikelselista innehåller bara det som avviker – en tom lista är det goda utfallet
• En avvikelse vars modell inte är installerad rapporteras som ej tillämplig i stället för att misslyckas
• Obegränsat ansvar visas som en lista, aldrig som en siffra som adderas till en summa
• Ledtiden uppdelad per part, eftersom dagar då motparten hade utkastet inte är avtalsteamets prestation
• Beror bara på kärnan, och att ta bort den lämnar ett fungerande system

Tre läsare, en aritmetik. Samma siffror beräknade en gång och återgivna på tre sätt, snarare än härledda på nytt per skärm där de skulle glida isär.

• En enda vy över frister: härledda avtalsdatum, åtaganden åt båda hållen, åtgärder beslutade på möten och leveransfrister
• Projektstyrning: intäkter, arbete, bunden kostnad, marginal och avvikelse mot uppskattning, som en sparad vy så att den kan grupperas
• En vy för klienten över hur långt arbetet kommit och vad som är skyldigt
• En vy för juristen över vad som ligger på dem den här veckan och om de håller sig inom uppskattningen

Två regler, och bara två – de som jämför poster och därför inte kan uttryckas som konfiguration.

• En underlicens territorium måste ligga inom huvudlicensens
• Två exklusiva licenser får inte överlappa
• Hållen separat från paketet för immateriella rättigheter, så att en verksamhet kan installera avtalstyperna utan kontrollerna
• Dess storlek är ett medvetet mått på hur väl basens tilläggspunkter fungerar

Jävskontroll vid inkommande avtal, på samma sätt som när ett ärende öppnas. Den spärrar övergången till nästa etapp; den varnar inte bara.

• En motpart kontrollerad mot befintliga klienter, motparter i pågående ärenden och kända närstående bolag
• Spärrar övergången till nästa etapp i stället för att visa en varning som kan avfärdas
• Själva kontrollen kan inte ändras när den väl registrerats – vem som körde den, över vilket omfång och vad de fann

Startpaketet. Installera kärnan och det här, så kan en verksamhet hantera avtal från första dagen utan att konfigurera något.

• Sekretessavtal, ramavtal, uppdragsbeskrivningar, tjänster, konsultuppdrag, leverans och inköp
• Villkoren varje typ bär och arbetsflödet den går igenom
• Spärrar som stoppar ett avtal från att nå underskrift halvfärdigt
• Ingen Python – och specialiserade paket bygger på det här i stället för att deklarera om det alla behöver

Anställning, anlitande av uppdragstagare, konsultuppdrag och överenskommelser vid avslut.

• Avtalstyper, villkorstyper, klausulbibliotek och förhandlingsmanual för anställningsavtal
• Mallar för åtaganden för uppsägningstid, provanställning och villkor efter anställningens slut
• Överenskommelser vid avslut är säkra som standard – varje ord spelar roll, och en tillsynsmyndighet frågar senare om dem
• Bara data, och ingen regelmodul

Advokatbyråer – avtal för klienter och med dem – och interna juridiska avdelningar. Samma system tjänar båda uppgifterna med tydligt olika standardval.

• Uppdragsbrev, förskottsavtal och instruktioner till ombud
• Ett klausulbibliotek med den reglerade formuleringen markerad som obligatorisk
• En byrås uppdragsbrev är konfidentiellt och specificerat som standard
• Avtal om villkorat arvode har en formulering som inte kan tas bort
• Jävskontrollen finns i contract_legal_rules, eftersom den jämför parter mellan ärenden

Licensgivare, innehavare av patent och varumärken, tekniköverföringskontor, universitet och varumärkesägare.

• Licenser, överlåtelser och optioner som avtalstyper, med villkorstyper för licenser
• Klausulbibliotek, förhandlingsmanual och mallar för åtaganden
• Inget register över tillgångar, med avsikt – ett patents handläggningshistorik hör till det portföljsystem som redan håller den
• De två regler ett paket inte kan uttrycka finns i den valfria contract_ip_rules

Hyresavtal, föravtal om hyra, nyttjanderätter, försäljningar, servitut och de handlingar som hänger på ett hyresavtal.

• Brytdatum som villkor som styr datum, eftersom en bryträtt löper ut i tysthet
• Uppsägningsfönstret som ett åtagande härlett från brytdatumet, och båda eskalerar
• Villkor om hyresjustering, driftkostnader och återställande
• Bara data, och ingen regelmodul

Skuldhandlingar: låneavtal, borgensåtaganden, säkerheter, borgenärsavtal och efterställningsavtal.

• Finansiella kovenanter som strukturerade villkor, med härledda testdatum
• Efterlevnadsintyget som ett åtagande där underlag krävs
• ”Vilka lån testas det här kvartalet, och mot vilka siffror?” blir en fråga med ett svar
• Det dokumenterar skulden; det redovisar den inte – saldon och upplupna poster stannar i redovisningen
• Bara data, och ingen regelmodul

Huvudentreprenader, underentreprenader, konsultuppdrag, säkerhetsgarantier och instrumenten runt dem.

• Byggt kring kedjan: ett huvudavtal lovar ett datum som bara underentreprenaderna kan leverera
• Motsvarande villkor hållna som strukturerade villkor så att de kan jämföras nedåt i kedjan
• Ansvar som underentreprenaderna och ansvarsförsäkringen måste bära
• Bara data, och ingen regelmodul

Personuppgiftsbiträdesavtal, business associate agreements och villkor för underbiträden.

• Avtalstyper för DPA, BAA och underbiträden med de villkor de bär
• Fönstret för anmälan av incidenter som ett eget villkor, eftersom det mäts i timmar
• Svar på revisioner och meddelande om underbiträden som härledda datum
• Bara data, och ingen regelmodul