ConTodo ERP — Backlog Completo de Producto
Propósito. Este documento es el backlog único de delivery de ConTodo: descompone los 18 módulos en una jerarquía Epic → Feature → User Story (US), cada US con criterios de aceptación en formato Gherkin (Given/When/Then), estimación en story points (SP), prioridad MoSCoW y release asignado (MVP / R2 / R3). Consolida el documento de Product Management (agente 2), integra las cinco condiciones P0 bloqueantes del quality gate de dominio (debate-03) y adopta el set de cifras canónicas reconciliadas del debate-01. Es el contrato de planificación entre Producto, Arquitectura, Backend, Frontend, QA, DevOps y Go-to-Market.
Disclaimer profesional (anti-overclaiming). Las normas tributarias peruanas (SUNAT) cambian con frecuencia. Los criterios de aceptación referidos a CPE, SIRE, PLE, detracciones, percepciones y PLAME reflejan el marco vigente a junio 2026 y deben revalidarse en homologación antes de cada release. ConTodo facilita el cumplimiento; la responsabilidad tributaria es del contribuyente. Las estimaciones son supuestos de planificación, no compromisos contractuales.
1. Convenciones del backlog
1.1 Jerarquía y nomenclatura
| Elemento | Código | Ejemplo |
|---|
| Epic | E-NN | E-02 Facturación Electrónica SUNAT |
| Feature | F-NN.M | F-02.1 Emisión de CPE |
| User Story | US-NN.M.K | US-02.1.1 Emitir factura desde pedido |
1.2 Escala de estimación (Story Points, Fibonacci)
Escala relativa de complejidad+esfuerzo+incertidumbre. Referencia de velocity supuesta: 2 squads × ~40 SP/sprint de 2 semanas = ~80 SP/sprint en régimen.
| SP | Significado | Esfuerzo aprox. de referencia |
|---|
| 1 | Trivial | < 0.5 día |
| 2 | Muy pequeño | ~1 día |
| 3 | Pequeño | 1–2 días |
| 5 | Mediano | 3–4 días |
| 8 | Grande | ~1 semana |
| 13 | Muy grande (candidato a split) | ~2 semanas |
| 21 | Épico mal descompuesto (DEBE dividirse) | > 2 semanas |
1.3 Prioridad MoSCoW (alineada al scoring del documento funcional)
Score = BV*0.35 + RG*0.30 + DEP*0.20 + ESF*0.15 (BV: valor de negocio, RG: urgencia regulatoria, DEP: dependencia/habilitador, ESF: esfuerzo inverso).
| MoSCoW | Significado | Regla de release |
|---|
| Must | Sin esto el release no se entrega | MVP o el release donde es bloqueante |
| Should | Importante, no bloqueante; se sacrifica si hay riesgo de fecha | R2 / R3 |
| Could | Deseable; primero en caerse | R3 / backlog |
| Won't (this release) | Fuera de alcance explícito, documentado anti-scope-creep | Roadmap |
1.4 Mapa de releases (eje temporal único — canónico debate-01)
Eje temporal canónico: Mes 0 = kickoff de desarrollo, Julio 2026. Reconcilia el calendario fragmentado de los documentos comerciales.
| Release | Equivale a fase funcional | Ventana | Outcome de negocio | Hito comercial |
|---|
| MVP | F0 Fundaciones + F1 Core comercial+fiscal | Mes 0–8 | Comercializadora/importadora factura y controla stock cumpliendo SUNAT | Primeros 3 pilotos de pago (~150 clientes fin Año 1) |
| R2 | F2 Profundidad financiera | Mes 8–14 | Cierre contable y EEFF en plataforma; importaciones con costeo | Reemplazo de CONCAR/SISCONT (~575 clientes fin Año 2) |
| R3 | F3 Verticalización (+ habilitadores de F4) | Mes 14–20 | Manufactura textil, CRM, multimoneda con ajuste FX | Penetración vertical textil (~1.500 clientes fin Año 3) |
| Roadmap (R4+) | F4 Talento + Inteligencia | Mes 20+ | RRHH/Planillas (PLAME), BI, IA | Upsell + expansión LATAM |
1.5 Definition of Done (DoD) transversal — aplica a TODA User Story
2. Resumen ejecutivo del backlog
2.1 Mapa Epic → Módulo → Release
2.2 Inventario de Epics, capacidad estimada y prioridad
| Epic | Nombre | Módulos | MoSCoW | Release | SP totales | Condiciones P0 dominio |
|---|
| E1 | Plataforma Multi-Tenant Segura | 1,2,3 | Must | MVP | 89 | RN-01, RN-18, RN-19 |
| E2 | Facturación Electrónica SUNAT | 7 + Cumpl. | Must | MVP | 110 | RN-05, RN-06, RN-11, RN-13 |
| E3 | Inventario Valorizado | 4,5 | Must | MVP | 76 | RN-12 |
| E4 | Ciclo Compra-Venta (O2C) | 7 | Must | MVP | 50 | — |
| E5 | Abastecimiento Local (P2P) | 6 | Must | MVP | 42 | RN-11 |
| E6 | Tesorería | 12 | Should | MVP/R2 | 47 | — |
| E18 | Onboarding y Migración de datos | transversal | Should | MVP/R2 | 47 | (R8 comercial) |
| E7 | Contabilidad PCGE | 11 | Must | R2 | 113 | RN-02, RN-03, RN-04, RN-10 |
| E8 | Estados Financieros | 13 | Should | R2 | 47 | RN-04 |
| E9 | Importaciones y Landed Cost | 10 | Should | R2 | 89 | RN-07, RN-08, RN-09, G1 |
| E10 | Logística y GRE | 9 | Should | R2 | 39 | RN-06 |
| E11 | Producción Textil | 8 | Could | R3 | 97 | RN-10, RN-16, RN-17 |
| E12 | CRM | 16 | Could | R3 | 34 | — |
| E13 | Multimoneda y Ajuste FX | transversal | Should | R3 | 42 | RN-15 |
| E14 | RRHH | 14 | Could | R4+ | 34 | — |
| E15 | Planillas PLAME | 15 | Should | R4+ | 63 | — |
| E16 | BI | 17 | Could | R4+ | 47 | — |
| E17 | IA Práctica | 18 | Won't (inicial) → Could | R4+ | 55 | — |
| Total | | | | | ~1.221 SP | |
Lectura de capacidad. A ~80 SP/sprint y descontando ~25% de overhead (ceremonias, bugs, spikes, deuda), la velocity efectiva es ~60 SP/sprint. El alcance MVP (E1–E6 + E18 ≈ 461 SP) cabe en ~8 sprints (~16 semanas de construcción + buffer de homologación SUNAT), consistente con la ventana Mes 0–8. R2 (≈ 288 SP) ~5 sprints; R3 (≈ 173 SP) ~3 sprints. Roadmap R4+ (≈ 199 SP) fuera del horizonte de este backlog.
2.3 Distribución MoSCoW (sobre US del backlog)
| MoSCoW | % SP | Comentario |
|---|
| Must | ~47% | Núcleo no negociable (plataforma + fiscal + inventario) |
| Should | ~31% | Profundidad financiera, importaciones, planillas |
| Could | ~17% | Producción, CRM, RRHH, BI |
| Won't (release inicial) | ~5% | IA diferida hasta masa de datos (anti-overclaiming) |
3. RELEASE MVP (Mes 0–8) — Core comercial + fiscal
Objetivo del MVP. Una comercializadora/importadora pequeña opera de punta a punta cumpliendo SUNAT: factura electrónica, controla stock valorizado, registra compras y maneja caja básica, con SIRE/PLE básico. Criterios de éxito: ≤5 días a 1ra factura, ≥99% aceptación SUNAT 1er intento, ≥3 pilotos facturando, p95 emisión CPE ≤3s, descuadre Kardex 0 céntimos.
Objetivo de negocio: plataforma segura, aislada por tenant y lista para pilotos; habilitador de todos los demás módulos.
Feature F-01.1 — IAM, autenticación y MFA (Must)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-01.1.1 | Como usuario quiero autenticarme con email+contraseña y MFA TOTP para proteger mi cuenta. | Dado un usuario con rol con acceso a contabilidad/tesoreria, cuando inicia sesión, entonces el sistema exige MFA TOTP obligatorio. Dado 5 intentos fallidos en 10 min, entonces la cuenta se bloquea temporalmente. Dado 30 min de inactividad, entonces la sesión expira. | 8 | Must |
| US-01.1.2 | Como usuario quiero recuperar mi contraseña por email seguro para no perder acceso. | Dado un token de reset, cuando expira (≤30 min) o se usa, entonces queda inválido; el evento se registra en audit log. | 3 | Must |
Feature F-01.2 — RBAC granular y segregación de funciones (SoD) (Must)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-01.2.1 | Como admin de empresa quiero crear roles con permisos por módulo y acción para garantizar SoD. | Dado un rol "Cajero" con tesoreria:read,cobrar, entonces no puede acceder a contabilidad:*. Dado un rol sin permisos, cuando se guarda, entonces el sistema lo rechaza. | 8 | Must |
| US-01.2.2 | Como auditor quiero un audit log inmutable de cada cambio de permiso y operación sensible para trazabilidad. | Dado una asignación/revocación de permiso, entonces se registra usuario, IP y timestamp (UTC-5); el registro no es editable ni borrable. | 5 | Must |
Feature F-01.3 — Aislamiento multi-tenant / multiempresa / multisucursal (Must · RN-01)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-01.3.1 | Como usuario de grupo empresarial quiero cambiar de empresa/sucursal activa sin re-login para operar varias razones sociales. | Dado un usuario en N empresas, cuando cambia de empresa, entonces todos los queries filtran por tenant_id+company_id; la sucursal activa fija almacén y serie por defecto. | 8 | Must |
| US-01.3.2 | Como arquitecto de datos quiero RLS de PostgreSQL por tenant para impedir fuga de datos entre empresas. | Dado el test automatizado de aislamiento en CI, entonces ningún query devuelve filas de otra empresa; el build falla si una tabla nueva no tiene policy RLS. | 13 | Must |
Feature F-01.4 — Maestro de Empresas, sucursales y certificado digital (Must · RN-18)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-01.4.1 | Como admin quiero registrar empresa (RUC), sucursales, series y puntos de emisión para operar facturación. | Dado un RUC, cuando se valida por módulo 11, entonces se acepta; cada sucursal define serie y almacén por defecto. | 5 | Must |
| US-01.4.2 | Como admin quiero cargar el certificado digital cifrado por empresa para firmar comprobantes. | Dado un certificado, entonces se almacena en KMS/secrets (nunca en repo), aislado por tenant; rota sin afectar emisión. | 8 | Must |
| US-01.4.3 | Como plataforma quiero parámetros tributarios versionados por vigencia (UIT, IGV, IPM, detracciones) para no hardcodear tasas. | Dado una tasa con vigencia, cuando cambia la normativa, entonces se crea nueva versión sin alterar comprobantes históricos. | 8 | Must |
Feature F-01.5 — Usuarios y portal multi-cliente para estudios contables (Should)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-01.5.1 | Como contador de estudio quiero operar varios RUC desde una cuenta para atender mi cartera. | Dado un contador asignado a N empresas, cuando selecciona una, entonces ve solo sus datos; el cambio queda en audit log. | 8 | Should |
| US-01.5.2 | Como admin quiero invitar usuarios por email y asignar rol por empresa/sucursal para gestionar el equipo. | Dado una invitación, cuando el usuario la acepta, entonces obtiene el rol del contexto invitado; permiso efectivo = rol en empresa/sucursal activa. | 5 | Should |
Subtotal E1: 89 SP.
Epic E2 — Facturación Electrónica SUNAT (CPE/SIRE/PLE) (Must · MVP · 110 SP)
Objetivo de negocio: emitir comprobantes válidos ante SUNAT en 1er intento y cumplir la obligación mensual (SIRE/PLE) sin doble digitación. Foso principal del producto. Integra condiciones P0 de dominio.
Feature F-02.1 — Gateway de emisión (Strategy: OSE primero, SEE fast-follow) (Must · decisión A4 debate-01)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-02.1.1 | Como producto quiero un ComprobanteGateway abstracto (patrón Strategy) para enviar vía OSE en MVP y migrar a SEE propio sin reescribir. | Dado la config de la empresa, cuando emite, entonces el gateway enruta a OSE; el contrato del gateway no cambia al activar SEE propio (año 2). | 13 | Must |
| US-02.1.2 | Como plataforma quiero almacenar XML/CDR/TXT inmutables en S3 ≥5 años para conservación legal (RN-13). | Dado un CPE aceptado, entonces XML firmado + CDR quedan en S3 con object-lock; recuperables en auditoría. | 5 | Must |
Feature F-02.2 — Emisión de CPE: factura/boleta/NC/ND (Must · RN-05, RN-06, RN-11)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-02.2.1 | Como vendedor quiero emitir factura/boleta electrónica para cumplir SUNAT y cobrar. | Dado un pedido con RUC válido (módulo 11), cuando emito, entonces se genera UBL 2.1 firmado XAdES-BES, se envía y se obtiene CDR de aceptación; representación PDF + QR. Dado rechazo, entonces el motivo se muestra legible y el comprobante queda rechazado. | 13 | Must |
| US-02.2.2 | Como contador quiero que el tributo se modele como IGV 16% + IPM 2% y se presente consolidado al 18% para que la cuenta 40 concilie (RN-05, P0 BLOQUEANTE). | Dado una venta, entonces internamente registra IGV(16%) e IPM(2%) en cuentas distintas; cuando se genera UBL/RVIE, entonces se presenta 18% consolidado. El test verifica suma exacta y cuadre de cuenta 40. | 8 | Must |
| US-02.2.3 | Como vendedor quiero emitir Nota de Crédito/Débito con tipo de motivo y referencia al documento original para evitar rechazo SUNAT 2xxx (RN-11, P0). | Dado una NC/ND, cuando no tiene motivo o referencia válida, entonces el sistema impide emitir; cuando los tiene, entonces SUNAT acepta. | 8 | Must |
| US-02.2.4 | Como plataforma quiero numeración correlativa por serie/punto de emisión sin saltos ni duplicados para cumplir RN-06. | Dado emisiones concurrentes, entonces constraint UNIQUE(serie, número, RUC) garantiza correlatividad; bajo carga no hay duplicados. | 8 | Must |
| US-02.2.5 | Como contador quiero cálculo de detracción por código de bien/servicio versionado con umbral S/ 700 para no perder crédito fiscal (RN-14). | Dado una operación afecta, cuando supera S/ 700 y tiene código con tasa vigente, entonces se calcula la detracción correcta (no 12% fijo); por debajo del umbral, no detrae. | 5 | Should |
Feature F-02.3 — Guía de Remisión Electrónica (GRE) (Should · RN-06)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-02.3.1 | Como operador logístico quiero emitir GRE-Remitente con motivo de traslado para mover bienes legalmente. | Dado un traslado, cuando emito GRE, entonces valida motivo, datos MTC de vehículo/conductor y se acepta; trazabilidad de tránsito. | 8 | Should |
Feature F-02.4 — SIRE (RVIE/RCE) y PLE 5.x (Must · O5)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-02.4.1 | Como contadora quiero generar y conciliar la propuesta RVIE/RCE de SUNAT vs. mis registros para cumplir el mensual sin doble digitación. | Dado un periodo, cuando solicito la propuesta, entonces ConTodo concilia con tolerancia de céntimos por redondeo; diferencias se marcan; permite aceptar/reemplazar/complementar; archiva ticket + constancia. | 13 | Must |
| US-02.4.2 | Como contadora quiero exportar PLE 5.x para los libros restantes para completar mi obligación. | Dado un libro, entonces se exporta TXT en formato vigente que pasa el validador SUNAT. | 8 | Should |
| US-02.4.3 | Como contadora quiero que la DUA/DAM figure como tipo de documento 50 en el RCE para sustentar el crédito fiscal de importación (G1, P0). | Dado una compra de importación nacionalizada, cuando genero el RCE, entonces el crédito fiscal cuelga del número de DUA (tipo 50), no de la factura del proveedor exterior. | 8 | Must |
Subtotal E2: 110 SP. Nota: F-02.4.3 depende de E9 (Importaciones, R2); en MVP se entrega el campo y validación, el flujo completo cierra en R2.
Epic E3 — Control de Inventario Valorizado (Must · MVP · 76 SP)
Objetivo de negocio: stock valorizado en tiempo real por almacén, Kardex que cuadra al céntimo (criterio de éxito MVP).
Feature F-03.1 — Maestro de productos y almacenes (Must)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-03.1.1 | Como jefe de inventario quiero crear productos/SKU con unidad de medida y conversiones para controlar existencias. | Dado un producto con UM base y alterna, cuando registro un movimiento en UM alterna, entonces convierte correctamente a UM base. Tipos: MP/SEMI/PT. | 5 | Must |
| US-03.1.2 | Como jefe de almacén quiero gestionar almacenes (físico, virtual, en tránsito) para segmentar existencias. | Dado un almacén por sucursal, entonces el stock se controla por almacén; transferencias entre almacenes registran salida+entrada. | 5 | Must |
| US-03.1.3 | Como jefe textil quiero producto configurable matriz talla × color (size grading) para manejar variantes. | Dado una matriz talla×color, cuando genero variantes, entonces cada SKU hijo controla stock propio bajo el producto padre. | 8 | Should |
Feature F-03.2 — Kardex valorizado y costeo (Must · RN-12)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-03.2.1 | Como jefa de almacén quiero ver stock y valorización en tiempo real por almacén para evitar quiebres y descuadres. | Dado entradas/salidas/transferencias, entonces saldo y costo se actualizan según método (Promedio Móvil default); el Kardex cuadra con Inventario al céntimo (0 descuadre). | 13 | Must |
| US-03.2.2 | Como plataforma quiero costo promedio móvil transaccional a prueba de concurrencia para evitar costos negativos (RN-12). | Dado movimientos concurrentes del mismo SKU+almacén, entonces el cálculo se serializa (lock pesimista o cola por SKU+almacén); nunca produce costo negativo. | 13 | Must |
| US-03.2.3 | Como contadora quiero exportar Kardex Formato 12.1 (físico) y 13.1 (valorizado) SUNAT para cumplir según mis ingresos. | Dado un periodo, entonces se exporta TXT/Excel formato SUNAT y visor web; cuadra con cuentas 20/21/24. | 8 | Should |
Subtotal E3: 76 SP. PEPS avanzado, lotes/series y vencimientos quedan post-MVP (R2/R3).
Epic E4 — Ciclo Compra-Venta (Order-to-Cash) (Must · MVP · 50 SP)
Objetivo de negocio: flujo cotización → pedido → factura sin re-digitar, con trazabilidad documental y control de crédito.
Feature F-04.1 — Cotización → Pedido → Comprobante (Must)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-04.1.1 | Como vendedor quiero convertir cotización aprobada en pedido y luego en factura para no re-digitar. | Dado una cotización aprobada, cuando la convierto, entonces hereda ítems/precios al pedido y al CPE con trazabilidad cotización↔pedido↔factura↔guía. | 8 | Must |
| US-04.1.2 | Como gerente quiero bloquear ventas que exceden la línea de crédito del cliente para controlar riesgo. | Dado un cliente con línea de crédito, cuando el pedido la excede, entonces se bloquea o requiere aprobación con permiso específico. | 5 | Must |
| US-04.1.3 | Como vendedor quiero aplicar precios y descuentos por política para respetar márgenes. | Dado una lista de precios y reglas de descuento, cuando cotizo, entonces se aplican y se impide descuento sobre el límite sin autorización. | 5 | Should |
Feature F-04.2 — Salida de inventario y COGS al facturar (Must)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-04.2.1 | Como plataforma quiero descontar stock y registrar COGS al emitir el comprobante para mantener Kardex y margen coherentes. | Dado una factura emitida, entonces se genera salida de Kardex a costo promedio y se abre CxC; el margen refleja costo real. | 8 | Must |
Feature F-04.3 — Reportes operativos comerciales (Should)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-04.3.1 | Como gerente quiero reportes de ventas, márgenes y stock para decidir. | Dado un rango de fechas, entonces muestra ventas por línea/cliente, márgenes y stock valorizado, exportable. | 8 | Should |
Subtotal E4: 50 SP.
Epic E5 — Abastecimiento Local (Procure-to-Pay) (Must · MVP · 42 SP)
Objetivo de negocio: OC → recepción → registro de compra con sustento de crédito fiscal y detracción/percepción.
Feature F-05.1 — Orden de compra y recepción (Must)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-05.1.1 | Como jefa de compras quiero emitir OC y registrar recepción a almacén para controlar abastecimiento. | Dado una OC, cuando recibo la mercadería, entonces entra al Kardex valorizado y la recepción se concilia con la OC (cantidades, diferencias). | 8 | Must |
Feature F-05.2 — Registro de compra y crédito fiscal (Must · RN-11)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-05.2.1 | Como contadora quiero registrar la factura de compra con IGV crédito fiscal, detracción y percepción para sustentar el RCE. | Dado una factura local, entonces calcula IGV(16%)+IPM(2%), detracción por código (umbral S/ 700) y percepción aplicable; alimenta el RCE. | 8 | Must |
| US-05.2.2 | Como contadora quiero registrar NC/ND de compra con motivo y referencia para ajustar correctamente. | Dado una NC de compra, cuando no referencia el documento original, entonces se impide; con referencia válida, ajusta crédito fiscal. | 5 | Must |
| US-05.2.3 | Como comprador quiero registrar anticipos a proveedor con detracción para el flujo común de adelantos. | Dado un anticipo, entonces se modela con detracción y se concilia contra la factura final (diferencia de cambio cuando aplique). | 8 | Should |
Feature F-05.3 — Aprobaciones de compra (Could)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-05.3.1 | Como gerente quiero aprobaciones multinivel de OC por monto para controlar gasto. | Dado una OC sobre umbral, entonces requiere aprobación del nivel correspondiente antes de enviarse. | 5 | Could |
Subtotal E5: 42 SP. Cotización a proveedores y aprobaciones avanzadas son post-MVP (R2).
Epic E6 — Tesorería (Should · MVP/R2 · 47 SP)
Objetivo de negocio: caja/bancos, cobros/pagos con medios locales (Yape/Plin/CCI/detracción BN) y posición de caja.
Feature F-06.1 — Caja, bancos, cobros y pagos (Should)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-06.1.1 | Como cajero quiero registrar cobros y pagos por Yape/Plin/CCI/cheque/efectivo para cerrar caja. | Dado un cobro, cuando lo confirmo, entonces cancela la CxC y registra el medio de pago; afecta caja/banco correcto. | 8 | Should |
| US-06.1.2 | Como gerente quiero posición de caja proyectada (CxC+CxP programadas) para anticipar liquidez. | Dado vencimientos abiertos, entonces muestra flujo proyectado multimoneda/multiempresa. | 8 | Should |
| US-06.1.3 | Como contadora quiero gestionar detracción pendiente de depósito (Banco de la Nación) para no perder crédito (F3). | Dado una detracción no depositada, entonces el estado bloquea el uso del crédito fiscal hasta confirmar constancia BN. | 8 | Should |
Feature F-06.2 — Conciliación bancaria (Should · R2)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-06.2.1 | Como contadora quiero importar extractos y conciliar por matching monto+fecha+referencia para cerrar bancos rápido. | Dado un extracto, entonces sugiere matches; lo no conciliado queda en bandeja; conciliación auditable. | 13 | Should |
Feature F-06.3 — Asientos automáticos de tesorería (Should · R2)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-06.3.1 | Como plataforma quiero generar CUSTOMER_PAYMENT/SUPPLIER_PAYMENT al confirmar movimiento para integrar con contabilidad. | Dado un cobro/pago confirmado, entonces dispara la plantilla contable correspondiente (depende de E7). | 5 | Should |
Subtotal E6: 47 SP. Registro de cobros/pagos en MVP; conciliación automática y asientos en R2 (al liberar E7).
Epic E18 — Onboarding y Migración de datos (Should · MVP/R2 · 47 SP)
Objetivo de negocio: reducir el costo de cambio desde CONCAR/SISCONT/Excel — barrera #1 de adopción (debate-01 A8, debate-03 §6). Tratada como inversión de producto, no como servicio manual.
Feature F-18.1 — Onboarding guiado y plantillas por vertical (Should)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-18.1.1 | Como nuevo cliente quiero un asistente de onboarding con plantillas (textil/importadora/distribuidora) para emitir mi 1ra factura en ≤5 días. | Dado un tenant nuevo, cuando elige su vertical, entonces precarga catálogos, series y configuración base; checklist guía hasta la 1ra emisión. | 8 | Should |
Feature F-18.2 — Importadores de datos legacy (Should)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-18.2.1 | Como contadora migrante quiero importar maestros (clientes, proveedores, productos) desde Excel/CSV para no re-digitar. | Dado una plantilla Excel, cuando la cargo, entonces valida, muestra errores por fila y permite corregir antes de confirmar. | 8 | Should |
| US-18.2.2 | Como contadora migrante quiero importar plan de cuentas y saldos iniciales desde CONCAR/SISCONT para no perder mi historia. | Dado un export CONCAR/SISCONT, cuando mapeo cuentas al PCGE, entonces carga saldos iniciales cuadrados (Σdebe=Σhaber) y registra el mapeo. | 13 | Should |
| US-18.2.3 | Como contadora migrante quiero un asistente de mapeo de plan de cuentas para conciliar mi catálogo con el PCGE. | Dado cuentas origen, entonces sugiere mapeo al PCGE 2019, marca no mapeadas y guarda la correspondencia versionada. | 8 | Should |
Feature F-18.3 — Migración de comprobantes históricos (Could · R2)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-18.3.1 | Como cliente migrante quiero importar comprobantes históricos (solo lectura/consulta) para conservar mi archivo. | Dado XMLs/registros previos, entonces se importan como históricos consultables sin reenviar a SUNAT. | 10 | Could |
Subtotal E18: 47 SP. F-18.1/18.2 en MVP (onboarding crítico); F-18.3 en R2.
4. RELEASE R2 (Mes 8–14) — Profundidad financiera
Objetivo R2. Cierre contable y EEFF en plataforma, e importaciones con costeo nacionalizado. Permite reemplazar CONCAR/SISCONT. Integra las condiciones P0 de contabilidad y nacionalización del quality gate.
Epic E7 — Contabilidad PCGE con asientos automáticos (Must · R2 · 113 SP)
Objetivo de negocio: mayor multi-tenant/multimoneda con partida doble garantizada en BD y ≥85% de asientos automáticos desde la operación.
Feature F-07.1 — Núcleo contable (PCGE + partida doble en BD) (Must · RN-02, RN-03, RN-04)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-07.1.1 | Como contadora quiero catálogo PCGE 2019 precargado y extensible por empresa para operar el mayor. | Dado una empresa nueva, entonces hereda PCGE is_system; puede crear divisionarias propias sin alterar las del sistema. | 8 | Must |
| US-07.1.2 | Como plataforma quiero partida doble inviolable validada en BD (constraint+trigger) para garantizar integridad (RN-02). | Dado un asiento, cuando Σdebe ≠ Σhaber por moneda funcional, entonces la BD lo rechaza (no solo la app). | 13 | Must |
| US-07.1.3 | Como auditor quiero inmutabilidad del asiento posted (corrección por extorno) para trazabilidad (RN-03). | Dado un asiento posted, cuando se intenta editar, entonces se impide; la corrección genera extorno/ajuste enlazado. | 8 | Must |
| US-07.1.4 | Como contadora quiero cierre de periodo (period_locked) irreversible salvo excepción auditada para proteger SIRE (RN-04, F5). | Dado un periodo cerrado con SIRE generado, cuando llega un asiento posterior, entonces obliga a complementar (no editar); la reapertura exige flujo de excepción auditado. | 8 | Must |
Feature F-07.2 — Motor de plantillas de asientos (Must)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-07.2.1 | Como contadora quiero plantillas de asiento parametrizables por evento y empresa para automatizar la operación. | Dado un evento (venta, compra, cobro), entonces genera el asiento según plantilla; ≥85% de asientos automáticos. | 13 | Must |
| US-07.2.2 | Como contadora quiero editar plantillas con dry-run, versionado y auditoría para adaptar sin riesgo. | Dado una edición de plantilla, cuando ejecuto dry-run, entonces muestra el asiento resultante sin postear; al guardar versiona y audita. | 8 | Must |
Feature F-07.3 — Subledgers CxC/CxP conciliados (Must · RN-20)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-07.3.1 | Como contadora quiero subledgers de CxC (12) y CxP (42) con aging conciliados al mayor para controlar cartera. | Dado el cierre, cuando corre el job nocturno, entonces concilia subledger ↔ mayor (12/42) y alerta si difieren. | 13 | Must |
| US-07.3.2 | Como contadora quiero provisiones y aging de cartera para gestionar incobrables. | Dado vencimientos, entonces clasifica por tramos de aging y permite provisión con asiento. | 8 | Should |
Feature F-07.4 — Plantillas de producción WIP→FG→COGS (Must · RN-10, G2, P0)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-07.4.1 | Como contadora industrial quiero plantillas WIP_ISSUE/WIP_LABOR/WIP_OVERHEAD/FG_RECEIPT (circuito 6→9→23→21→69) para que el Kardex de producción tenga espejo en el mayor (P0 BLOQUEANTE). | Dado una orden de producción, entonces los costos MP/MOD/CIF fluyen clase 6 → 79/91 → 23 → 21 → 69; el balance de comprobación cuadra contra el inventario. | 13 | Must |
Feature F-07.5 — Activos fijos e impuesto diferido (Should)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-07.5.1 | Como contadora quiero activos fijos con doble tratamiento contable/tributario (NIC 12) para calcular impuesto diferido. | Dado un activo, entonces registra depreciación contable y tributaria; calcula diferencia temporal y asiento de impuesto diferido. | 13 | Should |
Subtotal E7: 113 SP. F-07.4 se entrega en R2 aunque Producción (E11) sea R3: las plantillas son prerrequisito contable P0.
Epic E8 — Estados Financieros NIIF (Should · R2 · 47 SP)
Objetivo de negocio: EEFF en tiempo real con drill-down hasta el documento origen (diferenciador vs. Defontana/StarSoft).
Feature F-08.1 — Generación de los 4 EEFF (Should)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-08.1.1 | Como gerente/contadora quiero ESF, ER, EFE (indirecto) y ECPN derivados del balance de comprobación para ver la salud financiera. | Dado un periodo, entonces genera los 4 EEFF (NIC 1/7) mapeando fs_caption por cuenta; base devengo. | 13 | Should |
| US-08.1.2 | Como gerente quiero drill-down rubro → cuenta → asiento → documento para auditar cada cifra. | Dado un rubro del EEFF, cuando hago clic, entonces navego hasta el asiento y el documento origen. | 8 | Should |
| US-08.1.3 | Como plataforma quiero saldos en tabla agregada account_balances para rendimiento a escala SaaS. | Dado el reporte, entonces lee de saldos precalculados (no SUM en caliente); se reconstruye consistente con el mayor. | 8 | Should |
Feature F-08.2 — Cierre contable asistido (Should)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-08.2.1 | Como contadora quiero cierre asistido (corridas, balance, destino de resultados clase 8→59, bloqueo) para cerrar el periodo con control. | Dado un cierre, entonces ejecuta corridas automáticas, valida balance, traslada resultado y bloquea el periodo (RN-04). | 13 | Should |
Feature F-08.3 — Multi-GAAP (Won't en R2 → roadmap P2)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-08.3.1 | Como empresa quiero reportar NIIF y tributario simultáneo para doble propósito. | Roadmap. No se promete en R2 (anti-overclaiming, overkill para PYME). | 5 | Won't (R2) |
Subtotal E8: 47 SP (multi-GAAP fuera de R2).
Epic E9 — Importaciones y Landed Cost (Should · R2 · 89 SP)
Objetivo de negocio: costeo nacionalizado prorrateado multi-base con asiento de nacionalización desdoblado (foso real vs. competencia). Integra P0 de dominio.
Feature F-09.1 — Expediente de importación (máquina de estados) (Should)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-09.1.1 | Como jefa de importaciones quiero gestionar el expediente por su máquina de estados (Cotización→…→Ingresada) para controlar el proceso de 60–120 días. | Dado un expediente, cuando avanza de estado, entonces registra hitos; alertas Sidekiq si supera SLA (canal rojo). | 13 | Should |
| US-09.1.2 | Como jefa de importaciones quiero que el Incoterm precargue qué conceptos vienen incluidos para no omitir flete/seguro. | Dado Incoterm FOB, entonces el sistema exige registrar flete y seguro antes de numerar la DAM. | 5 | Should |
Feature F-09.2 — Costeo nacionalizado (prorrateo multi-base) (Should · RN-07, RN-15)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-09.2.1 | Como contadora de costos quiero prorratear conceptos por su base (flete/peso, seguro/FOB, ad-valorem/CIF) para el costo unitario nacionalizado real. | Dado una DAM, entonces prorratea cada concepto por su base; van al costo los no recuperables; NO van al costo IGV/IPM/Percepción (cuenta 40). | 13 | Should |
| US-09.2.2 | Como contadora quiero bloquear la valorización hasta DAM numerada para integridad NIC 2 (RN-07). | Dado mercadería en tránsito, cuando no hay DAM numerada, entonces no se valoriza el ingreso a Kardex. | 8 | Should |
| US-09.2.3 | Como contadora quiero diferencia de cambio (TC OCI/anticipo vs DAM) a cuentas 67/77, no al costo para no inflar inventario (RN-15). | Dado TC distintos, entonces la diferencia va a 67/77; un test impide que entre al costo del inventario. | 8 | Should |
| US-09.2.4 | Como jefa de importaciones quiero costeo proyectado en cotización + real al cierre con variación para decidir margen. | Dado una cotización, entonces estima costo nacionalizado; al cerrar, calcula variación proyectado vs. real. | 8 | Should |
Feature F-09.3 — Asiento de nacionalización desdoblado (Should · RN-08, RN-09, G1, P0)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-09.3.1 | Como contadora quiero el asiento de nacionalización desdoblado en 3 acreedores para conciliar correctamente (P0 BLOQUEANTE). | Dado una nacionalización, entonces genera: (a) 42/46 proveedor exterior por FOB+flete+seguro; (b) 40/10 Aduanas/Bancos por ad-valorem+IGV+IPM+percepción; (c) 42/63 agente de aduana. | 8 | Should |
| US-09.3.2 | Como contadora quiero bloquear el crédito fiscal de importación hasta Nacionalizada + tributos pagados, colgado de la DUA tipo 50 para cumplir RN-08/G1/F1. | Dado una importación, cuando no está nacionalizada con tributos pagados, entonces el crédito fiscal no se toma; al cumplirse, cuelga de la DUA (tipo 50) en el RCE. | 8 | Should |
Feature F-09.4 — Retención a no domiciliados (Could · G10 · P2)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-09.4.1 | Como contadora quiero calcular retención a no domiciliados (Art. 76 LIR) por flete/regalías para evitar multa. | Dado un servicio del exterior afecto, entonces calcula y registra la retención correspondiente. | 8 | Could |
Subtotal E9: 89 SP.
Epic E10 — Logística y GRE avanzada (Should · R2 · 39 SP)
Objetivo de negocio: traslado de bienes con guías electrónicas y trazabilidad, incluido el flujo de transformación (maquila).
Feature F-10.1 — GRE Remitente/Transportista y trazabilidad MTC (Should · RN-06)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-10.1.1 | Como operador quiero emitir GRE-Remitente y GRE-Transportista con motivos para trasladar bienes legalmente. | Dado un traslado, entonces valida motivo (venta, transformación, consignación, traslado entre almacenes), registro MTC y trazabilidad de tránsito. | 13 | Should |
| US-10.1.2 | Como operador textil quiero el motivo "traslado por transformación" que NO genera IGV débito para maquila correcta. | Dado un envío a taller, cuando uso motivo transformación, entonces no se trata como venta ni genera débito fiscal. | 8 | Should |
Feature F-10.2 — Transferencias y consignación (Should)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-10.2.1 | Como jefa de almacén quiero transferencias entre almacenes y bienes en consignación con GRE para controlar tránsito. | Dado una transferencia, entonces genera salida/entrada con GRE; consignación no descuenta como venta hasta liquidar. | 8 | Should |
| US-10.2.2 | Como gerente quiero trazabilidad de tránsito y estados de entrega para visibilidad logística. | Dado una GRE en tránsito, entonces muestra estado (emitida, en tránsito, entregada). | 5 | Should |
Feature F-10.3 — Catálogo MTC vehículos/conductores (Could)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-10.3.1 | Como operador quiero maestro de vehículos y conductores (MTC) para emitir GRE rápido. | Dado un vehículo registrado, cuando emito GRE, entonces autocompleta datos MTC validados. | 5 | Could |
Subtotal E10: 39 SP.
5. RELEASE R3 (Mes 14–20) — Verticalización textil
Objetivo R3. Manufactura textil completa (foso competitivo), CRM integrado y multimoneda con ajuste por diferencia de cambio. ICP año 1 = textil + importadora (debate-01 A9).
Epic E11 — Producción Textil (Costeo industrial) (Could · R3 · 97 SP)
Objetivo de negocio: costeo por Orden de Producción con BOM multinivel, merma acumulada, MOD por destajo/tarja, CIF absorbido y maquila como almacén-tercero — diferenciador que ni Odoo ni CONCAR/SISCONT integran.
Feature F-11.1 — BOM multinivel y explosión de necesidades (Could)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-11.1.1 | Como jefe de costos textil quiero definir BOM multinivel (fibra→hilo→tela→prenda) con merma por etapa para explotar necesidades reales. | Dado un BOM con mermas 12%/5%/7%/6%, cuando programo una OP, entonces calcula que 220 g de tela neta requieren 293 g de fibra (merma acumulada). | 13 | Could |
| US-11.1.2 | Como jefe de costos quiero variantes por matriz talla×color con size grading para costear cada SKU. | Dado una matriz, entonces escala consumos por factor de talla. | 8 | Could |
Feature F-11.2 — Orden de Producción y acumulación de costo (Could)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-11.2.1 | Como jefe de planta quiero acumular costo por OP en MP/MOD/CIF para conocer el costo unitario real. | Dado una OP cerrada, entonces acumula MP (promedio móvil / landed cost), MOD y CIF; emite costo unitario (estructura ~67/18/15). | 13 | Could |
| US-11.2.2 | Como jefe de planta quiero capturar MOD por tarja (tiempo) o destajo (por pieza) para el pago real de costura peruana. | Dado una etapa, cuando registro MOD por destajo, entonces valoriza por pieza incluyendo cargas sociales (factor ~1.45). | 8 | Could |
| US-11.2.3 | Como contadora de costos quiero CIF absorbido por tasa predeterminada (min-MOD/min-máquina) para distribuir indirectos. | Dado una tasa por centro, entonces absorbe CIF a la OP; al cierre calcula sub/sobre absorción (variación CIF, G7). | 13 | Could |
Feature F-11.3 — Maquila como almacén-tercero (Could · RN-16)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-11.3.1 | Como jefe de producción quiero gestionar maquila como almacén-tercero con liquidación merma pactada vs real para no perder control del inventario. | Dado un envío a taller (GRE transformación), entonces el inventario va a almacén-tercero (no es venta); al retorno liquida piezas OK + merma real vs pactada; refleja en Formato 13.1 (RN-16). | 13 | Could |
| US-11.3.2 | Como plataforma quiero definir el costeo del almacén-tercero en el promedio móvil para evitar descuadre (debate-03 §4). | Dado salida a costo y retorno a costo+conversión, entonces aplica la política definida (recalcula promedio o capa identificada) de forma consistente. | 8 | Could |
Feature F-11.4 — Mermas con sustento técnico (Could · RN-17, G8)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-11.4.1 | Como contadora quiero clasificar mermas (normal/anormal/desperdicio/subproducto) y generar sustento técnico para deducibilidad en Renta. | Dado una OP, entonces merma normal va al costo, anormal a gasto del periodo; genera reporte de merma por proceso con % técnico trazable a OP para fiscalización. | 8 | Could |
Subtotal E11: 97 SP.
Epic E12 — CRM (Could · R3 · 34 SP)
Objetivo de negocio: embudo prospecto → oportunidad → cotización integrado con Ventas, sin re-digitación.
Feature F-12.1 — Gestión de prospectos y oportunidades (Could)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-12.1.1 | Como vendedor quiero gestionar prospectos, oportunidades y actividades para seguir mi embudo. | Dado un prospecto, entonces registra etapa, actividades y seguimiento; pipeline visible por vendedor. | 13 | Could |
| US-12.1.2 | Como vendedor quiero convertir una oportunidad CRM en cotización/pedido sin re-digitar para acelerar el cierre. | Dado una oportunidad ganada, cuando la convierto, entonces crea la cotización en Ventas heredando datos del cliente. | 8 | Could |
Feature F-12.2 — Reportes comerciales CRM (Could)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-12.2.1 | Como gerente comercial quiero reportes de embudo y conversión para gestionar el equipo. | Dado un periodo, entonces muestra conversión por etapa, vendedor y línea. | 8 | Could |
| US-12.2.2 | Como vendedor quiero alertas de seguimiento de oportunidades para no perder leads. | Dado una oportunidad sin actividad N días, entonces notifica al responsable. | 5 | Could |
Subtotal E12: 34 SP.
Epic E13 — Multimoneda y Ajuste por Diferencia de Cambio (Should · R3 · 42 SP)
Objetivo de negocio: registro multimoneda desde F0 (ya en plataforma) + ajuste contable FX en R3 (complejo, NIC 21). Decisión escalonada (no pagar complejidad sin demanda).
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-13.1.1 | Como contadora quiero TC SUNAT/SBS diario y registro por línea en moneda origen + funcional (PEN) para NIC 21. | Dado un documento en USD, entonces guarda monto origen + TC + funcional por línea; el TC del día se obtiene automáticamente. | 13 | Should |
Feature F-13.2 — Ajuste por diferencia de cambio (Should · RN-15)
| US | Historia | Criterios de aceptación (Gherkin) | SP | MoSCoW |
|---|
| US-13.2.1 | Como contadora quiero revaluar partidas monetarias en ME al cierre (asiento FX_DIFFERENCE) para reflejar la diferencia de cambio. | Dado saldos en ME al cierre, entonces calcula y postea diferencia de cambio a 67/77 (nunca al costo). | 13 | Should |
| US-13.2.2 | Como contadora quiero distinguir diferencia realizada vs. no realizada (Art. 61 LIR) para el tratamiento tributario correcto (G5). | Dado la revaluación, entonces separa realizada de no realizada y aplica el tratamiento tributario adecuado. | 8 | Should |
| US-13.2.3 | Como gerente quiero reportes y EEFF consolidados en moneda de presentación para ver el grupo en una sola moneda. | Dado empresas en distintas monedas, entonces consolida a la moneda de presentación con TC de cierre. | 8 | Could |
Subtotal E13: 42 SP.
6. ROADMAP R4+ (Mes 20+) — Talento e Inteligencia
Fuera del horizonte de planificación detallada de este backlog. Se lista para completitud y para gobernar el anti-scope-creep. La IA se mantiene Won't en el release inicial (anti-overclaiming): se libera con masa de datos y métricas de ahorro verificables.
| Epic | Nombre | MoSCoW | SP est. | Features clave |
|---|
| E14 | RRHH | Could | 34 | T-Registro, contratos, AFP/ONP, centros de costo (alimenta MOD textil) |
| E15 | Planillas (PLAME/AFPnet) | Should | 63 | Remuneraciones, EsSalud 9%, CTS, gratificaciones, renta 5ta, asiento PAYROLL_ACCRUAL, PLAME, AFPnet |
| E16 | BI | Could | 47 | Dashboards (caja, márgenes, merma por taller, productividad costura), calendario tributario dinámico |
| E17 | IA Práctica | Won't (inicial) → Could | 55 | Conciliación matching difuso, asientos sugeridos, forecast de caja, OCR de DAM, asistente tributario pre-envío |
User Stories representativas (no estimadas en detalle):
- US-15.x.1 — Como planillero quiero calcular la planilla (EsSalud, AFP/ONP, CTS, gratificaciones, renta 5ta) con tasas parametrizadas por año para cumplir laboralmente. (Must dentro de E15.)
- US-15.x.2 — Como contadora quiero generar PLAME y AFPnet para declarar y pagar. (Must dentro de E15.)
- US-16.x.1 — Como gerente quiero un calendario tributario dinámico (último dígito RUC × cronograma SUNAT) con alertas para no incumplir plazos. (Should dentro de E16.)
- US-17.x.1 — Como contadora quiero conciliación bancaria con matching difuso (ML) para ahorrar ≥8 h/mes, liberada solo con datos suficientes y métricas verificables. (Could; Won't en release inicial.)
7. Matriz de trazabilidad: condiciones P0 de dominio → User Stories
Las cinco condiciones P0 bloqueantes del quality gate (debate-03) tienen US dedicadas y son DoD-críticas. Sin ellas, el producto no resiste fiscalización SUNAT ni cierre auditado.
| Condición P0 (debate-03) | Regla | User Story que la cubre | Release |
|---|
| Regla única IGV 16% + IPM 2% (18% presentación) | RN-05 | US-02.2.2 | MVP |
| Asiento de nacionalización desdoblado | RN-09 | US-09.3.1 | R2 |
| Plantillas de producción WIP→FG→COGS (6→9→23→21→69) | RN-10 / G2 | US-07.4.1 | R2 |
| DUA/DAM tipo 50 como sustento de crédito fiscal en RCE | RN-08 / G1 | US-02.4.3 + US-09.3.2 | MVP (campo) / R2 (flujo) |
| NC/ND con motivo y referencia al documento original | RN-11 / G4 | US-02.2.3 + US-05.2.2 | MVP |
7.1 Gaps P1/P2 de dominio mapeados
| Gap | Descripción | US | Release |
|---|
| Detracción por código + umbral S/ 700 (no 12% fijo) | RN-14 | US-02.2.5, US-05.2.1 | MVP |
| Anticipos cliente/proveedor con detracción y FX | G6 | US-05.2.3 | MVP/R2 |
| Diferencia de cambio realizada vs. no realizada (Art. 61) | G5 | US-13.2.2 | R3 |
| Variación CIF (sub/sobre absorción) | G7 | US-11.2.3 | R3 |
| Provisión de mermas anormales con sustento técnico | G8 / RN-17 | US-11.4.1 | R3 |
| Inventario en poder de terceros en Formato 13.1 | G9 / RN-16 | US-11.3.1 | R3 |
| Retención a no domiciliados (Art. 76 LIR) | G10 | US-09.4.1 | R2 (Could) |
| Importador de datos CONCAR/SISCONT (costo de cambio) | debate-03 §6 | US-18.2.2, US-18.2.3 | MVP |
8. Estimación consolidada y plan de capacidad
8.1 Resumen por release
| Release | Epics | SP totales | Sprints (a ~60 SP efectivos) | Ventana |
|---|
| MVP | E1, E2, E3, E4, E5, E6, E18 | 461 | ~8 | Mes 0–8 |
| R2 | E7, E8, E9, E10 | 288 | ~5 | Mes 8–14 |
| R3 | E11, E12, E13 | 173 | ~3 | Mes 14–20 |
| Roadmap R4+ | E14, E15, E16, E17 | 199 | (fuera de horizonte) | Mes 20+ |
| Total backlog | | ~1.221 | | |
8.2 Distribución de SP por dominio
8.3 Supuestos de estimación (explícitos)
| Supuesto | Valor | Riesgo si falla |
|---|
| Velocity por sprint (2 squads, 2 sem.) | ~80 SP nominal / ~60 SP efectivo | Si baja a 45, MVP se corre ~2 meses |
| Overhead (ceremonias, bugs, deuda, spikes) | 25% | Subestimar deuda alarga R2 (módulo contable complejo, R2 debate-01) |
| Homologación SUNAT (CPE/SIRE) | buffer ~3-4 semanas en MVP | Cambios normativos SUNAT (R1) pueden re-trabajar la capa de cumplimiento |
| Squads dedicados sin rotación | sí | Rotación destruye velocity y conocimiento de dominio |
| Spike de Contabilidad/PCGE antes de R2 | sí (R2 debate-01) | Sin spike, E7 se subestima (riesgo histórico de ERP) |
9. Riesgos del backlog y mitigaciones
| ID | Riesgo de delivery | Prob. | Impacto | Mitigación |
|---|
| B1 | Cambios normativos SUNAT durante MVP (SIRE/PLE/UBL) | Alta | Alto | Capa de cumplimiento versionada y aislada; validación contra XSD oficial en CI; OSE como buffer |
| B2 | Subestimación de E7 (Contabilidad/PCGE) — módulo más complejo | Media | Alto | Spike técnico antes de R2; contadora en el equipo; F-07.4 (WIP) priorizada como P0 aunque Producción sea R3 |
| B3 | Scope creep por pedidos de pilotos en MVP | Alta | Medio | MoSCoW estricto; "Won't" documentado; backlog priorizado como contrato |
| B4 | Fuga de datos entre tenants (US-01.3.2) | Baja | Crítico | Tests de aislamiento en CI bloquean el merge; RLS obligatorio por tabla |
| B5 | Concurrencia del costo promedio móvil (US-03.2.2) con maquila | Media | Alto | Lock pesimista/cola serializada; spike de costeo almacén-tercero antes de E11 |
| B6 | Inercia del contador hacia CONCAR/SISCONT (adopción) | Alta | Alto (comercial) | E18 (importadores) elevada a MVP; SIRE impecable (US-02.4.1) |
| B7 | Sobreventa de IA sin datos (E17) | Media | Medio | IA Won't en release inicial; liberar con métricas de ahorro verificables |
| B8 | Dependencia cruzada E6↔E7 y E2.4.3↔E9 mal secuenciada | Media | Medio | Entregar contratos/stubs en el release temprano y cerrar flujo en el posterior (documentado por US) |
10. Oportunidades capturadas en el backlog
| ID | Oportunidad | User Stories que la materializan |
|---|
| O1 | Reemplazo de legacy on-premise (CONCAR/SISCONT) | US-18.2.2, US-18.2.3, US-02.4.1 |
| O2 | Verticalización textil como foso (BOM + maquila + merma) | US-11.1.1, US-11.3.1, US-11.4.1 |
| O3 | Cumplimiento como gancho LATAM (gateway pluggable) | US-02.1.1 (Strategy gateway) |
| O4 | Pago local Yape/Plin + conciliación (alto valor PYME) | US-06.1.1, US-06.2.1 |
| O5 | SIRE nativo automatizado vs. carga manual del legacy | US-02.4.1, US-02.4.3 |
| O6 | EEFF en tiempo real con drill-down (vs. Defontana/StarSoft) | US-08.1.1, US-08.1.2 |
| O7 | IA práctica sobre datos propios (cuando exista masa) | US-17.x.1 (roadmap) |
11. Decisiones de priorización y alternativas evaluadas
| Decisión | Opción elegida | Alternativa descartada | Razón |
|---|
| Foco del MVP | Comercial + fiscal (compra-venta + CPE) | MVP contable primero | Mayor time-to-value e ingreso inmediato (decisión del PM, ratificada en debate-01) |
| Emisión CPE | Gateway: OSE en MVP, SEE propio fast-follow (año 2) | SEE propio en MVP (P0) / solo OSE permanente | Resuelve la contradicción SEE-vs-OSE (debate-01 A4); time-to-market sin perder el foso |
| Plantillas WIP (F-07.4) | Entregar en R2 aunque Producción sea R3 | Posponer a R3 con Producción | Son prerrequisito contable P0; sin ellas el Kardex no tiene espejo en el mayor |
| Importadores legacy (E18) | Elevados a MVP | Tratarlos como servicio manual de onboarding | Barrera #1 de adopción; inversión de producto, no servicio (debate-01 A8) |
| IA (E17) | Won't en release inicial | IA temprana como wrapper LLM | Sin datos no aporta valor verificable (anti-overclaiming) |
| Multimoneda | Registro en plataforma (MVP) + ajuste FX en R3 | Ajuste FX completo desde MVP | Decisión escalonada NIC 21; no pagar complejidad sin demanda |
| Multi-GAAP (US-08.3.1) | Roadmap P2 (Won't en R2) | Prometer en R2 | Overkill para PYME; anti-overclaiming |
| ICP de verticalización R3 | Textil + importadora | 5 verticales a la vez | Cuña afilada; el resto de verticales en año 2 (debate-01 A9) |
12. Conclusión
Este backlog convierte la estrategia de producto de ConTodo en un plan de delivery ejecutable y trazable: 17 Epics activos + 1 roadmap, ~1.221 SP, organizados en tres releases con eje temporal canónico único. El MVP (461 SP) entrega el ciclo comercial+fiscal que permite a una comercializadora/importadora facturar cumpliendo SUNAT en ≤5 días; R2 (288 SP) profundiza contabilidad, EEFF e importaciones para reemplazar a CONCAR/SISCONT; R3 (173 SP) verticaliza en textil, el foso real del producto. Las cinco condiciones P0 del quality gate de dominio están explícitamente mapeadas a User Stories y son DoD-críticas, garantizando que el producto resista fiscalización, cierre auditado y demo comparativa. El mayor riesgo no técnico —la inercia del contador hacia el legacy— se ataca elevando los importadores de datos a MVP. La disciplina MoSCoW + anti-overclaiming (IA diferida, multi-GAAP a roadmap, SEE propio fast-follow) mantiene el alcance honesto y vendible. Este documento es la fuente única de verdad de planificación; cualquier cambio de alcance debe actualizar primero esta priorización.
Backlog completo — propiedad de Producto ConTodo. Fuente: docs/01-agentes. Próxima revisión al cierre del MVP (Mes 8).