US-038 — Asignación de nivel corporativo

Detalle de la historia¶

Historia¶

Como administrador de FleteChat responsable de los contratos corporativos, quiero asignar un nivel corporativo a un cliente con fecha de inicio y fecha de vencimiento, para gestionar los contratos comerciales sobre plazos claros y que el motor de cotización aplique el precio correcto automáticamente.

Persona de usuario¶

Aplica exclusivamente al rol admin. El rol operator no gestiona asignaciones de nivel corporativo —sí puede consultarlas en la ficha del cliente para contexto operativo, pero no crearlas ni editarlas. El rol price_manager no interviene en asignaciones: mantiene las listas de precios en Epic 8.

Contexto de negocio¶

Un cliente corporativo tiene un contrato con fechas: entra en Silver en enero, migra a Gold en abril, renueva hasta diciembre. Sin un mecanismo explícito de asignación con plazos, cada cotización dependería de decisiones manuales, lo que es lento y propenso a errores (aplicar un precio antiguo a una cotización nueva, o al revés). La asignación con vigencia resuelve esto: el motor de cotización consulta el nivel activo del cliente en la fecha de la cotización y usa la lista de precios del nivel.

La asignación corporativa refleja un compromiso contractual; su manejo vive bajo el rol admin para mantener el control comercial centralizado y trazable (ver PR-166). El admin gestiona asignaciones desde el perfil del cliente en el backoffice: crea una nueva asignación (con fechas), edita una existente (corregir la fecha de vencimiento al renovar) o la termina anticipadamente. El historial completo queda visible para operator y admin, aunque sólo admin puede modificarlo.

Criterios de aceptación¶

Acceso¶

1. La creación, edición y terminación de asignaciones están disponibles sólo al rol admin (ver PR-166). El rol operator puede ver el historial de asignaciones en la ficha del cliente pero no puede modificar nada; los controles de alta/edición no aparecen en su interfaz. Cualquier intento por API devuelve 403.

Alta y edición¶

1. Desde el perfil de un cliente en el backoffice, el admin puede crear una asignación con los campos: cliente (preseleccionado), nivel corporativo (desplegable con niveles activos del catálogo, ver historia de catálogo), fecha de inicio, fecha de vencimiento, nota opcional (texto libre con motivación o referencia al contrato).
2. La UI valida que fecha de vencimiento sea mayor que fecha de inicio; si no, rechaza con mensaje claro.
3. El admin puede editar una asignación para ajustar fechas o nota mientras la asignación esté activa. Cambiar la fecha de inicio a una anterior ya pasada es posible con confirmación explícita; la edición queda en el audit log.
4. El admin puede terminar anticipadamente una asignación asignándole una fecha de vencimiento que sea hoy o una fecha pasada. La asignación pasa a estado "finalizada" y el cliente queda sin nivel a partir de ese momento (usará lista base hasta que se le asigne uno nuevo).

Unicidad del nivel activo¶

1. Un cliente puede tener como máximo una asignación activa a una fecha dada (ver PR-156). Si el admin intenta crear una asignación cuyo rango de fechas se solapa con una existente, la UI lo detecta y pide resolución: terminar la asignación anterior en la fecha de inicio de la nueva, o ajustar las fechas.

Historial visible¶

1. El perfil del cliente muestra el historial completo de asignaciones ordenado por fecha: nivel, fecha inicio, fecha vencimiento, estado (activa, finalizada, vencida), autor del cambio. Este historial es visible tanto al admin como al operator (aunque operator no puede editarlo).
2. Cada alta, edición, finalización y cambio de fechas queda registrado en el audit log con actor (admin), timestamp y diff.

Efecto en el motor de cotización¶

1. Al emitir una cotización para un cliente, el motor consulta la asignación activa a la fecha de emisión y usa la lista de precios del nivel correspondiente (ver PR-157).
2. Si el cliente no tiene asignación activa a la fecha de emisión, el motor usa la lista de precios base del sistema.
3. El nivel aplicado queda grabado en la cotización (snapshot). Cambios posteriores en la asignación del cliente no alteran cotizaciones ya emitidas.

Edge cases¶

• Admin intenta asignar un nivel desactivado (ver historia de catálogo). La UI filtra niveles desactivados del desplegable; no son seleccionables para nuevas asignaciones. Las asignaciones históricas con niveles desactivados siguen funcionando hasta vencer.
• Operator abre la ficha del cliente y necesita cambiar el nivel. La interfaz muestra el historial pero los controles de edición no están visibles; si requiere un cambio debe solicitarlo al admin. Este flujo de solicitud/escalamiento es operativo y no parte del alcance de v1.0.
• Asignación creada con fecha de inicio en el futuro. Válida. El cliente sigue con su nivel actual (o lista base) hasta la fecha de inicio; desde esa fecha el motor usa la nueva asignación.
• Asignación vence sin renovación. A partir del día siguiente a la fecha de vencimiento, el cliente queda sin nivel activo y el motor usa lista base. La alerta de vencimiento (ver historia correspondiente) avisa al equipo comercial antes de que esto ocurra.
• Admin corrige la fecha de vencimiento de una asignación vigente hacia adelante (renovación). La asignación extiende su vigencia; cotizaciones emitidas en el rango extendido usarán el nivel. Las ya emitidas no se ven afectadas.
• Admin corrige la fecha de vencimiento hacia una fecha ya pasada. Equivale a una terminación anticipada. La UI pide confirmación explícita y avisa que cotizaciones emitidas después de la nueva fecha de vencimiento no se verán afectadas (mantienen su snapshot).
• Cliente sin historial de asignaciones nunca fue corporativo. El perfil lo muestra como "sin nivel corporativo asignado"; el motor usa lista base.

Tamaño, prioridad y tipo¶

• Tamaño: M
• Prioridad: P1 — puerta de entrada del cliente corporativo al motor de cotización.
• Tipo: feature

Premisas¶

La historia está redactada bajo las siguientes premisas. Si alguna cambia, la historia debe revisarse y ajustarse en consecuencia. Todas deben ser confirmadas por el cliente antes de cerrar la historia.

• PR-156 — Un nivel activo por cliente a la vez. Un cliente puede tener como máximo una asignación activa a cualquier fecha. Asignaciones solapadas no son permitidas; el operador resuelve el conflicto al momento de crear o editar.
• PR-157 — Nivel aplicado por fecha de emisión de la cotización. El motor de cotización consulta la asignación activa en la fecha en que se emite la cotización y aplica la lista de precios correspondiente. La cotización guarda el nivel aplicado como snapshot; cambios posteriores en la asignación del cliente no alteran cotizaciones ya emitidas.
• PR-158 — Historial inmutable de asignaciones. Las asignaciones nunca se borran físicamente. Finalizar, editar o corregir fechas genera entradas auditables que preservan la trazabilidad del vínculo cliente-nivel a lo largo del tiempo.
• PR-166 — Asignación corporativa gestionada exclusivamente por admin. La creación, edición y terminación de asignaciones corporativas son responsabilidad exclusiva del rol admin. El rol operator tiene visibilidad del historial en la ficha del cliente pero no permisos de escritura; price_manager no tiene acceso a esta función.

Refinamiento y Definition of Ready¶

Notas¶

Checklist¶

• ✅ Historia escrita en formato Como / Quiero / Para
• ✅ Persona de usuario identificada
• ✅ Contexto de negocio documentado
• ✅ Criterios de aceptación observables y pass/fail
• ✅ Edge cases relevantes listados
• ✅ Tamaño y prioridad asignados
• ⬜ Premisas PR-156 a PR-158 y PR-166 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente