Dossier maestro de producto — Zimple Tecnología

Base única de conocimiento para marketing, comercial, ventas, licitaciones y comunicación

Versión: 2026-09-13 · Fuente: auditoría directa del código, bases de datos y documentación técnica de producción de las cinco aplicaciones. Uso: este documento es la fuente de verdad. De aquí se derivan brochures, pitch decks, propuestas, pliegos de licitación, guiones de demo y piezas publicitarias. Precios, planes y condiciones comerciales vigentes: comercial/PRECIOS_2026-09.md.

ÍNDICE

PARTE I — LA PLATAFORMA

1. Qué es Zimple y cuál es la tesis del producto
2. Arquitectura común y por qué importa comercialmente
3. Multi-tenencia, marca blanca y aislamiento de datos
4. Seguridad y trazabilidad
5. Inteligencia artificial: doctrina de uso
6. Mensajería unificada (WhatsApp/Email) como infraestructura
7. Cifras verificables de la plataforma

PARTE II — LAS CINCO APLICACIONES

8. EJE — Punto de venta y operación de negocios de consumo
9. PILAR — Gestión empresarial, construcción, tesorería y contabilidad
10. ÍTACA — Agencias de viajes, cotización, reservas y portal comercial
11. FARO — Gestión jurídica de despachos y consultorios
12. ZIMPLE GESTIÓN — Plano de control de la plataforma y portal de clientes

PARTE III — MATERIAL COMERCIAL

13. Matriz cruzada de capacidades
14. Diferenciadores defendibles (por qué no es "otro software más")
15. Argumentario por objeción
16. Insumos para licitaciones y pliegos
17. Alcances y condiciones comerciales
18. Glosario para no técnicos

PARTE I — LA PLATAFORMA

1Qué es Zimple y cuál es la tesis del producto

Zimple Tecnología construye y opera software de gestión vertical: sistemas completos, no plantillas, especializados por industria y desplegados como servicio (SaaS) multi-empresa sobre infraestructura propia en Google Cloud.

Hoy hay cuatro productos en producción, cada uno con clientes reales operando:

La tesis en una frase

El software genérico obliga a la empresa a adaptarse al programa. Zimple invierte la relación: cada producto habla el idioma de su industria y se parametriza sin programar — pero por debajo comparte una plataforma común de multi-tenencia, seguridad, mensajería e IA que un desarrollo a la medida jamás alcanzaría en costo ni en tiempo.

Las tres promesas que sostienen todo el discurso comercial

1. Especialización real, no configuración cosmética. El ERP no es un contable genérico con un módulo de obra: su modelo de datos entiende presupuesto → capítulo → partida → APU → recurso, actas de obra, retención de garantía y anticipos amortizables. FARO, el jurídico, entiende etapas procesales, compuertas de avance y material probatorio. El de turismo entiende tarifas de convenio noche a noche por tipo de persona. Eso no se logra configurando Odoo.

2. La empresa se parametriza a sí misma. Catálogos, tipos, estados, reglas, fórmulas, flujos de notificación, plantillas de documento, permisos campo por campo: todo se edita desde la interfaz. El cliente no depende del proveedor para operar distinto el mes que viene.

3. Todo queda registrado y explicado. No hay caja negra: cada movimiento de dinero deja rastro, cada decisión automática dice por qué la tomó, cada usuario tiene bitácora. Es la diferencia entre un sistema que reporta y un sistema auditable.

2Arquitectura común y por qué importa comercialmente

Stack por producto

Infraestructura compartida

• Servidor: Ubuntu en Google Cloud Platform.
• Entrada única: nginx-proxy + acme-companion → HTTPS con certificados Let's Encrypt renovados automáticamente para todos los dominios y subdominios.
• Aislamiento de red: cada aplicación tiene su red interna privada (base de datos inalcanzable desde internet) y solo el contenedor web se publica a la red de borde.
• Persistencia: volúmenes Docker nombrados por dominio (datos, subidas, backups, logs, exportaciones) — sobreviven a cualquier redespliegue.
• Respaldo: copia del código de las cinco aplicaciones a repositorio Git privado + dumps de base de datos.

Traducción comercial de la arquitectura

3Multi-tenencia, marca blanca y aislamiento de datos

Las cuatro aplicaciones que se venden a clientes son multi-empresa desde el modelo de datos, no por convención: cada tabla operativa lleva tenant_id y toda consulta se filtra por él. (Zimple Gestión, la quinta, no es multi-inquilino: es la instancia propia de Zimple desde la que se administran los inquilinos de las otras cuatro. Ver §12.)

Qué significa "tenant"

Un tenant es una empresa cliente. Comparte el programa, nunca los datos. En una misma instancia de POS conviven Arepitas Pa' Mamá, su fábrica y la demo comercial: ninguna ve nada de la otra.

Cómo entra cada empresa

Marca blanca real (white-label)

Cada empresa configura su propia identidad y la aplicación se ve como suya:

• Logo propio (subido desde la interfaz, con versionado para refrescar caché).
• Color primario y secundario de marca.
• Nombre visible distinto del nombre legal.
• PILAR: tabla tenant_branding completa — colores, logo, tipografías, encabezados de tablas y modales.
• FARO: sistema de tokens de diseño (--is-c-accent, superficies, densidad, tipografía) validados en servidor; el despacho cambia su marca y toda la interfaz se re-tiñe sin tocar una línea de código.
• ÍTACA: además del panel administrativo, cada agencia tiene un portal público propio en su dominio.

Criterio de marca aplicado: el login lleva marca Zimple (es un endpoint común a todos los tenants); el branding del cliente aparece después de entrar. En las apps entregadas a cliente final bajo su marca (FARO, portal del ERP) se muestra exclusivamente la marca del cliente.

Módulos conectables por empresa

El ERP tiene modules_enabled por tenant: se venden módulos, no un paquete monolítico. Una constructora activa Presupuestos + Plan de Recaudos; una empresa de servicios activa Servicios + Hitos y no ve nada de obra. La navegación se arma en tiempo real según los módulos habilitados y los permisos del usuario.

Licenciamiento incorporado al producto

Los modelos de tenant incluyen: plan (básico / profesional / enterprise), máximo de usuarios, máximo de proyectos, límite de almacenamiento, ciclo de facturación, fecha de inicio y fin de suscripción, próxima y última facturación, fin de periodo de prueba. El control comercial es parte del sistema, no una hoja de cálculo aparte.

4Seguridad y trazabilidad

Autenticación y sesión

• EJE / ÍTACA / FARO: JWT con expiración configurable, refresco, y cierre por inactividad validado en el servidor (no solo en el navegador).
• FARO: bloqueo de cuenta tras intentos fallidos (failed_login_attempts + locked_until), obligación de cambiar clave en el primer ingreso.
• PILAR: sesión PHP con timeout de inactividad de 1 hora, contraseñas con password_verify (bcrypt).
• Contraseñas siempre con hash bcrypt. Nunca en texto plano, nunca reversibles.

Permisos: cuatro sistemas, una misma filosofía

Ninguna de las cinco aplicaciones usa "roles fijos" como única forma de control.

EJE — 29 módulos × 12 acciones. Módulos: dashboard, pos, orders, delivery, products, supplies, stock, stock_rules, categories, customers, suppliers, users, cash, shifts, payroll, tasks, invoices, expenses, accounts, promotions, reports, metrics, analytics, documents, notifications, settings, audit, tenants, administration. Acciones: ver, crear, editar, eliminar, exportar, importar, aprobar, cancelar, devolver/reembolsar, aplicar descuento, cerrar (caja/turno), enviar (documento al cliente). Roles precargados (super_admin, admin, …) son solo semillas; el permiso efectivo se asigna usuario por usuario.

PILAR — 54 módulos × 5+ acciones + permisos por campo. Además del clásico módulo × acción ($auth->puede('operaciones','ver')), el ERP tiene rol_campos_operacion: control de visibilidad y edición campo por campo dentro de un formulario según el rol. Un almacenista ve la operación pero no el precio; el contador ve el precio pero no puede cambiar el proyecto.

ÍTACA — módulo × recurso por usuario (usuario_permiso), evaluado también en el enrutador del frontend.

FARO — 10 módulos × 33 permisos granulares, asignados por usuario. Decisión de diseño explícita: el rol es cualitativo, no define permisos. El administrador arma la matriz usuario por usuario. Ejemplo del criterio: reuniones.eliminar no entra en la línea base porque borrar una grabación destruye material probatorio — arranca solo en el administrador y se delega uno por uno.

Auditoría

• EJE: tabla audit_logs con acción, entidad, nombre de entidad, descripción, valores anteriores y nuevos en JSON, IP, navegador, estado y mensaje de error.
• FARO: audit_log (actor, acción, entidad, IP, detalle) + attachment_access_log (subida/descarga/borrado/restauración de cada archivo) + activity_events (feed de actividad) + VoiceTranscription como registro inmutable de cada dictado.
• PILAR: payment_audit_log, cron_execution_logs, eventos_log, noe_operacion_historial (timeline por operación), dead_letter_queue y circuit_breaker para integraciones.
• ÍTACA: copiloto_audit (todo lo que propone la IA), import_logs.

Prácticas defensivas verificables

• SQL: ORM (SQLAlchemy) en las tres apps Python → sin inyección posible. Sentencias preparadas en el ERP.
• XSS: DOMPurify en FARO; escapado en las demás.
• Encabezados de seguridad: CSP, HSTS, X-Frame-Options.
• Credenciales de terceros cifradas en reposo con Fernet (correo IMAP/SMTP, API de WhatsApp).
• Salida externa con lista blanca (fail-closed): el modo estricto solo permite enviar mensajes a números y correos autorizados. En demos y pruebas es imposible escribirle por accidente a un cliente real.
• Compuerta de envío: en FARO existe un interruptor global (outbound_mode: manual / automatic). En manual, el sistema no envía nada al exterior: solo avisa dentro de la aplicación.

5Inteligencia artificial: doctrina de uso

Las cinco aplicaciones usan Claude (Anthropic) — mayoritariamente Haiku 4.5 por costo/latencia, y modelos superiores donde se requiere razonamiento. La doctrina es la parte vendible:

El lema

El copiloto analiza y propone. El criterio y la decisión son del profesional.

No es una frase de folleto: está en el producto, en un solo módulo del que beben todas las pantallas (utils/doctrina.js en FARO), y se muestra con un sello allí donde el sistema entrega algo sobre lo que alguien va a actuar —un acta, un borrador, un flujo, una clasificación—, no en un pie de página que nadie lee. En la versión jurídica se enuncia como lo dice el despacho: el criterio es del abogado, y de nadie más.

Las cuatro reglas

1. La IA analiza, propone y ejecuta lo que se le pide. Nunca decide por su cuenta ni fija criterio. Hay tres patrones distintos y conviene no confundirlos, porque un comprador técnico los va a distinguir: - Solo clasifica (EJE): el clasificador de WhatsApp jamás escribe la respuesta al cliente. - Prepara y el humano confirma (PILAR e ÍTACA): las herramientas que modifican datos se llaman literalmente preparar_creacion_proveedor, preparar_actualizacion_operacion, proponer_edicion… Devuelven una propuesta; el cambio ocurre cuando la persona confirma. En ÍTACA, enviar un documento al cliente está marcado como acción irreversible y no sale nunca sin confirmación explícita. - Actúa como las manos del profesional (FARO): el copiloto jurídico sí escribe en la base —crea casos, tareas y clientes, agenda, aplica flujos— pero solo cuando el usuario se lo pide en la conversación, y cada herramienta comprueba los permisos de esa persona (user_has_permission). El copiloto no puede hacer nada que quien pregunta no pudiera hacer a mano, ni alcanzar datos que no pudiera ver.

Lo que en ningún caso ocurre: que el modelo decida por iniciativa propia. Ejemplo real y medido: en la bandeja de mensajes de FARO, cuando el modelo lee un correo como "urgente", la tarea que se crea conserva la prioridad que fijó la persona en la regla y la lectura del modelo queda anotada. Sí puede elevarla el diccionario de palabras clave del despacho —eso lo escribió alguien, es criterio de la casa—; la lectura del modelo, no.

2. Salida estructurada obligatoria. Se fuerza al modelo a responder por herramienta con esquema validado (tool_use). No se parsea texto libre: si el modelo se sale del esquema, reintenta. Esto elimina la clase completa de fallos "la IA respondió cualquier cosa".

3. Determinista primero, IA de respaldo (patrón híbrido). El clasificador de FARO corre ~120 palabras clave jurídicas y solo si la confianza no alcanza llama al modelo. El recomendador de flujos: si el tipo de servicio tiene plantilla por defecto, gana esa — sin gastar un token. Barato, rápido, y no depende de que la IA esté disponible (fail-open).

4. Presupuesto y guardarraíles por empresa. Presupuesto de tokens por tenant en el POS: si se agota, el flujo cae a la ruta manual sin romperse. Palabras prohibidas que bloquean antes de llamar al modelo. Umbral de confianza configurable.

Qué hace la IA hoy, por producto

El argumento de venta de la IA

"No le vendemos un chatbot. Le vendemos un asistente que lee sus datos reales — no internet: cuando le dice 'tiene tres cuentas por pagar vencidas', las buscó en su base de datos hace dos segundos.

Y no puede hacer daño, por tres razones concretas: no ve más de lo que ve usted (cada herramienta pasa por sus permisos); no actúa por su cuenta (o le prepara el cambio para que lo confirme, o lo ejecuta porque usted se lo acaba de pedir); y nunca fija criterio — le señala un término, le propone una tarea, le redacta un borrador, y la decisión sigue siendo suya. Eso último no es una promesa: está escrito en la pantalla, cada vez que el sistema le entrega algo."

6Mensajería unificada (WhatsApp/Email) como infraestructura

Existe un gateway central de mensajería (messaging_gateway, FastAPI) que atiende a todas las aplicaciones.

El principio de diseño

instancia de WhatsApp  ⇄  (aplicación, empresa)     es una BIYECCIÓN

Una instancia = un número de WhatsApp = una empresa. Se fuerza en la base de datos con restricciones únicas. La empresa dueña de un mensaje es una función pura de la instancia: jamás se infiere del contenido del mensaje ni del número que escribe. Cero fuga entre empresas, por construcción.

Qué sí y qué no hace el gateway

• Sí: transporte WhatsApp ↔ aplicación, ruteo, aislamiento, listas blancas fail-closed, auditoría central, idempotencia, administración de instancias (alta, QR, estado).
• No: absolutamente nada de semántica. No sabe qué es un cliente, no clasifica, no guarda conversaciones de negocio. Cada aplicación es soberana de su propia lógica.

Esta separación se tomó como decisión explícita después de desmantelar un CRM central que había mezclado lógica de negocio de dominios distintos. Es un aprendizaje convertido en arquitectura.

Canales soportados

• WhatsApp: Evolution API v2 (instancias propias, pareo por QR, webhooks + polling).
• Correo: IMAP entrante con SSL y carpeta configurable; SMTP saliente por cuenta (se responde desde la misma dirección a la que escribieron).
• Dentro de la aplicación: centro de notificaciones con preferencias por usuario y por tipo de evento.

7Cifras verificables de la plataforma

(medidas directamente sobre producción el 2026-09-04; entre paréntesis, el dato de la edición de julio, para que se vea el ritmo de construcción)

Total de la plataforma: 708 tablas de datos y 1.813 endpoints/vistas en producción, sin contar los 1.148 archivos PHP del ERP.

Volumen real gestionado en FARO, contando solo el despacho en producción y excluyendo el de demostración: 301 casos, 1.042 tareas, 143 clientes y 7.069 documentos en expedientes. (La instancia completa suma 405 casos; la diferencia es el despacho de demostración comercial, con datos sintéticos.)

Una precisión sobre la vigilancia de procesos, porque el dato anterior estaba mal atribuido. Las actuaciones capturadas de la Rama Judicial —217 actuaciones en 5 procesos, con 89 consultas reales a la Rama entre el 2 y el 4 de septiembre— están en el despacho de demostración, no en el de producción. El módulo está probado contra la fuente oficial real, pero el despacho en producción todavía no ha cargado los radicados de sus 301 casos, y sin radicado no hay nada que vigilar. Es una brecha de adopción, no de producto, y se declara así a propósito: la edición anterior la contaba como "en producción" y eso no se sostiene ante un comprador que pregunte. Volumen real en ÍTACA: 242 cotizaciones emitidas.

Cómo leer estas cifras. No son un argumento de venta por sí solas —nadie compra por número de tablas— pero sí son la prueba de dos afirmaciones que sí venden: que esto está construido y en producción, no en diapositivas; y que se sigue construyendo (en seis semanas: +25 tablas y +201 endpoints en ÍTACA, +11 tablas y +71 endpoints en FARO).

PARTE II — LAS CINCO APLICACIONES

8. EJE

Punto de venta y operación integral de negocios de consumo

Dominio: arepitaspama.top · Stack: FastAPI + PostgreSQL 16 + Vue 3 + Celery/Redis Escala: 68 tablas · 292 endpoints · 29 módulos de permisos Clientes en producción (4): Arepitas Pa' Mamá (punto de venta), Arepitas Pa Mamá Fábrica, Arepitas de Mamá 3 y un entorno de demostración comercial.

8.1 Para quién es y qué problema resuelve

Restaurantes, cafeterías, comidas rápidas, minimercados, panaderías y fábricas de alimento.

El problema real de estos negocios no es "facturar". Es que el dueño no sabe, al cerrar el día, si ganó plata. Vende bien, la caja no cuadra, el inventario se va sin explicación, la nómina se paga a mano en un cuaderno, los domicilios se pagan de la caja sin registro, y el WhatsApp del negocio es un caos de pedidos.

EJE ataca eso: la venta, el insumo, la caja, el egreso, la nómina y la conversación con el cliente son el mismo sistema.

8.2 Modelo de datos — las entidades núcleo

8.3 Módulos y funcionalidades

A. Punto de venta y órdenes

Ciclo de vida de la orden, distinto según el tipo de entrega — esto es lógica de negocio real, no un estado genérico:

En sitio:    pendiente → entregado → pagado → completado
Recoge/Llevar: pendiente → preparado → entregado → pagado → completado
Domicilio:   pendiente → preparado → EN CAMINO → entregado → pagado → completado

cancelado es posible desde cualquier estado. completado y cancelado son terminales.

• Cuatro tipos de orden parametrizables: domicilio, llevar, recoge, en sitio (con ícono y orden configurables).
• Pagos mixtos: una orden puede pagarse parte en efectivo, parte en Nequi, parte en tarjeta. Nueve medios base (efectivo, tarjeta, transferencia, Nequi, Daviplata, Llave, crédito, mixto, otro) y la lista es editable por empresa.
• Descuento manual del cajero separado del descuento por promoción. Dos campos distintos, deliberadamente: recalcular promociones no pisa el descuento que el cajero autorizó.
• Complementos configurables (empaques, bolsa, salsa de tomate, salsa rosada, mayonesa, cubiertos, servilletas) con ícono y posición — cada negocio arma su propia lista.
• Reordenamiento por arrastre (campo position) para priorizar la cola de cocina.
• Domicilio con contabilidad propia: el valor del domicilio se cobra al cliente y se paga al repartidor con su propio medio de pago, generando automáticamente un egreso al completar la orden, con trazabilidad al ID del gasto. Nada de "el domicilio salió de la caja y no sé cuánto".
• Aviso informativo de posible duplicado (doble clic) sin bloquear — un cliente sí puede pedir dos veces seguidas.

B. Productos, insumos e inventario con recetas

Este es uno de los diferenciadores técnicos más fuertes del producto.

• Producto simple vs. producto compuesto (combo armado de otros productos con cantidades).
• Receta de insumos por producto (product_supplies): vender una arepa descuenta maíz, queso y empaque automáticamente.
• Reglas de stock parametrizables (stock_rules): la empresa decide, por cada acción del sistema, qué le pasa al inventario.

Además: si la regla afecta componentes (para productos compuestos) y si está activa. → Un restaurante descuenta al confirmar; una fábrica descuenta al despachar. El mismo software, dos lógicas, cero código.

• Stock negativo permitido por insumo (allow_negative) para préstamos y créditos entre puntos.
• Historial completo de ajustes: cantidad antes, cambio (+/–), cantidad después, motivo, costo unitario, tipo y ID de referencia, notas, usuario.
• Margen de ganancia y precio final calculados por producto (descuento en % y en monto).
• Control de fecha de vencimiento con evaluación en zona horaria de Colombia.
• Alertas de stock bajo con notificación por WhatsApp a los números configurados, con plantilla de mensaje editable.

C. Caja registradora y arqueo — el módulo que cuadra el día

Múltiples cajas por negocio, cada una opcionalmente vinculada a una cuenta contable, con caja predeterminada.

Cada turno de caja registra: - Apertura: saldo inicial (con opción de sincronizar desde el saldo de la cuenta), notas, usuario. - Fotografía del stock de insumos al abrir y al cerrar (opening_stock_snapshot / closing_stock_snapshot). - Movimiento: total de ingresos en efectivo, total de egresos en efectivo, número de órdenes. - Cierre: saldo esperado calculado, saldo real contado, diferencia. - Conteo por denominación (denomination_breakdown): cuántos billetes de 50, de 20, cuántas monedas. - Saldos por cuenta al abrir y cerrar (efectivo, Nequi, Daviplata, banco…) — no solo el efectivo. - Estado final calculado por el sistema: cuadrado o descuadrado. - Si quedó descuadrado, es obligatorio escribir el motivo (inconsistency_reason).

Argumento de venta: "Al cerrar, el sistema le dice cuánto debería haber, usted cuenta y escribe cuánto hay. Si no cuadra, el sistema exige que alguien explique por qué — y queda firmado con nombre y hora."

D. Finanzas: cuentas, egresos y movimientos

• Cuentas por tipo con medio de pago asociado, número de cuenta y saldo vivo.
• Libro de movimientos (account_movements) que registra por cada movimiento: tipo, origen, monto, saldo antes y saldo después, fecha, descripción, notas, orden o egreso relacionado, cuenta de contrapartida en transferencias, movimiento espejo, usuario, medio, tipo de razón, si está conciliado, y si fue anulado (con fecha y motivo). → Trazabilidad de nivel contable: nunca se borra un movimiento, se anula con motivo.
• Egresos con origen, tipo, concepto, tercero, medio de pago, estado de pago (pendiente/parcial/pagado), monto pagado y saldo pendiente, cuenta afectada, usuario que registró.
• Transferencias entre cuentas con movimiento espejo enlazado.

E. Nómina por horas — el módulo más profundo del POS

Nueve tablas. Diseñado para la realidad laboral colombiana de un negocio con turnos.

• Tipos de hora configurables (hour_type_configs): nombre, código, tarifa base, multiplicador, hora de inicio y fin, si aplica a días de semana / domingos / festivos, prioridad de resolución, tipo de hora base del que deriva, si es especial, descripción y color. → Ordinaria, extra diurna, extra nocturna, dominical, festiva, recargo nocturno: cada negocio define las suyas con sus tarifas.
• Festivos (holidays): fecha, nombre, si es nacional, si es movible, año.
• Asignación de tipos de hora por empleado con multiplicador y tarifa base personalizados — se puede pactar distinto con una persona sin romper la configuración general.
• Turnos (shifts): entrada y salida marcadas, minutos de descanso, horas trabajadas, desglose de horas por tipo en JSON, horas ordinarias/extra/nocturnas, total del turno, estado, IP de marcación de entrada y de salida.
• Horario laboral por empleado (work_schedules): por día de la semana, si trabaja, minuto de inicio y fin, ventana de descanso.
• Bonificaciones (employee_bonuses) con siete tipos (desempeño, asistencia, ventas, festivo, horas extra, especial, otro) y concepto obligatorio.
• Libro mayor de nómina (payroll_ledger_entries) — el corazón del módulo:

Regla de integridad: las modificaciones se hacen anulando y creando, nunca sobrescribiendo. Los tipos que mueven dinero real generan su movimiento de cuenta asociado. → Se sabe siempre, por persona: cuánto se le debe, cuánto se le adelantó, cuánto se le descontó y por qué.

• Auto-liquidación programada el día de pago (tarea automática a las 23:55 hora Colombia).
• Vistas separadas: "Mi pago" (para el empleado), Configuración de nómina, Pago de nómina (para administración).

F. Promociones

Tipo, alcance, valor, vigencia (desde/hasta), monto mínimo de orden, objetivos específicos (productos o categorías en JSON), número de orden objetivo (la orden número 100 lleva descuento), tipos de orden a los que aplica, color. Se re-evalúan contra el subtotal sin tocar el descuento manual.

G. Analítica y dashboard del negocio

Dashboard con cinco pestañas: Flujo de Caja · Ventas e indicadores · Finanzas · Stock y sistema · Eventos · Fallos y Errores.

Consultas analíticas disponibles: - Órdenes por tipo de entrega, con tendencia. - Tendencias de ingreso. - Mapa de calor semanal (día × hora): a qué hora y qué día realmente se vende. - Estadísticas de clientes: con/sin registro, top clientes, únicos, nuevos. - Comparación de periodos (este mes vs. el anterior, con instantáneas). - Histórico de medios de pago, agregado y diario. - Ventas por hora, ventas diarias, top de productos, indicadores extendidos. - Métricas de inventario, de sistema y salud del servicio. - Flujo de caja y desglose de medios de pago. - Resumen de movimientos de stock.

H. Tareas y calendario

Tareas con estado, prioridad, responsable, rango de fecha y hora, evento de día completo, fecha límite y color. Vista de calendario.

I. Documentos digitales y biblioteca de medios

• Plantillas de documento por empresa (factura, otros) con archivo subido y detección automática de variables.
• Biblioteca de medios con nombre, descripción, palabras clave, producto asociado, tipo, MIME, tamaño y leyenda — para catálogos, WhatsApp y pantallas.

8.4 Parametrización sin programar — inventario completo

8.5 Zona horaria y correctitud operativa

Todo el sistema opera en America/Bogotá de forma explícita: el "hoy" del negocio, el vencimiento de productos, los cortes de nómina y las tareas programadas. Es un detalle que suena menor y que en la práctica es la diferencia entre un cierre de caja correcto y uno que cambia de día a las 7 p.m.

8.6 CRM conversacional de WhatsApp embebido — el diferenciador

Catorce tablas, motor de flujos propio, clasificador de IA y consola de atención. No es una integración: es parte del POS.

Identidad del contacto crm_phone_identities (teléfono global, único) → crm_contacts (por empresa: tipo, etapa, opt-out) → enlace opcional a customers del POS. → El mismo teléfono puede ser contacto de dos empresas distintas sin mezclar nada.

Ficha de negocio automática (crm_contact_facts) Total gastado, número de compras, ticket promedio, primera y última compra, productos favoritos, medio de pago preferido, tipo de orden preferido, última dirección, puntaje de compromiso, riesgo de abandono (bajo/medio/alto), total de mensajes, última interacción. → El sistema construye el perfil comercial de cada cliente sin que nadie lo llene a mano.

Motor de flujos declarativo Pasos soportados: enviar mensaje · lista (menú de WhatsApp) · botones · entrada de texto libre · confirmación sí/no · invocar herramienta (crear la orden en el POS) · bifurcación por condición · terminal. Cada paso guarda datos en el borrador de la conversación y decide la transición. Estado vivo por conversación (crm_conversation_states) con paso actual, borrador en JSON y expiración.

Cuatro plantillas de flujo listas por vertical: restaurante (pedido), cafetería (orden), minimercado (domicilio), comida rápida (retiro). Cada empresa las ajusta (crm_flow_configs con versión y publicación).

NLU con guardarraíles Claude Haiku 4.5, temperatura 0, salida forzada por herramienta con esquema {intent, confidence, entities}. Intenciones definidas por empresa, tono configurable, palabras prohibidas que bloquean antes de llamar al modelo, reglas de negocio, idioma, umbral de confianza y presupuesto de tokens por empresa. Si se agota → sin_clasificar → flujo de respaldo. El modelo nunca redacta la respuesta al cliente.

Escalamiento a humano crm_escalations con motivo, estado, prioridad, respuesta sugerida, asignación a un usuario, resolución y notas. Consola con bandeja, conversación, escalamientos y dashboard. Se puede pausar el bot, retomarlo, resolver y enviar manualmente — con auditoría de cada cambio de control (crm_bot_control_audit: nivel, acción, valor anterior, valor nuevo, quién y por qué).

Analítica de CRM: panorama de KPIs, distribución de intenciones, embudo, top de contactos, top de inferencias, tendencia diaria.

Trabajos automáticos: limpieza de estados expirados cada hora, reintento de envíos fallidos cada 5 minutos.

8.7 Incluido en la oferta 2026

• Facturación electrónica DIAN en los tres planes: documento equivalente POS y factura electrónica a través de proveedor tecnológico autorizado, con cupo mensual de documentos por plan (1.000 · 3.000 · 8.000).
• Venta sin internet: si se cae la conexión, la caja sigue vendiendo y sincroniza al volver; los documentos electrónicos se transmiten dentro del plazo.
• Cobro con QR y link de pago (Nequi, Daviplata, PSE, tarjeta), conciliado contra la cuenta del turno.
• Nómina electrónica desde el plan Negocio, a partir del libro por empleado.
• Cierre del día por WhatsApp y reportería programada (diaria, semanal, mensual) con alertas por meta.
• CRM de WhatsApp con asistente de IA que toma pedidos: incluido en Cadena, adicional en Punto y Negocio. Los flujos por vertical se ajustan por configuración de empresa.

9. PILAR

Gestión empresarial, construcción, tesorería y contabilidad

Dominio: erpzimpleconstrucciones.top (+ pma. administración de base de datos, api. servicio de voz) Stack: PHP 8.2 + MySQL 8.0 + Bootstrap 5.3 + microservicios Python (voz, adaptador contable, IA) Escala: 388 tablas, 1.148 archivos PHP de API y vistas, 54 módulos de permisos.

Es el sistema más grande y profundo de la plataforma. Nació para constructoras y evolucionó a un ERP con motor contable propio, aplicable a ingeniería, servicios e inmobiliaria.

9.1 Para quién es y qué problema resuelve

Constructoras, inmobiliarias, empresas de ingeniería de obra civil, empresas de servicios profesionales.

El problema: en una constructora, el dinero se mueve por veinte caminos y ninguno habla con el otro. Se compra material sin orden, el presupuesto se ejecuta sin que nadie lo compare, se paga sin saber si había que retener, el contador recibe una caja de facturas a fin de mes, la obra avanza y el cobro al cliente no, y la gerencia toma decisiones con información de tres semanas atrás.

La respuesta del ERP: un modelo único donde toda operación económica se captura una vez, en el lenguaje del que la vive, y el sistema deriva sola todas sus consecuencias — cuenta por pagar, afectación de presupuesto, retención, movimiento de inventario, asiento contable y notificación.

9.2 El motor NOE — la propiedad intelectual central

NOE es el modelo de operaciones del ERP. Es lo más defendible del producto y merece explicación completa porque es el argumento técnico que ningún competidor genérico puede replicar rápido.

El problema que resolvió

El modelo anterior (EOHP: Eventos → Operaciones → Hechos → Proyecciones) tenía cuatro catálogos que podían contradecirse entre sí, acoplamiento con el software contable (columnas siigo_* por todo el esquema) y falta de neutralidad. Se reescribió.

Las cuatro dimensiones ortogonales

Cada operación se clasifica en cuatro ejes independientes:

Un catálogo unificado en lugar de cuatro que se contradicen.

Categorías de causa (76 causas activas)

compras · ventas · financiero · tesorería · ajustes · construcción · financiamiento · gastos · inventario · activos_fijos · patrimonio · impuestos · otros

Ejemplos reales del catálogo: compra de bienes, compra de servicios, compra a no obligado a facturar, importación, compra de activo fijo, venta de bienes, venta de servicios, venta de inmueble, acta de obra, liquidación de contrato, retención de garantía, devolución de retención de garantía, anticipo entregado, anticipo recibido, legalización de anticipo, canje CxP/CxC, conciliación bancaria, gasto de caja menor, transferencia interna, préstamo otorgado, nómina devengo, provisión de cesantías/intereses/primas, provisión de garantía, depreciación mensual, mejora de activo fijo, retiro de activo fijo, aporte de capital, distribución de utilidades, pago de IVA a la DIAN, pago de retención en la fuente, pago de ICA, provisión de impuesto de renta, castigo de cartera, castigo de inventario, consumo de inventario en obra…

La capa de intención: verbos humanos

Aquí está la genialidad de usabilidad. El usuario no elige una "causa contable": elige lo que le pasó, en su idioma.

El catálogo de diseño tiene 16 verbos; hoy están activas 10 intenciones de captura primaria (el resto quedó consolidado dentro de otras o redirige a su módulo especializado — decisión de simplificación tomada tras el uso real). Las activas hoy: dejar una nota o pedir un ajuste · necesito comprar o contratar · solicitar anticipo · me pagaron / cobré algo · compré algo · ya gasté o pagué algo · vendí algo · le pagué a un proveedor · registrar anticipo · moví plata entre cuentas propias. El catálogo de intenciones es una tabla configurable: activar o desactivar un verbo es un cambio de dato, no de código.

Bloque A — Lo que ya pasó 1. Compré algo → bienes / servicios / activo fijo / importación / mejora 2. Vendí algo → bienes / servicios / acta de obra / inmueble / activo / comisión 3. Le pagué a un proveedor → exige emparejar con una CxP existente 4. Me pagaron una venta → exige emparejar con una CxC existente 5. Gasté plata → caja menor, almuerzo, parqueadero (sin factura) 6. Recibí dinero → ingreso financiero, dividendo, devolución 7. Entregué un anticipo → no es "le pagué" porque no hay factura previa 8. Recibí un anticipo → no es "me pagaron" 9. Moví plata entre cuentas propias

Bloque B — Lo que necesito hacer 10. Necesito comprar algo → solicitud con flujo de aprobación 11. Necesito plata → solicitud de anticipo o fondos 13. Necesito pagar algo → redirige a programación de pagos 14. Necesito cobrar algo → redirige a programación de cobros

Bloque C — Control y corrección 15. Corregir o anular algo → notas crédito/débito, devoluciones, ajustes 16. Subir soporte pendiente → legalizar con factura o CUFE 17. Conciliar cuentas → redirige a conciliaciones bancarias

Emparejamiento inteligente con corrección de rumbo: si el usuario dice "le pagué a un proveedor" y no existe una cuenta por pagar abierta, el sistema no lo deja crear un pago huérfano: le explica que eso no fue un pago, fue una compra de contado o un anticipo, y le ofrece cambiar de verbo. Esto elimina de raíz la clase de error contable más común en un ERP.

Los siete ejes del modelo de captura

Corrección de diseño registrada (hallazgo al cablear el motor, y es un buen argumento de rigor de ingeniería): el tipo de hecho no cambia por la modalidad de liquidación. Una compra de contado sigue reconociendo el gasto (obligación) y la liquidación se aplica al instante — la CxP nace y muere en el mismo acto. Si el tipo de hecho hubiera cambiado a "movimiento de caja", se habría perdido el gasto. Se reusó el motor en lugar de parchar la matriz.

La matriz determinista de consecuencias

Cada tipo de hecho dispara consecuencias deterministas, definidas por una función pura:

obligación         → CxP + presupuesto + salida contable
derecho de cobro   → CxC + presupuesto + salida contable
pago               → aplicar CxP + egreso de caja + salida contable
cobro              → aplicar CxC + ingreso de caja + salida contable
anticipo entregado → anticipo activo + egreso de caja + salida contable
anticipo recibido  → anticipo pasivo + ingreso de caja + salida contable

Tres garantías que esto compra: 1. Mismo dato de entrada → siempre las mismas consecuencias. 2. Anular un hecho reversa automáticamente TODAS sus consecuencias. 3. Probar el sistema exhaustivamente es viable (sin explosión combinatoria).

La regla de neutralidad contable

El ERP no es un software contable y nunca conocerá conceptos específicos del sistema contable externo.

El "saber" del proveedor vive en una tabla bisagra (noe_accounting_mapping) y en un microservicio adaptador Python independiente. Consecuencia comercial directa:

Cambiar de software contable = escribir un adaptador nuevo y cambiar los mapeos del cliente. CERO cambios al ERP.

Esto es un argumento poderosísimo en licitación: "no lo amarramos a un proveedor contable."

El adaptador contable (microservicio)

FastAPI dockerizado, con modo prueba (MockClient) y modo real: - Trabajador asíncrono con procesamiento por lotes y reintento exponencial. - Lee la bandeja de salida (noe_accounting_outbox), carga mapeos y credenciales por empresa, traduce el payload canónico y envía. - Recibe webhooks, mapea el evento a un enumerado canónico (cufe_assigned, doc_stamped, doc_rejected), identifica la empresa y actualiza el CUFE de vuelta en la operación. - Endpoints de salud, estado, métricas, ejecución manual y consulta por operación. - Bandeja de conflictos (noe_conflictos_sync) y cola de mensajes muertos para lo que no se pudo procesar. - Monitor visual de la sincronización con auto-refresco.

9.3 Módulos del ERP — recorrido completo

La navegación tiene ocho zonas: Gerencia · Contabilidad · RRHH · Tareas · Operaciones · Terceros · Proyectos · Tesorería · Reportes · Configuración.

A. Gerencia — Monitor ejecutivo

Resumen del negocio en tiempo real, con drilldown a cada área para actuar. Declaración de diseño explícita en el código: "NO genera decisiones — agrega y presenta".

B. Operaciones (NOE)

• Captura por objeto: ocho tarjetas de captura según lo que el usuario tiene en la mano.
• Bandeja de pendientes con filtros por grupo de tipos, borradores excluyentes, buscador global y alternador "por recibir".
• Lista de operaciones con filtros y KPIs.
• Detalle de operación con línea de tiempo completa (quién creó, quién aprobó, quién ejecutó) y acciones contextuales según el estado.
• Ítems por operación, retenciones, historial, notas internas, etiquetas.
• Adjuntos multi-factura por operación.
• Hitos y checklist auto-derivado de los requisitos de la causa.
• Reclasificación de operación (corregir la causa sin borrar).
• Solicitante = quien creó, con flujo de aprobación por permisos.
• División de línea por proyecto/presupuesto (una compra que sirve a dos obras).
• Órdenes de compra con plantilla configurable y generación de imagen/PDF para enviar al proveedor.
• Órdenes de compra por voz (microservicio Flask + transcripción).
• Solicitud de cotización y envío por WhatsApp; adjuntar cotización recibida en PDF.
• Recepción de inventario con modos de recepción configurables.

C. Contabilidad y fiscal

• Hechos económicos y detalle de hecho — la capa consolidada.
• Movimientos contables y asientos (noe_asiento, noe_asiento_linea) con vista previa antes de confirmar.
• Cuenta canónica (noe_cuenta_canonica) y mapeo de cuentas; sugerencia de PUC.
• Configuración de impuestos y reglas de impuestos por empresa.
• Motor de retenciones: conceptos, UVT anual, tarifas de ICA por municipio, retención por defecto según causa, explicación de retención (el sistema dice por qué retiene o no retiene, siempre).
• IVA por pagar · Retenciones por pagar · ICA por pagar · Provisión de renta como módulos con su propio flujo de pago a la DIAN.
• Identidad DIAN del tercero con dígito de verificación de NIT, responsabilidades fiscales, DIVIPOLA (municipios) y detector de huecos (qué terceros están incompletos).
• Adaptador contable, espejo, pendientes y conflictos de sincronización.
• Monitor contable y legalización pendiente (qué gastos y anticipos están sin soporte).
• Configuración de periodos fiscales y cierre.
• Estados financieros: vistas de balance general y estado de resultados.

D. Tesorería — el módulo gerencial de pagos

Monitor visual con: - KPI hero: liquidez / compromisos / vencidos. - Calendario de pagos con arrastrar y soltar (mes navegable). - Cola de pagos priorizable + bandeja de solicitudes. - Flujo de caja proyectado en gráfico. - Simulador de tesorería: "si pago esto hoy, cómo queda mi caja". - Prioridad de pagos unificada y configuración de prioridades por empresa.

Reglas de tesorería declarativas y configurables por empresa — un diferenciador real de gobierno corporativo:

Se evalúan al priorizar, reprogramar o pagar. Si alguna dispara "solicitud", la acción no se aplica y se crea una solicitud para que gerencia decida. Si la empresa no configura reglas, el default es "auto siempre" — el monitor se vuelve un tablero de solo lectura. Cero fricción para quien no lo necesita, control total para quien sí.

• Cuentas por pagar v2 y cuentas por cobrar v2 con aging.
• Pago desde la operación (sin salir del contexto).
• Cuenta y medio de pago obligatorios en CxP (integridad de saldo).
• Conciliaciones bancarias con movimientos de banco y ajustes de conciliación.
• Cuentas, cajas, bancos, libro de movimientos con saldo íntegro y bloqueo transaccional (integridad de dinero verificada en auditoría de orientación del 21-jul-2026).
• Obligaciones y cronogramas de obligación (generación automática de CxP recurrentes por cron).
• Programación de cobros y de pagos.
• Alertas de pago y bitácora de auditoría de pagos.

E. Proyectos, presupuestos y APU — el corazón de construcción

Jerarquía completa del presupuesto:

Proyecto → Presupuesto → Fase → Capítulo → Subcapítulo → Partida → Subpartida → APU (Análisis de Precio Unitario) → Recursos

APU (Análisis de Precio Unitario) con 20+ tablas: capítulos, subcapítulos, partidas, subpartidas, ítems, recursos por ítem, materiales, mano de obra, equipo, herramientas, transporte, costos indirectos, catálogos reutilizables (capítulos, ítems, fases, subpartidas), APU guardados con sus recursos, y APU por proyecto. → Esto es un presupuestador de obra de verdad, con la estructura que usa el sector.

• Constructor de partidas y constructor de fórmulas (motor de fórmulas propio).
• Presupuesto directo (modelo simplificado para quien no necesita APU completo).
• Códigos WBS por línea con agrupación y resumen por WBS.
• Vinculación proyecto ↔ presupuesto por tabla de enlace, con un presupuesto activo por proyecto e historial.
• Comprometido vs. ejecutado por línea: al pagar, el sistema actualiza el monto ejecutado de la línea del presupuesto activo.
• Plan de proyecto: fases, hitos, entregables, actividades, cronograma y avance.
• Centros de costo con vinculación a proyectos y reporte cruzado.
• Órdenes de cambio con sus líneas.
• Configuración AIU por proyecto (Administración, Imprevistos, Utilidad — figura contractual colombiana).
• Actas de hito físico.
• Plantillas de presupuesto e historial de versiones.

F. Plan de Recaudos (inmobiliaria) y Recaudos de Obra (ingeniería)

Dos módulos hermanos que ocupan el mismo "espacio comercial" según el nicho de la empresa.

Plan de Recaudos — venta de inmuebles a cuotas: - Planes de pago con cuota inicial y cuotas restantes; unidades; compradores. - Estado de cuenta completo: plan, todas las cuotas con estado, total proyectado / abonado / pendiente, porcentaje de cumplimiento, próxima cuota a vencer, historial de pagos. - Estado de cuenta imprimible con formato profesional para entregar al cliente. - Registro de pagos con método, cuenta, observaciones y pago en especie (valor, nombre y estado del bien). - Integridad de la suma de cuotas, reversión, auditoría de líneas y de planes. - Preferencias de plan, importación masiva y exportación.

Recaudos de Obra — contratos de ingeniería: - Contratos vinculados a proyectos. - Cobros por actas de avance o hitos contractuales. - Anticipo amortizable y retención de garantía. - Actas, cobros, hitos, pagos y recaudos como entidades propias. - CxC ↔ CxP conectadas.

G. Terceros y CRM

• Clientes, proveedores, contratistas, bancos, aseguradoras, entidades fiscales — con perfil fiscal por tipo.
• CRM con oportunidades, interacciones, contactos, contexto de cliente, etapas de venta, vendedores, campañas y participantes, cotizaciones con etiquetas y mapeo a presupuesto.
• Creación de tercero desde el RUT o desde la factura por IA (visión + extracción).
• Importación masiva de terceros con plantilla y análisis de archivo.
• Alias de material por proveedor (el proveedor le dice "cemento gris 50kg", nosotros "cemento tipo I").
• Configuración fiscal de proveedor y de contratista.
• Naturaleza NIT ↔ CC con implicaciones de retención.
• Documentos por tercero y cuentas bancarias por tercero.

Nota de integridad de datos registrada: los terceros no vienen del software contable; viven en las tablas del ERP y nunca se deduplican por nombre (solo por documento). Es una salvaguarda contra corrupción de datos maestros.

H. Recursos Humanos

• Asistencia con marcación, ajustes, revisión, cumplimiento configurable, alertas de incumplimiento, cierre automático por cron (por hora límite, por jornada excedida), reporte diario automático por WhatsApp, resumen por proyecto y exportaciones.
• Nómina con liquidaciones, prestaciones sociales, vacaciones, licencias, adelantos a empleados, horas extra con revisión e historial, compensación de horas.
• Empleados, equipos de trabajo, miembros de equipo.
• Paneles de personal y accidentes laborales + actividades de seguridad (SG-SST).
• Registro de horas y de tiempo por tarea.

I. Tareas y calendario

Tareas con plantillas, categorías, etiquetas, colaboradores, comentarios con reacciones, subtareas, entregables, relaciones entre tareas, worklogs, historial, menciones, recordatorios y registros de ciclo. Eventos de calendario con participantes y tipos de actividad. Edición embebida de tareas.

J. Inventario

• Materiales y herramientas con stock, historial, vistas consolidadas, alertas de stock crítico.
• Materiales alquilados con estado.
• Recepción de compra, consumo de obra, ajuste físico.
• Movimientos valorizados (inventario con costo).
• Importación y exportación de materiales y herramientas.
• Catálogos de unidades de medida, tipos de unidad, tipos de recurso, clases de ítem.

K. Activos fijos

Alta de activo, cronograma de depreciación, depreciación mensual automática, mejora de activo, baja/retiro. Vinculado a las causas NOE correspondientes.

L. Servicios y contratos (para empresas de servicios)

Servicios independientes, servicios de contratistas, hitos de servicio con entregables, pagos por hito integrados a tesorería, avance por hito, cumplimiento de hito.

M. Portal de Clientes — canal de cara al cliente final

Portal separado con acceso propio (slug + documento + clave), 30 secciones habilitables por empresa según nicho. Perfiles: Inmobiliaria/Constructora · Ingeniería de obras · Servicios/Comercial · Personalizado.

Secciones disponibles: Mis proyectos y avance · Estado de cuenta (plan de pagos) · Contratos de obra y cobros · Facturas y cartera · Documentos compartidos · PQRS/Solicitudes · Noticias y novedades (blog con comentarios) · Progreso didáctico de pagos (edificio que se construye por etapas) · Galería de avance de obra (fotos y videos por proyecto) · Bitácora del proyecto (permisos, radicados, equipo, veedurías) · Vitrina comercial (unidades disponibles y otros proyectos) · Camino a la entrega (checklist del comprador) · Simulador de cuotas (abonos, pago tardío, escenarios) · Acta de entrega digital (checklist por espacio y firma) · Mejoras y acabados (catálogo que el cliente solicita) · Programa de referidos · Garantías posventa (reclamos con fotos y visita técnica) · Valorización · Certificados · Recibos · Tarjeta · Invitaciones · Calificaciones · Mi perfil…

→ Argumento de venta muy fuerte para constructoras: el comprador de un apartamento deja de llamar a la oficina. Ve su avance, paga, reclama garantías y refiere amigos desde su celular.

N. Comunicaciones — motor de notificaciones

Vista única con tres pestañas: Monitoreo (KPIs, gráfico, tail en vivo, historial paginado) · Flujos (sub-pestañas por dominio) · Lista blanca.

98 flujos de notificación configurables, agrupados por dominio:

Cada flujo define: plantilla de mensaje con variables, canales, y destinatarios resueltos dinámicamente (usuario creador, asignado, por rol, por permiso — ej. permiso:monitor_pagos.ver).

Más de 80 variables documentadas para las plantillas: usuario, operación (código, descripción, causa, intención, tipo de evento, verbo de acción), tercero, estados, proyecto, centro de costo, URLs directas al recurso, montos formateados, imágenes.

Además: bitácora de vigilancia (comunicaciones_vigilancia_log), bandeja de salida (comunicaciones_outbox) con trabajador agendado y guarda de antigüedad, lista blanca por empresa.

O. Reportes — motor único

ReportEngine: un reporte es una vista guardable, filtrable y descargable, no una consulta nueva por formato. Cada página arma una especificación normalizada (título, columnas con tipo, filas, totales, filtros activos) y el motor la emite en: - HTML (vista previa en pantalla) - CSV (compatible Excel, separador ; para configuración colombiana) - XLSX (Excel real con formato, vía PhpSpreadsheet) - PDF con la marca de la empresa (vía dompdf)

Tipos de columna: texto, dinero, número, fecha, fecha-hora — con formato colombiano ($ 1.234.567, dd/mm/aaaa).

Reportes disponibles: Libro de operaciones · Compras y gastos por proveedor (con ticket promedio) · Gastos por centro de costo (con participación) · Pendientes por ejecutar por centro de costo · CxP con aging (Vencida / 0-30 / 31-60 / 61-90 / +90) · Pagos a proveedores realizados. Incluidos en la oferta 2026: Retenciones e impuestos · Estado de cuenta por tercero · Ejecución presupuestal por proyecto.

P. Copiloto ERP

Loop agéntico sobre Claude con 24 herramientas: capturar_operacion · consultar_cxp · consultar_cxc · consultar_saldos · estado_operacion · buscar_tercero · presupuesto_vs_ejecutado · priorizar_pagos · simular_tesoreria · buscar_kb (base de conocimiento) · resumen_financiero · preparar_envio_documento · preparar_actualizacion_proveedor · preparar_creacion_proveedor · preparar_actualizacion_operacion · preparar_edicion_plantilla · ver_plantilla_documento · capturar_pantalla · anticipos_pendientes · analitica_compras · consultar_inventario · estado_proyecto · salud_tesoreria · crear_tarea.

Las herramientas de escritura preparan el cambio; queda como cambio pendiente de confirmación (noe_copiloto_cambios_pendientes) que un humano aprueba. Conversaciones e historial persistidos. Base de conocimiento propia (noe_kb_articulos) consultable.

Q. Configuración y parametrización

• Configuración general de la empresa.
• Parámetros del sistema (dueño único de la parametrización): niveles de prioridad, rubros, categorías, etiquetas, tipos de unidad, unidades de medida, modos de recepción, medios de pago, estados de venta, roles y permisos con matriz módulo × acción.
• Consecuencias y automatizaciones: la matriz de consecuencias por causa, editable y con vista de validación. Disparan al CONFIRMAR la operación.
• Configuración fiscal: UVT y retenciones.
• Reglas de tesorería.
• Cumplimiento documental configurable (qué documentos exige cada tipo de tercero/operación, con recordatorios y vencimientos).
• Recordatorios de tareas.
• Comunicaciones (avisos, flujos y WhatsApp).
• Portal de clientes (accesos, PQRS, documentos, secciones).
• Videos de capacitación con categorías, comentarios y registro de reproducciones — onboarding dentro del producto.
• Configuración global de plataforma (panel_erp_zimple.php): tenants, branding, módulos y licencias.
• Clasificador: reglas base del clasificador de operaciones, configurables.
• Campos por rol (rol_campos_operacion): visibilidad y edición campo por campo.

9.3.b Obra — del presupuesto al corte, con tres planos que no se mezclan

El módulo de obra es lo que separa a este ERP de un contable genérico vendido a una constructora.

Tres planos de análisis, deliberadamente separados: lo presupuestado, lo comprometido (pedidos y contratos firmados, que ya son plata comprometida aunque no se haya pagado) y lo ejecutado. Mezclarlos es el error clásico que hace que una obra parezca sana hasta que deja de serlo: el gerente ve gasto bajo porque las facturas no han llegado, cuando el compromiso ya se comió el presupuesto.

Corte inmutable. Un corte de obra, una vez cerrado, no se reescribe. Si algo cambia después, se registra en el corte siguiente con su motivo. Es lo que permite responder «¿qué sabíamos en junio?» sin que la respuesta dependa de quién editó qué en agosto.

Formulario 1 pegado desde Excel. El presupuesto de obra —el Formulario 1 de las licitaciones públicas colombianas— se carga pegando directamente desde la hoja de cálculo, que es como llega del cliente y del proponente. Sin plantilla intermedia, sin reescribir cientos de ítems a mano.

Recepción de materiales con aviso consolidado, y gestión de clientes con dígito de verificación y régimen tributario — los datos que después exige la facturación electrónica.

9.3.c Cartera unificada — cuatro orígenes, una sola respuesta

«¿Cuánto nos deben?» tenía cuatro respuestas distintas según a quién se le preguntara, porque la deuda nace en cuatro sitios distintos del sistema. La cartera unificada los consolida en una sola vista con una sola cifra, que es la que se lleva al comité.

9.3.d Conciliación con facturación electrónica (DIAN)

Las facturas electrónicas se cruzan contra lo registrado en el ERP. Detalle que importa y que casi nadie resuelve: la DIAN expresa algunos montos en miles, de modo que 1.502.320 no es un millón y medio sino mil quinientos dos millones. Interpretarlo mal descuadra la conciliación entera; el sistema lo contempla explícitamente.

9.4 Automatización programada (cron)

Cierre automático de asistencia (por hora límite y por jornada excedida) · Reporte diario de asistencia · Generación de CxP por cronograma de obligaciones · Procesamiento de cuotas vencidas · Depreciación mensual · Bandeja de salida de WhatsApp · Recordatorios de tareas y documentos · Alertas de stock · Backups con retención configurable · Bitácora de ejecución de cada cron (cron_execution_logs).

9.5 Demos comerciales listas para vender

Dos entornos completos, sembrados y con fechas relativas que no envejecen (cron dominical las mantiene vigentes):

Ambas idempotentes (run_all.sh, etapas 10-cimientos → 60-planeación) y fail-closed. → Se puede hacer una demo mañana sin preparar nada.

9.6 Estado y alcance

Verificado en auditorías internas: - Integridad del dinero: resuelta (bloqueo transaccional en movimientos de cuenta) — auditoría de orientación 21-jul-2026. - Aislamiento entre empresas: certificado con reportes de tablas sin tenant_id y correcciones aplicadas. - Motor de causas y checklist: auditado 10-jul-2026; las consecuencias disparan al confirmar la operación. - Suite de pruebas del motor NOE: verde (147 pruebas PHP, 37 del adaptador Python, 9 extremo a extremo).

Incluido en la oferta 2026: - Facturación electrónica y documento soporte DIAN en los tres planes, a través de proveedor tecnológico autorizado, con el CUFE de vuelta en la operación; nómina electrónica desde el plan Empresa. - Cobros con link de pago (PSE, tarjeta, Nequi) en el portal del comprador y conciliación bancaria con el extracto. - CRM de la sala de ventas con asistente de IA para compradores por WhatsApp y firma electrónica de promesas y actas de entrega. - Sincronización contable acompañada: el mapeo de cuentas del cliente se deja listo en la puesta en marcha del plan Grupo; con él, el motor sincroniza sin intervención. - Aplicación para el celular y reportería programada con alertas por meta; conexión con Power BI en el plan Grupo.

10. ÍTACA

Agencias de viajes: cotización, reservas, portal comercial y operación

Dominio administrativo: turismo.zimple.uno · Portales de cliente: dominio propio por agencia (ej. amarillo.zimple.uno, checkinmayorista.zimple.top) Stack: FastAPI + PostgreSQL 15 + Vue 3 + PrimeVue · 88 tablas · 563 endpoints Agencias en la instancia (5): Amarillo Tours, Check In Mayorista CYC, Azul Caribe Viajes, Colombia Trips y Cumbre Andina. 242 cotizaciones emitidas.

10.1 Para quién es y qué problema resuelve

Agencias de viajes minoristas, mayoristas y operadores receptivos en Colombia.

El problema: la agencia cotiza en Excel o en WhatsApp. Las tarifas de convenio con hoteles están en un PDF que nadie actualiza. Un asesor cotiza distinto que otro. Cuando se vende, hay que volver a escribir todo en el contrato, en el voucher y en la reserva. Nadie sabe cuánto se le debe al hotel, cuánto al asesor, ni si la reserva dejó margen. Y el cliente final no tiene dónde ver su viaje.

La respuesta: una sola captura, tres salidas. La cotización se convierte en reserva sin re-escribir nada; la reserva genera los documentos (contrato, voucher, estado de cuenta) y las cuentas por pagar a proveedores y asesores; y el cliente lo ve todo en el portal de la agencia.

10.2 Modelo de datos

Catálogo comercial destinos · hoteles · habitaciones · alimentacion · tipos_persona · servicios_convenio + servicios_convenio_valores

Motor de tarifas tarifas_hotel · tarifas_receptivo · tarifas_traslado · tarifas_seguro + tablas de valores (valores_receptivo, valores_traslado, valores_seguro, valores_vuelo) · tasas_cambio · snapshots_tarifas

Reservas (cabecera + hijas por servicio) reservas → reserva_hotel · reserva_vuelo · reserva_traslado · reserva_receptivos · reserva_seguro · reserva_paquete · reserva_servicio_pasajeros · reserva_soportes

Fórmulas y variables formulas_sistema · formula_variables · variables_sistema · variables_sistema_valores

Finanzas estado_cuenta (plan de cuotas del cliente) · cxp_obligaciones · cxp_pagos · cxp_reglas · expensa_regla · expensa_ejecucion

Operación receptiva ordenes_receptivos + ordenes_receptivos_items

Documentos documento_plantilla · documentos_enviados

Portal público portal_products · portal_media · portal_quote_requests

Terceros y accesos clientes · terceros · tercero_proveedores · usuarios · usuario_permiso · agencia

Integraciones y tareas integraciones · integracion_tenant_config · cotizacion_jobs · tasks + comentarios/adjuntos/enlaces · copiloto_audit · home_videos · videos_config

10.3 El motor de tarifas de convenio — diferenciador central

Una tarifa de hotel se define por la combinación exacta de:

hotel × habitación × alimentación × tipo de persona × vigencia (fecha_in → fecha_out)

Con restricción de unicidad en la base de datos: imposible tener dos tarifas contradictorias para la misma combinación y periodo.

Características: - Vigencia por rango de fechas — temporada alta, baja, puentes. - Tipos de persona configurables (adulto, niño con rango de edad, bebé) con requisito de documentación. - Multi-moneda con tasas de cambio. - Campo custom en JSON para extensibilidad sin migración (descuento por grupo, mínimo de noches…). - Borrado suave: cambiar el estado a inactivo, nunca eliminar → se mantiene el historial. - Importación masiva de tarifas.

Cobertura y avisos inteligentes (mejora 2026): - El precio se calcula noche a noche, no por bloque. - Cuando varias tarifas cubren una noche, gana la más específica. - El sistema avisa activamente: rango invertido, noches sin tarifa asignada, huecos de cobertura. → Argumento: "no le va a cotizar mal por una noche que se le quedó sin tarifa. El sistema se lo dice antes."

Tarifas equivalentes para receptivos (tours), traslados y seguros.

10.4 Cotización — tres modos

Motor de fórmulas configurable — el corazón de la flexibilidad

Variables nativas (calculadas por el sistema, no editables — son datos reales de los servicios agregados):

Variables personalizables (las define la agencia): tasa administrativa, gastos administrativos, comisión de asesor, comisión de proveedor, impuestos, descuentos, ajustes, markup de hotel, markup de servicios, markup de vuelo.

Fórmula por defecto:

tarifa_final = tarifa_total_servicios + tasa_administrativa + impuestos − descuentos + ajustes

La fórmula es editable por la agencia. Cada agencia arma su propia estructura de precio, con las variables que quiera y en el orden que quiera.

Automatización de alta comercial: un disparador de PostgreSQL crea automáticamente las 11 variables nativas y la fórmula "Cotización Estándar" al dar de alta una agencia nueva. Cero configuración manual en el onboarding.

Cómo cotiza hoy — el modelo unificado (septiembre 2026)

El rediseño de 2026 parte de un principio: cada origen conserva su naturaleza y convergen solo en la última decisión, la tarifa. No se fuerza a que el convenio se parezca al mayorista ni al revés.

• Entrada única: destino, fechas y pasajeros. Sin contador de habitaciones. Cada pasajero es un tipo definido por la agencia, y la edad solo se pide a los tipos de menores — porque cada agencia corta la niñez en una edad distinta (una a los 12, otra a los 9), y el sistema lee el rango de cada una en vez de imponer el suyo.
• Convenio: el sistema propone las acomodaciones ya valoradas, enumerando combinaciones válidas de habitaciones y quién duerme en cada una — porque un niño en la doble no cuesta lo mismo que en la sencilla. Con tres pasajeros ofrece tres sencillas, sencilla + doble, o triple.
• Online (mayorista): se consulta habitación por habitación, no en bloque. Dos habitaciones son dos consultas y dos líneas: no se pierde precisión —medido: N habitaciones iguales cuesta exactamente ×N— y se gana que cada habitación elija su propio tipo, algo que la consulta conjunta no permite.
• Destinos fuera del tarifario: si el destino no tiene convenio, se cotiza igual contra el mayorista en línea. La agencia no pierde la venta por no tener tarifa negociada.

Este flujo está verificado con pruebas automatizadas de extremo a extremo en navegador.

10.4.b Red B2B entre agencias — el efecto de red

Lo que ninguna hoja de cálculo puede hacer. Una agencia publica en la red los cupos que le sobran —sillas de un charter, habitaciones de un bloqueo, un paquete armado— y las demás agencias de la plataforma los ven y los piden. En producción hay 14 publicaciones, 5 ofertas y 5 pedidos cursados.

Por qué importa comercialmente: cada agencia que entra a ÍTACA hace la plataforma más valiosa para las que ya están. Es la única parte del producto donde el argumento no es «te hace más eficiente» sino «te da acceso a inventario y a demanda que hoy no tienes». Y es difícil de replicar: un software que solo digitaliza a una agencia no puede ofrecer la red sin tener antes las agencias.

10.4.c Cupos y paquetes — inventario propio, no solo intermediación

Bloqueos de cupo con componentes (el paquete se arma con sus partes: aéreo, alojamiento, traslado, receptivo) y reservas contra el cupo, de modo que la agencia sabe en todo momento cuánto le queda por vender de lo que ya compró. Es el paso de agencia intermediaria a operador con inventario en riesgo: otro negocio, y con mejor margen.

10.5 Reservas

Decisión de diseño clave: cualquier venta de servicio es una reserva y vive en la misma pantalla. Solo seguro → reserva + reserva_seguro. Solo traslado → reserva + reserva_traslado. Paquete completo → reserva + varias hijas. No hay "solo se puede reservar si hay hotel".

Cabecera + tablas hijas por tipo de servicio — porque un vuelo y un traslado no tienen los mismos campos, y una reserva puede tener varios traslados o varios tours.

Estados: pendiente → preconfirmada → confirmada → (en_viaje, finalizada) · cancelada

Momentos que disparan lógica: - Al pasar a preconfirmada → se genera el plan de cuotas del cliente (estado_cuenta: cuota inicial + cuotas restantes). - Al pasar a confirmada → se generan automáticamente las cuentas por pagar a proveedores y al asesor.

Instantáneas de tarifas (snapshots_tarifas) — decisión de integridad importante: al crear la reserva se congela la tarifa vigente. Si mañana el hotel sube su tarifa de convenio, la reserva vendida no cambia de precio.

Valores editables y recalculables en columnas reales, no en JSON: subtotal, markup aplicado, total y detalle de tarifas por cada servicio; y subtotal, descuentos, ajustes, tasa administrativa y total en la cabecera. Recálculo por fórmula con bloqueo por estado (una reserva confirmada/finalizada/cancelada no se recalcula sola).

Soportes de reserva (comprobantes adjuntos) y pasajeros por servicio.

10.6 Cuentas por pagar — "¿cuánto le debo a quién?"

Las obligaciones se generan automáticamente al confirmar la reserva (o manualmente con "Generar por reserva").

Reglas CxP configurables (cxp_reglas) — el mecanismo que responde "cuánto pagar":

Variables disponibles en la fórmula CxP: el mismo banco global de la cotización/reserva más costo_base, servicio_subtotal, servicio_total, servicio_markup, servicio_impuestos (vuelo), servicio_noches, servicio_pasajeros, y banderas es_online / es_convenio.

Transparencia deliberada: si no hay regla aplicable, la obligación se crea igual con monto 0 y marca manual_entry_required = true. No se inventa un número: se le dice al usuario que falta definirlo.

Vista de CxP con columnas Total · Pagado · Programado · Pendiente, edición de monto y fecha, y registro de pago (ejecutado o programado).

Expensas (expensa_regla + expensa_ejecucion): gastos recurrentes con regla y ejecución.

10.7 Portal público de la agencia — canal de venta

Cada agencia tiene su portal público en su propio dominio, editable desde la aplicación sin programar.

• Editor del portal con branding, layout avanzado, biblioteca, oferta comercial (destinos y hoteles), multimedia, catálogo de productos, planes, imágenes, videos y vista previa.
• portal_products — catálogo de productos/planes con destacados y orden.
• portal_media — multimedia del portal.
• portal_quote_requests — solicitudes de cotización que entran desde el portal y aterrizan en la operación.
• Página de detalle de producto por slug (/p/:slug).
• CSS por agencia y columna lateral configurables.
• Videos de portada con configuración.

→ Argumento: "su página web deja de ser un folleto. Es la puerta de entrada de cotizaciones a su sistema."

10.8 Documentos con plantillas editables por agencia

Ocho tipos de documento: Cotización · Reserva · Contrato · Detalle del servicio · Voucher · Estado de cuenta · Comprobante de pago recibido · Comprobante de pago realizado.

• Plantillas por agencia, editables en la base de datos (HTML/CSS) — no horneadas en el código.
• Sistema de variables con {{clave}}: datos de la agencia (nombre, NIT, RNT — Registro Nacional de Turismo, dirección, teléfono, correo), cliente, reserva, servicios y familias indexadas (hotel_2_total, pasajero_3_nombre…). El endpoint /documentos/variables expone el catálogo completo al usuario.
• Salida Word y PDF de alta fidelidad.
• Registro de documentos enviados.
• Copiloto de documentos: carga la plantilla actual, propone cambios y valida al renderizar — el usuario confirma.

10.9 Integraciones y automatización de mayoristas

• Scraping de PriceAgencies con navegador automatizado: hoteles y vuelos (misma sesión). Formularios, autocompletado de aeropuertos, datepickers.
• Proveedor Google Flights adicional.
• Sanador de selectores (selector_healer.py) — cuando el sitio del mayorista cambia su HTML, el sistema intenta recuperarse.
• Persistencia y concurrencia de sesión: keepalive, latido programado, verificación real de estado de sesión (corrección registrada: check_login_status daba positivo falso en la página de login y el keepalive tapaba una sesión muerta — resuelto).
• Trabajos de cotización asíncronos (cotizacion_jobs) con seguimiento de progreso.
• Xvfb para navegador sin pantalla.
• Configuración de integraciones por agencia (integracion_tenant_config) con credenciales cifradas.
• CRM/WhatsApp vía Evolution API con remitente propio.

10.10 Analítica — cinco paneles gerenciales

Más: KPIs de tablero, reportes por asesor, métricas, pagos y comisiones. Gráficos SVG nativos (sin dependencias externas). Mi Panel por usuario.

10.11 Módulos completos

Cotizar · Reservas (lista + detalle) · Tarifas · Servicios · Terceros (usuarios, clientes, proveedores) · Integraciones · Documentos y plantillas · Reglas y Fórmulas · Tareas · Finanzas (CxP, Expensas) · Configuración (permisos, portal del cliente, destinos y hoteles, tipos de persona, videos) · Mi Panel · Panel Gerencial · Auditoría del Copiloto · Administración de agencias.

10.12 Parametrización sin programar

10.13 Estado y alcance

Incluido en la oferta 2026: - Portal de ventas con pasarela de pagos en los tres planes: el viajero cotiza, reserva y paga (PSE, tarjeta, Nequi) y el abono entra solo al estado de cuenta. Comisión del 2 % solo sobre lo vendido en línea (portal y Red B2B). - Facturación electrónica DIAN en los tres planes, a través de proveedor tecnológico autorizado. - CRM y asistente de WhatsApp con IA (adicional): embudo por asesor, seguimiento de cotizaciones, campañas y un asistente que responde, cotiza y agenda. - Cotización con mayoristas en línea con verificación de sesión, reintentos y sanador de selectores; los mayoristas nuevos se conectan en la puesta en marcha. - Aplicación para el celular y reportería programada con alertas por meta.

11. FARO

Gestión jurídica de despachos y consultorios

Dominio: is.zimple.uno · Stack: FastAPI + PostgreSQL 16 (pgvector) + Vue 3 77 tablas · 454 endpoints · 10 módulos con 33 permisos granulares Despachos en la instancia: 3 — Integrando Soluciones S.A.S. (Manizales, producción), Grupo GER Antioquia S.A.S. (en implantación) y Lexia Abogados S.A.S. (despacho de demostración comercial, datos 100 % sintéticos).

Volumen real gestionado — solo producción, sin contar la demo: 301 casos · 1.042 tareas · 143 clientes · 7.069 documentos en expedientes, en Integrando Soluciones. (La instancia completa suma 405 casos; la diferencia es el despacho de demostración. Se separan a propósito: un número inflado se cae en la primera pregunta del comprador, y aquí el activo es que las cifras aguanten la verificación.) (Las 217 actuaciones judiciales capturadas de la Rama Judicial están hoy en el despacho de demostración: el de producción todavía no ha cargado los radicados de sus casos. Ver §11.5.)

Marca: el producto se comercializa como FARO —bajada «Gestión jurídica», endoso «UN SISTEMA ZIMPLE»—, con personalización de marca por despacho (un despacho puede operarlo bajo su propio nombre y colores; ver §3).

Es la aplicación más moderna de la plataforma y la mejor vitrina de lo que Zimple puede construir hoy.

11.1 Para quién es y qué problema resuelve

Despachos jurídicos, consultorios jurídicos, firmas de abogados. Áreas: laboral, civil, comercial y seguridad social (parametrizables).

El problema: un despacho vive de plazos. Se pierde un término y se pierde el caso. Pero la información está en la cabeza del abogado, en su WhatsApp, en su correo y en carpetas de Drive. Nadie sabe en qué etapa va cada proceso, quién está sobrecargado, qué se está esperando de quién, ni por qué un caso lleva tres semanas quieto. Y el cliente llama a preguntar porque no tiene otra forma de saber.

La respuesta: el proceso jurídico modelado como pipeline guiado con compuertas, con todo lo que entra (correo, WhatsApp, voz) clasificado automáticamente y aterrizado en el caso correcto, y un copiloto que avisa de lo urgente antes de que sea tarde.

11.2 Modelo de datos

Identidad y seguridad: tenants · users · roles · permissions · role_permissions · user_permissions · audit_log

CRM: clients · client_contacts · client_notes · client_categories · portal_messages

Casos: cases · case_categories · case_groups · case_workflow_states · case_stages · case_stage_tasks · service_types

Tareas: tasks · task_comments · task_checklist_items · task_watchers · task_work_logs · task_ratings · task_priorities

Flujos: workflow_templates · workflow_stages · checklist_items · process_rules · process_rule_executions

Comunicaciones: inbound_accounts · inbound_messages · inbound_attachments · inbound_rules · outbound_log

Calendario: calendar_events · event_types · event_attendees · calendar_saved_views

Notificaciones: notifications · notification_preferences · notification_flows · notification_flow_recipients · notification_watch_log

Documentos: attachments · attachment_access_log · document_folders · library_documents · library_embeddings · document_templates · document_drafts · document_draft_versions

IA y voz: copilot_conversations · copilot_messages · voice_transcriptions

Reuniones: meetings · meeting_participants

Actividad: activity_events · app_settings

11.3 El caso — modelo profundo

Un caso tiene: código único por despacho, título, cliente, línea de práctica, subcategoría del catálogo, estado, prioridad, responsable (o responsable externo cuando lo lleva alguien fuera del equipo), fechas de apertura y cierre, descripción, etiquetas, y las partes del proceso.

Partes del proceso — modelado con precisión jurídica: - demandante y demandado como texto (uno o varios nombres). - client_role: cuál de los dos es nuestro cliente en este caso. → El mismo cliente puede ser demandante en un caso y demandado en otro. El sistema lo entiende. - counterparty_client_id: la contraparte como entidad real, para auto-relacionar casos que comparten contraparte.

Estados:

abierto → en_tramite ("En curso") → en_espera ↔ suspendido
                                  ↓
              cerrado_favorable | cerrado_desfavorable | archivado

Tipo de servicio × línea de práctica = línea de servicio. Tipos: Representación · Asesoría · Consultoría · Auditoría · Capacitación · Conciliación. Cada tipo puede tener su plantilla de flujo por defecto.

Grupos de casos / litigios masivos (case_groups) — capacidad diferencial: - masivo: lote homogéneo con la misma contraparte (ej. cinco demandas laborales de empleados distintos contra el mismo empleador). - cartera: lote de un mismo cliente contra N demandados distintos (el espejo). - relacionado: casos vinculados sueltos. Con vista consolidada y operaciones en lote: aplicar flujo, generar documentos, mover de etapa sobre todos los casos del grupo. → Argumento: "un litigio masivo de 40 demandas se gestiona como una sola cosa, sin dejar de ser 40 expedientes."

Política de preservación legal: borrar un caso con tareas se rechaza (ondelete=RESTRICT). La política es cerrar o archivar, nunca eliminar.

11.3.b Archivar — dos ejes que la mayoría de sistemas mezcla

El hallazgo de producto: casi todo software de gestión mete "archivado" dentro de los estados de cierre. Eso obliga a mentir sobre el desenlace para quitar algo de la vista. Aquí son dos preguntas independientes, con dos campos distintos:

Una sola palabra para todo: ARCHIVAR — clientes, casos, tareas y grupos. Archivar no borra, no declara desenlace y siempre se deshace. Las listas excluyen el baúl por defecto (si hubiera que acordarse de excluirlo en cada consulta, alguien se olvidaría y el baúl dejaría de servir) y el filtro tiene tres valores explícitos: lo activo · solo el baúl · todo.

Encaja con la política de preservación: nunca se borra un expediente; sale de la vista, no de la historia.

11.4 El pipeline guiado — el diferenciador central

Cómo se instancia

WorkflowTemplate → WorkflowStage → ChecklistItem   (la plantilla maestra)
        ↓ aplicar (clonado inmutable)
CaseWorkflowState → CaseStage → CaseStageTask → Task (materializada, viva)

Editar la plantilla maestra NO modifica los casos ya iniciados. El proceso de un caso queda congelado al aplicarse — como debe ser cuando lo que está en juego es un término procesal.

Las dos barras del detalle del caso

1. Etapas del caso: pending → active → completed. Una sola activa a la vez: la primera no completada.
2. Tareas con compuerta de la etapa actual.

La compuerta de avance

Una etapa no se puede completar hasta cerrar sus tareas marcadas como obligatorias (Task.blocks_stage). El endpoint devuelve 409 Conflict si quedan pendientes. No es un aviso: es un bloqueo.

Y el reverso: reabrir una tarea obligatoria de una etapa ya cerrada hace retroceder la etapa a activa. El proceso no puede mentir.

Avance ponderado y honesto

avance = Σ(peso de tareas COMPLETADAS) / Σ(peso de tareas NO canceladas, ámbito = caso)

Tres decisiones de honestidad métrica: - Solo las tareas de ámbito caso ligadas a etapas cuentan. Las internas y personales no contaminan el porcentaje. - Las canceladas se excluyen del numerador y del denominador: no cuentan como hechas ni penalizan. - Peso 1-5 por tarea: quien delega sube el peso de lo importante, para que el porcentaje signifique algo. "Radicar la demanda" no pesa lo mismo que "llamar al cliente".

11.5 Vigilancia de procesos — dejar de rastrear portales

El diferenciador que ningún competidor local tiene resuelto. Un despacho con 500 procesos no tiene un problema de consultar: tiene un problema de rastrear. Consultar un proceso en la Rama Judicial toma 30 segundos; averiguar cuáles de los 500 se movieron ayer toma la mañana entera, todos los días, y lo hace la persona más cara del despacho.

Consultas externas — 16 fuentes oficiales colombianas. Rama Judicial (procesos y actuaciones), RUES, SECOP, Supersalud, Superintendencia de Sociedades, Superfinanciera, SIC y demás registros públicos, integrados dentro de la aplicación: el abogado no sale a diez portales con diez formularios distintos, escribe una vez y recibe la respuesta en la ficha del caso.

Centro de Vigilancia — el barrido de la cartera completa. Recorre todos los procesos vigilados y reporta cuáles registraron actuación nueva. Probado contra la Rama Judicial real: 89 consultas entre el 2 y el 4 de septiembre, 2.201 filas recuperadas y 217 actuaciones conservadas en 5 procesos. Honestidad necesaria: esa actividad está hoy en el despacho de demostración. El despacho en producción aún no ha cargado los radicados de sus casos, y sin radicado no hay proceso que vigilar. El módulo está probado contra la fuente oficial; la adopción es el paso siguiente.

Una precisión de vocabulario que un abogado va a notar. Lo que se vigila son actuaciones —las anotaciones del expediente—, no "estados": en el foro colombiano los estados son otra cosa, la lista diaria por la que se notifican los autos (notificación por estado del Código General del Proceso, electrónicos desde la Ley 2213 de 2022). Y el nombre comercial es vigilancia de procesos, no "vigilancia judicial" a secas, porque la vigilancia judicial administrativa es una figura distinta: la queja por mora ante el Consejo Seccional de la Judicatura. Hablar con precisión aquí es parte de la credibilidad ante el comprador.

Una decisión de arquitectura que es, además, un argumento comercial. Los términos de uso de la Rama Judicial prohíben expresamente la consulta automatizada mediante robots. Un cron de madrugada sería exactamente eso. Por eso el bucle vive en el navegador del usuario: el backend procesa un lote acotado y devuelve el siguiente desplazamiento, y es la pantalla la que encadena las llamadas mientras el abogado ve el avance. Hay una persona detrás de cada consulta, que es justo lo que la fuente exige. Se construyó más lento a propósito para que el despacho no quede expuesto — y eso es defendible frente a un cliente institucional que pregunta si esto lo puede meter en problemas.

Acta de vigilancia — la capa de acción, de principio a fin. Detectar el movimiento no basta: lo que el despacho necesita es decidir qué hacer con él. El acta recorre el proceso completo — descarga los documentos de cada actuación y los adjunta al expediente, los lee (incluidos los escaneados, con OCR), y redacta un análisis estructurado: novedades, términos con su fecha límite, actuaciones relevantes y las tareas y vencimientos que propone crear.

Y aquí está la frontera, que es el argumento. El acta es una nota editable, no un veredicto: nada existe en el caso hasta que una persona marca qué crear y confirma. Los términos que publica el propio juzgado (con su fecha de inicio y de finalización) van primero y marcados como tales, separados de lo que interpretó el modelo — mezclarlos sin decirlo convertiría un hecho procesal y una lectura en la misma cosa, que es lo peor que podría hacer esta pantalla. La responsabilidad de un término jurídico no se delega en un modelo.

Historial de actuaciones. Cada proceso guarda su línea de tiempo completa, no solo el último estado. Importa porque el conteo de actuaciones puede bajar cuando el juzgado corrige un registro: comparar números no ve esa corrección, comparar historiales sí.

11.6 Tipificación de tareas — ejes ortogonales, no un enum plano

Insight de producto explícito: "En revisión" es un motivo de espera, no un estado. Esa distinción es la que permite medir productividad de verdad: si el caso lleva 20 días quieto esperando al juzgado, eso no es culpa del abogado, y el KPI lo refleja.

Colaboración por tarea: comentarios con hilo (reply_to_id) y menciones @usuario · checklist operativo con progreso automático · observadores con preferencias (notificar en comentario / cambio de estado / vencimiento) · registros de tiempo (inicio, fin, minutos, facturable, tarifa) · calificaciones 1-5 con calidad y puntualidad por evaluador · subtareas en árbol ilimitado.

Corrección de diseño registrada (24-jul-2026): las tareas futuras saturaban la vista. Ahora son accionables por defecto y la fecha se asigna al activar la etapa, no al crear el flujo.

11.7 Flujos de trabajo con asistencia de IA

• Plantillas por línea de práctica, con etapas y semillas de tarea (texto, días de desplazamiento del plazo, rol asignado, si es obligatoria, prioridad, peso).
• auto_apply: al crear un caso de esa línea, la plantilla se aplica sola (una activa por línea).
• Aplicación unificada: los dos caminos (automático y manual) usan el mismo núcleo, idempotente. Endpoint de backfill para reconstruir el pipeline de casos antiguos.

Tres niveles de asistencia, en orden de costo: 1. Determinista: si el tipo de servicio tiene plantilla por defecto → esa gana, sin IA. 2. Recomendador: si hay dos o más candidatas de la línea → Claude las rankea con puntaje y razón explicada. 3. Generador: Claude genera un flujo a medida (etapas + tareas con peso) para el contexto de ese caso, marcado ai_generated con autor.

El usuario siempre confirma. La IA nunca aplica un flujo sola.

Biblioteca de flujos con filtros: míos / de todos / solo IA, con autor visible.

Reglas de proceso declarativas (process_rules): - Disparadores: entrada a etapa · etapa completada · tarea completada · tiempo transcurrido · plazo próximo · manual. - Acciones: notificar · crear tarea · enviar mensaje · cambiar prioridad · marcar etapa hecha · disparar webhook. - Con condiciones en JSON y auditoría de cada disparo.

11.8 CRM y hoja de vida del cliente

Cliente único por documento, con el número normalizado (sin puntos, espacios ni guiones): 1.053.834.626 y 1053834626 no crean dos clientes. Detalle pequeño, consecuencia grande.

Tipos: natural (menor / adulto / extranjero) · jurídica (sin ánimo de lucro / SAS / cooperativa).

Hoja de vida — 21 campos contextuales que son exactamente los que un caso laboral o de seguridad social necesita: estado civil, nivel educativo, empleador y su NIT, cargo, fecha de inicio del empleo, ingreso mensual, tipo de contrato, EPS, AFP, ARL, cónyuge, número de hijos, dependientes, contacto de emergencia (nombre, teléfono, relación), estrato socioeconómico, grupos vulnerables, notas de perfil. → No es un CRM genérico con campos extra: es la ficha que el abogado laboral necesita para redactar la demanda.

Captación y referidos: canal de captación, quién refirió (otro cliente / un empleado / una persona externa), nombre del referidor, detalle de la captación. → Se puede medir de dónde viene el negocio.

Contactos secundarios con relación tipificada: familiar · empleador · contraparte · abogado contrario · testigo · perito · autoridad · otro.

Bitácora de interacciones por cliente, editable con registro de quién editó.

Expediente unificado: vista cronológica completa del caso y del cliente cruzando todos sus casos, incluyendo los eventos de auditoría — responde "¿quién cambió mi caso?" en la misma línea de tiempo.

11.9 Comunicaciones unificadas

Cuentas entrantes: correo (IMAP con SSL, carpeta y búsqueda configurables, SMTP por cuenta para responder desde la misma dirección) y WhatsApp (Evolution API v2, webhook + polling, pareo por QR). Credenciales cifradas con Fernet.

Pipeline automático:

Correo/WhatsApp entrante
  → daemon de polling → dispatcher → clasificador
  → busca cliente por correo/teléfono → lo enlaza
  → busca caso activo del cliente → lo enlaza
  → evalúa reglas: crear tarea (asignada, con plazo) | etiquetar | notificar
  → mensaje en bandeja
  → el usuario responde desde la misma pantalla → queda en bitácora de salida

Clasificador híbrido: ~120 palabras clave jurídicas por línea; si la confianza no alcanza, Claude. Salida: línea de práctica + confianza + etiquetas sugeridas.

Bitácora de salida (outbound_log) con canal, destino y estado (enviado / bloqueado / error).

11.10 Notificaciones — un bus de eventos con 47 avisos y cuatro niveles

El diferenciador aquí no es notificar: es NO notificar. Casi todo software de gestión avisa de todo y termina siendo ruido que nadie lee. El diagnóstico medido sobre el despacho real fue exactamente ese: 6.637 avisos acumulados y 6.166 sin leer — el 93 %. El mayor emisor era "documento subido", con 3.077 avisos y 99 % sin abrir. La causa, también medida: el 88 % de los documentos de un caso los sube su propio responsable. Eran abogados informándose a sí mismos.

La regla que lo resolvió: a nadie se le avisa de lo que acaba de hacer. Con las excepciones explícitas —el recordatorio que uno mismo se puso debe sonar— y aplicada en un solo punto del código, no repartida por veinte archivos.

Un catálogo único de 47 eventos, con el nivel como decisión de producto y no de programación:

Resumen diario a las 18:00 (hora de Bogotá), con ventana corte a corte y no día natural —si fuera día natural, lo ocurrido entre las 18:00 y medianoche no entraría en ningún resumen—, personal para cada quien y no se envía si no hay nada: "tres tareas atrasadas de la semana pasada" es un estado permanente, no una novedad.

Vigilantes del propio sistema. Además de los eventos del negocio, la plataforma se vigila a sí misma y avisa a la dirección: WhatsApp desvinculado, crédito de video agotándose, licencia por vencer, actas de reunión que se quedaron colgadas. El estado del vigilante vive en base de datos y no en memoria: si viviera en memoria, un despliegue lo reiniciaría a "no sé" y —con la regla de avisar solo en el cambio— no avisaría nunca de una caída en curso.

Destinatarios estáticos (usuario, rol, todos, teléfonos) y dinámicos (el actor, el asignado, el creador, los colaboradores, los observadores) · plantillas con variables · anti-duplicados con clave de deduplicación · 60 flujos configurables desde la interfaz, sin tocar código.

Compuerta global de salida: en manual → solo notificación interna, nada sale al exterior. En automatic → WhatsApp también. Es la garantía de que un despacho puede probar el sistema entero sin que le salga un mensaje a un cliente real.

11.11 Calendario

Eventos con tipos configurables (audiencia · juicio · reunión · revisión · recordatorio) con color, ícono y duración por defecto. Vinculación a caso, cliente y tarea. Asistentes internos (usuarios) y externos (nombre/correo/teléfono libre) con rol tipificado: juez · contraparte · abogado contrario · testigo · perito · otro. Estados: agendado · realizado · cancelado · aplazado. Recordatorios automáticos con minutos de antelación configurables. Vistas guardadas por usuario.

11.12 Documentos, expediente y biblioteca

• Adjuntos polimórficos (cliente / caso / tarea / comentario / nota) con SHA-256 para integridad, borrado suave y bitácora de todo acceso. Límite configurable (200 MB por defecto).
• Carpetas y subcarpetas de documentos con movimiento de ítems.
• Selección masiva con operaciones en lote: descargar ZIP, eliminar, mover, publicar al portal.
• Biblioteca de precedentes: documento reutilizable que referencia el adjunto original (no duplica el archivo).
• Embeddings de biblioteca (library_embeddings, PostgreSQL con pgvector) para búsqueda semántica.
• Marcos de documento (document_templates): plantillas con {{variables}} en HTML o Markdown, propias del despacho.
• Borradores con versionado (document_drafts + document_draft_versions).

11.13 Copiloto jurídico — 29 herramientas sobre los datos del despacho

Panel lateral con identidad visual propia (balanza + chispa), lanzador flotante y atajo Alt+J. No es un chat sobre documentos: es un agente que razona en varios pasos (bucle de hasta 10) sobre los datos reales del despacho.

Las 29 herramientas, por lo que hacen con los datos:

14 CONSULTAN — buscar_casos · detalle_caso · contexto_caso (contexto rico para redactar: contacto, etapa, pendientes, últimos hechos) · buscar_tareas (respetando la privacidad de las tareas personales de otros) · casos_en_riesgo · desempeno · buscar_clientes · buscar_grupos · detalle_grupo · buscar_biblioteca y buscar_semantico (RAG sobre la biblioteca de precedentes, citando la fuente) · leer_documento_biblioteca · listar_adjuntos_caso · leer_adjunto.

12 ESCRIBEN, con los permisos de quien pregunta — crear_caso · actualizar_caso · crear_cliente · actualizar_cliente · crear_tarea · actualizar_tarea · completar_tarea · agregar_nota_caso · crear_grupo · vincular_caso_a_grupo · aplicar_flujo · agendar_evento.

3 PRODUCEN BORRADORES — componer_documento · abrir_documento_para_editar · revisar_documento.

La frase que hay que decir bien. El copiloto sí modifica datos: crea un caso, agenda una audiencia, asigna una tarea. Lo que no hace es actuar por iniciativa propia. Tres controles, verificables en el código:

1. Permisos, herramienta por herramienta. Cada función que escribe empieza comprobando el permiso de quien está preguntando (user_has_permission(db, current, "casos.crear"), "tareas.completar", "crm.editar"…). El copiloto no puede hacer nada que esa persona no pudiera hacer a mano, ni ver un caso que no le corresponde. No tiene identidad propia: son las manos del abogado, no un usuario más con llaves maestras.
2. Solo a petición explícita, dentro de la conversación. No hay ningún proceso de fondo en el que el copiloto escriba por su cuenta.
3. Todo queda con rastro. Lo que el copiloto escribe deja auditoría igual que si lo hubiera hecho a mano la persona, con su nombre.

Lectura de documentos — el copiloto ve lo que hay en el expediente, no solo lo que está en texto. leer_adjunto abre Word, PDF, Excel (.xlsx/.xlsm), CSV, imágenes y PDF escaneados, estos últimos con OCR en español. Importa porque en un despacho colombiano una parte grande de lo que llega del juzgado son documentos fotografiados o escaneados: en la medición sobre el expediente real, el 18 % de los PDF no tenía una sola letra extraíble. Antes el copiloto respondía "el documento no contiene texto" —una cortesía sobre un documento que lo dice todo, solo que en píxeles—; ahora lo lee. El resultado se guarda en caché por documento: la primera lectura de una hoja de cálculo real tardó 2,29 s y las siguientes 0,01 s (224 veces más rápido).

Documentos jurídicos (HTML→PDF). Dos vías: - Tipos base: derecho de petición · oficio · solicitud · constancia. El cuerpo lo produce Claude con salida estructurada, anclado en datos reales; se envuelve en plantilla legal con membrete, fecha en español, REF y firma. - Marcos de la biblioteca: usa las plantillas del despacho; la IA rellena solo sus variables y el sistema rellena las de contexto (firma, fecha, código del caso, cliente, abogado). - Branding configurable y guardar en vez de solo descargar: al expediente, o a la biblioteca como precedente reutilizable — que queda indexado para el RAG. Círculo cerrado: generar → guardar → conocimiento reutilizable. Hoy hay 53 borradores y 17 documentos en la biblioteca. - Edición de un documento ya subido: listar_adjuntos_caso → abrir_documento_para_editar → revisar_documento. Hoy solo Word (.docx); si es PDF lo dice en lugar de intentarlo. Nunca aprueba ni envía: el resultado queda para que un humano lo revise.

Vigilante proactivo. Avisa por su cuenta, con detección determinista (no alucina): casos en riesgo, esperas internas estancadas y audiencias en las próximas 72 horas. Cada aviso trae severidad, título, detalle, acción y enlace. Un briefing en lenguaje natural resume lo urgente, con respaldo determinista si la IA está apagada. En la interfaz: contador rojo si hay urgentes y sección "Para tu atención hoy".

Persistencia y colaboración. Conversaciones guardadas por usuario con historial; solo el dueño ve sus chats. Se puede mencionar a un compañero, y las respuestas tienen acciones Copiar · Tarea · Compartir.

El sello, en la propia pantalla. El panel muestra el lema del despacho —el copiloto analiza y propone; el criterio y la decisión son del abogado— y lo mismo hacen el acta de vigilancia, el acta de reunión, los borradores, los flujos generados y la clasificación de la bandeja, cada uno diciendo qué conviene revisar ahí. Es la parte que se ve de una regla que además se cumple en el código.

11.14 Dictado y comandos por voz

Web Speech API en español de Colombia → Claude extrae intención y entidades → se ejecuta. Intenciones: crear tarea · comentar tarea · completar tarea · actualizar tarea · comentar caso · nota de cliente · resumir. Cada dictado queda como registro inmutable (voice_transcriptions: transcripción + intención + payload + si se aplicó + resultado) — trazabilidad jurídica. Además: notas de audio con transcripción y análisis multimodal.

11.15 Reuniones online con acta automática

Videollamadas integradas para tres contextos: staff (menú Reuniones), cliente (portal) e invitados externos por link firmado con vigencia configurable. 87 reuniones y 33 grabaciones en la instancia; 29 con acta generada.

Antes de entrar — la sala previa. Verse y oírse antes de que le vean: vista propia, barra de volumen del micrófono que confirma que de verdad le oye, elección de cámara y micrófono (los portátiles suelen tener dos), y la decisión de entrar con cámara o micrófono apagados. Las preferencias se recuerdan por equipo. En un despacho esto no es comodidad: es que un abogado no entre a una audiencia enseñando su cocina, ni descubra a mitad de frase que tenía el micrófono abierto.

Fondos y desenfoque, aplicados ya en la sala previa: lo que usted ve antes de entrar es exactamente lo que van a ver los demás.

Durante la reunión. Compartir pantalla a 1080p con la señal marcada como texto —para que el códec conserve la letra pequeña de un documento en lugar de suavizarla—, y el mosaico de asistentes en una columna lateral, nunca debajo: puesto abajo, los recuadros de las personas tapan justo la parte del documento que se está comentando. Control de asistentes, silenciar, pantalla completa, aforo, reentrada y evento de calendario vinculado, con asistencia registrada por webhooks.

Grabación y acta. Grabación a almacenamiento propio en Google Cloud Storage (no en el proveedor de video) y post-proceso probado extremo a extremo: descarga → audio 16 kHz mono segmentado en 15 minutos → transcripción (Whisper) → acta ejecutiva (Claude) → ambos quedan como documentos del caso, con portal_visible=false por defecto. Pipeline idempotente, porque los webhooks pueden llegar duplicados.

Neutralidad de proveedor: el backend habla con cualquier LiveKit; cambiar de proveedor son tres variables de entorno. Hoy corre sobre LiveKit Cloud con self-host como respaldo.

Una lección incorporada al producto. Tres grabaciones reales se perdieron sin audio porque la plantilla de composición solo montaba las pistas de vídeo. Se corrigió y, sobre todo, se añadió un vigilante del servicio de video que avisa a la dirección cuando el crédito se acerca al límite o el servicio no responde — antes de que alguien se entere grabando una audiencia. El límite que de verdad ata no era el que se miraba: son los minutos de transcodificación, no los minutos de participante.

11.16 Portal del cliente — el despacho deja de ser una caja negra

Identidad separada del staff. Un cliente nunca es un usuario del sistema: login propio validado contra los campos del cliente, token de tipo portal, obligación de cambiar la clave en el primer ingreso, registro del último acceso y recuperación de contraseña por autoservicio (el despacho no gasta tiempo en reponer claves).

25 endpoints propios. Lo que el cliente puede hacer, agrupado por para qué sirve:

Estado de adopción, dicho con precisión: conversación, solicitudes y encuestas ya tienen uso real en producción (9 mensajes, 3 solicitudes, 7 encuestas respondidas); las aprobaciones están construidas y todavía sin usar. Se declara porque un comprador que pida una demostración va a ver esa diferencia.

Lo que el cliente NO ve, por diseño: las actas y transcripciones de reuniones nacen con portal_visible=false; el despacho decide qué publica. Las notas internas, las tareas del equipo y la bitácora nunca salen al portal.

11.17 Indicadores y analítica

Índice de desempeño 0-100 explicable por persona y por equipo:

cumplimiento 40 + puntualidad/SLA 30 + calidad 20 − retrabajo 10

• Honesto: sin producción medible en la ventana → "s/d". No se infla con valores neutros por defecto.
• El retrabajo se mide con las reaperturas reales de tareas.
• Las horas con los registros de tiempo. La calidad con las calificaciones.

Analítica de pipeline: distribución de casos por etapa · etapas más lentas vs. duración esperada · casos en riesgo (obligatorias vencidas o etapa estancada) · "en espera, ¿de quién?" agrupado por motivo.

Vistas: Resumen · Equipo · Desempeño · Cartera · Pipeline · Supervisión · Trazabilidad. Más: tablero del día, feed de actividad, mapa de calor, búsqueda global unificada (casos + tareas + clientes, Ctrl+K).

Insight de producto registrado: el tablero estaba contando la muestra paginada en lugar de la cartera completa. Se corrigió calculando los KPIs en el servidor, no en el frontend. Es un ejemplo del rigor con que se tratan las cifras que ve el cliente.

11.18 Catálogos parametrizables

Etiquetas (con alcance) · categorías de cliente · subcategorías de caso por línea (laboral: despido, acoso, liquidación…) · tipos de servicio con modelo de facturación y flujo por defecto · prioridades con SLA en horas · tipos de evento de calendario.

11.19 Sistema de diseño v4

Lenguaje visual unificado y parametrizable por despacho, normativo para toda vista nueva: - El contenido manda; un solo acento (el color del despacho) tiñe enlaces, foco y botón principal. - Jerarquía por tipografía, no por cajas de color. - Nada de MAYÚSCULAS en el contenido. - Responsivo obligatorio a <560px, ~768px y ≥1280px. - Prohibido escribir un color literal en una vista: siempre tokens (--is-c-accent, superficies, texto, estado, forma, densidad, tipografía). Escribir un hex rompería el theming por despacho. - Kit de componentes: PageHead, Panel, Stat, StatRow, Toolbar, DataTable, SearchInput, QuickFilters, Tag, Avatar. Tema claro y oscuro.

11.20 Estado y alcance

Cerrado y verificado: multi-tenencia completa · permisos granulares · pipeline con compuerta · copiloto con 29 herramientas y lectura de todo tipo de documento (incluido OCR) · bus de eventos con catálogo único de 47 avisos · reuniones con sala previa, fondos y acta automática extremo a extremo · portal del cliente · archivar como baúl único · carpetas y selección masiva · grupos de casos · vigilancia de procesos sobre 16 fuentes oficiales.

Incluido en la oferta 2026: - Honorarios, cuentas de cobro y facturación electrónica DIAN en los tres planes, con cobro por link de pago (PSE, tarjeta, Nequi) y cartera por cliente; rentabilidad por caso y por cliente en el plan Firma. - Asistente de WhatsApp con IA que responde al cliente «¿en qué va lo mío?» con la última actuación (planes Despacho y Firma). - Correo y WhatsApp para avisos, documentos y campañas, con cupos mensuales por plan. - Firma electrónica con constancia para poderes, contratos y aprobaciones del portal. - Copiloto que lee todo tipo de documento (Word, Excel, CSV, PDF, imágenes y escaneados con OCR) y redacta con las plantillas del despacho. - Aplicación para el celular y reportería programada con alertas por meta. - Vigilancia con una persona detrás de cada consulta: los términos de la Rama Judicial prohíben el rastreo automatizado y FARO lo respeta por diseño. Los radicados se cargan y validan en la puesta en marcha. - Preservación legal: un expediente no se borra, se archiva.

12. ZIMPLE GESTIÓN

El plano de control de la plataforma y el portal del cliente

Dominio: zimple.uno/gestion · Portal de clientes: zimple.uno/portal Stack: FastAPI + PostgreSQL + Vue 3 · 87 tablas · 504 endpoints · 15 módulos de permisos

12.1 Qué es y por qué existe

Las cuatro aplicaciones anteriores se venden a clientes. Esta es distinta: es la que permite venderlas y sostenerlas. Zimple Gestión cumple dos funciones que en la mayoría de las empresas de software están repartidas entre cinco herramientas distintas y ninguna se habla con las otras:

1. Plano de control de toda la plataforma — dar de alta un cliente, activarle o suspenderle el servicio, ver quién entró a qué y cuándo, controlar la licencia y el cobro.
2. Portal del cliente — donde el cliente abre tickets, ve el estado de su servicio, consulta sus cuentas de cobro y se reúne por video con el equipo.

El argumento comercial: cuando un comprador pregunta «¿y si mañana necesito soporte?» o «¿cómo sé que ustedes van a estar?», la respuesta no es una promesa: es una herramienta que ya existe, que el cliente va a usar desde el primer día y que puede ver en la demo.

12.2 Administración multi-aplicación desde un solo sitio

Ninguna de las cuatro aplicaciones administra sus propios inquilinos: esa capacidad se extrajo deliberadamente de cada app y vive solo aquí. Un cliente de POS no puede tocar la configuración de su instancia ni la de nadie más, porque los endpoints que lo permitían fueron retirados de la app.

El plano de control descubre por consulta, no por aviso: pregunta periódicamente a cada aplicación qué inquilinos tiene. La diferencia importa —un aviso perdido deja un hueco permanente que nadie nota; una consulta periódica se repara sola y además descubre lo que ya existía.

Reparto de autoridad, sin ambigüedad: la aplicación manda sobre la identidad del inquilino (existe, cómo se llama, si está activo, cuántos usuarios tiene); Gestión manda sobre lo comercial (plan, vigencia, límites, cobro). Nunca se cruzan. Si se cruzaran, cada sincronización revertiría a la anterior en un bucle silencioso.

12.3 Licencias, cobro y mora

Tres tipos de licencia —básica, personalizada y completa— con módulos activables por cliente. La política de cobro está codificada, no delegada a la memoria de nadie: el servicio se suspende automáticamente el día siguiente a la fecha de pago si no se pagó, y la reconexión tiene un recargo del 10 %.

12.4 Soporte: tickets con destinatario a ambos lados

Un ticket tiene responsable en Zimple y destinatario en el cliente — la persona concreta, no «la empresa». Los avisos salen por WhatsApp y dentro de la aplicación cuando se abre un ticket, cuando alguien comenta, cuando cambia de estado y cuando se asigna.

12.5 Reuniones por video con acta automática

Videollamadas con el equipo, con el cliente desde su portal y con invitados externos por enlace. Compartir pantalla, chat, levantar la mano y grabación con acta redactada por IA: terminada la reunión, el sistema transcribe el audio y redacta un acta con resumen, temas, decisiones, compromisos y pendientes, que queda archivada junto al cliente o al ticket que la originó. El acta se marca siempre como generada por IA y sujeta a revisión.

12.6 Archivos — biblioteca central con vínculos

Almacenamiento de todo tipo de fichero (imágenes, vídeo, audio, comprimidos, hojas de cálculo) con árbol de carpetas, vista previa, y un mismo fichero vinculado desde varios sitios sin duplicarlo: el contrato subido una vez se ve desde la ficha del cliente y desde los tickets que lo citan.

12.7 Finanzas de la operación

Cuentas por cobrar (acuerdos de cobro recurrentes, cuentas de cobro, recaudos) y cuentas por pagar (gastos y compromisos mensuales, quincenales o recurrentes), contrastadas en una proyección de caja. Ingresos y egresos caen el mismo día del mes por diseño, para que la proyección compare peras con peras.

12.8 Auditoría y control de accesos

Registro de todos los accesos de todos los clientes: quién está en línea, último acceso de cada uno, actividad por inquilino. Un usuario cliente designado por empresa es el único que ve lo financiero y comercial; el resto solo ve y gestiona sus tickets.

12.9 Estado y límites

Construido y en producción. Pendiente: el almacenamiento de las grabaciones de reuniones requiere aprovisionamiento en la nube que aún no está hecho — las reuniones funcionan y se puede entrar, compartir pantalla y chatear, pero la grabación y el acta automática no están activas hasta que ese almacenamiento exista. El resto del módulo opera con normalidad.

PARTE III — MATERIAL COMERCIAL

13Matriz cruzada de capacidades

«n/a» no es una carencia: significa que la capacidad no tiene sentido en ese producto. Zimple Gestión no vende inventario ni liquida nómina porque no es un ERP — es el plano de control.

14Diferenciadores defendibles

Estos son los argumentos que no se pueden copiar con una demo de la competencia. Úsense en el centro de cualquier pieza.

14.1 "El sistema habla su idioma, no el del contador"

Prueba: los 16 verbos del ERP. El usuario dice "compré algo", "le pagué a un proveedor", "me llegó plata". El sistema traduce a causa contable, tipo de hecho, retención, documento legal y asiento. Y si el usuario se equivoca de verbo, el sistema se lo dice y le ofrece el correcto.

14.2 "Lo que el sistema decide solo, lo explica"

Prueba: la CxP del ERP muestra siempre por qué retiene o por qué no retiene. El índice de desempeño de FARO es explicable componente por componente. El copiloto cita la fuente cuando consulta la biblioteca. El vigilante detecta de forma determinista, no adivinando.

14.3 "Si no cuadra, alguien tiene que firmar por qué"

Prueba: el cierre de caja del POS calcula el esperado, recibe el contado, marca cuadrado/descuadrado y exige motivo escrito si no cuadra. Con nombre y hora.

14.4 "Nunca se borra: se anula con motivo"

Prueba: movimientos de cuenta anulables con fecha y razón (EJE). Libro de nómina que se corrige anulando y creando, jamás sobrescribiendo. Borrado suave en tarifas de turismo. Rechazo de borrado de casos con tareas en FARO.

14.5 "No lo amarramos a ningún proveedor"

Prueba: la regla de neutralidad del ERP. El conocimiento del software contable vive en una tabla bisagra y un microservicio adaptador. Cambiar de proveedor = adaptador nuevo, cero cambios al ERP. Igual con LiveKit en FARO: tres variables de entorno.

14.6 "La empresa se reconfigura sola"

Prueba: reglas de stock por acción (EJE). Fórmulas de precio editables (ÍTACA). Reglas de tesorería con dimensión/condición/acción (PILAR). Plantillas de proceso con etapas, pesos y compuertas (FARO). 98 flujos de notificación con destinatarios dinámicos (PILAR). Permisos campo por campo (PILAR).

14.7 "Los números no se inflan"

Prueba: el desempeño de FARO dice "s/d" cuando no hay datos, en lugar de un 50% neutro. El avance del caso excluye las tareas canceladas del numerador y del denominador. Los KPIs se calculan en el servidor sobre la cartera completa, no sobre la página visible. Las obligaciones de ÍTACA sin regla nacen en 0 y marcadas como pendientes de definir, no con un número inventado.

14.8 "Imposible que dos clientes se vean los datos"

Prueba: tenant_id en toda tabla operativa. La biyección instancia ⇄ empresa forzada con restricciones únicas en la base de datos. El dueño de un mensaje nunca se infiere del contenido. Certificaciones de multi-tenencia con reportes de tablas sin tenant_id y correcciones aplicadas.

14.9 "La IA no decide, y no puede hacer daño"

Prueba: el NLU del POS solo clasifica, jamás redacta al cliente. El copiloto del ERP prepara cambios (preparar_*) que un humano confirma. El de ÍTACA devuelve propuestas, y el envío al cliente está marcado como irreversible. El copiloto de FARO sí escribe —hay que decirlo, porque se verifica en dos minutos— pero solo a petición explícita y comprobando los permisos de quien pregunta en cada herramienta: no puede hacer nada que esa persona no pudiera hacer a mano.

Y una prueba mejor que cualquier declaración: en la bandeja de FARO, cuando el modelo lee un mensaje como "urgente", la tarea que se crea conserva la prioridad que fijó la persona; la lectura del modelo queda anotada, no aplicada. El diccionario de palabras clave del despacho sí puede elevarla, porque eso lo escribió alguien. La IA no pone criterio: lo pone el profesional, y el sistema lo dice en pantalla cada vez que le entrega algo.

Además: compuerta global de salida en modo manual · lista blanca fail-closed · presupuesto de tokens por empresa.

14.10 "El cliente final también entra"

Prueba: portal del ERP con 30 secciones (avance de obra con fotos, estado de cuenta, PQRS, garantías posventa, acta de entrega digital, referidos, simulador de cuotas). Portal público de ÍTACA que recibe solicitudes de cotización. Portal de FARO donde el cliente ve su caso, sube documentos, conversa y entra a reuniones.

15Argumentario por objeción

"Ya tenemos Excel / un sistema contable."

Excel no le avisa que una cuota vence mañana, no bloquea una etapa hasta que se radique la demanda, no descuenta el insumo al vender ni le exige explicar un descuadre de caja. Y su sistema contable registra el pasado; esto opera el presente y le entrega al contable el pasado ya cuadrado. No lo reemplazamos: lo alimentamos.

"Es muy caro / preferimos un desarrollo a la medida."

Un desarrollo a la medida le cuesta la construcción completa y después el mantenimiento completo, y arranca en cero. Aquí entra a un sistema con {368 tablas / 375 endpoints} ya construidos y probados en producción, y parametriza lo suyo. El costo de infraestructura se comparte; el aislamiento de sus datos no.

"¿Y si mañana no queremos seguir con ustedes?"

Sus datos son suyos: exportables en CSV, XLSX y PDF, y el respaldo de base de datos se le entrega. No hay formatos propietarios cerrados. Y por diseño no está amarrado a ningún proveedor externo: la neutralidad contable es una regla arquitectónica, no una promesa comercial.

"Nuestro proceso es distinto al de todos."

Exactamente por eso nada está en piedra. Los estados, los catálogos, las reglas, las fórmulas de precio, las etapas del proceso, los pesos, las notificaciones, los permisos y las plantillas de documento se editan desde la interfaz. Hay clientes en la misma app operando con lógicas opuestas.

"La IA se equivoca / no me confío."

Por eso la nuestra no decide. Consulta sus datos, propone, y el criterio sigue siendo suyo. En el ERP prepara un cambio que queda pendiente de aprobación. En FARO, si le pide crear una tarea, la crea — pero con sus permisos, no con los de un superusuario, y solo porque usted se lo pidió: no hay ningún proceso en el que actúe por su cuenta. Y lo que sí es una lectura suya —qué es urgente, qué significa un auto— se le muestra como propuesta y no se aplica solo.

Y cuando la IA no está disponible, todo sigue funcionando: la ruta determinista es la principal, la IA es el respaldo.

"¿Qué pasa con la seguridad de mi información?"

Base de datos en red privada, inalcanzable desde internet. Contraseñas con hash bcrypt. Credenciales de terceros cifradas en reposo. HTTPS con renovación automática. Auditoría de cada acción con valores antes y después, IP y navegador. Bitácora de cada descarga de archivo. Cierre de sesión por inactividad validado en el servidor. Y en modo estricto, el sistema no puede mandarle un mensaje a un número que no esté autorizado.

"¿Y si se cae?"

Cada aplicación corre aislada en sus propios contenedores: si una falla, las demás no se enteran. Los datos viven en volúmenes separados del programa. Hay respaldo del código en repositorio privado y dumps de base de datos con retención configurable. Las integraciones externas tienen reintento exponencial, cortacircuitos y cola de mensajes muertos: nada se pierde en silencio.

"Necesito que mis clientes vean su información sin llamarme."

Los tres sistemas con cliente final ya lo tienen. En el ERP el comprador ve el avance de su apartamento con fotos, paga, reclama garantías y refiere amigos. En FARO el cliente ve su caso, sube documentos y conversa. En ÍTACA el portal de la agencia recibe cotizaciones directo al sistema.

16Insumos para licitaciones y pliegos

16.1 Declaraciones de cumplimiento (redactadas para pegar)

Arquitectura y despliegue - Aplicación web multi-inquilino desarrollada sobre {FastAPI/Python 3.11 · PHP 8.2}, base de datos {PostgreSQL 16 · MySQL 8.0}, interfaz {Vue 3 · Bootstrap 5.3}. - Despliegue en contenedores Docker orquestados por Docker Compose sobre infraestructura Google Cloud Platform. - Proxy inverso con certificados TLS Let's Encrypt de renovación automática. Tráfico exclusivamente HTTPS. - Segmentación de red: bases de datos en red interna privada sin exposición a internet; únicamente el contenedor de aplicación se publica. - Persistencia en volúmenes nombrados independientes del ciclo de vida de la aplicación. - Aplicación para el celular (Android e iPhone), instalable y con notificaciones.

Multi-inquilino y aislamiento - Aislamiento de datos por tenant_id en la totalidad de las tablas operativas, aplicado en la capa de acceso a datos. - Restricciones de unicidad a nivel de base de datos que garantizan la biyección entre canal de comunicación e inquilino. - Certificación interna de multi-inquilino con inventario de tablas y verificación de fugas.

Seguridad - Autenticación por token JWT con expiración configurable y renovación. - Cierre de sesión por inactividad validado en servidor. - Bloqueo de cuenta por intentos fallidos; cambio obligatorio de contraseña en primer ingreso. - Contraseñas almacenadas con hash bcrypt; sin almacenamiento reversible. - Credenciales de sistemas externos cifradas en reposo (Fernet/AES). - Encabezados de seguridad CSP, HSTS y X-Frame-Options. - Prevención de inyección SQL por uso de ORM y sentencias preparadas. - Sanitización de contenido HTML (DOMPurify) contra XSS. - Control de comunicaciones salientes por lista blanca con política fail-closed.

Control de acceso - Modelo de permisos granular módulo × acción asignable por usuario individual. - {PILAR} Control de visibilidad y edición a nivel de campo por rol. - Rutas y endpoints protegidos por verificación de permiso en servidor y en cliente.

Auditoría y trazabilidad - Registro de auditoría con actor, acción, entidad, valores anteriores y posteriores, dirección IP y agente de usuario. - Bitácora de acceso a archivos (subida, descarga, eliminación, restauración). - Historial de estados y línea de tiempo por entidad de negocio. - Registro de ejecución de tareas programadas. - Los registros financieros no se eliminan: se anulan con motivo y trazabilidad.

Interoperabilidad - API REST documentada ({275 / 362 / 375} endpoints según sistema). - Exportación de datos en CSV, XLSX y PDF. - Integración con sistemas contables mediante adaptador desacoplado con carga canónica neutra (independencia de proveedor). - Integración de mensajería WhatsApp (Evolution API) y correo (IMAP/SMTP). - Webhooks entrantes y salientes.

Disponibilidad y resiliencia - Verificaciones de salud por servicio (healthcheck) con reinicio automático. - Reintento con retroceso exponencial en integraciones externas. - Patrón cortacircuitos y cola de mensajes muertos. - Procesamiento asíncrono en cola ({Celery/Redis} · cron supervisado). - Idempotencia en el procesamiento de webhooks.

Gobierno de la inteligencia artificial - La inteligencia artificial se emplea para clasificar, analizar, redactar y proponer. No se emplea para adoptar decisiones ni para fijar criterios profesionales, que corresponden en exclusiva al usuario responsable. - Toda salida del modelo se produce mediante esquema estructurado validado (tool_use), no por interpretación de texto libre. - Las funciones que modifican datos verifican los permisos del usuario solicitante en cada invocación: el asistente no dispone de identidad ni de privilegios propios, y no puede acceder a información que el usuario no pueda consultar por sí mismo. - Las propuestas del modelo no se aplican de forma automática: o quedan como cambio pendiente de confirmación, o se ejecutan únicamente por instrucción explícita del usuario dentro de la sesión. - Los hechos provenientes de fuentes oficiales se presentan diferenciados de la interpretación del modelo, con indicación de su procedencia. - La condición de contenido asistido por inteligencia artificial se declara en la interfaz en cada entrega, junto con los elementos que el usuario debe verificar. - Trazabilidad: toda operación asistida queda registrada en la bitácora de auditoría a nombre del usuario que la solicitó. - Arquitectura híbrida determinista primero: la vía por reglas es la principal y el modelo actúa como respaldo; ante indisponibilidad del proveedor de IA el sistema continúa operando. - Compuerta global de salida al exterior con modo manual, lista blanca de destinatarios y presupuesto de consumo por empresa.

Localización Colombia - Zona horaria America/Bogotá aplicada explícitamente en toda la lógica de negocio. - Formato de moneda y fecha colombiano. - Codificación UTF-8 (utf8mb4) con collation español. - {PILAR} Cumplimiento fiscal: identidad DIAN, dígito de verificación de NIT, responsabilidades fiscales, DIVIPOLA, UVT anual, retención en la fuente, IVA, ICA por municipio, documentos legales colombianos (factura electrónica, nota crédito/débito, documento soporte, recibo de caja, comprobante de egreso). - {PILAR} Figura AIU (Administración, Imprevistos, Utilidad) para contratación de obra. - {ÍTACA} RNT (Registro Nacional de Turismo) en documentos de agencia.

Sostenibilidad - Código fuente respaldado en repositorio Git privado. - Documentación técnica y funcional interna mantenida. - {PILAR} Suite de pruebas automatizadas del motor de operaciones: 147 pruebas de aplicación, 37 del adaptador contable, 9 extremo a extremo. - {PILAR} Videos de capacitación integrados al producto con seguimiento de reproducción.

16.2 Cifras para tablas de pliego

17Alcances y condiciones comerciales

Esta sección fija qué se vende y en qué condiciones, para que cada comercial diga lo mismo. La franqueza de la marca —«dice lo que no hace»— se aplica a las condiciones: no cobramos por usuario, no amarramos con permanencia y no escondemos el precio.

Lo que incluyen las cuatro plataformas

• Cobros en línea: link de pago y QR con PSE, tarjeta, Nequi y Daviplata. La tarifa de la entidad de pagos la cobra la pasarela.
• Facturación electrónica DIAN a través de proveedor tecnológico autorizado (EJE con cupo por plan; FARO, ÍTACA y PILAR hasta 300 documentos al mes).
• WhatsApp y correo: un número incluido, avisos operativos sin límite y campañas con cupo mensual.
• Asistentes con IA: copiloto interno y asistente de atención a clientes, con cupos por plan que nunca se exceden sin autorización del administrador.
• Aplicación para el celular (Android e iPhone), instalable y con notificaciones.
• Reportería: tablero en tiempo real y resumen semanal en todos los planes; reportes programados y alertas desde el plan 2; tablero gerencial y Power BI en el plan 3.
• Firma electrónica con constancia donde el producto la usa: contratos, poderes, actas y aprobaciones.

Lo que no hacemos

• No cobramos por usuario: cada plan trae un cupo y el adicional tiene precio publicado.
• No hay permanencia: se cancela con 30 días de aviso y el cliente se lleva el respaldo completo.
• No hay precios escondidos: planes, adicionales y puesta en marcha están publicados en zimple.uno.
• No se cobra un consumo adicional sin autorización del administrador.

Por producto

Cómo responder una pregunta de alcance

✅ "Sí, viene en el plan {plan}. Se configura en la puesta en marcha y queda escrito en el acta de arranque, con su fecha." ✅ "Eso es específico de su operación: lo cotizamos por alcance, con precio cerrado, a partir de la hora de ingeniería publicada ($100.000)."

Precios y condiciones vigentes: comercial/PRECIOS_2026-09.md (v2, 12-sep-2026).

18Glosario para no técnicos

Cómo usar este dossier

Documento generado por auditoría directa del código fuente, esquemas de base de datos y documentación técnica de producción de las cinco aplicaciones — Zimple Tecnología, 2026-09-04. Precios y condiciones comerciales: PRECIOS_2026-09.md, versión del 12-sep-2026.