Bitácora 1–6 jul: kickoff, manual de marca y Discovery de facturación

- REGISTRO #22–28: kickoff (1-jul), manual de marca recibido, coordinación
  y sesión de Discovery del proceso de facturación (6-jul), envío de la
  propuesta v1.2 y seguimiento del token de BIND (solicitado por Erika).
- Cambios de reglas del 6-jul: lista blanca eliminada (recordatorios a
  todos) y cotización BIND obligatoria como inicio del flujo.
- marca/: tokens oficiales destilados del manual de imagen corporativa.
- Plan de actividades actualizado con responsables reales post-kickoff.
- Fuentes: transcripts de kickoff y Discovery, WhatsApps de Erika, manual
  de imagen corporativa (PDF).

bitacora/REGISTRO.md

@@ -11,7 +11,7 @@
 - **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 → 30 jun 2026
+**Periodo:** 30 abr 2026 → 6 jul 2026 (última actualización: sesión de Discovery del proceso de facturación, 6-jul)
 **Orden:** cronológico (más antiguo arriba)
 
 ---
@@ -400,6 +400,180 @@ Erika (PM, contacto principal) confirma que **ya pasaron los temas administrativ
 
 ---
 
+## 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.
+
+### 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 sesión del **martes 7-jul** probablemente ya no sea necesaria (Johann cerró diciendo que sus dudas quedaron resueltas) — confirmar con 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–10:28 AM · WhatsApp Erika ↔ Johann · seguimiento al token de BIND ⭐
+
+> 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** — Sobre *"Validación técnica de la API de BIND con la cuenta real · mar 07 → mié 08 jul"*: *"¿se necesita una sesión?"* **Respuesta de Johann:** no — es trabajo propio con el token en mano (probar endpoints y compartir resumen de hallazgos); solo si algo no cuadra (permisos/cobertura) pediría 15–20 min con Pedro o Arturo. Pide el token **martes temprano** para cumplir las fechas del plan.
+
+> **Lectura estratégica:**
+> - **El bloqueador del token por fin tiene tracción:** Erika lo gestiona activamente contra el plan de actividades y ya lo **solicitó internamente** (10:26). Primera respuesta real al seguimiento que Johann venía haciendo 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.
+> - Pendiente de higiene: al recibir el token, **confirmar de qué usuario salió** (documentar cuál llave es para qué — acuerdo del kickoff) y tratarlo como **llave de producción** (sin sandbox).
+
+---
+
 ## Resumen ejecutivo del hilo (para contexto rápido)
 
 ### Datos duros confirmados por Balam
@@ -407,9 +581,11 @@ Erika (PM, contacto principal) confirma que **ya pasaron los temas administrativ
 - **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, ~50 facturas/mes.
+- **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.
+- **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).
 - **Book = SaaS** (no interno).
 - **Jira:** solo gestión de proyectos con clientes.
 - **Nube preferida:** Azure.
@@ -425,8 +601,10 @@ Erika (PM, contacto principal) confirma que **ya pasaron los temas administrativ
 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 30-jun-2026 — kickoff mañana 1-jul)
-**Contrato FIRMADO (26-jun)** y **proyecto en arranque.** El **kickoff con Noé está confirmado para el miércoles 1-jul, 7:00 am.** Johann entregó el **plan de actividades** (4 etapas, fechas tentativas) en `../planeacion/Plan-actividades.xlsx`. Erika coordina el seguimiento (tablero Kanban en Jira) y es la **intermediaria de todas las sesiones**.
+### Estado actual (al 6-jul-2026 — Discovery en marcha)
+**Contrato FIRMADO (26-jun)**, **kickoff realizado (1-jul)** y **primera sesión de Discovery realizada (6-jul, 7am, con Ara + Arturo — [#27](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-)).** El proceso actual quedó mapeado end-to-end: **Jira ITSM (mandatorio) → validación administración → prefactura BIND → CFDI → envío por correo con particularidades por cliente**. Dos reglas cambiaron en la sesión: **lista blanca eliminada** (recordatorios a todos) y **cotización BIND obligatoria** como inicio del flujo. Ara/Arturo deben enviar hoy el **Excel de particularidades de envío**; Johann trabaja el **prototipo** con el flujo real. **Propuesta v1.2 enviada (2-jul)** — en espera de confirmación de Balam para emitir la factura de 30 h. **Token de BIND sigue pendiente** (no se tocó en la sesión).
+
+**Definido en el kickoff:** token **de Arturo** para BIND (solo consulta; se prueba primero) · **Balam crea el repo** (GitHub privado) y **gestiona Azure** (Pedro+Noé) · Johann reporta **horas en Jira** (Pedro le enseña; corte de Erika los lunes) · Discovery **con Arturo + Araceli** (Erika agenda). **Dos bloqueadores vivos:** (1) **accesos** (token BIND, Azure, repo) y (2) **emisión de la 1ª factura** — Johann ya envió la propuesta v1.2 ajustada (2-jul); **no factura hasta que Balam confirme por correo**.
 
 **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.