En este artículo
Portal de clientes de Odoo: cuándo configurar, ampliar o desarrollar
Tu cliente puede descargar una factura. Ahora necesita que un compañero apruebe el pedido del comprador antes de confirmarlo. Averigua qué partes de esa regla puede aplicar tu instalación actual de Odoo.
Decide la ampliación del portal de clientes de Odoo a partir de las acciones y relaciones entre cuentas que necesitas. Comprueba primero el recorrido nativo. Añade un módulo acotado cuando la regla que falta pertenezca a Odoo. Considera un portal independiente cuando el recorrido abarque varios sistemas o necesite una interfaz con mantenimiento propio. Exige las mismas pruebas de autorización en todas las vías.
Investigación revisada: 5 de noviembre de 2026. Los datos del producto proceden del código fuente de la documentación oficial de Odoo 20.0. El ejemplo del distribuidor y la matriz descargable son propuestas para diseñar la solución. No ejecutamos estas pruebas contra una base de datos real de Odoo.
¿Qué puede hacer ya el portal de clientes nativo de Odoo?
El portal nativo admite acciones concretas sobre documentos y funciones de autoservicio. Compruébalas en tu versión y configuración instaladas. Un cambio de diseño puede resolverse con ajustes. Dar a otra persona autoridad sobre un pedido cambia una regla del negocio. Pide pruebas de esa regla antes de convertir cualquiera de las solicitudes en un desarrollo a medida.
La documentación del portal enumera acciones relacionadas con pedidos, facturas y cuentas. Su descripción de lectura y consulta no significa que los clientes nunca puedan actuar desde el portal. La documentación de firma en línea explica la confirmación de presupuestos por el cliente cuando está habilitada. Las actualizaciones de la cuenta del portal cubren cambios específicos de contacto, pago y seguridad.
Son acciones definidas por la aplicación. No demuestran un derecho general a editar registros ni la cadena de aprobación que exige la organización compradora. Identifica quién realizó la acción e inspecciona el registro resultante. Después, pide a esa misma persona que intente una operación prohibida.
Para cada requisito, registra la demostración nativa y la carencia pendiente. Marca como no comprobada cualquier función que siga sin probarse. “Portal de clientes incluido” no establece quién puede aprobar el pedido modificado de un compañero.
¿Qué relaciones entre empresas y contactos debes modelar?
Asigna el rol de cada contacto a una cuenta de cliente y a una acción permitida. Distingue la empresa operativa de Odoo de la entidad jurídica del cliente y sus sucursales. Compartir dominio de correo o contacto principal no acredita la autoridad deseada. Exige una asignación explícita de cuenta antes de incorporar a alguien al circuito de aprobación.
Odoo explica cómo conceder y revocar acceso al portal desde Contactos. Eso proporciona un mecanismo de gestión de cuentas. Las pruebas de aceptación deben establecer además qué registros y acciones recibe cada contacto invitado en la configuración concreta.
Imagina un distribuidor con las cuentas de cliente A y B. Comprador A prepara compras para A. Aprobador A puede autorizarlas dentro del límite acordado. Un usuario de consulta financiera descarga las facturas de A. Un empleado regional necesita una relación aprobada con ambas cuentas.
| Rol | Alcance permitido | Límite que debe demostrarse |
|---|---|---|
| Comprador A | Preparar la solicitud de compra de A y consultar su avance. | No aprobar su propia solicitud cuando se exige separación de funciones. |
| Aprobador A | Aprobar una solicitud admisible y vigente de A. | No aprobar solicitudes de B ni versiones modificadas que nunca revisó. |
| Consulta financiera A | Consultar y descargar los documentos financieros permitidos de A. | No modificar pedidos ni obtener adjuntos de B. |
| Administrador delegado A | Solicitar o gestionar el subconjunto acordado de miembros de A. | No asignar roles superiores ni otras cuentas sin autorización adicional. |
| Empleado regional | Usar roles aprobados por separado para A y B. | Cambiar de cuenta no traslada permisos ni datos de borradores entre ellas. |
Crear una cuenta y autorizarla requieren comprobaciones distintas. Odoo documenta las invitaciones y las cuentas compartidas entre sitios web en la configuración de cuentas de clientes. Ninguno de esos ajustes demuestra que se haya implantado la matriz anterior. Incluye al personal de soporte y las identidades de integración automatizada en la misma revisión.
¿Conviene configurar, ampliar o crear un portal independiente?
Elige el diseño más pequeño que pueda aplicar el proceso acordado y que su responsable pueda mantener. La configuración encaja con una capacidad nativa demostrada. Una ampliación encaja con una regla ausente vinculada a los registros de Odoo. Un frontend independiente encaja cuando la experiencia entre sistemas y su valor justifican operar otra aplicación.
| Enfoque | Razón para elegirlo | Prueba antes de aprobarlo | Responsabilidad continuada |
|---|---|---|---|
| Configurar el portal nativo | Las aplicaciones instaladas ya admiten las acciones y relaciones necesarias. | Recorrido completo del cliente con las pruebas pertinentes de denegación. | Mantener configuración, invitaciones, regresiones y soporte. |
| Ampliar Odoo | Una regla acotada de permisos, aprobación o documentos pertenece a la transacción de Odoo. | Comportamiento del módulo en la versión exacta, control del servidor y pruebas de actualización. | Mantener el módulo cuando cambian dependencias y versiones. |
| Crear otro portal | El cliente necesita un recorrido por Odoo y otros sistemas, o una interfaz con publicaciones independientes. | Asignación de identidades, comandos autorizados, fuentes responsables y recuperación de fallos. | Operar otra aplicación con sus integraciones y controles de publicación. |
El alojamiento puede limitar las ampliaciones. Odoo Online excluye los módulos personalizados y los de Apps Store. Consulta la decisión de integración entre Online y Odoo.sh para resolver el alojamiento, y las restricciones de arquitectura de la API de Odoo antes de especificar un backend externo.
Un portal independiente no elimina automáticamente una regla difícil de Odoo. Si un usuario interno, una importación o una integración también pueden cambiar el pedido, limitar el navegador deja otras vías abiertas. Sitúa la condición obligatoria donde todas las operaciones pertinentes deban respetarla y prueba esas vías de forma explícita.
Pide a cada proveedor que demuestre el mismo proceso y sus excepciones. La guía de software a medida frente a software estándar trata la decisión de compra más amplia. Si también consideras Power Pages, su modelo de costes de usuarios externos es un cálculo diferente, no una estimación para esta ampliación de Odoo.
¿Qué hace que una aprobación del cliente se cumpla?
Vincula la aprobación a la persona, la cuenta de cliente y la versión del registro revisado. Define qué cambios la invalidan. Un botón Aprobar solo constituye una interfaz. El servidor debe comprobar la autoridad y el registro vigente cuando acepta la transición.
Supongamos que el distribuidor exige una segunda persona para compras superiores a un umbral ilustrativo de 5.000 EUR. Define si incluye impuestos, qué conversión de moneda se aplica y qué ocurre exactamente en 5.000 EUR. Decide quién puede cambiar el umbral y autorizar a un suplente. Odoo no puede deducir esas decisiones de la instrucción “añadir aprobaciones”.
El comprador presenta la revisión 7 por 5.200 EUR. Aprobador A la revisa. Antes de la confirmación, el comprador cambia la cantidad y genera la revisión 8 por 6.400 EUR. La regla propuesta invalida la aprobación anterior y exige otra revisión. El servidor debe comparar la versión aprobada con la vigente al aceptar la transición.
Decide si el rechazo permite modificar la solicitud y si la cancelación libera una reserva. Una delegación caducada también necesita una regla para las acciones en cola. Conserva la decisión junto con la versión revisada y la referencia al registro resultante.
Esta política del comprador es distinta del proceso de firma del presupuesto del vendedor. Para una tienda Shopify, consulta la comparación de aprobaciones B2B en Shopify. No presupongas que sus capacidades se aplican a Odoo.
¿Cómo pruebas el acceso delegado antes del lanzamiento?
Prueba cada acción permitida junto a otra que deba denegarse a la misma identidad. Después inspecciona los registros del negocio. Usa un entorno protegido y cuentas de prueba explícitas. Incluye solicitudes directas de documentos, identificadores modificados, miembros revocados y cambios en los datos aprobados. Ocultar botones no basta para demostrar el control.
| Prueba | Resultado esperado según la política de ejemplo | Evidencia |
|---|---|---|
| Consulta financiera A descarga una factura permitida de A. | Se devuelve el documento correcto. | Identidad, cuenta, referencia del registro e identidad del documento. |
| El mismo usuario solicita directamente una factura o un adjunto de B. | No se revelan documentos ni metadatos protegidos. | Respuesta y resultado de autorización del servidor. |
| Comprador A presenta una solicitud superior al umbral. | La solicitud espera a una segunda persona autorizada. | Estado del negocio y ausencia de confirmación no autorizada. |
| La solicitud revisada cambia antes de confirmarse. | La aprobación anterior no autoriza la versión modificada. | Comparación de versiones y exigencia de nueva revisión. |
| Un empleado pierde su pertenencia con una sesión abierta. | La siguiente operación protegida respeta la revocación. | Hora de revocación, identidad de la solicitud y acción denegada. |
| Llegan dos solicitudes de aprobación para la misma revisión. | Se produce una sola vez el efecto de negocio previsto. | Estado final y referencias correlacionadas de las solicitudes. |
Descarga la matriz propuesta de aceptación de permisos del portal. Todas las pruebas empiezan como NOT_RUN. Sustituye los roles y umbrales ilustrativos por la política aprobada. Añade la versión instalada, la revisión del módulo y las pruebas reales. El archivo especifica pruebas; no es un análisis de seguridad.
Aplica la política al enfoque elegido. Acompaña cada denegación de una acción autorizada que funcione. Bloquear todas las solicitudes no demuestra que el portal sea correcto. Una demostración con permisos de administrador tampoco acredita el aislamiento entre clientes.
¿Qué sistema responde por los documentos y las acciones fallidas?
Nombra el sistema de referencia para cada operación y define qué muestra el portal cuando ese sistema no está disponible. El cliente debe distinguir una solicitud enviada de un pedido confirmado. Soporte necesita conciliar un resultado incierto sin repetir una acción que quizá ya terminó.
En un portal que conecta varios sistemas, define un contrato breve por operación: identificador del registro de origen, cuenta del cliente, actualidad esperada, comando permitido, estados de respuesta y responsable de recuperación. Si el estado de entrega procede del almacén y el de facturación de Odoo, muestra por separado sus fuentes y horas de actualización.
Comprueba la autorización al descargar documentos, además de hacerlo en la página que los enlaza. Revisa copias en caché, PDF generados, exportaciones y resultados de búsqueda. Una lista de pedidos bien delimitada no basta si la petición posterior de un adjunto omite la relación con la cuenta. Asigna la administración de clientes a un responsable y conserva su registro de auditoría.
¿Qué debe contener el encargo de implementación?
El encargo debe describir el recorrido completo del cliente, su matriz de permisos, los estados excepcionales y las evidencias de aceptación. Asigna también soporte y actualizaciones. Compara las propuestas con ese alcance, incluidas sus responsabilidades de prueba y su trabajo recurrente.
- Define el primer recorrido. Por ejemplo, un comprador invitado prepara la compra, otra persona la aprueba y el comprador consulta el resultado aceptado.
- Adjunta el modelo de relaciones. Incluye varias cuentas, administración delegada, bajas de personal y autoridad temporal.
- Especifica la condición obligatoria. Indica qué cambios requieren otra aprobación y dónde la aplica cada vía de escritura.
- Nombra las evidencias. Exige operaciones permitidas y denegadas repetibles, comprobaciones de identidad documental y verificación del registro final.
- Asigna el trabajo continuado. Incluye actualizaciones de módulos y conectores, accesos de soporte, supervisión y comprobaciones de publicación repetibles.
- Conserva la entrega técnica. El equipo de mantenimiento debe disponer del código, la configuración, las asignaciones de cuentas y las instrucciones de operación.
Pide presupuestar la misma matriz de aceptación. Si una oferta excluye la administración delegada o la recuperación de escrituras inciertas, registra la exclusión antes de considerarla una implementación más barata.
¿Qué desarrollaríamos primero?
Implementaríamos un recorrido completo con sus comprobaciones de permisos y fallos, usando el portal nativo donde cumpla la política acordada. Ampliaríamos una carencia demostrada. Encargaríamos otra aplicación cuando su experiencia adicional tenga un responsable y un plan de mantenimiento creíble.
El servicio de desarrollo de portales de clientes de Wavect parte de las acciones que necesita el cliente. Lleva a la definición de alcance la matriz de personas y cuentas, junto con una demostración nativa que no satisfaga un requisito. Con ellas puedes concretar qué debe cambiar el desarrollo.