balam/bitacora/PENDIENTES.md

PENDIENTES — acciones abiertas

Acciones vivas del proyecto. Formato: [ ] abierta · [x] cerrada (no se borran, dejan rastro). Cada una con responsable y, si aplica, fecha. Ver contexto en REGISTRO.md.

Última actualización: 2026-08-21, mediodía — ⭐ primera cotización real emitida (folio 1026; la 2.ª, corregida, pendiente de confirmar). Anterior: 2026-08-20, noche. Cruce completo del buzón contra la bitácora (MCP ms365): se incorporaron 9 comunicaciones faltantes y se corrigieron 2 errores de registro. Hay sesión mañana viernes 21-ago, 7:00 am con Noé, Ara y Pedro sobre el formulario modificado y FAC-106. Ver REGISTRO #65–#68.

✅ 21-ago — la cotización ya se emite; lo que deja la sesión (REGISTRO #69)

• 🔥 Cancelar el folio 1026 en BIND (IVA 243,640.96 por el error de escala). Araceli o Johann, desde Ventas → Cotizaciones.
• 🔥 Confirmar la segunda emisión (VAT: 0.16): folio esperado 1027, total 1,431.44 MXN. Verificar por lectura y anotar el folio en #69.
• 📧 Enviar el correo a Pedro (CC Noé, Ara) con la causa — borrador listo en ../planeacion/Correo-error-resuelto-2026-08-21.md; faltan los dos corchetes (folio y estado de la 1026).
• 📝 Capturar la minuta de las definiciones de la sesión: ¿se validaron las 17 categorías? ¿Empresa origen = 3 cuentas o 1? ¿se agrega IVA 0%? ¿Azure? ¿a quién se reportan horas ahora?
• 🔧 Resolver el servicio desde el combo, no fijo: la UI manda el GUID del servicio 027 hardcodeado. Falta el mapeo 17 categorías de Jira → GUID de /api/Services (y BIND tiene 5 "Servicio de Enlace": hay que elegir uno por categoría, idealmente después de que Balam depure su catálogo).
• 🔧 Lista de precios desde el cliente: usar Clients.PriceListID (CEMEX → "A") en vez del GUID fijo; el read model de Quotes reporta ese campo mal.
• Sesión 21-ago → Hecha. Tres intentos en vivo fallaron (protocolo aplicado, nada creado); la causa se encontró después y la emisión funcionó al 5.º intento.
• 🔒 Bind:Mode ReadOnly al cerrar → Hecho en esta máquina (y API/ng apagados). ⚠️ En la otra máquina configurar user-secrets desde cero; Bind:Mode por default es ReadOnly.

🔥🔥 SESIÓN VIERNES 21-AGO, 7:00 AM — Noé, Araceli y Pedro (preparación; ya ocurrió)

• 🔥 Johann — inspeccionar FAC-106 por API → HECHO (20-ago, noche). Informe completo: ../planeacion/Sondeo-FAC-106-y-payload-2026-08-20.md. ⭐ El formulario nuevo resuelve conceptos/partidas: Servicio/Producto (combo, 17 categorías), Cantidad, IVA y Cliente (combo, 17 clientes de BIND) ya son campos estructurados; request type nuevo Cotización Bind. Config corregida: el campo de cliente pasó de customfield_10202 a customfield_11598 — era la causa de que el 12-ago "el cliente no se detectó".
• 🔥🔴 Resolver el ERROR 500 del POST de cotización → DIAGNOSTICADO (20-ago) leyendo 4 cotizaciones reales de BIND. Tres defectos en el payload: (1) VATRate va como fracción (0.16), no como 16; (2) el VAT de partida es monto, no tasa (Price × Qty × 0.16 — verificado en 3 de 4); (3) cada cotización real usa un PriceListID distinto y ninguno coincide con el único que devuelve GET /api/PriceLists → omitirlo. Dry-run corregido ejecutado (operación #18); body listo en el informe. Falta la confirmación real, que es la prueba de mañana.
• 🔴 PREGUNTAR MAÑANA — Empresa origen tiene 3 valores: Balam, RegioTurk y Helmstone. ¿La cotización se emite siempre en la misma cuenta de BIND o hay una por empresa? Hay un solo token. Si son cuentas distintas, el alcance cambia.
• 🔴 PREGUNTAR MAÑANA — el combo IVA de Jira solo ofrece 16%. No hay 0%, y en el combo de clientes hay tres de exportación (ACUNTIA S.A.U., VictTec LLC, IAMCFORWARDER). El Discovery registró 16%/0% y en BIND hay cotizaciones reales con VAT = 0. Falta la opción.
• 🔴 PREGUNTAR MAÑANA — "Servicio de Enlace" existe 5 veces en BIND, con unidad, unidad SAT y ChargeVAT distintos entre sí (una cobra IVA, cuatro no). El combo de Jira manda una sola etiqueta: la correspondencia etiqueta → ítem de BIND no está definida. Se depuró el combo de Jira; falta depurar BIND y fijar el mapeo.
• ⚠️ Fijar por escrito que manda el combo Cliente (11598): sobrevive Nombre del cliente (11596, texto libre) en el mismo formulario.
• 🔒🔴 Regresar Bind:Mode a ReadOnly → HECHO (20-ago, noche); verificado: /api/emision/estado responde ReadOnly. Mañana en la sesión: dotnet user-secrets set "Bind:Mode" "Write" --project src/Balam.Api (y reiniciar el API) SOLO para emitir, y de vuelta a ReadOnly al cerrar.
• 🔧 Cablear los 4 campos nuevos → HECHO (20-ago, noche). El wizard prellena la partida completa desde el ticket (título ← Servicio/Producto, cantidad, tasa de IVA) y manda vatRate como fracción; el endpoint rechaza con 400 cualquier tasa > 1. Verificado e2e contra FAC-106 real: detalle con servicio/cantidad/iva/fechaVencimiento poblados y dry-run (operación #19) con VATRate=0.16, VAT=197.44, sin PriceListID. Tests 74/74. El flujo de mañana es: abrir la solicitud → vista previa automática → encender Write → Confirmar.
• 🔥 Johann — preparar el caso de escritura sobre FAC-106 → LISTO (20-ago, noche). El cliente ya se lee del combo 11598 (CEMEX detectado y con match único en el catálogo sincronizado) y la partida sale de los campos estructurados. Queda solo la Confirmación real en la sesión — el único paso que nadie puede ensayar sin escribir en producción.
• 🔥 Johann — en la sesión: encender Bind:Mode=Write solo para emitir y regresarlo a ReadOnly antes de cerrar.
• ⚠️🔥 Johann — anunciar al abrir la sesión el destino de la cotización real (cancelarla al terminar vs. cliente de prueba) y que la prefactura pertenece a una sesión posterior. Pendiente arrastrado del 12-ago; sigue sin resolverse.
• 🔴 Validar las 17 categorías con Noé y Ara. Pedro redujo el catálogo de servicios de 67 → 17 pero lo condicionó: "tengo que verlas con Noé y Ara antes". Es el momento de cerrar el hueco de conceptos/partidas que bloquea B7 desde el #62.
• ☁️ Azure — insistir; lleva 3 semanas sin avanzar. El 11-ago Noé ofreció explorarlo en la sesión "con una cuenta que estamos creando para este uso"; el 12-ago no se tocó — Noé solo dijo "eso lo resuelvo con Pedro" (REGISTRO #65 §8). Ahora que Pedro es el responsable, es su pendiente directo. Requisitos ya comunicados el 28-jul: grupo de recursos + Contributor (app + BD + Key Vault), sin Global Admin. Sin esto la transición automática no existe y todo queda en disparo manual.
• 👤 Confirmar quién es el responsable del proyecto. → CONFIRMADO: Pedro. Noé lo anunció el 12-ago: "Erika ya no va a ser la PM de este proyecto. El seguimiento del proyecto lo va a traer Pedro." ⚠️ Nunca se comunicó por escrito — el anuncio existe solo en la grabación. Ver REGISTRO #65 §1.

🆕 Abierto por la sesión del 12-ago (REGISTRO #65)

• 🔴 Balam — definir la regla de EDICIÓN de cotizaciones. Araceli las modifica seguido ("siempre hay ajustes") y verificó en vivo que BIND conserva el mismo número al editar. La plataforma no implementa edición. Disyuntiva planteada por Noé y dejada a Balam: historial de cotizaciones (ticket nuevo o regenerar) vs. modificar la misma. Araceli se inclina por conservar historial. Impacta el diseño de B7 — preguntarlo mañana.
• ⚠️ Cancelaciones: la plataforma NO cancela, pero SÍ lleva el récord. Acordado el 12-ago. Antes del timbrado se cancela libremente; después requiere acuerdo con el cliente por correo → cancelación en el ERP → despacho ante el SAT → el cliente acepta en una liga del SAT. Falta modelar el récord ("esta factura se canceló y fue sustituida por esta").
• Balam/Pedro — quitar el SLA a los tickets de cotización para que no impacten métricas (acordado con Araceli en la sesión).
• 📼 Pedro — enviar las grabaciones de BIND (altas de proveedor/clientes, facturación y una tercera). Ofrecidas al cierre del 12-ago; no consta que hayan llegado — no aparecen en el buzón al 20-ago.
• 🗂️ Balam — resolver la herramienta de seguimiento del proyecto. El tablero de Jira para las actividades de Johann "muy próximo iba a necesitar que sea de paga por el tipo de licencia"; se barajaron SharePoint y Google Drive; Noé prefiere Jira pero falta permiso de admin para crear spaces. Mientras tanto sigue vigente lo del #58: el Excel de horas ES el sistema de seguimiento.
• 💰 Definir a quién se le reportan horas, avances y facturación ahora. Todo el circuito administrativo iba por Erika: cortes de horas, Excel de avance, recordatorios de factura (#45, #51, #58, #59). Con el relevo del 12-ago nadie dijo qué pasa con esa vía — y el relevo ni siquiera se comunicó por escrito. Preguntarlo mañana: si el seguimiento es con Pedro, ¿los cortes de horas también, o siguen con Erika/Paola?
• 🔒 Johann — avisar a Pedro antes de cada escritura (cotización o prefactura), ofrecido en la sesión. Noé reafirmó el candado: "no hacer más pruebas de lo que definiéramos, para evitar errores o cosas en producción".

🚨 Huecos de registro abiertos (detectados en el cruce del 20-ago)

• 🚨 Capturar la minuta de la sesión del 12-ago → HECHO (20-ago): transcript localizado y registrado en REGISTRO #65 (../fuentes/2026-08-12 - Transcript - Sesion prueba de escritura Jira-BIND.txt). Las cuatro preguntas quedaron respondidas: no se emitió cotización (error 500); Azure no se tocó y quedó con Pedro; sí, ahí Noé anunció a Pedro como responsable del seguimiento; y el molde de Araceli nunca existió — Pedro construyó un formulario nuevo en vivo.
• 📌 Versionar Cotizacion-BIND-campos-y-catalogos.xlsx — está en la raíz del repo sin trackear y ya es el insumo que Balam usó para rehacer el formulario de Jira (#66).
• 📄 Leer los procedimientos de carga de facturas ya descargados en ../fuentes/ (#46a): 5 portales — Cemex, Acuntia, ATC Consolidados, DYLO y Victec. ⚠️ Dos clientes que el Discovery nunca mencionó y Axie no aparece: el universo de destinos de envío no está cerrado.
• 🗺️ Contrastar el diagrama del flujo de facturación de Jira (../fuentes/2026-07-22 - Correo - Flujo facturacion JIRA BALAM.png, #57a) contra el disparador acordado y lo observado por API.
• 🔎 Identificar qué se firmó en Buk el 30-abr y el 5-may — dos documentos anteriores al contrato de junio que la bitácora nunca registró (REGISTRO #0).
• 📖 Leer el hilo comercial de abril ("Propuesta de servicios por hora - Balam", 23–28 abr) y completar REGISTRO #0: es donde se fijó la tarifa por hora.

🔥 Flujo Jira→BIND — abierto tras la definición del 7-ago

• 🔥 Johann — responder el correo del hilo de Jira → Enviado el 10-ago. Pide ticket de ejemplo, propone mié 12 / jue 13 a las 7:00 am, fija el alcance en la cotización y recuerda Azure. Texto en REGISTRO #62.
• 🔥 Araceli — levantar el TICKET DE EJEMPLO capturado "como debería ser" (ruteado por Noé el 11-ago; la noche del 11 no existía) → Lo resolvió PEDRO el 20-ago con FAC-106, tras rehacer el formulario de Jira contra el Excel de campos de BIND (#66, #67). ⚠️ No consta que Araceli haya capturado el molde que Noé le pidió: el camino fue otro — Balam modificó el formulario y Pedro levantó el ticket. Los planes B y C (captura en vivo / FAC-100) quedan sin usar.
• 🔥 Balam/Noé — confirmar la sesión (mié 12 o jue 13, 7:00 am) → CONFIRMADA por Noé (11-ago, 10:41 am): miércoles 12-ago, 7:00 am. Además, Azure se explora en la misma sesión con una cuenta nueva creada para este uso. Ver REGISTRO #63.
• 🔴 Conceptos/partidas — la vía quedó definida el 12-ago: DEPURAR EL CATÁLOGO, no agregar un campo. Araceli mostró que el combo de servicios de BIND está sucio (040 y 029 son el mismo servicio; entradas con nombres de personas, "monitor Samsung", periodos en el nombre) y se acordó dejar solo opciones genéricas, volver combo la descripción del ticket y homologar los combos de Jira con los de BIND. Pedro ejecutó la depuración: 67 → 17 categorías, pendientes de validar mañana con Noé y Ara. Dato fiscal: horas de consultoría = unidad SAT E48. Ver REGISTRO #65 §5, #67.
• 🔴 ACUNTIA — se resuelve con el segundo ticket de ejemplo. FAC-100 trae un solo Monto sin IVA (7,594.00 USD) para el ticket que históricamente representa 40–48 facturas. ¿Un ticket → una cotización? Ver REGISTRO #55 punto 6.
• ⚠️ Tickets de Automation for Jira — convertido en SUPUESTO, ya no bloquea. 10 de 69 no tienen request type ni un solo campo (incluido FAC-91, vivo en validación nacional). En el correo del 10-ago se asienta que siguen tramitándose a mano y que la automatización cubre solo los que entran por el portal. Si Balam objeta, la regla de Automation tendría que propagar los campos (trabajo de ellos). El molde capturado a mano no puede resolver esto.
• ⚠️🔥 Johann — decidir el destino de la cotización de la prueba en BIND. El ejercicio escribe una cotización real en BIND producción. Dos salidas: cancelarla al terminar o apuntarla a un cliente de prueba. Decidir esta noche y anunciarlo al abrir la sesión del 12, antes de ejecutar.
• 🔴 ¿El comercial ya genera la cotización en BIND, o la genera la plataforma? → RESUELTO en la sesión del 12-ago: la genera la PLATAFORMA. Noé le preguntó a Araceli si le serviría que Jira hiciera la cotización y evitarle el primer paso → "Sí, sí me serviría" → "vamos a hacer ese ejercicio, Johann". El paso comercial de cotizar a mano desaparece para venta nueva; la recurrente sigue fuera de alcance (comercial solo avisa el periodo y administración prefactura). Ver REGISTRO #65 §3.
• Alcance del ejercicio en vivo: ¿cotización o prefactura? → Decidido (10-ago): termina en la COTIZACIÓN. Es lo que contestó Arturo el 4-ago; la aprobación de Araceli va entre En proceso de facturación y Facturado, así que la prefactura pertenece después; Arturo pidió gradualismo explícito; y la cotización se cancela sin efecto fiscal mientras la prefactura es un registro en Invoices con UUID = null. La prefactura queda para la segunda sesión. Candados acordados: cotización → prefactura → aprobación humana → timbrado (REGISTRO #55).
• ⚠️ La transición automática depende de Azure. En la prueba del miércoles el disparo es manual (pipeline Draft→DryRun→Confirmed de ADR-001 con flags apagados). Para que corra automática hace falta el ambiente publicado y corriendo continuo — otro argumento para insistir en el acceso a Azure.
• 🔥 Johann — preparar el flujo contra el ticket de ejemplo → CONSTRUIDO (11-ago, noche): contrato Quotes_NewQuote obtenido del portal público, CreateQuoteAsync con guardas, POST /api/emision/cotizacion (dry-run/confirmación auditadas en WriteOperations), pantalla solicitudes/:id/cotizar y vínculo ticket→cotización. 73/73 pruebas. Corre contra cualquier ticket FAC — el molde solo mejora los datos. La escritura real sigue gateada a Bind:Mode=Write, que se enciende SOLO en la sesión. Ver REGISTRO #64.
• 🔥 Johann — enviar a Noé/Pedro el script de la prueba esta noche (../planeacion/Script-cotizacion-sesion-2026-08-12.md) — cumple la condición del 24-jul de compartirlo antes.
• 🔥 Johann — en la sesión: encender Bind:Mode=Write solo para emitir y regresarlo a ReadOnly antes de cerrar. ⚠️ La semántica fina de partidas (Type/SelectedUnit/VAT) se valida contra la primera respuesta real; si BIND rechaza, el error se lee en pantalla y se ajusta en vivo.
• Balam/Noé — fecha para la prueba acompañada de escritura. → Es la sesión confirmada del mié 12-ago, 7:00 am (Noé, 11-ago). Formato aceptado desde el 7-ago; no habrá FACTEST. Ver REGISTRO #63.
• Balam — ¿nacional vs extranjero cambia la cotización o solo el paquete de salida (PDF+XML vs PDF)? Hay dos estatus de validación y una aprobación por rama.
• Balam/Pedro — migrar a cuenta de servicio en vez de la cuenta personal de Pedro. Planteado el 29-jul, sin respuesta: hoy todo lo que escriba la plataforma queda firmado como Pedro y una rotación suya mata la integración.
• Johann — levantar el sandbox Jira Cloud propio (plan Free, proyecto JSM que replique el workflow de FAC). Con FACTEST descartado, es el único lugar donde se puede equivocar sin costo.
• ⚠️ Johann — implementar la detección por changelog, no por estatus actual. FAC-100 estuvo 2m44s en el estatus disparador; un poller de 15 min que consulte el estado actual se pierde la mayoría de los disparos. Refuerza el caso de pedir un webhook / regla de Automation a Pedro.
• Johann — mover el token de Jira a user-secrets/Key Vault y borrarlo de disco (ya está en .gitignore:9). Mismo pendiente que arrastra bind_token_api.txt.

🔴 Johann (proveedor) — inmediato

• ⚠️🔥 Enviar la propuesta/adenda ajustada por la integración Jira→BIND → Hecho (29-jul): v1.3 enviada por WhatsApp (8:18 am) y por correo (3:56 pm) a Noé, CC Ara/Erika/Pedro. APROBADA por Noé el 30-jul: "De acuerdo con la propuesta actualizada". Alcance: 7–10 h ($4,200–$6,000 MXN + IVA); total primera etapa 119–146 h. Ver REGISTRO #59, #60.

• 📊 Enviar el Excel de horas de las etapas siguientes (2, 3) → Hecho (29-jul, 8:18 am): Avance-Balam-2026-07-28.xlsx por WhatsApp; 👍 de Erika. Ver REGISTRO #59.

• 🔑 Destrabar el acceso a la API de Jira (401 del 29-jul) → Resuelto (30-jul): Pedro confirmó el correo del apikey (pedro.ayala@...), regeneró el token y GET /myself respondió 200. Ver ../planeacion/Investigacion-API-Jira.md (Bloque 0).

• 🌱 Seeder de datos de prueba (B9) → Hecho (1-ago): DevDataSeeder opt-in con datos ficticios (5 estados × MXN/USD × PUE/PPD). El desfase con lo reportado a Erika el 27-jul quedó saldado. Ver REGISTRO #61.

• 🔑 Copiar propuesta/token-jira.txt a esta máquina y correr ../planeacion/pruebas-jira-lectura.sh → Hecho (6-ago): script corrido completo contra FAC (todo 200; auth OK con el token renovado) + sondeo dirigido de customfields. Los IDs quedaron capturados y documentados en ../planeacion/Investigacion-API-Jira.md (sección 6-ago): sí existen "Monto sin IVA"/"Monto con IVA" pero casi nadie los llena (2/69); "Nombre del Cliente" y "Periodo de Incidencias" llegan como ADF. ⚠️ El token estaba suelto en balam-plataforma/token-jira.txt (repo del cliente, sin ignorar): se movió a propuesta/ + user-secrets y se blindó el .gitignore del subrepo.

• 🧪 Crear el sandbox Jira Cloud Free propio (decidido 1-ago) para desarrollar escritura (transiciones/comentarios/creación) sin tocar FAC; la prueba en la instancia real sigue reservada a la sesión acompañada que autorizó Noé.

• ⏱️ Capturar horas 28-jul→1-ago en el CSV (propuesta preparada, validar montos) y regenerar Avance-Balam desde script — la copia en disco del 28-jul está desincronizada (re-guardado manual).

• 📅 Demo del viernes 7-ago: material listo — frontend (login→cartera→facturas→detalle+PDF→clientes), seeder demo como respaldo si BIND falla, scheduler en vivo.

• Asistir al kickoff con Noé (mié 1-jul, 7:00 am) → Hecho (1-jul). Ver REGISTRO #22.

• 📅 Asistir a la sesión "Proceso actual de facturación y cobranza" (lun 6-jul, 7:00 am) → Hecha (6-jul). Proceso mapeado end-to-end; lista blanca eliminada; cotización BIND obligatoria. Ver REGISTRO #27.

• 🎨 Preparar y entregar el prototipo de la Etapa 0 → Entregado por correo (10-jul) a Erika + Noé, CC Pedro, con PDF y versión navegable. Refleja facturación, envío, cobranza y reglas del Discovery. Ver REGISTRO #40.

• 📧 Enviar por correo el prototipo (imágenes) + comentarios → Hecho (10-jul). Balam respondió que lo revisaría internamente.

• 📊 Responder a Erika el % de avance de Fase 0 → Atendido mediante el Excel de avance ajustado y entrega del prototipo. La validación final sigue abierta.

• 📅 Preparar y asistir a la sesión de reglas/dudas de Etapa 1 (mié 22-jul) → Hecha (22-jul, 7 am): alta de cliente/proveedor mapeada (Arturo en pantalla), fee = lo registra el despacho (plataforma solo detecta), Jira confirmado en el proceso (estatus final "resuelto"; validación PDF+XML nacional / PDF internacional). No se tocaron particularidades de envío ni PUE/PPD. Ver REGISTRO #54 y minuta en ../planeacion/Sesion-Etapa1-2026-07-22.md.

• 📅 Preparar y asistir a la validación del prototipo (jue 23-jul, 7:00 pm). Llevar decisiones que requieren visto bueno y separar MVP de Anexo B. Aprovechar para meter la pregunta PUE/PPD que no se alcanzó el 22-jul. Ver REGISTRO #42.

• 📊 Compartir con Erika el corte de avance de la Etapa 1 solicitado el 16-jul → Hecho (16-jul, 8:40 pm): Excel Plan-actividades-avance-2026-07-16.xlsx enviado por WhatsApp; Erika acusó recibo ("Ntp, gracias"). Ver REGISTRO #46.

• 📄 Revisar los procedimientos de carga de facturas por cliente enviados por correo el 16-jul. Conservar correo/adjuntos como evidencia y contrastar destinatarios, adjuntos, asunto, cuerpo y nomenclatura contra el Discovery y el prototipo. Ver REGISTRO #46.

• 🔐 Validar permiso de escritura en el repositorio privado de Balam → Comprobado (16-jul): push exitoso del scaffold inicial (backend .NET 10 + Angular 21, commits 220942a..1f7f098) a pedro-balam-itsm/BALAM. Ver REGISTRO #46.

• ⏱️ Validar el corte reconstruido de 30 h en ../planeacion/Seguimiento-horas.csv: 22 h de Etapa 0 + 8 h de Etapa 1. Solo 3.08 h corresponden a sesiones con duración comprobable; las otras 26.92 h están marcadas como reconstruidas. Ajustarlas si la memoria/evidencia indica otra distribución y después conciliar con Jira. Ver REGISTRO #45.

• 📝 Cerrar el documento de hallazgos + ADRs (../planeacion/Hallazgos-y-decisiones-Etapa0.md) después de las sesiones del 22–23 jul.

• 🔐 Decidir/aplicar el rol local balam_app para que RLS aplique en desarrollo: la política RLS de B6 está aplicada, pero el usuario balam del contenedor es superuser (BYPASSRLS) y la ignora. Falta: CREATE ROLE balam_app LOGIN NOSUPERUSER NOBYPASSRLS + REASSIGN OWNED + apuntar la cadena de conexión de desarrollo (appsettings.Development y DesignTimeDbContextFactory) a ese rol + repetir la verificación psql. En Azure no existe este hueco (el usuario de app no es superuser). Ver REGISTRO #53.

• ⚠️ Preguntar a Arturo: ¿por qué TODO el histórico se factura PUE? 1,374/1,374 facturas con método de pago = PUE, cero PPD, aunque cobran a crédito 30–90 días. Toca la regla "PPD default" de la capa de escritura (B7) y el requerimiento del SAT que ellos mismos sufrieron. No se alcanzó a preguntar en la sesión del 22-jul — reintentar el 23-jul (validación del prototipo) o en la sesión de API Jira con Pedro. Ver REGISTRO #52, #54.

• 📅 Proponer a Erika usar la sesión del martes 7-jul para COBRANZA → Propuesto (6-jul, 3:01 pm) y CONFIRMADO (6-jul, 6:36 pm): convocatoria de Teams enviada para el martes 7-jul, 7:00–8:00 am, con Araceli y Arturo (CC Noé). Ver REGISTRO #34.

• 📅 Asistir a la sesión de cobranza (mar 7-jul, 7:00 am) → Hecha (7-jul). Sin grabación. Ver REGISTRO #35.

• 📝 Documentar el proceso de cobranza de la sesión del 7-jul (sin grabación) → Hecho (7-jul): reconstruido de memoria el mismo día. Notas en ../fuentes/2026-07-07 - Notas - Proceso actual de cobranza (sin grabacion).md; entrada REGISTRO #35.

• 📊 Exceles de cobranza (condicional): si Balam valida que el prototipo representa bien su operación, ya no se requieren. Si pide ajustes, solicitar a Arturo estructura con datos ficticios de abiertas/canceladas/días vencidos, pago↔folio y estado de cuenta. No confundir con el Excel de particularidades de envío, que sigue pendiente. Ver REGISTRO #44.

• 🔑 Dar seguimiento a si Pedro crea el usuario de solo lectura de BIND que pidió Noé (mientras tanto Erika opera con el usuario de Arturo, sin bloqueo) — sigue sin resolverse una semana después (7-jul). Ver REGISTRO #37.

• 🔧 Decidir si probar endpoints de escritura (POST/PUT) de BIND → Decidido (7-jul): NO todavía. Contradice la instrucción de Noé de mantener solo-lectura mientras Pedro confirma el alcance del token; sin sandbox, el riesgo fiscal es real. Alternativa segura: catalogar operaciones de escritura desde el portal de desarrolladores de BIND (documentación), no probarlas en vivo. Ver REGISTRO #36.

• 📧 Responder el correo de Pedro → Enviado (6-jul, ~3:28 pm): acuse de recibo + usuario de Arturo documentado + arranque de trabajo con la API, sin comprometer entregas adicionales. Ver REGISTRO #29.

• 📧⚠️ Responder el correo de Noé (importancia alta, 4:33 pm) describiendo las salvaguardas ya operando → ESTABA HECHO DESDE EL 6-JUL, 4:46 PM (13 minutos después del correo de Noé), a Noé y Pedro con Erika en copia. Cubre las cinco salvaguardas: solo-lectura bloqueado en código, consumo acotado, token en gestor de secretos fuera del repo, sin datos reales en la documentación, y escritura diferida. (Corrección del 20-ago: este pendiente llevaba mes y medio abierto por error — el correo apareció al cruzar el buzón.) Ver REGISTRO #31a.

• ⚠️ No atar nada al token actual: Pedro está revisando permisos y puede reemplazarlo por uno de un usuario nuevo de solo lectura — mantener el token como variable de entorno intercambiable (ya es así en el sandbox). Ver REGISTRO #31.

• 🔑 Validar la API de BIND con el token real → ✅ Hecha (6-jul, adelantada un día): 117 peticiones GET-only, Plan A del saldo CONFIRMADO, flujo MVP 100% sostenible en lectura, PDF por API. Hallazgo duro: sin recurso de pagos/REP. Documento: ../bind-api-sandbox/VALIDACION-API.md. Ver REGISTRO #32.

• 📨 Escalar a Pedro las preguntas técnicas de la API (juntas, esta semana): (1) ¿existe endpoint de pagos individuales / complementos de pago (REP) no documentado? — es el hueco más relevante para el flujo PPD, y ganó caso de negocio el 7-jul: el despacho registra los pagos en BIND uno por uno a mano; (2) tabla de mapeo CFDIUse interno → clave SAT; (3) shape del endpoint /{id}/xml; (4) ¿webhooks/eventos o solo polling?; (5) ⚠️ qué token alimenta el Power BI — el 7-jul Arturo mostró su Power BI conectado con su token, pero el kickoff acordó Ara=Power BI / Arturo=desarrollo; BIND emite 1 token por usuario, así que si ambos usos comparten el de Arturo, reemplazarlo por el usuario solo-lectura que planteó Noé rompería uno de los dos. Ver REGISTRO #32 §10, #35.

• 🔐 Higiene del token: moverlo a un gestor de secretos y borrar bind_token_api.txt de la raíz del repo y del correo/descargas (está gitignoreado, pero sigue en disco).

• ⚠️ Aclarar expectativa de recordatorios a clientes: lo que Ara/Arturo describieron el 6-jul son recordatorios automáticos a clientes, que están diferidos al Anexo B (el MVP trae alertas internas). Aclararlo pronto o anticipar que pidan ese módulo al cierre del MVP. Igual con la idea de agentes observando Jira (Nivel 3, fase posterior) y el deseo multi-empresa (Regiotour, Elmstone). Reapareció el 7-jul: quieren correos automáticos al cliente pasados 1–5 días de vencimiento ("ser proactivos"). Ver REGISTRO #27, #35.

• Ajustar la propuesta (30 h explícitas, sin "Etapa 0", términos comerciales en una sección) → Hecho (1-jul): propuesta v1.2 — se agregó el concepto "Facturación inicial: 30 h / $18,000 + IVA" (cubre Etapa 0 + inicio de Etapa 1; Etapa 0 se mantiene en 18–22 h) y se consolidó §3.3 Condiciones comerciales. PDF generado y enviado el 2-jul.

• 📧 Enviar el correo (Noé, CC Pedro, Ara, Erika) con la propuesta v1.2 ajustada, vinculando la facturación inicial de 30 h al acuerdo → Hecho (2-jul, 5:39 PM): enviado con Propuesta-Balam.pdf adjunto, sin esperar el correo de Erika+Paola. Ver REGISTRO #26.

• 💸 NO facturar todavía. Erika confirmó el 13-jul que recibió la propuesta v1.2; la validación para emitir sigue pendiente porque Noé y la CEO están fuera del país. Mantener la factura lista y emitir en cuanto llegue el visto bueno, con pago a 30 días. Ver REGISTRO #41.

• Configurar Jira y aprender el flujo con Pedro — reportar horas ahí (incluye material informativo); Erika hace el corte los lunes. Mientras tanto usar ../planeacion/Seguimiento-horas.csv.

• Usar los tokens de marca en el prototipo → Hecho: prototipo y capturas usan Amarillo #F7BD0C, Café #331F0E y Poppins.

• Preparar el Excel de actividades → Entregado y consolidado: la única versión operativa se conserva en ../planeacion/Plan-actividades-avance-2026-07-10-ajustado.xlsx; contiene el corte reconstruido de 30 h al 15-jul.

• Proponer sesiones de Discovery → Hecho (29-jun): propuestas y aceptadas; Erika coordina las agendas (intermediaria de sesiones).

• Cambiar régimen fiscal (en proceso) para poder facturar (CFDI semanal los viernes, pago a 30 días).

• Confirmar qué permisos exactos de Azure necesita → Definido: acceso Contributor acotado a un grupo de recursos de Balam; no se requiere Global Admin ni una cuenta nueva. Solicitar durante la semana del 21-jul.

• Arrancar el Discovery una vez Balam entregue los accesos → Hecho (6–7 jul): facturación, envío y cobranza mapeados.

• (Opcional) Pedir a Balam 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). Ver REGISTRO #19.

• Revisar y firmar el contrato de servicios → Hecho (26-jun): revisado, negociados 2 ajustes (pago de horas al terminar + aceptación a 10 días) y FIRMADO. Ver REGISTRO #18, #19.

• Responder el correo de Noe (8-jun) → Hecho (10-jun): aceptados los 4 ajustes y respondidas las 3 preguntas técnicas. Ver REGISTRO #16.

• Decisión comercial: sin anticipo / pago a 30 días → Aceptado (10-jun), con la condición de firmar el contrato/orden de trabajo antes de arrancar (sustituye al anticipo como mecanismo de compromiso).

• Preparar propuesta v1.1 → Enviada (10-jun) con los 4 ajustes reflejados. Ver REGISTRO #16:

  • Soporte: bolsa de horas a $600/h, vigencia 12 meses (sin caducidad mensual).
  • Garantía: 45 días.
  • Comercial: sin anticipo; factura de Etapa 0 + pago a 30 días; avances a 30 días.
  • Conciliación bancaria: reflejada como primer alcance condicionado a horas liberadas por el Discovery.
  • Dashboard/reporteo: ajustado para no solapar con el tablero Power BI de Pedro (conservar cobranza + alertas).

🟡 Balam

• ☁️⚠️ Noé: otorgar el acceso a Azure — grupo de recursos con permiso Contributor (app + BD + Key Vault); no requiere Global Admin ni cuenta nueva. Requisitos comunicados por Johann el 28-jul 4:53 pm; Erika lo escaló a Noé (5:23 pm). Bloquea ambiente, staging y CI/CD. Movimiento (11-ago): Noé propone explorar/validar los accesos EN la sesión del 12-ago, con una cuenta que están creando para este uso — llevar los requisitos a la mano. Ver REGISTRO #59, #63.
• 📅⚠️ Erika/Arturo: avisar fecha de la sesión del flujo de facturación tras la revisión interna (Ara de viaje desde el 28-jul). Desbloquea B7 (capa de escritura). Ver REGISTRO #58.
• 🧾 Balam: decisiones de negocio de la integración Jira→BIND — estatus disparador, request type a observar, fuente de monto y conceptos de la cotización. Sin esto no se escribe código productivo de la integración. Ver ../planeacion/Investigacion-API-Jira.md.
• Balam: enviar el documento/contrato de firma → Hecho (25-jun): contrato enviado vía Paola (RH); ajustado y firmado el 26-jun. Ver REGISTRO #18, #19.
• 🔑 Balam: completar accesos de Etapa 1 — token BIND ✅; manual de marca ✅; invitación al repo GitHub recibida y acceso confirmado informalmente (falta validar escritura); Azure programado para semana del 21-jul. Ya no bloquea el desarrollo local, pero Azure sí condiciona despliegue/CI-CD.
• Erika (PM): pedir el plan de actividades → Recibido (30-jun). Erika es la intermediaria de todas las sesiones, agendó el kickoff (1-jul, 7am) y monta el tablero Kanban en Jira. Ver REGISTRO #21.
• Noe: formalizar por correo → Hecho: aclaraciones (8-jun, #15) y luz verde + redacción del documento de firma (16-jun, #17).
• Pedro + Erika: armar el tablero de seguimiento en Jira y revisarlo juntos (instruido formalmente por Noe el 16-jun).
• Pedro: enviar manual de marca → Hecho (1-jul): enviado por correo. Tokens en ../marca/Marca-Balam.md. Ver REGISTRO #23.
• Erika: entregar el token de BIND → ✅ ENTREGADO por correo (6-jul, 12:40 pm), mismo día en que se solicitó. Ver REGISTRO #28.
• Balam: confirmar a qué usuario pertenece el token → ✅ Confirmado (6-jul, 12:38 pm): Pedro lo entregó por correo (bind_token_api.txt) indicando que fue generado con el usuario de Arturo Rosas — conforme al kickoff (Arturo=dev, Ara=Power BI). Ver REGISTRO #29.
• Pedro/Balam: confirmar permisos de escritura para Johann-28 en el repositorio GitHub privado. Pedro envió la invitación el 15-jul y Johann confirmó acceso el 16-jul; falta una prueba efectiva de escritura. Ver REGISTRO #43, #46.
• Pedro: enseñar a Johann el flujo de Jira (reporte de horas como los demás consultores).
• Pedro + Noé: configurar Azure y permisos (Noé otorga donde Pedro tiene limitantes).
• Erika: coordinar la sesión de Discovery con Arturo + Araceli → Hecho: agendada (1-jul) y realizada (6-jul, 7am). Ver REGISTRO #24, #27.
• 📊 Ara + Arturo: enviar el Excel de particularidades de envío por cliente (destinatarios + adjuntos + nomenclatura). Erika confirmó el 13-jul que continúa en preparación y que esperan entregarlo durante la semana. Ver REGISTRO #41.
• Arturo: definir el proceso para cuando el cliente NO esté dado de alta en BIND — el ASIS del alta ya quedó mapeado en la sesión del 22-jul (REGISTRO #54); sigue abierta la decisión de MVP: ¿la plataforma solo detecta que falta el cliente o también lo crea? (cruza con la estimación Jira→BIND de ~10 h). Ver REGISTRO #27, #51.
• 📤 Arturo/Pedro: enviar a Johann el diagrama del flujo Jira de facturación en tamaño legible (comprometido en la sesión del 22-jul; el screenshot era ilegible). Ver REGISTRO #54.
• 📅 Erika: agendar la sesión con Pedro (+Arturo) para explorar la API de Jira (conexión, campos, webhook), la facturación recurrente (~30 facturas/mes) y qué facturas son automáticas vs manuales — acordada en la sesión del 22-jul. Ver REGISTRO #54.
• Erika + Paola / Noé: confirmar la propuesta v1.2 para emitir las 30 h. Erika confirmó recepción; validación pendiente por viaje de Noé y CEO. Ver REGISTRO #41.
• Arturo: dar acceso/contexto de bancos (para conciliación). Las reglas de negocio de facturación ya quedaron mapeadas en la sesión del 6-jul (REGISTRO #27); bancos sigue pendiente.

⚙️ Acordado (referencia, ya cerrado)

• Anticipo de Discovery ($18,000): aprobado (4-jun) → Corregido (8-jun): Balam NO maneja anticipos. Se factura la Etapa 0 (30 h) y se paga a 30 días.
• Propuesta v1.1 enviada (10-jun) y aceptada por Balam (16-jun). Balam redacta el documento de firma.
• Condición de arranque: contrato/orden de trabajo firmado antes de iniciar (planteado por Johann 10-jun; aceptado por Balam 16-jun).
• Contrato de servicios FIRMADO (26-jun-2026) por Johann (firma electrónica). Incluye 2 ajustes finales: pago de horas al terminar + aceptación a 10 días naturales. Facturación semanal (viernes), pago a 30 días.
• Plan de actividades (4 etapas) entregado a Erika (29–30 jun). Kickoff con Noé agendado (1-jul, 7am). Erika = intermediaria de sesiones; tablero Kanban en Jira.
• Pagos: a 30 días post-factura (incluida la Etapa 0); política firme de Balam (8-jun).
• Gestión en Jira (ágil, no Gantt); Erika valida entregables (4-jun).
• Comunicación: canal de WhatsApp + correo para evidencia. Contactos: Erika=principal, Pedro=técnico, Arturo=negocio (4-jun).