Desde el 1 de julio de 2026
Guía de remisión electrónica
Obligatoria. Sin catálogo de productos con unidad de medida válida no se puede emitir, y el catálogo no se improvisa la semana anterior.
ERP · Perú · Sistema interno en desarrollo
Casi todos empiezan por la factura. Nosotros por el maestro del que cuelga la factura: un catálogo de productos con presentaciones, almacenes, lotes y kardex valorizado. Lo demás se construye encima sin rehacer nada.
La idea central
Casi todo el desorden de un inventario nace de tratarlos como tres artículos distintos. Acá son tres presentaciones de uno solo, cada una con su factor de conversión.
Por qué ahora
Un módulo que resuelve una obligación fechada se explica solo; uno que «ordena procesos» hay que evangelizarlo.
Desde el 1 de julio de 2026
Obligatoria. Sin catálogo de productos con unidad de medida válida no se puede emitir, y el catálogo no se improvisa la semana anterior.
Por tramos de ingresos
Formatos 12.1 y 13.1. Exige movimientos valorizados y consistentes: es exactamente lo que produce un kardex bien llevado.
Permanente
Las unidades de medida de los comprobantes salen de ahí. Si el maestro de productos no las usa desde el día uno, todo lo que se emita arrastra el error.
Los módulos
El orden no es de gusto: cada módulo necesita que el anterior exista de verdad.
Maestro de productos con jerarquía de empaques, almacenes, lotes y kardex valorizado. Es la base de todo lo demás.
Módulo baseEntradas que alimentan el kardex y fijan el costo con el que después se vende.
En diseñoSalidas, precios por presentación y los datos que exige el comprobante electrónico.
En diseñoCasos de uso de personal, documentados antes de escribirse.
DocumentadoEl módulo de demostración —Académico → Estudiantes— ejercita entero el andamiaje que después usan los módulos de negocio: filtros, orden, paginación, alta con detalles y edad derivada, alta múltiple en lote, duplicar, eliminar y exportar a CSV.
Cómo está construido
PostgreSQL corre dentro del backend: migra y siembra al arrancar. Instalar el sistema no obliga a administrar un servidor de base de datos aparte.
Detección de cambios explícita en vez de un parche global. En pantallas densas —una tabla con filtros y miles de filas— es la diferencia entre fluido y pegajoso.
El dominio —modelo, validación, normalización— no sabe de framework ni de base de datos. Se prueba solo y sobrevive al cambio de ambos.
Techo duro comprobado en CI, backend incluido. Cuando un archivo se pasa se parte; no se sube el número.
Preguntas
Porque el catálogo de productos es el maestro del que cuelga todo lo demás: sin unidad de medida del Catálogo 03 no se emite una factura ni una guía de remisión electrónicas. Empezar por facturación obliga a improvisar un catálogo pobre que después hay que rehacer.
La caja, el blíster y la pastilla no son tres artículos: son tres presentaciones del mismo producto, cada una con su factor de conversión a la unidad base. El inventario se lleva siempre en unidad base, y comprar por caja o vender por pastilla deja de ser un problema de cuadre.
Nada aparte. La base de datos va embebida en el backend: migra y siembra sola al arrancar, así que no hay que administrar un servidor de base de datos por separado.
No. Es un sistema interno en desarrollo: el armazón está —altas, filtros, orden, paginación, exportación, altas en lote— y los módulos de negocio se van incorporando por fases, empezando por inventario.
Si la respuesta tarda, hablemos. La primera conversación suele terminar en un mapa de presentaciones.
O escribinos a hola@summr.cc · Ver los otros productos