Files

T

Johann bee2d02f50 Documenta semana 24-27 jul: validación de prototipo (aprobada), API de Jira y avance de Etapa 1

- REGISTRO #55: validación del prototipo Etapa 0 (24-jul) APROBADA; único bloqueo = definir el flujo de facturación en Jira (sesión propuesta por Araceli para el martes 28)
- REGISTRO #56: sesión de API de Jira con Pedro (27-jul) — token PAF a 1 año, bandeja FAC; + seguimiento por correo del mismo día con los límites de velocidad (65k puntos/h, burst/s, por-issue) y entrega del token por Google Drive
- REGISTRO #57: hilo de WhatsApp con Erika (21-27 jul) — coordinación, envío del flujo por correo y reagenda 23→24 jul; 3 imágenes inferidas
- Transcripciones y correo en fuentes/; guion de validación en planeacion/
- Avance-Etapa1-2026-07-27 (nota + mensaje para Erika) y Excel del corte del 27-jul (núcleo verificado; capa de escritura en pausa por definición de Balam)
- Seguimiento-horas: sesiones del 24-jul (validación) y 27-jul (API Jira)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-27 08:18:08 -06:00

119 KiB

Raw Blame History

REGISTRO · Bitácora de comunicaciones — Proyecto Balam

Log cronológico de toda comunicación del proyecto (correos, llamadas, mensajes). Es la fuente de la verdad del "qué se dijo y cuándo". Convención y plantillas para registrar en README.md. Material crudo (transcripciones, .eml, PRD) en ../fuentes/.

Hilo de correo principal: "Re: Solicitud de cotización – PRD" Participantes:

Johann (proveedor) — johann_antonio85@hotmail.com
Noe Rocha — CTO, Balam — noe.rocha@balamtalentoestrategico.com
Araceli Sanchez Jimenez ("Ara") — Balam — araceli.sanchez@balamtalentoestrategico.com
Erika Chavez — Project Manager, Balam — erika.chavez@balamtalentoestrategico.com · WhatsApp +52 1 81 2353 5803
Pedro Alberto Ayala Elizondo — Desarrollador / contacto técnico, Balam — pedro.ayala@balamtalentoestrategico.com
Paola — Recursos Humanos, Balam — coordinó la firma del contrato (WhatsApp)

Periodo: 30 abr 2026 → 22 jul 2026 (última actualización: sesión de reglas Etapa 1 — alta de clientes, fee y flujo Jira, 22-jul) Orden: cronológico (más antiguo arriba)

1 · Apr 30, 2026 — 4:38 PM · Erika Chavez → Johann

Asunto: Solicitud de cotización – PRD CC: Noe Rocha, Araceli Sanchez

Buenas tardes,

Espero que se encuentren muy bien. Mi nombre es Erika Chávez, Project Manager en Balam. Es un gusto saludarte, Johann.

Por medio de este medio, te comparto el PRD con la finalidad de solicitar tu apoyo en la elaboración de la cotización correspondiente.

Quedo atenta a cualquier duda o comentario.

Saludos.

2 · May 4, 2026 — 3:30 PM · Johann → Erika (CC Noe, Ara)

Buenos días Araceli,

Gracias por compartir el PRD, ya lo revisé a detalle durante el fin de semana. El alcance está muy claro y bien estructurado.

Para preparar la propuesta técnica con una estimación precisa por fase, me surgen las siguientes preguntas:

Integraciones

¿BIND ERP tiene API habilitada o se trabaja con exportación de archivos?
¿BUK expone API para consultar nómina procesada?
¿Los 3 bancos entregan estados de cuenta por API, archivos (CSV/OFX) o PDFs?
¿Cuál es el banco americano que manejan?
¿Pueden dar acceso a ambientes sandbox de BIND y BUK para desarrollo, o solo cuentan con producción?

Facturación

¿Ya cuentan con un PAC contratado para timbrado CFDI? ¿Cuál?
La facturación a clientes en Texas, ¿es invoice estándar o requiere tax compliance específico?
El PRD menciona soporte para EUR en RF-02, pero la regla de facturación internacional refiere solo a USD. ¿Confirman que el MVP debe incluir EUR, o lo dejamos preparado para una fase posterior?

Cobranza

El PRD indica que ACUNTIA y los "top 3 clientes" no deben recibir recordatorios automáticos. ¿Quiénes son esos top 3? ¿Es una lista fija o configurable?
Se menciona el uso de tickets físicos en pagos con tarjeta como problema actual. ¿Esto se refiere a pagos con terminal donde el registro es manual?

Datos y sistemas

¿"Book" es un sistema interno? ¿Cuenta con API o base de datos accesible?
¿Jira se usa únicamente para gestión de proyectos o también como fuente de datos de clientes/colaboradores?

Operación

¿Aproximadamente cuántos colaboradores tienen en nómina y cuántas facturas emiten al mes?
¿Quién sería el contacto operativo para validar reglas de negocio durante el desarrollo?

Infraestructura y diseño

¿Tienen servidor o nube preferida para hospedar la plataforma, o propongo opciones?
¿Cuentan con guía de marca / assets (logo, colores, tipografía) para la plataforma, o se diseña desde cero?

Con estas respuestas puedo tener la propuesta lista en 24–48 horas. Si prefieren, podemos agendar una sesión corta de 20–30 minutos para revisarlas en conjunto.

3 · May 4, 2026 — 7:59 PM · Noe Rocha → Johann (respuestas inline)

Hola Johan, te paso los comentarios más abajo de lo que sé; algunos los tengo que investigar y otros los puede responder o aclarar Ara (TBD Ara).

Pregunta	Respuesta de Noe
¿BIND ERP tiene API habilitada?	Exportación de archivos
¿BUK expone API?	No hasta donde sabemos
¿Estados de cuenta de los 3 bancos?	PDFs
¿Cuál es el banco americano?	TBD Ara
¿Sandbox de BIND y BUK?	Solo producción
¿PAC contratado para CFDI?	Integrado en el mismo sistema de BIND (hasta donde sabe)
¿Facturación a Texas, tax compliance?	TBD Ara
¿EUR en MVP?	Dejarlo preparado para fase posterior. Por el momento solo USD con empresas europeas
¿Quiénes son ACUNTIA + top 3, lista fija o configurable?	Lista configurable de acuerdo al objetivo de negocio
¿Tickets físicos en pagos con tarjeta?	TBD Ara
¿"Book" es interno?, ¿API?	Es un SaaS
¿Jira para qué se usa?	Gestión de proyectos y servicios solamente con clientes
¿Cuántos colaboradores y facturas/mes?	45 colaboradores + 5 proveedores tipo freelancer
¿Contacto operativo durante desarrollo?	Un servidor (Noe) y el gerente administrativo
¿Nube preferida?	Preferentemente Azure; si hay mejor costo-beneficio, abiertos a evaluar
¿Guía de marca / assets?	TBD Ara

3a · May 6, 2026 — Araceli Sánchez → Johann · respuestas "en verde"

Asunto: Re: Solicitud de cotización – PRD (Fuente: lista del hilo de Outlook. Su contenido íntegro no consta en el .eml disponible — ver aviso.)

"Te respondo en verde. Gracias, Saludos." Araceli responde los puntos que Noe dejó marcados TBD Ara el 4-may: (1) banco americano, (2) tax compliance para clientes en Texas, (3) tickets físicos en pagos con tarjeta, (4) guía de marca / assets.

⚠️ Evidencia pendiente: el texto exacto de las respuestas "en verde" no está en el .eml disponible (capturado el 3-jun, donde esos 4 puntos aún figuran resaltados en amarillo como "TBD Ara", sin responder). Acción: recuperar el correo verde original para transcribir las respuestas aquí. El Resumen ejecutivo infiere banco = IBC Bank Texas y tax = estándar a partir de la llamada del 19-may; falta confirmar la atribución a este correo.

3b · May 6, 2026 — Johann → Balam · acuse

Asunto: Re: Solicitud de cotización – PRD (Fuente: lista del hilo de Outlook.)

"Muchas gracias por sus comentarios. Los incorporo a la propuesta y se las comparto a la brevedad." Johann acusa recibo de las respuestas (Noe inline + Araceli en verde) y anuncia que las incorpora a la propuesta.

4 · May 8, 2026 — 5:06 PM · Johann → Noe

Hola Noe,

Antes de compartirles la propuesta técnica final, me gustaría agendar una sesión contigo para revisar algunos puntos que impactan directamente el alcance:

Dashboards: ¿Qué campos e indicadores necesitan visualizar por módulo (facturación, cobranza, conciliación)? Quiero asegurarme de que el diseño refleje exactamente lo que el equipo de finanzas y dirección necesita ver.
Mapa técnico de datos: Sería muy útil que en la llamada me pudieras mostrar los sistemas desde donde sacaremos la información — qué sale de BUK, qué está en BIND, qué está en Book y cómo interactúan hoy. Esto me ayudará a dimensionar mejor la parte de integración y asegurar que no haya sorpresas durante el desarrollo.
Acceso a bancos: Si en algún punto se busca integración vía API bancaria, conviene definirlo desde ahora para contemplarlo en el alcance desde el inicio.

¿Tienes disponibilidad para una sesión de 30–45 minutos?

5 · May 11, 2026 — 5:47 PM · Noe → Johann

Hola Johan,

Te paso opciones para una reunión:

Miércoles de 7am a 8am, 6pm a 7pm
Jueves de 7am a 8am

Te doy opciones muy temprano o muy tarde para que se te acomode en tu horario. Si hay tiempo para ti de verlo en horarios intermedios nos podemos adecuar.

6 · May 12, 2026 — 10:27 PM · Johann → Noe

Hola Noe,

Jueves de 7-8am me parece bien.

Saludos.

7 · May 16, 2026 — 10:32 AM · Noe → Johann

Buenos días Johan,

¿Podemos tener la sesión este martes? O bien, si es algo de una llamada, ¿a qué número te podría marcar?

(Implícita: la llamada se sostuvo el martes 19 de mayo de 2026 — transcripción en ../fuentes/2026-05-19 - Transcript - Solicitud de cotizacion.txt.)

7a · May 16, 2026 — Johann → Noe · confirma sesión + comparte teléfono

Asunto: Re: Solicitud de cotización – PRD (Fuente: lista del hilo de Outlook.)

"Buen día Noe, claro, este martes podemos tener sesión. Cualquier cosa te comparto mi número: 8131610998. Saludos." (La sesión se sostuvo el martes 19-may; ver #7.)

8 · May 25, 2026 — 10:41 PM · Noe → Johann

Hola Johann,

En el caso de Bind tiene una API que veo factible que podamos usar para nuestra necesidad:

Como dato tiene un límite de 20 mil solicitudes diarias, no sé si es poco o mucho para nuestra necesidad, pero hay que tomarlo en cuenta.

Como nuestro primer interés es el tema de facturación, considero que la propuesta sería primero solo considerando el sistema ERP Bind.

Saludos.

9 · May 27, 2026 — AM · Pedro (desarrollador, Balam) → Johann ⭐ (último mensaje)

Buenos días Johan,

Espero te encuentres bien. Quiero compartirte una actualización respecto a nuestra plataforma BUK: confirmamos que sí cuenta con soporte API para integraciones con herramientas externas. Puedes consultar la documentación disponible en el siguiente enlace.

(Nota: el link al API no se incluyó en el mensaje recibido; pendiente solicitarlo en la respuesta.)

Aunque esta integración no es prioridad en este momento, queremos que cuentes con esta información para que puedas preparar una propuesta cuando sea oportuno avanzar con el tema.

En cuanto tengamos mayor claridad sobre los tiempos, te los haremos saber.

¡Saludos!

Lectura estratégica:

Pedro está ejecutando lo que Noe le pidió en la llamada del 19-may (acelerar con BUK / Book / proveedores).

No cambia el alcance del MVP — BUK sigue siendo Fase 2 post-MVP.

Sí confirma viabilidad técnica del ciclo end-to-end Jira → BUK → Plataforma → BIND para Fase 2.

Pedro perfila como contacto técnico día a día durante el proyecto (responde la pregunta abierta del checklist).

10 · May 29, 2026 — 2:44 PM · Johann → Noe (CC Ara, Erika, Pedro) · envío de la propuesta

Asunto: Re: Solicitud de cotización – PRD Evidencia: hilo ../fuentes/RE_ Solicitud de cotización – PRD (1).eml (en este punto Pedro ya aparece en CC). Adjunta la propuesta v1.0 en PDF. El cuerpo del correo ("Adjunto la propuesta para la plataforma de automatización financiera que conversamos…") consta dentro del .eml.

Envío de la propuesta v1.0 en PDF (Propuesta-Balam.pdf). MVP BIND-first enfocado en facturación: consulta + emisión asistida de facturas MXN/USD vía API de BIND (con dry-run + confirmación humana; timbra el PAC de BIND), cobranza operativa (aging, alertas internas, lista blanca ACUNTIA + Top 3), dashboard, reportes y bitácora. Inversión $67,200 – $81,600 MXN + IVA, 6–7 semanas, anticipo de 30 h ($18,000 + IVA) para Discovery. Módulos diferidos (conciliación, Stripe, recordatorios a clientes, asientos, BUK) cotizados de forma indicativa en el Anexo B.

11 · Jun 2, 2026 — 5:33 PM · Pedro → Johann, Noe (CC Ara, Erika)

Asunto: RE: Solicitud de cotización – PRD

"Buenas tardes, Johan. Gracias por compartir la propuesta. @Noe Rocha y yo la hemos revisado y tenemos varios comentarios que nos gustaría compartir contigo directamente en una sesión conjunta. ¿Nos podrías compartir tu disponibilidad para mañana por la tarde, o tu horario de preferencia para el jueves 4 de junio?"

12 · Jun 2, 2026 — 9:39 PM · Johann → Pedro, Noe (CC Ara, Erika)

"Buen día, Pedro: Claro que sí, con gusto. Me funcionaría mejor el jueves 4 de junio a las 7:00 am para revisar los comentarios juntos. Si a esa hora no l[es funciona]…" (vista previa)

13 · Jun 3, 2026 · Pedro → Johann, Noe (confirmación + liga Teams)

"Buenos días, Johan. Te agendo para el día de mañana a las 7 am. Te comparto el link de la sesión. Reunión de Microsoft Teams — Unirse: https://teams.microsoft.com/meet/22…" (vista previa)

Queda confirmada la sesión: jueves 4-jun, 7:00 am, por Microsoft Teams.

14 · Jun 4, 2026 — 7:00 AM · Llamada de revisión de propuesta ⭐

Participan: Noe, Pedro, Erika y Johann. Transcripción completa en ../fuentes/2026-06-04 - Transcript - Revision de propuesta.txt.

Veredicto general: "En términos generales, la propuesta está bien." El proyecto avanza; hay puntos a negociar/ajustar antes de formalizar.

Acuerdos y decisiones:

Anticipo $18,000 (Discovery): APROBADO. Arrancan con eso; el monto final del MVP se aclara tras Discovery (Noe entiende que el rango $67.2K–$81.6K depende de lo que se encuentre).
Conciliación: Noe la quiere incluir (hoy es 100% manual y ya es un problema real). Vio que está cotizada en el Anexo B (~$48–63K). Condicional al flujo: si facturación queda en ~$67K pediría conciliación de inmediato; si sube a $81.6K, evaluará tiempos/flujo en las próximas semanas. Enfoque platicado: estados de cuenta PDF → extracción (librerías/OCR/IA) → matching por algoritmo (~98%) usando la API de BIND para las facturas. Involucrar a Arturo (bancos).
Dashboard/reporteo: posible recorte. Balam ya tiene un tablero Power BI (hecho por Pedro) que resuelve antigüedad de cartera; Noe no quiere pagar por lo que ya tienen. Sí quiere el módulo de cobranza + alertas internas (que el tablero no ejecuta). Validar con Pedro qué del dashboard es redundante.
Lista blanca: confirmado que es configurable, no limitada a 3.
Soporte/mantenimiento: a Noe no le gusta la caducidad de horas a 30 días ("úsalo o lo pierdes"); pide negociar mayor vigencia. Johann: negociable.
API BIND: Pedro hoy usa la llave de Araceli para el Power BI; para desarrollo se usará otra (de Arturo, mismos permisos). BIND parece permitir 1 API key por usuario (Pedro confirmará); generarlas desde la cuenta maestra (ARA) y documentar cuál es para qué.
Azure: se gestiona con Guajardo / Erika. Johann requiere permisos para crear App Service + PostgreSQL (no Global Admin).
Manual de marca: existe (paleta, tipografía, logos); Pedro lo envía.
Reglas de negocio: se definen con Arturo + Pedro.
Metodología IA: aclarado = no se entrenan modelos con datos de Balam. Noe OK.
Pagos: anticipo a 7 días OK; avances a 30 días (Balam cobra a sus clientes a 60–120 días; 30 es el mínimo negociado). Johann aceptó.
Gestión del proyecto: en Jira (estilo ágil/Yael, no Gantt). Pedro crea el espacio (plan free); Erika valida entregables para el pago.
Comunicación: canal de WhatsApp + correo para evidencia formal. Erika = contacto principal · Pedro = técnico · Arturo = negocio.
Fiscal (Johann): en proceso de cambiar régimen (24 h); confirma que sí puede facturar.
Inicio: Johann puede empezar cuanto antes, de preferencia inicio de semana para coordinar con Arturo.

Próximos pasos definidos en la llamada:

Noe formaliza por correo a partir del 5-jun: solicita factura de anticipo, envía info/accesos y los ajustes a la propuesta para arrancar.
Johann: cambiar régimen fiscal (24 h), emitir factura de anticipo, preparar Discovery.
Pedro: enviar manual de marca; revisar llaves API (cuántas por usuario, generar desde ARA); crear proyecto en Jira.
Pendiente con Arturo: reglas de negocio + acceso a bancos (conciliación).
Azure: gestionar con Guajardo/Erika.

15 · Jun 8, 2026 — 6:15 PM · Correo · Noe → Johann (CC Ara, Erika, Pedro) · aclaraciones y preguntas

Evidencia: ../fuentes/2026-06-08 - Correo - Noe aclaraciones y preguntas.md. Re-adjunta Propuesta-Balam.pdf.

Noe formaliza por escrito 4 aclaraciones/ajustes y 3 preguntas, antes de avanzar:

Ajustes solicitados:

La inversión final del módulo de facturación queda supeditada al Discovery (112 vs 136 h, 6–7 sem). — De acuerdo, así estaba planteado.
Soporte: el límite de consumo mensual es limitante; piden bolsa de horas vigente 12 meses (paquetes por hora, no mensualidad con caducidad).
Garantía: piden 45 días (no 30) — el ciclo financiero es mensual y los defectos no se ven hasta pasado el cierre.
Sin anticipos (política Balam) y pago estricto a 30 días post-factura. Proponen: Johann factura las 30 h de la Etapa 0 y se programa el pago a 30 días.

Preguntas:

¿Qué pasa si el Discovery revela que la API de BIND no soporta la escritura/emisión esperada?
Si el Discovery reduce horas, ¿se puede adelantar algo de conciliación?
Sin sandbox, ¿qué garantías concretas contra una emisión errónea con efecto fiscal? ¿Hay reversa/cancelación contemplada?

Acción Johann: responder el correo (respuestas + postura comercial) y reflejar los cambios en la propuesta v1.1. Decisión clave: aceptar el esquema sin anticipo / pago a 30 días (impacto en flujo). Ver PENDIENTES.md.

16 · Jun 10, 2026 — 6:11 PM · Johann → Noe (CC Ara, Erika, Pedro) · respuesta + propuesta v1.1

Asunto: RE: Solicitud de cotización – PRD CC: Araceli Sánchez, Erika Chávez, Pedro Ayala Evidencia: ../fuentes/2026-06-10 - Correo - Johann respuesta v1.1.md. Adjunta Propuesta-Balam.pdf (v1.1).

Johann responde el correo del 8-jun, acepta los 4 ajustes y contesta las 3 preguntas técnicas; reenvía la propuesta v1.1.

Respuesta a los ajustes:

Inversión del módulo de facturación: de acuerdo, se confirma con el Discovery (112–136 h, 6–7 semanas).
Soporte: de acuerdo. Replanteado como bolsa de horas a $600/h + IVA, vigencia 12 meses desde su contratación, sin caducidad mensual.
Garantía: de acuerdo, 45 días (cubre el primer cierre mensual).
Sin anticipo / pago a 30 días: de acuerdo. Factura las 30 h de la Etapa 0 al inicio y el pago corre a 30 días, igual que los avances. Única condición: dejar firmado el contrato/orden de trabajo antes de iniciar (la firma formaliza el compromiso y le permite arrancar de inmediato).

Respuesta a las preguntas:

Si BIND no soporta escritura/emisión: es lo que el Discovery valida antes de construir. Si no es viable o implica riesgo, la facturación se entrega en modo asistido (la plataforma prepara y valida; la emisión final se confirma en BIND) y se reajusta el alcance del módulo. No se invierte en construir algo que no funcione.
Si el Discovery reduce horas: sí, la capacidad liberada puede arrancar un primer alcance de conciliación, con mini-scope y estimación al cierre del Discovery.
Garantías sin sandbox / reversa: la emisión tiene cinco candados — lectura primero, validación en Discovery, dry-run antes de cada emisión, confirmación humana obligatoria por factura y feature flag apagado por defecto. La plataforma no auto-emite; el timbrado lo hace el PAC de BIND. La cancelación de un CFDI corre por el proceso fiscal BIND/SAT (con su ventana de aceptación); la plataforma puede disparar/registrar esa solicitud vía API de BIND si la soporta — a confirmar en Discovery.

Lectura estratégica:

Johann cede en lo comercial (sin anticipo, 30 días, 45 días garantía, soporte 12 meses) pero fija un candado propio: firma del contrato antes de arrancar, que sustituye al anticipo como mecanismo de compromiso. Es el punto a vigilar.

Las 3 respuestas técnicas desactivan los riesgos que Noe planteó sin ampliar alcance: el Discovery sigue siendo la red de seguridad.

La conciliación queda explícitamente condicionada a horas liberadas por el Discovery — coherente con lo que Noe pidió el 4-jun.

17 · Jun 16, 2026 — 3:35 PM · Noe → Johann, Pedro (CC Ara, Erika) · luz verde ⭐

Asunto: Solicitud de cotización – PRD CC: Araceli Sánchez, Erika Chávez Evidencia: ../fuentes/2026-06-16 - Correo - Noe luz verde y documento de firma.md. Adjunto: Outlook-p2vlyjhm (50 KB). (Hora 3:35 PM tomada de la captura del correo.)

Balam da luz verde a los términos de la v1.1. Noe confirma:

"Estamos de acuerdo con lo que se definió." Balam ya está redactando el documento para firmar estos acuerdos.
Pide a Johann esperar a que le envíen todo para los siguientes pasos (queda en hold del lado del proveedor).
Instruye a Pedro a armar el tablero de seguimiento en JIRA y revisarlo con Erika para el seguimiento del proyecto de desarrollo, "para ir preparando el camino".

Lectura estratégica:

Hito comercial: el cliente acepta formalmente la propuesta v1.1. El proyecto pasa de "negociación" a "preparación de firma".

La pelota está del lado de Balam: redactar el documento de firma. Johann debe revisarlo cuando llegue (verificar que recoja: sin anticipo + firma previa, 30 días de pago, 45 días de garantía, soporte bolsa 12 meses, alcance MVP BIND-first y el condicionante de Discovery) antes de firmar.

Se activa el tablero Jira (Pedro + Erika), tal como se acordó el 4-jun — primer paso operativo real.

No hay accesos ni fecha de arranque todavía: el Discovery no inicia hasta que llegue el documento firmado + los accesos.

18 · Jun 25, 2026 — Balam (vía Paola, RH) → Johann · contrato de servicios para firma

Evidencia: ../fuentes/2026-06-26 - WhatsApp - Paola (RH) ajustes y firma de contrato.md. Contrato: ../propuesta/2026_06-25_12-13__Contrato_de_servicios_profesionales__Johann_Joseph_Velazquez_Antonio.pdf.

Balam envía el Contrato de Prestación de Servicios Profesionales (PDF) para firma, coordinado por Paola (Recursos Humanos) vía WhatsApp. Es el "documento de firma" que Noe anunció el 16-jun (#17). Recoge los términos v1.1: sin anticipo, pago a 30 días, garantía 45 días, alcance MVP BIND-first, firma como condición de arranque, propiedad intelectual de Balam, y facturación semanal (viernes) por horas trabajadas. Johann pide corregir su segundo nombre ("Josep" → "Joseph"); Paola corrige.

19 · Jun 26, 2026 — WhatsApp Johann ↔ Paola (RH) · ajustes finales y FIRMA del contrato ⭐

Evidencia: ../fuentes/2026-06-26 - WhatsApp - Paola (RH) ajustes y firma de contrato.md. Contrato firmado: ../propuesta/2026_06-26_14-19__Contrato_de_servicios_profesionales__Johann_Joseph_Velazquez_Antonio.pdf.

Johann revisa el contrato a detalle y plantea observaciones por WhatsApp. Balam acepta 2 ajustes y los agrega (nueva cláusula "Terminación anticipada, pago de servicios y aceptación de entregables"):

Pago al terminar: en terminación anticipada se pagan las horas efectivamente trabajadas hasta la fecha.
Aceptación de entregables: se dan por aceptados si no hay comentarios por escrito en 10 días naturales; correcciones limitadas al alcance pactado.

Correcciones aplicadas: firmas → "EL CLIENTE / EL PRESTADOR DE SERVICIOS" (se quitó "TRABAJADOR"); se eliminó el párrafo "Para constancia" duplicado.

Johann FIRMA el contrato (firma electrónica, 26-jun 14:48, RFC VEAJ031228MD6).

Lectura estratégica:

Cierre formal del cierre comercial. El proyecto queda contratado; falta que Balam entregue los accesos para arrancar.

Residuo (bajo riesgo): la cláusula "Firma Electrónica" de la última página quedó duplicada y aún dice "EL PATRÓN" (residuo de plantilla). Opcional pedir copia limpia; el resto del contrato define bien a las partes y declara que no hay relación laboral.

Términos NO incluidos (Johann decidió no insistir): tope/límite de responsabilidad, rescisión recíproca, metodología IA, "lugar de servicios", bolsa de horas 12 meses.

Facturación semanal (viernes) por horas + 30 días — distinto del "por etapa" de la propuesta; es lo vinculante.

20 · Jun 29, 2026 — WhatsApp Erika → Johann · arranque del plan de actividades ⭐

Evidencia: ../fuentes/2026-06-29 - WhatsApp - Erika arranque del plan de actividades.md.

Erika (PM, contacto principal) confirma que ya pasaron los temas administrativos internos de Balam y arranca la coordinación de ejecución. Pide a Johann un listado de actividades con fechas (Excel) por etapas (como en la propuesta), empezando por Etapa 0 y 1: actividad · fecha inicio–fin · responsable, alineado a los entregables, indicando dónde requiere apoyo de Balam. Ofrece llamada de 5 min.

Lectura estratégica:

El proyecto entra en fase de ejecución / kickoff.

Acción de Johann: preparar el Excel de actividades (Etapa 0 y 1) y proponer sesiones de Discovery (conocer el proceso actual + encaminar el prototipo) — parte de la Etapa 0; el contrato ya obliga a Balam a dar disponibilidad de interlocutores.

Sigue pendiente que Balam entregue los accesos (API BIND, Azure, manual de marca, reglas con Arturo).

21 · Jun 29–30, 2026 — WhatsApp Johann ↔ Erika · plan de actividades entregado + kickoff agendado ⭐

Evidencia: ../fuentes/2026-06-29 - WhatsApp - Erika arranque del plan de actividades.md. Plan vigente consolidado: ../planeacion/Plan-actividades-avance-2026-07-10-ajustado.xlsx (+ .md).

Johann entrega el plan de actividades (Excel sencillo: actividad · fecha inicio–fin · responsable · apoyo de Balam): primero Etapa 0 y 1 (29-jun) y luego enviado completo, las 4 etapas (0–3) con fechas tentativas (30-jun, 12:34). Las sesiones quedan ubicadas por etapa; la Etapa 0–1 se mantiene idéntica a lo enviado el 29-jun.
Erika confirma que será la intermediaria de todas las sesiones ("lo que necesites me lo pides y yo coordino agendas").
Kickoff con el Ing. Noé CONFIRMADO: miércoles 1-jul, 7:00 am.
Erika está montando el tablero Kanban en Jira para el seguimiento (mide avance por %).

Lectura estratégica:

Arranca la operación: el 1-jul es el kickoff. Etapa 0 (ejecución) planeada para la semana del 6-jul, condicionada a accesos.

Erika como punto único de coordinación de sesiones simplifica la logística (Johann define qué necesita; ella agenda con la persona correcta).

Bloqueador vivo: accesos de Balam (API BIND, Azure, manual de marca, reglas con Arturo).

22 · Jul 1, 2026 — 7:00 AM · Llamada · Kickoff del proyecto ⭐

Participan: Noe Rocha, Pedro Ayala, Erika Chávez y Johann. Canal: Microsoft Teams. Evidencia: ../fuentes/2026-07-01 - Transcript - Kick off-Proyecto integración Balam.txt.

Resumen: Arranque formal del MVP. Noé fija la expectativa (plataforma robusta en menos de 6 meses, con posible integración futura de CRM — "vámonos por partes"). Revisan el GANTT por etapas, el detalle de accesos, la mecánica de horas en Jira y —el punto más largo— cómo vincular la factura de la Etapa 0 con el documento contractual.

Acuerdos / decisiones:

API BIND (token): solo Ara y Arturo tienen usuario en BIND; se acordó que los tokens salgan de la cuenta mayor (todos los permisos habilitados). Para desarrollo se usará el token de Arturo (aún sin usar), dejando el de Ara para los tableros Power BI. BIND = 1 token por usuario, no caducable ni múltiple. Se probará primero el token de Arturo para confirmar que expone todo lo necesario. Entendimiento: es de pura consulta (invoices, facturas, pagos); esta etapa es solo visualización, sin edición.
Manual de marca: Pedro lo envía hoy por correo (paquete de branding). → cumplido, ver #23.
Repositorio: lo crea Balam / Pedro (GitHub privado) para montar backend/frontend en Fase 1–2. (Antes se preveía que lo montara Johann; ahora lo provee Balam.)
Azure: lo gestionan Pedro + Noé (Noé otorga permisos donde Pedro tiene limitantes).
Discovery / proceso actual: sesión sí o sí con Arturo y Araceli (Araceli conoce mejor el proceso; Arturo lleva 3 meses y aún no define todo). Erika la coordina (pedirá horas disponibles del equipo).
Horas / Jira: Johann reportará sus horas en Jira igual que los demás consultores, subiendo incluso material informativo para transparencia. Pedro le enseñará el flujo. Erika hace el corte los lunes y reporta a dirección al cierre de semana.
Facturación Etapa 0 = 30 h (tema abierto): se confirma el monto (30 h), pero la propuesta dice Etapa 0 = 18–22 h, lo que el área de pagos/compras cuestionará. Noé necesita que la factura sea muy vinculante con un documento. Acción (Erika + Paola): revisar si el contrato ya ata las 30 h; si no, pedirán por correo a Johann ajustar la propuesta para que indique explícitamente las 30 h — sin etiquetarlo "Etapa 0" (para no contraponerse con las 18–22 h que figuran arriba; "primer pago por 30 h" abarcaría Etapa 0 + un poco más). Johann aún no factura: espera la aclaración/correo para emitir con redacción clara. Balam quiere que ya corra el plazo de pago (30 días).
Conciliación: sigue de interés; se evaluará integrarla en esta primera fase según lo que arroje el Discovery (que definirá 112 vs 136 h del módulo de facturación). Hoy la hacen 100% manual.

Pendientes que surgieron:

Balam/Pedro — generar y entregar el token de Arturo (BIND) y probar cobertura de endpoints — arranque Discovery.
Balam/Pedro — crear el repositorio GitHub privado.
Pedro + Noé — configurar Azure y permisos.
Pedro — enseñar a Johann el flujo de Jira (reporte de horas).
Erika — coordinar la sesión de Discovery con Arturo + Araceli (pedir horas disponibles).
Erika + Paola — revisar si el contrato vincula las 30 h; de no ser así, solicitar a Johann por correo el ajuste de la propuesta.
Johann — no facturar aún; al recibir el correo, ajustar la propuesta (30 h explícitas, sin llamarlo "Etapa 0", términos comerciales en una sola sección) y emitir la factura.

Citas relevantes: "Vámonos por partes, como dice Chuck el destripador." · "Necesito que sea muy vinculante al tema del pago con lo que dice el documento… me van a decir ¿dónde dice que son 30 horas?" · "Como recomendación, cuando hables de términos comerciales, déjalo en una sola sección."

Lectura estratégica:

El bloqueador ya no es solo "accesos": la emisión de la primera factura queda condicionada a que Balam aclare internamente (contrato vs propuesta) y lo pida por correo. Johann hizo bien en no facturar todavía; conviene tener lista la versión ajustada de la propuesta para responder rápido cuando llegue el correo.

Balam asume más de la infraestructura de lo previsto (crea el repo, gestiona Azure con Pedro/Noé), lo que reduce fricción de accesos para Johann.

Token de Arturo, solo consulta: coherente con la estrategia de "lectura primero"; la escritura/emisión se valida en Discovery. Un solo token por usuario refuerza el pendiente de documentar cuál llave es para qué.

Erika = punto único para agendar la sesión Arturo+Araceli, clave del Discovery. Jira pasa a ser obligatorio para el reporte de horas (corte lunes).

23 · Jul 1, 2026 — 7:33 AM · Correo · Pedro → Johann · manual de imagen corporativa

CC: Noe Rocha, Erika Chávez, Araceli Sánchez. Dirección: recibido. Evidencia (adjunto): ../fuentes/manual de imagen corporativa - Balam.pdf.

Resumen: Pedro comparte el manual de imagen corporativa de Balam "para su uso en la herramienta que se desarrollará". Sobre el API de BIND, indica que buscará a Johann "en otro momento para ver este tema" (queda para coordinar por separado). Es el "paquete de branding" que Pedro ofreció en la llamada de hoy (#22).

Acción derivada: cierra el pendiente del manual de marca. Los tokens (color, tipografía, uso de logo) quedan destilados en ../marca/Marca-Balam.md para el prototipo de la Etapa 0.

Adjuntos: manual de imagen corporativa - Balam.pdf.

Nota de marca: colores oficiales Amarillo #F7BD0C + Café #331F0E + Blanco; tipografía Poppins. El ámbar #C0892F de la propuesta PDF es acento editorial de Johann, distinto del amarillo de marca — para la plataforma se usan los oficiales.

24 · Jul 1, 2026 — WhatsApp Erika ↔ Johann · agenda la sesión "Proceso actual de facturación y cobranza" (lunes 6-jul)

Evidencia: ../fuentes/2026-07-01 - WhatsApp - Erika coordinacion sesion facturacion-cobranza.md.

7:01 AM: Erika confirma con Johann que ya están en la sesión de kickoff y que se pueda conectar (ver #22).

1:45–1:46 PM: Erika pregunta si puede pedir agenda a las personas involucradas en el proceso de facturación y cobranza para verlo el lunes 06 y martes 07 de julio a las 7 am. Johann da el visto bueno; Erika queda en confirmar por correo.

6:09–6:39 PM: Erika confirma que le aceptaron la reunión del lunes 06 a las 7 am y envía la liga de Teams. Convocatoria: "Proceso actual de facturación y cobranza- Balam", lunes 6-jul 7:00–8:00 AM, organiza Erika, invitados Johann, Araceli Sánchez Jiménez y Arturo Rosas Hernández (CC Noe Rocha).

Lectura estratégica:

Esta sesión es la reunión de Discovery con Arturo + Araceli que Erika se comprometió a coordinar en el kickoff (#22) — cierra ese pendiente.

Solo quedó confirmado el lunes 6-jul; no hay evidencia de que se haya agendado también el martes 7-jul mencionado por Erika. A confirmar si hace falta una segunda sesión.

25 · Jul 2, 2026 — 4:18–4:41 PM · WhatsApp Erika ↔ Johann · agenda/materiales para la sesión del 6-jul

Evidencia: ../fuentes/2026-07-01 - WhatsApp - Erika coordinacion sesion facturacion-cobranza.md.

Erika pregunta si Johann necesita algún documento o ejercicio de parte de Balam para la sesión del lunes, para poder anticiparlo a los asistentes. Johann responde con los puntos que propone cubrir:

Proceso de facturación en BIND (PDF/XML), con ejemplos en USD y MXN.
Revisión de cobranza y reglas de crédito.
Confirmación de la "lista blanca" de clientes (sin recordatorios).
Cualquier otro tema operativo que tengan en el radar.
Pregunta si ya tienen el token de BIND disponible, para poder arrancar con lo técnico.

Lectura estratégica:

Johann fija la agenda de la sesión de Discovery (#24) antes de que ocurra — mismos temas que venía preguntando desde el 4-may (facturación BIND, cobranza, lista blanca).

Aprovecha el mensaje para dar seguimiento al token de BIND (de Arturo), pendiente desde el kickoff (#22) — sin respuesta todavía a este punto.

26 · Jul 2, 2026 — 5:39 PM · Correo · Johann → Noe (CC Ara, Erika, Pedro) · envío de la propuesta v1.2

Asunto: RE: Solicitud de cotización – PRD Para: Noe Rocha · CC: Araceli Sánchez Jiménez, Erika Chávez, Pedro Alberto Ayala Elizondo Adjunto: Propuesta-Balam.pdf (v1.2, 2 MB).

"Buenas tardes a todos, como comentamos en la sesión, les comparto la propuesta actualizada (v1.2, adjunta), donde queda explícita la facturación inicial de 30 horas al arranque del proyecto, con pago a 30 días naturales. Quedo atento a su confirmación para proceder con la emisión de la factura correspondiente. Cualquier comentario o ajuste, con gusto lo revisamos antes."

Johann envía la propuesta v1.2 (30 h de facturación inicial explícitas, condiciones comerciales consolidadas en §3.3) y queda a la espera de que Balam confirme para poder emitir la factura.

Lectura estratégica:

Johann toma la iniciativa: en el kickoff (#22) el plan era que Erika+Paola revisaran primero el contrato y, de ser necesario, pidieran por correo el ajuste; en vez de esperar ese correo, Johann ya envió la propuesta ajustada directamente, lo que puede acelerar el ciclo de la factura.

Sigue vigente el candado: no facturar hasta recibir la confirmación de Balam sobre este correo. Ver PENDIENTES.md.

Nota menor: el documento adjunto conserva la frase "arranque condicionado a contrato u orden de trabajo firmado" (§3.3 y Próximos pasos), redactada como si la firma estuviera pendiente — cuando el contrato ya se firmó el 26-jun (#19). No debería generar confusión (Balam ya sabe que está firmado), pero queda anotado por si alguien lo señala.

27 · Jul 6, 2026 — 7:00 AM · Llamada · Discovery: proceso actual de facturación y cobranza ⭐

Participan: Araceli Sánchez (comercial/dirección), Arturo Rosas Hernández (administración/facturación), Erika Chávez y Johann. Noé era opcional y no asistió. Canal: Microsoft Teams (~1 h 5 min). Evidencia: ../fuentes/2026-07-06 Proceso actual de facturación y cobranz_ Transcript.txt.

Resumen: Primera sesión de Discovery (Etapa 0). Araceli y Arturo muestran en vivo el proceso completo de facturación: entrada por Jira ITSM (obligatoria desde hace ~1 mes) → validación de administración → prefactura en BIND → emisión de CFDI → envío por correo con particularidades por cliente. Se demostró el flujo real en BIND (crearon y cancelaron una prefactura en vivo). Dos reglas de negocio cambiaron en la propia sesión. La parte de cobranza NO se cubrió — solo se tocaron la lista blanca y la idea de recordatorios; el proceso de seguimiento de pagos queda pendiente de mapear (cuando Johann preguntó si después seguía cobranza, Ara redirigió al proceso de envío de factura).

El proceso actual, paso a paso

1. Entrada — Jira ITSM (portal de servicios interno):

Desde hace ~2 quincenas es mandatorio: "si no hay algo que se levante a través de Jira en un ticket, no se factura". Antes se controlaba con un Excel manual → facturas olvidadas (descubrían en marzo que enero no se facturó) y errores de moneda.
Módulo Administración General → Facturación, con dos tipos: "Facturación adicional" (suma) y "Bajas" (resta).
El portal sirve a varias empresas (Balam, Regiotour, Elmstone); el campo "empresa origen" las distingue. A futuro quieren que la plataforma facture también para las demás — por ahora el foco es Balam.
Campos del formulario: empresa origen · summary · proyecto · cliente nuevo (sí/no — si es nuevo se adjunta cédula de identificación fiscal + cotización; si es recurrente solo cotización) · moneda (MXN/USD) · días de crédito (default 30; a veces 45; CEMEX 90 innegociable) · periodo de incidencias (horas extra, periodos de servicio, comentarios) · facturación recurrente (sí/no) + periodo de recurrencia en meses (el equipo de tecnología trabaja en que las recurrencias se detonen solas cierto día).
Quién lo llena: siempre la parte comercial = Araceli (excepcionalmente Pau la apoya). "El deber ser es que la parte comercial siempre levante el ticket."
Tres vías generan factura: (a) ticket directo de facturación adicional; (b) Headhunting — el ticket de RH detona automáticamente una factura de anticipo y, al colocar a la persona, el 50% o 100% restante; (c) Staff augmentation — al arrancar la persona en el cliente se genera el ticket de factura.
Ruteo: todos los tickets se asignan por regla a una sola persona: Arturo. Administración hace doble check (datos, cédula fiscal, estado de cuenta) sobre la lista.
Flujo interno del ticket con SLAs: solicitud abierta → proceso de facturación → (espera del colaborador / cancelado) → se adjunta PDF + XML obligatorios como evidencia → botón de validación/autorización → estatus "facturado". Flujo alterno de facturación extranjera: sin XML, solo la invoice en PDF ("validación extranjera").

2. BIND ERP (lo opera Arturo):

Consulta: Finanzas → Cuentas por cobrar (facturas en proceso, vencidas, pagadas — ahí dan seguimiento a cobranza).
Creación: Ventas → generar documento. Siempre hacen prefactura primero (no se timbra ante el SAT; cancelar una factura timbrada es retrabajo administrativo y contable) → doble check → Emitir CFDI.
Prerequisitos que asumen cargados: cliente dado de alta, cuentas, moneda. Pregunta abierta que dejó Arturo: definir qué hará la automatización cuando el cliente NO esté dado de alta (proceso aparte).
Campos relevantes: sucursal (hoy solo matriz; serviría para facturar por unidad de negocio a futuro) · días de crédito (manual, editable, default del cliente) · orden de compra (deber ser: OC autorizada como prerequisito) · uso CFDI: "gastos en general" (nacional) y "sin efectos fiscales" (extranjera — se timbra igual pero con IVA 0%) · método de pago PPD/PUE · conceptos precargados editables (ej. 029 "consultoría y servicios"; sugieren incluir el nombre del recurso) · dirección fiscal precargada · comentarios (ponen el ticket de Jira para cruzar reportes).
⚠️ PPD vs PUE es delicadísimo: siempre dan crédito → casi todo es PPD. Hace ~2 años administración seleccionó PUE por error y les cayó un requerimiento del SAT. PUE exige complemento de pago timbrado el mismo día. (Regla de validación clara para la plataforma.)
⚠️ IVA no es automático en BIND: "sin efectos fiscales"/extranjero debería ir con 0% y pesos con 16%, pero BIND no lo pone solo — Arturo lo capturó manualmente (y en el ejemplo puso 16% en una sin efectos fiscales; Ara lo señaló). Otra validación clara para la plataforma. Además, por ser reclutadora a veces llevan retenciones adicionales.
Tras la prefactura se habilitan: emitir CFDI, registrar pago, nota de crédito, editar, copiar (así manejan las recurrencias), cancelar, exportar partidas a Excel, enviar por email (a los correos configurados del cliente), descargar PDF, póliza contable.

3. Envío al cliente (el paso que les falta sistematizar):

La facturación "termina" hasta que la factura se envía por correo, y cada cliente tiene particularidades: Axie (extranjero): facturas + estado de cuenta de todas las facturas · CEMEX: factura a un hub + Excel de horas del colaborador con visto bueno del jefe + nomenclatura específica del asunto (número de proveedor, mes, número de factura en posiciones exactas) y redacción específica del correo · Dilo (proyectos): factura + cotización del proyecto · Acuntia: .zip + estado de cuenta.
Tienen un Excel con cliente → destinatarios; les falta la columna de adjuntos/particularidades. Ara + Arturo se comprometieron a completarlo y enviarlo HOY (6-jul).
Volumen real: ~55 facturas/mes de solo 4–6 clientes — el cliente mayor exige una factura por colaborador (~40 colaboradores); agrupadas serían 5–6 facturas.

Dolores (en palabras de Ara, dirección general)

El caos de control ya lo mitigó Jira; el dolor vivo es que el proceso en BIND sigue siendo manual → errores en montos, descripciones, moneda, IVA, PPD/PUE.
No quiere "engrosar la nómina" con capturistas: quiere que la automatización absorba la carga y enfocar a la gente en actividades de más valor. El volumen es bajo (~55/mes); el problema es la incidencia de errores, y están en franco crecimiento.
Reporteo ya lo cubren con Power BI; lo que piden de la plataforma es que administración solo valide prefacturas antes del envío.
Dónde quieren la automatización: después de Jira (confirmado explícitamente por Ara y Arturo cuando Johann lo preguntó). Idea de Arturo: que los agentes observen Jira (botones/aprobaciones del flujo) para saber cuándo accionar en BIND.

🔄 Cambios de reglas de negocio (decididos en la sesión)

Lista blanca ELIMINADA. Solo tenían a Acuntia (nunca hubo "top 3" reales). Y en la propia llamada Ara revirtió la decisión: los recordatorios de morosidad deben ir a TODOS los clientes, sin excepciones — hoy arrastran una factura de febrero y otra de abril justamente del cliente "muy pagador" por no recordarle a tiempo. Arturo coincidió: con recordatorios automáticos no habrían llegado a julio con una factura de febrero.
Cotización en BIND = punto de partida OBLIGATORIO. Ara lo fijó como requisito formal: "sí puedes tomar, Johann, como un requisito de que vamos a partir de una cotización del sistema". El deber ser: comercial genera la cotización en BIND → se adjunta al ticket de Jira → administración (o el agente) la convierte a prefactura con un clic → validación humana → CFDI. Para cliente nuevo: comercial levanta ticket → administración (que tiene el privilegio) da de alta al cliente en BIND → avisa → comercial ya puede cotizar. No quiere "desarrollo con parchecitos". (Excepción discutida y descartada: aun en headhunting con rango salarial abierto, la cotización puede esperar al cierre — siempre habrá cotización.)

Acuerdos / próximos pasos de la sesión:

Ara + Arturo — enviar hoy (6-jul) el Excel de particularidades de envío por cliente (destinatarios + adjuntos + nomenclatura).
Johann — trabajar el prototipo reflejando el flujo real (lo dijo al cierre: "ya me da una idea más clara de cómo trabajar el prototipo que les mostraré"). Dudas de seguimiento vía Erika.

Lectura estratégica:

El flujo real valida el diseño de la propuesta: cotización → factura vía API era exactamente el mecanismo cotizado en la Etapa 2, y ahora además es política interna de Balam. El pipeline objetivo queda nítido: Jira (disparador) → cotización BIND → prefactura → validación humana → CFDI → envío por correo.

La eliminación de la lista blanca simplifica el MVP (el catálogo/lista configurable puede quedar como capacidad, hoy vacía). PERO ojo: lo que Ara y Arturo describen son recordatorios automáticos a clientes, que están diferidos al Anexo B (el MVP trae alertas internas). Su expectativa apunta a ese módulo — conviene aclararlo pronto o anticipar que lo pidan al cierre del MVP.

Jira como disparador del flujo (agentes observando tickets/botones) se parece al "Nivel 3" (generación desde eventos) que estaba en fase posterior. La integración con la API de Jira no está cotizada en el MVP — vigilar ese límite de alcance cuando se diseñe el prototipo.

Se levantaron reglas de validación de oro para la plataforma: PPD por default (PUE solo consciente — ya les costó un requerimiento del SAT) · IVA 16% MXN / 0% extranjero-sin efectos fiscales (BIND no lo automatiza) · prefactura SIEMPRE antes de timbrar · OC/cotización como prerequisito · alta de cliente como flujo aparte.

El token de BIND NO se tocó en la sesión — sigue abierto desde el kickoff y el WhatsApp del 2-jul (#25).

La cobranza quedó sin mapear — la sesión del martes 7-jul (que Erika mencionó desde el 1-jul) sería el espacio natural para cubrirla: cómo dan seguimiento hoy a los pagos, quién persigue morosos, cómo concilian cuentas por cobrar, y de dónde saldría el aging. Proponérselo a Erika.

Multi-empresa (Regiotour, Elmstone) aparece como deseo de futuro de Ara — anotarlo para el roadmap, no para el MVP.

28 · Jul 6, 2026 — 9:01 AM–12:40 PM · WhatsApp Erika ↔ Johann · token de BIND ENTREGADO ⭐

Evidencia: ../fuentes/2026-07-06 - WhatsApp - Erika sesion discovery y seguimiento token BIND.md.

Tras la sesión de Discovery (7–8 am, #27), Erika revisa el plan de actividades línea por línea:

9:01 — Sobre "Entrega y validación de accesos (BIND, Azure, manual de marca) · lun 06 → mar 07 jul": "¿solo necesitas el token tal cual?" Johann (9:53–9:54): "Sí, para BIND solo necesito el token tal cual. Lo de Azure no me urge hoy y el manual de marca ya lo tengo."
10:26 — Erika: "okey deja lo solicito" → el token queda formalmente solicitado dentro de Balam.
10:28–10:37 — Sobre "Validación técnica de la API de BIND con la cuenta real · mar 07 → mié 08 jul": "¿se necesita una sesión?" Johann (10:37): "No, esa validación la hago yo por mi cuenta ya teniendo el token."
12:10–12:19 — Token GENERADO dentro de Balam: "ya solicitaran el token ahorita te lo comparto". Erika desconoce si tiene vencimiento (según el kickoff: no caduca), comenta que lo tienen en un .txt y pregunta si sirve por correo. Johann (12:25): sí, por correo y .txt está bien; (12:27) pide que le confirmen a qué usuario pertenece el token para documentarlo.
12:40 — Erika: "ya se compartió por correo" → ✅ TOKEN DE BIND ENTREGADO.

Lectura estratégica:

El bloqueador del token se resolvió el mismo día: Johann lo empujó a las 9:01 vía el plan de actividades, Erika lo solicitó a las 10:26 y estaba entregado a las 12:40 — un día antes de la fecha del plan (mar 7-jul). Cierra el seguimiento que venía desde el 2-jul (#25).

Que Erika trabaje sobre el plan de actividades confirma que el Excel de Johann es el instrumento real de seguimiento — mantenerlo al día paga.

Quedan dos higienes: (1) Balam debe confirmar de qué usuario salió el token (Johann lo pidió 12:27, Erika "okey" — el acuerdo del kickoff fue el de Arturo para dev); (2) tratarlo como llave de producción (sin sandbox): guardarlo en gestor de secretos, no dejarlo en el correo/.txt.

Desbloquea la validación técnica de la API (mar 7 – mié 8 del plan) — puede incluso adelantarse hoy.

29 · Jul 6, 2026 — 12:38 PM · Correo · Pedro → Johann (CC Noe, Erika) · entrega formal del token de BIND ✅

Adjunto: bind_token_api.txt. Evidencia: ../fuentes/2026-07-06 - Correo - Pedro entrega token BIND (usuario Arturo Rosas).md.

Pedro entrega el token de la API de BIND por correo (es el envío que Erika anunció por WhatsApp a las 12:40, #28) y confirma que fue generado con el usuario de Arturo Rosas — conforme al acuerdo del kickoff (llave de Arturo para desarrollo; la de Ara para Power BI). Se ofrece para validar dudas directamente. Erika agradece en el hilo (12:39). Johann acusa recibo (~3:28 pm): toma nota del usuario de Arturo para documentarlo, confirma que ya puede comenzar a trabajar con la API y que cualquier duda la validará con Pedro — deliberadamente sin comprometer entregas adicionales (los hallazgos se integran al documento de cierre de la Etapa 0 ya planeado).

Lectura estratégica:

Cierra las dos puntas del pendiente de accesos BIND: token entregado y usuario documentado. La entrega por correo (no WhatsApp) además deja la evidencia formal en el canal correcto.

Higiene inmediata: pasar el token del .txt a un gestor de secretos y no conservarlo en el buzón.

Dato colateral: la firma de Pedro lo identifica como ITSM Analyst / Consultor de Gestión de Servicios TI — coherente con que él montó el portal Jira ITSM del Discovery.

30 · Jul 6, 2026 — 3:01 PM · WhatsApp Johann → Erika · propone sesión de cobranza (martes 7-jul)

Evidencia: ../fuentes/2026-07-06 - WhatsApp - Erika sesion discovery y seguimiento token BIND.md (bloque 7).

Johann plantea a Erika que la sesión de hoy solo alcanzó para facturación y envío, y que falta mapear cobranza (seguimiento de pagos y cuentas por cobrar). Propone el martes 7-jul, 7am — retomando la fecha que Erika misma había mencionado el 1-jul — o cuando se acomode en la semana. Erika queda en revisar la agenda con las personas involucradas y confirmar.

Lectura estratégica:

Completa el Discovery pendiente de #27 reutilizando la propia propuesta de Erika (bajo costo de coordinación). Interlocutor clave: Arturo (lleva CxC en BIND); Ara deseable por el contexto comercial.

Idealmente se confirma antes del viernes 10 (validación del prototipo), para que la pantalla de Cobranza llegue respaldada por el proceso real y no como hipótesis.

31 · Jul 6, 2026 — 4:33 PM · Correo · Noé → Johann, Pedro (CC Erika) · salvaguardas sobre el token ⚠️

Importancia alta. Evidencia: ../fuentes/2026-07-06 - Correo - Pedro entrega token BIND (usuario Arturo Rosas).md (respuesta de Noé en el hilo).

Noé responde al hilo de la entrega del token con dos instrucciones:

A Johann: mientras Pedro revisa si el acceso es de lectura o también de escritura, aplicar "las salvaguardas necesarias para evitar alguna afectación operativa".
A Pedro: si es necesario, crear un usuario específico de solo lectura en BIND para esta etapa de exploración — "la cuenta de Arturo tiene algunos privilegios elevados que creo que no serían necesarios en este momento".

Implicación: el token de Arturo podría ser reemplazado por uno de un usuario nuevo de solo lectura.

Lectura estratégica:

La preocupación de Noé es exactamente el diseño ya construido: el sandbox opera en modo solo-lectura por defecto con bloqueo de escrituras en código, dry-run, cuota vigilada y token fuera del repo (.gitignore ya cubre bind_token_api.txt y *.env). Responder describiendo esas salvaguardas convierte un correo de riesgo en una oportunidad de confianza con el CTO.

Ojo operativo: si Pedro crea un usuario nuevo, el token cambiará — no invertir esfuerzo en atar nada al token actual; el cliente ya está parametrizado por variable de entorno, el cambio es trivial.

Coherente con la estrategia "lectura primero" de la propuesta: nadie está pidiendo frenar la validación, solo asegurar el perímetro.

32 · Jul 6, 2026 — tarde · Validación técnica de la API de BIND con la cuenta real ⭐ ✅

Actividad del plan "Validación técnica de la API de BIND" (mar 7 – mié 8) — ejecutada un día antes, el mismo día en que llegó el token. Evidencia completa: ../bind-api-sandbox/VALIDACION-API.md (117 peticiones, exclusivamente GET, solo estructura — cero datos reales persistidos).

Veredictos clave:

✅ Plan A del saldo CONFIRMADO — el riesgo central de la propuesta quedó resuelto a favor: cada fila de Invoices trae Total, Payments (acumulado) y CreditNotes; el saldo por factura es una resta local, verificada aritméticamente. No se activa el Plan C (+6–8 h) — la inversión apunta a la parte baja del rango.
✅ El flujo del MVP es 100% sostenible en lectura: cotizaciones legibles (con partidas y comercial), prefacturas distinguibles (UUID null / IsFiscalInvoice false), PPD/PUE y días de crédito auditables (en el detalle), IVA por partida (habilita la validación 16%/0%), PDF del CFDI descargable por API (insumo del módulo de envío), aging viable con ExpirationDate + saldo.
❌ No existe recurso de pagos individuales ni de complementos de pago (REP) — 20 nombres probados, todos 404. La cobranza operativa del MVP funciona igual (detecta pago por transición de estatus/residual), pero la fecha valor del pago y los REP del flujo PPD no son visibles. Escalar a Pedro.
⚠️ Sin vínculo cotización→factura en la API — la trazabilidad la llevará la plataforma (registrar el par al orquestar la conversión).
⚠️ Rarezas a cablear con cuidado: token inválido responde 500 (no 401); $select y conteos no funcionan (paginación manual con $top=100); nomenclatura CFDI invertida vs SAT (CFDIPaymentTerm = PPD/PUE); CFDIUse es código interno (falta tabla de mapeo); typo real del API (Loctaion); campos clave solo en el detalle → sync incremental obligatorio.
✅ Token acotado a una sola empresa (la de Arturo → Balam) — multi-empresa confirmado fuera del alcance por API.
Presupuesto de sync: ~1,000 req/día con polling cada 15 min ≈ 5% del límite de 20K. Holgado.

Preguntas que quedan para Pedro/doc (§10 del documento): endpoint de pagos/REP no descubierto · tabla CFDIUse interno→clave SAT · shape del endpoint /xml · códigos de Status >2 · webhooks/eventos.

Lectura estratégica:

El Discovery técnico ya pagó: el Plan A confirmado elimina la mayor incertidumbre de horas de la propuesta, y todo lo que el MVP necesita en lectura existe. La actividad del plan se cerró anticipada — buen dato para el corte de Erika del lunes.

El hueco de REP/pagos es real pero no bloquea el MVP (cobranza operativa funciona por transición de estatus); importa para el flujo PPD completo y para conciliación (Anexo B). Escalarlo con Pedro esta semana, idealmente junto con la tabla de CFDIUse.

Las salvaguardas prometidas a Noé (#31) se cumplieron al pie: GET-only por construcción, presupuesto de peticiones, reporte sanitizado, token fuera de git.

33 · Jul 6, 2026 — 4:34–5:03 PM · WhatsApp Erika → Johann · confirma operar solo-lectura (eco del correo de Noé)

Evidencia: ../fuentes/2026-07-06 - WhatsApp - Erika sesion discovery y seguimiento token BIND.md (bloque 8).

Resumen: Erika transmite por WhatsApp, en versión breve, la instrucción de Noé sobre salvaguardas del token (#31): "referente a lo del token que se te compartió, para evitar complicaciones operativas." Johann confirma: "por el momento estaré haciendo operaciones solo de lectura." Erika agradece el entendimiento.

Acción derivada: confirmación informal, no sustituye la respuesta formal por correo a Noé (borrador listo, ver PENDIENTES.md) — conviene enviarla igual para dejar constancia en el canal formal, tal como pidió Noé.

Lectura estratégica:

Erika actúa como puente entre la instrucción formal de Noé (correo, 4:33 pm) y Johann — coherente con su rol de intermediaria única.

El contenido no agrega nada nuevo a lo ya resuelto por diseño (sandbox solo-lectura); es una confirmación de bajo costo que sostiene la confianza mientras se prepara la respuesta formal.

34 · Jul 6, 2026 — 6:36–6:40 PM · WhatsApp + convocatoria Outlook/Teams · confirma sesión de cobranza (martes 7-jul) ⭐

Evidencia: ../fuentes/2026-07-06 - WhatsApp - Erika sesion discovery y seguimiento token BIND.md (bloque 9).

Resumen: Erika envía la convocatoria "Proceso actual de cobranza- Balam", martes 07/07/2026, 7:00–8:00 AM, por Microsoft Teams. Organiza Erika Chávez; invitados Johann, Araceli Sánchez Jiménez y Arturo Rosas Hernández (CC: Noé Rocha) — cierra la propuesta que Johann hizo el mismo día a las 3:01 pm (#30). Johann confirma recepción por WhatsApp (6:40 pm).

Acción derivada: asistir a la sesión el martes 7-jul, 7:00 am (agenda: cómo dan seguimiento hoy a pagos y cuentas por cobrar, quién persigue morosos, cómo concilian, de dónde saldría el aging — temas listados en la lectura estratégica de #27).

Lectura estratégica:

Cierra el hueco de Discovery que quedó abierto el 6-jul: facturación y envío ya están mapeados (#27); cobranza se mapea el 7-jul, antes del viernes 10 (fecha objetivo para la validación del prototipo) — como Johann buscaba al proponerlo.

Interlocutores correctos confirmados: Arturo (lleva CxC en BIND) y Araceli (contexto comercial), igual que en la sesión anterior — buena señal de continuidad.

Convocatoria aún sin respuestas registradas ("4 sin respuesta") al momento de reenviarla — no es un riesgo en sí, Balam ya confirmó la sesión por WhatsApp.

35 · Jul 7, 2026 — 7:00 AM · Llamada · Discovery: proceso actual de cobranza (sin grabación) ⭐

Participan: Arturo Rosas (administración/CxC — mostró el proceso) y Johann; la convocatoria incluía también a Araceli y Erika (CC Noé). Canal: Microsoft Teams, 7:00–8:00 AM. ⚠️ Sin grabación — evidencia: ../fuentes/2026-07-07 - Notas - Proceso actual de cobranza (sin grabacion).md (notas de memoria de Johann, mismo día).

Resumen: Segunda sesión de Discovery — cierra el mapeo de cobranza que quedó pendiente el 6-jul (#27). Arturo mostró sus Exceles de control (facturas abiertas, canceladas, días de morosidad — el aging de facto) y el flujo real de un pago: el cliente avisa por correo/mensaje con su estado de cuenta → se comparte con el despacho contable, que registra los pagos en BIND uno por uno → un Power BI (conectado, según Arturo, con su token) muestra la cartera pero no está al día.

El detalle que complica conciliar:

Un mismo pago puede cubrir decenas de facturas ("10 pesos divididos en 40 facturas" — consistente con el cliente que exige factura por colaborador, ~40).
Los comprobantes llegan todos con el mismo patrón de referencia (tipo num_referencia.pdf) → la referencia no distingue facturas, se concilia por folio.
Al recibir el dinero hay un fee/comisión → los montos no cuadran exactos contra el total facturado.
Caso mostrado: Arturo pidió a Acuntia su relación de pagos; respondieron con un Excel pago ↔ folio — control de ambos lados, pero totales distintos por el fee.
Casos límite: clientes que pagan facturas viejas arrastradas (aplicación fuera de orden) y facturas pagadas cuyo registro va atrás de la realidad.

Lo que buscan: ser proactivos — recordatorios configurables (pasados 1–5 días de vencimiento, correo al cliente) o al menos visibilidad inmediata del atraso. Su evolución: eran reactivos ("ya hace rato que no me paga"), hoy son activos, quieren ser proactivos.

Pendientes que surgieron:

Johann — pedir a Arturo los Exceles: control de cobranza (abiertas/canceladas/morosidad), el Excel tipo Acuntia (pago↔folio) y un estado de cuenta ejemplo.
Johann — preguntar cómo registran en BIND la diferencia por fee (¿pago parcial con residual? ¿nota de crédito?).
Johann/Pedro — verificar qué token alimenta el Power BI (ver lectura estratégica).

Lectura estratégica:

El diseño de cobranza del MVP queda respaldado por el proceso real: el aging por factura con residual (Plan A: Total − Payments − CreditNotes, confirmado en #32) cubre exactamente los casos que Arturo describió — pagos fuera de orden y facturas arrastradas se leen por factura, no por cliente.

Regla de diseño nueva — tolerancia a fees: "pagada" no puede exigir residual = 0 exacto; hace falta un umbral configurable para no mostrar como morosas facturas saldadas con comisión. Aplica también a la conciliación futura (Anexo B).

El hueco de pagos/REP del API (#32) ahora tiene caso de negocio: el despacho registra pagos a mano, uno por uno — automatizar ese registro requeriría justo el endpoint que no apareció. Refuerza la escalación a Pedro.

⚠️ Discrepancia de tokens a verificar: Arturo mostró el Power BI conectado con su token, pero el kickoff (#22) acordó Ara = Power BI / Arturo = desarrollo. BIND emite 1 token por usuario: si Power BI y el desarrollo comparten el de Arturo, el reemplazo por un usuario solo-lectura que planteó Noé (#31) rompería uno de los dos. Verificar con Pedro antes de cualquier cambio.

Los recordatorios proactivos a clientes reaparecen (tercera vez: propuesta original, sesión del 6-jul, hoy) — siguen siendo módulo del Anexo B (el MVP trae alertas internas + visibilidad). La aclaración de expectativas ya no puede esperar mucho.

Actor nuevo en el mapa: el despacho contable — no había aparecido en el Discovery de facturación; es quien toca BIND para los pagos.

Los Exceles de Arturo son la especificación de facto de la pantalla de Cobranza (columnas, buckets de morosidad que ya usan) — pedirlos con las salvaguardas de siempre: datos reales fuera del repo y de los documentos, solo estructura.

36 · Jul 7, 2026 — 12:27 PM · WhatsApp Erika → Johann · seguimiento del pendiente de BIND (¿probar escritura?)

Evidencia: ../fuentes/2026-07-07 - WhatsApp - Erika seguimiento BIND.md.

Resumen: Erika revisa de nuevo el plan de actividades y pregunta por la línea "Validación técnica de la API de BIND con la cuenta real" (vigente hoy 7-jul y mañana 8-jul según el plan): "johan respecto a este punto, es para hoy y mañana, todo bien, necesitas algo?" — la misma actividad que Johann ya adelantó y cerró el 6-jul (#32).

⚠️ A las 9:28 am Erika había respondido "no" a un mensaje previo que no está incluido en la evidencia disponible — contexto pendiente de aclarar.

Acción derivada: Johann evalúa si hace falta sondear los endpoints de escritura (POST/PUT) de BIND, ya que la validación de lectura cerró en #32. Decisión: no probarlos en vivo contra producción todavía — sigue vigente la instrucción de Noé de mantener el modo solo-lectura mientras Pedro confirma el alcance real del token (#31), y no hay sandbox donde ensayar sin riesgo fiscal. Camino seguro en su lugar: revisar el catálogo de operaciones del portal de desarrolladores de BIND (ya referenciado por Noé el 25-may — incluye al menos Activities_AddActivity) para documentar qué escrituras existen, sin ejecutarlas. Respuesta a Erika: nada adicional urgente para las pruebas; lo único abierto es escalar con Pedro las preguntas técnicas ya listadas en PENDIENTES.md (endpoint de pagos/REP, tabla CFDIUse, shape de /xml, webhooks).

Lectura estratégica:

Buena disciplina: la tentación de "ya que tenemos el token, probemos escritura" se descarta porque contradice justo lo que Noé pidió resguardar — probarlo ahora sería el peor momento (token de Arturo con privilegios elevados, posible reemplazo en curso).

El BindClient ya está diseñado para este escenario: modo read-only bloquea cualquier método mutante en código (BindReadOnlyViolation), y addActivity() queda estructuralmente listo pero inerte hasta que se active dry-run/write con autorización — los candados de la propuesta (dry-run + confirmación humana) siguen intactos.

37 · Jul 7, 2026 — 3:56–5:49 PM · WhatsApp Erika ↔ Johann · seguimiento al usuario de lectura de BIND

Evidencia: ../fuentes/2026-07-07 - WhatsApp - Erika seguimiento BIND.md (bloque 3).

Erika confirma que, mientras se resuelve si Pedro crea el usuario de solo lectura que pidió Noé por correo (#31), ella sigue operando en BIND con el usuario de Arturo a modo de lectura, sin que esto la bloquee. Pregunta si ese usuario de lectura se lo iban a crear. Johann aclara que Noe le pidió a Pedro revisar si era necesario crearlo — la decisión no depende de Erika. Erika, reconociendo que no está familiarizada con el tema, queda en revisarlo con el equipo técnico.

Lectura estratégica:

Confirma que el reemplazo de token propuesto por Noé el 6-jul (#31) sigue sin resolverse una semana después — Pedro no ha confirmado si crea el usuario nuevo. No es bloqueante hoy (Erika opera con el de Arturo sin problema), pero sigue abierto el riesgo señalado en #35: si el Power BI de Arturo comparte el mismo token que el de desarrollo, reemplazarlo rompería uno de los dos usos.

38 · Jul 8, 2026 — 10:09 AM–10:55 AM · WhatsApp Erika ↔ Johann · datos ficticios para los Exceles de cobranza

Evidencia: ../fuentes/2026-07-08 - WhatsApp - Erika datos ficticios cobranza y avance fase 0.md (bloques 1–2).

Erika avisa que Balam está validando internamente si puede compartir la información de cobranza que Johann solicitó (#35, pendiente en PENDIENTES.md), por tratarse de información delicada. Johann ofrece una salida de bajo fricción: acepta que sean datos ficticios, ya que lo que necesita es la estructura que siguen, no los datos reales. Erika traslada la propuesta al equipo (10:50) y queda en avisar cuando tenga respuesta.

Lectura estratégica:

Resuelve por adelantado la fricción de confidencialidad de los Exceles de cobranza pedidos en #35: en vez de esperar una validación legal/interna que podría demorar, Johann baja el estándar a "estructura, no datos reales" — coherente con la salvaguarda ya prometida a Noé de mantener datos reales fuera del repo y de los documentos.

Sin fecha comprometida para la respuesta de Balam; sigue siendo no bloqueante para el avance del prototipo.

39 · Jul 9–10, 2026 · WhatsApp Erika ↔ Johann · avance de Fase 0 + prototipo sin sesión de validación agendada

Evidencia: ../fuentes/2026-07-08 - WhatsApp - Erika datos ficticios cobranza y avance fase 0.md (bloques 3–4).

9-jul, 7:20 PM: Erika pide a Johann un corte de avance de las actividades de Etapa 0 ("cómo vamos"). Johann responde hasta las 9:10 PM preguntando por qué medio compartirlo, sin resolverlo esa noche.

10-jul, 8:41–9:39 AM: Erika insiste ("nomás dime qué actividades y % de avance"). Johann reconoce que no confirmó la sesión de validación del prototipo que él mismo se había puesto como meta para el viernes 10-jul (ver PENDIENTES.md): el día anterior no dio seguimiento y no quedó agendada la reunión. Ofrece, en su lugar, compartir el prototipo por correo con sus propios comentarios. Erika acepta y da instrucciones de destinatarios, corrigiéndose dos veces en minutos: primero pide copiar a Pedro, al Ing. Noé y a Araceli (9:00); a los 21 minutos corrige — sin Araceli (9:21–9:22); y pocos minutos después acota aún más — solo a ella y al Ing. Noé, con Pedro en copia, "nosotros se los pasamos internamente" (9:28). Johann confirma y, al cierre, retoma la pregunta pendiente del 9-jul sobre si el % de avance de Fase 0 se reporta por el mismo canal de WhatsApp — sin respuesta aún al cierre de este tramo.

Lectura estratégica:

Dos pendientes de Johann quedan expuestos por la falta de seguimiento propio: (1) el reporte de avance/% de Fase 0 que Erika pidió desde el 9-jul, y (2) la sesión de validación del prototipo del viernes 10-jul (comprometida en PENDIENTES.md) que no se agendó a tiempo. Ambos se resuelven convergiendo en un solo entregable: correo con el prototipo (imágenes) + avance de Fase 0, en vez de una reunión.

Lista de destinatarios del correo del prototipo, final: Erika + Ing. Noé, CC Pedro únicamente — Araceli queda excluida (Balam decide compartirlo con ella internamente). Difiere del patrón habitual del hilo de correo principal, donde Araceli sí solía ir en copia — respetar esta instrucción explícita para este envío.

Sigue sin resolverse el % de avance de Fase 0 que se debe reportar — acción abierta de Johann.

40 · Jul 10, 2026 · Correo · Johann → Erika, Noé (CC Pedro) · entrega del prototipo Etapa 0 ⭐

Evidencia documental: ../prototipo/Correo-prototipo-Etapa0.md. Adjunto: ../prototipo/Prototipo-Balam-Etapa0.pdf.

Johann entrega por correo el prototipo navegable de facturación y cobranza, con PDF y acceso temporal a la versión web. El material usa datos ficticios y refleja el flujo levantado en Discovery: Jira → cotización BIND → prefactura → validación humana → CFDI → envío, además de cobranza por factura.

Balam responde que lo revisará internamente y compartirá comentarios. La retroalimentación queda pendiente; no se realizó la sesión en vivo prevista originalmente para ese día.

Acción derivada: mantener el entregable en validación y continuar únicamente con trabajo de Etapa 1 que no dependa de cambios visuales.

41 · Jul 13, 2026 · WhatsApp Erika ↔ Johann · continuidad de Etapa 1, sesión con Arturo y factura de 30 h

Evidencia: ../fuentes/2026-07-13 a 2026-07-15 - WhatsApp - Seguimiento prototipo sesiones accesos.md.

Johann comunica que, mientras Balam revisa el prototipo, avanzará localmente con base de datos, autenticación/roles y cliente de consulta de BIND. Erika explica que la CEO se encuentra fuera del país y que la diferencia de horario dificulta la validación inmediata.

Johann pide coordinar una sesión con Arturo para cerrar alta de clientes nuevos, tratamiento del fee en BIND y Excel de particularidades de envío. Erika contactará a Arturo y confirma que el Excel continúa en preparación.

Sobre la propuesta v1.2 y la factura inicial de 30 h, Erika confirma que recibió el documento. La validación administrativa sigue pendiente porque la CEO y Noé están fuera del país por trabajo; Erika revisará cómo obtener el visto bueno.

Lectura estratégica: no hay rechazo comercial ni bloqueo técnico total. Johann mantiene momentum en local, pero la factura aún no debe emitirse sin confirmación y las definiciones de negocio se recorren.

42 · Jul 14, 2026 · WhatsApp Erika ↔ Johann · dos sesiones confirmadas para 22–23 jul

Evidencia: ../fuentes/2026-07-13 a 2026-07-15 - WhatsApp - Seguimiento prototipo sesiones accesos.md.

Erika confirma dos espacios distintos:

Miércoles 22-jul: sesión de dudas y definiciones de la Etapa 1 con Arturo y participación solicitada de la CEO.
Jueves 23-jul, 7:00 pm: sesión de validación del prototipo de la Etapa 0. Erika envía la convocatoria.

Temas para el 22-jul: alta de cliente nuevo, registro de diferencias por fee, particularidades de envío y definición de alcance de la posible automatización Jira → cotización BIND.

43 · Jul 14–15, 2026 · WhatsApp Erika ↔ Johann · ajuste de accesos y repositorio GitHub autorizado

Evidencia: ../fuentes/2026-07-13 a 2026-07-15 - WhatsApp - Seguimiento prototipo sesiones accesos.md.

Johann aclara que para la Etapa 1 requiere un repositorio privado de GitHub de Balam y, posteriormente, acceso acotado a Azure. Se mantiene la reprogramación: repositorio primero; Azure durante la semana del 21-jul; CI/CD y secretos el 24-jul.

El 15-jul Erika confirma que Noé autorizó la creación del repositorio y solicita el usuario de GitHub. Johann comparte Johann-28 (https://github.com/Johann-28).

Estado: repositorio autorizado; falta recibir la invitación y verificar permisos de escritura. Azure aún no bloquea el desarrollo local.

44 · Jul 14, 2026 · WhatsApp Erika ↔ Johann · Excel de días vencidos condicionado a validación

Evidencia: ../fuentes/2026-07-13 a 2026-07-15 - WhatsApp - Seguimiento prototipo sesiones accesos.md.

Erika pregunta si todavía se requiere el Excel de control de cobranza con días vencidos. Johann aclara que, si Balam considera que la estructura del prototipo refleja correctamente su operación, ya no será necesario prepararlo; si detectan ajustes, seguirá siendo útil como referencia y puede contener datos ficticios.

Impacto: deja de ser un pendiente obligatorio y permanece condicionado a la retroalimentación del prototipo. Esto no sustituye el Excel de particularidades de envío por cliente, que Balam continúa preparando.

45 · Jul 15, 2026 · Gestión interna · se inicia control local de horas

Mientras Pedro habilita el flujo de reporte en Jira, Johann crea un control local en ../planeacion/Seguimiento-horas.csv y su guía en ../planeacion/Seguimiento-horas.md.

Se cargan 3.08 h de sesiones con duración comprobable y se reconstruye retrospectivamente el resto del esfuerzo por actividad hasta un corte de 30 h: 22 h de Etapa 0 y 8 h de Etapa 1. Las 26.92 h reconstruidas quedan etiquetadas como estimadas y deben validarse contra memoria/evidencia y Jira antes de facturar; no se derivan del porcentaje de avance.

Acción: Johann debe validar el desglose reconstruido, capturar diariamente en adelante y conciliar con Jira cuando Balam otorgue acceso al flujo.

46 · Jul 16, 2026 · WhatsApp · Erika ↔ Johann · invitación Git, procedimientos y solicitud de avance

Evidencia: ../fuentes/2026-07-16 - WhatsApp - Erika invitacion Git procedimientos y avance Etapa1.md.

Erika informa que Pedro envió el 15-jul la invitación al repositorio privado y pide validar el acceso. Johann confirma por WhatsApp que ya puede entrar; queda pendiente comprobar que también tenga permisos de escritura. Erika envía por correo los procedimientos de carga de facturas por cliente y Johann confirma recepción.

Erika solicita un corte del avance de la Etapa 1. Johann se compromete a prepararlo y compartirlo por WhatsApp. Esa misma noche (8:40 pm) Johann envía por WhatsApp el Excel Plan-actividades-avance-2026-07-16.xlsx; Erika acusa recibo a las 8:44 pm ("Ntp, gracias").

Acciones derivadas:

~~Johann — validar permisos de escritura en el repositorio de Balam~~ → Comprobado (16-jul): push exitoso del scaffold inicial (backend .NET 10 + frontend Angular 21) al repo de Balam.
Johann — revisar el correo y los procedimientos de carga de facturas; documentar reglas o diferencias frente al Discovery.
~~Johann — enviar a Erika el corte de avance de Etapa 1~~ → Hecho (16-jul, 8:40 pm): Excel enviado por WhatsApp con acuse de Erika.

Estado técnico comprobado al preparar el corte: repositorio local limpio; solución .NET 10 y cliente BIND compilando; 13/13 pruebas del cliente BIND aprobadas; endpoints base /health y /api/bind/status. La base de datos, autenticación/roles, sincronización y endpoints de cartera siguen en construcción.

47 · Jul 19, 2026 · Gestión interna · demo del 18-jul no realizada; entorno local montado en la Mac

La demo semanal planeada para el viernes 18-jul no ocurrió (confirmado por Johann el 19-jul). Causa señalada: la validación del prototipo de la Etapa 0 sigue pendiente (quedó para el jue 23-jul) y eso ha retrasado el avance de la etapa. Los días 17–18 jul no registran trabajo en ../planeacion/Seguimiento-horas.csv. La próxima demo queda apuntada al viernes 24-jul (cierre de Etapa 1), donde también conviene comunicar que la capa de escritura se entrega en dry-run (ver nota en ../planeacion/Agenda-semana-2026-07-20.md).

El mismo 19-jul se montó el entorno local en la Mac: repo del cliente clonado en balam-plataforma/ (convención de ../planeacion/Plan-Etapa1.md), SDK .NET 10 instalado en usuario, token cargado en user-secrets, API corriendo (/health y /api/bind/status verificados, modo ReadOnly, 13/13 pruebas verdes) y frontend Angular servido. Se creó la agenda por día de la semana 20–24 jul (../planeacion/Agenda-semana-2026-07-20.md) y se actualizó el CSV de horas con los cortes del 16 y 19 jul.

48 · Jul 19, 2026 — noche · Desarrollo · B0+B1 completados (adelantados del lunes) + Scalar UI

Trabajo adelantado la noche del domingo siguiendo ../planeacion/Plan-Etapa1.md al pie, con asistencia de IA (Claude Code). Tiempo real registrado en ../planeacion/Seguimiento-horas.csv (~1.25 h de sesión — el plan estimaba 4–5.5 h manuales; el registro es de horas efectivamente trabajadas, conforme al contrato).

B0 — Preparación local: docker-compose.yml con Postgres 17 en puerto 5438 (5433–5437 ocupados por otros proyectos locales — difiere del 5433 que asume el plan en la otra máquina); cadena de conexión en appsettings.Development.json; DesignTimeDbContextFactory; referencia Infrastructure → Integrations.Bind; dotnet-ef 10.0.10.

B1 — Fundación de datos: entidades Tenant, Client, Invoice (modelo central: Uuid null ⇒ prefactura, OpenBalance, CfdiPaymentTermRaw, PaidDetectedAtUtc), Quote, QuoteInvoiceLink (ADR-003, con JiraTicketKey ADR-006), InvoiceStatusChange (ADR-004, fecha de detección), WriteOperation (pipeline Draft→DryRun→Confirmed, ADR-001); TenantId en SyncCheckpoint/AuditLogEntry; BalamDbContext → IdentityDbContext con llaves Guid; convenciones fechas BIND sin zona vs *Utc timestamptz y decimal(18,2)/ExchangeRate(18,6); migración Inicial aplicada (16 tablas); DbSeeder idempotente verificado: tenant Balam (GUID fijo), 4 roles, 5 usuarios ficticios *@balam.dev (password en user-secrets Seed:DefaultPassword).

Extra: UI del OpenAPI con Scalar en /scalar/v1 (solo Development). Estado verificado: API arriba con BD, 13/13 pruebas verdes, seed comprobado por consulta directa a Postgres. Cambios sin commitear en el repo del cliente — commit pendiente de Johann.

Efecto en la agenda: el lunes 20 queda libre para gestión + arrancar B2 (auth JWT + roles + bitácora) directamente.

49 · Jul 19, 2026 — noche · Desarrollo · B2 completado (adelantado del lunes): auth JWT + policies + bitácora

Continuación de la sesión nocturna asistida por IA (~0.5 h reales registradas en el CSV). Con esto el trabajo técnico planeado para el lunes 20 queda hecho; el lunes queda solo la gestión + arrancar B3 (sync de clientes).

B2 conforme al plan: POST /api/auth/login (Identity + JWT propio, sin MapIdentityApi, sin refresh en E1) y GET /api/auth/me; Jwt:SigningKey en user-secrets con fail-fast; policies nombradas (PuedeVerCartera, PuedeDispararSync, PuedeVerBitacora, PuedeOperarEscritura) con matriz provisional hasta la sesión del 22-jul; roles como constantes (BalamRoles); bitácora en dos piezas — AuditMiddleware (mutantes + 401/403) e IAuditLogger explícito — y GET /api/audit (Direccion/Administracion). Decisión aplicada del plan: BD obligatoria con fail-fast.

Verificado end-to-end contra el API corriendo: login fallido 401 (auditado una sola vez), login Finanzas 200 con token, /me 200, /me sin token 401, /api/audit con Finanzas 403 (auditado), con Dirección 200 mostrando toda la secuencia. 13/13 pruebas verdes.

Repo del cliente: 3 commits locales (5631f55 Scalar, 6264ea3 B0+B1, 4617070 B2) — push pendiente por decisión de Johann (no se hace push sin su orden explícita).

50 · Jul 19, 2026 — noche · Desarrollo · B3 completado: sync de clientes CONTRA PRODUCCIÓN + hallazgo de datos

Cierre de la sesión nocturna (~0.5 h reales más). Primer dato real de BIND viviendo en la plataforma: 16 clientes sincronizados con detalle (días de crédito 0/30/45/60/90), checkpoint registrado y ciclo auditado en bitácora.

Hallazgo de producción: hay clientes con LocationID/LoctaionID null — caso que la validación del 6-jul no encontró. Se hicieron nullable todos los GUIDs de referencia de los modelos BIND (commit fb0f066); los IDs propios siguen no-nulos. Vale mencionarlo a Pedro junto con las 5 preguntas técnicas.

B3 conforme al plan: full-scan de lista + SourceHash, detalle solo nuevos/cambiados con tope por ciclo, normalización RFC/nombre, dedup por RFC exacto excluyendo genéricos — verificado en real: el único RFC repetido es XEXX010101000 (2 clientes extranjeros) y quedó correctamente FUERA del dedup. Idempotencia comprobada: segundo run = 16 sin cambio, 1 sola petición. Consumo total del día: ~42 peticiones de 20,000.

POST /api/sync/run (Finanzas/Administración; Operaciones→403 verificado) y GET /api/sync/status. 13/13 pruebas verdes. Repo: 5 commits locales, push pendiente por decisión de Johann.

Estado de bloques al cierre del domingo: B0 ✅ · B1 ✅ · B2 ✅ · B3 ✅ — el lunes queda gestión + B4 (sync de facturas/cotizaciones + cartera, el bloque más grande) con margen de un día completo vs. el plan.

51 · Jul 21, 2026 · WhatsApp Erika ↔ Johann · estimación Jira→BIND comunicada (10 h) y alcance confirmado por Erika ⭐

Erika pidió en la mañana la estimación del cambio nuevo "para tenerla a la mano" antes de su sesión con directores. Secuencia clave:

Johann comunicó: ~10 h de desarrollo, a confirmar el miércoles 22 en la sesión con Arturo (primero cerrar reglas del flujo y validar la escritura de BIND). Quedó por escrito que "no estaba contemplado al inicio; es una mejora que surgió en el Discovery".
Erika retó con la §1.4 de la propuesta ("¿no es esto lo de las cotizaciones?"). Aclaración que quedó asentada: crear cotizaciones manualmente desde la plataforma SÍ está en el MVP (capa de escritura); lo nuevo es que los tickets de Jira las generen automáticamente. Erika encontró ella misma la §1.3 donde Jira dice "Fuera de alcance" y lo confirmó con 👍. Erika lo valida internamente con los directores.
Erika preguntó por 2 actividades vencidas en fechas del Excel (backend base y multi-tenant); Johann respondió "esas ya quedaron". Backend base ✅ real (B2); multi-tenant al ~80% — hacer B6 (RLS real) de inmediato para que la afirmación quede cubierta.
Nuevo compromiso: compartir las horas semanalmente por Excel mientras Pedro habilita Jira, con entregable + actividad + horas de cada etapa (formato pedido por Erika, lunes de corte).

52 · Jul 21, 2026 — noche · Desarrollo · B4 completado: sync de facturas/cotizaciones + cartera por moneda + SYNC HISTÓRICO ⭐

Sesión nocturna asistida por IA (~1 h real registrada en el CSV). La plataforma ya tiene la cartera completa de producción viviendo en Postgres.

B4 conforme al plan: InvoiceStatusMapper como función pura en Domain con 13 pruebas xUnit (precedencia Cancelada→Pagada→Emitida→Vencida→Vigente; "hoy" en hora MX vía MexicoTime; la frontera Emitida/Vigente se ajusta en minutos si la sesión del 22 la cambia). InvoiceSyncService con ventana única (delta por Date + re-barrido de abiertas viejas, solape 1 día, cursor que solo avanza al completar la pasada) y QuoteSyncService con sonda del filtro CreationDate + fallback a full-scan. Detección de pagos ADR-004: transición → InvoiceStatusChanges con fecha de DETECCIÓN; facturas nuevas NO generan transición (el histórico fotografía, no detecta). Campo nuevo DetailSyncedAtUtc (migración DetalleSyncPendiente) para tope de detalle 50/ciclo + backfill B5. Endpoints: GET /api/cartera (por moneda, jamás suma monedas; primer uso de PuedeVerCartera), GET /api/invoices|clients|quotes. Normalización PPD/PUE desde la etiqueta larga de BIND.

Sync histórico corrido y verificado esta noche (jamás en demo): 1,494 facturas y 43 cotizaciones, detalle 1,494/1,494 (0 pendientes), idempotencia comprobada (2ª pasada = 100% sinCambio), InvoiceStatusChanges = 0 (cero pagos falsos), 24.5 min, ~1,700 peticiones (~8.5% de cuota; cierre del día ~1,750 de 20,000). Cartera verificada BD ↔ endpoint exacto: MXN 17 abiertas $1,568,772.32 · USD 92 abiertas $320,379.06.

Hallazgos de producción: (1) el filtro CreationDate de Quotes SÍ funciona (pendiente §10 de VALIDACION-API resuelto de facto); (2) ⚠️ las 1,374 facturas con método de pago traen PUE — ninguna PPD (120 con el campo vacío). Todo el histórico se factura "pago en una sola exhibición" aunque cobran a crédito 30–90 días — preguntar a Arturo en la sesión del 22 (toca la regla PPD-default de la capa de escritura y el riesgo SAT que ellos mismos reportaron).

Commit 2e1ae82. 26/26 pruebas verdes. 7 commits locales, push pendiente por decisión de Johann.

53 · Jul 21, 2026 — noche · Desarrollo · B6: RLS real de Postgres (contractual) — código completo; verificación local pendiente de rol de app

Cierre de la sesión (~0.5 h real). B6 conforme al plan: ITenantOwned en las 8 entidades de negocio; ICurrentTenantProvider + FixedTenantProvider (ADR-005: tenant único); TenantConnectionInterceptor (set_config('app.tenant_id',…) en cada conexión, vías sync y async); filtros globales EF por entidad como segunda capa; migración RlsPorTenant a mano con ENABLE/FORCE ROW LEVEL SECURITY + política tenant_isolation (USING + WITH CHECK, fail-closed sin GUC) en las 8 tablas. Migración aplicada (catálogo confirma relrowsecurity=t, relforcerowsecurity=t en las 8); app end-to-end igual que antes (login, cartera, sync). Commit fedb376.

⚠️ Verificación de aislamiento local INCOMPLETA: la prueba psql devolvió filas sin GUC y con tenant ajeno porque balam (usuario bootstrap del contenedor) es superuser con BYPASSRLS — FORCE somete al owner, pero ningún candado somete a un superuser. El fix (pendiente de decisión de Johann, quedó en PENDIENTES): crear rol local balam_app (LOGIN, NOSUPERUSER, NOBYPASSRLS), transferirle la propiedad y apuntar la cadena de conexión de desarrollo a ese rol — replica cómo será Azure, donde el usuario de la app tampoco es superuser. Las políticas en sí son correctas; el hueco es del entorno local, no del código.

54 · Jul 22, 2026 — 7:00 AM · Llamada · Sesión de reglas Etapa 1: alta de clientes, fee bancario y flujo Jira ⭐

Participan: Noe Rocha (sala de juntas), Arturo Rosas, Araceli (se suma ~min 21 para el tema del fee) y Johann. Erika no participó. Duración ~48 min. Transcripción: ../fuentes/2026-07-22 - Flujo para dar de alta clientes nuevos,_ Transcript.txt. Agenda preparada en ../planeacion/Sesion-Etapa1-2026-07-22.md.

Resumen: Se resolvieron 3 de los temas de la agenda: alta de cliente/proveedor en BIND (demostrada en pantalla por Arturo), tratamiento del fee bancario (lo registra el despacho, no Balam) y flujo Jira de facturación (estatus, validaciones y confirmación de que Jira ya es parte del proceso). Quedaron fuera: particularidades de envío, la pregunta PUE/PPD y el cierre técnico (repo/Azure/Jira horas).

1 · Alta de cliente/proveedor en BIND (ASIS, demostrado por Arturo):

Mismo procedimiento para clientes (módulo Ventas→Clientes) y proveedores (Compras→Proveedores). Botón Agregar → 2 pestañas: Detalle y Direcciones.
Detalle: razón social, RFC, nombre comercial y categoría se toman de la constancia de situación fiscal; banco y CLABE del estado de cuenta del cliente. Días y monto de crédito vienen de la negociación comercial (no de un documento). Además: correo de comunicación, sucursal (solo existe matriz), teléfono, uso CFDI (mayoría "gastos en general", según constancia), régimen fiscal e idioma de documentos (p. ej. BICTEX → inglés). Clientes agregan: ventas esperadas, lista de precios, descuento pactado.
Direcciones: país/estado/municipio/calle/CP, también de la constancia. Al guardar, BIND asigna un ID interno consecutivo (ej. 1016), exclusivo de la instancia de Balam.
En editar se pueden adjuntar archivos: constancia, carátula bancaria, NDA, contrato marco — todo en un solo lugar.
El alta nace del área comercial: cuando una propuesta pasa a firme, administración da de alta al cliente. Caso reciente: Frisa.
Extranjeros (ej. Acuntia): documento legal/fiscal del país en lugar de constancia; BIND propone un RFC genérico; uso CFDI = "sin efectos fiscales"; la factura al extranjero genera solo PDF, sin XML ni timbrado SAT (se registra como gasto/ingreso extranjero sin obligaciones fiscales).
No se hizo alta en vivo (producción, sin datos de prueba). Arturo se comprometió a grabar y documentar los procesos nuevos conforme ocurran (Frisa está por facturarse; hará manuales Word/PowerPoint).

2 · Fee/comisión bancaria (con Araceli):

El fee NO lo registra Balam: lo registra y deduce contablemente el despacho, para que la factura quede saldada al 100% sin residual de deuda del cliente. Balam solo concilia estado de cuenta ↔ facturas pagadas.
El fee solo aplica a pagos internacionales que mueven dinero hacia México (ej. Europa→Banorte; varía según banco emisor). Los pagos nacionales cuadran a centavos, sin fee. BigTech paga de banco americano a banco americano de Balam → sin fee.
El monto del fee no es predecible (no hay reglas conocidas), pero siempre viene marcado en el estado de cuenta ("comisión", "IVA sobre comisión"). Por eso es crítico pedir el estado de cuenta al cliente — además Accent/Axios tiene muchas facturas por el mismo monto y sin estado de cuenta no se sabe cuál pagaron.
Regla para la plataforma: el agente de conciliación solo debe identificar la diferencia como fee bancario; quién autoriza saldar la factura con diferencia es el despacho, a nivel contable. Hoy el caso vivo es Acuntia.

3 · Jira (flujo de facturación) — confirmado que SÍ entra en la fórmula:

Noe reconoció explícitamente que el alcance inicial decía "sin Jira" pero el proceso interno evolucionó y hoy todo pasa por Jira; la integración se pone sobre la mesa como ajuste.
Space "Facturación" separado (hay otros: administración general, GEDEX, RH), con un solo request type hoy (facturación adicional/recurrente) — el universo de tickets de facturación está cerrado y filtrable.
Flujo de estatus del ticket: inicia → abierto → proceso de facturación (confirmar monto, cliente dado de alta, constancia vigente, cuenta bancaria) → validación (nacional: adjuntar PDF + XML obligatorios; internacional: solo PDF) → facturado → resuelto. El estatus que confirma facturación válida es "resuelto" (el anterior solo es validación en curso). Las validaciones nacieron de desaciertos operativos reales ("ya facturé" sin evidencia).
Facturación recurrente: ~30 facturas/mes salen de un flujo recurrente por contratos establecidos — es proceso de Balam ejecutado en BIND, no capacidad nativa de BIND, y siempre con intervención humana (los montos pueden variar mes a mes). Pedirá sesión aparte con Pedro para entenderlo.
Forecast contractual a largo plazo: BIND solo proyecta sobre lo ya facturado (por plazo de pago); Noe quisiera a futuro proyección por contrato — explícitamente NO es para ahora.

4 · Escritura en BIND / prueba Jira→cotización: Johann planteó probar el flujo ticket Jira → cotización BIND (cotización→prefactura→factura). Noe accedió a explorarlo pero con advertencia fuerte: no hay ambiente de pruebas, es producción directa — "muy, muy medida la prueba… para no hacernos harakiri". La escritura será acordada y controlada llegado el momento.

Acuerdos / próximos pasos que anotó Noe:

Balam (Arturo/Pedro) — enviar a Johann el diagrama del flujo Jira en tamaño legible (el screenshot se veía ilegible en la llamada).
Balam (Erika coordina) — sesión con Pedro (+Arturo) para: API de Jira (explorar conexión), facturación recurrente y facturas automáticas vs manuales.
Confirmado: mañana jueves 23-jul, sesión de validación del prototipo.

Lectura estratégica:

Jira→BIND avanza: Noe aceptó en voz alta que Jira ya es parte del proceso y encaminó API + sesión con Pedro — coherente con la estimación de ~10 h comunicada a Erika el 21-jul (#51). El disparador de facturación es el estatus "resuelto"; para crear cotizaciones el candidato natural es un estatus previo (a confirmar con Pedro en la sesión de API).

El fee simplifica el MVP de conciliación: la plataforma NO registra ajustes contables — solo detecta y etiqueta la diferencia como fee bancario en pagos internacionales. El asiento es del despacho. Esto acota el alcance justo donde la agenda temía ambigüedad.

Alta de clientes: quedó mapeado el ASIS completo, pero no se decidió si la plataforma solo detecta clientes faltantes o también los crea — la pregunta del MVP sigue abierta y toca la estimación Jira→BIND (#51): un ticket de un cliente inexistente en BIND cruza ambas piezas.

No se tocaron: la pregunta PUE vs PPD (1,374 facturas históricas todas PUE, #52) — reintentarla el 23-jul o con Pedro—, las particularidades de envío (Excel sigue pendiente de Ara/Arturo) y el cierre técnico (Azure/Jira horas).

Factura extranjera sin XML confirma el diseño del prototipo (PDF-only para internacionales) y explica por qué la validación de Jira solo exige PDF en ese ramal.

55 · Jul 24, 2026 — 11:00 AM · Llamada · Validación del prototipo Etapa 0 — APROBADO (queda 1 definición de proceso) ⭐

Participan: Erika Chávez (abre), Johann (presenta), Noe Rocha, Araceli Sánchez, Arturo Rosas. Duración ~1 h 4 min. La sesión estaba agendada para el jueves 23-jul 7 am pero se corrió al viernes 24-jul 7 am porque Araceli (dueña del proceso) tuvo un tema personal (reagenda documentada en #57). Transcripción: ../fuentes/2026 - 07 - 24 - Validación de prototipo etapa 0- proyec_ Transcript.txt. Guion usado: ../planeacion/Guion-validacion-prototipo-2026-07-23.md.

Veredicto: Etapa 0 validada. Johann recorrió el PDF y luego el prototipo navegable (URL). Ara: "Johann nos captó absolutamente todo lo indispensable y más… de momento no le pondría nada", "Me encantó", "Sí a todo". Arturo: "yo no le pondría nada más… esto es lo mínimo que necesitamos". Ambos aprobaron el MVP tal cual. Queda pendiente UNA sola cosa del lado de Balam: redefinir el flujo de facturación en Jira (ver abajo) antes de volver con Johann para hacer el MVP productivo. Erika confirmó que esto no bloquea a Johann, que ya está en Etapa 1.

El único bloqueo real — definición de proceso (no de sistema): hoy el CIS de Jira exige que la factura se haga antes de cerrar el ticket, es decir el proceso de facturación ya no arrancaría desde el sistema. Hay que decidir si la ejecución (prefactura) se dispara desde la plataforma (lo deseable, para que el sistema optimice) o se sigue haciendo antes y solo se presenta al sistema. Arturo pidió explícitamente que sea PREFACTURA, no timbrado automático: validación previa (nacional vs extranjera, montos, datos fiscales) para evitar cancelaciones que el SAT observa; "para ir monitoreando la eficiencia de la IA. Tal vez en algún futuro daremos independencia completa". Ara sale de viaje mié/jue/vie; propuso el martes 28-jul para esa sesión; Erika coordina. Es prerrequisito para que Johann conecte el frontend a la escritura.

Decisiones y aclaraciones que quedaron asentadas:

Cotización SIEMPRE, sin excepciones (Ara). Incluso las recurrentes (contrato AXIANS 3–4 años) deben nacer de una cotización → prefactura/factura. Es un punto de control para cazar cambios (sueldos, viáticos, ajustes) y errores. "El esfuerzo es el mismo": la cotización vive en BIND y se convierte a prefactura/factura con un clic. Noe lo cerró como 3 candados: cotización → prefactura → aprobación humana → timbrado.
Nada de agente de IA en este MVP (Noe, muy vocal, lo repitió 3 veces): esto es reglas de negocio + procesos + integración de sistemas para homologar pantallas, no LLM. La IA llega después; el candidato claro para agente es conciliación (hoy 100% manual). Primero la base de proceso, "si le metemos IA de inicio va a ser una fiesta". Johann alineado: el MVP asienta el proceso para montar los modelos encima.
Roles: la plataforma ya los soporta; por ahora Ara y Arturo ven todo, se acotan cuando entre un analista.
Dashboard: las 4 tarjetas son propuesta, todo customizable. "Qué necesita atención" se alimentaría de Jira + estatus de facturación. Posible acople con el Power BI de aging de Pedro (no duplicar reporteo).
Fuente única = BIND (Vine) o Jira. No hay fuente alterna. Cartera vencida sale de BIND; lo que no esté en BIND requeriría carga/capa manual.
Un ticket = una factura (hoy). Caso ACUNTIA/Accions: un solo ticket con un Excel de 40–48 facturas. Queda abierto si se maneja como ticket-por-factura o un ticket con múltiples hijos (definición de proceso, va con el punto del bloqueo).
Todo nace en Jira — política de empresa: "Lo que no está en JIRA no se procesa." Ni correo ni mensaje; incluso los correos se reenvían a una dirección que auto-crea el ticket.
Envío con particularidades por cliente: validado y les gustó (CEMEX bloqueado por faltar Excel de horas; ACUNTIA = zip con PDF+XML+estado de cuenta). El módulo de configuración de reglas de envío queda cerrado/hardcodeado al inicio; si cambian reglas, se cobra como horas de servicio. No se desarrolla ahora.
NAFINSA / cadenas productivas (solo CEMEX): facturas ya programadas para pago (p. ej. cae 24-sep, 120 días) que no existen como estatus en BIND. Quieren una capa/pantalla extra "programado para pago" para planeación financiera (Arturo: "la cerecita del pastel"). Idea de Ara: ticket Jira automático cada 15 días para revisar el portal Nafinsa, adjuntar Excel/pantallazos y alimentar cuentas por cobrar, haciendo match por folio. A evaluar con Johann.
Fee: tolerancia configurable por cliente (% o fijo); se muestra como "pagada pero con tolerancia". (Consistente con #54: el asiento contable es del despacho, la plataforma solo detecta/etiqueta.)
Recordatorios internos en el MVP: D+1 → Arturo, D+15 → Araceli. Los correos al cliente (D+5, D+30) NO son alcance ("no está definida la regla"). Excepciones de seguimiento por cliente contempladas.
Bitácora/auditoría: "Me encanta, sí a todo."

Observaciones que anotó Noe sobre el prototipo: (a) un ticket rotulado "facturación nacional" era extranjera → pedía XML+PDF cuando extranjera es solo PDF (ajuste menor); (b) los estatus del prototipo son placeholders previos a explorar Jira ("listo para facturar" ≈ "facturado" en Jira real) y se adaptarán al flujo que Balam defina.

Cierre y próximos pasos:

Balam hace teamback para separar must vs nice-to-have y define el flujo de facturación/prefacturación (sesión martes 28-jul, Erika coordina).
Antes del go-live habrá una prueba muy observada de prefacturación (primera escritura real sobre BIND), paso a paso y validada.
Sesión con Pedro para el API de Jira queda encaminada (se materializó el 27-jul, #56).
Johann: montar el frontend, conectarlo al backend ya construido (cliente BIND, auth, multi-tenant, BD) y hacer las pruebas.

Lectura estratégica:

Etapa 0 cerrada en la práctica con validación entusiasta de los dueños del proceso (Ara y Arturo) y respaldo de Noe. El entregable de Etapa 0 quedó aprobado; el único hilo suelto es una definición de proceso de Balam, no una carencia del prototipo.

"Cotización siempre" es una decisión firme que simplifica la capa de escritura (B7): un solo camino cotización→prefactura→aprobación→timbre, sin ramas de excepción para recurrentes. Elimina ambigüedad que la agenda temía.

PUE/PPD no se retomó en esta sesión — sigue abierta desde #52 (1,374 facturas históricas todas PUE). Reintentarla con Arturo en la sesión del 28-jul o con el flujo Jira.

Dos capacidades nuevas asomaron fuera del MVP core: "programado para pago"/planeación financiera (Nafinsa) y el espacio "comercial" en Jira para generar cotizaciones. Ambas son candidatas a ampliación (horas extra), útiles para el pipeline comercial, pero no deben inflar el MVP — es justo lo que Noe pidió filtrar con el teamback.

La prueba observada de prefacturación es el hito de riesgo antes del go-live: es la primera escritura real sobre producción. Los candados acordados (dry-run, confirmación humana por factura, feature flag) son el seguro.

56 · Jul 27, 2026 — mañana · Llamada · Sesión API de Jira con Pedro: token comprometido y bandeja "Facturación" (FAC) identificada ⭐

Participan: Noe Rocha, Erika Chávez, Pedro Ayala (TI, dueño de Jira), Johann. Duración ~12 min. Transcripción: ../fuentes/2026-07-27 - API de conexión con JIRA Transcript.txt. Es el Discovery de API que quedó encaminado el 22-jul (#54) y ratificado el 24-jul (#55).

Objetivo (Noe): el Discovery mostró que buena parte del proceso de facturación llega por Jira, conectividad que originalmente no se contempló y que ahora sí será necesaria. Pedro explica cómo se conecta hoy vía API.

Lo que confirmó Pedro:

Usa el API de Jira para varios tableros de TI (limpieza de usuarios, aprobadores, conectores, SLAs). Funciones: crear y consultar actividades/tickets, aprobaciones, documentos adjuntos, cambio de estatus. Es de lectura Y escritura — todo accionable ("cualquier creación que se haría manual se puede hacer por API"). Cubre el CRUD que Johann necesita.
Token comprometido: Pedro genera una API key llamada "PAF" (Plataforma de Automatización Financiera), expiración a 1 año — 27-jul-2027. La envía por correo en TXT junto con la documentación de desarrolladores de Atlassian (informativa). Ya la tenía lista al cierre de la llamada.
Límites de consumo: a diferencia de BIND (20K/día), Pedro cree que Jira no tiene tope por día; lo investigará en Atlassian y lo revisa con Johann. Noe quiere saber el límite de transacciones por escritura/consulta para planear la operación.
Los tokens se generan desde la cuenta de Pedro, diferenciados por nombre; buena práctica rotarlos.

Identificación de dónde consultar (aclaración importante): no es "tablero" (eso es Power BI) sino el Space de Jira. Los tickets de facturación viven en la bandeja/space "Facturación", con llave FAC- + número. Otras bandejas: Administración General (AG), ITS (DITCM), Recursos Humanos (RH), Facturación (FAC), HD. El API es global (extrae de todas), pero la que importa es Facturación, que funciona como bandeja "padre": procesos que se cierran en RH o Administración General caen en Facturación. Este es el insumo que Johann pidió el 24-jul para saber de dónde extraer los tickets.

Próximos pasos acordados:

Pedro → enviar por correo: token TXT (PAF) + documentación Atlassian; investigar límites de consumo. → CUMPLIDO el mismo día (ver seguimiento).
Johann → revisar la documentación de Jira/Atlassian; con la key, integrar la consulta al prototipo. Construir un script de consulta y también scripts de creación/edición/eliminación sobre un registro de prueba. Noe: no existe un CRUD previo por API; cuando llegue el momento se hace una prueba en vivo de creación. Johann es el checkpoint — avisa cuando necesite prueba o tenga dudas.

Seguimiento — correo de Pedro del mismo día (27-jul, 7:40 am; CC Noe y Erika): ../fuentes/2026-07-27 - Correo - Pedro medicion de consumo API Jira y token.md. Johann acusó recibo ("Enterado, muchas gracias Pedro! Saludos").

No hay límite de volumen ("X llamadas al mes") ni costo extra de licencia por usar la API. Hay 3 límites de velocidad en paralelo, cualquiera devuelve HTTP 429 (RateLimit-Reason indica cuál):
1. Cuota por puntos/hora: 1 punto base + 1 por objeto de dominio (issues, proyectos) o 2 por objeto de identidad (usuarios, grupos, roles); las escrituras solo cobran el punto base. Bolsa por defecto 65,000 puntos/hora.
2. Burst por segundo: 100 req/s GET y POST, 50 PUT y DELETE, bucket por endpoint y por tenant. Consulta de clientes de service desk topada a 5/s.
3. Por issue en escrituras: 20 ops/2 s y 100/30 s sobre un mismo ticket.
No existe dashboard de consumo (limitante de Atlassian): consola de desarrolladores solo muestra el tier de apps propias; el detalle por token exige Atlassian Guard Premium (licencia aparte); las apps de Marketplace estiman por muestreo. Única fuente confiable = headers de respuesta: X-RateLimit-Limit/Remaining/NearLimit (NearLimit se activa con <20% de capacidad) y en 429 además X-RateLimit-Reset, Retry-After, RateLimit-Reason.
Token entregado vía enlace de Google Drive (carpeta compartida). ⚠️ Tratar como credencial: mover a user-secrets/Key Vault, no dejar en texto plano.

Lectura estratégica:

Desbloqueo clave para B7/Jira→BIND: con token de escritura a 1 año y la bandeja FAC identificada, se habilita tanto la lectura de tickets como la automatización Jira→cotización BIND estimada en ~10 h (#51). El API confirmado como read+write despeja el mayor riesgo de la integración.

"Facturación como bandeja padre" es un dato de arquitectura relevante: consultar solo FAC puede no bastar si el disparador nace en RH/AG y cae en FAC — validar en las pruebas si conviene escuchar la bandeja padre o rastrear los procesos origen.

Límite de consumo resuelto (correo 27-jul): no hay tope mensual; 3 límites de velocidad (puntos 65k/h, burst/s, por-issue en escrituras) sin dashboard nativo → el sync debe autorregularse leyendo los headers X-RateLimit-* (pausar en NearLimit, respetar Retry-After en 429). Las escrituras son baratas en puntos (solo el base), lo que favorece la capa de escritura frente a las consultas de identidad (2 puntos c/u).

Pendiente de proceso aún abierto: qué estatus de Jira dispara qué (facturación vs cotización) sigue amarrado a la definición del martes 28-jul (#55) — la conectividad ya está, la regla de negocio no.

57 · Jul 21–27, 2026 · WhatsApp Erika ↔ Johann · coordinación de sesiones, envío del flujo de facturación y reagenda 23→24 jul

Hilo de coordinación que complementa la parte de fondo del 21-jul (#51) y enlaza la sesión de reglas del 22-jul (#54), la validación del 24-jul (#55) y la sesión de API de Jira del 27-jul (#56). Transcripción completa (con imágenes inferidas): ../fuentes/2026-07-21 a 2026-07-27 - WhatsApp - Erika coordinacion sesiones validacion y API Jira.md.

21-jul (tarde): Johann propuso compartir las horas por Excel mientras se habilita Jira; Erika pidió el formato entregable + actividad + horas por etapa. Erika cuestionó si lo de las cotizaciones ya estaba (📷 captura) → Johann aclaró que crear cotizaciones sí está en el MVP y que lo nuevo (Jira genere la cotización en BIND automáticamente) requeriría acceso técnico a Jira + escritura controlada en BIND. Erika confirmó por su cuenta que Jira dice "fuera de alcance".

22-jul: Erika se disculpó por no asistir a la sesión de reglas de esa mañana ([#54]; avisó a los ingenieros para que la tomaran igual). Preguntó dos veces si se ajustará la propuesta por el cambio de la integración Jira → compromiso de Johann: enviar el conteo de horas + la propuesta ajustada "entre hoy y mañana" (para el 23-jul). Erika propuso la sesión de API de Jira con Noe y Pedro y confirmó que ya envió por correo el flujo de facturación de Jira (2:26 pm).

23-jul (reagenda): por un tema personal de Araceli (dueña del proceso), la validación del prototipo se movió de jueves 23-jul 7 am a viernes 24-jul 7 am. La sesión de API de Jira se movió de viernes 24-jul 7 am → 7 pm → finalmente lunes 27-jul 7 am por disponibilidad de Pedro. Erika preguntó si "esta actividad se acabó ayer" (📷 captura del plan) → Johann: sí, falta la prueba de escritura en BIND pero ya está.

24-jul: intercambio de arranque; se conectan a la sesión de validación ([#55]).

27-jul (mañana): Erika pidió los avances de la Etapa 1; Johann preguntó si ya existe el Jira del proyecto — justo antes de la sesión de API donde Pedro compromete el token PAF ([#56]).

Pendientes que deja el hilo:

Johann — enviar conteo de horas (Excel: entregable + actividad + horas por etapa) + propuesta ajustada por la integración Jira→BIND. ⚠️ Comprometido para el 23-jul — verificar si ya se envió.
Johann — entregar avances de Etapa 1 solicitados el 27-jul.
Conservar el correo del flujo de facturación de Jira (Erika, 22-jul) como evidencia/insumo.

Nota de imágenes: las capturas no vienen en el volcado; se infieren tres adjuntos por los deícticos ("esto", "esta actividad") — cotizaciones (21-jul 12:58), "fuera de alcance" (21-jul 1:03, confianza media) y actividad del plan (23-jul 11:29). Detalle en el archivo de fuentes.

Resumen ejecutivo del hilo (para contexto rápido)

Datos duros confirmados por Balam

BIND ERP: API existe y es viable (confirmado 25-may). Límite 20K req/día. PAC para CFDI integrado en BIND.
BUK: ✅ tiene API (confirmado 27-may por Pedro). No es prioridad para MVP — habilita Fase 2 post-MVP. Link pendiente de recibir.
Bancos: 3 bancos, solo PDFs. Banco americano = IBC Bank Texas (confirmado en llamada del 19-may).
Sandbox: solo producción (BIND y BUK).
Volumen: 45 colaboradores + 5 freelancers, ~55 facturas/mes de 4–6 clientes (el mayor exige 1 factura por colaborador, ~40) — actualizado 6-jul.
EUR: fuera del MVP; solo MXN + USD.
Lista blanca cobranza: ~~ACUNTIA + top 3, configurable~~ → ELIMINADA (6-jul): Ara decidió recordatorios a todos los clientes morosos, sin excepciones. (La capacidad configurable se conserva, hoy vacía.)
Cotización BIND obligatoria (6-jul): todo lo que se facture parte de una cotización en el ERP (requisito fijado por Ara).
Flujo actual: Jira ITSM mandatorio (~1 mes) → validación administración (Arturo) → prefactura BIND → CFDI → envío por correo con particularidades por cliente (Excel pendiente de Ara/Arturo).
Cobranza actual (mapeada 7-jul): el cliente avisa el pago por correo/mensaje (estado de cuenta) → el despacho contable registra los pagos en BIND uno por uno → Power BI de cartera (desactualizado). Se concilia por folio (la referencia no distingue facturas); los fees generan diferencias contra el total. Quieren recordatorios proactivos (1–5 días de vencimiento).
Book = SaaS (no interno).
Jira: solo gestión de proyectos con clientes.
Nube preferida: Azure.
Contacto operativo durante MVP: Noe + gerente administrativo.

Pendientes que Ara (Araceli) debía responder

Banco americano específico (resuelto en llamada: IBC Texas).
Tax compliance para clientes Texas (resuelto en llamada: estándar).
Tickets físicos en pagos con tarjeta.
Guía de marca / assets.

Señales clave del CTO

Llamada del 19-may (transcript aparte): Noe pidió textualmente "no le queremos estar poniendo estrellitas al pino, nada más estrictamente lo que se necesita". Foco = facturación + conciliación.
Correo del 25-may: Noe pide explícitamente que la propuesta se recorte a "solo ERP BIND" primero, dejando bancos/conciliación para fase posterior.

Estado actual (al 15-jul-2026 — Etapa 0 en validación, Etapa 1 iniciada en local)

Contrato firmado, kickoff y Discovery completos. El prototipo de la Etapa 0 fue entregado por correo el 10-jul y Balam lo revisa internamente. La sesión formal de validación quedó confirmada para el jueves 23-jul a las 7:00 pm.

Johann inició en local las actividades independientes de Etapa 1. La sesión para cerrar dudas y reglas quedó el miércoles 22-jul con Arturo y la CEO. Deben resolverse alta de cliente nuevo, tratamiento del fee, particularidades de envío y si la automatización Jira → cotización BIND se incorpora al alcance.

Accesos: token BIND y manual de marca recibidos; repositorio GitHub autorizado por Noé y en proceso de invitación para Johann-28; Azure programado para la semana del 21-jul; CI/CD y secretos separados para el 24-jul. Jira técnico no se necesita salvo que se apruebe la integración automática Jira→BIND.

Comercial: propuesta v1.2 recibida por Erika, pero la confirmación para emitir la factura de 30 h sigue pendiente mientras Noé y la CEO están fuera del país. No hay rechazo ni pago vencido.

Seguimiento: se abrió control local de horas en ../planeacion/Seguimiento-horas.csv. El Excel de cobranza/días vencidos queda condicionado a la retroalimentación del prototipo; el Excel de particularidades de envío sigue pendiente de Balam.

Términos vinculantes del contrato: sin anticipo + firma previa (cumplida) · facturación semanal los viernes por horas efectivamente trabajadas, pago a 30 días · garantía 45 días · alcance MVP BIND-first · arranque condicionado a accesos + API de BIND con lectura/escritura.

Calendario vigente: Etapa 1 en local desde 13-jul · repo 15–16 jul · Azure semana del 21-jul · sesión de reglas 22-jul · validación prototipo 23-jul · CI/CD y secretos 24-jul. Etapas 2–3 se afinan después de esas validaciones.

Acciones inmediatas de Johann: capturar/reconstruir horas reales; aceptar y validar el repositorio; continuar backend local; preparar las preguntas del 22-jul; cerrar hallazgos/ADRs tras las sesiones; mantener lista la factura sin emitirla todavía.

En espera de Balam: invitación al repo, acceso Azure, flujo Jira para horas, Excel de particularidades de envío, definiciones de Arturo/CEO y confirmación para emitir la primera factura.

Pendiente menor: (opcional) pedir copia limpia del contrato — la cláusula de Firma Electrónica de la última página quedó duplicada y aún dice "EL PATRÓN" (residuo de plantilla, bajo riesgo).

Conciliación: sigue como posible primer alcance si el Discovery libera horas (mini-scope + estimación al cierre del Discovery).

119 KiB Raw Blame History Unescape Escape

REGISTRO · Bitácora de comunicaciones — Proyecto Balam

1 · Apr 30, 2026 — 4:38 PM · Erika Chavez → Johann

2 · May 4, 2026 — 3:30 PM · Johann → Erika (CC Noe, Ara)

Integraciones

Facturación

Cobranza

Datos y sistemas

Operación

Infraestructura y diseño

3 · May 4, 2026 — 7:59 PM · Noe Rocha → Johann (respuestas inline)

3a · May 6, 2026 — Araceli Sánchez → Johann · respuestas "en verde"

3b · May 6, 2026 — Johann → Balam · acuse

4 · May 8, 2026 — 5:06 PM · Johann → Noe

5 · May 11, 2026 — 5:47 PM · Noe → Johann

6 · May 12, 2026 — 10:27 PM · Johann → Noe

7 · May 16, 2026 — 10:32 AM · Noe → Johann

7a · May 16, 2026 — Johann → Noe · confirma sesión + comparte teléfono

8 · May 25, 2026 — 10:41 PM · Noe → Johann

9 · May 27, 2026 — AM · Pedro (desarrollador, Balam) → Johann ⭐ (último mensaje)

10 · May 29, 2026 — 2:44 PM · Johann → Noe (CC Ara, Erika, Pedro) · envío de la propuesta

11 · Jun 2, 2026 — 5:33 PM · Pedro → Johann, Noe (CC Ara, Erika)

12 · Jun 2, 2026 — 9:39 PM · Johann → Pedro, Noe (CC Ara, Erika)

13 · Jun 3, 2026 · Pedro → Johann, Noe (confirmación + liga Teams)

14 · Jun 4, 2026 — 7:00 AM · Llamada de revisión de propuesta ⭐

15 · Jun 8, 2026 — 6:15 PM · Correo · Noe → Johann (CC Ara, Erika, Pedro) · aclaraciones y preguntas

16 · Jun 10, 2026 — 6:11 PM · Johann → Noe (CC Ara, Erika, Pedro) · respuesta + propuesta v1.1

17 · Jun 16, 2026 — 3:35 PM · Noe → Johann, Pedro (CC Ara, Erika) · luz verde ⭐

18 · Jun 25, 2026 — Balam (vía Paola, RH) → Johann · contrato de servicios para firma

19 · Jun 26, 2026 — WhatsApp Johann ↔ Paola (RH) · ajustes finales y FIRMA del contrato ⭐

20 · Jun 29, 2026 — WhatsApp Erika → Johann · arranque del plan de actividades ⭐

21 · Jun 29–30, 2026 — WhatsApp Johann ↔ Erika · plan de actividades entregado + kickoff agendado ⭐

22 · Jul 1, 2026 — 7:00 AM · Llamada · Kickoff del proyecto ⭐

23 · Jul 1, 2026 — 7:33 AM · Correo · Pedro → Johann · manual de imagen corporativa

24 · Jul 1, 2026 — WhatsApp Erika ↔ Johann · agenda la sesión "Proceso actual de facturación y cobranza" (lunes 6-jul)

25 · Jul 2, 2026 — 4:18–4:41 PM · WhatsApp Erika ↔ Johann · agenda/materiales para la sesión del 6-jul

26 · Jul 2, 2026 — 5:39 PM · Correo · Johann → Noe (CC Ara, Erika, Pedro) · envío de la propuesta v1.2

27 · Jul 6, 2026 — 7:00 AM · Llamada · Discovery: proceso actual de facturación y cobranza ⭐

El proceso actual, paso a paso

Dolores (en palabras de Ara, dirección general)

🔄 Cambios de reglas de negocio (decididos en la sesión)

28 · Jul 6, 2026 — 9:01 AM–12:40 PM · WhatsApp Erika ↔ Johann · token de BIND ENTREGADO ⭐

29 · Jul 6, 2026 — 12:38 PM · Correo · Pedro → Johann (CC Noe, Erika) · entrega formal del token de BIND ✅

30 · Jul 6, 2026 — 3:01 PM · WhatsApp Johann → Erika · propone sesión de cobranza (martes 7-jul)

31 · Jul 6, 2026 — 4:33 PM · Correo · Noé → Johann, Pedro (CC Erika) · salvaguardas sobre el token ⚠️

32 · Jul 6, 2026 — tarde · Validación técnica de la API de BIND con la cuenta real ⭐ ✅

33 · Jul 6, 2026 — 4:34–5:03 PM · WhatsApp Erika → Johann · confirma operar solo-lectura (eco del correo de Noé)

34 · Jul 6, 2026 — 6:36–6:40 PM · WhatsApp + convocatoria Outlook/Teams · confirma sesión de cobranza (martes 7-jul) ⭐

35 · Jul 7, 2026 — 7:00 AM · Llamada · Discovery: proceso actual de cobranza (sin grabación) ⭐

36 · Jul 7, 2026 — 12:27 PM · WhatsApp Erika → Johann · seguimiento del pendiente de BIND (¿probar escritura?)

37 · Jul 7, 2026 — 3:56–5:49 PM · WhatsApp Erika ↔ Johann · seguimiento al usuario de lectura de BIND

38 · Jul 8, 2026 — 10:09 AM–10:55 AM · WhatsApp Erika ↔ Johann · datos ficticios para los Exceles de cobranza

39 · Jul 9–10, 2026 · WhatsApp Erika ↔ Johann · avance de Fase 0 + prototipo sin sesión de validación agendada

40 · Jul 10, 2026 · Correo · Johann → Erika, Noé (CC Pedro) · entrega del prototipo Etapa 0 ⭐

41 · Jul 13, 2026 · WhatsApp Erika ↔ Johann · continuidad de Etapa 1, sesión con Arturo y factura de 30 h

42 · Jul 14, 2026 · WhatsApp Erika ↔ Johann · dos sesiones confirmadas para 22–23 jul

43 · Jul 14–15, 2026 · WhatsApp Erika ↔ Johann · ajuste de accesos y repositorio GitHub autorizado

44 · Jul 14, 2026 · WhatsApp Erika ↔ Johann · Excel de días vencidos condicionado a validación

45 · Jul 15, 2026 · Gestión interna · se inicia control local de horas

46 · Jul 16, 2026 · WhatsApp · Erika ↔ Johann · invitación Git, procedimientos y solicitud de avance

47 · Jul 19, 2026 · Gestión interna · demo del 18-jul no realizada; entorno local montado en la Mac

48 · Jul 19, 2026 — noche · Desarrollo · B0+B1 completados (adelantados del lunes) + Scalar UI

49 · Jul 19, 2026 — noche · Desarrollo · B2 completado (adelantado del lunes): auth JWT + policies + bitácora

50 · Jul 19, 2026 — noche · Desarrollo · B3 completado: sync de clientes CONTRA PRODUCCIÓN + hallazgo de datos

51 · Jul 21, 2026 · WhatsApp Erika ↔ Johann · estimación Jira→BIND comunicada (10 h) y alcance confirmado por Erika ⭐

52 · Jul 21, 2026 — noche · Desarrollo · B4 completado: sync de facturas/cotizaciones + cartera por moneda + SYNC HISTÓRICO ⭐

53 · Jul 21, 2026 — noche · Desarrollo · B6: RLS real de Postgres (contractual) — código completo; verificación local pendiente de rol de app

54 · Jul 22, 2026 — 7:00 AM · Llamada · Sesión de reglas Etapa 1: alta de clientes, fee bancario y flujo Jira ⭐

55 · Jul 24, 2026 — 11:00 AM · Llamada · Validación del prototipo Etapa 0 — APROBADO (queda 1 definición de proceso) ⭐

56 · Jul 27, 2026 — mañana · Llamada · Sesión API de Jira con Pedro: token comprometido y bandeja "Facturación" (FAC) identificada ⭐

57 · Jul 21–27, 2026 · WhatsApp Erika ↔ Johann · coordinación de sesiones, envío del flujo de facturación y reagenda 23→24 jul

Resumen ejecutivo del hilo (para contexto rápido)

Datos duros confirmados por Balam

Pendientes que Ara (Araceli) debía responder

Señales clave del CTO

Estado actual (al 15-jul-2026 — Etapa 0 en validación, Etapa 1 iniciada en local)

119 KiB

Raw Blame History