balam/bitacora/REGISTRO.md

# 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](README.md). Material crudo (transcripciones, .eml, PRD) en [`../fuentes/`](../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 → 10 jul 2026 (última actualización: avance de Fase 0 + envío del prototipo por correo, 10-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:

1. **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.
2. **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.
3. **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:

- [Referencia API · Portal de desarrolladores · Bind ERP](https://developers.bind.com.mx/api-details#api=bind-erp-api&operation=Activities_AddActivity)
- [API de Bind ERP — sitio de ayuda](https://ayuda.bind.com.mx/hc/es/articles/360007437754-api-de-bind-erp)

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:**
1. **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).
2. **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).
3. **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.
4. **Lista blanca:** confirmado que es **configurable**, no limitada a 3.
5. **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.
6. **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é**.
7. **Azure:** se gestiona con **Guajardo / Erika**. Johann requiere permisos para crear App Service + PostgreSQL (no Global Admin).
8. **Manual de marca:** existe (paleta, tipografía, logos); **Pedro lo envía**.
9. **Reglas de negocio:** se definen con **Arturo + Pedro**.
10. **Metodología IA:** aclarado = no se entrenan modelos con datos de Balam. Noe OK.
11. **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ó.
12. **Gestión del proyecto:** en **Jira** (estilo ágil/Yael, no Gantt). Pedro crea el espacio (plan free); **Erika valida entregables** para el pago.
13. **Comunicación:** canal de **WhatsApp** + correo para evidencia formal. **Erika = contacto principal · Pedro = técnico · Arturo = negocio.**
14. **Fiscal (Johann):** en proceso de cambiar régimen (24 h); confirma que **sí puede facturar**.
15. **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:**
1. 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.*
2. **Soporte:** el límite de consumo **mensual** es limitante; piden **bolsa de horas vigente 12 meses** (paquetes por hora, no mensualidad con caducidad).
3. **Garantía:** piden **45 días** (no 30) — el ciclo financiero es mensual y los defectos no se ven hasta pasado el cierre.
4. **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](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:**
1. **Inversión** del módulo de facturación: de acuerdo, se confirma con el Discovery (112–136 h, 6–7 semanas).
2. **Soporte:** de acuerdo. Replanteado como **bolsa de horas a $600/h + IVA, vigencia 12 meses** desde su contratación, sin caducidad mensual.
3. **Garantía:** de acuerdo, **45 días** (cubre el primer cierre mensual).
4. **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"):
1. **Pago al terminar:** en terminación anticipada se pagan las **horas efectivamente trabajadas** hasta la fecha.
2. **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:**
1. **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**.
2. **Manual de marca:** Pedro lo **envía hoy por correo** (paquete de branding). → cumplido, ver [#23](#23--jul-1-2026--733-am--correo--pedro--johann--manual-de-imagen-corporativa).
3. **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.)
4. **Azure:** lo gestionan **Pedro + Noé** (Noé otorga permisos donde Pedro tiene limitantes).
5. **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).
6. **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.
7. **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).
8. **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](#22--jul-1-2026--700-am--llamada--kickoff-del-proyecto-)).

**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`](../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](#22--jul-1-2026--700-am--llamada--kickoff-del-proyecto-)).

**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](#22--jul-1-2026--700-am--llamada--kickoff-del-proyecto-)) — 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](#22--jul-1-2026--700-am--llamada--kickoff-del-proyecto-)) — 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](#22--jul-1-2026--700-am--llamada--kickoff-del-proyecto-)) 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](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](#19--jun-26-2026--whatsapp-johann--paola-rh--ajustes-finales-y-firma-del-contrato-)). 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)
1. **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.
2. **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](#25--jul-2-2026--418441-pm--whatsapp-erika--johann--agendamateriales-para-la-sesión-del-6-jul)).
> - **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](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-)), 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](#25--jul-2-2026--418441-pm--whatsapp-erika--johann--agendamateriales-para-la-sesión-del-6-jul)).
> - 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](#28--jul-6-2026--901-am1240-pm--whatsapp-erika--johann--token-de-bind-entregado-)) 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](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-) 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:

1. **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"*.
2. **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`](../bind-api-sandbox/VALIDACION-API.md) (117 peticiones, exclusivamente GET, solo estructura — cero datos reales persistidos).

**Veredictos clave:**

1. ✅ **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.
2. ✅ **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.
3. ❌ **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.**
4. ⚠️ **Sin vínculo cotización→factura en la API** — la trazabilidad la llevará la plataforma (registrar el par al orquestar la conversión).
5. ⚠️ **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**.
6. ✅ **Token acotado a una sola empresa** (la de Arturo → Balam) — multi-empresa confirmado fuera del alcance por API.
7. **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](#31--jul-6-2026--433-pm--correo--noé--johann-pedro-cc-erika--salvaguardas-sobre-el-token-)) 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](#31--jul-6-2026--433-pm--correo--noé--johann-pedro-cc-erika--salvaguardas-sobre-el-token-)): *"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](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](#30--jul-6-2026--301-pm--whatsapp-johann--erika--propone-sesión-de-cobranza-martes-7-jul-)). 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](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-)).

> **Lectura estratégica:**
> - **Cierra el hueco de Discovery que quedó abierto el 6-jul:** facturación y envío ya están mapeados ([#27](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-)); 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](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-)). 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](#32--jul-6-2026--tarde--validación-técnica-de-la-api-de-bind-con-la-cuenta-real--)) 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](#32--jul-6-2026--tarde--validación-técnica-de-la-api-de-bind-con-la-cuenta-real--)) 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](#22--jul-1-2026--700-am--llamada--kickoff-del-proyecto-)) 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](#31--jul-6-2026--433-pm--correo--noé--johann-pedro-cc-erika--salvaguardas-sobre-el-token-)) **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](#32--jul-6-2026--tarde--validación-técnica-de-la-api-de-bind-con-la-cuenta-real--)).

> ⚠️ 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](#31--jul-6-2026--433-pm--correo--noé--johann-pedro-cc-erika--salvaguardas-sobre-el-token-)), 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](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](#31--jul-6-2026--433-pm--correo--noé--johann-pedro-cc-erika--salvaguardas-sobre-el-token-)), 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](#31--jul-6-2026--433-pm--correo--noé--johann-pedro-cc-erika--salvaguardas-sobre-el-token-)) **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](#35--jul-7-2026--700-am--llamada--discovery-proceso-actual-de-cobranza-sin-grabación-): 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](#35--jul-7-2026--700-am--llamada--discovery-proceso-actual-de-cobranza-sin-grabación-), 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](#35--jul-7-2026--700-am--llamada--discovery-proceso-actual-de-cobranza-sin-grabación-): 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:

1. **Miércoles 22-jul:** sesión de dudas y definiciones de la Etapa 1 con Arturo y participación solicitada de la CEO.
2. **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:**

- [x] ~~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.
- [x] ~~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:

1. **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".
2. 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.
3. 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.**
4. **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.

---

## 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
1. **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.
2. **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).