Una jerarquía de cuenta B2B debe representar quién compra, para qué unidad organizativa compra, qué presupuesto puede utilizar y quién debe aprobar la operación. No basta con crear perfiles de «comprador» y «administrador». El portal necesita separar la entidad legal, las divisiones o sedes, los centros de coste, las direcciones, los roles y las reglas de aprobación; además, debe conservar qué permisos fueron directos y cuáles se heredaron.
La prueba de que el modelo funciona no es que un usuario pueda iniciar sesión. Es que dos personas de la misma empresa, con responsabilidades distintas, vean exactamente los catálogos, direcciones, presupuestos y pedidos que les corresponden; y que una ausencia, una revocación o un cambio organizativo no deje pedidos bloqueados ni accesos residuales.
Modela primero la organización, después los usuarios
Una persona puede cambiar de puesto, trabajar para varias sedes o aprobar temporalmente para otra unidad. Por eso los permisos no deberían colgar directamente de su correo electrónico. El modelo base debería distinguir:
- Entidad legal: la organización que contrata, recibe facturas y asume el crédito.
- Unidad de compra: división, filial, delegación, planta o proyecto que realiza pedidos.
- Centro de coste: dimensión contable a la que se imputa el gasto.
- Ubicación: direcciones de entrega y facturación autorizadas.
- Usuario: identidad autenticada que actúa para una o varias unidades.
- Rol: conjunto de permisos dentro de una unidad concreta.
No copies sin más el organigrama de recursos humanos. La jerarquía del portal debe reflejar el proceso de compra. Una empresa puede tener veinte departamentos, pero sólo tres ámbitos relevantes para pedidos: España, Portugal y grandes proyectos. El nivel correcto es el mínimo que permite aplicar acceso, presupuesto, catálogo, dirección y aprobación sin excepciones manuales.
Qué se hereda y qué debe ser explícito
Para cada dato decide si una unidad hija lo hereda del padre, lo amplía o lo sustituye. Documenta la decisión en una matriz:
| Elemento | Herencia recomendada | Excepción habitual |
|---|---|---|
| Roles corporativos | Heredables si el rol lo indica | Una planta restringe la aprobación a personal local |
| Reglas de aprobación | Regla corporativa + reglas locales | Proyecto con límites más estrictos |
| Catálogo | Desde la unidad comercial superior | Filial con surtido regulado |
| Direcciones | Explícitas | No exponer todas las sedes a todos los compradores |
| Centro de coste | Explícito o por ámbito | Un usuario puede imputar a dos proyectos concretos |
| Condiciones de pago | Entidad legal | Delegación con acuerdo propio |
La herencia reduce mantenimiento, pero también amplía el radio de un error. Si el administrador corporativo recibe un rol heredable, puede actuar en todas las unidades hijas. El portal debe mostrar el origen del permiso —directo o heredado desde una unidad identificada— para que soporte pueda explicar por qué una persona tiene acceso.
Diseña roles por capacidad, no por cargo
Evita roles vagos como «usuario avanzado». Construye permisos atómicos y agrúpalos en arquetipos comprensibles:
| Rol | Puede | No debería poder por defecto |
|---|---|---|
| Solicitante | Crear listas y solicitudes | Aprobar su propia solicitud |
| Comprador | Crear y enviar pedidos dentro de política | Modificar usuarios o reglas |
| Aprobador | Ver contexto y aprobar/rechazar | Cambiar el pedido sin devolverlo |
| Finanzas | Consultar facturas, crédito y centros de coste | Administrar compradores |
| Administrador de cuenta | Invitar, suspender y asignar roles permitidos | Elevar sus propios privilegios |
| Auditor | Consultar pedidos, decisiones y registros | Ejecutar operaciones |
Aplica mínimo privilegio y segregación de funciones. Un solicitante no debe aprobar su propia compra; un administrador de cliente no debería otorgar permisos superiores a los suyos; y el soporte del vendedor no debería suplantar a un comprador sin autorización, motivo y registro temporal.
Centros de coste, presupuestos y límites
El centro de coste no es un campo de texto libre al final del checkout. Debe ser una referencia válida, vigente y autorizada para la unidad y el usuario. Decide:
- si es obligatorio para todas las líneas o para el pedido completo;
- si un pedido puede repartirse entre varios centros;
- quién puede cambiarlo después de la aprobación;
- si el presupuesto se reserva al enviar, al aprobar o al confirmar;
- qué ocurre cuando el ERP rechaza la combinación contable.
Distingue límite de pedido, presupuesto disponible y autoridad de aprobación. Un comprador puede tener permiso para crear una solicitud de 20.000 euros aunque sólo pueda confirmar directamente hasta 2.000; el resto entra en aprobación. El presupuesto, en cambio, determina si la unidad puede asumir el gasto, no quién pulsa «aprobar».
Reglas de aprobación deterministas
Una regla debe indicar ámbito, condición, aprobadores, orden y resultado si nadie responde. Las condiciones habituales combinan:
- importe neto o bruto y moneda normalizada;
- unidad, centro de coste o proyecto;
- categoría, producto restringido o proveedor;
- desviación frente a presupuesto o contrato;
- dirección de entrega o país;
- tipo de comprador y canal.
Ejemplo: «Para la planta BCN-02, un pedido de material de laboratorio superior a 5.000 EUR necesita primero al responsable del centro de coste y después a Compliance. El solicitante nunca es elegible como aprobador». Si coinciden varias reglas, define si se fusionan, si gana la más restrictiva o si siguen rutas paralelas. Nunca dependas del orden accidental en que se guardaron.
Estados mínimos del flujo
El pedido debería distinguir borrador, enviado, pendiente de aprobación, aprobado, rechazado, devuelto para cambios, caducado, cancelado y enviado al ERP. Cada transición necesita actor, fecha, comentario opcional u obligatorio y versión del pedido. Si el comprador modifica cantidad, dirección, centro de coste o precio después de aprobar, invalida la aprobación y recalcula la ruta.
Delegaciones, vacaciones y escalado
Una delegación debe tener titular, sustituto, alcance, inicio, fin y motivo. No copies todos los permisos del aprobador indefinidamente. Limita la sustitución a unidades y capacidades concretas, impide la autodelegación circular y avisa tanto al titular como al sustituto.
Define también un SLA: recordatorio a las 24 horas, escalado a las 48 y caducidad o reasignación a las 72, por ejemplo. El sistema no debe autoaprobar por silencio. Si no hay aprobador válido, muestra el bloqueo al comprador y notifica al administrador de la cuenta con una acción concreta.
Altas, cambios y bajas sin permisos residuales
El ciclo de vida importa más que el alta inicial:
- Una invitación caduca, está ligada a una empresa y no concede permisos hasta verificarse.
- El administrador asigna sólo roles dentro de su ámbito.
- Los cambios de unidad recalculan permisos heredados y pedidos pendientes.
- La suspensión revoca sesiones y tokens activos, no sólo oculta el usuario.
- La baja reasigna tareas pendientes y conserva el historial con una identidad inmutable.
Sincroniza las referencias maestras con ERP, CRM o proveedor de identidad, pero define qué sistema manda para cada atributo. Si el CRM dice que una persona está activa y el directorio corporativo la ha deshabilitado, la política de seguridad debe resolver el conflicto de forma explícita.
Auditoría que permita reconstruir una decisión
Registra quién actuó, para qué unidad, con qué rol efectivo, sobre qué versión, desde qué canal y qué cambió. Para una aprobación, conserva regla y versión, condiciones evaluadas, aprobadores candidatos, decisión, comentario, delegación utilizada y resultado enviado al ERP. Evita guardar datos sensibles innecesarios; protege el registro contra alteraciones y fija retención conforme a la política legal.
Pruebas imprescindibles antes de publicar
- Un usuario de una filial no ve direcciones, pedidos ni centros de otra.
- Un rol heredado aparece sólo en las unidades permitidas y muestra su origen.
- El solicitante no aprueba su propio pedido ni mediante delegación.
- Se prueban los importes justo por debajo, en el límite y justo por encima.
- Dos reglas simultáneas generan siempre la misma ruta.
- Un cambio material invalida la aprobación anterior.
- Ausencia, sustitución, escalado, rechazo y caducidad terminan sin bloqueo oculto.
- La suspensión corta sesiones y reasigna pendientes.
- El ERP recibe entidad legal, unidad, centro de coste y trazabilidad correctos.
- Un auditor puede reconstruir el flujo sin acceso de escritura.
Esta arquitectura de cuentas debe encajar con las capacidades operativas de un portal B2B para distribuidores.
Preguntas frecuentes
¿Cuántos niveles debe tener la jerarquía?
Los mínimos necesarios para expresar acceso y política de compra. Añadir niveles del organigrama sin efecto operativo aumenta las excepciones y hace más difícil entender la herencia.
¿Puede un usuario pertenecer a varias unidades?
Sí, pero el contexto activo debe ser visible y cada pedido debe quedar ligado a una sola unidad compradora. Al cambiar de contexto se recalculan catálogo, direcciones, centros y permisos.
¿Quién administra los usuarios del cliente?
Un administrador de cuenta puede gestionar el ámbito delegado, pero la plataforma debe impedir que se otorgue privilegios superiores o que modifique controles reservados al vendedor.
¿Qué pasa con un pedido cuando el aprobador causa baja?
Debe reevaluarse con la versión vigente de la política y reasignarse o escalarse. Mantén en el historial quién era el candidato original y por qué cambió la ruta.
Fuentes primarias para contrastar el diseño
- commercetools: Business Units, para compañías, divisiones, asociados y herencia de reglas.
- commercetools: roles y permisos de asociados, para capacidades granulares y segregación entre solicitud y aprobación.
- Microsoft Dynamics 365 Commerce: jerarquías de clientes B2B, para organizaciones, personas y control de acceso.
- Microsoft Dynamics 365 Commerce: jerarquías organizativas, para unidades, centros de coste, vigencia y auditoría histórica.
Siguiente paso
Construye tres casos reales —compra dentro de límite, compra con doble aprobación y ausencia del aprobador— y obliga al portal y al ERP a producir la misma unidad, centro de coste y decisión. Para profundizar en el diseño funcional del portal, consulta los recursos de CODE B2B.