# Fibromuebles OS MVP Design ## Contexto Fibromuebles necesita reducir dependencia operativa de Odoo sin intentar clonar Odoo completo. El objetivo de corto plazo es reemplazar el flujo diario que consume tiempo: presupuestar, convertir a pedido, registrar pagos, mover caja y ver pendientes reales en el dashboard. La app actual ya tiene una base util: Next.js + PocketBase, autenticacion por roles, Clientes, Pedidos, Cortes nativo conectado a Pedidos, Caja, Calculadora y modulos legacy como respaldo. El proximo paso debe consolidar el flujo comercial y operativo, no abrir una migracion gigante. ## Decisiones Confirmadas - El numero de presupuesto se asigna al crear el presupuesto, incluso si queda como borrador. - El numero no se recicla si el presupuesto se rechaza, cancela o queda abandonado. - La nomenclatura es `YYMM-####`: ejemplo `2605-0001`. - Los ultimos cuatro digitos suben de forma continua durante el anio y se reinician al empezar el anio siguiente. - Al aprobar un presupuesto no se crea pedido automaticamente. - La creacion de pedido se hace con una accion explicita: `Convertir a pedido`. - El pedido confirmado conserva el mismo numero que el presupuesto. - El primer sprint se concentra en `Presupuestos -> Pedido -> Pagos/Caja -> Dashboard`. - Catalogo avanzado, sitio web, facturacion completa y permisos finos quedan para fases posteriores. ## Objetivo Del MVP Dejar funcional en pocos dias un circuito minimo que permita: 1. Crear un presupuesto numerado. 2. Cargar cliente, descripcion, productos/lineas libres, totales y estado. 3. Aprobar o rechazar el presupuesto sin efectos secundarios peligrosos. 4. Convertir explicitamente un presupuesto aprobado en pedido. 5. Registrar pagos parciales asociados al presupuesto o pedido. 6. Imputar cada pago a una cuenta de caja. 7. Reflejar pagos como movimientos de caja. 8. Mostrar en Inicio los pendientes que requieren accion. ## Alcance Del Primer Sprint ### Arreglos Urgentes - Corregir `Clientes`: los botones `Cerrar` y `Guardar` deben funcionar de forma confiable. - Corregir entrada de texto multilinea en Pedidos para que `Shift + Enter` permita lineas nuevas donde corresponde. - Agregar productos o lineas debajo de la descripcion del pedido. - Agregar flags en Pedido: `hay_que_medir` y `hay_que_enviar`. - Mostrar esos flags como pendientes accionables en Inicio. - Mantener `estado_cortes` sincronizado desde el modulo Cortes, no como dato manual principal. ### Presupuestos Crear un modulo `Presupuestos` con: - Listado con filtros por estado, cliente, numero y fecha. - Formulario de creacion/edicion. - Numero automatico reservado al crear. - Estados minimos: `borrador`, `enviado`, `aprobado`, `rechazado`, `cancelado`. - Datos de cliente reutilizando la coleccion `clientes`. - Descripcion general. - Lineas de presupuesto: producto opcional, descripcion libre, cantidad, precio unitario, subtotal. - Total calculado desde lineas, con ajuste manual diferido fuera del primer sprint. - Accion `Convertir a pedido`, visible solo cuando el presupuesto este aprobado y todavia no tenga pedido asociado. ### Pedidos Actualizar Pedidos para soportar pedidos nacidos desde presupuesto: - Agregar relacion opcional `presupuesto`. - Mantener el mismo numero del presupuesto. - Copiar cliente, descripcion, lineas y total al pedido. - Crear el pedido sin duplicar pagos existentes. - Seguir integrando con Cortes desde el pedido. ### Pagos Y Caja Reemplazar el campo simple `senia` como fuente principal por pagos reales: - Crear coleccion `cuentas` para cuentas como `Efectivo`, `Banco`, `MercadoPago`. - Crear coleccion `pagos` con monto, cuenta, fecha, cliente, presupuesto, pedido y nota. - Permitir pagos parciales. - Calcular pagado y saldo desde la suma de pagos. - Crear un movimiento de caja por cada pago de ingreso. - Evitar doble carga: un pago debe tener un movimiento de caja asociado o una regla idempotente que impida duplicados. ### Inicio / Dashboard Inicio debe mostrar accion, no decoracion: - Presupuestos borrador o enviados pendientes. - Presupuestos aprobados sin convertir a pedido. - Pedidos que requieren medicion. - Pedidos que requieren envio. - Pedidos con saldo pendiente. - Cortes pendientes o en curso. - Ingresos del dia por cuenta para admin. ## Fuera De Alcance Del Primer Sprint - Facturacion fiscal completa. - Integracion AFIP. - Reemplazo contable total. - Sitio web publico conectado al catalogo. - Ecommerce o carrito. - Permisos editables por categoria. - Automatizaciones avanzadas de cotizacion con IA. - Migracion masiva desde Odoo. - Eliminacion de Odoo como respaldo. ## Arquitectura PocketBase sigue siendo la fuente de datos del MVP. Next.js mantiene modulos separados por dominio y helpers de acceso a datos en `frontend/src/lib/pb`. Nuevas colecciones previstas: - `presupuestos` - `presupuesto_items` - `cuentas` - `pagos` Colecciones existentes a modificar: - `pedidos` - `movimientos` - `clientes`, solo si la implementacion de pagos/presupuestos necesita normalizar algun dato operativo que hoy falta. La conversion `presupuesto -> pedido` debe implementarse como una operacion explicita e idempotente desde frontend/helper, con validacion para no crear dos pedidos desde el mismo presupuesto. ## Numeracion La app debe generar el proximo numero buscando el mayor numero usado en el anio corriente. Ejemplo: - Primer presupuesto de mayo 2026: `2605-0001`. - Ultimo de mayo: `2605-0067`. - Primero de junio: `2606-0068`. - Primero de enero 2027: `2701-0001`. La secuencia anual debe vivir en una coleccion o registro transaccional para evitar duplicados si dos presupuestos se crean casi al mismo tiempo. Si PocketBase no ofrece una operacion atomica comoda para esto desde el frontend, la asignacion debe quedar en hook/backend, no solo en codigo de UI. ## Riesgos - El mayor riesgo es ampliar demasiado el sprint y terminar con muchos modulos a medio cerrar. - La numeracion debe ser robusta desde el principio; corregir numeros duplicados despues es perdida de confianza. - Pagos y caja deben ser idempotentes; duplicar movimientos de dinero es peor que no automatizarlos. - Odoo debe quedar como respaldo temporal hasta que el flujo nuevo tenga uso real varios dias. - La facturacion puede bloquear la salida total de Odoo, pero no bloquea reemplazar el flujo operativo diario. ## Estrategia De Entrega 1. Arreglar bugs actuales que frenan uso diario. 2. Agregar schema minimo de presupuestos, cuentas y pagos. 3. Implementar numeracion segura. 4. Crear UI de presupuestos. 5. Implementar conversion explicita a pedido. 6. Integrar pagos con caja. 7. Redisenar Inicio como tablero operativo. 8. Verificar con datos locales y navegador antes de tocar produccion. ## Criterios De Aceptacion - Crear un presupuesto genera un numero `YYMM-####` correcto. - El numero no cambia al editar el presupuesto. - Aprobar un presupuesto no crea pedido automaticamente. - `Convertir a pedido` crea un solo pedido asociado, con el mismo numero. - Un presupuesto ya convertido no permite crear otro pedido duplicado. - Un pago parcial reduce el saldo visible. - El pago queda asociado a una cuenta. - El pago aparece como ingreso en caja sin duplicarse. - Inicio muestra pendientes de medicion, envio, saldo, presupuestos por convertir y cortes. - La app compila y las pruebas existentes siguen pasando.