HEYAY LABSContenido de la propuesta
Finanzas con Norma.
El primer flujo de X-Men.
Un cerebro propio de Rolling Host, con módulo financiero y aplicación web. Captura en Excel; consulta y operación desde ChatGPT o desde la web, sobre una misma base de datos.
- Preparado para
- Norma y José
Rolling Host - Preparado por
- HEYAY LABS
- Fecha
- 6 de octubre de 2026
- Etapa propuesta
- Implementación FDE
01Lo que proponemos
Construir el cerebro de Rolling Host con su módulo financiero para Norma y una aplicación web para visualizar, editar y consultar los dashboards principales. José y sus equipos podrán trabajar sobre la misma información desde ChatGPT, otros asistentes habilitados o la aplicación web.
El trabajo será híbrido. El equipo sigue capturando y haciendo sus números en Excel. Para incorporar esa información al sistema, pega los datos o sube el archivo por chat. El agente entiende qué recibió, pide lo que falta y propone cómo registrarlo; el sistema valida, guarda y calcula desde una base de datos propia.
Norma conserva las decisiones sobre tratamientos y ajustes. José consulta el cierre aprobado y las decisiones que le corresponden. El objetivo es mitigar errores de captura y consolidación, reducir revisiones repetidas y conservar el origen de cada cambio.
La base de trabajo ya existe: sesiones de entendimiento, revisión de 12 libros y 52 funcionalidades documentadas. Conservamos ese análisis como respaldo y priorizamos qué construir primero.
02Qué recibirá Norma
| Entrega del piloto | Qué podrá hacer |
|---|---|
| Excel + recepción por chat | Seguir trabajando en Excel y pegar datos o subir archivos al chat; conocer qué se recibió, qué falta y qué no cuadra. |
| Datos y cálculos propios | Conservar movimientos y pagos, distribuir nómina corporativa y calcular el P&L con reglas verificadas. |
| Aplicación web y dashboards | Visualizar y editar la información autorizada; consultar resultado por unidad y periodo, gastos, nómina, pagos y pendientes en los dashboards principales. |
| Conectividad con sistemas terceros | Evaluar y construir conexiones con el punto de venta u otros sistemas cuando tengan API disponible, accesos autorizados y alcance acordado. |
| Extraordinarios y pendientes | Consultar el gasto original, pagos y cargos por mes; aplazar o juntar cargos y ver el efecto antes de aprobar. |
| Bitácora, revisión y cierre | Consultar quién subió o confirmó cada cambio, resolver incidencias, aprobar una versión y exportar a Excel. |
| Conexión con José | Publicar el cierre con fuentes, fecha, cobertura y decisiones pendientes; recibir las decisiones autorizadas de dirección. |
Rojo significa extraordinario. El sistema separa cuánto se gastó, cuánto se pagó al proveedor y cuánto se cargó al resultado de cada mes. La nómina corporativa usa porcentajes con vigencia aprobada por Norma.
Una aplicación web que también pueden usar los agentes
Construiremos una aplicación web para visualizar la información financiera, editar registros autorizados y consultar los dashboards principales: P&L por unidad y periodo, ingresos y gastos, nómina, pagos y saldos, extraordinarios e incidencias del cierre.
La aplicación comparte la misma base de datos con el chat. Una edición muestra el cambio propuesto, aplica las validaciones y permisos y conserva quién modificó qué. Los cambios en un cierre publicado generan una revisión que requiere aprobación.
También será agéntica: crearemos un servidor MCP que exponga sus funciones de consulta y edición autorizada para agentes de inteligencia artificial. Así podrán recuperar datos de los dashboards, proponer modificaciones y ejecutar las acciones confirmadas usando las mismas reglas y bitácora que la aplicación web.
La primera validación compara un mes histórico completo contra sus fuentes; después Norma opera un cierre nuevo con acompañamiento. Cada diferencia debe quedar explicada.
Información que fluye de sistema a sistema
También podremos abordar conexiones con el punto de venta y otros sistemas del grupo para que la información llegue al módulo financiero y al cerebro con menos transferencias manuales. Para conectar un sistema tercero debe contar con una API disponible y acceso autorizado.
Revisaremos qué datos expone la API, cómo se identifican los movimientos, sus permisos y límites, y qué operaciones permite. Con eso priorizamos y acordamos las conexiones a construir, su frecuencia y si solo consultan información o también admiten acciones confirmadas.
Las conexiones dejan rastro de origen y última actualización y controlan duplicados y fallos. Si un sistema no cuenta con API o aún no hay acceso, su información puede seguir entrando por exportaciones Excel y chat.
Las 52 funcionalidades describen el destino completo. Las integraciones concretas con terceros se seleccionan según disponibilidad de API, accesos y complejidad dentro del alcance acordado. Lectura programada de carpetas, fotos y extensión a otras unidades se priorizan como ampliaciones.
03Cómo opera Excel + chat + datos
Excel sigue siendo el espacio donde el equipo captura, organiza y hace sus números. El chat será la puerta de entrada al sistema: se puede pegar una tabla o subir el archivo Excel. Ambas opciones pasan por interpretación, revisión y confirmación antes de convertirse en información aceptada.
El equipo trabaja en sus formatos.
Corte, nómina, inventario y pagos.
Copy-paste o archivo.
Entiende columnas, propone campos y pregunta lo que falta.
Fuente de verdad única.
Registros, cálculos, versiones y bitácora de cambios.
Qué hace el chat con la información
| Paso | Qué ocurre |
|---|---|
| 1. Reconocer | Identifica qué información se entregó, sus columnas, unidad y periodo. Propone cómo corresponde a los campos de la base. |
| 2. Pedir lo que falta | Señala campos obligatorios ausentes o ambiguos: fecha, unidad, concepto o importe. Pregunta y conserva el lote pendiente. |
| 3. Comprobar | El servicio verifica tipos, sumas, duplicados, permisos y coherencia. El agente explica incidencias y propone relaciones o clasificaciones. |
| 4. Confirmar | Muestra qué se agregará o modificará. La persona autorizada confirma; las decisiones sobre ajustes y cierre siguen bajo la autoridad de Norma. |
| 5. Guardar con recibo | El sistema guarda lo aceptado y devuelve folio, conteos, periodo y pendientes. Solo entonces el chat confirma que quedó registrado. |
| 6. Registrar el cambio | La bitácora guarda quién entregó, quién confirmó, cuándo, qué cambió, valores anteriores/nuevos, fuente y motivo. |
Una fuente de verdad y un historial verificable
La base de datos concentra los registros aceptados, los pagos, las asignaciones entre meses y los cálculos de Finanzas. Excel continúa como captura y salida de reportes; las cifras consolidadas se obtienen del estado vigente del sistema.
Un cambio posterior vuelve por chat como una revisión: se compara contra lo guardado y se confirma antes de actualizar. La bitácora distingue a quien entrega una fuente, a quien confirma su carga y a quien aprueba el tratamiento. La identidad proviene de la sesión autenticada del conector.
Si se sube un archivo, se conserva su versión y el origen de los registros. Si se pega información, se conserva el contenido entregado y su recibo. El historial empieza en lo que recibe y registra el sistema: atribuir ediciones previas dentro de Excel requiere evidencia adicional.
04El cerebro general de Rolling Host
El sistema de Norma conserva los movimientos y cálculos de Finanzas. El cerebro general conecta ese dominio con el conocimiento, estado y decisiones del resto del negocio: lo que José ya construyó en el CEO Office Maestro y lo que sus gerentes confirmen sobre sus áreas.
Agnóstico significa que el negocio conserva su información y sus reglas aunque cambie de inteligencia. Claude, ChatGPT o un agente futuro son maneras de acceder al mismo cerebro. Cada persona consulta y registra únicamente lo que sus permisos y su autoridad permiten.
La ontología: hacer explícita la lógica del negocio
Para que un agente trabaje correctamente necesita entender qué existe en Rolling Host, qué significa cada concepto, cómo se relaciona con los demás y qué reglas, excepciones y decisiones lo gobiernan. Ese modelo compartido del negocio es la ontología. Se construye con José, Norma y sus equipos a partir de la lógica que hoy aplican en su trabajo.
Documentaremos conceptos como razón social, unidad, periodo, gasto, pago, asignación y cierre; sus relaciones, estados, fuentes de verificación y autoridad. Así el agente puede distinguir lo recibido de lo aprobado y un pago de un cargo al resultado, y saber qué necesita preguntar antes de actuar.
Una estructura navegable para personas y agentes
Organizaremos el conocimiento como un file system: un índice por áreas y temas, documentos breves enlazados e instrucciones de navegación. El agente podrá localizar el contexto pertinente y consultar sus fuentes sin cargar todo el conocimiento de la empresa en cada conversación.
Usaremos formatos abiertos como OKF — Open Knowledge Format—, que organiza conocimiento en archivos Markdown con metadatos YAML y enlaces. La estructura permite encontrar y describir el conocimiento; la ontología aporta su significado y las reglas del negocio. Los movimientos financieros siguen en la base de datos y los documentos referencian sus fuentes autorizadas.
Un cerebro que evoluciona
Cada corrección validada, nueva fuente o cambio de proceso puede enriquecer ese modelo. Conservaremos versiones, evidencia y aprobación de las reglas, junto con pruebas de casos aceptados por el equipo. Una observación del agente se revisa antes de convertirse en una regla vigente.
Adaptaremos la organización del contexto, las instrucciones, los conectores y las evaluaciones a las mejores prácticas que vayamos verificando para los modelos utilizados. Antes de incorporar un cambio comprobaremos su efecto en los casos de Rolling Host. La entrega incluye el procedimiento para mantener esta evolución, preservando datos, permisos e historial.
Referencia de formato abierto: Open Knowledge Format, repositorio de Google Cloud. El formato organiza el conocimiento; las definiciones y decisiones se construyen y validan con Rolling Host.
Cómo se conecta una inteligencia al cerebro
Construiremos un servicio de acceso al núcleo y sus herramientas de consulta y registro. Se presenta como una app o plugin en ChatGPT y como un conector en Claude, según la configuración admitida por las cuentas. El contrato compartido conserva el significado de los datos, los permisos y los recibos de las acciones.
| Mecanismo | Para qué se utiliza |
|---|---|
| MCP y API | Dar al asistente herramientas para consultar datos, proponer registros, revisar incidencias y solicitar acciones al sistema. |
| MCP de la aplicación financiera | Exponer los datos de los dashboards y las funciones de consulta y edición autorizada de la aplicación web para que también las utilicen agentes. |
| API de sistemas terceros | Conectar POS y otras fuentes con API disponible y acceso autorizado para intercambiar información entre sistemas bajo reglas y permisos acordados. |
| App / plugin / conector | La entrada visible en cada herramienta: conecta la cuenta de la persona con las funciones permitidas del cerebro. |
| Agent to Agent (A2A) | Comunicar agentes independientes para intercambiar tareas y resultados cuando el caso requiera esa coordinación. |
El acceso se comprueba en el servidor: identidad, entidad legal, función y acciones autorizadas. Cada solicitud de escritura se valida y deja un recibo y una bitácora. El protocolo conecta las herramientas; las reglas de Rolling Host determinan quién puede ver, proponer o aprobar.
La aparición de agentes como Muse de Meta y dot de OpenAI refuerza este enfoque: construir el activo de Rolling Host para poder conectar nuevas interfaces conforme admitan acceso externo y se validen sus permisos.
La primera entrega prueba el acceso desde ChatGPT y Claude en las cuentas habilitadas. La adaptación a Muse, dot u otros agentes, y la coordinación por A2A, se evalúan según sus interfaces disponibles y el caso de uso; no se presupone compatibilidad universal ni un mismo instalador para todas las herramientas.
Qué conserva el cerebro
| Capa | Aplicación en el piloto |
|---|---|
| Conocimiento | Definiciones, reglas de Norma, procedimientos y excepciones aceptadas. |
| Hechos | Cargas, correcciones y decisiones con folio, autor, fecha y ámbito. |
| Evidencia | Archivos y registros que respaldan cada cifra y cada afirmación. |
| Estado y autoridad | Cómo está el cierre hoy, quién responde, quién decide, qué está bloqueado y qué fue aprobado y verificado. |
Estado vivo: recibido → con incidencias → listo para revisión → aprobado → publicado. Una carga no equivale a un cierre aprobado. Si se corrige después de publicar, la versión vigente sigue visible hasta que se apruebe la revisión.
Autoridad: quien entrega una fuente responde por ella; Norma decide los tratamientos de su ámbito; José resuelve lo que se le escale. La matriz de autoridad define cuáles ajustes requieren cada aprobación.
Razones sociales: se registran por separado entidad legal, marca y unidad. Los permisos se aplican también al chat, búsquedas y exportaciones. Un consolidado para José requiere autorización explícita sobre las entidades incluidas.
Fuentes en conflicto: se preservan ambas versiones, se marca qué está verificado, reportado o inferido y se pide resolución al responsable. Los avisos se priorizan por impacto acordado y muestran quién debe decidir.
Estos criterios incorporan la respuesta de José del 17 de septiembre. Las decisiones y acciones sensibles siguen bajo validación humana. La recepción técnica puede automatizarse; no sustituye la aceptación de los datos ni la aprobación del cierre.
Referencias de conectores y protocolos
Apps MCP en ChatGPT · Conectores MCP remotos en Claude · Agent2Agent: comunicación entre agentes. Documentación oficial consultada el 6-oct-2026; disponibilidad y acciones se verifican en las cuentas del piloto.
05Análisis del proceso con Norma
Estas son las sesiones, los archivos y las reglas que fundamentan lo que vamos a construir. El detalle del diagnóstico y las funcionalidades permanece dentro de esta propuesta.
Sesiones y correos que fundamentan el alcance
- Onboarding de Norma, 4-sep: Excel, fuentes y duplicación de captura; resumen consultado.
- Entendimiento de Norma, página fechada 25-sep: transcripción completa, extraordinarios, nómina y consolidación. La fecha de la página no confirma por sí sola la fecha de grabación; el análisis conserva la discrepancia con el antecedente del 17-sep.
- Sesión de cerebro empresarial, 16-jun: notas y resumen sobre memoria compartida y estado de gerentes.
- Correos con José: 28-may, alcance X-Men; 1-jun, diagnóstico antes del desarrollo; 6-sep, fechas y adopción de Norma; 15-sep, arquitectura enviada; 17-sep, estado, autoridad y piloto. Son antecedentes y solicitudes; no acreditan que el desarrollo ya esté implementado.
Los 12 archivos recibidos y para qué sirven
| Archivo | Uso en el proceso |
|---|---|
| CORTE MENSUAL (1).xlsx | Detalle y controles de ventas, gastos y aportaciones. |
| P&L (1).xlsx | Presentación del resultado y referencias a parcialidades. |
| FORMATO EDO RES AA.xlsx | Reporte externo con mapeo y conciliación propios. |
| FORMATO INVENTARIO.xlsx | Inventarios y valuación para costo consumido. |
| Ingresos y Egresos efectivo.xlsx | Cruce de ventas, gastos y conteo de caja. |
| AMARO RECORDS REPORTE PAGO DE NOMINA 2026 (1).xlsx | Formato de Amaro incorporado el 25-sep. |
| AMARO RECORDS REPORTE PAGO DE NOMINA 2026 (1) (1).xlsx | Segundo formato de Amaro incorporado el 5-oct. |
| JAMAICA GOGO REPORTE PAGO DE NOMINA 2026.xlsx | Nómina de unidad; incorporado el 5-oct. |
| LUPE CANDOR REPORTE PAGO DE NOMINA 2026.xlsx | Nómina de unidad; incorporado el 5-oct. |
| GEISHA GITANA AME REPORTE DE NOMINA 2026.xlsx | Formato AME; incorporado el 5-oct. |
| GEISHA GITANA PROVI REPORTE DE NOMINA 2026.xlsx | Formato PROVI; incorporado el 5-oct. |
| CORPORATIVO REPORTE DE NOMINA 2026.xlsx | Base corporativa para distribución; incorporado el 5-oct. |
Siete libros de nómina en total, seis incorporados el 5-oct. La fecha de descarga no identifica el periodo de sus datos. La revisión no modificó originales ni expone salarios individuales.
Hallazgos del análisis y lógica construida
| Hallazgo | Regla o funcionalidad que se construirá |
|---|---|
| Rangos inconsistentes en Corte y referencias de aportaciones faltantes en ciertos meses. | Leer todo el detalle, comprobar cobertura y separar ventas de otras entradas. |
| Presupuesto y semanas se cancelan en fórmulas de P&L; AA tiene referencias rotas. | Separar presupuesto y real y calcular desde reglas validadas; explicar diferencias. |
| La copia del P&L trae referencias a parcialidades, pero no conserva esos conceptos en rojo. | Guardar extraordinario como atributo explícito y confirmar qué significa cada parcialidad. |
| Norma distribuye corporativo y decide cargos entre periodos. | Versionar porcentajes y decisiones; separar pagos, cargos al resultado y saldos. |
| El paquete contiene plantillas y datos parciales, no un cierre completo demostrable. | Completar un mes de referencia antes de afirmar exactitud o ahorro de un cierre real. |
Modelo de relaciones: razón social → unidad → periodo → movimiento original → pagos y asignaciones → P&L versionado → aprobación y consulta de José. Cada elemento conserva fuente, responsable y decisiones aplicables.
Documentación completa
- Propuesta detallada del 5-oct: 14 secciones y 52 funcionalidades.
- Análisis de sesiones, archivos, fórmulas y decisiones.
- Detalle funcional: 12 módulos, reglas y casos de aceptación.
- Propuesta FDE y complemento de estado, autoridad y acceso.
La versión del 6-oct incorpora los correos de José y el método FDE. Complementa el alcance anterior con estado vivo, autoridad y separación por entidad legal. El módulo financiero, la aplicación web y los conectores son entregables propuestos.
La lógica de Norma: extraordinarios, pagos, nómina e inventario
Gastos extraordinarios, pagos y meses
Rojo identifica un gasto extraordinario. Un extraordinario puede cargarse completo ese mes o repartirse entre periodos. El sistema guarda ambos atributos por separado y relaciona cada cargo con el gasto original.
| Concepto | Cómo lo conserva el sistema |
|---|---|
| Gasto original | Documento, monto, unidad, concepto y periodo de origen. |
| Pagos al proveedor | Abonos realizados y saldo aún por pagar. |
| Cargos al P&L | Monto asignado a cada mes, autor y motivo. |
| Pendiente de asignar | Total original menos cargos aplicados, con calendario y seguimiento. |
| Cambios de Norma | Aplazar, juntar parcialidades o cambiar un calendario con comparación antes/después. |
Nómina e insumos
| Regla | Comportamiento esperado |
|---|---|
| Staff de línea | Nómina agregada asignada a su unidad, conciliada con sus fuentes. |
| Corporativo | Porcentajes normalmente fijos, con vigencia y cambios aprobados. No se redistribuye cada semana automáticamente por ventas. |
| Banco, efectivo y deducciones | Conciliación según significado de campos acordado; neto y otros componentes permanecen diferenciados. |
| Insumos consumidos | Se incluyen aunque estén pendientes de pago; costo basado en inventarios y compras con ajustes acordados. |
| Cierres y presupuesto | Presupuesto, real y ajustes se conservan separados; los cambios de reglas no reescriben cierres publicados. |
Un texto como «pago 3 de 5» requiere confirmar si describe abonos al proveedor o cargos entre meses. La interpretación se guarda como regla explícita. El tratamiento documentado aquí es gerencial; las definiciones contables aplicables se validarán con Norma y su equipo.
Análisis técnico completo: proceso, reglas, archivos y fórmulas revisadas
Proceso y responsabilidades actuales
| Entrada | Trabajo actual | Resultado que consume Norma |
|---|---|---|
| Ventas del POS | Captura en cédula de ventas | Ventas por periodo y forma de pago |
| Notas, facturas, bancos y efectivo | Una persona captura Corte Mensual; otras revisan pagos y presupuestos | Gastos clasificados y pendientes |
| Nómina semanal/quincenal de cada unidad | RH prepara libros; Norma revisa sumas y transfiere totales | Nómina por unidad sin exponer salarios individuales |
| Nómina de corporativo | Norma aplica porcentajes por persona/grupo y unidad | Costo asignado a cada negocio |
| Inventarios | Conteos y valuación | Costo de insumos consumidos |
| Gastos administrativos y mantenimiento extraordinarios | Norma decide cargos entre meses y controla pendientes con colores/texto | Ajustes al reporte gerencial |
| Estado de resultados externo AA | Norma revisa lo entregado por contadores | Información para el reporte al CEO |
En la sesión del 25-sep hay una capturista del Corte y cuatro personas involucradas en su revisión, incluyendo Norma. RH tiene dos personas que pueden llenar nómina. Norma plantea que una sola persona concentre la carga al sistema. Astrid aparece como posibilidad; no está designada formalmente.
OneDrive/Microsoft y Google Drive son fuentes distintas. Preferir Excel no obliga a migrar todas las carpetas antes de obtener valor. La carga inicial de archivos puede reunir fuentes de ambas plataformas.
Reglas que deben quedar fuera de la cabeza de Norma
Nómina y distribución entre unidades
- Staff de línea se carga a su unidad; corporativo se distribuye según una matriz de porcentajes.
- Los porcentajes son normalmente fijos y cambian mediante decisión, aunque ventas y tamaño de la unidad influyen al definirlos. No recalcularlos automáticamente con las ventas de cada semana.
- Versionar matriz, vigencia, persona/grupo, unidades, aprobador y motivo. Validar 100% de distribución y registrar diferencias de redondeo. Un cambio de matriz no reescribe cierres pasados.
- Conciliar banco, efectivo y deducciones aplicables con el total de cada periodo. La transcripción distingue el neto pagado de deducciones que se pagan por otra vía. Esa distinción debe preservar el costo completo donde corresponda y evitar duplicarlo: confirmar campos y tratamiento con Norma antes de fijar la fórmula.
- Los reportes para asistentes llevan agregados. RH puede trabajar con su nómina autorizada sin recibir ventas ni P&L de todas las unidades. Nómina individual y distribución corporativa requieren permisos explícitos.
Gastos, pagos y cargos entre meses
Guardar por separado: documento original, monto, fecha del documento, consumo/periodo de origen, pagos al proveedor y asignaciones al reporte gerencial. Pagar un gasto y cargarlo al P&L son operaciones distintas.
Norma relata que puede omitir una parcialidad un mes, incluir dos después y mantener pendientes desde el año anterior. El sistema necesita saldo pendiente de asignar, historial y motivo de cada cambio; dividir un monto en partes iguales no reproduce su proceso.
El color rojo del P&L significa gasto extraordinario. Un gasto extraordinario puede cargarse completo o en parcialidades. Registrar dos atributos independientes: recurrente/extraordinario y directo/distribuido entre periodos.
Propuesta: la IA prepara alternativas y explica diferencias; Norma confirma el tratamiento. Mostrar un puente entre movimientos originales y reporte gerencial ajustado, incluyendo cargos diferidos y saldo pendiente. Esto permite entender la cifra que recibe José sin borrar el gasto original. Es un diseño del reporte gerencial; no se ha validado aquí un tratamiento fiscal o contable.
Inventario y costo de insumos
La sesión describe inventario inicial + compras − inventario final como base del costo consumido. Los insumos consumidos entran aunque no estén pagados. Confirmar devoluciones, transferencias, mermas, impuestos y valuación antes de consolidar todas las unidades.
La cifra del 20% mencionada por Norma es un criterio para bebidas de ciertos negocios, no un umbral universal verificado. Una desviación genera revisión; por sí sola no prueba robo.
Calendario y definiciones
Definir día operativo para ventas de madrugada, semanas que cruzan meses, nómina semanal/quincenal, ventas con/sin IVA y diferencia entre presupuesto, real y ajustes. La plantilla P&L está fechada en febrero de 2026; no asumir que corresponde al mes del piloto.
Revisión actual de los archivos
| Archivos | Evidencia estructural | Implicación |
|---|---|---|
| Corte Mensual | 16 hojas, rangos fijos, sin tablas de Excel detectadas | Importar detalle con controles de cobertura; no confiar solo en la carátula |
| P&L | Una hoja `Presupuesto Jamaica (2)`; semanas A:E, F rotulada Presupuesto y resultados H | Acordar qué representa cada columna antes de automatizar |
| Siete libros de nómina | Jamaica, Lupe, dos Geisha, corporativo y dos Amaro | Ya hay más formatos que en el diagnóstico anterior; ambos Amaro tienen hashes y estructuras distintos |
| AA | Ocho hojas, dos ocultas, datos parciales y errores | Ingesta separada con conciliación; no dar por aprobado lo externo |
| Inventario | Destilados, sin alcohol y herramientas | Confirmar inventarios de apertura/cierre y qué rubros corresponden a COGS |
| Efectivo | Una hoja de ventas, gastos y conteo | Validar el cruce, conservando el conteo físico humano |
Los libros de nómina tienen campos operativos mayormente vacíos y datos numéricos residuales en algunas pestañas. Corte y P&L son plantillas sin un mes completo demostrable. Hay datos parciales en AA e inventario. No existe en este paquete una conciliación completa que permita demostrar ahorro o exactitud de un cierre real.
Defectos confirmados y cuestiones a validar
1. Corte, CARATULA!B8: total de ventas de enero vacío; los otros meses tienen referencias.
2. Corte, CARATULA!B16/D16/F16/H16: enero apunta a APORTACIONES!B10 y febrero a B11, ambas vacías; marzo y abril no tienen fórmula. El total de enero está en APORTACIONES!B9. Algunos meses posteriores sí apuntan a fila 9. La frase histórica «las aportaciones nunca entran» era demasiado amplia.
3. Corte, CARATULA!B21/D21: Operación llega a fila 181 en enero y 799 en febrero. B22 frente a R22/X22: Administración termina en fila 86 para enero y 134 para septiembre/diciembre. Son rangos inconsistentes que pueden excluir nuevas filas; con estas plantillas no se cuantifica pérdida real.
4. Corte, CARATULA!B35/J35: enero usa ingresos de fila 15 y mayo total de fila 17. Definir la naturaleza de «aportaciones» y el significado de esta vista antes de homogeneizar. No sumar automáticamente financiación como utilidad operativa.
5. P&L, F12/H12, F23/H23 y otras filas: F contiene el negativo de las semanas y H suma A:F. Si esas fórmulas permanecen, los valores de A:E se cancelan en esas filas. Confirmar si F debía sustituirse manualmente o representa otra lógica. No usar esta plantilla como motor de cálculo sin resolverlo.
6. P&L, H9: promedio simple de tickets semanales A:F. Si se busca ticket mensual, calcular ingresos aplicables / clientes del periodo, con tratamiento explícito de semanas sin clientes y separación del presupuesto.
7. AA, VENTAS!K9:R9/T9:V9: 11 fórmulas con #REF!. Hay 26 valores cacheados #REF! en la hoja y divisiones entre cero en otras. Los errores cacheados muestran el último valor guardado, no una recalculación actual.
8. Efectivo, Ingresos y Egresos!A1: valor guardado #VALUE!. No se confirmó que afecte el total de dinero; reportarlo sin atribuirle una pérdida.
No se editaron originales ni se publicó información individual de nómina. La revisión acredita problemas estructurales, no una auditoría financiera concluida.
Las 52 funcionalidades del proceso, en detalle
Doce módulos y 52 funcionalidades que aterrizan el proceso completo. Las etapas de la sección 10 organizan su implementación. Las decisiones indicadas como «por validar» se acordarán con Norma antes de convertirlas en reglas definitivas.
M01. Unidades, periodos y reglas
| ID | Funcionalidad | Qué permite |
|---|---|---|
| F01 | Catálogo de unidades y fuentes | Asociar cada libro con negocio, tipo de información y responsable. Distinguir ambas Geisha y versiones de Amaro. |
| F02 | Calendario de cierre | Seleccionar año, mes y semanas. Definir día operativo para ventas nocturnas y reglas de semanas que cruzan meses. |
| F03 | Catálogo de conceptos | Relacionar categorías de Corte, P&L y AA mediante cuentas comunes y reglas por unidad. Casos sin correspondencia quedan pendientes. |
| F04 | Reglas con vigencia | Conservar quién aprobó una regla y desde cuándo aplica; no alterar periodos cerrados al cambiarla. |
Base: archivos con estructuras distintas y lógica explicada por Norma. Día operativo, correspondencias y calendario exactos: por validar.
M02. Recepción de archivos y datos
| ID | Funcionalidad | Qué permite |
|---|---|---|
| F05 | Recepción e interpretación por chat | Recibir Excel o información estructurada mediante el conector. El agente propone unidad, periodo, tipo de libro y registros; confirma ambigüedades y conserva la fuente. El servicio valida y devuelve recibo. Canal separado para nómina sensible. |
| F06 | Lista de fuentes esperadas | Mostrar Corte, nóminas, inventarios y exportaciones recibidos/faltantes. Un día cerrado o sin operación puede declararse para distinguirlo de una omisión. |
| F07 | Lectura de registros completos | Reconocer encabezados, filas nuevas, hojas ocultas y espacios en nombres. No importar subtotales como movimientos adicionales. |
| F08 | Detección de recargas y revisiones | Reenviar el mismo archivo no duplica datos. Un archivo actualizado muestra altas, cambios y bajas propuestas antes de sustituir información aceptada. |
Base: sesión plantea una persona que sube archivos y recibe feedback. El flujo admite copy-paste y carga de archivos Excel por chat. La información pegada conserva su contenido y recibo; el archivo conserva su versión y los registros de origen disponibles.
M03. Validación y bandeja de incidencias
| ID | Funcionalidad | Qué permite |
|---|---|---|
| F09 | Revisión de estructura y campos | Detectar fechas, conceptos, importes o unidad faltantes y columnas desplazadas. |
| F10 | Revisión independiente de cálculos | Comparar detalle contra totales declarados y detectar referencias rotas o filas omitidas por fórmulas. |
| F11 | Posibles duplicados | Señalar coincidencias por identificadores, proveedor, fecha e importe; distinguir factura de pago y parcialidades legítimas. |
| F12 | Incidencias con origen y seguimiento | Mostrar problema, archivo/hoja/fila, responsable, respuesta y estado. Solicitar corrección y repetir los controles afectados. |
El agente interpreta, relaciona información y propone cómo registrarla. El software valida los registros y calcula el P&L desde la base de datos, con reglas repetibles. Una anomalía no autoriza a cambiar el importe sin evidencia. Las incidencias que impiden aprobar se definirán con Norma; las restantes pueden quedar como observaciones visibles.
M04. Ventas, efectivo y bancos
| ID | Funcionalidad | Qué permite |
|---|---|---|
| F13 | Ventas por día y forma de pago | Importar y comparar cédula y reporte disponible del POS, preservando descuentos, cortesías e impuestos. |
| F14 | Conciliación de efectivo | Relacionar venta, dinero adicional, gastos y sobrante con el registro de caja. El conteo físico sigue a cargo del equipo. |
| F15 | Conciliación de pagos bancarios | Asociar movimientos a gastos/documentos y explicar comisiones, pagos parciales y diferencias de fecha. |
| F16 | Separación de ventas y otras entradas | Distinguir venta, aportaciones y transferencias para evitar que una misma entrada incremente ventas y utilidad por error. |
Base: Corte, efectivo y proceso de bancos. Integración directa del POS es posterior; el piloto usa exportaciones. Conciliación automática de bancos depende de recibir estados/exportaciones y acordar cómo se identifican pagos.
M05. Gastos y clasificación para el P&L
| ID | Funcionalidad | Qué permite |
|---|---|---|
| F17 | Registro único de cada gasto | Conservar documento, concepto, unidad, importe, periodo de origen y evidencia. |
| F18 | Pagos y pendientes por separado | Registrar pagos al proveedor y saldo por pagar sin confundirlos con cargos al P&L. |
| F19 | Clasificación sugerida y revisión | Proponer cuenta/categoría usando reglas aprobadas; Norma o una persona autorizada resuelve casos ambiguos. |
| F20 | Recurrente o extraordinario | Guardar esa distinción como campo, con explicación y representación visual en el reporte. |
Base: categorías del Corte y explicación de rojo/negro. La categoría de mantenimiento por sí sola no convierte todo gasto en extraordinario.
M06. Gastos extraordinarios y asignaciones entre meses
| ID | Funcionalidad | Qué permite |
|---|---|---|
| F21 | Relación gasto original–cargos al P&L | Un gasto puede tener varios cargos en distintos meses; cada cargo mantiene el vínculo con el original. |
| F22 | Calendario y saldo pendiente | Mostrar total, cargos ya aplicados, cargos previstos y monto aún sin asignar, incluidos pendientes de años anteriores. |
| F23 | Decisiones de Norma | Cargar completo, dividir, aplazar una parcialidad, juntar parcialidades o cambiar el calendario con motivo y vigencia. |
| F24 | Comparación antes de guardar | Mostrar cómo cambia el P&L al aplicar un ajuste. Una simulación no altera el cierre vigente hasta confirmarla. |
| F25 | Control de conservación del monto | Evitar cargos repetidos y asignaciones superiores al gasto; registrar correcciones de forma trazable. |
| F26 | Puente del resultado gerencial | Explicar a José lo registrado originalmente, lo cargado ese mes y lo diferido, sin borrar el movimiento de origen. |
Esta es la funcionalidad central que explicó Norma. El sistema prepara cálculos y seguimiento; ella decide el calendario de esos cargos. Alcance de esa autoridad y qué cambios requieren también aprobación de José: por validar.
M07. Nómina de unidades y corporativo
| ID | Funcionalidad | Qué permite |
|---|---|---|
| F27 | Importación de formatos de nómina | Leer las estructuras semanal/quincenal recibidas, conservar periodo y unidad y detectar empleados fuera de las sumas originales. |
| F28 | Conciliación de nómina | Comparar banco, efectivo, deducciones y totales según el significado acordado de cada campo. Separar neto pagado de otros componentes. |
| F29 | Distribución corporativa | Aplicar la matriz aprobada por persona/grupo y unidad; validar 100%, vigencia y redondeo. |
| F30 | Nómina agregada para el P&L | Generar totales por unidad y concepto autorizado sin mostrar salarios individuales a asistentes. |
| F31 | Cambios de plantilla y matriz | Incorporar altas/bajas y cambios de porcentajes sin duplicar nómina ni recalcular cierres históricos. Mostrar qué unidades y reportes afecta un cambio. |
Base: siete libros y explicación de Norma. La matriz es generalmente fija hasta nueva decisión; no se reemplaza por reparto semanal proporcional a ventas. La automatización no calcula una nómina nueva ni realiza pagos: consolida y comprueba la preparada por RH.
M08. Inventario y consumo
| ID | Funcionalidad | Qué permite |
|---|---|---|
| F32 | Inventarios de apertura y cierre | Vincular conteos/valuaciones con unidad, fecha y rubro; señalar ausencia de un inventario necesario. |
| F33 | Costo consumido | Preparar inventario inicial + compras − inventario final, con ajustes explícitos acordados. Distinguir mercancía de herramientas/equipo. |
| F34 | Indicadores de costo | Comparar costo contra ventas y criterios de cada unidad. Explicar desviaciones y fuentes sin atribuir una causa no demostrada. |
Base: formato de inventario y transcripción. Valuación, impuestos, traslados, devoluciones y mermas: por validar. Los insumos consumidos no se posponen solo por estar pendientes de pago.
M09. Construcción y revisión del P&L
| ID | Funcionalidad | Qué permite |
|---|---|---|
| F35 | P&L desde la base de datos | Calcular ingresos, costos, nómina, grupos de gastos y resultado por unidad/periodo desde registros aceptados y reglas versionadas. La base del sistema es la autoridad; el Excel exportado es una vista del resultado. |
| F36 | Presupuesto separado del real | Comparar presupuesto, acumulado y diferencia sin mezclar columnas en un único total. Disponibilidad de presupuesto y definición de provisiones: por validar. |
| F37 | Indicadores y comparaciones | Ticket por ingresos/clientes del mismo periodo, porcentajes de costo y nómina, margen y resultado; comparación semanal/mensual con cobertura comparable. |
| F38 | Navegación hasta el origen | De una cifra ir a movimientos, fuentes, nómina agregada y ajustes que la componen. |
| F39 | Incorporación de AA | Recibir el reporte externo, mapearlo y mostrar diferencias; su aprobación externa no implica aprobación automática en el sistema. |
Las fórmulas actuales contienen defectos. El sistema debe preservar la presentación y la lógica acordada, calculando con reglas verificadas. El P&L original es evidencia de lo entregado, no una referencia infalible de exactitud.
M10. Revisión, aprobación y exportación
| ID | Funcionalidad | Qué permite |
|---|---|---|
| F40 | Vista de revisión de Norma | Resultado, incidencias, extraordinarios, asignaciones y pendientes juntos; concentrar su atención en decisiones. |
| F41 | Correcciones desde Excel o interfaz | Registrar cambios con identificadores estables y comparación contra la versión vigente. No sincronizar silenciosamente dos copias editables. Modalidad exacta: por validar. |
| F42 | Estados y aprobación | Recibido, pendiente de corrección, listo para revisión, aprobado y publicado. Una importación no publica un cierre por sí sola. |
| F43 | Versiones y reapertura | Preservar lo publicado; una corrección posterior crea revisión con autor, motivo y diferencias. |
| F44 | Salidas para equipo y José | Excel del P&L, reporte de diferencias y resumen ejecutivo con periodo, cobertura, fecha y explicación de extraordinarios. |
Base: sesión pide Excel modificable, controles de guardado e historial. Norma no necesita tocar fórmulas ni posiciones de celdas para cambiar una asignación. Si edita un Excel exportado, el servicio debe recibir y validar sus cambios antes de tratarlos como guardados.
M11. Consulta por asistente y conexión con X-Men
| ID | Funcionalidad | Qué permite |
|---|---|---|
| F45 | Trabajo diario por chat | Entregar archivos/información, pedir una conciliación y consultar qué falta, por qué cambió un gasto o cómo va una semana, con cifras calculadas desde la base y fuentes autorizadas. |
| F46 | Acciones confirmadas desde chat | Proponer clasificación o ajuste, ver su efecto y guardar con recibo; mismas reglas que en Excel/interfaz. |
| F47 | Publicación de Finanzas a X-Men | Registrar cierre aprobado, versión, unidad, periodo, cobertura, bloqueos y decisiones requeridas. |
| F48 | Consulta y decisiones de José | Recuperar el cierre vigente y pendientes; registrar decisiones para que Norma las consulte en su contexto. |
Base: conversación propone conector privado y cerebro compartido. Claude y ChatGPT son interfaces del mismo registro. Hay que comprobar compatibilidad de cuentas y superficies; no se promete un instalador idéntico para ambas. El núcleo conserva permisos y reglas aunque cambie el modelo.
M12. Accesos, historial y operación
| ID | Funcionalidad | Qué permite |
|---|---|---|
| F49 | Permisos por persona y unidad | Separar captura, nómina individual, ventas, ajustes, aprobación y consulta ejecutiva. |
| F50 | Bitácora de decisiones y cambios | Registrar quién cargó, corrigió, aprobó o cambió reglas, qué cambió y cuándo. El historial del servicio no depende de capturar todas las conversaciones del usuario. |
| F51 | Recuperación y trabajos fallidos | Conservar lotes pendientes y recibos; reintentar sin duplicar. Respaldar datos y fuentes necesarias para recuperar cierres. |
| F52 | Feedback operativo | Mostrar trabajos terminados/fallidos y pendientes al usuario adecuado. Chat/interfaz es el canal inicial; avisos por WhatsApp o correo requieren un alcance adicional acordado. |
Auditar cambios en la base del sistema es parte del desarrollo. Atribuir cada edición previa en OneDrive depende del historial disponible y acceso a Microsoft; no se da por resuelto con la importación de un archivo.
06Cómo trabajaremos: FDE
FDE — ingeniería de campo con IA— es nuestro servicio de desarrollo junto al equipo. Asignamos una persona responsable de implementación que trabaja con José, Norma y sus equipos: entiende los casos reales, construye el sistema, acompaña las pruebas y convierte las correcciones en reglas aceptadas.
Con José partimos del CEO Office y sus conexiones con los gerentes para definir el cerebro, sus ámbitos y su autoridad. Con Norma aprovechamos el entendimiento ya realizado y trabajamos con quienes capturan, preparan nómina y revisan las fuentes para llevar esa lógica al flujo híbrido de Excel y chat.
- Sesión con Norma
- Reglas y relaciones
- Desarrollo y pruebas
- Validación en operación
- Correcciones aceptadas
El cerebro incluye el modelo de negocio: entidades, unidades, periodos, gastos, pagos, asignaciones, responsables y decisiones. Los cálculos y restricciones se codifican; el agente interpreta, relaciona y propone dentro de ese modelo.
| Quién | Responsabilidad |
|---|---|
| HEYAY LABS / Adolfo | Dirigir el desarrollo, modelar datos y reglas, construir conectores, probar y documentar las entregas. |
| Responsable FDE de HEYAY LABS | Trabajar directamente con el equipo, levantar casos y dudas, implementar y acompañar pruebas y ajustes; persona asignada al arranque. |
| Norma | Validar la lógica, resolver excepciones y aceptar el proceso de revisión y cierre. |
| Responsable de carga y equipos fuente | Entregar el periodo completo y corregir incidencias de su ámbito; designación pendiente. |
| José | Elegir prioridad y marca piloto, acordar autoridad y límites de información y aceptar el alcance de la etapa. |
Trabajaremos durante dos meses: el primero para desarrollo y el segundo para pruebas y ajustes con Norma y su equipo, con revisión semanal y cuatro ciclos quincenales. En cada revisión se demuestra lo construido y se registra qué fue aceptado, qué falta y qué cambió.
Rolling Host conserva datos, reglas, documentación y configuración del núcleo. La entrega incluye material para personas y agentes, pruebas de casos validados por Norma y un procedimiento para incorporar nuevas correcciones. Propiedad y transferencia del código se precisan en el acuerdo de servicios.
07Ruta y aceptación
| Etapa | Entrega | Cómo se acepta |
|---|---|---|
| Semana 1 · Reglas y base | Unidad y periodo, fuentes, matriz y roles; prueba de copy-paste/Excel y revisión de APIs de sistemas terceros para priorizar conexiones. | Norma valida los casos; José acuerda prioridad y límites de acceso. |
| Semana 2 · Cierre histórico | Validaciones, pagos, asignaciones, nómina, primera versión del P&L y vistas iniciales de la aplicación web. | Se compara el mes histórico; cada diferencia y cifra lleva a su origen. |
| Semana 3 · Cerebro y conectores | Estado, autoridad, evidencia y herramientas de consulta/publicación para los equipos del piloto. | Norma y José consultan el mismo registro autorizado desde las cuentas habilitadas. |
| Semana 4 · Versión para pruebas | Flujo híbrido, aplicación web con edición y dashboards principales, MCP, cerebro y bitácora integrados, con documentación inicial. | El equipo dispone de una versión funcional para comenzar las pruebas del segundo mes. |
| Mes 2 · Pruebas y ajustes | Pruebas con los datos reales disponibles, revisión de incidencias, ajustes al flujo acordado y documentación final. | Norma revisa/publica, José consulta el cierre autorizado y el equipo recibe el procedimiento para operar. |
Los dos meses se cuentan desde el arranque acordado y la disponibilidad de fuentes y accesos del piloto. Se fijan las fechas de inicio, paso a pruebas y cierre en la reunión de arranque. Si el cierre nuevo aún no coincide con ese calendario, validaremos su recorrido con los datos disponibles y registraremos lo pendiente.
La aceptación incluye recargas sin duplicados, conservación de saldos, cambios que no reescriben cierres aprobados y pruebas de acceso entre entidades. La compatibilidad con Claude y ChatGPT se comprueba en las cuentas reales, incluyendo recepción de archivos y acciones autorizadas.
Mediremos tiempo de preparación y revisión, incidencias, cobertura de fuentes y capacidad de Norma para revisar, corregir y publicar. La solicitud de José de avanzar en su dominio del agente se traduce en tareas observables; no se afirma un porcentaje de dominio o ahorro ya obtenido.
08Inversión y forma de pago
Dos meses de trabajo: desarrollar el sistema financiero de Norma y el cerebro con sus conectores, probarlo con el equipo y ajustar el flujo acordado.
Inversión total · MXN
$75,000
Mes 1: desarrollo · Mes 2: pruebas y ajustes incluidos
- Pago 1
Mes 1 · primera quincena - $18,750
- Pago 2
Mes 1 · segunda quincena - $18,750
- Pago 3
Mes 2 · primera quincena - $18,750
- Pago 4
Mes 2 · segunda quincena - $18,750
Cuatro pagos quincenales durante los dos meses para facilitar el flujo de pago de Rolling Host. Las fechas se fijan con el arranque.
Incluye desarrollo, pruebas y ajustes del flujo híbrido de Norma, base de datos y bitácora, aplicación web para consulta, edición autorizada y dashboards financieros principales, servidor MCP para acceso mediante agentes, revisión del P&L, núcleo de conocimiento, hechos, evidencia, estado y autoridad, y conectores para los equipos del piloto.
El núcleo queda preparado para incorporar otras áreas. La primera implementación conecta captura y fuentes de Finanzas, revisión de Norma y consulta de José; los procesos propios de Carlos, Rafa y otras áreas se priorizan después.
Licencias, consumo de modelos, infraestructura y acompañamiento posterior a los dos meses se acuerdan por separado.
09Qué sigue para arrancar
Confirmar con Norma y José el piloto y la fecha de inicio: un mes de desarrollo seguido de un mes de pruebas y ajustes. La inversión total es de $75,000 MXN, distribuida en cuatro pagos quincenales de $18,750 MXN durante los dos meses para facilitar su flujo de pago.
| Acuerdo o insumo | Qué falta concretar |
|---|---|
| Unidad y periodo | Seleccionar una marca con mes cerrado completo. Jamaica es candidata; la elección sigue abierta. |
| Fuentes completas | Corte y P&L entregado, nóminas, matriz corporativa vigente, inventarios inicial/final y exportaciones acordadas del mismo periodo. |
| Autoridad y acceso | Quién carga, quién corrige, quién aprueba cada ajuste y qué puede consultar cada persona por entidad legal. |
| Conector y operación | Cuentas del chat, mecanismo de entrega de archivos, accesos a fuentes y cuentas de infraestructura de Rolling Host. |
| Sistemas terceros | Identificar POS y demás sistemas a conectar; comprobar API, documentación, accesos, datos y alcance de las integraciones seleccionadas. |
| Equipo y confidencialidad | Identificar a quienes implementarán y formalizar el NDA para nuevos terceros, conforme a lo solicitado por José. |
| Arranque y pagos | Acordar las fechas de desarrollo, pruebas y cierre, y los cuatro pagos quincenales durante los dos meses. |
El diagnóstico documentado es la base de la propuesta de trabajo, conforme al correo del 1 de junio. La propuesta pasa ahora a construcción, con alcance, entregas e inversión definidos para estos dos meses.