142 piezas, y para qué sirve cada una.

Entrar en la aplicación, y el control de edad que decide si una cuenta puede usarse siquiera.

• Pantalla de bienvenida y dirección en el primer arranque, para que quien vuelve aterrice donde lo dejó
• Registro y acceso contra la pasarela, con los tokens guardados en almacenamiento seguro
• Restablecimiento de la contraseña por correo electrónico
• El control de mayoría de edad, mostrado antes de poder comprar nada

La comprobación que permite a alguien hacer transacciones, incluidos los estados en los que queda una persona mientras un humano revisa lo que el paso automático no pudo resolver.

• Una introducción guiada que explica qué se pide y por qué
• Captura de escaneo facial, y la comprobación de documento como vía alternativa
• Estados de resultado dudoso y en revisión, para que la persona nunca quede sin saber
• El estado de verificación se traslada a lo que la cuenta tiene permitido hacer

La primera pestaña. Un canal ordenado de artículos, vídeos y novedades, junto con los editores que hay detrás.

• Un canal de contenidos ordenado, servido por la pasarela
• Detalle del contenido con imágenes y texto enriquecido
• Perfiles de editores, para que un lector pueda seguir una fuente

Herramientas autoguiadas: evaluaciones que la persona hace por sí misma, sus resultados y las funciones de pareja construidas a su alrededor.

• Hacer una evaluación y leer sus resultados
• El mapa de preferencias — una vista personal y una compartida
• Añadir, unirse, invitar y comparar parejas
• Detalle de la pareja, para que una comparación se pueda leer en lugar de ser una puntuación

El directorio tal como lo encuentra un paciente: explorar, comparar, guardar, preguntar y el chat que viene después.

• Explorar y filtrar el directorio de profesionales
• Un perfil con titulaciones, idiomas, servicios y valoraciones
• Profesionales guardados — Mis profesionales
• Chatear con un profesional, y la lista de esas conversaciones
• Solicitudes de consulta, para una pregunta que todavía no es una reserva

Lo que realmente se puede reservar, con el precio, la duración y si es en línea o presencial.

• Explorar los servicios que ofrece la clínica
• Detalle del servicio con precio, duración y modalidad
• Directamente a la reserva o la compra desde el servicio

Comprar — una sesión suelta, un paquete o un producto. De aquí sale el crédito que el paciente gastará después.

• Catálogo de productos y detalle del producto
• Carrito, pago y el acuerdo de servicio aceptado en la compra
• Confirmación del pedido, y el historial de pedidos que hay detrás
• El pago lo gestiona la pasarela, nunca la aplicación

Gastar un crédito en una hora concreta de una agenda concreta — y todo lo que el paciente ve después sobre ello.

• Crear una reserva sobre disponibilidad real, en la zona horaria del propio paciente
• La lista de reservas, con todos los estados que puede tener una sesión
• Detalle de la reserva: enlace para unirse, ubicación y sala, cambio de fecha y cancelación
• Sesiones compradas — créditos disponibles, gastados y pendientes de reservar

Preguntar en público, preguntar en privado, y las personas con las que un paciente elige compartir su evolución.

• Un canal público de preguntas, y preguntar antes de comprometerse a nada
• Detalle de la pregunta con la respuesta del propio profesional
• Incidencias de soporte — abrir una, seguirla y leer las respuestas
• Invitaciones de pareja y la lista de parejas

La tercera pestaña, y la respuesta a la mayoría de las consultas de soporte. Todo lo que la aplicación sabe de la persona, en una pantalla.

• Sesiones reservadas e historial de sesiones, con comentarios y valoraciones
• Créditos, sesiones compradas y favoritos
• Dirección de facturación, facturas, detalle de factura, métodos de pago
• Notificaciones, chats con profesionales, chats de pareja y preguntas hechas
• Mis servicios y mis contenidos, para quien publica
• Editar el perfil, cambiar la contraseña y las pantallas de la cuenta

La misma pestaña, vista por un profesional. Es lo que permite llevar toda una consulta desde un teléfono en lugar de desde un escritorio.

• Disponibilidad: horario semanal y excepciones con fecha
• Los chats de los pacientes, y el historial del paciente detrás de cada conversación
• Enviar un informe de sesión desde la sesión a la que pertenece
• Analítica del profesional — el embudo de reservas, la antelación y las cifras por paciente
• Ingresos y los cuatro compartimentos, ocultos y sustituidos por recuentos en un contrato asalariado

Un asistente conversacional en la aplicación, transmitido a través de la pasarela para que ninguna credencial del modelo llegue nunca al dispositivo.

• Una pantalla de chat con respuestas en tiempo real
• Historial de conversaciones, para poder retomar un hilo más tarde
• Encaminado por la interfaz de IA de la pasarela, que resuelve a un proveedor real o a uno simulado

Los controles que una persona espera encontrar, incluidos los que un regulador espera que pueda encontrar.

• Ajustes de la aplicación y selección de idioma entre 23 idiomas
• Ajustes de privacidad, y qué notificaciones llegan por qué canal
• Ajustes de seguridad, incluidas las sesiones de dispositivo
• Condiciones, política de privacidad y documentos legales dentro de la aplicación, no en una web
• Eliminación de la cuenta, como un camino que la persona puede recorrer por sí misma

Aquello sobre lo que se construye cada función anterior. No es una pantalla, sino la razón de que las pantallas se comporten de forma coherente.

• Red contra la pasarela, con la renovación de tokens y la gestión de errores en un solo lugar
• Almacenamiento seguro para los tokens y el estado protegido del dispositivo
• Enrutamiento, para que una notificación pueda abrir exactamente la pantalla a la que se refiere
• Un único tema que aplica el sistema de diseño de Raznameh
• 23 archivos de traducción, con el sistema de calendario siguiendo a la persona, no al negocio
• Componentes compartidos, para que una lista, un estado vacío y un error se vean igual en todas partes

Intermedia el acceso contra el núcleo de negocio y emite sus propios tokens de corta duración. La aplicación nunca guarda una credencial del núcleo.

• Acceso, registro, renovación y cierre de sesión, con JWT emitido por la pasarela
• El usuario actual y su perfil
• Registro de dispositivos, para que las notificaciones lleguen al terminal correcto
• Documentos legales y la aceptación registrada a nombre de una persona

Todo lo que un paciente explora antes de gastar nada, servido con rapidez y en caché allí donde sale caro.

• Los profesionales, sus perfiles, su disponibilidad y sus servicios
• Categorías de servicios y productos reservables
• Valoraciones y puntuaciones, respetando el estado de moderación
• Lecturas en caché para todo lo que el directorio consulta una y otra vez

La mitad transaccional. Compra, crédito, reserva, factura y pago, cada uno trasladado al núcleo de negocio en lugar de reimplementado.

• Crear, cambiar de fecha y cancelar una reserva, con la política que aplica el núcleo
• Los pedidos y los créditos que generan
• Facturas y documentos de factura
• Inicio y confirmación del pago, tras una interfaz de pagos

La mitad de lectura intensiva: lo que una persona explora cuando no está reservando.

• El canal de contenidos ordenado y el detalle del contenido
• Preguntas y respuestas públicas
• Descubrimiento, evaluaciones y sus resultados
• Funciones de pareja y las comparaciones construidas sobre ellas

El centro de WebSocket. Chat, presencia, transmisión de IA y señalización de voz y vídeo, en una sola conexión.

• Gestión de la conexión WebSocket y de la presencia
• Chat entre paciente y profesional, y canales de grupo
• Señalización para llamadas de voz y vídeo
• Entrega de notificaciones y ajustes de notificación por persona
• Notificaciones push mediante Firebase Cloud Messaging

Los archivos, guardados de forma que la aplicación nunca habla directamente con el almacenamiento y nada se sirve desde una URL adivinable.

• Acceso seguro a documentos, respetando las reglas de acceso del núcleo en lugar de volver a decidirlas
• Subida y recuperación de multimedia, a través de la pasarela
• Imágenes redimensionadas y en caché, para que un listado del directorio sea ligero en un teléfono

El resto: abrir una incidencia, pedir una consulta, decirle a la aplicación qué ha activado esta instalación y hablar con un modelo.

• Incidencias de soporte y sus respuestas
• Solicitudes de consulta
• Configuración en tiempo de ejecución, para que la aplicación muestre solo las funciones que este negocio ha activado
• Peticiones de IA, transmitidas en tiempo real, con la credencial del modelo guardada aquí y en ningún otro sitio

Cuatro indicadores de función, cada uno resuelto a un proveedor real o a uno simulado. Por eso todo el sistema se puede demostrar, desarrollar y probar sin ninguna cuenta externa.

• DATA_SOURCE — el núcleo de negocio Odoo, o un conjunto de datos simulado
• PAYMENTS — un proveedor real, o uno simulado que se comporta como tal
• NOTIFICATIONS — Firebase Cloud Messaging, o uno simulado
• AI — un proveedor de modelos real, o uno simulado
• Limitación de frecuencia y cubos de tokens en Redis, para que un límite se mantenga entre procesos
• Ningún proveedor externo puede impedir por sí solo que la clínica venda, preste y registre una sesión

El motor de agenda que hay debajo de todo lo demás — calendarios, disponibilidad, salas y las reglas que deciden qué huecos puede ver realmente un paciente.

• Un motor de disponibilidad que convierte el horario semanal, las excepciones con fecha y las reservas existentes en huecos libres
• Planificadores, anfitriones, ubicaciones y salas, con aforo y detección de solapamientos
• Reglas de huecos, listas de espera y ofertas automáticas de hueco cuando se libera una reserva
• Preguntas de admisión hechas en el momento de reservar, con las respuestas guardadas en la reserva
• Recordatorios por correo electrónico y SMS, con listas de exclusión por persona
• Publicación del calendario en ICS, y enlaces a sistemas de calendario externos
• Registros de asistencia, un embudo de reservas y la analítica que hay detrás de las cifras por profesional
• Limitación de frecuencia en las rutas públicas de reserva, y una vía de supresión de los datos de reservas

Vende sesiones individuales como créditos. Es el módulo que separa comprar y reservar en dos pasos, lo que permite vender hoy un paquete y programarlo a lo largo de meses.

• Sesiones vendidas como créditos sobre un producto, sueltas o en paquete
• Acuerdos de servicio del paquete aceptados en la compra y conservados en la versión aceptada
• Políticas de cancelación escalonadas, con plazos de preaviso, penalizaciones y un periodo de gracia
• Flujos de cambio de fecha y de cancelación que devuelven el crédito cuando la política lo dice
• Los compartimentos del profesional — comprado, reservado, celebrado, sin reservar — y la evolución por profesional
• Enlaces de reserva en el portal, y controles en el carrito de la web que impiden una compra que no se podría reservar
• Un punto de conexión para el pago: la sesión congela su propio reparto al reservarse sin saber qué es un contrato
• Comentarios tras la sesión, y el rastro de ausencias que necesitan los informes de fiabilidad

La capa de aplicación: los profesionales y sus perfiles públicos, la API móvil, contenidos y comunidad, notificaciones y la cuenta del paciente.

• Perfiles de profesional con un flujo de verificación, credenciales, servicios y calendarios
• Valoraciones, puntuaciones, preguntas públicas y el panel del profesional que hay detrás
• Endpoints REST para la aplicación móvil, autenticación JWT y sesiones WebSocket
• Chat en tiempo real — de paciente a profesional, chats de pareja y canales de grupo — vinculado a las sesiones
• Contenidos y publicación: perfiles de editor, un canal ordenado y descubrimiento
• Facturas, métodos de pago y el puente del pedido a la sesión
• Notificaciones por push, correo electrónico y dentro de la aplicación, con distribución de avisos de sesión
• Verificación de edad e identidad, incidencias de soporte, solicitudes de consulta y registro de dispositivos

Apps de OdooOnDelights Platform

Los diecisiete informes de gestión. Doce preguntan si el registro de la clínica coincide con lo que ocurrió; cuatro comparan cómo les va a los profesionales; uno está por encima de todos.

• Listas de conciliación: sesiones atascadas, créditos sin reservar, cobertura frente a demanda, cadena del dinero, registro de cargos
• Preparación de pagos, conducta de cancelación, expediente de cumplimiento, continuidad de pacientes y la cola de moderación
• Sesiones sin informe, y sesiones canceladas leídas junto con la conducta
• Rendimiento: la ficha del profesional, la clasificación, la fiabilidad y los resultados de los pacientes
• Un único control de alcance — todo el negocio, personas seleccionadas, una persona — con un periodo de comparación
• Vistas guardadas y exportación a CSV en cada informe
• Un informe nunca escribe: desinstalarlo elimina los informes y no cambia ningún comportamiento operativo

La nota clínica que un profesional registra tras una sesión celebrada — guardada como documento seguro sobre el paciente, no como adjunto de una reunión.

• Un informe registrado en la sesión y anotado como relativo al paciente
• Cifrado en reposo en el servicio de documentos seguros, con una clave por versión
• El acceso lo decide solo el equipo asistencial, nunca un rol ni la antigüedad
• Las correcciones se registran como versiones nuevas; la anterior queda exactamente como estaba
• Cada lectura queda registrada, de modo que perseguir un informe que falta nunca obliga a leer uno

Un acuerdo permanente en lugar de una compra cada vez: un plan vendido en la tienda, y la membresía de un paciente sobre él.

• Los planes son productos de la tienda con imagen y descripción; el catálogo público está en /memberships
• Una membresía incluye créditos de sesión, acceso al chat y minutos de consulta fuera de sesión
• Los créditos siguen siendo créditos de sesión ordinarios, así que la reserva nunca tiene que aprender un segundo reglamento
• Periodos con renovación y traspaso, y el plan decide qué se traspasa
• Un profesional ve cuáles de sus pacientes son miembros, y de qué plan

Tiempo de un profesional comprado en minutos en lugar de como cita, gastado en el chat y contabilizado al minuto.

• Un servicio puede vender una bolsa de minutos del profesional, con un plazo de validez opcional
• Tarifa definida en la empresa, que se puede sobrescribir por servicio
• Un asiento por cada cargo, y un extracto que pueden abrir tanto el paciente como el profesional
• La bolsa se comprueba donde se envía el mensaje, no donde alguien se acuerda de comprobarla

El cuestionario que un paciente rellena antes de la primera sesión, guardado como contenido clínico y no como respuestas de encuesta.

• Un servicio indica qué cuestionario lo acompaña
• El paciente lo rellena antes de la sesión, desde sus propias páginas
• Las respuestas se escriben directamente en un documento cifrado — nunca se quedan en el almacenamiento de la encuesta
• El profesional lo abre desde la sesión, con las reglas de acceso a documentos habituales

La transferencia bancaria como vía de pago, para las clínicas que quieren que una persona revise cada pedido antes y después de que se mueva el dinero.

• Aprobar el pedido, facturarlo, recibir el justificante de la transferencia, aprobarlo y, entonces, emitir los créditos
• Los créditos aparecen solo cuando se aprueba el justificante, así que un pedido impagado no puede reservar una sesión
• Un rechazo lleva su motivo, y el pedido vuelve a quien puede resolverlo
• Cada paso es un estado del pedido, no una nota que alguien dejó

La mitad de la vía offline que ve el paciente: dónde paga, qué sube y a qué está esperando el pedido.

• Cada estado tiene su propio color y marca en Mis pedidos, para que esperar se distinga a simple vista de un rechazo
• Pagar y subir el justificante en un solo cuadro de diálogo, sin salir del pedido
• El motivo del rechazo se muestra donde lo va a leer la persona que tiene que actuar
• Una tarjeta en el panel para los pedidos que necesitan algo del paciente

Los libros, en un panel propio: qué ha entrado, qué se debe, cuánto ha costado la prestación y qué está por venir. Separado del de administración a propósito — perseguir una factura impagada en el día a día es un trabajo, y llevar el libro mayor es otro.

• Una página de inicio con cuatro recuadros de importes, seis ratios de salud, seis gráficos y una lista de alertas
• Veintiún informes: caja, ingresos, coste de prestación, previsión, fugas y dos listas de verificación de control
• Devengo o caja, cinco periodos y un intervalo personalizado, conservados en cada informe de detalle
• Acotar cualquier informe por servicio, profesional o paciente; vista de gráfico y CSV en cada página
• Nada compensado, ninguna tasa sin denominador, las capas de la previsión nunca sumadas
• Una lista de verificación de cierre de mes en la que todo marcado es un buen cierre
• Lee el libro mayor y nunca contenido clínico — una concesión aparte, sobre una cuenta interna

What needs doing, for the four teams around the clinic. Sales, people, marketing and delivery each get a page, and every page opens with the same question: what is late, what is now, what is coming, and what has nobody promised to act on.

• Four dashboards, each a record rather than code, so a pack can add one
• The activity strip on every page: late · today · planned · nothing scheduled · needs attention
• **Nothing scheduled** is the band Odoo has no state for — an open record nobody has promised to do anything about, which appears on no other screen
• The attention rule is printed under its own count, because a threshold the reader cannot see is one they stop trusting
• Twenty-six reports, each carrying the code of the specification row it implements
• A figure whose model is not installed reports *not applicable*, never zero
• Lists that should be empty, with a nightly alert that ships switched off
• Every rate prints its denominator, and an em dash under five records
• Today's presence and absence — still checked in, checked in today, on leave today
• Depends on base, mail and web and nothing else: it reports on CRM, HR, mailing, project and contract data without requiring any of it

How we are doing, in the app managers already open. Four pages in Odoo's own Dashboards, in a Clinic Teams section of their own, built the way its Sales and Expenses pages are built.

• Four pages — CRM, Sales, Delivery, People — beside Odoo's own
• Four KPI tiles a page, each with the previous period beside it
• Two charts and two to four top-N tables a page, every one opening the records behind it
• A figure that is a state of the world takes no period and shows no comparison — headcount filtered to the last ninety days is not headcount
• A chart grouped by a date takes the period; one grouped by a stage does not
• The workbooks are generated and their cross-references validated before anything is written
• Each page is visible to the Odoo group that owns its data, so nothing extra is granted

Three more pages in the same section, kept apart because each one needs an app the clinic may not run.

• Attendance: currently checked in, records, hours worked, extra hours, by employee and by department
• Time off: requests awaiting an answer, days approved, refusals, and where leave falls by month, type and department
• Staff payments: to report, to validate, to reimburse, and what was claimed in the period
• Separate from the other dashboards because each forces an app — attendance, time off, expenses
• Attendance counts records, not people: a lunch break makes one person two rows, and the page says so
• Currently checked in is a presence figure during the working day and a list of people who forgot to check out after it

Un formulario público que convierte una pregunta en una tarea de la que alguien es responsable.

• Un formulario en /support/ticket que puede usar cualquiera, con sesión iniciada o no
• Cada envío abre una tarea, asignada al administrador de la tienda
• Quien la envía sigue su propia incidencia, y el administrador recibe el aviso en Discuss

Un proceso asistencial con un inicio, un final y un plan — la columna de la que cuelga todo lo demás en la historia clínica. La asistencia no es una sucesión de citas, y el registro lo refleja.

• Un episodio se abre con la primera sesión celebrada, y un paciente tiene uno abierto cada vez
• Un plan de tratamiento por episodio: problema → objetivo → meta, tres niveles y ni uno más
• Un objetivo lleva un título, una fecha prevista y un resultado — hacia qué se trabajó, y cómo fue
• En curso o Finalizado como estado seguro para el paciente, separado de los seis resultados clínicos para que ambos nunca compartan pantalla
• Un plan se revisa o se sustituye, nunca se edita sobre sí mismo: la versión acordada queda como estaba
• Cerrar un episodio pide un resultado para cada objetivo abierto, porque es el único momento en que alguien conoce la respuesta — y dice cuántos se cerrarían sin él
• El cierre pone en marcha el plazo de conservación desde el que cuenta el servicio de documentos
• Todo profesional que ha atendido al paciente ve el episodio; leer el informe de un colega es una solicitud aparte, aprobada por la administración de la clínica y registrada en cualquier caso
• El paciente lee el mismo episodio en sus propias páginas, con palabras que nunca le califican

Plantillas de nota como una lista ordenada de campos tipados, para que una nota sea un conjunto de respuestas y no una prosa en la que nadie puede buscar.

• Una plantilla es una lista versionada y publicada de campos tipados — texto, número, escala, opción, fecha
• Una nota completada son las respuestas más un documento seguro generado
• Las respuestas se pueden leer exactamente cuando se puede leer su documento: una regla de acceso, no dos que se van separando
• Visibilidad por campo, para que una observación privada no esté en la copia del paciente en lugar de estar oculta en ella
• Las plantillas se eligen en el formulario del informe de sesión, por disciplina

El contenido de partida del motor de plantillas: mil formatos de nota con nombre, para que una clínica no empiece con una biblioteca vacía.

• Más de mil plantillas con nombre — SOAP, DAP, BIRP, admisión, revisión — agrupadas por disciplina
• Instaladas como datos, editables después como cualquier plantilla que redacte la propia clínica

Lo que un paciente registra entre sesiones, vinculado al objetivo que mide. Un programa que no informa sobre nada es como el seguimiento se convierte en deberes.

• Una biblioteca de programas con seis tipos de elemento: cuestionario, medición, opción, diario, archivo, tarea
• Un programa se envía a un objetivo, de modo que cada registro informa sobre algo que el plan pidió de verdad
• El paciente registra sobre su propio plan: primero lo que toca hoy, luego cada objetivo y lo pendiente en él
• Nada en una pantalla del paciente le cuenta ni le puntúa — algo no registrado se lee como no registrado, y no hay tasa, ni puntuación, ni racha
• La cartera del profesional, de peor a mejor: alertas de riesgo por confirmar, programas nunca iniciados, silencios de más de catorce días, lo que termina esta semana
• Una tasa con menos de cinco datos se muestra como un guion, y un recuento que falló se muestra como no disponible — nunca como cero
• «Me está costando», que llega al profesional sin ningún número asociado
• Informes registrados sobre un objetivo y no sobre una cita, cifrados, con las mismas reglas de acceso que cualquier otro informe clínico
• Los programas se revisan en una sesión, y lo cuenta el informe de la clínica que pregunta si alguien los miró
• Toda pantalla que muestra observaciones advierte de que los registros no se supervisan en tiempo real

Instrumentos puntuados propiedad de la clínica. No se incluye ningún contenido de instrumento ni se reclama ninguna licencia: la clínica introduce lo que tiene derecho a usar.

• Una puntuación se guarda con la versión del instrumento que la produjo, y nunca se recalcula
• Tramos y umbrales por instrumento, y un tramo de riesgo genera una alerta que alguien tiene que confirmar
• Lo rellena el paciente en el portal o durante la sesión, y el canal queda registrado en ambos casos
• Evolución por instrumento con su tendencia; las puntuaciones de instrumentos distintos nunca se combinan en un número, porque miden cosas distintas en escalas distintas
• Un cuestionario es un tipo de elemento de programa, no una función aparte con su propia lista

Una nota escrita una vez y archivada a cada asistente como su propio documento.

• Una fuente redactada, un documento archivado por cada paciente asistente
• Un campo privado no está en el documento de otro asistente, en lugar de estar oculto dentro de él
• Se archiva a quienes asistieron, no a todos los que estaban reservados
• La sesión cuenta como documentada solo cuando cada asistente tiene su copia

Una fecha de revisión que el profesional fija al terminar una sesión, y sobre la que se actúa cuando llega.

• Un recordatorio es una fecha y un motivo, creado al final de una sesión
• Invita; nunca reserva
• Los recordatorios vencidos aparecen en el resumen de la clínica antes de que se envíe ningún mensaje automáticamente
• La invitación automática está desactivada salvo que la clínica la active

Códigos diagnósticos allí donde la facturación los necesita, con búsqueda en lugar de escritos de memoria.

• Capítulos y códigos CIE-10-MC con búsqueda
• Un código registrado en el paciente y trasladado a pedidos y facturas

Las condiciones de pago por sesión en el contrato laboral, y el ciclo de pago que las liquida. Nada se recalcula en el momento del pago — cada sesión congeló su propio reparto al reservarse.

• Cuatro tipos de pago: salario mensual, tarifa por hora, importe fijo por sesión o un porcentaje de cada sesión
• Las condiciones viven en la versión del contrato, así que el historial queda fechado y solo una está en vigor cada vez
• Ciclos de pago — semanal, quincenal, mensual o trimestral — anclados al calendario o al inicio del contrato
• Un proceso diario que abre un ciclo de pago en borrador la mañana en que se cierra un ciclo
• Confirmar un ciclo genera una factura de proveedor por profesional a partir de los importes congelados
• Un historial de pagos que el profesional puede ver, incluidos los ciclos cancelados
• Renegociar hoy nunca reescribe lo que se debía el mes pasado

Envía a firmar los contratos de colaboración desde el registro al que pertenecen, y conserva en él el historial de firmas.

• Enviar un contrato a firmar desde el propio contrato
• Cada solicitud se conserva en ese registro como su historial
• El pago de sesiones puede retenerse bajo un contrato que nadie ha firmado todavía
• Se instala solo cuando están presentes las dos partes, para que ningún módulo cargue con una dependencia que no necesita

El servicio en sí. Un modelo lo adopta con una línea y obtiene sus documentos, un recuento y un diálogo de archivo que dice en lenguaje llano quién podrá abrir el resultado antes de guardarlo.

• Cifrado en reposo con una clave propia, guardado fuera del almacén de ficheros de Odoo y nunca servido por /web/content
• Acceso por reglas explícitas, denegado por defecto: una regla de permiso que coincida y ninguna de denegación que coincida, siempre
• Ser administrador, responsable o quien lo archivó no concede nada por sí solo
• Cada lectura, igual que cada escritura, queda registrada en un registro encadenado por hash, de solo anexado, que nadie puede editar
• Versionado y de solo anexado: una corrección es una versión nueva y la anterior queda intacta
• Conservación y eliminación con reglas relativas, ejecutadas destruyendo la clave
• Deliberadamente no busca dentro de los documentos: el contenido cifrado no admite búsqueda de texto completo

La capa criptográfica, en un módulo propio para que la gestión de claves pueda revisarse y auditarse sin leer el resto de la aplicación.

• Cifrado de sobre AES-256-GCM: una clave de datos aleatoria por versión de documento, envuelta con una clave del despliegue
• La clave de cifrado de claves nunca se guarda en la base de datos
• El texto cifrado en un directorio propio, fuera del almacén de ficheros
• Rotación de claves que vuelve a envolverlas sin reescribir ni un byte del texto cifrado
• Destrucción criptográfica: destruir la clave elimina el documento y deja intacto el registro de auditoría
• Se niega a arrancar si la clave falta, es legible por todos, pertenece al usuario equivocado o está guardada donde viajaría con los datos

Donde una persona lee los documentos sobre sí misma que se han compartido con ella, en /my/documents — y solo esos.

• El interesado ve un documento cuando una regla de acceso del interesado se lo concede y nada lo deniega — nunca solo porque trate sobre él
• Las notas de psicoterapia, los documentos sellados y los que están bajo una decisión de retención vigente no se muestran nunca, digan lo que digan sus reglas
• Un único filtro que usan todas las rutas, para que solo exista una definición de quién puede ver qué
• Contenido descifrado en memoria y transmitido; nada se escribe en disco
• Un documento que el usuario no puede ver devuelve 404, nunca 403: adivinar referencias no debe revelar quién tiene historia
• Cada visualización y descarga queda registrada, también las del propio interesado, y la página lo indica
• Lecturas limitadas por usuario, contadas desde el registro de accesos para que el límite se mantenga entre procesos

Archiva documentos seguros contra contactos — el sujeto más habitual, porque la persona de la que trata un documento suele ser aquella contra la que se archiva.

• Añade el servicio de documentos seguros a res.partner
• Se instala solo cuando ambos lados están presentes y se desinstala sin tocar ninguno
• Un puente por aplicación, para que adoptar el servicio en un contacto no arrastre aplicaciones ajenas

Archiva documentos seguros contra oportunidades — un dosier de due diligence no tiene nada de clínico y exige exactamente lo mismo.

• Añade el servicio de documentos seguros a crm.lead
• Cifrado, sujeto a reglas y registrado en cada lectura, como cualquier otro documento seguro
• Se instala y desinstala limpiamente y con independencia de los demás puentes

Archiva documentos seguros contra fichas de empleado — un expediente disciplinario o un informe de salud laboral es algo que archiva un responsable y que la mayor parte de RR. HH. no debe poder abrir.

• Añade el servicio de documentos seguros a hr.employee
• Acceso denegado por defecto, para que un rol de RR. HH. no abra un expediente por el mero hecho de serlo
• Se instala y desinstala limpiamente y con independencia de los demás puentes

Archiva documentos seguros contra tareas — un contrato confidencial o un entregable firmado, guardado donde se sigue el trabajo.

• Añade el servicio de documentos seguros a project.task
• Se instala solo cuando ambos lados están presentes y se desinstala sin tocar ninguno

Archiva documentos seguros contra pedidos — un acuerdo firmado o los documentos de identidad de un cliente, guardados junto a la venta a la que pertenecen.

• Añade el servicio de documentos seguros a sale.order
• Se instala solo cuando ambos lados están presentes y se desinstala sin tocar ninguno

Opcional: saca la clave de cifrado de claves del servidor de Odoo, para que una copia de la base de datos no sea una copia de los documentos.

• Las claves de los documentos se envuelven y desenvuelven a través de una autoridad remota en lugar de localmente
• La clave de cifrado de claves nunca está en la máquina que sirve la aplicación
• Se activa por despliegue; el backend local sigue disponible y sin cambios
• Si la autoridad no responde, se niega a abrir documentos en lugar de recurrir en silencio a otra vía

Resuelve el equipo asistencial. Un terapeuta llega a la historia de las personas de su propia cartera, no a la de toda la clínica — y eso es lo que hace exigible el principio de mínimo necesario en lugar de dejarlo en aspiración.

• Relaciones asistenciales — de profesional a paciente, con un tipo, un inicio y un final
• El acceso termina cuando termina la relación, tras un periodo de gracia suficiente para completar las notas pendientes
• Roles clínicos que deciden a qué parte de la aplicación llega alguien, nunca qué puede abrir
• Un perfil solo para la dirección con incidentes, reclamaciones y derivaciones de protección — cerrado incluso para quien los registró
• El registro de comunicaciones: qué salió del servicio, hacia quién y con qué base
• Derechos del interesado: solicitudes de acceso con su plazo legal, rectificaciones que se añaden en lugar de sobrescribir, limitaciones que sellan
• Anclas de conservación — último contacto, fecha de nacimiento, fecha de defunción — para que la capa base calcule a partir de ellas
• El propio registro de la brecha — qué pasó, a quién afectó y si quien se lo llevó podía leerlo — con las capas jurisdiccionales añadiendo sus plazos a un único incidente en lugar de llevar cada una el suyo
• Comunicaciones confidenciales: un paciente puede pedir que no se use nunca un canal, y se bloquea en el punto de salida de los mensajes, no en la memoria de alguien — un correo a una dirección bloqueada se cancela, nunca se envía en silencio a la dirección que consta
• Ningún campo en ninguna parte para anotar por qué lo pidió, porque exigir una explicación es justo lo que la norma prohíbe
• Una prórroga de una solicitud de acceso y solo una, limitada sobre la fecha resultante y no sobre el número tecleado — un mes desde marzo y un mes desde julio no duran lo mismo
• La tarifa desglosada en los componentes que la norma permite, porque «razonable y basada en costes» es una afirmación, y una afirmación con un solo número detrás es una que nadie puede comprobar
• Una copia a un tercero designado por la persona, denegada hasta que conste su instrucción escrita y firmada
• Una denegación revisada por alguien distinto de quien denegó — impuesto por el sistema, no dejado al procedimiento
• Una rectificación denegada con la que la persona no está de acuerdo: su declaración, la posible réplica y ambas acompañando cada comunicación posterior del registro discutido — adjuntadas por el registro, no por la memoria de nadie
• Quien ya tiene la información aguas abajo queda identificado e informado, porque una rectificación de la que nadie se entera corrige una sola copia del registro

La capa del RGPD: la maquinaria de derechos y gobernanza que HIPAA no tiene, y por eso una instalación con estándar estadounidense no cubre la UE.

• Base jurídica registrada por tipo de documento — art. 9.2.h para la historia asistencial, no el consentimiento
• Supresión (art. 17) ejecutada destruyendo la clave, de modo que se respeta el derecho sin borrar la prueba de lo que se tenía
• Una evaluación de supresión, y nada se destruye mientras haya una retención legal o un plazo de conservación vigente
• Portabilidad (art. 20) como un zip transmitido — metadatos en JSON, contenido tal como se archivó, cada documento registrado por separado
• Notificación de brechas (arts. 33 y 34): 72 horas ante la autoridad, y la exención por cifrado del art. 34.3.a
• EIPD y registro de actividades de tratamiento como parte del expediente de gobernanza

Un puente, no un desarrollo — une un aviso de privacidad firmado con el registro de acuse, para que el expediente pueda decir qué versión vio realmente la persona.

• Una firma completada escribe el acuse una sola vez — un webhook entregado dos veces no debe falsear el recuento de pendientes
• La solicitud de firma nombra la versión del aviso, porque es la única pregunta que se le hace a un acuse
• Un bolígrafo sobre un formulario en recepción sigue siendo un acuse por escrito; el puente añade una vía sin sustituir la ordinaria
• Una solicitud firmada por un profesional en nombre de un paciente no es el acuse de ese paciente, y no cuenta como tal

El UK GDPR y la Data Protection Act 2018 sobre el mismo núcleo técnico — con la prueba de daño grave construida como flujo de trabajo y no como una casilla.

• La prueba de daño grave (DPA 2018, anexo 3, parte 2) registrada con quién decidió, cuándo, sobre qué documentos y por qué
• Solo puede adoptarla alguien con una relación asistencial vigente, algo que el sistema comprueba en lugar de suponer
• Aparece en una cola de revisión antes de caducar y decae por sí sola a los seis meses
• Levantarla restaura la etiqueta que el documento tenía antes, no «normal»
• La retención es frente al interesado, no frente al equipo asistencial — quienes tratan a la persona la siguen leyendo
• El calendario de conservación del NHS Records Management Code of Practice 2021 como datos iniciales
• Tratamiento según la Access to Health Records Act para la historia de personas fallecidas

Las salvaguardas administrativas — la mitad de HIPAA que no trata de cifrado, y la mitad que más citan las sanciones.

• El análisis de riesgos como un ejercicio con periodo, alcance y método, separado del registro de lo que encontró — para poder comparar el año próximo con este
• Cada riesgo se traslada a la siguiente evaluación con un vínculo al anterior, porque un registro que empieza en blanco cada año pierde la constancia de lo decidido
• El riesgo inherente se calcula y el residual deliberadamente no — un residual obtenido restando una puntuación de control es una ficción que dice lo mismo de un control probado la semana pasada que de uno escrito en una política
• Aceptar un riesgo exige un motivo registrado; la decisión suele ser correcta y después nadie puede saber cuál fue
• La revisión de actividad con sus preguntas nombradas — sin relación asistencial, acceso de emergencia, un apellido compartido, fuera de horario, un volumen anómalo — porque «revisar los registros» sin decir qué buscar es como una revisión acaba en una firma sobre nada
• Completar una revisión verifica cada cadena de hash tocada en el periodo, que es lo que convierte un registro a prueba de manipulaciones en uno en el que la manipulación se detecta
• Nombramientos como intervalos de fechas con los huecos calculados, porque el requisito no es quién lo ocupa hoy sino que alguien lo ocupó sin interrupción
• Expedientes sancionadores legibles solo por un grupo al que nadie entra por implicación — un expediente sancionador que se filtra es un incidente en sí mismo
• Una lista de baja y una tarea diaria que la abre para cualquiera cuya fecha de salida ya ha pasado: las cuentas que sobreviven al empleo son el control que más falla
• Formación con caducidad, porque la formación caducada no es formación
• Un análisis de criticidad que comprueba sus propias cuentas: un sistema cuya base de datos se recupera más despacio que él tiene un objetivo de recuperación que alguien escribió, y los dos números viven en filas distintas de una hoja de cálculo
• Planes de contingencia que dicen cuándo se probaron por última vez, y una lista de los que no se probaron nunca — lo único que distingue a una organización con un plan de una que cree tenerlo
• Una prueba que no alcanzó sus objetivos tiene que decir qué falló, porque una prueba que no enseñó nada a nadie no es una evidencia
• La seguridad de las transmisiones como historial y no como afirmación: «usamos HTTPS» habla en presente, y estos registros dicen que era cierto los días por los que alguien pregunta
• Comprobaciones que no se pueden editar ni borrar, porque la gracia de un historial es que no se puede maquillar

La capa HIPAA. La separación de las notas de psicoterapia se sostiene en el almacenamiento en lugar de depender de que las reglas de acceso sean correctas.

• El designated record set (45 CFR 164.501) marcado por tipo de documento, para que una respuesta de acceso no pueda incluir lo que queda fuera de él
• Las notas de psicoterapia en su propio espacio de claves — la clave que abre la historia ordinaria no las abre
• Una concesión al interesado sobre las notas se rechaza por cualquier vía, incluida una escritura directa en la tabla de reglas
• Un documento ya escrito no puede reetiquetarse para pasar al espacio de claves de las notas
• 42 CFR Part 2: el aviso de prohibición de nueva comunicación se genera, no se teclea
• Seis años de comunicaciones en el registro, según la subparte
• Notificación de brechas (164, subparte D): una comunicación no permitida se presume brecha hasta que la evaluación de cuatro factores diga lo contrario, con el razonamiento registrado
• Sesenta días para avisar a las personas desde el descubrimiento, calculados y no tecleados, con aviso antes de que venzan
• Los dos «quinientos» por separado — aviso a los medios por encima de 500 residentes de un Estado, aviso al HHS a partir de 500 en total
• Avisos individuales con los cinco elementos que exige 164.404(c), para que ninguno pueda quedarse fuera de una carta que se lee bien
• El registro anual de brechas pequeñas generado como documento, no reconstruido de memoria en febrero
• El Notice of Privacy Practices versionado, con los acuses registrados contra la versión que se entregó realmente
• La mitad fácil de saltarse: cuando no se obtuvo firma, se exigen el esfuerzo realizado y el motivo — una carpeta de formularios firmados no responde a esa pregunta
• Una lista de trabajo de pacientes sin nada registrado frente al aviso vigente
• Los motivos para denegar el acceso como lista cerrada, cada uno indicando si la persona tiene derecho a revisión — ofrecer una que no existe y negar una que sí existe son ambos hallazgos
• Los cuatro motivos para denegar una rectificación, también cerrados, y el que es un hecho sobre el documento comprobado contra el documento
• La norma Part 2 de 2024: un único consentimiento para tratamiento, pago y operaciones, rechazado si no es revocable — un consentimiento único sin marcha atrás es el que alguien olvida que dio
• Una limitación Part 2 sobre esos fines tratada como un derecho y no como una petición, y comprobada antes que la general — una comprobación en el orden inverso permitiría la comunicación antes de llegar a la pregunta
• Una brecha que afecta a historia de trastornos por consumo de sustancias lo dice en el aviso, en lugar de enterrarlo bajo «información asistencial»
• 164.410 como dos plazos: el encargado tiene sesenta días desde su propio descubrimiento y los nuestros empiezan cuando nos avisa, así que una brecha puede tener 118 días sin que nadie haya incumplido un plazo
• El aviso al paciente de Part 2 versionado junto al aviso de privacidad, en lugar de una constante en Python que nadie versiona

El plazo de conservación alemán, como una regla que el servicio documental cuenta en lugar de una línea de una política que nadie aplica.

• § 630f BGB: diez años desde el último contacto, cargado como regla de conservación
• Limitado a este módulo y no a todo el paquete de la UE, porque el plazo es nacional

The Norwegian rules the GDPR layer does not cover, each one sitting where the action happens rather than in a policy: publishing a profile, confirming a payout run, disclosing something to a parent.

• Pasientjournalforskriften § 14: the patient reads every access to every record about them, including the records they are not shown — by type, never by title
• A retention kind with no disposal date at all, because Norway keeps records while they are needed; the years are a review interval and a person decides, with a reason
• A journal hand-over to a successor, Norsk helsearkiv or Nasjonalarkivet, built at the moment of download, recorded as a disclosure per document, and downloadable once
• Helsepersonelloven § 74: a profile using a protected title cannot be published without a checked HPR number, and the check runs on write so the sync cannot get round it
• Nearest relative, parent, guardian and lasting power of attorney, with the §§ 3-4 and 4-3 age rules enforced at the disclosure register rather than as a filter on a page
• Arbeidsmiljøloven § 1-8: a payout run that pays per session will not confirm without a current determination, and the facts behind it are shown unweighted because the question is legal
• Personvernombud and information security lead as designations, checked for Norwegian companies only

The roles Finnish law makes a provider name, and the duties hanging off each one. Independent of the Norwegian pack — both switch on from the company country, so one database can hold both.

• Licensed and protected-title professionals kept apart, because they are different rights: psykoterapeutti is a protected title in Finland and a free word in Norway
• Terhikki number, the date of the employer check and whether it was a register lookup or the decision document; a typed number counts as declared, not checked
• A service unit with its own registration, and the vastuuhenkilö as a designation per unit, so a fortnight with nobody answering for it is reported
• The public self-monitoring plan and the confidential security plan kept apart by construction: one policy record cannot be flagged as both
• Asiakastietolaki § 11: two years of log information with the recipient and the basis, a written request with a two-month clock, and a withholding recorded with its reason
• Potilaslaki § 9(2) has no age, so a minor is a recorded judgement: without one, a disclosure to a guardian is refused and the refusal says the judgement is missing
• Twelve years after death, and where the death is not known, 120 years from birth

Switzerland splits the qualification from the permission to practise, counts insured sessions against a doctor's order, and binds the supplier to the same criminal secret as the practitioner. Three things the core cannot express, and nothing else.

• The federal title is not the licence: a practice permit is cantonal, one per canton, each with its own expiry, so a practitioner may hold the name in Switzerland and the right to work in only one place
• A profile using a protected title is refused publication without both a checked PsyReg number and a current, checked cantonal licence — and the refusal says which of the two is missing
• Where a title is checked and no licence is, the public status says so rather than implying one; an unverified market is not served by a listing that reads like a verified one
• Anordnungsmodell: fifteen sessions on a doctor's order, renewable once to thirty, and the insurer beyond that — counted through the chain of renewals, warned before the session that would not be paid for, and refused at the second renewal without an approval on file
• Only a delivered session counts; a booked one does not, because counting it would stop an order two sessions early
• Article 321 binds auxiliary persons to the same criminal duty as the practitioner, so the register asks the one question the article turns on: can they read the data in the clear?
• Ten years after the last contact, seeded on the retention clock the document service already had — no second way of saying the same thing
• The cantons each practitioner is licensed in decide which language their authorities correspond in, shown on the practitioner and on every licence
• Insured billing has its shape here and none of its catalogue: a tariff edition, positions in taxation points, point values per canton and insurer class. The positions and point values are licensed data a deployment loads, because a plausible invented code is one somebody bills on
• A session that cannot be priced says which canton has no point value loaded, and shows no amount at all — zero francs would mean the session costs nothing, which is a different statement
• German, French and Italian throughout the interface, in Swiss terms: a Berufsausübungsbewilligung rather than a translated "cantonal licence", and a Hilfsperson rather than an "auxiliary person"

Una lista fija de preguntas que se le hacen al propio despliegue. La mayor parte de la comprobación ya existía y estaba dispersa; esta es la página que la lee en un solo sitio.

• Un registro de comprobaciones, un ejecutor programado y un informe sobre ambos
• Solo se informa de lo que está mal: una comprobación que pasa no dice nada, así que la página está vacía cuando el despliegue está sano
• Cada hallazgo nombra la regla de la que procede y el registro en el que se encontró
• Las ejecuciones se conservan, así que un hallazgo que vuelve una y otra vez se ve como un patrón y no como una novedad

El servicio de firma en sí: una ceremonia de firma en el portal, políticas por jurisdicción y un registro de auditoría encadenado por hash. Alojado en casa, así que ningún documento sale del sistema para firmarse.

• Una ceremonia de firma en el portal que recoge identidad e intención en el momento de firmar
• Un registro de auditoría encadenado por hash que nadie puede editar ni borrar
• Políticas por jurisdicción que rigen qué exige una firma válida
• Las solicitudes de firma como registros, con su propio estado e historial

Quién estaba facultado para firmar por una contraparte y si su credencial sigue vigente — comprobado, no supuesto.

• Facultad para obligar, controlada por firmante de cada contraparte
• Los acuerdos firmados como registros con una vigencia
• Las credenciales de los profesionales reclamadas antes de que caduquen

Lo que una firma clínica necesita además de un nombre: capacidad, facultad para firmar en nombre de otra persona, supervisión y un consentimiento que puede retirarse.

• Declaración de capacidad registrada en el momento de firmar
• Firma en nombre de un paciente, con la facultad registrada
• Firma conjunta del supervisor cuando el servicio la exige
• Un ciclo de vida del consentimiento revocable en lugar de una casilla de una sola vez

Los elementos que HIPAA exige a una autorización, validados en lugar de confiados a una plantilla.

• Validación de los elementos obligatorios de una autorización HIPAA
• El material de 42 CFR Part 2 separado del resto
• El registro de comunicaciones que una entidad cubierta debe presentar cuando se le pide

Una acción «Solicitar firma» en candidatos y empleados, para que una oferta o una política se firme donde la persona ya está.

• Solicitar firma en la ficha de un candidato
• Solicitar firma en la ficha de un empleado
• Las solicitudes se guardan en la ficha como su historial

Una acción «Solicitar firma» en presupuestos y pedidos de compra.

• Solicitar firma en un pedido de venta
• Solicitar firma en un pedido de compra
• El documento firmado se guarda junto al pedido

Pone las plantillas de firma donde vende la clínica: vinculadas a un profesional o a un servicio, enviadas automáticamente al comprar y visibles como un estado.

• Plantillas de firma electrónica vinculadas a un profesional o a un servicio
• Enviadas al comprar, sin que nadie tenga que acordarse de enviarlas
• El estado de firma visible para los profesionales en el portal y en la app móvil

Cierra la sesión que nadie está usando. 45 CFR 164.312(a)(2)(iii) pide terminarla tras un periodo de inactividad predeterminado y deja el periodo a su criterio — así que es un ajuste, con la aplicación en el servidor y no en el navegador.

• Periodo de inactividad, periodo de aviso y un límite absoluto, fijados por empresa
• Comprobado en el servidor en cada petición autenticada, así que desactivar el temporizador del navegador no sirve de nada
• Un aviso antes de que termine la sesión, para que nadie pierda una nota a medio escribir por un control pensado para protegerle
• Un límite absoluto además del de inactividad, porque una sesión que un script mantiene viva sigue siendo una sesión que debe terminar
• Cada cierre queda registrado — quién, en qué superficie y qué regla lo provocó
• El registro es de solo anexado: la prueba de que un control funcionó vale lo que cuesta cambiarla
• Un periodo de cero lo desactiva, una decisión que la norma permite y que su análisis de riesgos deja registrada

Conecta Odoo Community con cualquier modelo de lenguaje grande, detrás de una interfaz — para que el proveedor pueda cambiar sin que la lógica de negocio se entere.

• Proveedores configurados por despliegue, con la credencial fuera del código de la aplicación
• Agentes definidos como prompts con las herramientas que pueden usar
• Llamada a herramientas, para que un modelo pueda actuar y no solo responder
• Ejecuciones registradas, para poder revisar después qué se preguntó y qué se respondió
• Acciones de servidor que pueden dirigirse desde un prompt
• Diagnósticos para comprobar que un proveedor es accesible y está bien configurado

Convertir a mano un usuario entre interno y portal obliga a editar permisos en el orden correcto y recordar los efectos secundarios. Esto lo convierte en un botón.

• Un campo Tipo de usuario en el formulario de usuario, en la lista y en los filtros de búsqueda
• Botones Convertir en interno y Convertir en portal en el formulario de usuario
• Una acción Convertir tipo de usuario en la lista de usuarios, para varios a la vez
• Barreras de seguridad: el usuario del sistema, su propio usuario y el último administrador que queda no pueden convertirse nunca por accidente

Empresas, usuarios, grupos, contactos, idiomas y las reglas de registro que deciden quién ve qué. No aparece en la lista de aplicaciones porque todo depende de él.

• Empresas y separación multiempresa
• Usuarios, grupos y reglas de acceso a nivel de registro
• Los contactos como un único modelo compartido por pacientes, profesionales y proveedores
• Idiomas, traducciones y configuración regional por usuario
• Acciones planificadas — la cola de trabajos detrás de cada tarea nocturna

La interfaz de back-office en la que trabaja el personal, y las herramientas de edición detrás de cada campo de texto enriquecido y cada bloque web.

• Vistas de lista, formulario, kanban, calendario, tabla dinámica y gráfico
• Filtros, agrupaciones y búsquedas guardadas en cada pantalla
• Exportación a CSV y XLSX desde cualquier lista
• Editor HTML — el campo de texto enriquecido que se usa en todos los registros
• Constructor HTML — el editor de bloques de arrastrar y soltar
• Enrutamiento web — la capa de URL por la que se sirve cada página del portal y de la web

Apps de OdooWebWeb RoutingHTML EditorHTML Builder

La mensajería, y el hilo de mensajes que acompaña a cada registro — así es como una decisión conserva su historia en lugar de vivir en la bandeja de entrada de alguien.

• El chatter de cada registro: mensajes, notas, seguidores y cambios de campos registrados
• Canales internos y mensajes directos
• Correo saliente con plantillas, y enrutamiento del entrante
• Actividades — una tarea asignada contra un registro en lugar de a la memoria de alguien
• OdooBot, y su variante de RR. HH. para los avisos de incorporación

Apps de OdooDiscussOdooBotOdooBot - HR

El área autenticada a la que llega un paciente, un profesional o una contraparte sin ser usuario interno — todo lo que cuelga de /my.

• Usuarios de portal sin acceso al back-office
• Documentos, pedidos y facturas compartidos con la persona a la que pertenecen
• El marco dentro del que se construye cada página de portal propia de esta plataforma
• Una página de registro personalizada, para que el alta siga la marca y no la de Odoo por defecto

Apps de OdooCustomer PortalCustomize Signup Page

La aplicación de agenda: personas, organizaciones y las relaciones entre ellas.

• Particulares y empresas, con contactos dependientes
• Direcciones, identificadores fiscales y datos bancarios
• Etiquetas y categorías para segmentar
• El registro al que remiten por igual un paciente, un profesional y un proveedor

Apps de OdooContacts

Lo que se vende. En una clínica son sesiones y bonos, pero el modelo de debajo es el estándar.

• Plantillas de producto y variantes
• Unidades de medida, y productos de servicio por tiempo
• Tarifas, para que un bono o un segmento pueda tener otro precio
• Categorías de producto para informar por línea de servicio

Calendarios laborales, capacidad y ausencias — el modelo en el que se expresan las horas semanales y las excepciones con fecha de un profesional.

• Horarios laborales por persona, con zona horaria
• Capacidad de los recursos y ausencias
• El calendario sobre el que se calcula la ocupación

Apps de OdooResource

Los pequeños módulos instalados que nadie abre a propósito, cada uno de los cuales elimina una categoría concreta de incidencias de soporte.

• Onboarding Toolbox — progreso guiado de la puesta en marcha de un despliegue nuevo
• Validación de números de teléfono — números normalizados al introducirlos, para que el SMS llegue de verdad
• Google reCAPTCHA — protección antispam en los formularios públicos
• Google Gmail — correo saliente a través de una cuenta de Google sin contraseña SMTP

Apps de OdooOnboarding ToolboxPhone Numbers ValidationGoogle reCAPTCHA integrationGoogle Gmail

Presupuestos y pedidos de venta — el registro del que cuelga cada sesión comprada, y el extremo izquierdo de la cadena del dinero.

• Presupuestos, confirmación y pedidos de venta
• Líneas de pedido con las sesiones o bonos comprados
• Estado de prestación y de facturación por línea
• Plantillas de presupuesto, para un bono que se vende una y otra vez
• Equipos de venta y los informes que los acompañan
• El pedido al que se remonta cada crédito, cada factura y cada pago

Apps de OdooSales

El libro mayor. Facturas, facturas de proveedor, pagos, impuestos y conciliación — donde vive de verdad la contabilidad de la clínica.

• Facturas de cliente y facturas rectificativas, con las facturas emitidas inalterables
• Facturas de proveedor — incluidas las que crea un ciclo de pago para los profesionales
• Pagos, extractos bancarios y conciliación
• Impuestos, posiciones fiscales y plan de cuentas
• Diarios, asientos contables y el registro de auditoría que hay detrás
• Balance, cuenta de resultados, antigüedad de cobros y antigüedad de pagos

Apps de OdooInvoicing

Costes e ingresos atribuidos a algo que no es una cuenta — un proyecto, una línea de servicio, un profesional.

• Cuentas y distribuciones analíticas
• Costes e ingresos seguidos por proyecto o por línea de servicio
• La dimensión sobre la que se calculan los informes de margen

El marco en el que se conectan los métodos de pago, para que añadir o cambiar de proveedor sea configuración y no desarrollo.

• Proveedores de pago configurados por empresa
• Tokens de pago, para una tarjeta guardada que el paciente reutiliza
• Transacciones con su propio estado, conciliadas contra facturas
• La costura tras la que se sitúa el indicador PAYMENTS del gateway

Hay tres proveedores activados: un procesador de tarjetas real, uno de demostración para formación y métodos manuales para el dinero que llega fuera de una pasarela.

• Stripe — tarjetas, monederos y métodos de pago guardados
• Demo — un proveedor que se comporta como uno real, para formación y ensayos
• Métodos de pago personalizados — transferencia, efectivo y todo lo que se concilia a mano
• Otros diecisiete proveedores vienen con Odoo y están a un interruptor de distancia

Apps de OdooPayment Provider: StripePayment Provider: DemoPayment Provider: Custom Payment Modes

Descuentos, promociones, tarjetas regalo y programas de fidelización — aplicados igual en un pedido de venta que en el pago del comercio electrónico.

• Códigos de cupón y promociones automáticas
• Tarjetas de fidelización y acumulación de puntos
• Tarjetas regalo y saldos de monedero electrónico
• Reglas de programa por producto, línea de servicio o segmento de clientes

Apps de OdooCoupons & LoyaltySale LoyaltySale Loyalty - Delivery

Lo que gasta el personal, y la parte que se refactura a un paciente en lugar de absorberse.

• Notas de gastos, aprobación y reembolso
• Gastos contabilizados directamente
• Refacturar un gasto indicando en él el pedido de venta
• El lado del coste de un encargo prestado

Apps de OdooExpensesSales Expense

Pedidos de compra y gestión de proveedores — el lado del coste comprometido, y la forma en que llegan las facturas de proveedor.

• Solicitudes de presupuesto y pedidos de compra
• Fichas y tarifas de proveedores
• Facturas de proveedor casadas con los pedidos
• El pedido sobre el que se puede solicitar una firma

Apps de OdooPurchase

Leads y oportunidades — usados aquí para las consultas que todavía no son pacientes y para las solicitudes de consulta que llegan desde la app.

• Leads, oportunidades y un embudo configurable
• Actividades y siguientes pasos para cada oportunidad
• Motivos de pérdida e informes de tasa de éxito
• El modelo contra el que se pueden archivar documentos seguros para un dosier de due diligence

Apps de OdooCRM

Completar lo que un lead no le contó, encontrar leads que nunca se pusieron en contacto y darle a un equipo comercial algo por lo que competir.

• Enriquecimiento de leads — datos de la empresa completados automáticamente a partir del dominio del correo
• Generación de leads — leads obtenidos por sector, tamaño y ubicación
• Gamificación del CRM — objetivos, insignias y clasificaciones sobre el embudo

Apps de OdooLead EnrichmentLead GenerationCRM Gamification

Un widget de chat en la web pública, atendido por personas reales y conectado tanto al embudo como al servicio de ayuda interno de RR. HH.

• Chat en vivo — operadores, canales y respuestas predefinidas
• Chat en vivo en la web — el widget en la web pública y en el directorio
• Chat en vivo del CRM — una conversación convertida en lead sin volver a teclear nada
• Chat en vivo de RR. HH. — el mismo canal usado internamente para las preguntas del personal
• Transcripciones guardadas contra el visitante y, cuando se sabe quién es, contra el contacto

Apps de OdooLive ChatWebsite Live ChatCRM LivechatHR - Livechat

El canal con la tasa de apertura más alta, conectado en los puntos donde una clínica realmente lo necesita. Los recordatorios de sesión ya lo usan.

• Pasarela SMS — la infraestructura de envío y el estado de entrega
• SMS en el CRM — escribir a un lead desde la oportunidad
• Enviar SMS al visitante — y la variante que funciona desde un lead
• Selección - SMS — escribir a un candidato sobre una entrevista
• Exclusión por persona, para que una baja se respete en todas partes

Apps de OdooSMS gatewaySMS in CRMSend SMS to VisitorSend SMS to Visitor with leadsRecruitment - SMS

Una extensión propia en leads y contactos: enviar un mensaje de WhatsApp predefinido sin salir del registro.

• Acción de envío rápido en un lead y en un contacto
• Plantillas de mensaje predefinidas
• El canal que muchos pacientes de este mercado leen de verdad

Apps de OdooCRM Extension v2 - WhatsApp Quick Send

Cifras periódicas enviadas a quienes deben verlas, y atribución de cada enlace que publica el negocio.

• Resúmenes de KPI — un resumen programado enviado por correo a los responsables
• Rastreador de enlaces — enlaces cortos con etiquetas UTM y estadísticas de clics
• Campaña, medio y fuente registrados contra el visitante que convirtió

Apps de OdooKPI DigestsLink Tracker

El constructor de páginas detrás de la web pública — las páginas que marketing edita sin un desarrollador.

• Páginas de arrastrar y soltar con bloques reutilizables
• Páginas multilingües y metadatos SEO
• Menús, temas y versiones de página
• El directorio público y las páginas de perfil de los profesionales

Apps de OdooWebsite

Vender en la web pública: el catálogo, el carrito y el pago por el que pasa un paciente antes de tener ningún crédito.

• Catálogo público de productos y páginas de producto
• Carrito, pago y cobro en la web
• Cuentas de cliente e historial de pedidos
• Los controles del carrito que impiden una compra que no se puede reservar

Apps de OdooeCommerce

La parte editorial: los artículos que aparecen en el feed de contenidos de la app y en la web pública.

• Blogs, entradas, etiquetas y comentarios
• Entradas multilingües
• La fuente de la que lee el feed de contenidos ordenado

Apps de OdooBlog

Los tres puntos en los que un visitante puede crear un registro sin cuenta — cada uno llega a un sitio donde trabaja una persona.

• Formulario de contacto — una consulta que llega como lead, no como correo
• Envío de tareas en línea — un formulario web que crea una tarea de proyecto
• Empleos en línea — vacantes publicadas, y candidaturas que llegan a Selección

Apps de OdooContact FormOnline Task SubmissionOnline Jobs

Tres pequeños módulos que conectan la web pública con el resto del sistema. Nadie los abre; sin ellos se rompe todo.

• Website Mail — suscripciones e hilos de mensajes en páginas públicas
• Website Partner — una página pública para un contacto, que es lo que es un perfil profesional
• Website Payment — el pago en la web conectado al marco de pagos

Apps de OdooWebsite MailWebsite PartnerWebsite Payment

Fichas de empleado y contratos. En Odoo 19 un contrato es una versión del empleado, y esa línea temporal de versiones es la que contiene las condiciones de pago de un profesional.

• Fichas de empleado, departamentos y puestos
• Versiones de contrato con historial fechado, una vigente cada vez
• Horario laboral por empleado
• El registro sobre el que se construyen las condiciones de pago de los profesionales y los ciclos de pago

Apps de OdooEmployees

Para qué está cualificado cada profesional, cuándo caduca esa cualificación y quién depende de quién.

• Gestión de competencias — competencias, niveles y progresión por empleado
• Certificación de competencias — certificados con caducidad, lo que permite reclamar una credencial a tiempo
• Organigrama de RR. HH. — líneas jerárquicas en la ficha del empleado
• Gamificación de RR. HH. — objetivos internos e insignias

Apps de OdooSkills ManagementSkills CertificationHR Org ChartHR Gamification

Candidatos y contratación — y la razón por la que una oferta es uno de los documentos que se le pide gestionar a la firma electrónica.

• Puestos, candidatos y un embudo de contratación
• Programación de entrevistas y fichas de evaluación
• Competencias comparadas con los requisitos del puesto
• La ficha del candidato a la que se puede solicitar una firma

Apps de OdooRecruitmentRecruitment - Skills Management

Desde dónde trabaja cada persona un día concreto — lo que en una clínica significa saber quién está en el centro para recibir a un paciente.

• Días en casa y en la oficina por empleado
• La misma información en el calendario del equipo
• Visible junto al calendario de salas al planificar sesiones presenciales

Apps de OdooRemote WorkRemote Work with calendar

Proyectos y tareas. Se usan para el trabajo de prestación y, en la vertical de contratos, para separar el coste de ganar un contrato del coste de prestarlo.

• Proyectos, tareas y etapas
• Asignación, plazos y avance
• Archivo de documentos por tarea, incluidos documentos seguros
• El proyecto contra el que se informan el coste y el margen del contrato

Apps de OdooProject

Una lista de tareas personal por usuario, separada del trabajo de proyecto — donde van las pequeñas cosas que un responsable recoge durante la rutina de la mañana.

• Tareas privadas con fecha límite
• Convertibles en tarea de proyecto cuando resultan ser trabajo de verdad

Apps de OdooTo-Do

Reuniones y eventos. Cada sesión es un evento de calendario por debajo, lo que hace que los calendarios de salas y de equipo sean reales y no una simple representación.

• Eventos con asistentes, recurrencia y recordatorios
• Disponibilidad visible en todo un equipo
• Sincronización con calendarios externos
• El evento al que se asocia una sesión reservada

Apps de OdooCalendar

Cuestionarios. Se usan aquí para las preguntas de admisión al reservar y para la encuesta privada de valoración después de una sesión.

• Cuestionarios con preguntas condicionales
• Respuestas guardadas contra la persona que respondió
• Puntuación, cuando un cuestionario es una evaluación
• Las preguntas de admisión asociadas a un servicio reservable

Apps de OdooSurveys

Tiempo registrado contra un proyecto o una tarea. Disponible y desactivado en el despliegue de referencia — es una dependencia de la vertical de contratos, no del trabajo clínico.

• Entradas de tiempo contra proyectos y tareas
• Coste por hora a partir de la ficha del empleado
• Aprobación e informes de partes de horas
• Las horas que la facturación de contratos convierte en cifras de recuperación y ocupación

Una línea de formación: eventos de pago o gratuitos, cursos en línea y un foro público — todo vendido por el mismo carrito y registrado en la misma contabilidad.

• Eventos con inscripción, entradas, sesiones paralelas y expositores
• Eventos vendidos como productos a través del pago existente
• Sesiones en directo y cuestionarios para las sesiones en línea
• Cursos de eLearning, con competencias obtenidas al completarlos
• Un foro público, y eventos conectados al embudo del CRM

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

Campañas a listas que el negocio ya tiene. La clínica envía hoy correo y SMS transaccionales; esta es la mitad de marketing de la misma infraestructura.

• Marketing por correo — campañas, plantillas, pruebas A/B y estadísticas
• Marketing por SMS — lo mismo, en el canal con la tasa de apertura más alta
• Envíos masivos dirigidos a leads, oportunidades, asistentes o ponentes de eventos
• Marketing Card — imágenes personalizadas para compartir en una campaña
• Botones de suscripción al boletín en la web, por correo o por SMS

Apps de 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

Para una clínica que también vende algo físico en mostrador — libros, suplementos, kits de pruebas — o que tiene caja en recepción.

• Inventario — existencias, ubicaciones, reaprovisionamiento y valoración
• Punto de venta — una caja que funciona sin conexión y sincroniza
• Descuentos en el punto de venta, y los programas de fidelización ya configurados

Apps de OdooInventoryPoint of SalePoint of Sale - Coupons & LoyaltyPoint of Sale Discounts

El lado de la administración de personal. Relevante cuando una clínica emplea a suficientes personas como para que las ausencias y la presencia ya no quepan en un calendario compartido.

• Ausencias — solicitudes, aprobación, saldos y su efecto en las nóminas
• Asistencias — entrada y salida, con control de presencia
• Informes de asistencia junto a los partes de horas
• Salario por hora del empleado, para calcular el coste de las horas prestadas
• Flota e historial de flota, cuando se proporcionan vehículos
• Comedor — la aplicación para pedir la comida

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

Stripe está activado. Cualquiera de estos puede añadirse o sustituirlo como configuración — por eso entrar en un mercado nuevo es un cambio de ajustes y no un proyecto.

• Europa — Mollie, Buckaroo, Worldline, Redsys, Adyen
• América — Authorize.Net, Mercado Pago, PayPal, Nuvei
• Oriente Medio y África — Amazon Payment Services, Paymob, DPO, Flutterwave
• Asia — AsiaPay, Razorpay, Xendit
• Turquía — Iyzico

Apps de 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

Servicios externos opcionales. Todos están desactivados por defecto, y es deliberado: cada uno envía algo fuera del sistema, y eso debe ser una decisión y no un valor por defecto.

• Google Calendar — sincronización bidireccional de las agendas del personal
• Google Maps y autocompletado de lugares en la web
• Autocompletado de direcciones de Google en los formularios de contacto
• Usuarios de Google — inicio de sesión con una cuenta de Google Workspace
• Almacenamiento en la nube en Azure o Google, para adjuntos a gran escala

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

Piezas sueltas que resuelven cada una un problema concreto. Se incluyen por completitud, no porque una clínica las necesite el primer día.

• Complementos de correo para Outlook y Gmail, en CRM y en Proyecto
• Mail Group — un debate al estilo lista de correo, con archivo en la web
• Reciclaje de datos — encuentra registros duplicados y obsoletos
• Perfil web — una página pública para un usuario de portal
• Formularios de entrevista de Selección, e informes de margen de gastos de venta
• Una integración de telefonía con el CRM (Issabel)

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

El acuerdo, sus partes, sus condiciones estructuradas con su procedencia, sus versiones y un flujo de etapas configurables asignadas a cinco fases fijas.

• Acuerdos con partes, condiciones estructuradas y procedencia de cada condición
• Versiones, para que «¿qué decía en marzo?» siga teniendo respuesta
• Etapas configurables asignadas a cinco fases fijas
• Sin vocabulario sectorial y sin dependencia de la firma electrónica, del almacenamiento cifrado ni de proyectos
• Los sectores llegan como paquetes de configuración y no como bifurcaciones del código

Construido para que la revisión se centre en lo que ha cambiado y en lo que se desvía, nunca en el texto estándar sin cambios — que es donde se suelen abandonar los sistemas de contratos.

• Una biblioteca de cláusulas vinculada a condiciones estructuradas, de modo que aceptar una alternativa fija la condición que lleva
• Manuales de negociación, rondas, cuestiones y desviaciones registradas
• Las reuniones como rondas de negociación por derecho propio, conservando el razonamiento y las posiciones
• El resultado de una reunión crea cambios propuestos y nunca modifica el contrato por sí solo
• Un registro que une cada etapa desde la solicitud hasta la ejecución, con cada hueco a la vista

Una aprobación decidida sobre más de un eje. Tratarla solo como jerarquía es el error de diseño habitual: un acuerdo de confidencialidad estándar, sea cual sea su importe, no necesita a nadie de rango superior.

• Aprobación por importe, desviación, tipo de contrato y riesgo
• La desviación como eje propio y no como un modificador del importe
• La aprobación por un delegado se registra siempre como tal — «en nombre de» es un hecho distinto
• Funciona en Odoo Community, donde la aplicación Aprobaciones no está disponible

Registra qué cambió una modificación, no solo que existe.

• Ejecutar una modificación cierra las filas de condiciones que altera y abre otras nuevas en la fecha de efecto
• Todo lo que se deriva de una condición cambiada se recalcula, y la variación se muestra antes de la ejecución
• Las modificaciones en conflicto se detectan al ejecutarlas
• Una renuncia que caduca restablece la condición vigente en ese momento, no la original

La firma es el comienzo de la obligación, no el final de un flujo de trabajo. Esto se ocupa de lo que viene después.

• Obligaciones en ambos sentidos, con evidencia donde se exige evidencia
• Fechas derivadas calculadas a partir de las condiciones y no tecleadas, que se mueven cuando se mueven las condiciones de las que dependen
• Una escala de avisos que no depende de recordárselo a la persona que ya no ha actuado
• La decisión de renovación presentada junto a las obligaciones que la contraparte ha incumplido

Dos costes, separados: lo que costó ganar un contrato y lo que cuesta prestarlo. Sumarlos da una cifra que no responde a ninguna de las dos preguntas.

• El esfuerzo de negociación registrado como gasto general, se firme o no el contrato
• El coste de prestación recuperado frente al valor del contrato
• Contratos vinculados a proyectos de muchos a muchos, con un rol, porque un único campo de proyecto falla con el primer acuerdo marco
• Un contrato de proveedor firmado es coste comprometido desde su ejecución, no desde su primera factura

Cuánto vale una hora, qué permiten los honorarios y las cuatro cifras que necesitan ambas cosas.

• Tarifas, una marca de facturable y un estado de facturado en el tiempo registrado
• Bases de honorarios indicadas en el contrato
• Recuperación — lo facturado frente al valor del tiempo registrado
• Ocupación — horas facturables frente a horas disponibles, según el propio calendario laboral de la persona
• Inmovilizado — trabajo sin facturar más facturas sin cobrar, y cuántos días de facturación suponen
• Un aviso de honorarios con tope basado en el coste previsto, porque uno que salta al llegar al tope salta demasiado tarde

El cuarto canal de intercambio: la contraparte lee aquí la versión actual, la comenta y sube sus correcciones como una ronda entrante.

• La contraparte abre la versión actual, la comenta y devuelve sus correcciones
• Las correcciones llegan como una ronda entrante con el fichero adjunto, no como un correo que alguien debe acordarse de archivar
• No se ve nada interno — ni posiciones, ni desviaciones, ni aprobaciones, ni el manual de negociación, ni las notas internas
• Opcional, porque un diseño que da por hecho que la contraparte usará nuestro portal fracasa con el primer cliente grande

Cómo usa un contrato el servicio de firma. La finalización es el evento que pone en marcha todo lo demás.

• Las aprobaciones deben estar completas antes de que se pueda enviar una versión
• La facultad del firmante para obligar, comprobada frente a su credencial
• La versión se bloquea al enviarse, para que cualquier afirmación posterior sobre lo firmado sea demostrable
• Al completarse, la versión queda ejecutada, el contrato avanza, las condiciones se activan y las fechas derivadas le siguen
• Desinstalarlo deja un sistema que funciona — las firmas en papel se registran con un método y se ven completas

Cifrar todos los contratos hace el sistema inservible; no cifrar ninguno lo hace inseguro. Por eso la confidencialidad es un nivel del acuerdo.

• Solo los acuerdos marcados como seguros envían sus documentos al servicio de documentos seguros
• Cifrado por versión con una clave guardada fuera de la base de datos
• Acceso denegado por defecto, y cada lectura registrada antes de devolver el contenido
• Eliminación destruyendo la clave
• Avisa en el momento del cambio de que pasar a seguro no deshace haber guardado algo sin cifrar

Listas de alertas que deberían estar vacías, y las vistas de gestión por las que merece la pena discutir.

• Una lista de alertas solo contiene lo que se sale de lo normal — una lista vacía es el buen resultado
• Una alerta cuyo modelo no está instalado aparece como no aplicable en lugar de fallar
• La responsabilidad sin límite se muestra como lista, nunca como una cifra sumada a un total
• El tiempo de ciclo separado por parte, porque los días que la contraparte tuvo el borrador no miden el rendimiento del equipo de contratos
• Depende solo del núcleo, y quitarlo deja un sistema que funciona

Tres lectores, una sola aritmética. Las mismas cifras calculadas una vez y presentadas de tres formas, en lugar de volver a calcularlas en cada pantalla, donde acabarían divergiendo.

• Una única vista de plazos: fechas derivadas del contrato, obligaciones en ambos sentidos, acciones acordadas en reuniones y plazos de entrega
• Control de proyectos: ingresos, mano de obra, coste comprometido, margen y desviación sobre el presupuesto, como vista almacenada para poder agruparla
• Una vista para el cliente de en qué punto está el trabajo y qué se debe
• Una vista para el abogado de lo que le toca esta semana y de si está dentro del presupuesto

Dos reglas, y solo dos — las que comparan registros y por tanto no pueden expresarse como configuración.

• El territorio de una sublicencia debe quedar dentro del de su licencia principal
• Dos licencias exclusivas no deben solaparse
• Separado del paquete de PI, para que un negocio pueda instalar los tipos de contrato sin las comprobaciones
• Su tamaño es una medida deliberada de lo bien que funcionan los puntos de extensión de la base

Comprobación de conflictos al dar de alta un contrato, igual que al abrir un asunto. Bloquea el cambio de etapa; no se limita a avisar.

• Una contraparte comprobada frente a los clientes existentes, las partes contrarias en asuntos vivos y las filiales conocidas
• Bloquea el cambio de etapa en lugar de mostrar un aviso que se puede descartar
• La propia comprobación es inalterable una vez registrada — quién la hizo, sobre qué alcance y qué encontró

El paquete de partida. Instale el núcleo y este, y un negocio puede gestionar contratos desde el primer día sin configurar nada.

• Acuerdos de confidencialidad, acuerdos marco, pliegos de trabajo, servicios, consultoría, suministro y compra
• Las condiciones que lleva cada tipo y el flujo por el que avanza
• Controles que impiden que un contrato llegue a la firma a medio formar
• Nada de Python — y los paquetes especializados dependen de este en lugar de volver a declarar lo que todos necesitan

Empleo, contratación de autónomos, consultoría y acuerdos de salida.

• Tipos de acuerdo, tipos de condición, biblioteca de cláusulas y manual de negociación para la contratación laboral
• Plantillas de obligaciones para preaviso, periodo de prueba y condiciones posteriores a la extinción
• Los acuerdos de salida son seguros por defecto — cada palabra cuenta, y más adelante un regulador pregunta por ellos
• Solo datos, y sin módulo de reglas

Despachos de abogados — contratos para sus clientes y con ellos — y asesorías jurídicas internas. El mismo sistema sirve a ambos con valores por defecto muy distintos.

• Hojas de encargo, provisiones de fondos e instrucciones a abogados externos
• Una biblioteca de cláusulas con la redacción regulada marcada como obligatoria
• La hoja de encargo de un despacho es confidencial y detallada por defecto
• Los acuerdos de honorarios condicionados llevan una redacción que no se puede eliminar
• La comprobación de conflictos vive en contract_legal_rules, porque compara partes entre asuntos

Licenciantes, titulares de patentes y marcas, oficinas de transferencia de tecnología, universidades y propietarios de marcas.

• Licencias, cesiones y opciones como tipos de acuerdo, con tipos de condición de licencia
• Biblioteca de cláusulas, manual de negociación y plantillas de obligaciones
• Sin registro de activos, deliberadamente — la historia de tramitación de una patente pertenece al sistema de cartera que ya la contiene
• Las dos reglas que un paquete no puede expresar viven en el módulo opcional contract_ip_rules

Arrendamientos, precontratos de arrendamiento, licencias de ocupación, compraventas, servidumbres y las escrituras que cuelgan de un arrendamiento.

• Las fechas de desistimiento como condiciones que generan fechas, porque un derecho de desistimiento caduca en silencio
• La ventana de preaviso como una obligación derivada de la fecha de desistimiento, y ambas escalan
• Condiciones de revisión de renta, gastos comunes y reposición
• Solo datos, y sin módulo de reglas

Documentos de deuda: contratos de financiación, garantías, garantías reales, acuerdos entre acreedores y de subordinación.

• Los covenants financieros como condiciones estructuradas, con fechas de verificación derivadas
• El certificado de cumplimiento como una obligación que exige evidencia
• «¿Qué financiaciones se verifican este trimestre, y con qué cifras?» pasa a ser una pregunta con respuesta
• Documenta la deuda; no la contabiliza — los saldos y las periodificaciones se quedan en contabilidad
• Solo datos, y sin módulo de reglas

Contratos principales, subcontratos, encargos profesionales, garantías colaterales y los instrumentos que los rodean.

• Construido en torno a la cadena: un contrato principal promete una fecha que solo los subcontratos pueden cumplir
• Las condiciones espejo guardadas como condiciones estructuradas para poder compararlas a lo largo de la cadena
• La responsabilidad que los subcontratos y el seguro de responsabilidad profesional tienen que cubrir
• Solo datos, y sin módulo de reglas

Contratos de encargo del tratamiento, business associate agreements y condiciones de subencargados.

• Tipos de acuerdo DPA, BAA y de subencargado con las condiciones que llevan
• El plazo de notificación de brechas como condición propia, porque se mide en horas
• La respuesta a auditorías y el aviso de subencargados como fechas derivadas
• Solo datos, y sin módulo de reglas