150 pièces, et à quoi chacune sert.

Entrer dans l'application, et le contrôle d'âge qui décide si un compte peut être utilisé tout court.

• Écran d'accueil et aiguillage au premier lancement, pour qu'un utilisateur qui revient atterrisse là où il s'était arrêté
• Inscription et connexion auprès de la passerelle, avec les jetons tenus en stockage sécurisé
• Réinitialisation du mot de passe par courriel
• Le contrôle des 18 ans, présenté avant tout achat possible

La vérification qui permet à quelqu'un de faire des transactions, y compris les états dans lesquels une personne se trouve pendant qu'un humain revoit ce que l'étape automatique n'a pas pu trancher.

• Une introduction guidée expliquant ce qui est demandé et pourquoi
• Capture d'un scan facial, et vérification de document comme voie de rechange
• États de résultat limite et de revue en cours, pour que la personne ne reste jamais sans réponse
• Le statut de vérification se répercute sur ce que le compte a le droit de faire

Le premier onglet. Un fil classé d'articles, de vidéos et d'actualités, avec les éditeurs qui les publient.

• Un fil de contenus classé, servi par la passerelle
• Détail d'un contenu avec images et texte enrichi
• Profils d'éditeur, pour qu'un lecteur puisse suivre une source

Des outils en autonomie : des évaluations que la personne fait elle-même, leurs résultats, et les fonctions partenaires bâties autour.

• Faire une évaluation, et en lire les résultats
• La carte des délices — une vue personnelle, et une vue partagée
• Ajouter, rejoindre, inviter et comparer des partenaires
• Détail d'un partenaire, pour qu'une comparaison se lise plutôt qu'elle ne se note

L'annuaire tel qu'un client le rencontre : parcourir, comparer, enregistrer, demander, et la discussion qui suit.

• Parcourir et filtrer l'annuaire des praticiens
• Un profil avec qualifications, langues, services et avis
• Praticiens enregistrés — Mes experts
• Discuter avec un praticien, et la liste de ces conversations
• Demandes de consultation, pour une question qui n'est pas encore une réservation

Ce qui peut réellement être réservé, avec le prix, la durée et le mode — en ligne ou sur place.

• Parcourir les services offerts par la clinique
• Détail d'un service avec prix, durée et mode de prestation
• Passer directement à la réservation ou à l'achat depuis le service

Acheter — une séance, un forfait ou un produit. C'est d'ici que vient le crédit qu'un client dépense ensuite.

• Catalogue de produits et détail d'un produit
• Panier, paiement et contrat de service accepté à l'achat
• Confirmation de commande, et l'historique des commandes derrière
• Paiement traité par la passerelle, jamais par l'application

Dépenser un crédit sur une heure précise dans un agenda précis — et tout ce que le client en voit ensuite.

• Créer une réservation sur des disponibilités réelles, dans le fuseau horaire du client
• La liste des réservations, avec chaque statut qu'une séance peut avoir
• Détail d'une réservation : lien de connexion, lieu et salle, report et annulation
• Séances achetées — crédits détenus, dépensés, et encore à réserver

Demander en public, demander en privé, et les personnes avec qui un client choisit de partager ses progrès.

• Un fil de questions publiques, et poser une question avant de s'engager
• Détail d'une question avec la réponse du praticien
• Tickets d'assistance — en ouvrir un, le suivre, lire les réponses
• Invitations de partenaires et liste des partenaires

Le troisième onglet, et la réponse à la plupart des questions d'assistance. Tout ce que l'application sait de la personne, sur un seul écran.

• Rendez-vous réservés et historique, avec retours et avis de séance
• Crédits, séances achetées et favoris
• Adresse de facturation, factures, détail d'une facture, moyens de paiement
• Notifications, discussions avec les praticiens, discussions de partenaires et questions posées
• Mes services et mes contenus, pour qui publie
• Modifier son profil, changer son mot de passe, et les écrans de compte

Le même onglet, vu par un praticien. C'est ce qui rend tout un cabinet pilotable depuis un téléphone plutôt que depuis un bureau.

• Disponibilités : horaires hebdomadaires, et exceptions datées
• Discussions des clients, et l'historique du client derrière chaque conversation
• Déposer un compte rendu de séance depuis la séance à laquelle il appartient
• Analyses du praticien — l'entonnoir de réservation, le délai de prise et les chiffres par client
• Revenus et les quatre postes, masqués et remplacés par des compteurs sur un contrat salarié

Un assistant conversationnel dans l'application, diffusé par la passerelle, de sorte qu'aucun identifiant de modèle n'atteint jamais l'appareil.

• Un écran de discussion avec des réponses diffusées en continu
• Historique des conversations, pour reprendre un fil plus tard
• Acheminé par l'interface IA de la passerelle, qui se résout en un vrai fournisseur ou en une simulation

Les commandes qu'une personne s'attend à trouver, y compris celles qu'un régulateur s'attend à ce qu'elle puisse trouver.

• Réglages de l'application et choix de la langue parmi 23 locales
• Réglages de vie privée, et quelles notifications arrivent sur quel canal
• Réglages de sécurité, y compris les sessions d'appareil
• Conditions, politique de confidentialité et documents juridiques dans l'application plutôt que sur un site
• Suppression du compte, comme une voie que la personne peut emprunter elle-même

Ce sur quoi chaque fonction ci-dessus repose. Pas un écran, mais la raison pour laquelle les écrans se comportent de la même façon.

• Réseau vers la passerelle, avec renouvellement des jetons et gestion des erreurs au même endroit
• Stockage sécurisé des jetons et de l'état sécurisé de l'appareil
• Routage, pour qu'une notification ouvre exactement l'écran auquel elle renvoie
• Un thème unique portant le système de design 7DaysCare
• 23 fichiers de traduction, le système de calendrier suivant la personne et non l'entreprise
• Des composants partagés, pour qu'une liste, un état vide et une erreur se ressemblent partout

Intermédiaire de connexion vers le noyau d'affaires ; émet ses propres jetons de courte durée. L'application ne détient jamais un identifiant du noyau.

• Connexion, inscription, renouvellement et déconnexion, avec un JWT émis par la passerelle
• L'utilisateur courant et son profil
• Enregistrement de l'appareil, pour que les notifications poussées atteignent le bon téléphone
• Documents juridiques et l'acceptation consignée au regard d'une personne

Tout ce qu'un client parcourt avant de dépenser quoi que ce soit, servi vite et mis en cache là où c'est coûteux.

• Praticiens, leurs profils, leurs disponibilités et leurs services
• Catégories de services et produits réservables
• Avis et notes, avec l'état de modération respecté
• Lectures mises en cache pour tout ce que l'annuaire sollicite de façon répétée

La moitié transactionnelle. Achat, crédit, réservation, facture et paiement, chacun projeté sur le noyau d'affaires plutôt que réimplémenté.

• Créer, reporter et annuler une réservation, la politique étant appliquée par le noyau
• Commandes et les crédits qu'elles produisent
• Factures et documents de facture
• Initiation et confirmation du paiement, derrière une interface de paiements

La moitié tournée vers la lecture : ce qu'une personne parcourt quand elle ne réserve pas.

• Le fil de contenus classé et le détail d'un contenu
• Questions et réponses publiques
• Découverte, auto-évaluations et leurs résultats
• Fonctions partenaires et les comparaisons bâties dessus

Le concentrateur WebSocket. Discussion, présence, diffusion IA et signalisation pour la voix et la vidéo, sur une seule connexion.

• Gestion de la connexion WebSocket et présence
• Discussion entre client et praticien, et canaux de groupe
• Signalisation pour les appels voix et vidéo
• Acheminement des notifications et réglages de notification par personne
• Notifications poussées par Firebase Cloud Messaging

Des fichiers, tenus de sorte que l'application ne parle jamais directement au stockage et que rien n'est servi depuis une URL devinable.

• Accès sécurisé aux documents, en respectant les règles d'accès du noyau plutôt qu'en les rejugeant
• Téléversement et récupération de médias, passés par la passerelle
• Images redimensionnées et mises en cache, pour qu'une liste d'annuaire coûte peu sur un téléphone

Le reste : ouvrir un ticket, demander une consultation, dire à l'application ce que ce déploiement a activé, et parler à un modèle.

• Tickets d'assistance et leurs réponses
• Demandes de consultation
• Configuration à l'exécution, pour que l'application n'affiche que les fonctions activées par cette entreprise
• Requêtes IA, diffusées en continu, l'identifiant du modèle étant tenu ici et nulle part ailleurs

Quatre interrupteurs, chacun se résolvant en un vrai fournisseur ou en une simulation. C'est pourquoi le parc peut être démontré, développé et testé sans aucun compte externe.

• DATA_SOURCE — le noyau d'affaires Odoo, ou un jeu de données simulé
• PAYMENTS — un vrai fournisseur, ou une simulation qui se comporte comme lui
• NOTIFICATIONS — Firebase Cloud Messaging, ou une simulation
• AI — un vrai fournisseur de modèle, ou une simulation
• Limitation de débit et seaux à jetons dans Redis, pour qu'une limite tienne sur tous les processus
• Aucun fournisseur externe ne peut à lui seul empêcher la clinique de vendre, de délivrer et de consigner une séance

Le moteur de planification sous tout le reste — agendas, disponibilités, salles et les règles qui décident quels créneaux un client a le droit de voir.

• Un moteur de disponibilités qui résout horaires hebdomadaires, exceptions datées et réservations existantes en créneaux libres
• Planificateurs, hôtes, lieux et salles, avec capacité et détection des conflits
• Règles de créneaux, listes d'attente et offres automatiques de créneau quand une réservation se libère
• Questions d'admission posées au moment de la réservation, les réponses restant sur la réservation
• Rappels par courriel et SMS, avec des listes de suppression par personne
• Publication d'agenda en ICS, et liens vers les systèmes d'agenda externes
• Registres de présence, un entonnoir de réservation et les analyses derrière les chiffres par praticien
• Limitation de débit sur les routes de réservation publiques, et une voie d'effacement des données de réservation

Vend des séances individuelles sous forme de crédits. C'est le module qui fait de l'achat et de la réservation deux étapes distinctes, ce qui permet de vendre un forfait aujourd'hui et de l'étaler sur des mois.

• Des séances vendues comme crédits sur un produit, à l'unité ou en forfait
• Contrats de service de forfait acceptés à l'achat et conservés dans la version acceptée
• Politiques d'annulation par paliers avec délais de préavis, pénalités et délai de grâce
• Flux de report et d'annulation qui rendent le crédit là où la politique le dit
• Les postes du praticien — acheté, réservé, retenu, non réservé — et la progression par praticien
• Liens de réservation du portail, et garde-fous du panier qui bloquent un achat non réservable
• Une couture de résolution de paie : la séance fige sa propre répartition à la réservation sans savoir ce qu'est un contrat
• Retours après séance, et la trace des absences dont le rapport de fiabilité a besoin

La couche applicative : les praticiens et leurs profils publics, l'API mobile, les contenus et la communauté, les notifications, et le compte côté client.

• Profils de praticien avec un flux de vérification, titres, services et agendas
• Avis, notes, questions publiques et le tableau de bord du praticien derrière
• Points d'accès REST pour l'application mobile, authentification JWT et sessions WebSocket
• Discussion en temps réel — client vers praticien, discussions de partenaires et canaux de groupe — reliée aux sessions
• Contenus et publication : profils d'éditeur, un fil classé et la découverte
• Factures, moyens de paiement et le pont de la commande à la séance
• Notifications en poussé, par courriel et dans l'application, avec une diffusion pour les alarmes de séance
• Vérification d'âge et d'identité, tickets d'assistance, demandes de consultation et enregistrement d'appareil

Applications OdooClinic

Les dix-sept rapports de gestion. Douze demandent si le registre de la clinique correspond à ce qui s'est passé ; quatre comparent la tenue des praticiens ; un domine tous les autres.

• Listes d'alignement : séances bloquées, crédits non réservés, couverture face à la demande, chaîne de l'argent, grand livre des honoraires
• Préparation des versements, conduite d'annulation, dossier de conformité, continuité des clients et file de modération
• Séances sans compte rendu, et séances annulées lues à côté de la conduite
• Performance : la fiche de praticien, le classement, la fiabilité et les résultats clients
• Un seul réglage de périmètre — toute l'activité, des personnes choisies, une personne — avec une période de comparaison
• Vues enregistrées et export CSV sur chaque rapport
• Un rapport n'écrit jamais : le désinstaller retire les rapports et ne change aucun comportement opérationnel

La note clinique qu'un praticien dépose après une séance tenue — stockée comme document sécurisé concernant le client plutôt que comme pièce jointe à un rendez-vous.

• Un compte rendu déposé sur la séance et consigné comme portant sur le client
• Chiffré au repos sur le service de documents sécurisés, avec une clé par version
• Accès décidé uniquement par la résolution de l'équipe de soins, jamais par un rôle ni par l'ancienneté
• Corrections déposées comme nouvelles versions ; la version précédente reste exactement telle quelle
• Chaque lecture journalisée, de sorte que relancer un compte rendu manquant ne veut jamais dire en lire un

Un arrangement permanent plutôt qu'un achat à chaque fois : une formule vendue en boutique, et l'abonnement d'un client à cette formule.

• Les formules sont des produits de la boutique avec image et description ; le catalogue public est à /memberships
• Un abonnement porte des crédits de séance, l'accès à la discussion et des minutes de consultation hors ligne
• Les crédits restent des crédits de séance ordinaires, de sorte que la réservation n'apprend jamais un second corpus de règles
• Des périodes avec renouvellement et report, ce qui se reporte étant décidé par la formule
• Un praticien voit lesquels de ses clients sont abonnés, et à quoi

Du temps de praticien acheté en minutes plutôt qu'en rendez-vous, dépensé en discussion et comptabilisé à la minute.

• Un service peut vendre un budget de minutes de praticien, avec une fenêtre de validité facultative
• Grille tarifaire au niveau de la société, modifiable par service
• Une écriture de grand livre par imputation, et un relevé que le client comme le praticien peuvent ouvrir
• Le budget est vérifié là où le message est envoyé, pas là où quelqu'un pense à le vérifier

Le questionnaire qu'un client remplit avant la première séance, stocké comme contenu clinique plutôt que comme réponses d'enquête.

• Un service nomme le questionnaire qui l'accompagne
• Le client le remplit avant la séance, depuis ses propres pages
• Les réponses sont écrites directement dans un document chiffré — jamais laissées dans le stockage propre à l'enquête
• Le clinicien l'ouvre depuis la séance, sous les règles d'accès ordinaires aux documents

Le virement bancaire comme voie de paiement, pour les cliniques qui veulent qu'une personne examine chaque commande avant et après le mouvement d'argent.

• Approuver la commande, la facturer, recevoir la preuve du virement, approuver la preuve, puis émettre les crédits
• Les crédits n'apparaissent qu'une fois la preuve approuvée, de sorte qu'une commande impayée ne peut pas réserver une séance
• Un refus porte son motif, et la commande retourne à la personne qui peut y remédier
• Chaque étape est un état sur la commande plutôt qu'une note laissée par quelqu'un

La moitié côté client de la voie hors ligne : où il paie, ce qu'il téléverse, et ce que la commande attend.

• Chaque état a sa couleur et sa marque sur Mes commandes, de sorte qu'en attente se distingue visiblement de refusé
• Payer et téléverser la preuve dans une seule boîte de dialogue, sans quitter la commande
• Le motif du refus est montré là où la personne qui doit y remédier le lira
• Une tuile de tableau de bord pour les commandes qui attendent quelque chose du client

Les livres, sur un tableau de bord à part : ce qui est entré, ce qui est dû, ce que la prestation a coûté et ce qui reste à venir. Séparé de celui de l'administration à dessein — relancer une facture impayée est un métier, tenir le grand livre en est un autre.

• Une page d'accueil avec quatre tuiles d'argent, six ratios de santé, six graphiques et une liste d'alertes
• Vingt et un rapports : trésorerie, revenus, coût de prestation, prévision, fuites et deux listes de contrôle
• Comptabilité d'engagement ou de caisse, cinq périodes et une plage personnalisée, reprises dans chaque détail
• Restreindre n'importe quel rapport par service, praticien ou client ; une vue graphique et un CSV sur chaque page
• Rien de compensé, aucun taux sans dénominateur, des couches de prévision jamais additionnées
• Une liste de clôture de fin de mois où tout coché est la bonne clôture
• Lit le grand livre et jamais le contenu clinique — un droit distinct, sur un compte interne

Ce qu'il y a à faire, pour les quatre équipes autour de l'établissement. Commercial, ressources humaines, marketing et prestation ont chacun leur page, et chaque page ouvre sur la même question : qu'est-ce qui est en retard, qu'est-ce qui est maintenant, qu'est-ce qui vient, et sur quoi personne ne s'est engagé à agir.

• Quatre tableaux de bord, chacun un enregistrement plutôt que du code : un pack métier peut donc en ajouter un
• La bande d'activité sur chaque page : en retard · aujourd'hui · prévu · rien de planifié · demande attention
• « Rien de planifié » est la bande pour laquelle Odoo n'a aucun état : un enregistrement ouvert sur lequel personne ne s'est engagé, et qui n'apparaît sur aucun autre écran
• La règle d'attention est imprimée sous son propre compte, car un seuil que le lecteur ne voit pas est un seuil auquel il cesse de croire
• Vingt-six rapports, chacun portant le code de la ligne de spécification qu'il met en œuvre
• Un chiffre dont le modèle n'est pas installé indique « sans objet », jamais zéro
• Des listes qui devraient être vides, avec une alerte nocturne livrée désactivée
• Chaque taux imprime son dénominateur, et un tiret cadratin en dessous de cinq enregistrements
• Présences et absences du jour — encore pointé, pointé aujourd'hui, en congé aujourd'hui
• Ne dépend que de base, mail et web : il rend compte des données CRM, RH, mailing, projet et contrat sans exiger aucune d'entre elles

Où nous en sommes, dans l'application que les responsables ouvrent déjà. Quatre pages dans les tableaux de bord d'Odoo, dans une section « Équipes de la clinique », construites comme le sont ses pages Ventes et Notes de frais.

• Quatre pages — CRM, ventes, prestation, personnel — à côté de celles d'Odoo
• Quatre tuiles d'indicateurs par page, chacune avec la période précédente à côté
• Deux graphiques et deux à quatre tableaux de tête par page, chacun ouvrant les enregistrements derrière lui
• Un chiffre qui décrit un état du monde ne prend pas de période et n'affiche pas de comparaison : un effectif filtré sur quatre-vingt-dix jours n'est pas un effectif
• Un graphique groupé par une date prend la période ; un graphique groupé par une étape, non
• Les classeurs sont générés et leurs renvois validés avant que quoi que ce soit ne soit écrit
• Chaque page est visible du groupe Odoo propriétaire de ses données : rien de plus n'est accordé

Trois pages de plus dans la même section, tenues à part parce que chacune exige une application que l'établissement ne fait peut-être pas tourner.

• Présences : actuellement pointés, enregistrements, heures travaillées, heures supplémentaires, par personne et par département
• Congés : demandes sans réponse, jours approuvés, refus, et où tombent les absences par mois, type et département
• Paiements au personnel : à déclarer, à valider, à rembourser, et ce qui a été demandé sur la période
• Séparées des autres tableaux de bord parce que chacune force une application : présences, congés, notes de frais
• Les présences comptent des enregistrements, pas des personnes : une pause déjeuner fait de quelqu'un deux lignes, et la page le dit
• « Actuellement pointés » est un chiffre de présence pendant la journée de travail et, après, la liste des gens qui ont oublié de dépointer

Un formulaire public qui transforme une question en une tâche dont quelqu'un est responsable.

• Un formulaire à /support/ticket que tout le monde peut utiliser, connecté ou non
• Chaque envoi ouvre une tâche, attribuée à l'administrateur de la boutique
• L'auteur suit son propre ticket, et l'administrateur est prévenu dans Discuss

Un parcours de soins avec un début, une fin et un plan — la colonne vertébrale à laquelle tout le reste du dossier clinique se rattache. Les soins ne sont pas un flot de rendez-vous, et le dossier le dit.

• Un épisode s'ouvre à la première séance tenue, et un client en a un seul d'ouvert à la fois
• Un plan de traitement par épisode : problème → but → objectif, trois niveaux et pas plus
• Un but porte un titre, une date cible et un résultat — vers quoi on a travaillé, et comment cela s'est passé
• En cours ou Terminé comme état visible par le client, tenu à l'écart des six issues cliniques pour que les deux ne partagent jamais un écran
• Un plan est revu ou remplacé, jamais modifié sur place : la version convenue reste telle qu'elle était
• Clore un épisode demande une issue sur chaque but ouvert, parce que c'est le seul moment où quelqu'un connaît la réponse — et dit combien se clôtureraient sans
• La clôture démarre l'horloge de conservation à partir de laquelle le service de documents compte
• Chaque praticien qui a vu le client voit l'épisode ; lire le compte rendu d'un collègue est une demande distincte, approuvée par un administrateur de clinique et écrite au journal dans les deux cas
• Le client lit le même épisode sur ses propres pages, dans des mots qui ne le notent jamais

Des gabarits de note comme liste ordonnée de champs typés, de sorte qu'une note est faite de réponses plutôt que d'une prose que personne ne peut chercher.

• Un gabarit est une liste versionnée et publiée de champs typés — texte, nombre, échelle, choix, date
• Une note complétée, ce sont les réponses plus un document sécurisé rendu
• Les réponses sont lisibles exactement quand leur document l'est : une règle d'accès, pas deux qui divergent
• Visibilité par champ, de sorte qu'une observation privée est absente de la copie du client plutôt que cachée dedans
• Gabarits choisis sur le formulaire de compte rendu de séance, par discipline

Le contenu de départ du moteur de gabarits : un millier de formats de note nommés, pour qu'une clinique ne commence pas avec une bibliothèque vide.

• Plus d'un millier de gabarits nommés — SOAP, DAP, BIRP, admission, revue — groupés par discipline
• Installés comme données, modifiables ensuite comme tout gabarit que la clinique écrit elle-même

Ce qu'un client consigne entre les séances, rattaché au but qu'il mesure. Un programme qui ne rend compte de rien, c'est ainsi que le suivi devient un devoir scolaire.

• Une bibliothèque de programmes avec six sortes d'éléments : questionnaire, mesure, choix, journal, téléversement, tâche
• Un programme est envoyé à un but, de sorte que chaque saisie rend compte de quelque chose que le plan a vraiment demandé
• Le client consigne sur son propre plan : ce qui est dû aujourd'hui d'abord, puis chaque but et ce qui est ouvert dessus
• Rien sur une surface client ne le compte ni ne le note — une chose non consignée se lit comme non consignée, et il n'y a ni taux, ni score, ni série
• La charge de travail du clinicien, le pire d'abord : indicateurs de risque à accuser, jamais commencés, silencieux depuis quatorze jours, se terminant cette semaine
• Un taux portant sur moins de cinq éléments s'affiche comme un tiret, et un compteur en échec s'affiche comme indisponible — jamais comme zéro
• « Je trouve cela difficile », qui atteint le clinicien sans nombre attaché
• Des rapports déposés sur un but plutôt que sur un rendez-vous, chiffrés, sous les mêmes règles d'accès que tout autre rapport clinique
• Programmes revus en séance, comptés par le rapport de clinique qui demande si quelqu'un a regardé
• Chaque surface portant des observations dit que les saisies ne sont pas surveillées en temps réel

Des instruments cotés appartenant à la clinique. Aucun contenu d'instrument n'est livré et aucune licence n'est revendiquée : la clinique saisit ce qu'elle a le droit d'utiliser.

• Un score est enregistré avec la version d'instrument qui l'a produit, et n'est jamais recalculé
• Bandes et seuils par instrument, une bande de risque levant un indicateur que quelqu'un doit accuser
• Rempli par le client sur le portail ou en séance, le canal étant consigné dans les deux cas
• Des chronologies par instrument avec un sens d'évolution ; des scores d'instruments différents ne sont jamais combinés en un seul nombre, parce qu'ils mesurent des choses différentes sur des échelles différentes
• Un questionnaire est une sorte d'élément de programme, pas une fonction séparée avec sa propre liste

Une note écrite une fois et déposée auprès de chaque participant comme son propre document.

• Une source rédigée, un document déposé par client présent
• Un champ privé est absent du document d'un autre participant, pas caché dedans
• Déposé auprès des personnes présentes, pas de toutes celles qui étaient inscrites
• La séance ne compte comme documentée que lorsque chaque participant a sa copie

Une date d'échéance qu'un clinicien fixe à la fin d'une séance, traitée quand elle arrive.

• Un rappel, c'est une date et un motif, créés à la fin d'une séance
• Il invite ; il ne réserve jamais
• Les rappels échus apparaissent sur le récapitulatif de la clinique avant qu'aucun message ne parte automatiquement
• L'invitation automatique reste désactivée tant que la clinique ne l'active pas

Les codes de diagnostic là où la facturation en a besoin, cherchables plutôt que saisis de mémoire.

• Chapitres et codes CIM-10-CM cherchables
• Un code consigné sur le client et repris sur les commandes et les factures

Une seule liste de questions dans le produit, et les trois choses qu'elle n'apporte pas d'elle-même : une clé de réponse stable, une visibilité par question, et un marquage pour le seul chiffre autorisé à quitter le chiffré.

• Le produit avait fait pousser quatre constructeurs : les champs saisis du modèle de note, les questions propres à la prise de rendez-vous, les points de suivi, et le questionnaire derrière la fiche d'admission
• Quatre constructeurs, c'est quatre endroits où ajouter un type de question, quatre rendus, et quatre réponses à « où est passée cette réponse ? »
• Une liste de questions est rédigée dans survey.survey et nulle part ailleurs
• Aucune ligne de réponse d'enquête n'est jamais créée : ce magasin, ce sont des colonnes Postgres ordinaires — bonnes pour « comment la séance s'est-elle passée ? » et mauvaises pour un antécédent médical
• Les réponses d'un formulaire sécurisé n'existent qu'à l'intérieur d'un document chiffré, en version JSON et en version HTML
• La seule exception est un chiffre que l'auteur a marqué exploitable, parce qu'un graphique ne sait pas lire du chiffré
• Une question privée est absente du document partagé et classée dans le sien, au lieu d'être masquée sur un écran que quelqu'un peut modifier
• Dès qu'un formulaire a été rempli une fois, ses questions, ses options et les scores de ses options cessent de bouger
• Qui peut lire une fiche d'admission n'est pas qui peut lire une note structurée : les types de document appartiennent donc au module qui consomme le formulaire

Les questions d'un planning sont conçues dans l'enquête et classées chiffrées, pour que la prise de rendez-vous puisse rester une prise de rendez-vous.

• Un planning nomme une enquête, et la page de réservation publique la rend avec le rendu unique
• Les réponses sont classées dans un document chiffré rattaché à la réservation
• Le modèle de questions propre au planning reste, et c'est bien : un numéro de téléphone, une référence, une case de consentement, et celles qui écrivent directement sur la fiche contact là où un accueil doit les lire
• Ce pour quoi il avait la mauvaise forme, c'est un établissement qui demande « qu'est-ce qui vous amène aujourd'hui ? »
• Cette réponse se trouvait auparavant dans une colonne ordinaire sans aucun contrôle d'accès, en clair sur la page de confirmation, et recopiée dans la description de l'événement d'agenda — qui se synchronise vers l'extérieur et part dans chaque invitation
• Rien dans ce module n'écrit dans l'un ou l'autre, et c'est son objet même, non un effet de bord
• La dépendance au service documentaire vit dans cette passerelle, pour qu'un déploiement qui ne veut qu'une page de réservation n'ait que cela

Le fonds d'outils psychologiques numérisé, en enregistrements cherchables, avec un formulaire vivant facultatif dès qu'un scan est transformé en formulaire.

• Le fonds numérisé chargé en enregistrements portant leur texte OCR, pour qu'un outil se trouve par ce qui est écrit dessus
• Une taxonomie selon le système que chaque outil vise
• Une enquête facultative, créée quand un scan devient un formulaire vivant
• Les questions ne sont jamais rédigées ici — c'est le travail du constructeur unique
• Régénéré depuis les PDF sources par script plutôt que modifié à la main

Les conditions de rémunération des séances sur le contrat de l'employé, et le cycle de paiement qui les règle. Rien n'est recalculé au moment du versement — chaque séance a figé sa propre répartition lors de sa réservation.

• Quatre types de rémunération : salaire mensuel, taux horaire, forfait par séance, ou pourcentage de chaque séance
• Conditions tenues sur la version du contrat, de sorte que l'historique est daté et qu'une seule est en vigueur à la fois
• Cycles de paiement — hebdomadaire, quinzaine, mensuel ou trimestriel — ancrés sur le calendrier ou sur le début du contrat
• Une tâche quotidienne qui ouvre un cycle de versement en brouillon le matin où un cycle se clôt
• Confirmer un cycle lève une facture fournisseur par praticien, à partir des montants figés
• Un historique de versements conservé que le praticien peut consulter, y compris les cycles annulés
• Renégocier aujourd'hui ne réécrit jamais ce qui était dû le mois dernier

Envoie les contrats d'engagement à la signature depuis le document auquel ils appartiennent, et garde l'historique signé sur ce document.

• Envoyer un contrat à la signature depuis le contrat lui-même
• Chaque demande conservée sur ce document comme son historique
• La rémunération de séance peut être retenue sous un contrat que personne n'a encore signé
• Ne s'installe que lorsque les deux côtés sont présents, de sorte qu'aucun module ne porte une dépendance dont il n'a pas besoin

Les praticiens indépendants louent la plateforme dans un forfait que nous construisons. Ce module tient les forfaits, les abonnements, et les règles qui disent ce que l'état d'un abonnement permet de faire.

• Les forfaits portent un canal — cabinet, place de marché ou les deux —, des prix mensuels et annuels, et des lignes de conditions écrites en phrases
• Les interrupteurs de fonctionnalités d'un forfait sont lus depuis les modules installés plutôt que saisis
• Un abonnement copie les conditions et les fonctionnalités du forfait à la signature et ne les relit jamais : un changement de prix demain laisse donc intacts les abonnements d'aujourd'hui
• Un abonnement en vigueur par praticien et au plus un en chemin, imposés par deux index uniques partiels plutôt que par un contrôle que quelqu'un peut oublier
• Tout nouveau praticien indépendant démarre sur l'essai intégré — sept jours par défaut, réglable dans les paramètres
• À la fin de l'essai, les nouvelles réservations et le lien du praticien attendent qu'un forfait soit choisi, signé et payé. Les enregistrements ne sont jamais fermés
• L'administration peut attribuer un forfait que le site n'affiche pas — par carte, sur facture ou entièrement offert —, avec le contrat envoyé ou une copie signée jointe, et le motif consigné
• Forfait et facturation sur le compte du praticien, et un bandeau dans l'espace de travail pendant l'essai ou après l'échéance
• Les praticiens salariés, engagés par un contrat de travail, ne sont jamais sur un forfait et jamais bloqués

Qui a amené quel client à quel praticien — le seul fait dont dépend chaque commission payée par un praticien indépendant, et le seul que la plateforme n'enregistrait pas.

• Une ligne par couple praticien-client, portant l'origine et l'appartenance : client du praticien, ou client de la plateforme
• L'appartenance est fixée au premier contact et ne change que par un transfert administratif, avec motif
• Le lien court du praticien, /e/<code> : qui le suit s'inscrit et devient client de ce praticien
• Déjà inscrit et nouveau chez ce praticien : il appuie sur « Rejoindre ». Déjà client de ce praticien via la plateforme : il reste client de la plateforme, et le clic est journalisé
• Chaque visite du lien, et ce qu'elle a donné
• Comment une personne est venue à la plateforme — directement, ou amenée par un praticien — est tenu à part de l'appartenance, car l'un est un fait sur une personne et l'autre sur un couple

Quand le praticien encaisse l'argent du client, il doit sa part à l'entreprise. Une exécution mensuelle qui la lui facture et la suit jusqu'au paiement.

• Les praticiens validant les commandes et envoyant les liens de paiement, le devis, la facture et la page de paiement portent le nom commercial, l'adresse et le numéro de TVA du praticien comme vendeur
• Le fait que le praticien ait encaissé est figé sur la séance à la réservation, à côté du partage de la part : changer le réglage demain n'atteint donc pas le mois dernier
• Aucune formule nouvelle : la part de l'entreprise dit déjà ce que l'entreprise garde, et si c'est le praticien qui tient l'argent, c'est exactement ce qu'il doit
• Un praticien salarié ne garde rien d'une séance et en doit donc la totalité ; un indépendant en 70/30 doit les 30
• Une exécution de recouvrement par cycle, en miroir de l'exécution des versements — une facture client par praticien pour la somme des parts qu'il a encaissées
• Comptabiliser cette facture immédiatement ou attendre que quelqu'un la regarde est un réglage, activé par défaut
• « Payé » est l'état de paiement propre à Odoo : ce module l'observe et ne crée jamais de paiement
• L'espace de travail du praticien gagne une page Paiements — gagné, encaissé, dû, et chaque facture avec son état
• Les tableaux de bord de l'administration et de la comptabilité reçoivent l'autre côté : ouvert contre payé, compté et totalisé, avec les gains du mois à côté

La liste de ce que savent faire les modules installés, déclarée par chaque module lui-même, pour que les forfaits l'activent et le désactivent.

• Personne ne saisit le catalogue : un module qui a quelque chose à vendre livre un enregistrement de fonctionnalité par capacité
• Odoo crée ces enregistrements à l'installation du module et les supprime à sa désinstallation : le catalogue décrit donc toujours ce que cette base sait réellement faire
• Aucun balayage, aucune tâche de synchronisation, et aucune seconde liste à côté de la liste des modules pour s'en désynchroniser
• Ne dépend de rien d'autre que base, volontairement, pour que déclarer une fonctionnalité n'entraîne jamais un module clinique dans une dépendance à la coque de la plateforme
• Ce qu'une fonctionnalité signifie pour un praticien donné — si son forfait l'a activée, et jusqu'à quelle limite — appartient au forfait, pas ici

Le service lui-même. Un modèle l'adopte en une ligne et gagne ses documents, un compteur, et une boîte de dialogue de dépôt qui dit en mots simples qui pourra ouvrir le résultat avant qu'il ne soit stocké.

• Chiffré au repos avec sa propre clé, stocké hors du magasin de fichiers Odoo et jamais servi par /web/content
• Accès par règles explicites, refus par défaut : une règle d'autorisation qui correspond et aucune règle de refus qui corresponde, chaque fois
• Être administrateur, gestionnaire ou l'auteur du dépôt n'accorde rien en soi
• Chaque lecture comme chaque écriture journalisée, dans un journal en ajout seul chaîné par empreintes que personne ne peut modifier
• Versionné et en ajout seul : une correction est une nouvelle version, la précédente reste intacte
• Conservation et destruction selon des règles relatives, exécutées en détruisant la clé
• Ne cherche délibérément pas à l'intérieur des documents — un contenu chiffré ne peut pas être cherché en plein texte

La couche cryptographique, tenue comme module à part pour que la gestion des clés puisse être revue et auditée sans lire le reste de l'application.

• Chiffrement en enveloppe AES-256-GCM : une clé de données aléatoire par version de document, enveloppée sous une clé de déploiement
• La clé de chiffrement des clés n'est jamais stockée dans la base
• Le texte chiffré dans un répertoire à lui, hors du magasin de fichiers
• Une rotation de clé qui ré-enveloppe les clés sans réécrire un octet de texte chiffré
• Crypto-effacement : détruire la clé détruit le document et laisse la piste d'audit intacte
• Refuse de démarrer si la clé est absente, lisible par tous, détenue par le mauvais utilisateur, ou stockée là où elle voyagerait avec les données

Là où une personne lit les documents qui lui ont été partagés à son sujet, à /my/documents — et seulement ceux-là.

• Une personne concernée voit un document lorsqu'une règle d'accès du sujet l'accorde et que rien ne le refuse — jamais du simple fait qu'il la concerne
• Les notes de psychothérapie, les documents scellés et les documents sous une décision de rétention en cours ne sont jamais affichés, quoi que disent leurs règles
• Un seul filtre utilisé par chaque route, de sorte qu'il n'y a jamais qu'une seule définition de qui peut voir quoi
• Contenu déchiffré en mémoire et diffusé ; rien n'est écrit sur disque
• Un document que l'utilisateur ne peut pas voir renvoie 404, jamais 403 — deviner des références ne doit pas révéler qui détient des dossiers
• Chaque consultation et chaque téléchargement journalisés, y compris ceux de la personne concernée, et la page le dit
• Lectures limitées en débit par utilisateur, comptées depuis le journal d'accès pour que la limite tienne sur tous les processus

Dépose des documents sécurisés sur les contacts — le sujet le plus fréquent, puisque la personne qu'un document concerne est d'ordinaire celle sur laquelle il est déposé.

• Ajoute le service de documents sécurisés à res.partner
• S'installe dès que les deux côtés sont présents, et se désinstalle sans toucher ni l'un ni l'autre
• Un pont par application, de sorte qu'adopter le service sur un contact n'entraîne pas d'applications sans rapport

Dépose des documents sécurisés sur les opportunités — un dossier de vérification diligente n'a rien de clinique, et a exactement les mêmes exigences.

• Ajoute le service de documents sécurisés à crm.lead
• Chiffré, soumis aux règles et journalisé à chaque lecture, comme tout autre document sécurisé
• S'installe et se désinstalle proprement, indépendamment des autres ponts

Dépose des documents sécurisés sur les fiches d'employé — un dossier disciplinaire ou un rapport de médecine du travail est quelque chose qu'un gestionnaire dépose et que la plupart des RH ne doivent pas pouvoir ouvrir.

• Ajoute le service de documents sécurisés à hr.employee
• Accès en refus par défaut, de sorte qu'un rôle RH n'ouvre pas un dossier du simple fait d'être un rôle RH
• S'installe et se désinstalle proprement, indépendamment des autres ponts

Dépose des documents sécurisés sur les tâches — un contrat confidentiel ou un livrable signé tenu là où le travail est suivi.

• Ajoute le service de documents sécurisés à project.task
• S'installe dès que les deux côtés sont présents, et se désinstalle sans toucher ni l'un ni l'autre

Dépose des documents sécurisés sur les commandes — un accord signé, ou les pièces d'identité d'un client, tenus sur la vente à laquelle ils appartiennent.

• Ajoute le service de documents sécurisés à sale.order
• S'installe dès que les deux côtés sont présents, et se désinstalle sans toucher ni l'un ni l'autre

Facultatif : sortir la clé de chiffrement des clés de la machine Odoo, pour qu'une copie de la base ne soit pas une copie des documents.

• Clés de document enveloppées et désenveloppées par une autorité distante plutôt que localement
• La clé de chiffrement des clés ne se trouve jamais sur la machine qui sert l'application
• Activée par déploiement ; le moteur local reste disponible et inchangé
• Une autorité injoignable refuse d'ouvrir les documents plutôt que de se rabattre en silence

Résout l'équipe de soins. Un thérapeute atteint les dossiers des personnes de sa propre charge de travail, pas de celle de la clinique — c'est ce qui rend la norme du minimum nécessaire applicable plutôt qu'incantatoire.

• Des relations de soins — du clinicien au client, avec une sorte, un début et une fin
• L'accès prend fin quand la relation prend fin, après un délai de grâce assez long pour finir les notes en cours
• Des rôles cliniques qui décident quelle partie de l'application une personne atteint, jamais ce qu'elle peut ouvrir
• Un profil réservé au directeur pour les incidents, les plaintes et les signalements de protection — fermé même à qui les a déposés
• Le registre des communications : ce qui est sorti du service, vers qui, et sur quel fondement
• Droits de la personne : demandes d'accès avec leur horloge légale, modifications qui s'ajoutent au lieu d'écraser, restrictions qui scellent
• Ancrages de conservation — dernier contact, date de naissance, date de décès — pour que la couche de base calcule à partir d'eux
• La trace d'atteinte elle-même — ce qui s'est passé, qui était touché, et si qui l'a prise pouvait la lire — les couches de juridiction ajoutant leurs propres horloges à un seul incident plutôt que chacune gardant la sienne
• Communications confidentielles : un client peut demander qu'un canal ne soit jamais utilisé, et c'est refusé là où les messages partent plutôt que là où quelqu'un y pense — un courriel vers une adresse bloquée est annulé, jamais envoyé discrètement à l'adresse du dossier
• Aucun champ nulle part pour consigner pourquoi il l'a demandé, parce qu'exiger une explication est précisément ce que la règle interdit
• Une seule prorogation sur une demande d'accès, plafonnée sur la date obtenue plutôt que sur le nombre saisi — un mois depuis mars et un mois depuis juillet n'ont pas la même longueur
• Les frais détaillés selon les composantes que le règlement permet, parce que « raisonnable, fondé sur les coûts » est une affirmation, et une affirmation avec un seul nombre derrière est invérifiable
• Une copie à une personne désignée par l'intéressé, refusée tant que sa directive écrite signée n'est pas au dossier
• Un refus revu par quelqu'un d'autre que celui qui a refusé — appliqué, pas laissé à la procédure
• Une modification refusée avec laquelle la personne est en désaccord : sa déclaration, toute réfutation, et les deux voyageant avec chaque communication ultérieure du dossier contesté — jointes par le registre, pas par la mémoire de quelqu'un
• Quiconque en aval détient déjà l'information est nommé et prévenu, parce qu'une modification dont personne n'entend parler ne corrige qu'un exemplaire d'un dossier

La couche RGPD : la machinerie des droits et de la gouvernance à laquelle HIPAA n'a pas d'équivalent, et c'est pourquoi une réalisation aux normes américaines ne couvre pas l'UE.

• Fondement licite consigné par type de document — art. 9(2)(h) pour les dossiers de traitement, pas le consentement
• Effacement (art. 17) réalisé en détruisant la clé, de sorte que le droit est honoré sans effacer la preuve de ce qui était détenu
• Une évaluation d'effacement, et rien de détruit tant qu'une suspension légale ou une durée de conservation tient
• Portabilité (art. 20) comme archive zip diffusée — métadonnées en JSON, contenu tel que déposé, chaque document journalisé individuellement
• Notification des atteintes (art. 33/34) : 72 heures à l'autorité, et l'exemption de chiffrement de l'art. 34(3)(a)
• AIPD et registre des traitements conservés comme partie du dossier de gouvernance

Un pont, pas une construction — relie un avis de confidentialité signé à l'enregistrement de l'accusé, pour que le dossier puisse dire quelle version la personne a réellement vue.

• Une signature achevée écrit l'accusé de réception, une seule fois — un webhook livré deux fois ne doit pas fausser le compte de ceux qui restent
• La demande de signature nomme la version de l'avis, parce que c'est la seule question qu'on pose à un accusé de réception
• Un stylo sur un formulaire à la réception reste un accusé écrit ; le pont ajoute une voie plutôt que de remplacer l'ordinaire
• Une demande signée par un clinicien au nom d'un client n'est pas l'accusé de réception de ce client, et n'est pas comptée comme tel

Le RGPD britannique et le Data Protection Act 2018 sur le même noyau technique — avec le critère du préjudice grave bâti comme un flux plutôt que comme une case.

• Le critère du préjudice grave (DPA 2018, ann. 3 partie 2) consigné avec qui a décidé, quand, sur quels documents et pourquoi
• Ne peut être pris que par quelqu'un ayant une relation de soins en cours, ce que le système vérifie au lieu de le supposer
• Apparaît dans une file de revue avant d'expirer, et tombe de lui-même au bout de six mois
• Le lever rétablit l'étiquette que le document avait avant, pas « normal »
• La rétention est vis-à-vis de la personne concernée, pas de l'équipe de soins — ceux qui la traitent continuent de le lire
• Le calendrier de conservation du NHS Records Management Code of Practice 2021 comme données de départ
• Traitement de l'Access to Health Records Act pour les dossiers des personnes décédées

Les garanties administratives — la moitié de HIPAA qui ne parle pas de chiffrement, et celle que l'application cite le plus.

• L'analyse de risque comme exercice avec une période, un périmètre et une méthode, distincte du registre de ce qu'elle a trouvé — pour que l'an prochain se compare à cette année
• Chaque risque repris dans l'évaluation suivante avec un lien de retour, parce qu'un registre qui repart vierge chaque année perd la trace de ce qui a été décidé
• La cote inhérente calculée et la cote résiduelle délibérément pas — un résiduel obtenu en soustrayant un score de contrôle est une fiction qui dit la même chose d'un contrôle testé la semaine dernière et d'un contrôle écrit dans une politique
• Accepter un risque exige un motif consigné ; la décision est souvent la bonne et personne ne peut dire après coup laquelle c'était
• La revue d'activité avec ses questions nommées — aucune relation de soins, bris de glace, un nom de famille partagé, hors des heures, un volume aberrant — parce que « revoir les journaux » sans dire quoi chercher, c'est ainsi que les revues deviennent une signature sur rien
• Achever une revue vérifie chaque chaîne d'empreintes touchée dans la période, ce qui transforme un journal où l'altération se détecte en un journal où l'altération se remarque
• Des désignations tenues comme plages de dates avec les trous calculés, parce que l'exigence n'est pas qui la détient aujourd'hui mais que quelqu'un l'ait détenue sans interruption
• Des enregistrements de sanction lisibles seulement par un groupe que personne ne rejoint par implication — un enregistrement de sanction qui fuit est un incident à lui seul
• Une liste de fin d'accès et une tâche quotidienne qui en lève une pour quiconque a dépassé sa date de départ : des comptes qui survivent à l'emploi, c'est le contrôle le plus souvent raté
• De la formation avec une expiration, parce qu'une formation expirée n'est pas une formation
• Une analyse de criticité qui vérifie sa propre arithmétique : un système dont la base se restaure plus lentement que lui a un objectif de reprise écrit par quelqu'un, et les deux nombres vivent sur des lignes différentes d'un tableur
• Des plans de continuité qui disent quand ils ont été testés pour la dernière fois, et une liste de ceux qui ne l'ont jamais été — la seule chose qui distingue une organisation avec un plan d'une organisation qui croit en avoir un
• Un test qui n'a pas atteint ses objectifs doit dire ce qui a mal tourné, parce qu'un test qui n'a rien appris à personne n'est pas une preuve
• La sécurité des transmissions comme historique plutôt que comme affirmation : « nous utilisons HTTPS » parle du présent, et ces enregistrements disent que c'était vrai les jours sur lesquels on vous interroge
• Des vérifications qui ne peuvent être ni modifiées ni supprimées, parce que tout l'intérêt d'un historique est qu'il ne peut pas être rangé

La couche HIPAA. La séparation des notes de psychothérapie tient dans le stockage plutôt que de reposer sur la justesse des règles d'accès.

• L'ensemble de dossiers désigné (45 CFR 164.501) marqué par type de document, de sorte qu'une réponse d'accès ne peut pas inclure ce qui en est exclu
• Les notes de psychothérapie dans leur propre espace de clés — la clé qui ouvre le dossier ordinaire ne les ouvre pas
• Un octroi à la personne concernée sur les notes refusé sur tous les chemins, y compris une écriture directe dans la table des règles
• Un document déjà écrit ne peut pas être réétiqueté dans l'espace de clés des notes
• 42 CFR Part 2 : l'avis d'interdiction de retransmission généré plutôt que tapé
• Six ans de communications dans le registre, selon la sous-partie
• Notification des atteintes (164 sous-partie D) : une communication non permise est présumée une atteinte jusqu'à ce que l'évaluation à quatre facteurs dise le contraire, le raisonnement étant consigné
• Soixante jours aux personnes à compter de la découverte, calculés plutôt que saisis, et signalés avant expiration
• Les deux cinq cents tenus à part — avis aux médias au-delà de 500 résidents d'un État, avis au HHS à 500 ou plus au total
• Des avis individuels portant les cinq éléments exigés par le 164.404(c), pour qu'aucun ne soit discrètement omis d'une lettre qui se lit bien
• Le registre annuel des petites atteintes produit comme document, pas assemblé de mémoire en février
• La Notice of Privacy Practices versionnée, avec les accusés de réception consignés au regard de la version réellement remise
• La moitié qu'on saute facilement : là où aucune signature n'a été obtenue, l'effort et le motif sont exigés — un classeur de formulaires signés ne répond pas à cette question
• Une liste de travail des clients sans rien de consigné au regard de l'avis en vigueur
• Les motifs de refus d'accès comme liste fermée, chacun portant si la personne a droit à une révision — offrir une révision qui n'existe pas et en refuser une qui existe sont deux constatations
• Les quatre motifs de refus d'une modification, fermés eux aussi, et celui qui est un fait sur le document vérifié au regard du document
• La règle Part 2 de 2024 : un consentement unique couvrant traitement, paiement et exploitation, refusé s'il n'est pas révocable — un consentement unique sans retour possible est celui qu'on oublie avoir donné
• Une restriction Part 2 sur ces finalités traitée comme un droit plutôt que comme une demande, et vérifiée avant la générale — une vérification faite dans l'autre sens permettrait la communication avant d'atteindre la question
• Une atteinte impliquant des dossiers de trouble lié à l'usage de substances le dit dans l'avis, au lieu de l'enfouir sous « renseignements de traitement »
• Le 164.410 comme deux horloges : le sous-traitant a soixante jours depuis sa propre découverte et les nôtres commencent quand il nous prévient, de sorte qu'une atteinte peut avoir 118 jours sans que personne n'ait raté une échéance
• L'avis patient Part 2 versionné à côté de l'avis de confidentialité, plutôt qu'une constante en Python que personne ne versionne

La durée de conservation allemande, comme une règle que le service de documents calcule plutôt qu'une ligne dans une politique que personne n'applique.

• § 630f BGB : dix ans après le dernier contact, ensemencé comme règle de conservation
• Limité à ce module plutôt qu'à tout le pack UE, parce que la durée est nationale

Les règles norvégiennes que la couche RGPD ne couvre pas, chacune posée là où l'action se produit plutôt que dans une politique : publier un profil, confirmer une exécution de versements, divulguer quelque chose à un parent.

• Pasientjournalforskriften § 14 : le patient lit chaque accès à chaque dossier le concernant, y compris ceux qui ne lui sont pas montrés — par type, jamais par titre
• Un type de conservation sans aucune date d'élimination, parce que la Norvège garde les dossiers aussi longtemps qu'ils servent ; les années sont un intervalle de revue et une personne décide, avec un motif
• Une remise de dossier à un successeur, à Norsk helsearkiv ou à Nasjonalarkivet, construite au moment du téléchargement, consignée comme divulgation document par document, et téléchargeable une seule fois
• Helsepersonelloven § 74 : un profil utilisant un titre protégé ne peut être publié sans numéro HPR vérifié, et la vérification s'exécute à l'écriture — la synchronisation ne peut donc pas la contourner
• Proche le plus proche, parent, tuteur et mandat de protection future, avec les règles d'âge des §§ 3-4 et 4-3 imposées au registre des divulgations plutôt que comme un filtre sur une page
• Arbeidsmiljøloven § 1-8 : une exécution de versements payant à la séance ne se confirme pas sans qualification en cours, et les faits qui la soutiennent sont montrés sans pondération, parce que la question est juridique
• Personvernombud et responsable de la sécurité de l'information comme désignations, vérifiées pour les seules sociétés norvégiennes

Les rôles que le droit finlandais oblige un prestataire à nommer, et les devoirs qui pendent à chacun. Indépendant du pack norvégien — les deux s'activent depuis le pays de la société, une seule base peut donc tenir les deux.

• Professions réglementées et titres protégés tenus à part, car ce sont des droits différents : psykoterapeutti est un titre protégé en Finlande et un mot libre en Norvège
• Numéro Terhikki, date de la vérification par l'employeur et nature de celle-ci — consultation du registre ou document de décision ; un numéro saisi compte comme déclaré, non comme vérifié
• Une unité de service avec son propre enregistrement, et la vastuuhenkilö comme désignation par unité, de sorte qu'une quinzaine sans responsable est signalée
• Le plan d'autosurveillance public et le plan de sécurité confidentiel sont séparés par construction : un même enregistrement de politique ne peut pas être marqué comme les deux
• Asiakastietolaki § 11 : deux ans d'information de journal avec le destinataire et la base, une demande écrite avec un délai de deux mois, et un refus consigné avec son motif
• Potilaslaki § 9(2) ne donne aucun âge : un mineur est donc une appréciation consignée — sans elle, une divulgation au tuteur est refusée, et le refus dit que l'appréciation manque
• Douze ans après le décès, et là où le décès n'est pas connu, 120 ans après la naissance

La Suisse sépare la qualification de l'autorisation de pratiquer, compte les séances assurées contre une ordonnance médicale, et lie le fournisseur au même secret pénal que le praticien. Trois choses que le noyau ne sait pas exprimer, et rien d'autre.

• Le titre fédéral n'est pas l'autorisation : l'autorisation de pratiquer est cantonale, une par canton, chacune avec sa propre échéance — un praticien peut donc porter le nom en Suisse et n'avoir le droit de travailler qu'en un seul lieu
• Un profil utilisant un titre protégé n'est pas publié sans un numéro PsyReg vérifié et une autorisation cantonale en cours et vérifiée — et le refus dit lequel des deux manque
• Là où un titre est vérifié et aucune autorisation ne l'est, le statut public le dit au lieu d'en sous-entendre une ; un marché non vérifié n'est pas servi par une fiche qui se lit comme une fiche vérifiée
• Anordnungsmodell : quinze séances sur ordonnance médicale, renouvelables une fois jusqu'à trente, l'assureur au-delà — comptées à travers la chaîne des renouvellements, averties avant la séance qui ne serait pas payée, et refusées au second renouvellement sans accord au dossier
• Seule une séance délivrée compte ; une séance réservée non, car la compter arrêterait une ordonnance deux séances trop tôt
• L'article 321 lie les auxiliaires au même devoir pénal que le praticien : le registre pose donc la seule question dont dépend l'article — peuvent-ils lire les données en clair ?
• Dix ans après le dernier contact, semés sur l'horloge de conservation que le service documentaire avait déjà — pas de seconde manière de dire la même chose
• Les cantons dans lesquels chaque praticien est autorisé décident de la langue dans laquelle leurs autorités correspondent, montrée sur le praticien et sur chaque autorisation
• La facturation assurée a ici sa forme et aucun de ses catalogues : une édition tarifaire, des positions en points tarifaires, des valeurs du point par canton et classe d'assureur. Positions et valeurs du point sont des données sous licence qu'un déploiement charge, car un code inventé plausible est un code sur lequel quelqu'un facture
• Une séance qui ne peut pas être tarifée dit quel canton n'a pas de valeur du point chargée, et n'affiche aucun montant — zéro franc voudrait dire que la séance ne coûte rien, ce qui est une autre affirmation
• Allemand, français et italien dans toute l'interface, en termes suisses : une Berufsausübungsbewilligung plutôt qu'une « licence cantonale » traduite, et une Hilfsperson plutôt qu'une « personne auxiliaire »

Une liste fixe de questions posées au déploiement lui-même. L'essentiel des vérifications existait déjà et était éparpillé ; voici la page qui les lit au même endroit.

• Un registre de vérifications, un exécuteur planifié, et un rapport sur les deux
• Seul ce qui va mal est signalé : une vérification qui passe ne dit rien, la page est donc vide quand le déploiement est sain
• Chaque constatation nomme la règle dont elle vient et l'enregistrement sur lequel elle a été trouvée
• Les exécutions sont conservées, de sorte qu'une constatation qui revient se voit comme un motif plutôt que comme une nouvelle

Le service de signature lui-même : une cérémonie de signature sur le portail, des politiques de juridiction, et une piste d'audit chaînée par empreintes. Auto-hébergé, de sorte qu'aucun document ne quitte le parc pour être signé.

• Une cérémonie de signature sur le portail, avec identité et intention saisies au moment de la signature
• Une piste d'audit chaînée par empreintes que personne ne peut modifier ni supprimer
• Des politiques de juridiction qui régissent ce qu'exige une signature valable
• Des demandes de signature comme enregistrements, avec leur propre statut et leur historique

Qui avait le pouvoir de signer pour une contrepartie, et si son titre est encore valable — vérifié plutôt que supposé.

• Pouvoir d'engager suivi par signataire de contrepartie
• Accords signés conservés comme enregistrements avec une durée
• Titres de praticien relancés avant leur échéance

Ce qu'une signature clinique exige au-delà d'un nom : la capacité, le pouvoir de signer au nom d'autrui, la supervision, et un consentement qui peut être retiré.

• Attestation de capacité consignée au moment de la signature
• Signature au nom d'un client, le pouvoir étant consigné
• Contresignature du superviseur là où le service l'exige
• Un cycle de vie du consentement révocable plutôt qu'une case cochée une fois

Les éléments que HIPAA exige d'une autorisation, validés plutôt que confiés à un gabarit.

• Validation des éléments exigés d'une autorisation HIPAA
• Matériel 42 CFR Part 2 séparé du reste
• La reddition des communications qu'une entité couverte doit produire sur demande

Une action Demander une signature sur les candidats et les employés, pour qu'une offre ou une politique soit signée là où la personne se trouve déjà.

• Demander une signature sur une fiche de candidat
• Demander une signature sur une fiche d'employé
• Demandes conservées sur la fiche comme son historique

Une action Demander une signature sur les devis et les bons de commande.

• Demander une signature sur une commande client
• Demander une signature sur un bon de commande
• Le document signé conservé sur la commande

Place les gabarits de signature là où la clinique vend : épinglés à un praticien ou à un service, envoyés automatiquement à l'achat, et visibles comme un statut.

• Gabarits de signature épinglés à un praticien ou à un service
• Envoyés à l'achat, sans que personne ait à y penser
• Statut de signature montré aux praticiens dans le portail et dans l'application mobile

Met fin à une session que personne n'utilise. Le 45 CFR 164.312(a)(2)(iii) demande une fin de session après une période d'inactivité prédéterminée, et vous laisse la période — c'est donc un réglage, l'application se faisant sur le serveur plutôt que dans le navigateur.

• Période d'inactivité, période d'avertissement et plafond absolu, réglés par société
• Vérifiés sur le serveur à chaque requête authentifiée, de sorte que désactiver la minuterie du navigateur n'apporte rien
• Un avertissement avant la fin de session, pour que personne ne perde une note à moitié écrite à cause d'un contrôle censé le protéger
• Un plafond absolu autant qu'un plafond d'inactivité, parce qu'une session maintenue en vie par un script reste une session qui devrait finir
• Chaque fin de session consignée — qui, quelle surface, et quelle règle y a mis fin
• L'enregistrement est en ajout seul : la preuve qu'un contrôle a fonctionné vaut ce qu'il coûte de la modifier
• Mettre la période à zéro le désactive, ce qui est une décision que la spécification permet et que votre analyse de risque consigne

Relie Odoo Community à n'importe quel grand modèle de langage, derrière une interface — de sorte que le fournisseur peut changer sans que la logique métier le sache.

• Fournisseurs configurés par déploiement, l'identifiant étant tenu hors du code applicatif
• Agents définis comme des invites avec les outils qu'ils ont le droit d'appeler
• Appel d'outils, pour qu'un modèle puisse agir plutôt que seulement répondre
• Exécutions consignées, de sorte que ce qui a été demandé et ce qui est revenu est inspectable ensuite
• Actions serveur pilotables depuis une invite
• Diagnostics pour vérifier qu'un fournisseur est joignable et correctement configuré

Convertir un utilisateur entre interne et portail à la main suppose de modifier les droits d'accès dans le bon ordre et de se rappeler les effets de bord. Ceci en fait un bouton.

• Un champ Type d'utilisateur sur la fiche, la liste et les filtres de recherche
• Des boutons Convertir en interne et Convertir en portail sur la fiche utilisateur
• Une action Convertir le type d'utilisateur sur la liste des utilisateurs, pour plusieurs à la fois
• Des garde-fous : l'utilisateur système, votre propre utilisateur et le dernier administrateur restant ne peuvent jamais être convertis par accident

En-tête, pied de page et page de connexion sur une seule mise en page, nommée d'après la société présente dans cette base.

• Une mise en page pour l'en-tête, le pied de page et la page de connexion
• Le nom affiché est celui de la société dans cette base, non une valeur saisie dans un gabarit
• L'adresse du logo et une ligne de copyright personnalisée sont des paramètres système, modifiables aussi sous Paramètres → Site web → Marque publique
• Les liens de l'en-tête viennent du menu principal de ce site : ils se modifient donc là où se modifie tout autre menu

Sociétés, utilisateurs, groupes, contacts, langues et les règles d'enregistrement qui décident qui voit quoi. Absent de la liste des applications parce que tout en dépend.

• Sociétés et périmètre multi-société
• Utilisateurs, groupes et règles d'accès au niveau de l'enregistrement
• Les contacts comme modèle unique partagé par les clients, les praticiens et les fournisseurs
• Langues, traductions et locale par utilisateur
• Actions planifiées — la file de tâches derrière chaque travail nocturne

L'interface de back-office dans laquelle le personnel travaille, et les outils d'édition derrière chaque champ de texte enrichi et chaque bloc de site.

• Vues liste, formulaire, kanban, calendrier, tableau croisé et graphique
• Filtres, regroupements et recherches enregistrées sur chaque écran
• Export CSV et XLSX depuis n'importe quelle liste
• Éditeur HTML — le champ de texte enrichi utilisé partout
• Constructeur HTML — l'éditeur de blocs par glisser-déposer
• Routage web — la couche d'URL par laquelle chaque page de portail et de site est servie

Applications OdooWebWeb RoutingHTML EditorHTML Builder

La messagerie, et le fil de messages attaché à chaque enregistrement — c'est ainsi qu'une décision garde son historique au lieu de vivre dans la boîte courriel de quelqu'un.

• Le fil de suivi sur chaque enregistrement : messages, notes, abonnés et changements de champs suivis
• Canaux internes et messages directs
• Courriel sortant avec gabarits, et routage entrant
• Activités — une tâche assignée sur un enregistrement plutôt qu'à la mémoire de quelqu'un
• OdooBot, et sa variante RH pour les invites d'accueil

Applications OdooDiscussOdooBotOdooBot - HR

La zone authentifiée qu'un client, un praticien ou une contrepartie atteint sans être utilisateur interne — tout ce qui est sous /my.

• Des utilisateurs du portail sans aucun accès au back-office
• Documents, commandes et factures partagés avec la personne à qui ils appartiennent
• Le cadre dans lequel chaque page de portail sur mesure de cette plateforme est bâtie
• Une page d'inscription personnalisée, pour que l'inscription corresponde à la marque plutôt qu'au défaut d'Odoo

Applications OdooCustomer PortalCustomize Signup Page

L'application carnet d'adresses : personnes, organisations, et les liens entre elles.

• Personnes physiques et sociétés, avec des contacts rattachés
• Adresses, identifiants fiscaux et coordonnées bancaires
• Étiquettes et catégories utilisées pour la segmentation
• L'enregistrement auquel un client, un praticien et un fournisseur se ramènent tous

Applications OdooContacts

Ce qui est vendu. Dans une clinique, ce sont des séances et des forfaits, mais le modèle en dessous est le modèle standard.

• Modèles de produit et variantes
• Unités de mesure, et produits de service pour le temps
• Listes de prix, pour qu'un forfait ou un segment soit tarifé différemment
• Catégories de produit utilisées pour les rapports par ligne de service

Calendriers de travail, capacité et congés — le modèle dans lequel s'expriment les horaires hebdomadaires d'un praticien et ses exceptions datées.

• Horaires de travail par personne, avec fuseaux horaires
• Capacité des ressources et congés
• Le calendrier au regard duquel l'utilisation est calculée

Applications OdooResource

Les petits modules installés que personne n'ouvre exprès, et dont chacun supprime une catégorie précise de ticket d'assistance.

• Boîte à outils d'accueil — progression guidée de la mise en place d'un nouveau déploiement
• Validation des numéros de téléphone — numéros normalisés à la saisie, pour que les SMS arrivent vraiment
• Google reCAPTCHA — protection anti-pourriel sur les formulaires publics
• Google Gmail — courrier sortant par un compte Google sans mot de passe SMTP

Applications OdooOnboarding ToolboxPhone Numbers ValidationGoogle reCAPTCHA integrationGoogle Gmail

Devis et commandes clients — l'enregistrement auquel chaque séance achetée se rattache, et l'extrémité gauche de la chaîne de l'argent.

• Devis, confirmation et commandes clients
• Lignes de commande portant les séances ou forfaits achetés
• Statut de livraison et de facturation par ligne
• Gabarits de devis, pour un forfait vendu de façon répétée
• Équipes commerciales et les rapports qui les suivent
• La commande à laquelle un crédit, une facture et un paiement se rattachent tous

Applications OdooSales

Le grand livre général. Factures, factures fournisseurs, paiements, taxes et rapprochement — là où les livres de la clinique vivent vraiment.

• Factures clients et avoirs, les factures émises étant immuables
• Factures fournisseurs — y compris celles qu'un cycle de versement crée pour les praticiens
• Paiements, relevés bancaires et rapprochement
• Taxes, positions fiscales et plan comptable
• Journaux, écritures et la piste d'audit derrière
• Bilan, compte de résultat, balance âgée clients et fournisseurs

Applications OdooInvoicing

Coût et revenu attribués à autre chose qu'un compte — un projet, une ligne de service, un praticien.

• Comptes analytiques et répartitions
• Coût et revenu suivis par projet ou par ligne de service
• La dimension sur laquelle les rapports de marge sont calculés

Le cadriciel dans lequel les moyens de paiement se branchent, de sorte qu'ajouter ou changer de fournisseur relève du paramétrage plutôt que du développement.

• Fournisseurs de paiement configurés par société
• Jetons de paiement, pour une carte enregistrée qu'un client réutilise
• Transactions avec leur propre état, rapprochées des factures
• La couture derrière laquelle se trouve l'interrupteur PAYMENTS de la passerelle

Trois fournisseurs sont activés : un processeur de cartes réel, un de démonstration pour la formation, et des moyens manuels pour l'argent qui arrive hors passerelle.

• Stripe — cartes, portefeuilles et moyens de paiement enregistrés
• Démonstration — un fournisseur qui se comporte comme un vrai, pour la formation et les répétitions
• Modes de paiement personnalisés — virement, espèces et tout ce qui se rapproche à la main
• Dix-sept autres fournisseurs sont livrés avec Odoo et sont à un interrupteur près

Applications OdooPayment Provider: StripePayment Provider: DemoPayment Provider: Custom Payment Modes

Remises, promotions, cartes cadeaux et programmes de fidélité — appliqués aussi bien sur une commande que sur le paiement en ligne.

• Codes de réduction et promotions automatiques
• Cartes de fidélité et cumul de points
• Cartes cadeaux, et soldes de portefeuille électronique
• Règles de programme par produit, ligne de service ou segment de clientèle

Applications OdooCoupons & LoyaltySale LoyaltySale Loyalty - Delivery

Ce que le personnel dépense, et la part qui est refacturée à un client plutôt qu'absorbée.

• Notes de frais, approbation et remboursement
• Frais comptabilisés directement
• Refacturer un frais en lui rattachant la commande
• Le versant coût d'un engagement délivré

Applications OdooExpensesSales Expense

Bons de commande et gestion des fournisseurs — le versant des coûts engagés, et la façon dont arrivent les factures fournisseurs.

• Demandes de prix et bons de commande
• Fiches fournisseurs et listes de prix
• Factures fournisseurs rapprochées des commandes
• La commande sur laquelle une signature peut être demandée

Applications OdooPurchase

Pistes et opportunités — utilisés ici pour les demandes qui ne sont pas encore des clients, et pour les demandes de consultation venues de l'application.

• Pistes, opportunités et un pipeline paramétrable
• Activités et prochaines actions sur chaque opportunité
• Motifs de perte et rapports de taux de réussite
• Le modèle sur lequel des documents sécurisés peuvent être déposés pour un dossier de vérification diligente

Applications OdooCRM

Compléter ce qu'une piste ne vous a pas dit, trouver des pistes qui n'ont jamais pris contact, et donner à une équipe commerciale de quoi se mesurer.

• Enrichissement des pistes — coordonnées d'entreprise complétées automatiquement depuis un domaine de courriel
• Génération de pistes — pistes extraites par secteur, taille et lieu
• Ludification du CRM — objectifs, badges et classements sur le pipeline

Applications OdooLead EnrichmentLead GenerationCRM Gamification

Un module de discussion sur le site public, tenu par de vraies personnes, et relié à la fois au pipeline et au service RH.

• Discussion en direct — opérateurs, canaux et réponses préenregistrées
• Discussion en direct du site — le module sur le site public et l'annuaire
• Discussion en direct CRM — une conversation convertie en piste sans rien retaper
• RH - Discussion en direct — le même canal utilisé en interne pour les questions du personnel
• Transcriptions conservées sur le visiteur et, une fois connu, sur le contact

Applications OdooLive ChatWebsite Live ChatCRM LivechatHR - Livechat

Le canal au plus fort taux d'ouverture, branché là où une clinique en a vraiment besoin. Les rappels de séance l'utilisent déjà.

• Passerelle SMS — l'infrastructure d'envoi et le statut de livraison
• SMS dans le CRM — écrire à une piste depuis l'opportunité
• Envoyer un SMS à un visiteur — et la variante qui fonctionne depuis une piste
• Recrutement - SMS — écrire à un candidat au sujet d'un entretien
• Suppression par personne, de sorte qu'un retrait est respecté partout

Applications OdooSMS gatewaySMS in CRMSend SMS to VisitorSend SMS to Visitor with leadsRecruitment - SMS

Une extension sur mesure sur les pistes et les contacts : envoyer un message WhatsApp prédéfini sans quitter l'enregistrement.

• Action d'envoi rapide sur une piste et sur un contact
• Gabarits de message prédéfinis
• Le canal que beaucoup de clients de ce marché lisent réellement

Applications OdooCRM Extension v2 - WhatsApp Quick Send

Des chiffres périodiques poussés vers ceux qui devraient les voir, et l'attribution de chaque lien que l'entreprise publie.

• Récapitulatifs d'indicateurs — un résumé planifié envoyé par courriel aux gestionnaires
• Suivi de liens — liens courts étiquetés UTM avec statistiques de clics
• Campagne, média et source consignés sur le visiteur qui a converti

Applications OdooKPI DigestsLink Tracker

Le constructeur de pages derrière le site public — les pages que le marketing modifie sans développeur.

• Pages par glisser-déposer avec des blocs réutilisables
• Pages multilingues et métadonnées de référencement
• Menus, thèmes et versionnement des pages
• L'annuaire public et les pages de profil des praticiens

Applications OdooWebsite

Vendre sur le site public : le catalogue, le panier et le paiement que traverse un client avant même de détenir un crédit.

• Catalogue public de produits et pages produit
• Panier, paiement et règlement sur le site
• Comptes clients et historique des commandes
• Les garde-fous du panier qui bloquent un achat non réservable

Applications OdooeCommerce

Le versant publication : les articles qui apparaissent dans le fil de contenus de l'application et sur le site public.

• Blogues, articles, étiquettes et commentaires
• Articles multilingues
• La source que le fil de contenus classé lit

Applications OdooBlog

Les trois endroits où un visiteur peut créer un enregistrement sans compte — chacun atterrissant là où une personne travaille vraiment.

• Formulaire de contact — une demande qui arrive comme piste, pas comme courriel
• Envoi de tâche en ligne — un formulaire du site qui crée une tâche de projet
• Offres d'emploi en ligne — postes publiés, et candidatures arrivant dans le recrutement

Applications OdooContact FormOnline Task SubmissionOnline Jobs

Trois petits modules qui relient le site public au reste du système. Personne ne les ouvre ; tout casse sans eux.

• Courrier du site — abonnements et fils de messages sur les pages publiques
• Partenaire du site — une page publique pour un contact, ce qu'est un profil de praticien
• Paiement du site — le paiement sur le site relié au cadriciel de paiement

Applications OdooWebsite MailWebsite PartnerWebsite Payment

Fiches d'employé et contrats. Dans Odoo 19, un contrat est une version de l'employé, et cette chronologie de versions est ce qui porte les conditions de rémunération d'un praticien.

• Fiches d'employé, départements et postes
• Versions de contrat avec un historique daté, une seule en vigueur à la fois
• Horaire de travail par employé
• La fiche sur laquelle les conditions de rémunération et les cycles de versement sont bâtis

Applications OdooEmployees

Ce que chaque praticien est qualifié pour faire, quand cette qualification expire, et qui rend compte à qui.

• Gestion des compétences — compétences, niveaux et progression par employé
• Certification des compétences — certificats avec expiration, ce qui rend un titre relançable
• Organigramme RH — lignes hiérarchiques sur la fiche d'employé
• Ludification RH — objectifs internes et badges

Applications OdooSkills ManagementSkills CertificationHR Org ChartHR Gamification

Candidats et embauche — et la raison pour laquelle une offre fait partie des documents que la pile de signature électronique doit traiter.

• Postes, candidats et un pipeline d'embauche
• Planification des entretiens et grilles d'évaluation
• Compétences confrontées aux exigences du poste
• La fiche de candidat depuis laquelle une signature peut être demandée

Applications OdooRecruitmentRecruitment - Skills Management

D'où chaque personne travaille un jour donné — ce qui, pour une clinique, veut dire savoir qui est sur place pour recevoir un client.

• Jours au domicile et au bureau par employé
• La même information affichée sur le calendrier d'équipe
• Visible à côté du calendrier des salles quand on planifie des séances sur place

Applications OdooRemote WorkRemote Work with calendar

Projets et tâches. Utilisés pour le travail de prestation et, dans la branche contrats, pour séparer le coût de gagner un contrat du coût de l'exécuter.

• Projets, tâches et étapes
• Attribution, échéances et avancement
• Dépôt de documents au niveau de la tâche, y compris les documents sécurisés
• Le projet au regard duquel le coût et la marge d'un contrat sont rapportés

Applications OdooProject

Une liste de tâches personnelle par utilisateur, séparée du travail de projet — là où vont les petites choses qu'un gestionnaire ramasse pendant la routine du matin.

• Des tâches privées avec des échéances
• Convertibles en tâche de projet quand il s'avère que c'est du vrai travail

Applications OdooTo-Do

Rendez-vous et événements. Chaque séance est un événement de calendrier en dessous, et c'est ce qui rend les calendriers de salle et d'équipe réels plutôt qu'un simple affichage.

• Événements avec participants, récurrence et rappels
• Disponibilité visible à l'échelle d'une équipe
• Synchronisation avec des calendriers externes
• L'événement auquel une séance réservée est rattachée

Applications OdooCalendar

Des questionnaires. Utilisés ici pour les questions d'admission posées à la réservation et pour l'enquête de retour privée après une séance.

• Questionnaires avec questions conditionnelles
• Réponses enregistrées au regard de la personne qui a répondu
• Cotation, là où un questionnaire est une évaluation
• Les questions d'admission attachées à un service réservable

Applications OdooSurveys

Du temps consigné sur un projet ou une tâche. Disponible et désactivé sur le déploiement de référence — c'est une dépendance de la branche contrats plutôt que du travail de clinique.

• Saisies de temps sur des projets et des tâches
• Coût horaire issu de la fiche d'employé
• Approbation et rapports de feuilles de temps
• Les heures que la facturation de contrat transforme en chiffres de recouvrement et d'utilisation

Un pôle formation : événements payants ou gratuits, cours en ligne et forum public — tous vendus par le même panier et rapportés dans les mêmes livres.

• Événements avec inscription, billetterie, sessions et exposants
• Événements vendus comme produits par le paiement existant
• Sessions en direct et quiz pour les séances en ligne
• Cours de formation en ligne, avec des compétences acquises à l'achèvement
• Un forum public, et des événements reliés au pipeline CRM

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

Des campagnes vers des listes que l'entreprise détient déjà. La clinique envoie aujourd'hui des courriels et des SMS transactionnels ; voici la moitié marketing de la même infrastructure.

• Marketing par courriel — campagnes, gabarits, tests A/B et statistiques
• Marketing par SMS — la même chose, sur le canal au plus fort taux d'ouverture
• Envoi en masse ciblant pistes, opportunités, participants ou intervenants d'un événement
• Carte marketing — images de partage personnalisées pour une campagne
• Boutons d'inscription à l'infolettre sur le site, par courriel ou par SMS

Applications OdooEmail MarketingSMS MarketingMass mailing on attendeesMass mailing on lead / opportunitiesMass mailing on track speakersMass mailing sms on lead / opportunitiesMarketing CardNewsletter Subscribe ButtonNewsletter Subscribe SMS Template

Pour une clinique qui vend aussi quelque chose de physique au comptoir — livres, compléments, kits de test — ou qui tient une caisse à l'accueil.

• Inventaire — stock, emplacements, réapprovisionnement et valorisation
• Point de vente — une caisse qui fonctionne hors ligne et se synchronise
• Remises au point de vente, et les programmes de fidélité déjà configurés

Applications OdooInventoryPoint of SalePoint of Sale - Coupons & LoyaltyPoint of Sale Discounts

Le versant administration du personnel. Pertinent dès qu'une clinique emploie assez de monde pour que congés et présence ne tiennent plus dans un calendrier partagé.

• Congés — demandes, approbation, soldes, et l'effet sur les bulletins de paie
• Présences — pointage d'entrée et de sortie, avec contrôle de présence
• Rapports de présence à côté des feuilles de temps
• Salaire horaire de l'employé, pour chiffrer les heures délivrées
• Flotte et historique de flotte, là où des véhicules sont fournis
• Cantine — l'application de commande des repas

Applications OdooTime OffTime Off in PayslipsAttendancesTimesheets/attendances reportingEmployee Presence ControlHR Attendance HolidaysEmployee Hourly WageFleetFleet HistoryLunch

Stripe est activé. N'importe lequel de ceux-ci peut être ajouté ou substitué par paramétrage — c'est ce qui fait de l'entrée sur un nouveau marché un changement de réglage plutôt qu'un projet.

• Europe — Mollie, Buckaroo, Worldline, Redsys, Adyen
• Amériques — Authorize.Net, Mercado Pago, PayPal, Nuvei
• Moyen-Orient et Afrique — Amazon Payment Services, Paymob, DPO, Flutterwave
• Asie — AsiaPay, Razorpay, Xendit
• Türkiye — Iyzico

Applications OdooPayment 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

Des services externes facultatifs. Tous désactivés par défaut, ce qui est délibéré : chacun envoie quelque chose hors du parc, et cela doit être une décision plutôt qu'un défaut.

• Google Calendar — synchronisation bidirectionnelle des agendas du personnel
• Google Maps et l'autocomplétion des lieux sur le site
• Autocomplétion d'adresse Google sur les formulaires de contact
• Utilisateurs Google — connexion avec un compte Google Workspace
• Stockage infonuagique sur Azure ou Google, pour les pièces jointes à grande échelle

Applications OdooGoogle CalendarGoogle MapsGoogle places autocompletionGoogle Address AutocompleteGoogle UsersCloud StorageCloud Storage AzureCloud Storage Google

Des bricoles qui résolvent chacune un problème étroit. Listées par souci d'exhaustivité plutôt que parce qu'une clinique en a besoin dès le premier jour.

• Extensions de messagerie pour Outlook et Gmail, sur le CRM et sur les projets
• Groupe de courrier — une discussion de type liste de diffusion, avec archive sur le site
• Recyclage de données — trouve les enregistrements en double et périmés
• Profil de site — une page publique pour un utilisateur du portail
• Formulaires d'entretien de recrutement, et rapports de marge sur les frais de vente
• Une intégration de téléphonie CRM (Issabel)

Applications OdooMail PluginCRM Mail PluginProject Mail PluginMail GroupWebsite Mail GroupData RecycleWebsite profileHr Recruitment Interview FormsSales Expense MarginCRM Issabel Integration

L'accord, ses parties, ses conditions structurées avec leur provenance, ses versions, et un flux d'étapes paramétrables projetées sur cinq phases fixes.

• Des accords avec des parties, des conditions structurées et la provenance des conditions
• Des versions, pour que « que disait-il en mars ? » reste une question avec une réponse
• Des étapes paramétrables projetées sur cinq phases fixes
• Aucun vocabulaire sectoriel et aucune dépendance à la signature électronique, au stockage chiffré ou aux projets
• Les secteurs arrivent comme des packs de paramétrage plutôt que comme des embranchements du code

Bâti pour que la revue porte sur ce qui a changé et ce qui dévie, et jamais sur du texte standard inchangé — c'est là que les systèmes de contrats sont d'ordinaire abandonnés.

• Une bibliothèque de clauses reliée aux conditions structurées, de sorte qu'accepter un repli fixe la condition qu'il porte
• Guides de négociation, tours, points en litige et déviations consignées
• Des réunions comme tours de négociation à part entière, gardant le raisonnement et les positions
• Une issue de réunion crée des changements proposés et ne modifie jamais le contrat d'elle-même
• Un journal reliant chaque étape de la demande à l'exécution, chaque trou étant visible

Une approbation décidée sur plus d'un axe. La traiter comme une affaire d'ancienneté seule est l'erreur de conception courante : un accord de confidentialité standard, à n'importe quel montant, n'a besoin de personne de haut rang.

• Approbation selon le montant, la déviation, le type de contrat et le risque
• La déviation comme axe à part entière plutôt que comme modificateur du montant
• Une approbation par un délégué toujours consignée comme telle — « au nom de » est un fait différent
• Fonctionne sur Odoo Community, où l'application Approbations n'est pas disponible

Consigne ce qu'un avenant a changé, pas seulement qu'il existe.

• Exécuter un avenant clôt les lignes de condition qu'il modifie et en ouvre de nouvelles à la date d'effet
• Tout ce qui découle d'une condition changée est recalculé, et le mouvement est montré avant l'exécution
• Avenants contradictoires détectés à l'exécution
• Une renonciation caduque ranime la condition en vigueur au moment de la caducité, pas l'originale

La signature est le début de l'obligation, pas la fin d'un flux. Voici ce qui porte la suite.

• Des obligations dans les deux sens, avec des preuves là où des preuves sont exigées
• Des dates dérivées calculées à partir des conditions plutôt que saisies, et déplacées quand leurs conditions motrices bougent
• Une échelle d'escalade qui ne consiste pas à relancer la personne qui n'a déjà pas agi
• La décision de renouvellement présentée avec les obligations que la contrepartie n'a pas tenues

Deux coûts, tenus à part : ce qu'un contrat a coûté à gagner, et ce qu'il coûte à exécuter. Les additionner produit un nombre qui ne répond à aucune des deux questions.

• L'effort de négociation consigné comme frais généraux, que le contrat se signe ou non
• Le coût de prestation recouvré sur la valeur du contrat
• Contrats reliés aux projets en plusieurs-à-plusieurs avec un rôle, parce qu'un champ projet unique casse au premier accord-cadre
• Un contrat fournisseur signé est un coût engagé dès l'exécution, pas dès sa première facture

Ce que vaut une heure, ce que les honoraires permettent, et les quatre chiffres qui ont besoin des deux.

• Taux de facturation, indicateur facturable et état facturé sur le temps consigné
• Bases d'honoraires énoncées sur le contrat
• Recouvrement — facturé rapporté à la valeur du temps consigné
• Utilisation — heures facturables rapportées aux heures disponibles, d'après le calendrier de travail de la personne
• Immobilisation — travail non facturé plus factures non encaissées, et combien de jours de facturation cela représente
• Une alerte d'honoraires plafonnés pilotée par le coût projeté, parce qu'une alerte qui se déclenche au plafond se déclenche trop tard

Le quatrième canal d'échange : la contrepartie lit ici la version courante, commente, et téléverse ses annotations comme un tour entrant.

• La contrepartie ouvre la version courante, la commente et renvoie ses annotations
• Les annotations arrivent comme un tour entrant avec le fichier joint, pas comme un courriel que quelqu'un doit penser à classer
• Rien d'interne n'est visible — ni positions, ni déviations, ni approbations, ni guide de négociation, ni notes internes
• Facultatif, parce qu'une conception qui suppose que la contrepartie utilisera notre portail échoue au premier grand client

Comment un contrat utilise le service de signature. L'achèvement est l'événement qui déclenche tout le reste.

• Les approbations doivent être complètes avant qu'une version puisse être envoyée
• Le pouvoir d'engager du signataire vérifié au regard de son titre
• La version verrouillée au moment de l'envoi, de sorte que toute affirmation ultérieure sur ce qui a été signé est prouvable
• À l'achèvement, la version est exécutée, le contrat avance, les conditions s'activent et les dates dérivées suivent
• Le désinstaller laisse un système qui fonctionne — les signatures papier sont consignées avec une méthode et paraissent complètes

Chiffrer chaque contrat rend le système inutilisable ; n'en chiffrer aucun le rend dangereux. La confidentialité est donc un niveau sur l'accord.

• Seuls les accords marqués sécurisés acheminent leurs documents vers le service de documents sécurisés
• Chiffrement par version sous une clé tenue hors de la base
• Accès en refus par défaut, et chaque lecture journalisée avant que le contenu ne soit renvoyé
• Destruction en détruisant la clé
• Dit au moment du changement que passer en sécurisé n'annule pas le fait d'avoir stocké quelque chose en clair

Des listes d'alerte qui devraient être vides, et les vues de gestion qui valent d'être discutées.

• Une liste d'alerte ne contient que ce qui sort du cadre — une liste vide est le bon résultat
• Une alerte dont le modèle n'est pas installé se signale comme sans objet plutôt qu'en échouant
• La responsabilité non plafonnée montrée comme une liste, jamais comme un nombre ajouté à un total
• Le délai de cycle ventilé par côté, parce que les jours où la contrepartie détenait le projet ne sont pas la performance de l'équipe contrats
• Ne dépend que du noyau, et le retirer laisse un système qui fonctionne

Trois lecteurs, une seule arithmétique. Les mêmes nombres calculés une fois et rendus de trois façons, plutôt que redérivés par écran, où ils divergeraient.

• Une vue unique des échéances : dates de contrat dérivées, obligations dans les deux sens, actions convenues en réunion et échéances de prestation
• Contrôle de projet : revenu, main-d'œuvre, coût engagé, marge et écart d'estimation, comme vue stockée pour pouvoir être groupée
• Une vue côté client de l'avancement du travail et de ce qui est dû
• Une vue côté avocat de ce qui lui incombe cette semaine et s'il reste dans l'estimation

Deux règles, et deux seulement — celles qui comparent des enregistrements et ne peuvent donc pas s'exprimer par paramétrage.

• Le territoire d'une sous-licence doit tenir à l'intérieur de celui de sa licence mère
• Deux licences exclusives ne doivent pas se chevaucher
• Tenu à part du pack PI, pour qu'une entreprise puisse installer les types de contrat sans les vérifications
• Sa taille mesure délibérément à quel point les points d'extension de la base fonctionnent bien

Le contrôle des conflits à l'entrée d'un contrat, comme à l'ouverture d'un dossier. Il bloque le changement d'étape ; il n'avertit pas.

• Une contrepartie vérifiée au regard des clients existants, des parties adverses sur les dossiers en cours, et des affiliés connus
• Bloque le changement d'étape plutôt que de lever un avertissement que l'on peut écarter
• La vérification elle-même immuable une fois consignée — qui l'a faite, sur quel périmètre, et ce qu'elle a trouvé

Le pack de départ. Installez le noyau et celui-ci, et une entreprise peut gérer ses contrats dès le premier jour sans rien paramétrer.

• Accords de confidentialité, accords-cadres, énoncés de travaux, services, conseil, fourniture et achat
• Les conditions que chaque type porte et le flux qu'il traverse
• Des garde-fous qui empêchent un contrat d'atteindre la signature à moitié formé
• Aucun Python — et les packs spécialisés dépendent de celui-ci plutôt que de redéclarer ce dont tout le monde a besoin

Emploi, engagement de contractuels, conseil et transaction.

• Types d'accord, types de condition, bibliothèque de clauses et guide de négociation pour la contractualisation d'emploi
• Gabarits d'obligation pour le préavis, la période d'essai et les conditions post-rupture
• Les transactions sont sécurisées par défaut — chaque mot compte, et un régulateur y revient plus tard
• Des données seulement, et aucun module de règles

Cabinets d'avocats — contrats pour les clients et avec eux — et directions juridiques internes. Le même système sert les deux métiers avec des valeurs par défaut nettement différentes.

• Lettres de mission, provisions sur honoraires et instructions au conseil
• Une bibliothèque de clauses où la formulation réglementée est marquée obligatoire
• La lettre de mission d'un cabinet est confidentielle et détaillée par défaut
• Les conventions d'honoraires conditionnels portent une formulation qu'on ne peut pas retirer
• Le contrôle des conflits vit dans contract_legal_rules, parce qu'il compare des parties d'un dossier à l'autre

Donneurs de licence, titulaires de brevets et de marques, bureaux de transfert de technologie, universités et propriétaires de marques.

• Licences, cessions et options comme types d'accord, avec des types de condition de licence
• Bibliothèque de clauses, guide de négociation et gabarits d'obligation
• Pas de registre d'actifs, délibérément — l'historique de procédure d'un brevet appartient au système de portefeuille qui le détient déjà
• Les deux règles qu'un pack ne peut pas exprimer vivent dans le contract_ip_rules facultatif

Baux, promesses de bail, licences d'occupation, ventes, servitudes et les actes qui se rattachent à un bail.

• Les dates de résiliation comme conditions pilotant des dates, parce qu'un droit de résiliation expire en silence
• La fenêtre de préavis comme obligation dérivée de la date de résiliation, les deux s'escaladant
• Conditions de révision de loyer, de charges et de remise en état
• Des données seulement, et aucun module de règles

Documents de dette : conventions de crédit, garanties, sûretés, conventions intercréanciers et de subordination.

• Des covenants financiers comme conditions structurées, avec des dates de test dérivées
• Le certificat de conformité comme obligation avec preuve exigée
• « Quelles lignes sont testées ce trimestre, et sur quels chiffres ? » devient une question avec une réponse
• Il documente la dette ; il ne la comptabilise pas — soldes et charges à payer restent en comptabilité
• Des données seulement, et aucun module de règles

Marchés principaux, sous-traitances, missions de maîtrise d'œuvre, garanties annexes et les instruments qui les entourent.

• Bâti autour de la chaîne : un marché principal promet une date que seules les sous-traitances peuvent tenir
• Des conditions en miroir tenues comme conditions structurées pour être comparées tout au long de la chaîne
• Une responsabilité que les sous-traitances et l'assurance responsabilité professionnelle doivent porter
• Des données seulement, et aucun module de règles

Accords de sous-traitance, business associate agreements et conditions de sous-traitance ultérieure.

• Types d'accord DPA, BAA et sous-traitant ultérieur avec les conditions qu'ils portent
• La fenêtre de notification d'atteinte comme condition à part entière, parce qu'elle se mesure en heures
• Réponse à un audit et avis de sous-traitance ultérieure comme dates dérivées
• Des données seulement, et aucun module de règles