Cada ítem describe el alcance técnico (modelo, API, permisos, jobs e i18n) y el valor asociado. Las tareas en alcance son las que se van a desarrollar. Los ítems marcados como incluidos o en $0 no suman.
Plataforma
Refactor de UX/UI de la plataforma
No forma parte de este alcance.
Descripción
Rediseño visual y de información de la plataforma para que sea más clara, consistente y usable. Incluye reorganizar la navegación (módulos operativos arriba, gestión de empresa en el perfil), versión móvil completa con acceso a escanear, onboarding guiado para clientes nuevos, panel agregado sin Hub, change log de órdenes, nombre real de la tienda, vínculo visual case/each e indicador de productos sin tiendas asignadas.
Alcance técnico
Top bar operativa por Hub; dropdown de perfil con Empresa, Usuarios, Hubs, Tiendas, Productos, Categorías y Proveedores; sidebar solo con filtros. Mobile: mismas rutas y CTA de scan. Wizard de onboarding (onboardingCompletedAt). Dashboard con hubId opcional (agregado para Admin). Timeline de OrderChangeLog. Header con pointOfSale.name. Chips case↔each y badge “Sin tiendas asignadas”. Cubre los ítems marcados Incluido en UX/UI.
MVP panel administrativo (Super Admin)
No forma parte de este alcance.
Descripción
Panel exclusivo del Owner de Viable —por encima de las organizaciones cliente— para crear y gestionar clientes, ver su estado (activa, inactiva, en onboarding), entrar a cualquier cuenta para soporte y consultar métricas globales de uso. No es visible para usuarios de los clientes.
Alcance técnico
Tenant de plataforma sobre Organization: rol Owner, CRUD de orgs (activa / inactiva / onboarding), acceso de soporte a cualquier Hub, planes/config global, dashboard de métricas (órdenes, usuarios activos, inventario en movimiento). Rutas y API aisladas para que ningún JWT de cliente liste otras orgs. Cubre el ítem 11.1 del backlog; no duplicar.
Facturas
Alerta de invoice duplicado
BUGNo forma parte de este alcance.
Descripción
Detectar y advertir si una factura parece duplicada (mismo proveedor, número o monto ya cargado) antes de enviarla.
Alcance técnico
Lookup por hub con matching de vendorId + invoiceNumber y fallback vendorId + total + fecha ±N días. Warning (bloqueo configurable). Índice en (hubId, vendorId, invoiceNumber).
Minimum stock: umbral y auto-completado
No forma parte de este alcance.
Descripción
Cada ítem guarda un mínimo de stock que dispara alertas. Al crear un ítem desde una factura, se propone el 10% de la cantidad recibida (editable). Si el ítem se elimina, deja de alertar.
Alcance técnico
Campo minStock en Item; default ceil(qty×0.1) al crear desde línea de invoice. Las alertas de low-stock leen este valor. Soft-delete o flag para que un ítem eliminado no dispare alerta. Exponer en ficha y en review de factura.
Indicador de productos sin tiendas asignadas
Incluido en UX/UINo forma parte de este alcance.
Descripción
Marcar en el listado los productos nuevos de una factura que aún no tienen tiendas, sin interrumpir la subida.
Alcance técnico
Cubierto por el ítem 1: badge en listado/review de invoice cuando el ítem no tiene PointOfSale asignados. No bloquear submit.
Validación de balance del invoice
BUGNo forma parte de este alcance.
Descripción
Antes de enviar, el sistema suma (costo × cantidad) + impuestos, lo compara con el total y bloquea si no cuadra.
Alcance técnico
Cálculo server-side: sum(cost×qty) + taxTotal vs invoice.total, con tolerancia de redondeo (p. ej. 1 COP). HTTP 400 si no coincide. Mostrar delta en UI. No confiar en el total enviado por el cliente.
Campo Tax Total
No forma parte de este alcance.
Descripción
Casilla de impuesto total tal como aparece en la factura cargada (lo extraído del documento, no un recálculo del sistema).
Alcance técnico
Campo taxTotal persistido desde extracción IA o captura manual, distinto de un tax calculado. Alimenta la validación de balance. Ajustar el prompt de visión para extraer el tax line del documento.
Totales por columna y total general
No forma parte de este alcance.
Descripción
Subtotal por línea de ítem y un total general único para toda la factura.
Alcance técnico
Line amount = cost×qty. Footer de tabla con sumatorias. Total general único alineado a invoice.total / validación de balance.
Inventario y catálogo
Price no obligatorio al subir factura
No forma parte de este alcance.
Descripción
El precio de venta deja de ser obligatorio. Si queda vacío, se asume igual al costo. El costo (lo que dice la factura) es el valor principal.
Alcance técnico
Quitar required de price en DTO de invoice/item create. Default price = cost en backend si null. El costo sigue siendo el campo canónico de la factura.
Valor de inventario — costo promedio ponderado
No forma parte de este alcance.
Descripción
El inventario se valora al costo, no al precio de venta. Cada entrada recalcula el promedio de las unidades en existencia; las salidas salen al promedio vigente.
Alcance técnico
WAC por ítem y hub: newAvg = (qtyOnHand×avg + inboundQty×inboundCost) / (qtyOnHand+inboundQty). Persistir avgCost y qty. Salidas y ajustes descuentan al avg vigente. Reportes leen avgCost×qty, nunca price. Migración: backfill desde último costo o historial de invoices.
Alias de ítem — excluir cantidad
BUGNo forma parte de este alcance.
Descripción
Los alias que genera la IA no deben incluir la cantidad, para que el mismo producto se reconozca aunque cambie el empaque o las unidades.
Alcance técnico
Sanitizar tags/aliases en el pipeline de matching: strip qty y pack-size tokens (cs, pk, 24pk, 60). Ajustar prompt. Opcional: normalizar aliases existentes. Relacionado con el agente de facturas ya entregado.
Tax ID → Account Number / Vendor ID
No forma parte de este alcance.
Descripción
En la subida con IA, dejar de extraer Tax ID (Viable no es un sistema de pagos) y usar número de cuenta o ID de proveedor.
Alcance técnico
Renombrar campo en schema, i18n y prompt de extracción. Mapear accountNumber/vendorId en Vendor. No persistir tax IDs fiscales salvo NIT en ficha de proveedor (ítem de proveedores).
Creación automática de subítem (case → each)
Incluido en UX/UINo forma parte de este alcance.
Descripción
Al crear un ítem por caja, preguntar si se puede distribuir por unidad. Si se confirma, se crea el subítem vinculado (SKU-IND, etiqueta EACH) con el mismo nombre.
Alcance técnico
Cubierto por el ítem 1: prompt unitsPerCase + flag distributable; Item hijo con parentId y sku -IND.
Visibilidad del vínculo case ↔ each
Incluido en UX/UINo forma parte de este alcance.
Descripción
En el listado de productos debe verse claro qué ítems están vinculados entre sí (caja y unidad).
Alcance técnico
Cubierto por el ítem 1: chip CASE → EACH en el listado, con parent/child en el serializer.
Usuarios y tiendas
Bug al cambiar de Hub
BUGNo forma parte de este alcance.
Descripción
Al reasignar el Hub de un usuario, el cambio debe aplicarse de inmediato o en la siguiente navegación, sin forzar cierre de sesión.
Alcance técnico
Hoy el hub queda en JWT/contexto. Invalidar o refrescar claims al PATCH de user.hubId; el front re-fetch del HubProvider en la siguiente navegación. Cubrir websocket rooms keyed por hub.
Renombrar el status del Hub
No forma parte de este alcance.
Descripción
Cambiar “Draft” a “In Progress” y “Published” a “Live” para mayor claridad (o eliminar el status si ya no aporta).
Alcance técnico
i18n + display del enum. Si se cambia el enum en DB: migración DRAFT→IN_PROGRESS, PUBLISHED→LIVE. No romper filtros existentes.
Nombre de la store en la vista Store Manager
Incluido en UX/UINo forma parte de este alcance.
Descripción
Mostrar el nombre real de la tienda de forma prominente; quitar la etiqueta genérica “Dashboard”.
Alcance técnico
Cubierto por el ítem 1: header del dashboard de store lee pointOfSale.name.
Agrupación de stores por tipo
No forma parte de este alcance.
Descripción
Agrupar tiendas por tipo de libre creación (restaurantes, bares, piso, plaza de comidas, etc.).
Alcance técnico
Modelo StoreType (nombre libre por org/hub) + store.typeId. CRUD admin. Filtros y agrupación en listados. Sin tipos precargados obligatorios.
Múltiples stores por Store Manager
No forma parte de este alcance.
Descripción
Un mismo Store Manager puede estar asignado a varias tiendas y cambiar entre ellas, similar a las locations de Square POS.
Alcance técnico
Relación N:N User↔PointOfSale para rol Store Manager. Multi-select al crear/editar. Switcher de tienda activa (header + persistencia). Autorización: pedidos solo contra stores asignadas.
Selección de Hub/Tienda con memoria de contexto
No forma parte de este alcance.
Descripción
Recordar el último Hub o Tienda usado, mostrarlo siempre en la barra superior y permitir cambiarlo en un clic, para evitar pedidos o despachos desde el lugar equivocado.
Alcance técnico
Persistir lastHubId/lastStoreId por usuario. Header chip siempre visible. Al login, hidratar el último contexto válido; si perdió acceso, caer al primero disponible.
Devices y kiosk
Kiosk — confirmación de emparejamiento
BUGNo forma parte de este alcance.
Descripción
Al escanear el QR para emparejar una tablet, una vez exitoso el QR debe desaparecer y mostrar un mensaje tipo “Paired successfully”.
Alcance técnico
Tras ACK de pairing (websocket o poll), desmontar QR y montar pantalla de éxito. El QR deja de ser usable después del bind.
Gestión de tiendas
Límites en la cantidad de órdenes
No forma parte de este alcance.
Descripción
Los admins configuran un máximo de unidades por ítem y/o por tienda, para que las stores no pidan cantidades ilimitadas.
Alcance técnico
Config org/hub: maxQtyPerItem y/o maxQtyPerStore. Validar en create/update order en API. UI con tope y mensaje. Kiosk respeta el mismo techo.
Flujo de órdenes
Renombrar “Receive” a “Acknowledge”
No forma parte de este alcance.
Descripción
El estado o acción de la orden hoy llamado Receive pasa a llamarse Acknowledge.
Alcance técnico
i18n es/en y labels de la state machine. El enum interno puede quedarse si el display está aislado; si se renombra RECEIVED→ACKNOWLEDGED, migración + notificaciones.
Hub Manager edita la orden hasta la entrega
No forma parte de este alcance.
Descripción
Los Hub Managers pueden corregir cualquier aspecto de una orden hasta marcarla Delivered (p. ej. una botella rota en tránsito). Cada cambio queda registrado para auditoría.
Alcance técnico
PATCH de líneas/cantidades/notas permitido en estados < DELIVERED para Hub Manager y Delivery Man. OrderChangeLog (actor, campo, before, after, ts). Bloquear post-DELIVERED.
Orden de devolución (bulk)
No forma parte de este alcance.
Descripción
Flujo de devolución masiva separado del pedido regular: tienda de origen, ítems, cantidades y motivo (fin de evento, dañado, excedente). Al confirmar, el inventario se ajusta de una vez, con trazabilidad.
Alcance técnico
Nuevo tipo ReturnOrder (no cuelga de una Order de ida): originStoreId, reason enum, lines[]. Confirmación de Hub Manager dispara ajuste de stock en transacción. Listados y reportes de devoluciones leen este modelo.
Detalle de lo que cambió en la orden (delta)
No forma parte de este alcance.
Descripción
Cuando se actualiza una orden, el manager ve exactamente qué cambió. Al hacer clic en la notificación se abre esa vista de detalle.
Alcance técnico
Payload de notificación con diff (líneas added/removed/qty). Deep-link a order detail anclado al change log. Reusa el log de auditoría de edición de órdenes.
Change log de la orden
Incluido en UX/UINo forma parte de este alcance.
Descripción
Historial de cambios y actividad al final de cada orden.
Alcance técnico
Cubierto por el ítem 1: timeline al pie de order-detail con OrderChangeLog y eventos de status.
Recordatorio de In Transit
No forma parte de este alcance.
Descripción
Notificación automática si una orden lleva más de 1 hora en estado In Transit.
Alcance técnico
Job (cron o cola) periódico: orders WHERE status=IN_TRANSIT AND updatedAt < now-1h AND reminderSentAt is null. Notificación (y email si hay canal). Flag para no repetir.
Panel y navegación
Rediseño de navegación
Incluido en UX/UINo forma parte de este alcance.
Descripción
Separar dos niveles: barra superior operativa por Hub (Panel, Inventario, Pedidos, Facturas) y menú de perfil con la gestión global de empresa. La barra izquierda solo muestra filtros del módulo activo.
Alcance técnico
Cubierto por el ítem 1. Entregar la IA de navegación junto al rediseño visual.
Panel sin Hub seleccionado — vista agregada
Incluido en UX/UINo forma parte de este alcance.
Descripción
Sin Hub seleccionado, el Panel muestra datos de todos los Hubs. Al elegir uno, se filtra a ese Hub.
Alcance técnico
Cubierto por el ítem 1: dashboard con hubId opcional; Admin ve agregado, Hub Manager solo el suyo.
Panel dinámico, métricas financieras y sistema de reportería
No forma parte de este alcance.
Descripción
El panel pasa a ser el centro de reportería de la operación: cada métrica es clicable y lleva a su fuente (órdenes pendientes, inventario, devoluciones). Incluye indicadores financieros (gasto del mes vs período anterior, tendencia de costos por categoría, valor de inventario en movimiento) y los reportes por rol —inventario, pedidos, productos más pedidos y devoluciones— recortados a Admin, Hub Manager, Store Manager y Viewer (solo lectura).
Alcance técnico
Cards clickable con query (status, rango). Queries: spend MTD vs período previo, cost trend by category, inventario en movimiento a WAC. Capa de reportes scoped por rol (Admin / Hub Manager / Store Manager / Viewer GET-only) y export Excel donde ya existe el pipeline. Incluye el ítem de reportes por rol.
Facturas a nivel de Hub, no de Empresa
No forma parte de este alcance.
Descripción
La gestión de facturas pasa a vivir en el Hub, porque cada centro maneja su inventario y sus facturas de forma independiente.
Alcance técnico
Rutas settings/invoices → dashboard/hub/invoices. API scoped por hubId. Migrar invoices huérfanos al hub correspondiente. Hub Manager solo su hub; Admin puede ver todos vía panel agregado.
Versión móvil y acceso rápido a escanear
Incluido en UX/UINo forma parte de este alcance.
Descripción
La versión móvil hoy solo muestra el panel. Debe navegar a los demás módulos, igual que la web, con acceso rápido a escanear para el Hub Manager.
Alcance técnico
Cubierto por el ítem 1. Navegación móvil completa y CTA de scan para Hub Manager.
Roles y permisos
Roles y permisos editables por empresa o por Viable
No forma parte de este alcance.
Descripción
Sistema de roles y permisos que el Admin de cada empresa o el Owner de Viable puede ajustar. Parten de dos niveles: interno Viable (Owner / Super Admin) y cliente (Admin, Hub Manager, Store Manager, Delivery Man, Viewer), con la posibilidad de editar qué puede ver y hacer cada rol sin un desarrollo a medida.
Alcance técnico
RBAC persistido (rol + permisos por org, con override de plataforma). UI de edición para Owner Viable y Admin de empresa. Guards en API y filtrado de menús. Roles base: Owner, Admin, Hub Manager, Store Manager, Delivery Man, Viewer. No hardcodear permisos en cada pantalla más allá de leer la matriz.
Proveedores
Fortalecer ficha del proveedor
No forma parte de este alcance.
Descripción
El proveedor deja de ser un campo suelto en la factura. La ficha incluye al menos nombre, email de contacto y NIT, para poder generar y enviar órdenes de compra.
Alcance técnico
Modelo Vendor: name, email, nit (único por org). CRUD + asociación en invoice. No incluye el flujo completo de PO/correo. Validar formato de NIT y no duplicados.
Onboarding
Onboarding guiado para clientes nuevos
Incluido en UX/UINo forma parte de este alcance.
Descripción
Wizard la primera vez que entra un Admin nuevo: crear Hub → crear tiendas → invitar usuarios → subir la primera factura. Completado, desaparece y no vuelve a aparecer.
Alcance técnico
Cubierto por el ítem 1: checklist onboardingCompletedAt y wizard multi-step reutilizando forms existentes.
Reportes
Reportes por rol
Incluido en reporteríaNo forma parte de este alcance.
Descripción
Cada rol ve los reportes de su función. Admin: inventario, pedidos, productos más pedidos y devoluciones por Hub. Hub Manager: recorte a su Hub. Store Manager: historial y estado de sus pedidos. Viewer: los del Admin, en solo lectura.
Alcance técnico
Cubierto por el ítem 31: misma capa de reportes scoped por rol y export Excel.
Consideraciones
- Los valores incluyen análisis, desarrollo, integración y pruebas de cada funcionalidad.
- El refactor de UX/UI ($2.500.000) incluye navegación, móvil, onboarding, panel agregado, change log, nombre de tienda, case/each e indicador de productos sin tiendas.
- El panel administrativo ($3.000.000) cubre el Super Admin de organizaciones y métricas de plataforma.
- El panel dinámico y sistema de reportería ($1.250.000) incluye los reportes por rol.
- Los ítems en $0 son correcciones de bug. Los marcados como Incluido no suman al total.
- En alcance suma solo las tareas que el cliente aprobó. Super Admin, reportería, roles editables y las demás no aprobadas quedan fuera por ahora.
- No incluye capacitación, soporte post-entrega ni alcances no descritos aquí.