Registro #69: primera cotización real en BIND desde FAC-106 (folio 1026) tras 5 intentos; Type=2 y VAT como tasa, indocumentados

Sesión del 21-ago: tres intentos en vivo fallaron (uno con error explícito
que se corrigió al momento, dos con 500 genérico); se aplicó el protocolo,
se verificó por lectura que nada quedó en BIND, y con autorización de Balam
se siguió sobre el ticket de prueba. La causa fue Items[].Type (2 =
servicio, el catálogo donde BIND busca el ID) y, ya emitida, la escala de
Items[].VAT (tasa, no monto) que dejó el folio 1026 con IVA absurdo y debe
cancelarse. La segunda emisión corregida queda pendiente de confirmar.

Incluye el borrador del correo a Balam con la causa y el Excel de campos y
catálogos de BIND que fue el insumo del formulario nuevo de Jira.

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

bitacora/PENDIENTES.md

@@ -2,22 +2,71 @@
 
 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](REGISTRO.md).
 
-_Última actualización: 2026-08-10 (Balam definió el flujo Jira→BIND en el correo del 7-ago: disparador = `En proceso de facturación`, todos los request types, monto/conceptos como campos de Jira, prueba acompañada sin `FACTEST`. Verificado por API el 10-ago: el campo `Monto sin IVA` ya existe, pero **los conceptos no tienen campo** y **10 de 69 tickets no traen datos estructurados**. Ver [REGISTRO #59](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](REGISTRO.md)–[#68](REGISTRO.md)._
+
+## ✅ 21-ago — la cotización ya se emite; lo que deja la sesión ([REGISTRO #69](REGISTRO.md))
+
+- [ ] 🔥 **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.
+- [x] ~~**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.
+- [x] ~~🔒 **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ó)
+
+- [x] ~~🔥 **Johann — inspeccionar `FAC-106` por API**~~ → **HECHO (20-ago, noche).** Informe completo: [`../planeacion/Sondeo-FAC-106-y-payload-2026-08-20.md`](../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ó"*.
+- [x] ~~🔥🔴 **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.
+- [x] ~~🔒🔴 **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.
+- [x] ~~🔧 **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.
+- [x] ~~🔥 **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](REGISTRO.md).
+- [ ] ☁️ **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](REGISTRO.md) §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.
+- [x] ~~👤 **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](REGISTRO.md) §1.
+
+## 🆕 Abierto por la sesión del 12-ago ([REGISTRO #65](REGISTRO.md))
+
+- [ ] 🔴 **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](REGISTRO.md): **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](REGISTRO.md), [#51](REGISTRO.md), [#58](REGISTRO.md), [#59](REGISTRO.md)). 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)
+
+- [x] ~~🚨 **Capturar la minuta de la sesión del 12-ago**~~ → **HECHO (20-ago):** transcript localizado y registrado en [REGISTRO #65](REGISTRO.md) (`../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](REGISTRO.md)).
+- [ ] 📄 **Leer los procedimientos de carga de facturas** ya descargados en `../fuentes/` ([#46a](REGISTRO.md)): 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](REGISTRO.md)) 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](REGISTRO.md)).
+- [ ] 📖 **Leer el hilo comercial de abril** ("Propuesta de servicios por hora - Balam", 23–28 abr) y completar [REGISTRO #0](REGISTRO.md): es donde se fijó la tarifa por hora.
 
 ## 🔥 Flujo Jira→BIND — abierto tras la definición del 7-ago
 
-- [x] ~~🔥 **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 #59](REGISTRO.md).
-- [ ] 🔥 **Balam — levantar el TICKET DE EJEMPLO capturado "como debería ser"** (pedido para hoy/mañana en el correo del 10-ago). Tarea **dejada sin asignar a propósito** para que Balam la ruteé; en la práctica es de Arturo. Es el mecanismo elegido para resolver por evidencia, y no por correo, los huecos de abajo. ⚠️ **Riesgo: el precedente de latencia es de 8 días** (pregunta del 30-jul contestada el 7-ago). Si no hay respuesta para mañana al mediodía, empujar por WhatsApp con Erika, que es el canal que responde el mismo día.
-- [ ] 🔥 **Balam/Noé — confirmar la sesión** (mié 12 o jue 13, 7:00 am). Sin fecha confirmada no hay prueba acompañada.
-- [ ] 🔴 **Conceptos/partidas — se resuelve con el ticket de ejemplo.** El acuerdo del 4-ago resolvió el monto (`customfield_11556`) pero **no existe campo de conceptos en todo el sitio de Jira**. Si en el molde el desglose no cabe en ningún campo, hay que agregar uno; si no, la cotización va de una sola línea. **Sigue siendo el único bloqueo real para cerrar B7.**
+- [x] ~~🔥 **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](REGISTRO.md).
+- [x] ~~🔥 **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](REGISTRO.md), [#67](REGISTRO.md)). ⚠️ **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.
+- [x] ~~🔥 **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](REGISTRO.md).
+- [ ] 🔴 **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](REGISTRO.md) §5, [#67](REGISTRO.md).
 - [ ] 🔴 **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](REGISTRO.md) 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**. Anunciado en el correo, con dos salidas ofrecidas: cancelarla al terminar o apuntarla a un cliente de prueba. Definir cuál antes de la sesión.
-- [ ] 🔴 **¿El comercial ya genera la cotización en BIND, o la genera la plataforma?** Contradicción abierta: el 6-jul Ara dijo que **el comercial la genera y la plataforma la convierte** a prefactura ([REGISTRO #27](REGISTRO.md)); el 4-ago Arturo dijo que **la plataforma la genera**; y el formulario de Jira sigue exigiendo **adjuntar la cotización**. Si ambas cosas ocurren, **quedan dos cotizaciones por ticket**. Se resuelve viendo qué adjunto pone Arturo en el ticket de ejemplo: cotización de BIND ya existente (→ convertir) o documento comercial (→ crear).
+- [ ] ⚠️🔥 **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.**
+- [x] ~~🔴 **¿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](REGISTRO.md) §3.
 - [x] ~~**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](REGISTRO.md)).
 - [ ] ⚠️ **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 script contra el ticket de ejemplo** en cuanto Arturo lo levante, para llegar a la sesión con el flujo funcionando. Compartirlo con Balam **antes** de la sesión (protocolo del Bloque 6 de `../planeacion/Investigacion-API-Jira.md`).
-- [ ] **Balam/Noé — fecha para la prueba acompañada de escritura.** Aceptado el formato el 7-ago, sin día propuesto por ellos. En el correo del 10-ago se proponen **mié 12 o jue 13-ago, 7:00 am o después de 6:00 pm** (30 min), sobre un ticket que cree Arturo, con el script compartido de antemano. **No habrá `FACTEST`.**
+- [x] ~~🔥 **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](REGISTRO.md).
+- [ ] 🔥 **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.
+- [x] ~~**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](REGISTRO.md).
 - [ ] **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.
@@ -26,6 +75,15 @@ _Última actualización: 2026-08-10 (Balam definió el flujo Jira→BIND en el c
 
 ## 🔴 Johann (proveedor) — inmediato
 
+- [x] ~~⚠️🔥 **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](REGISTRO.md), [#60](REGISTRO.md).
+- [x] ~~📊 **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](REGISTRO.md).
+- [x] ~~🔑 **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).
+- [x] ~~🌱 **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](REGISTRO.md).
+- [x] ~~🔑 **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.
+
 - [x] ~~**Asistir al kickoff con Noé (mié 1-jul, 7:00 am)**~~ → **Hecho (1-jul).** Ver [REGISTRO #22](REGISTRO.md).
 - [x] ~~📅 **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](REGISTRO.md).
 - [x] ~~🎨 **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](REGISTRO.md).
@@ -47,7 +105,7 @@ _Última actualización: 2026-08-10 (Balam definió el flujo Jira→BIND en el c
 - [ ] 🔑 **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](REGISTRO.md).
 - [x] ~~🔧 **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](REGISTRO.md).
 - [x] ~~📧 **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](REGISTRO.md).
-- [ ] 📧⚠️ **Responder el correo de Noé (importancia alta, 4:33 pm)** describiendo las **salvaguardas** ya operando: solo-lectura bloqueado en código, consultas acotadas, token en gestor de secretos fuera del repo, sin datos reales en documentos, escritura solo con autorización + candados de la propuesta. Borrador listo. **Confirmación informal ya dada por WhatsApp (6-jul, 5:01 pm) — falta la respuesta formal por correo para dejar constancia en el canal correcto.** Ver [REGISTRO #31](REGISTRO.md), [#33](REGISTRO.md).
+- [x] ~~📧⚠️ **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](REGISTRO.md).
 - [ ] ⚠️ **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](REGISTRO.md).
 - [x] ~~🔑 **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`](../bind-api-sandbox/VALIDACION-API.md). Ver [REGISTRO #32](REGISTRO.md).
 - [ ] 📨 **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](REGISTRO.md) §10, [#35](REGISTRO.md).
@@ -76,6 +134,9 @@ _Última actualización: 2026-08-10 (Balam definió el flujo Jira→BIND en el c
 
 ## 🟡 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](REGISTRO.md), [#63](REGISTRO.md).
+- [ ] 📅⚠️ **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](REGISTRO.md).
+- [ ] 🧾 **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`.
 - [x] ~~**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](REGISTRO.md), [#19](REGISTRO.md).
 - [ ] 🔑 **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.
 - [x] ~~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](REGISTRO.md).

bitacora/REGISTRO.md

@@ -7,15 +7,32 @@
 - **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)
+- **Erika Chavez** — Project Manager, Balam — `erika.chavez@balamtalentoestrategico.com` · WhatsApp +52 1 81 2353 5803 · ⚠️ **PM del proyecto hasta el 12-ago-2026**, cuando Noé anunció su relevo ([#65](REGISTRO.md))
+- **Pedro Alberto Ayala Elizondo** — Desarrollador / contacto técnico, Balam — `pedro.ayala@balamtalentoestrategico.com` · ⭐ **responsable del seguimiento del proyecto desde el 12-ago-2026** ([#65](REGISTRO.md))
+- **Arturo Rosas Hernandez** — Gerencia administrativa / operación, Balam — `arturo.rosas@balamtalentoestrategico.com`
+- **Paola de los Angeles Castro Martínez** — Recursos Humanos, Balam — `hr@balamtalentoestrategico.com` · coordinó la firma del contrato (WhatsApp)
 
-**Periodo:** 30 abr 2026 → 22 jul 2026 (última actualización: sesión de reglas Etapa 1 — alta de clientes, fee y flujo Jira, 22-jul)
+**Periodo:** 8 abr 2026 → 21 ago 2026 (última actualización: **21-ago** — ⭐ **primera cotización real emitida en BIND desde un ticket** (folio 1026, [#69](REGISTRO.md)); `Type=2` y `VAT` como tasa, indocumentados. Anterior: **20-ago** — cruce completo del buzón de Outlook vía MCP ms365 + recuperación del transcript del **12-ago**. Se incorporan 10 comunicaciones que faltaban y se corrigen 2 errores. ⭐ **Cambio de gobernanza: Pedro Ayala releva a Erika en el seguimiento del proyecto desde el 12-ago.** Próxima sesión: **viernes 21-ago, 7:00 am** con Noé, Ara y Pedro sobre `FAC-106`)
 **Orden:** cronológico (más antiguo arriba)
 
 ---
 
+## 0 · Abr 8–28, 2026 · Correo · Prehistoria comercial — cómo se fijó la tarifa por hora
+
+> ⚠️ **Entrada de inventario (añadida el 20-ago-2026).** El registro arrancaba el 30-abr con la solicitud de cotización; el buzón muestra que **la relación comercial se abrió cinco semanas antes**. Los cuerpos de estos correos **aún no se han leído** — se listan aquí para que dejen de estar fuera del registro. Es el hilo donde se pactó la tarifa por hora que sostiene todo lo demás.
+
+| Fecha | Movimiento |
+|---|---|
+| 8-abr | Paola (RH) → Johann · "Johann Velazquez - Proyecto Balam" |
+| 23-abr 10:18 am | **Noé abre el hilo "Propuesta de servicios por hora - Balam"** 📎 — *"En seguimiento a la llamada de días previos para colaborar con nosotros como proveedor de servicios y sobre tu interés en participar en procesos de consultoría en desarrollo, automatización e IA (agentes, automatización, SLM's)…"* |
+| 23-abr | Araceli · "Sesión Balam" + dos respuestas al hilo 📎 · Johann responde dos veces |
+| 24-abr | Paola 📎 · Johann responde 📎 |
+| 27–28-abr | Paola cierra el hilo |
+
+**Además, dos firmas en Buk sin explicar:** "Tu documento está listo" + código de firma el **30-abr** y otra vez el **5-may** — anteriores al contrato de servicios de junio ([#18](REGISTRO.md), [#19](REGISTRO.md)). Son dos documentos firmados que este registro nunca mencionó. **Acción:** identificar qué se firmó (¿NDA, convenio marco?) y si condiciona algo del contrato posterior.
+
+---
+
 ## 1 · Apr 30, 2026 — 4:38 PM · Erika Chavez → Johann
 
 > **Asunto:** Solicitud de cotización – PRD
@@ -100,12 +117,20 @@ Con estas respuestas puedo tener la propuesta lista en 24–48 horas. Si prefier
 
 ## 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.)*
+> **Asunto:** RE: Solicitud de cotización – PRD · 3:42 PM · Para Noé, CC Johann
+> ✅ **Evidencia recuperada el 20-ago-2026** del buzón (MCP ms365): `../fuentes/2026-05-06 - Correo - Araceli respuestas al cuestionario (hilo PRD).md`
 
 *"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.
+✅ **RESUELTO (20-ago-2026).** El correo apareció íntegro en el buzón y las respuestas quedaron transcritas en `../fuentes/2026-05-06 - Correo - Araceli respuestas al cuestionario (hilo PRD).md`. Lo que confirma:
+
+- ⭐ **Banco americano = "IBC BANK, es un banco Texano e ingresamos vía web."** — deja de ser inferencia de la llamada del 19-may: **está por escrito desde el 6-may**.
+- ⭐ **Tax = "Por el momento TAX estándard"** — ídem.
+- **PAC:** *"Integrado hasta donde se en el mismo sistema de Bind, confirmo está contenido dentro del precio del ERP."*
+- **Pagos con tarjeta:** no tienen terminal; lo que buscan es **mandar un link de pago** y/o **domiciliación** ("pólizas, etc"). Matiza el punto 3 de arriba: no era un problema de registro manual.
+- **Manual de marca:** sí existe y lo pueden compartir (se entregó el 1-jul, [#23](REGISTRO.md)).
+
+> ⚠️ **Único residuo:** el cuerpo se recuperó como **texto plano**, así que el resaltado verde no es recuperable y no puede distinguirse tipográficamente qué contestó Araceli y qué Noé. El contenido, que era lo que faltaba, sí está completo.
 
 ---
 
@@ -620,6 +645,26 @@ Noé responde al hilo de la entrega del token con dos instrucciones:
 
 ---
 
+## 31a · Jul 6, 2026 — 4:46 PM · Correo · Johann → Noé, Pedro (CC Erika) · respuesta formal con las salvaguardas ✅
+
+> Evidencia: `../fuentes/2026-07-06 - Correo - Johann respuesta salvaguardas token.md`. **Recuperado del buzón el 20-ago-2026.**
+
+> 🔧 **Corrección de registro.** Este correo faltaba. [#33](REGISTRO.md) y [PENDIENTES.md](PENDIENTES.md) daban la respuesta formal a Noé por **no enviada** ("borrador listo… falta la respuesta formal por correo"), y así llevaba **mes y medio**. Se envió el mismo 6-jul, **13 minutos después** del correo de Noé de las 4:33 pm ([#31](REGISTRO.md)).
+
+Johann contesta punto por punto las salvaguardas que ya estaban operando:
+
+- **Solo lectura, bloqueado en código:** *"el cliente que uso bloquea desde el código cualquier operación de escritura, así que no hay forma de modificar datos"*.
+- **Consumo acotado:** pocas consultas, resultados pequeños, *"muy por debajo del límite diario de BIND"*.
+- **Token fuera del repo:** *"no queda en el repositorio ni en registros, lo guardo en un gestor de secretos"*.
+- **Sin datos reales en documentación:** solo estructura de la API (nombres de campos y tipos), *"sin información real de clientes o facturas"*.
+- **Escritura diferida** y disposición inmediata a cambiar de token: *"si Pedro lo crea, de mi lado cambiar el token es inmediato y no afecta el avance"*.
+
+> **Lectura estratégica:**
+> - El pendiente 📧⚠️ más viejo del proyecto **nunca existió**: estaba cumplido desde el día uno. Lo que sí sigue abierto es la contraparte de Balam — que Pedro decida si crea el usuario de solo lectura ([#37](REGISTRO.md)).
+> - Confirma el patrón de canal: la instrucción de riesgo de Noé se respondió por correo (evidencia formal) **y** por WhatsApp vía Erika ([#33](REGISTRO.md)).
+
+---
+
 ## 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).
@@ -649,7 +694,7 @@ Noé responde al hilo de la entrega del token con dos instrucciones:
 
 **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é.
+**Acción derivada:** confirmación informal, no sustituye la respuesta formal por correo a Noé. ✅ **La respuesta formal SÍ se envió**, el mismo 6-jul a las **4:46 pm** — ver [#31a](REGISTRO.md). *(Corrección del 20-ago: este registro y PENDIENTES la daban por pendiente con "borrador listo" desde hace mes y medio.)*
 
 > **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.
@@ -769,6 +814,18 @@ Balam responde que lo revisará internamente y compartirá comentarios. La retro
 
 ---
 
+## 40a · Jul 10, 2026 · Correo · Reacción de Balam al prototipo: acuse de Erika y Noé fuera de oficina
+
+> Añadido el 20-ago-2026 desde el buzón. Complementa [#40](REGISTRO.md), que registraba el envío pero no la respuesta.
+
+- **2:13 pm — Erika → Johann, Noé (CC Pedro):** *"Buenas tardes Johan. Confirmo de recibido. Saludos!"* — acuse seco, sin comentarios de fondo.
+- **12:14 pm — Noé: respuesta automática de ausencia.**
+
+> **Lectura estratégica:**
+> - **Explica el silencio sobre el entregable.** El prototipo se envió a Erika y Noé; Noé estaba fuera de oficina ese día, y la validación real no ocurrió hasta el **24-jul** ([#55](REGISTRO.md)) — dos semanas después. El entregable de la Etapa 0 estuvo dos semanas sin lectura del CTO, y el registro no lo hacía visible.
+
+---
+
 ## 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`.
@@ -846,6 +903,29 @@ Erika solicita un corte del avance de la Etapa 1. Johann se compromete a prepara
 
 ---
 
+## 46a · Jul 16, 2026 — 1:01 PM · Correo · Erika → Johann · procedimientos de carga de facturas (5 portales) 📎
+
+> **Adjunto recuperado y guardado el 20-ago-2026:** `../fuentes/2026-07-16 - Correo - Procedimientos de cargas de facturas-clientes.zip` (1.7 MB). Cierra el pendiente *"conservar correo/adjuntos como evidencia"* de [#46](REGISTRO.md).
+
+**Asunto:** Procedimiento de cargas de facturas-Proyecto integración Balam
+
+El ZIP trae **16 archivos en 5 carpetas**, un procedimiento por portal de cliente, cada uno en `.docx` + `.pptx` (guía con capturas):
+
+| # | Cliente | Archivos |
+|---|---|---|
+| 1 | **Cemex** | docx + pptx (912 KB — el más extenso) |
+| 2 | **Acuntia** | docx + pptx |
+| 3 | **ATC Consolidados** | docx + pptx |
+| 4 | **DYLO** | docx + pptx |
+| 5 | **Victec** | docx + pptx |
+
+> **Lectura estratégica:**
+> - ⭐ **Dos clientes que el Discovery nunca mencionó: `ATC Consolidados` y `Victec`.** Las particularidades de envío levantadas el 6-jul ([#27](REGISTRO.md)) hablaban de Axie, CEMEX, Dilo y Acuntia. Aquí Axie no aparece, "Dilo" se escribe **DYLO**, y salen dos portales nuevos. **El universo de destinos no está cerrado.**
+> - **No son "correos con particularidades", son portales de carga.** El Discovery los trató como variantes del envío por correo; el material muestra procedimientos de **subida a portal del cliente**, que es otro tipo de trabajo — y otro alcance si algún día se automatiza.
+> - **Sigue pendiente leerlos** y contrastarlos contra el prototipo y el MVP.
+
+---
+
 ## 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`).
@@ -1067,6 +1147,16 @@ Cierre de la sesión (~0.5 h real). **B6 conforme al plan:** `ITenantOwned` en l
 
 ---
 
+## 57a · Jul 22, 2026 — 2:24 PM · Correo · Erika → Johann · flujo de facturación de Jira (diagrama) 📎
+
+> **Adjunto recuperado y guardado el 20-ago-2026:** `../fuentes/2026-07-22 - Correo - Flujo facturacion JIRA BALAM.png`. Cierra el pendiente *"conservar el correo del flujo de facturación de Jira como evidencia/insumo"* de [#57](REGISTRO.md).
+
+**Asunto:** Flujo de facturación JIRA — es el envío que Erika anunció por WhatsApp ese mismo día ([#57](REGISTRO.md), 2:26 pm: *"ya envié por correo el flujo de facturación de Jira"*).
+
+Diagrama del flujo tal como Balam lo tenía documentado **antes** de las definiciones del 30-jul–7-ago ([#62](REGISTRO.md)). **Acción:** contrastarlo contra el disparador acordado (`En proceso de facturación`) y contra lo observado por API, para detectar dónde el diagrama oficial y la instancia real difieren.
+
+---
+
 ## 58 · Jul 27–28, 2026 · WhatsApp Erika ↔ Johann · avance de Etapa 1 entregado, Excel de horas para FACTURACIÓN y Jira aún sin licencia ⭐
 
 > Continuación de [#57](REGISTRO.md). Registrado a partir de capturas de pantalla del hilo (4 imágenes). Cubre el envío del avance del 27-jul y los pedidos de Erika del 27 (tarde) y 28 (mañana).
@@ -1085,7 +1175,7 @@ Johann envió el **avance por actividad en texto** (8:12 am), con 👍 de Erika
 **28-jul, mañana — el propósito del Excel y dos pendientes:**
 1. **(8:36 am) ⭐ "es para llevar el conteo de horas de cada etapa sobre todo para la FACTURACIÓN correspondiente de la misma."** → El Excel de horas es el insumo de facturación, no solo seguimiento.
 2. **(9:12 am) "johann adicional, ¿pasaste la propuesta con lo adicional de JIRA que no estaba contemplado?"** → Johann (10:58 am): **"Aún no la comparto, te la paso a la brevedad."** ⚠️ Es el compromiso que viene arrastrándose desde el 22-jul ([#57](REGISTRO.md)).
-3. **(9:27 am)** Sobre Azure: Johann preguntó si el acceso lo iba a entregar Noé o Pedro → Erika: **"Sip"** + *"deja pregunto"* (11:01 am). Johann pidió contexto de qué se requiere específicamente de Azure (11:19 am).
+3. **(9:27 am)** Sobre Azure: Johann preguntó si el acceso lo iba a entregar Noé o Pedro → Erika: **"Sip"** + *"deja pregunto"* (11:01 am). **Erika pidió a Johann contexto de qué se requiere específicamente de Azure (11:19 am)** — respondido esa tarde, ver [#59](REGISTRO.md). *(Corregido con la captura del hilo: la pregunta la hizo Erika, no Johann.)*
 
 **Lecturas clave:**
 > - **El Excel de horas es documento de facturación** (dicho por Erika, 28-jul 8:36 am). Cambia su naturaleza: ya no es reporte de avance, es sustento de cobro. Refuerza que las 41.58 h estén validadas y trazables.
@@ -1103,7 +1193,91 @@ Johann envió el **avance por actividad en texto** (8:12 am), con 👍 de Erika
 
 ---
 
-## 59 · Jul 30 – Ago 10, 2026 · Correo · Balam define el flujo Jira→BIND: disparador, campos y prueba acompañada ⭐🔥
+## 59 · Jul 28–29, 2026 · WhatsApp Erika ↔ Johann · requisitos Azure escalados a Noé, propuesta v1.3 + Excel de etapas entregados, seguimiento API Jira ⭐
+
+> Continuación de [#58](REGISTRO.md). Registrado a partir de capturas de pantalla del hilo (3 imágenes). Cierra los dos pendientes 🔥 de Johann que dejó #58.
+
+**28-jul, tarde — requisitos de Azure definidos y escalados:** Erika había pedido contexto de qué se requiere específicamente de Azure (11:19 am, ver [#58](REGISTRO.md)). **Johann respondió (4:53 pm): "un grupo de recursos con permiso de Contributor para desplegar la aplicación, la base de datos y el Key Vault de secretos. No requiere Global Admin ni cuenta nueva. Con eso puedo montar el ambiente y el CI/CD."** → Erika (5:23 pm): *"okey de acuerdo, deja lo solicito con el inge porque desconozco si pedro puede apoyarme con ese permiso que se requiere de azure"* — es decir, **el acceso a Azure quedó escalado a Noé**, no a Pedro.
+
+**28-jul, 5:38 pm — status check de Erika:** *"y ahorita estas detenido por algo o en que estas trabajando?"* → Johann (5:41 pm): **"Mientras tenemos la junta para ver el flujo de facturación, estoy trabajando en la integración con Jira, hoy en la noche podré compartirte el Excel de las actividades que llevamos más las de las siguientes etapas."** Erika: "De acuerdo" (5:42 pm). Buen manejo: la espera de B7 no se lee como bloqueo total porque el tiempo se redirige a la integración Jira.
+
+**29-jul, 8:18–8:19 am — entrega doble (cierra los dos pendientes 🔥 de [#58](REGISTRO.md)):** Johann envió por WhatsApp **`Propuesta-Balam.pdf` (v1.3, 21 págs)** y **`Avance-Balam-2026-07-28.xlsx`** con el mensaje *"Te comparto el excel y la propuesta con lo de Jira, cualquier cosa lo revisamos"*. Ambos archivos con 👍 de Erika; *"Buen día johan / Lo reviso gracias"* (9:35 am).
+
+**29-jul, 11:09 am — Erika pide formalizar por correo:** *"puedes compartirla en la cadena de correo donde adjuntaste la ultima version con los cambios que te dijo el inge noé pls para que la tengan todos"* (adjuntó captura del correo de la v1.2) → Johann: "Sin problema" (11:18 am) → **correo enviado a las 3:56 pm** (ver [#60](REGISTRO.md)).
+
+**29-jul, tarde — seguimiento a la API de Jira:** Erika (1:27 pm): *"Johan mande un correo para ver si nos puedes apoyar con tu retroalimentacion al respecto de la API de jira, si pudiste ingresar o se necesita algo adicional va"* → Johann (4:59 pm): **"Listo, también ya lo respondí, estaba haciendo unas pruebas extra para asegurarme de que no estuviese probando mal el token"** (era la etapa del 401, ver `../planeacion/Investigacion-API-Jira.md`). Erika: *"Lo valido con Pedro para ajustar"* (5:00 pm). **Johann pidió saber el correo desde el cual se generó el apikey** (5:00 pm) → Erika: "Sí claro" (5:18 pm). *(Resuelto el 30-jul: Pedro confirmó `pedro.ayala@balamtalentoestrategico.com`, regeneró el token y el `GET /myself` respondió 200 — Bloque 0 de la investigación.)*
+
+**Lecturas clave:**
+> - **Los dos pendientes 🔥 de Johann quedaron cerrados el 29-jul por la mañana:** propuesta ajustada por Jira (arrastrada desde el 22-jul) y Excel de horas de etapas siguientes. El hilo comercial más viejo se destrabó.
+> - **Azure ya no depende de Pedro:** Erika lo escaló a Noé porque duda que Pedro pueda otorgar el permiso Contributor. Los requisitos exactos ya están comunicados y por escrito (grupo de recursos + Contributor + Key Vault, sin Global Admin).
+> - **Erika opera como PM activa:** status check directo ("¿estás detenido?"), pide formalizar por correo lo que llega por WhatsApp, y da seguimiento al bloqueo del token Jira con Pedro. El patrón WhatsApp→correo confirma que **el correo es el canal de evidencia** para todo lo comercial.
+
+## 59a · Jul 29, 2026 · Correo · Erika ↔ Johann · seguimiento a la API de Jira en el hilo de Pedro
+
+> Añadido el 20-ago-2026 desde el buzón. [#59](REGISTRO.md) registró este intercambio **como WhatsApp**; los correos existen y son el canal donde realmente se documentó.
+
+- **1:25 pm — Erika → Johann** (hilo *"Seguimiento: medición de consumo API de Jira y accesos"*): pide retroalimentación sobre el acceso a la API de Jira.
+- **4:58 pm — Johann → Erika:** responde en el hilo. Es el *"Listo, también ya lo respondí"* que Erika acusa por WhatsApp a las 4:59 pm ([#59](REGISTRO.md)).
+
+> **Lectura estratégica:**
+> - Refuerza el patrón ya asentado: **WhatsApp coordina, el correo documenta.** Al registrar solo el lado de WhatsApp, el registro perdía el rastro del canal formal — justo el que Balam pide usar.
+
+---
+
+## 60 · Jul 29–30, 2026 · Correo · Johann → Noé (CC Ara, Erika, Pedro) · propuesta v1.3 (Jira→BIND) enviada y APROBADA por el CTO ⭐
+
+> Cadena de correo sobre el mismo hilo donde se envió la v1.2 (2-jul). Registrado a partir de captura de Outlook.
+
+**29-jul, 3:56 pm — envío de la v1.3:** Johann → Noé, CC Araceli, Erika y Pedro, con `Propuesta-Balam.pdf` (3 MB) adjunto. Puntos del cuerpo:
+- **Incorpora al alcance la integración Jira → BIND:** los tickets de la bandeja de Facturación generan automáticamente su cotización en BIND, con trazabilidad ticket → cotización → factura.
+- **Ajuste: 7 a 10 h ($4,200 – $6,000 MXN + IVA)**, en línea con la estimación de ~10 h comunicada el 21-jul ([#51](REGISTRO.md)).
+- **Total primera etapa: 119 a 146 h ($71,400 – $87,600 MXN + IVA)**, 6 a 8 semanas a media dedicación.
+- **El control fiscal no cambia:** la integración crea cotizaciones, nunca facturas. Se conserva la cadena cotización → prefactura → aprobación humana → timbrado por el PAC de BIND. Tarifa, facturación semanal y garantía siguen igual.
+
+**30-jul, 4:51 pm — ✅ APROBACIÓN de Noé (CTO):** *"De acuerdo con la propuesta actualizada para seguir avanzando con la integración de JIRA."*
+
+**Lecturas clave:**
+> - **La integración Jira→BIND queda formalmente dentro del alcance, aprobada por el CTO y por correo** — el canal de evidencia correcto. Las 7–10 h del ajuste son ahora horas contratadas.
+> - Con esto, el alcance de la primera etapa queda cerrado en **119–146 h**. La aprobación llega un día después del envío: sin fricción comercial.
+> - La aprobación habilita continuar la parte técnica de la integración ([`../planeacion/Investigacion-API-Jira.md`](../planeacion/Investigacion-API-Jira.md)), aunque **el código productivo sigue bloqueado por decisiones de negocio** (estatus disparador, request type, fuente de monto/conceptos) y por la aprobación explícita de cada prueba de escritura.
+
+**Pendientes que dejan #59–#60:**
+- [x] ~~Johann — enviar la propuesta/adenda ajustada por Jira→BIND~~ → **Hecho (29-jul) y APROBADA por Noé (30-jul).**
+- [x] ~~Johann — enviar el Excel de horas de las etapas siguientes~~ → **Hecho (29-jul):** `Avance-Balam-2026-07-28.xlsx`.
+- [x] ~~Johann/Pedro — destrabar el acceso a la API de Jira (401)~~ → **Resuelto (30-jul):** correo del apikey confirmado, token regenerado, `GET /myself` → 200.
+- [ ] Balam/Noé — **otorgar el acceso a Azure** (grupo de recursos con Contributor; escalado por Erika el 28-jul 5:23 pm). Bloquea ambiente, staging y CI/CD.
+- [ ] Balam/Erika — **avisar fecha de la sesión del flujo de facturación** tras su revisión interna. Desbloquea B7.
+- [ ] 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.
+
+---
+
+## 61 · Ago 1, 2026 · Desarrollo · Recuperación del plan: E1 técnica cerrada (B5/B6/B8/B9), frontend de lectura de E2 completo y cliente Jira ⭐
+
+> Sesión de trabajo del sábado 1-ago para poner el proyecto donde el plan del 28-jul dice que debería estar, y adelantar todo lo que no depende de Balam. 9 commits nuevos en `pedro-balam-itsm/BALAM` (pusheados junto con los 7 que faltaban de B0–B6 — **el repo del cliente ya refleja todo el trabajo**).
+
+**Entorno (bloqueos propios resueltos):** el backend no compilaba en esta máquina (faltaba apuntar al SDK .NET 10 de `~/.dotnet`); Docker apagado. Resuelto y documentado en el CLAUDE.md del repo. `bind_token_api.txt` borrado del disco (el token vive solo en user-secrets).
+
+**Etapa 1 — deuda técnica cerrada (lo no bloqueado):**
+- **B9 · `DevDataSeeder`** ✅ — datos demo 100% ficticios opt-in (`Seed:DevData=true`): 5 clientes (con caso de dedup), 11 facturas cubriendo los 5 estados × MXN/USD × PUE/PPD, 3 cotizaciones y 2 vínculos con ticket ficticio. Idempotente, fechas relativas a "hoy" MX. **Cierra el entregable 8 y el pendiente "se reportó como hecho el 27-jul".** Runbook en CLAUDE.md.
+- **B6 · verificación RLS real** ✅ — rol `balam_app` (NOSUPERUSER/NOBYPASSRLS) creado y con ownership de las tablas; la connection string de desarrollo ya lo usa. Verificado fail-closed por psql: sin GUC 0 filas, INSERT rechazado. Script de init para volúmenes nuevos en `backend/db/init/`.
+- **B5 · scheduler** ✅ — `BackgroundService` + `PeriodicTimer` cada 15 min (configurable; ≤0 lo apaga) con guardas de solape y de cuota (<10% restante salta el ciclo). **Primer ciclo real contra BIND detectó el movimiento desde el 27-jul: 3 facturas nuevas, 46 pagos, 2 cotizaciones nuevas.**
+- **B8 · `Balam.Api.Tests`** ✅ — 25 pruebas de integración con el API completo contra Postgres real (`balam_test`, recreada por corrida): matriz rol→policy (401/403/200), login sin filtración de correos, cartera multimoneda contra la fixture demo, paginación/filtros, PDF demo sin tocar BIND. **Total de la solución: 61/61 pruebas verdes.**
+
+**Etapa 2 — recuperadas las filas vencidas (29-31 jul) y adelantadas las de la semana próxima (solo lectura, nada bloqueado):** andamiaje Angular (sesión JWT en señales, interceptor, guards por rol espejo de las policies, login) · shell con identidad de marca y estado del sync · cartera por moneda **sin total combinado** · listado de facturas con búsqueda/filtros/paginación/orden del lado del servidor (el API se extendió para ello) · detalle con desglose y **descarga de PDF vía proxy** (el token de BIND nunca llega al navegador) · catálogo de clientes con dedup visible y **export CSV** (facturas y clientes). Verificado end-to-end con login real por el proxy de desarrollo. **Fuera de alcance por bloqueo:** creación de cotizaciones y conversión (flujo sin validar por Balam), XML (shape sin confirmar con Pedro), tipo de cambio DOF (diferido: la captura al facturar depende de B7).
+
+**Integración Jira — todo lo posible sin Balam:** proyecto `Balam.Integrations.Jira` espejo del cliente BIND (Basic auth email:token, `search/jql` con `nextPageToken` — el clásico da 410—, changelog, transiciones con `expand=transitions.fields`, servicedeskapi, rate limit leído de headers `X-RateLimit-*`), con los tres modos ReadOnly/DryRun/Write y **read-only por default** (FAC es producción); 10 pruebas con `FakeHandler`. Los modelos persisten el **id numérico inmutable** (la llave FAC-nnn cambia con un move — Bloque 5). Registro condicional en el API (+`/api/jira/status`). ⚠️ **Las pruebas de lectura contra FAC real quedaron bloqueadas EN ESTA MÁQUINA: `propuesta/token-jira.txt` no existe aquí (quedó en la otra computadora, gitignoreado).** Script listo para correrlas en un comando: `planeacion/pruebas-jira-lectura.sh`.
+
+**Pendientes que deja la sesión:**
+- [ ] Johann — **copiar `propuesta/token-jira.txt` a esta máquina** y correr `planeacion/pruebas-jira-lectura.sh` (bloques 2/3/4/5 de la investigación, solo lectura).
+- [ ] Johann — **crear el sandbox Jira Cloud Free propio** (decidido 1-ago) para desarrollar transiciones/comentarios/creación sin tocar FAC.
+- [ ] Johann — **capturar las horas del 28-jul→1-ago** en el CSV (propuesta preparada, pendiente de validación) y regenerar el Excel de avance desde el script (la copia en disco está desincronizada — re-guardado manual del 28-jul).
+- [ ] Johann — demo del viernes 7-ago: ya hay material (frontend + seeder demo + scheduler).
+
+---
+
+## 62 · Jul 30 – Ago 10, 2026 · Correo · Balam define el flujo Jira→BIND: disparador, campos y prueba acompañada ⭐🔥
+
+> ⚠️ Nota de merge (11-ago): esta entrada se escribió en la otra máquina como "#59" sin conocer las #59–#61 locales; se renumeró a #62 al integrar ambas líneas de trabajo.
 
 > Hilo `RV: Seguimiento: medición de consumo API de Jira y accesos` (fuente original conservada localmente; no versionada porque contiene cabeceras y adjuntos completos del correo). Continúa [#56](REGISTRO.md). Es **la definición del flujo de facturación que estaba bloqueando B7 desde el 24-jul** ([#55](REGISTRO.md), [#58](REGISTRO.md)).
 
@@ -1116,7 +1290,7 @@ Johann envió el **avance por actividad en texto** (8:12 am), con 👍 de Erika
 | 3-ago 4:58 pm | Noé **escala internamente** a Araceli y Arturo (CC Pedro), reconociendo el cambio de propósito: *"el flujo de JIRA tenía un propósito claro, validar la actividad y la evidencia, ahora cambiar a ejecutar y automatizar actividades con el desarrollo"*. Entra **Araceli Sánchez** al hilo. |
 | 3-ago 4:59 pm | Noé a Johann: *"Estamos definiendo para darte respuesta mañana mismo"*. |
 | 4-ago 12:15 pm | **Arturo responde en verde** sobre los tres puntos + adjunta captura del formulario y del filtro de request types. |
-| 7-ago 5:34 pm | Noé reenvía a Johann y **contesta la cuarta**: prueba acompañada. |
+| 7-ago 11:34 am | Noé reenvía a Johann y **contesta la cuarta**: prueba acompañada. *(Corregido el 20-ago: el registro decía 5:34 pm — se leyó como local la hora UTC 17:34.)* |
 
 **Las 4 definiciones, cerradas:**
 
@@ -1184,6 +1358,221 @@ Johann envió el **avance por actividad en texto** (8:12 am), con 👍 de Erika
 
 ---
 
+## 63 · Ago 11, 2026 · Correo · Noé confirma la sesión (mié 12-ago, 7:00 am) y rutea el ticket de ejemplo a ARACELI; Azure entra a la agenda 🔥
+
+> Respuesta de Noé (11-ago, 10:41 am) al correo del 10-ago ([#62](REGISTRO.md)). Registrado desde captura de Outlook. Para: Johann y Araceli; CC Pedro. **Arturo y Erika siguen fuera del hilo** (la nota del borrador de agregarlos al CC no se aplicó en el envío).
+
+**Lo que confirma:**
+- ✅ **Sesión: miércoles 12-ago, 7:00 am** (tomó la primera de las dos fechas propuestas).
+- 🔀 **El ticket de ejemplo queda asignado a ARACELI** (*"@Araceli Sanchez Jimenez por favor puedes generar el ticket en JIRA"*) — no a Arturo, como preveía la apuesta de PENDIENTES. Consistente con [#62]: Araceli es la aprobadora del workflow; el molde lo captura quien aprueba.
+- ☁️ **Azure entra a la agenda de la sesión:** *"De los permisos de Azure mañana lo podemos explorar para validarte los accesos con una cuenta que estamos creando para este uso"*. Primer movimiento desde el escalamiento del 28-jul ([#59](REGISTRO.md)) — y llega como **cuenta nueva creada para este uso**, no como permiso sobre una cuenta de Johann.
+
+**Verificación por API, noche del 11-ago** (script de lectura, todo 200): **el molde aún NO existe** — el sitio sigue en 69 tickets, 0 actualizados en la ventana. Y `FAC-98` (*"Baja Jorge Herrera L2"*, nacido de Automation, sin un solo campo estructurado) **lleva desde el 24-jul parado en `En proceso de facturación`** — 17 días en el estatus "que dura minutos": los tickets de Automation también rompen la premisa de duración, y es el exhibit vivo del supuesto asentado el 10-ago.
+
+**Lecturas clave:**
+> - **La latencia fue de un día, no de ocho.** La táctica del molde + fechas cerradas funcionó: Noé contestó en <1 día hábil confirmando todo.
+> - **Riesgo operativo para las 7:00 am: el molde no existe la noche anterior.** Plan B: que Araceli lo capture **en vivo al abrir la sesión** — convierte el riesgo en el mejor momento de la demo (captura → detección → wizard con sus datos, y siendo ella quien captura, el molde queda con la autoridad de la aprobadora). Plan C: correr sobre `FAC-100` (único con `Monto sin IVA` poblado; de paso pone ACUNTIA en la mesa).
+> - **La sesión ganó una segunda agenda (Azure).** Llevar a la mano los requisitos ya comunicados el 28-jul: grupo de recursos + **Contributor** (app + BD + Key Vault), sin Global Admin — para validar en vivo que la cuenta nueva alcanza.
+
+**Pendientes que deja el correo:**
+- [x] ~~Balam/Noé — confirmar la sesión~~ → **CONFIRMADA: mié 12-ago, 7:00 am.**
+- [ ] 🔥 Araceli — **crear el ticket de ejemplo** (pedido por Noé el 11-ago; no existe la noche del 11).
+- [ ] 🔥 Johann — **decidir y anunciar al abrir la sesión** el destino de la cotización real (cancelar al terminar vs. cliente de prueba) y que la prefactura pertenece a la 2.ª sesión.
+- [ ] ☁️ Johann — llevar los requisitos de Azure para validar la cuenta nueva en la sesión.
+
+---
+
+## 64 · Ago 11, 2026 — noche · Desarrollo · Capa de escritura mínima: ticket FAC → cotización BIND real, con dry-run y candados (lista para la sesión del 12) ⭐
+
+> Sesión nocturna previa a la prueba acompañada. Objetivo pedido: llegar con un ejemplo real de **"leer de Jira y escribir en BIND"**, no con simulación. 2 commits en `balam-plataforma` (locales, sin push).
+
+**El hueco que había:** el wizard de emisión (6-ago) simula la mitad *cotización → prefactura* y arranca desde una cotización BIND EXISTENTE; el ejercicio del 12 es la otra mitad, *ticket → cotización nueva*. Además el `BindClient` bloqueaba POST por diseño y el shape de creación nunca se había documentado (la doc "detallada tras login" seguía pendiente con Pedro).
+
+**El contrato se consiguió sin login:** el data-plane del portal de developers (APIM) responde anónimo. Operación **`Quotes_NewQuote` = `POST /api/Quotes`**, body con `ClientProspect{isNew, Client{ClientId, ClientName}}`, `Items[{Title, Unit, Price, Qty, VAT, IEPS, …}]`, `CurrencyID/LocationID/VATRate/Comments`; responde el **GUID de la cotización creada**. También existen `Quotes_UpdateQuote` y `Quotes_DeleteQuote` (la reversa por API existe, aunque la cancelación de la prueba se hará desde la pantalla de BIND). ⚠️ El SDK oficial de GitHub (2018) es ANTERIOR al recurso Quotes — no sirve de referencia. ⚠️ Semántica fina de partidas (`Type`, `SelectedUnit`, VAT ¿monto o tasa?) sin documentar: se valida contra la primera respuesta real, en la sesión.
+
+**Lo construido (73/73 pruebas verdes + smoke test de arranque):**
+- `BindClient.CreateQuoteAsync` — hereda las guardas del núcleo: en ReadOnly lanza, en DryRun loguea sin enviar, solo `Bind:Mode=Write` envía. 3 pruebas nuevas con `FakeHandler` (una por modo, la de Write valida el body PascalCase con `isNew` en minúsculas, sic del portal).
+- `POST /api/emision/cotizacion` (modo `DryRun`/`Confirmed`) — valida contra el catálogo sincronizado (el cliente DEBE existir en BIND), persiste **cada intento** en `WriteOperations` (ADR-001), y en Confirmed: crea, **verifica por lectura** (folio/total), refleja la Quote en nuestra BD y guarda el vínculo **ticket → cotización** en `QuoteInvoiceLink` (migración: `InvoiceId` ahora opcional — el vínculo nace en la emisión y se completa al facturar, ADR-003). Policy `PuedeOperarEscritura` (Finanzas/Administración). El 409 cuando el modo no es Write es el candado visible.
+- Pantalla **`solicitudes/:id/cotizar`** ("Generar cotización en BIND", botón nuevo en el detalle) — prellena cliente/moneda/monto/concepto desde el ticket, exige confirmar el cliente a mano (Jira no trae RFC), y aplica ADR-001 en la UI: **dry-run con el body exacto del wire** antes de habilitar Emitir; cualquier edición lo invalida; Emitir pide confirmación explícita con cliente y total.
+- Doc para Balam: `../planeacion/Script-cotizacion-sesion-2026-08-12.md` — el "script compartido antes" que pidió Noé el 24-jul (operación única, body de ejemplo, candados, reversa, qué NO hace). **Enviarlo esta noche.**
+
+**Guion de la sesión (7:00 am), afinado en la madrugada del 12 para la coreografía de pantalla compartida** (ellos capturan → Johann recarga y se ve llegar → un clic → confirmación → cotización): (1) anunciar que el ejercicio crea UNA cotización real y su destino; (2) molde de Araceli — si no existe, que lo capture EN VIVO compartiendo su pantalla; (3) Johann comparte la suya: **⟳ Actualizar** en la bandeja (nuevo: salta el caché de 60 s — sin esto el ticket recién capturado no aparecía) → el ticket se ve llegar; (4) abrir el ticket, repasar los campos que llenaron; (5) **"Crear cotización en BIND →"** (ahora CTA primario; también hay botón Cotizar por fila) → la vista previa del body se genera SOLA; (6) encender `Bind:Mode=Write` + reiniciar API → confirmar el diálogo → folio en pantalla → verlo en su BIND; (7) **apagar el modo Write ahí mismo**; (8) temas verbales (conceptos con el molde, ACUNTIA, Automation con FAC-98 de exhibit, PUE/PPD, cuenta de servicio, prefactura=2.ª sesión); (9) Azure con la cuenta nueva.
+
+**Lecturas clave:**
+> - **El compromiso del correo ("llego a la sesión con el flujo ya funcionando") queda cumplible sin el molde:** el flujo corre contra cualquier ticket de FAC; el molde solo mejora los datos.
+> - **La primera escritura real ocurre EN la sesión, nunca antes** — es literalmente el formato de prueba acompañada que autorizó Noé. Si BIND rechaza el primer intento (semántica de partidas), el error se lee en pantalla y se ajusta en vivo: para eso es la sesión.
+> - El default ReadOnly y la pantalla con candado convierten la salvaguarda de ADR-001 en algo que Balam puede VER — vale más que explicarla.
+
+**Pendientes que deja la sesión:**
+- [ ] 🔥 Johann — **enviar el script a Noé/Pedro esta noche** (doc listo en planeacion/).
+- [ ] 🔥 Johann — en la sesión: encender `Bind:Mode=Write` solo para emitir y **regresarlo a ReadOnly antes de cerrar**.
+- [ ] Johann — capturar las horas de esta sesión nocturna en el corte siguiente.
+- [ ] Johann — si BIND ajusta el shape en vivo (Type/SelectedUnit/VAT), documentar la semántica confirmada en `../planeacion/Investigacion-API-Jira.md` y en el CLAUDE.md del repo de la plataforma.
+
+---
+
+## 65 · Ago 12, 2026 — 7:00 AM · Llamada · Prueba de escritura Jira→BIND: **Pedro releva a Erika**, se decide que la plataforma genera la cotización y el primer POST falla con 500 ⭐🔥
+
+> Evidencia: `../fuentes/2026-08-12 - Transcript - Sesion prueba de escritura Jira-BIND.txt` (52 min). Asistentes: **Noé, Araceli, Pedro y Johann**. *(La diarización del transcript es poco fiable en varios tramos — atribuye a Noé frases que claramente son de Pedro; el contenido sí es legible.)*
+
+### 1 · ⭐ Cambio de PM — anuncio de Noé (2:26 y 4:12)
+
+> *"Nada más creo que no te había avisado, no sé si te lo mandé por correo o no. **Erika ya no va a ser la PM de este proyecto. El seguimiento del proyecto lo va a traer Pedro.**"* — y lo repite al cerrar el bloque: *"Bueno, este es un anuncio, Johann. **El tema del seguimiento es con Pedro.**"*
+
+Explica el vuelco de interlocución que se ve desde el 18-ago ([#67](REGISTRO.md)) y por qué Erika desaparece del hilo después del 29-jul. **Nunca llegó por correo** — el anuncio es exclusivamente verbal y vivía solo en esta grabación.
+
+### 2 · La lógica comercial de la cotización, explicada por Araceli (9:38–13:22)
+
+La explicación más completa que se ha obtenido de por qué existe la cotización:
+
+- **Día 1 / venta nueva:** comercial cotiza **directamente en BIND** para que el cliente acepte el monto. Requisito previo: **el cliente ya debe estar dado de alta**, o la cotización no sale con nombre ni RFC. Cerrada la venta, comercial solicita facturación **adjuntando esa cotización**; administración busca el número (p. ej. `01`) y desde el menú de la cotización en BIND da **prefactura o factura**.
+- **Recurrente:** comercial **no vuelve a cotizar**; solo avisa a administración el periodo (3, 6, 12 meses) y administración genera prefacturas y facturas. *"el área comercial no se entera cuando es recurrencia"*.
+- **Por qué existe la prefactura:** *"antes nos íbamos directamente a facturación, pero luego había muchos errores y ya estaban timbradas… era todo un rollo la cancelación con el SAT"* — hay clientes que deben aceptar la cancelación y *"CEMEX se tarda años"*.
+
+### 3 · ⭐ DECISIÓN: la cotización la genera la plataforma (13:23–14:15)
+
+Noé pregunta a Araceli si le serviría que **Jira generara la cotización** y le ahorrara el primer paso → *"Sí, sí me serviría"*. Noé: *"vamos a hacer ese ejercicio, Johann… eso va a quitar tal H que hoy por hoy se está haciendo desde el área comercial."*
+
+> ✅ **Cierra la contradicción 🔴 que llevaba abierta desde el 6-jul**: Ara había dicho que el comercial genera la cotización y la plataforma la convierte; Arturo dijo lo contrario el 4-ago. **Resolución: para venta nueva la genera la plataforma**, y el paso comercial desaparece. La recurrente sigue fuera de alcance.
+
+### 4 · ⚠️ El molde nunca existió — Pedro construye el formulario EN VIVO (14:43–29:52)
+
+Araceli confirma que **no hay tipo de ticket para cotización**: *"Jira no, fíjate que no lo tenemos, pero lo tendremos que definir"*. **El molde que Noé le encargó el 11-ago nunca se creó.** En su lugar, Pedro lo improvisa en la sesión: *"lo que puedo hacer es **construir un nuevo formulario muy rápido aquí en Jira** con campos muy muy especiales para la cotización y hacemos esa prueba en vivo"* — y se apoya en **el Excel que Johann había mandado esa misma mañana** ([#66](REGISTRO.md)): *"ya habíamos mapeado campos en un correo con Johann"*.
+
+**Campos acordados en vivo:** Empresa origen · Summary (título del ticket) · Descripción *(hoy texto libre; **debe ser combo**)* · Nombre del cliente *(**debe ser combo**, solo clientes dados de alta en BIND)* · Tipo de moneda · Monto sin IVA · Fecha de vencimiento *(= vigencia de la cotización)*. Además, **quitarle el SLA a estos tickets para que no impacten métricas**.
+
+### 5 · ⭐ El catálogo de BIND está sucio — y de ahí salen las 17 categorías (22:54–27:22)
+
+Araceli abre el combo de productos y servicios de BIND en pantalla y señala el desorden: *"consultoría y horas de servicio, este es **040 y 029, esto es absolutamente lo mismo**"*; hay entradas con números de personas, *"monitor Samsung"*, *"servicios profesionales 16 horas"*, periodos metidos en el nombre. Su conclusión: debería haber **solo opciones genéricas** y editarse el detalle en la cotización.
+
+**Acuerdo (Noé, 27:04):** *"Actividad pendiente: **depurar los campos que se van a usar en la cotización**, para que sean los mismos que van a estar en el combo desplegable y coincidan con los campos que se van a estar planchando en [BIND]."*
+
+> ⭐ **Éste es el origen de las "17 categorías" de Pedro** ([#67](REGISTRO.md)): de los **67 servicios** que Johann catalogó en el Excel a **17** depuradas. **Es la vía por la que se está resolviendo el hueco de conceptos/partidas** — no agregando un campo de partidas a Jira, sino limpiando el catálogo y volviendo combo la descripción.
+>
+> Dato fiscal capturado: horas de consultoría = **unidad SAT `E48`**.
+
+### 6 · 🔴 La primera escritura real a BIND — ERROR 500, no se creó cotización (30:08–49:59)
+
+- ✅ **El ticket creado en vivo se reflejó en la plataforma** de inmediato: *"ya se vio reflejado el ticket que hicimos aquí de prueba"*.
+- ⚠️ **El cliente no se detectó:** el mapeo venía del `summary`/`description`, no de campos estructurados. Johann lo resolvió en vivo con el endpoint de clientes de BIND y seleccionó **CEMEX**.
+- 🔴 **Al ejecutar el POST: error 500.** Diagnóstico en vivo: faltaban campos que el portal envía en ceros, y sobre todo **la lista de precios**.
+- **Araceli:** *"nosotros realmente **no tenemos una lista de precios**… ese lo podríamos agarrar del monto, del [Jira]. Ya ves que te pusieron **monto sin IVA. Ese sería nuestra lista de precios**."* Noé imagina que BIND multiplica cantidad × precio del servicio, pero Araceli confirma que **ellos capturan el número directo** — Pedro: *"como campo abierto"*.
+- Johann reintentó con un ítem existente; **la sesión cerró sin cotización creada**, con el compromiso de validar y avisar.
+
+> 🚨 **Corrige la lectura del [#64](REGISTRO.md).** La capa llegó probada en dry-run con 73/73, pero **el primer POST real contra BIND falló**. La semántica de partidas (`Type`/`SelectedUnit`/lista de precios) no está resuelta, y es exactamente lo que hay que llevar cerrado a la sesión del 21-ago.
+
+### 7 · Reglas de negocio que quedaron abiertas
+
+- **Edición de cotizaciones (32:49–39:05):** Araceli necesita modificar cotizaciones ("siempre hay ajustes"). Verificó en vivo que **BIND conserva el mismo número al editar** (cotización `10.19`) y solo registra la modificación. La plataforma **no tiene edición implementada**. Noé plantea la disyuntiva —**historial de cotizaciones** (nuevo ticket o regenerar) vs. **modificar la misma**— y la deja como definición de Balam: *"creo que como regla tenemos que definirlo nosotros, para no andar trayendo a Johann arriba y abajo"*. Araceli se inclina por conservar historial.
+- **Cancelaciones (41:53–45:06):** mientras no se timbre se puede cancelar libremente — *"mientras no las [timbremos] en CFDI, podemos cancelar y hacer las prefacturas que queramos"*. Ya timbrada: acuerdo con el cliente por correo → cancelación en el ERP → el despacho la cancela ante el SAT → **el cliente debe aceptarla en una liga del SAT**. **Decisión: el desarrollo NO ejecuta cancelaciones, pero sí debe llevar el récord** (*"esta factura se canceló y fue sustituida por esta"*).
+
+### 8 · Otros acuerdos
+
+- ☁️ **Azure sigue del lado de Balam.** Noé: *"Pendientes de nuestro lado hacia ti es el tema del ambiente de Azure… para que puedas irlo generando"* → *"eso lo resuelvo con Pedro"*. **No se exploró en la sesión**, pese a que el 11-ago se anunció que se vería aquí ([#63](REGISTRO.md)).
+- 📼 **Grabaciones de BIND:** Pedro tiene videos de altas de proveedor/clientes y facturación y quedó de enviarlos al terminar. **No consta que hayan llegado.**
+- 🗂️ **Herramienta de seguimiento del proyecto sin resolver:** 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 barajan **SharePoint** y **Google Drive**. Noé prefiere Jira pero falta el permiso de admin para crear spaces. Sigue vigente lo asentado en [#58](REGISTRO.md): **el Excel de horas es, de facto, el sistema de seguimiento**.
+- 🔒 **Candado reafirmado (Noé, 50:28):** *"esta es la primera prueba de escritura… habíamos acordado ser muy puntuales, **de no hacer más pruebas de lo que definiéramos**, para evitar errores o cosas en producción que puedan afectar"*. Johann ofrece **avisar a Pedro cada vez** que vaya a escribir una cotización o prefactura.
+- 🔁 **Pedro quiere jalar los catálogos de BIND por API** para no capturar a mano (50:59). Johann ofrece dárselos en JSON o Excel — de hecho **ya se los había mandado esa mañana** ([#66](REGISTRO.md)).
+
+> **Lectura estratégica:**
+> - **La sesión cambió la gobernanza del proyecto y no quedó registro escrito.** Un cambio de PM anunciado solo de viva voz, en una grabación que estuvo ocho días fuera de la bitácora, es exactamente el riesgo que la regla de oro busca evitar.
+> - **El Excel del [#66](REGISTRO.md) llegó una hora antes y se volvió el insumo de la sesión.** Sin él, Pedro no habría podido armar el formulario en vivo. La táctica de mandar "qué necesita el destino" se validó en tiempo real.
+> - **El molde de Araceli nunca existió y ya no hará falta:** el camino real fue formulario nuevo + catálogo depurado, no un ticket de ejemplo. Los planes B y C del [#63](REGISTRO.md) quedaron sin usar.
+> - 🔴 **El 500 es el pendiente técnico más caro que dejó la sesión** y sigue abierto ocho días después. La sesión del 21-ago es la segunda oportunidad de emitir la primera cotización real; conviene llegar con el shape del POST ya resuelto contra el nuevo formulario.
+
+---
+
+## 66 · Ago 12, 2026 · Correo · Johann → Pedro (CC Ara, Noé) · campos y catálogos de la cotización BIND ⭐
+
+> Evidencia: `../fuentes/2026-08-12 - Correo - Campos cotizacion BIND.md`. **Adjunto:** `../Cotizacion-BIND-campos-y-catalogos.xlsx`.
+
+**8:09 am — Johann entrega la estructura completa de la cotización en BIND**, en dos partes:
+
+- **Campos del formulario:** cada campo de la cotización, cuáles son **obligatorios**, y **el origen de las opciones** de cada combo.
+- **Catálogos con datos reales de BIND hoy:** **67 servicios, 3 productos, 17 clientes**, monedas, sucursales y listas de precios.
+
+**10:30 am — Pedro acusa:** *"Confirmo de recibido. Estaré trabajando en conjunto con el equipo para regresar con comentarios."*
+
+> **Lectura estratégica:**
+> - ⭐ **Es la jugada que destraba el hueco de conceptos/partidas.** Desde el [#62](REGISTRO.md) el único bloqueo real de B7 era que **Jira no tiene campo de conceptos**. En vez de pedirlo en prosa, Johann invierte la dirección: manda **qué necesita BIND para recibir** y deja que Balam ajuste el formulario de origen. Es la misma táctica del "molde" del 10-ago, pero al revés.
+> - **Funcionó.** El 18-ago Pedro reporta que **redujo el catálogo a 17 categorías** y que el formulario se armó *"con lo que marcaste en 'Sí' en el excel compartido"* ([#67](REGISTRO.md)). El Excel de Johann se volvió la especificación del formulario de Jira.
+> - ⚠️ **Los comentarios formales nunca llegaron por correo.** Pedro los prometió el 12-ago; se materializaron **6 días después y por WhatsApp**. El canal de evidencia volvió a quedar vacío.
+> - 📌 El Excel **sigue sin versionar en git** (está en la raíz del repo, sin trackear).
+
+---
+
+## 67 · Ago 18–20, 2026 · WhatsApp Johann ↔ Pedro · Pedro toma el timón: 17 categorías, formulario modificado y sesión del viernes 21-ago ⭐🔥
+
+> Evidencia: `../fuentes/2026-08-18 a 2026-08-20 - WhatsApp - Pedro formulario 17 categorias y sesion 21-ago.md`.
+
+**18-ago — comentarios al Excel, por fin:**
+
+- ⭐ Pedro: *"**logré reducirlo a 17 categorías** pero tengo que verlas con Noé y Ara antes"* (catálogo de servicios: de **67 → 17**).
+- ⭐ Pedro: *"del formulario son lo que **marcaste en 'Si' en el excel compartido**"* — el formulario de Jira se rehace contra los campos obligatorios de BIND.
+- Johann pide lo que necesita: **un ticket de prueba con el nuevo formulario**, para pasarlo a cotización.
+
+**19-ago — Balam mueve el formulario y convoca:** Pedro anuncia *"ya hemos realizado algunas **modificaciones en nuestros formularios y campos**"* y pide sesión **con Noé y Ara**, el viernes a las 7. Johann ofrece **preparar el caso de escritura** para esa misma sesión; Pedro acepta (*"si me parece bien el caso"*).
+
+**20-ago — el ticket llega el día antes, al filo:**
+
+- 9:48 am Johann pide el ticket para el ejercicio → 10:47 am *"dame un momento"*.
+- 3:43 pm ⚠️ *"de momento **no pude crear el ticket** debido a que **surgieron varios comentarios internos**, dejame tocar base con Noé"*.
+- 4:23 pm ✅ *"ya me confirmaron Johan, **mañana a las 7 am**"* + **`FAC-106`**.
+- 4:24 pm ⚠️ *"**no te dejará entrar debido a la licencia**"*, ofrece pantallazo de la estructura.
+
+> **Lectura estratégica:**
+> - 👤 ⭐ **Cambió el interlocutor del proyecto.** Desde el 18-ago **todo se coordina con Pedro**: comentarios, formulario, agenda, ticket y convocatoria. Erika (PM, contacto único durante toda la Etapa 0) **no aparece en el hilo desde el 29-jul**, y Noé pasó de definir a validar. Concuerda con lo que Johann recuerda de una junta donde se anunció a **Pedro como nuevo responsable del proyecto** — sin registrar ([#65](REGISTRO.md)).
+> - ⭐ **Balam cambió Jira para acomodar a BIND.** Es la primera vez en el proyecto que **el sistema origen se ajusta al destino** en lugar de pedirle al desarrollo que absorba la diferencia. El Excel del [#66](REGISTRO.md) fue el instrumento.
+> - ⚠️ **Las 17 categorías NO están validadas.** Pedro lo dice explícito: *"tengo que verlas con Noé y Ara antes"*. La sesión del viernes es donde eso se aprueba — y de ahí sale (o no) el mapeo de conceptos.
+> - 🔁 **Se repite el patrón del 11-ago:** el insumo de la sesión llega la víspera por la tarde y **no se puede inspeccionar** (entonces el molde no existía; hoy `FAC-106` existe pero la licencia bloquea la UI). **Mitigación disponible esta noche: leerlo por API** — el token PAF corre sobre la cuenta de Pedro, que sí tiene licencia, y es como se sondeó el sitio el 6-ago y el 11-ago. No hace falta el pantallazo para conocer la estructura.
+> - **El alcance sigue siendo la cotización**, no la prefactura ([#62](REGISTRO.md)); y la escritura real sigue gateada a `Bind:Mode=Write`, que se enciende solo durante la sesión ([#64](REGISTRO.md)).
+
+---
+
+## 68 · Ago 20, 2026 — 4:25 PM · Correo · Pedro → Noé, Johann · "Seguimiento - PAF" (convocatoria + FAC-106)
+
+> Evidencia: `../fuentes/2026-08-20 - Correo - Pedro Seguimiento PAF.md`. **PAF** = Plataforma de Automatización Financiera, el nombre con el que Pedro bautizó el token del proyecto el 27-jul ([#56](REGISTRO.md)).
+
+Correo escueto: la liga de **`FAC-106`** y la reunión de **Microsoft Teams** (Id. 280 788 665 449 275). Es el formalizado por correo de lo acordado por WhatsApp minutos antes ([#67](REGISTRO.md)).
+
+> ⚠️ **El correo no dice fecha ni hora.** La convocatoria real —**viernes 21-ago, 7:00 am**— consta solo en WhatsApp. Si alguien reconstruye el proyecto desde el correo, la sesión aparece sin fecha.
+
+> **Lectura estratégica:**
+> - **Noé va en el "Para", no en copia:** la sesión tiene al CTO como asistente, no como observador. Coincide con que se validan las 17 categorías, que Pedro no puede aprobar solo.
+> - Es el **primer correo del proyecto que no cuelga de un hilo previo** — asunto nuevo, con el nombre del proyecto. Encaja con el relevo de interlocución del [#67](REGISTRO.md).
+
+---
+
+## 69 · Ago 21, 2026 — 7:00 AM · Llamada + trabajo posterior · PRIMERA COTIZACIÓN REAL EN BIND desde un ticket (folio 1026) — tras 5 intentos y dos semánticas indocumentadas ⭐🔥
+
+> Asistentes: Noé, Araceli, Pedro, Johann. Preparación: [`../planeacion/Guion-sesion-2026-08-21.md`](../planeacion/Guion-sesion-2026-08-21.md) y [`../planeacion/Sondeo-FAC-106-y-payload-2026-08-20.md`](../planeacion/Sondeo-FAC-106-y-payload-2026-08-20.md). ⚠️ **Minuta de la parte de definiciones (17 categorías, Empresa origen, IVA 0%, Azure) pendiente de capturar por Johann** — esta entrada cubre la parte técnica, que quedó auditada en `WriteOperations`.
+
+**En la sesión (7:04–7:11 am) — tres intentos, cero cotizaciones creadas:**
+
+| # | Op | Body | Respuesta de BIND |
+|---|---|---|---|
+| 1 | 23 | sin `ID`/`Type` de partida, sin `PriceListID` | 500 **explícito**: *"Required property 'ID'… 'Type' not found… El ID de la lista de precio es requerido"* → se corrigió en vivo (lista "A" dada por Araceli) |
+| 2 | 28 | + `ID` servicio 027, `Type: 1`, `PriceListID` A, `Unit: "Servicio"`, **sin `ExchangeRate`** | 500 **genérico** `174068216` (*"comunicarte con soporte técnico"*) |
+| 3 | 34 | ídem con el servicio `ChargeVAT:true` | 500 genérico `174068255` |
+
+Se aplicó el protocolo del guion §6: parar, anunciar el diagnóstico, pivotear a las definiciones. **Verificado por lectura después de cada intento: 52 cotizaciones en BIND, ninguna nueva.** Al salir de la sesión, Balam autorizó seguir sobre `FAC-106` por ser ticket de prueba.
+
+**Investigación posterior (solo lectura):**
+- Schema tipado del portal (APIM, anónimo): `Items` son **`NewFullProducts`**, requeridos solo `ID` y `Type`, **sin enums ni descripciones**. Permiso descartado: el token trae `5|11|AgregarCotizacion`. `GET /api/Series?docType=n` devuelve `[]` para todo `n` (sin series → `DocNumberID` no aplica). El read model de `Quotes` reporta `PriceListID` = su propio `ID` (bug de BIND); la lista real de CEMEX es **"A" `03e4bb2d`** (`Clients.PriceListID`).
+- Intento 4 (op 44): + `ExchangeRate 1.0`, `Unit E48` + `SelectedUnit`, `Type: 1` → 500 genérico `174068365`.
+- ⭐ **Intento 5 (op 45): `Type: 2` → HTTP 200, folio 1026.** `Type` es **el catálogo donde BIND busca el `ID`: 2 = servicio, 1 = producto.** Indocumentado; solo descubrible por ensayo.
+
+**Pero el folio 1026 salió mal:** `VAT = 243,640.96` sobre base 1,234 = **1,234 × 197.44**. ⭐ **En el write model `Items[].VAT` es TASA (0.16), no monto** — BIND lo multiplica por precio × cantidad. El read model sí devuelve montos, lo que indujo el error. **Corregido en UI y con guard de 400** (misma regla que `VATRate`). **El folio 1026 debe cancelarse** (IVA absurdo) y la segunda emisión, ya con `VAT: 0.16`, debe dar 1,234 + 197.44 = **1,431.44 MXN** — folio y confirmación pendientes de Johann.
+
+> **Lectura estratégica:**
+> - **Se cumplió lo que la prueba acompañada existe para hacer:** dos semánticas que ningún documento de BIND contiene (`Type` y la escala de `VAT`) quedaron resueltas contra producción y escritas en el modelo. El costo fue un folio de prueba que se cancela sin efecto.
+> - **El primer error de BIND fue útil y los tres siguientes no:** cuando falla la validación del JSON, BIND dice qué falta; cuando falla por dentro, solo da un código. El diagnóstico salió de comparar con cotizaciones reales y del schema del portal, no del mensaje.
+> - **La plataforma se portó como se diseñó:** cada intento auditado en `WriteOperations` con body y respuesta, verificación por lectura entre intentos, y el candado de `Bind:Mode` encendido solo para emitir. Es el argumento de confianza ante Noé, y va en el correo.
+> - ⚠️ **Deuda que deja:** el GUID del servicio (027) y la lista de precios ("A") van **fijos en la UI**. Lo correcto es resolver el servicio desde el combo `Servicio/Producto` (17 categorías → GUID de BIND, que además hoy tiene 5 "Servicio de Enlace" distintos) y la lista desde `Clients.PriceListID`.
+> - Borrador del correo a Balam: [`../planeacion/Correo-error-resuelto-2026-08-21.md`](../planeacion/Correo-error-resuelto-2026-08-21.md).
+
+---
+
 ## Resumen ejecutivo del hilo (para contexto rápido)
 
 ### Datos duros confirmados por Balam

fuentes/2026-05-06 - Correo - Araceli respuestas al cuestionario (hilo PRD).md

@@ -0,0 +1,61 @@
+# Correo — 6 may 2026, 3:42 PM · Araceli Sánchez → Noé Rocha, Johann
+
+**Asunto:** RE: Solicitud de cotización – PRD
+**Recuperado del buzón el 20-ago-2026** (MCP ms365). Resuelve la evidencia que [REGISTRO #3a](../bitacora/REGISTRO.md) daba por perdida.
+
+> ⚠️ **Sobre el color:** el cuerpo se recuperó como texto plano, así que **el resaltado verde no es recuperable**; lo que sí queda es el texto íntegro con las respuestas intercaladas. Los cuatro puntos que Noé dejó como "TBD Ara" el 4-may aparecen aquí ya respondidos.
+
+---
+
+## Cuerpo de Araceli
+
+> Hola, Johann,
+>
+> Te respondo en verde.
+>
+> Gracias,
+> Saludos.
+
+## Hilo citado — Noé Rocha, 4 may 2026, 7:59 PM
+
+> Hola Johan,
+>
+> Te paso los comentarios más abajo de lo que se, algunos los tengo que investigar y otros los puede responder o aclarar Ara (TBD Ara)
+>
+> Saludos.
+
+### Respuestas intercaladas (pregunta de Johann → respuesta de Balam)
+
+**Integraciones**
+
+- ¿BIND ERP tiene API habilitada o se trabaja con exportación de archivos? → **Exportación de archivos**
+- ¿BUK expone API para consultar nómina procesada? → **No hasta donde sabemos**
+- ¿Los 3 bancos entregan estados de cuenta por API, archivos (CSV/OFX) o PDFs? → **PDF's**
+- ¿Cuál es el banco americano que manejan? → *TBD Ara* → **IBC BANK, es un banco Texano e ingresamos vía web.**
+- ¿Pueden dar acceso a ambientes sandbox de BIND y BUK para desarrollo, o solo cuentan con producción? → **Solo producción**
+
+**Facturación**
+
+- ¿Ya cuentan con un PAC contratado para timbrado CFDI? ¿Cuál? → **Integrado hasta donde se en el mismo sistema de Bind, confirmo está contenido dentro del precio del ERP.**
+- La facturación a clientes en Texas, ¿es invoice estándar o requiere tax compliance específico? → **Por el momento TAX estándard**
+- ¿EUR entra al MVP (RF-02) o se deja preparado? → **Dejarlo preparado para fase posterior, por el momento solo es USD la facturación con empresas Europeas.**
+
+**Cobranza**
+
+- ¿Quiénes son los "top 3 clientes" sin recordatorios? ¿Lista fija o configurable? → **Lista Configurable de acuerdo al objetivo de negocio.**
+- ¿Los tickets físicos en pagos con tarjeta son registro manual de terminal? → **No tenemos el pago con tarjeta de crédito, pero lo que estamos buscando es que podamos mandar un link para pago con tarjeta para que nuestros clientes puedan pagar, y/o mandar una liga en donde podamos domiciliar pagos como pólizas, etc**
+
+**Datos y sistemas**
+
+- ¿"BUk" es un sistema interno? ¿Tiene API o BD accesible? → **Es un SaaS, NOTA: no es Book, es BUK, y es nuestra plataforma de recursos humanos en donde manejamos contratos, nóminas, vacaciones, es el core de la empresa para la gestión del talento.**
+- ¿Jira es solo gestión de proyectos o también fuente de datos? → **Gestión de proyectos y servicios solamente con clientes.**
+
+**Operación**
+
+- ¿Cuántos colaboradores en nómina y cuántas facturas al mes? → **45 Colaboradores y 5 proveedores de servicios tipo Freelancer. Emitimos no más de 50 facturas al mes**
+- ¿Quién valida reglas de negocio durante el desarrollo? → **Un servidor y el gerente administrativo.**
+
+**Infraestructura y diseño**
+
+- ¿Servidor o nube preferida? → **Preferentemente Azure, si en costos beneficio hay otras estamos abiertos a evaluar.**
+- ¿Guía de marca / assets? → **Sí, tenemos un manual de uso de marca, que lo podemos compartir**

fuentes/2026-05-27 - WhatsApp - Pedro primer contacto.md

@@ -0,0 +1,16 @@
+# WhatsApp — 27 may 2026 · Pedro Ayala → Johann · primer contacto
+
+Volcado literal aportado por Johann el 20-ago-2026. Es el mensaje que [REGISTRO #9](../bitacora/REGISTRO.md) registra como la entrada de Pedro al proyecto.
+
+---
+
+- **09:57 Pedro:** Hola Johan muy buenos días
+- **09:58 Pedro:** te escribe Pedro Ayala de Balam.
+- **10:00 Pedro:** cómo estas? / oye me comenta Noé que **te hizo llegar la información acerca del desarrollo de agentes**, crees que con esa información nos puedas dar una propuesta.
+- **10:00 Pedro:** si no dinos para poder movernos a conseguir la información que se necesita
+- **10:01 Pedro:** quedo al pendiente. ¡saludos!
+- **10:01 Johann:** Hola Pedro, buenos días!
+- **10:03 Johann:** Sí sin problema, de hecho estaba trabajando en la propuesta ya para poderselas enviar
+- **10:04 Pedro:** excelente Johan, lo aprecio mucho / De igual manera si pudieras **darme copia en el correo** lo agradecería. Mi correo es pedro.ayala@balamtalentoestrategico.com
+- **10:05 Johann:** De acuerdo, aprecio tu acercamiento, se las comparto cuanto antes
+- **10:08 Pedro:** De acuerdo, Johan / Saludos

fuentes/2026-07-06 - Correo - Johann respuesta salvaguardas token.md

@@ -0,0 +1,20 @@
+# Correo — 6 jul 2026, 4:46 PM · Johann → Noé Rocha, Pedro Ayala (CC Erika Chávez)
+
+**Asunto:** Re: Entrega de Token Bind API
+**Recuperado del buzón el 20-ago-2026** (MCP ms365).
+
+> ⚠️ **Corrige el registro:** [PENDIENTES.md](../bitacora/PENDIENTES.md) y [REGISTRO #33](../bitacora/REGISTRO.md) daban esta respuesta por **no enviada** ("borrador listo"). Se envió el mismo 6-jul, **13 minutos después** del correo de Noé (4:33 pm).
+
+---
+
+> Buenas tardes, Noe
+>
+> De acuerdo, me parece bien la precaución. Te comento cómo estoy trabajando esta etapa:
+>
+> Todas mis consultas a la API son únicamente de lectura; el cliente que uso bloquea desde el código cualquier operación de escritura, así que no hay forma de modificar datos. Además hago pocas consultas y con resultados pequeños, muy por debajo del límite diario de BIND. El token no queda en el repositorio ni en registros, lo guardo en un gestor de secretos, y en mis notas solo documento la estructura de la API (nombres de campos y tipos), sin información real de clientes o facturas.
+>
+> La parte de escritura queda para más adelante.
+>
+> Y sin problema con el usuario de solo lectura, si Pedro lo crea, de mi lado cambiar el token es inmediato y no afecta el avance.
+>
+> Saludos.

fuentes/2026-08-12 - Correo - Campos cotizacion BIND.md

@@ -0,0 +1,27 @@
+# Correo — 12 ago 2026 · Johann ↔ Pedro Ayala · campos y catálogos de la cotización BIND
+
+**Asunto:** Campos Cotización en BIND
+**Adjunto:** `Cotizacion-BIND-campos-y-catalogos.xlsx` (en la raíz del repo)
+
+---
+
+## 12-ago, 8:09 AM · Johann → Pedro (CC Araceli, Noé)
+
+> Buenos días, Pedro. Espero que te encuentres muy bien.
+>
+> Te comparto un archivo de Excel con los campos requeridos por BIND para la creación de cotizaciones. El documento está organizado de la siguiente manera:
+>
+> - **Campos del formulario:** Detalla los campos de la cotización, indica cuáles son obligatorios y especifica el origen de las opciones para cada menú desplegable (combo).
+> - **Hojas adicionales (Catálogos):** Contienen los datos reales de cada combo tal como se encuentran configurados actualmente en BIND. Esto incluye: servicios (67), productos (3), clientes (17), monedas, sucursales y listas de precios.
+>
+> Quedo al pendiente,
+> Saludos
+
+## 12-ago, 10:30 AM · Pedro → Johann
+
+> Buenos días, Johan.
+>
+> Muchas gracias por la información compartida. Confirmo de recibido.
+> Estaré trabajando en conjunto con el equipo para regresar con comentarios.
+>
+> Saludos,

fuentes/2026-08-12 - Transcript - Sesion prueba de escritura Jira-BIND.txt

@@ -0,0 +1,554 @@
+RE: Seguimiento: medición de consumo API de Jira y accesos
+Wed, Aug 12, 2026
+
+0:00 - Unidentified Speaker
+¡Gracias por ver el vídeo!
+
+0:36 - Unidentified Speaker
+A Pedro, buenos días.
+
+0:41 - Unidentified Speaker
+¿Qué tal, ingeniero?
+
+0:45 - Unidentified Speaker
+Buenos días.
+
+0:47 - Pedro Alberto Ayala Elizondo
+Estoy comiendo un agua, perdón.
+
+0:54 - Unidentified Speaker
+Sí, a vos, boludo.
+
+1:10 - Pedro Alberto Ayala Elizondo
+Y a qué hora se arranca?
+
+1:14 - Noe Rocha
+A qué hora se arranca? A las nueve y media. ¿La sesión? Sí, la de Dilo. La que tienen programada con Centro, me refiero. Sí, a las nueve y media. Ya hablé con Marcos para incluir a Salvador. ¿Por qué quieren que se impulgue Cruz Más Salvador en esta sesión?
+
+1:47 - Unidentified Speaker
+Ok.
+
+2:14 - Noe Rocha
+Listo. Hola Johann, buenos días.
+
+2:16 - Unidentified Speaker
+¿Cómo estás?
+
+2:17 - Johann
+¿Qué tal Pedro? ¿Qué tal Araceli? Buenos días. ¿Y ustedes? ¿Cómo están?
+
+2:22 - Araceli Sanchez Jimenez
+Hola Johann, muy bien. Muchas gracias. Buenos días.
+
+2:26 - Noe Rocha
+Estamos muy bien, gracias. Oye, Johann, bueno, esta sesión es en seguimiento a lo que hemos estado platicando. Nada más creo que no te había avisado. No sé si te lo mandé por correo o no. Erika ya no va a ser la PM de este proyecto. El seguimiento del proyecto lo va a traer Pedro. Después de todo lo que vamos a estar realizando contigo. Nada más quisiera asegurar que... Pedro, no sé si se alcanzó a ver con Erika el tema del Gira del seguimiento con las actividades de Johann.
+
+3:05 - Noe Rocha
+Sí, ya se tiene creado lo que es el Gira.
+
+3:09 - Pedro Alberto Ayala Elizondo
+Pero habíamos llegado a la conclusión de que ese tablero muy próximo iba a necesitar que sea de paga por el tipo de licencia que tenemos. Exploramos también la posibilidad de hacerlo mediante un SharePoint. Y también está la posibilidad de hacerlo con un Google Drive, que es algo más sencillo y un poco más... Que ya estamos todos familiarizados con cómo funciona un Google Drive o cómo funciona Google Drive. ¿Cómo funciona un SharePoint?
+
+3:39 - Noe Rocha
+Pero hoy vamos a ver lo del RegioTour, ¿no? También, el anterior. Sí. Ah, ahí es donde falta el admin de acceso, para que puedas crear spaces. Sí. Ah, bueno, lo vemos eso, porque me interesa hacerlo sobre Jira, porque ya que ese puede funcionar. Bueno, muy bien.
+
+3:56 - Pedro Alberto Ayala Elizondo
+Entonces, nada más sería de crearlo y sería de copiar las actividades que ya están en el otro y se agregan. Y sobre esas actividades, sobre esas tarjetas, Se van actualizando las actividades a medida que se avanza. Bueno, para resolverlo hoy.
+
+4:12 - Noe Rocha
+Bueno, este es un anuncio, Johann. El tema del seguimiento es con Pedro. Y bueno, vamos a resolver el tema de Jira para que haya el récord de lo que has estado haciendo. Pendientes de nuestro lado hacia ti es el tema del ambiente de Azure, ¿verdad? Para que puedas irlo generando.
+
+4:34 - Unidentified Speaker
+Sí.
+
+4:35 - Noe Rocha
+Ok. Bueno, eso lo resuelvo con Pedro. Y último punto. Adelante, Pedro. Sí, también tengo los videos de los que faltaban de las grabaciones de Bind.
+
+4:46 - Pedro Alberto Ayala Elizondo1
+Ah, sí. Que es el de altas de proveedor y clientes, facturación. Y al tercero no me acuerdo, pero ahí está. Ahí lo tengo en la carpeta. Si quieres, al finalizar la sesión te los hago llegar.
+
+5:04 - Noe Rocha
+Sí, es más informativo, Johann, de cómo funciona Bind, por si necesitas algún dato adicional. Contexto. Contexto y módulos, ¿no? Y ya después de eso puedes tener alguna reunión si es necesario para aclarar. Bueno, muy bien, Johann. Ahora sí, ya con lo que estuvimos viendo vía correo electrónico de los giras, cómo se generan los procesos de facturación y cómo vamos a empezar a hacer algunas integraciones, dimos algunas respuestas contigo. Sobre hacer una prueba sobre un ticket. Te dimos respuesta en cuanto a los campos que nosotros estamos considerando usar en las etiquetas o en los requisitos que se tienen en el space de facturación, que habías preguntado. Y es solamente en facturación adicional se va a tomar en cuenta. Y te comentábamos que básicamente todo lo y todos los type requests que mencionamos nosotros. Ahora, nos habéis pedido que hiciéramos un ticket, ¿cierto? Como para hacer una prueba con los campos que se tendrían que usar. ¿Por qué? Porque lo que estábamos haciendo era que nosotros metíamos una solicitud de facturación con una cotización adjunta como primer paso. Y esa cotización viene de Vine. O sea, ya viene como cotización. Lo que nosotros mencionábamos es que, aparte de la cotización, vinieran los campos ya llenados del propio JIRA, para que los datos se extrajeran de los campos de JIRA, no de un PDF o un documento junto. De acuerdo? Y de ahí vamos a partir a hacer, recuérdame, ahora sí, platícanos qué vamos a hacer con Sí, claro.
+
+6:58 - Johann
+Lo que se pretendía, lo que pretendía hacer ahorita en esta sesión, era con el ticket creado, ya con los campos definidos y llenados, como querían que fueran llenados de aquí en adelante, hacer una prueba con la plataforma, en donde vemos cómo se ve el ticket de Jira, reflejado en la bandeja de Jira, y creamos una cotización. A partir de ella. Y de ahí ver, también de mi parte, qué hay que ajustar. Porque hasta ahora he estado haciendo pruebas de dry run. O sea, no he mandado nada, no mando ningún post hacia el RP de Byte. Entonces también me serviría como primer caso. Muy bien.
+
+7:46 - Noe Rocha
+Es que mira, creo que hay una aclaración que Araceli haciendo ayer. Me dice que en la definición que ella se hizo con Arturo, que estaba haciendo parte de esto, y en las definiciones de los flujos de gira, y corrígeme, Rassely, si estoy mal para darle ese contexto a Johann, cuando se hace la solicitud de una facturación adicional, ya viene una cotización, ¿cierto? Directamente de Bain. Sí. Muy bien. Entonces tú lo que necesitarías en sí, pues ya no es la cotización cuando tú, tú como área comercial generas el ticket con una solicitud de cotización adicional.
+
+8:39 - Unidentified Speaker
+Tú lo que necesitarías sería.
+
+8:43 - Araceli Sanchez Jimenez
+Quien yo o Johann. Sí.
+
+8:46 - Noe Rocha
+Sí, no tú, tú estás hablando del proceso, de tu necesidad y proceso.
+
+8:52 - Johann
+A ver, ¿otra vez la pregunta?
+
+8:54 - Noe Rocha
+Sí, es que lo que estábamos explorando específicamente en este caso con Johann es que cuando hay una solicitud de facturación adicional, en un primer escenario se manejaba, o al menos eso es lo que yo entendí con Arturo, que la cotización fuera creada desde Jira, pero en el proceso como tú lo definiste para Jira es, no, tú ya integras la cotización desde un principio y esa cotización viene ya desde Vine. Entonces, cuando hablamos de cotización, no hablamos de un documento, una cotización fuera del sistema, sino del mismo sistema. O sea, ya no necesita ser la cotización, pues, porque tú ya lo hiciste.
+
+9:38 - Araceli Sanchez Jimenez
+Bueno, miren, si quieren les voy a explicar el proceso. Es algo que yo haya definido. Eso suena como si fuera una imposición. Se los voy a explicar porque dado que estamos haciendo algo nuevo, si hay algo que cambiar, lo hacemos. Les voy a decir cómo es el tema comercial, si y por qué nace así. Hagan de cuenta que la empresa es el primer día, el día cero. Entonces, pues no hay nada de facturación recurrente que hacer ni nada porque vendido sí entonces yo vendo el primer proyecto entonces la parte comercial para vender el primer proyecto tengo que cotizarlo para que sobre esa cotización el cliente me acepte el monto entonces yo lo que hago ahorita es yo genero directamente desde el rp la cotización si desde el rp entonces para generarla antes el cliente ya tiene que estar dado de alta porque si no pues no va a salir con su nombre ni el rfc y todo eso entonces una una vez que yo ya lo vendí y ya lo cerré pues yo solicito la factura entonces como yo ya tengo la factura del sistema yo solicito facturación y cuando yo solicito la facturación yo subo la cotización ¿Por qué? Porque como la cotización ya está en el sistema, nada más buscan mi número de cotización, el 01, entonces tú te vas al RPI, además ahí ves cotizaciones, te vas a la 01 y en el menú de esa cotización viene prefactura, factura o cancelar o modificar. Entonces tu administración le da prefactura o factura, como sea, ¿sí? Entonces ese es un proceso. Cuando yo vendo por primera vez algo y entonces yo tengo que cotizarlo. Yo qué estoy haciendo? Ya lo estoy cotizando siempre desde el sistema. Si la parte comercial. Luego qué pasa si esta venta es recurrente? Es decir, que se cierra por un año o dos. Yo el otro mes, yo como comercial, Yo no vuelvo a generar una cotización. Yo nada más informo a administración que esa facturación va a ser recurrente y le doy el tiempo 3, 6, 4. Y entonces yo comercial con ese aviso, yo ya no me encargo de cada mes estar haciendo la cotización para que facture. Lo que hace ya con el aviso administración es generar la pre-facturas y después las facturas. ¿Por qué se generan las pre-facturas? Antes nos íbamos directamente a facturación, pero luego había muchos errores y ya estaban timbradas. Entonces, era todo un rollo la cancelación con el SAT. Porque hay unos clientes que tienen que aceptar la cancelación y hay otros que no. Y SEMEC se tarda años en cancelar. Entonces, lo que hicimos fue... ¿Qué hicimos? Porque yo también estoy metida en la parte administración, administración, todo lo que es recurrente hace una prefactura, las valida y entonces ya las factura, pero es el área comercial no se entera cuando es recurrencia. Sí. Entonces. Pues así es el proceso y, por ejemplo, si la parte comercial vende algo y no es recurrencia, pues entonces la cotización que hizo comercial es la que se factura.
+
+13:22 - Unidentified Speaker
+Ok.
+
+13:23 - Noe Rocha
+Ahora, pregunta. ¿A ti se te facilitaría que desde el mismo JIRA, si no hicieras ese primer paso de cotización, JIRA hiciera la cotización? La verdad que sí. ¿Para que no tengas que estar adjuntando actividad? Bueno, para el día 1, vamos a hablar del día 1. ¿Sí te sirve que JIRA haga la cotización?
+
+13:47 - Araceli Sanchez Jimenez
+Sí, sí me serviría. Ok.
+
+13:50 - Noe Rocha
+Bueno, entonces vamos a hacer ese ejercicio, Johann. Sí, porque creo que eso va a ser una parte de lo que va a quitar, pues, tal H, tal H que hoy por hoy se está haciendo desde el área comercial. Entonces, lo que quedamos era de tener un ticket para una prueba de que ese ticket fuera a ser la cotización.
+
+14:14 - Unidentified Speaker
+¿Cierto, Johann? Sí, justamente.
+
+14:15 - Noe Rocha
+Muy bien. Ahora, Rassely. ¿Tenemos algún caso de algún ticket que ya esté creado para no tenerlo que hacer de cero? O si lo creamos ahorita, digo, no nos tardamos mucho para hacer esa prueba y ese ejercicio de decir, oye, estos son los datos ficticios, ¿verdad? Vamos a hablar de ficticios de algún cliente para que sea cotización de alguien que existe. Y vaya y hagamos la prueba con Johann para hacer la cotización.
+
+14:43 - Araceli Sanchez Jimenez
+Sí, lo podríamos hacer porque puedo inventar los datos aquí el tema es que no hay un ticket que yo pueda usar o sea una categoría por ejemplo yo podría meterme ahorita Gira y poner una actividad en general este y pero en la descripción del cuerpo y tendría que poner exactamente qué hacer si entonces yo no sé si después hay un flujo en donde sea cotización.
+
+15:11 - Noe Rocha
+Gira no, fíjate que no lo tenemos, pero lo tendremos que definir.
+
+15:16 - Araceli Sanchez Jimenez
+Sí, pero entonces si quieres, podemos hacer un, dejen, abro, vamos a hacer un, aunque el flujo ahorita no lo tengamos definido, voy a agarrar uno de, ahorita comparto la pantalla, uno de actividad general para, para verlo.
+
+15:32 - Noe Rocha
+Nada más, ojo, Johann, yo me acuerdo, tú estás trabajando sobre el space de gira de facturación, ¿verdad? Sí.
+
+15:41 - Araceli Sanchez Jimenez
+Ah, tendría que ser sobre este. Sí, bueno. Ok. Voy a agarrar este de facturación adicional, aunque sea cotización por primera vez. Estamos de acuerdo. Sí. Ok. Si ven mi pantalla.
+
+15:56 - Unidentified Speaker
+Sí, sí.
+
+15:57 - Araceli Sanchez Jimenez
+Ok. Bueno, aquí.
+
+15:58 - Pedro Alberto Ayala Elizondo1
+Ah, sí, yo lo que es es que, pero aunque te interrumpa, pero él desde un principio se había quedado que trámite de pagos se quedaba en la bandeja de administración general. Pero la verdad es que ahorita, siendo todo lo que estamos platicando y que haga sentido, tenemos sentido que la parte de trámite de pagos caiga en la bandeja de facturación.
+
+16:23 - Araceli Sanchez Jimenez
+Pago proveedores, esto no es el.
+
+16:25 - Pedro Alberto Ayala Elizondo1
+Mire, ahora sí puede ir a la pago a proveedores, papi.
+
+16:29 - Araceli Sanchez Jimenez
+Sí, a eso se refiere. Mira, es que aquí está en administración. Ajá.
+
+16:34 - Pedro Alberto Ayala Elizondo1
+Tramitación de pagos es los pagos nosotros vamos a hacer a proveedores pero bueno también tiene razón Pedro también son pagos de nómina directamente a nuestros colaboradores entonces lo que podría hacer yo es replicarlo o sea no no borrarlo de aquí para no no dejarlo fuera del alcance también de la administración general lo puedo replicar en en facturación le pongo los campos necesarios en ese y hacemos la prueba con esos campos necesarios nada más.
+
+17:10 - Araceli Sanchez Jimenez
+¿Como para cotización te refieres? Ajá.
+
+17:13 - Pedro Alberto Ayala Elizondo1
+Entonces, lo que puedo hacer es construir un nuevo formulario muy rápido aquí en Jira con campos muy muy especiales para que Yoja necesite para la cotización y hacemos esa prueba en vivo.
+
+17:29 - Noe Rocha
+Ok, como quieran.
+
+17:31 - Noe Rocha
+¿Cuánto te tardas? Para ser muy puntuales con el tiempo de Johann. Porque el hijo solo tiene una hora.
+
+17:39 - Araceli Sanchez Jimenez
+No, no, me tardo cinco minutos.
+
+17:41 - Araceli Sanchez Jimenez
+Si quieres, yo te digo los campos que tienen que tener Pedro.
+
+17:46 - Noe Rocha
+Bueno, ya habíamos mapeado campos en un correo con Johann. Que en ese correo con Johann eran los campos de, déjame ver, nada más el correo que le mandamos.
+
+17:57 - Araceli Sanchez Jimenez
+Sí, está de empresa origen. Eso sí tiene que ir, Pedro.
+
+18:02 - Noe Rocha
+Sí, porque tú ya tienes mapeados los campos con respecto a lo que te mandamos, ¿verdad, Johann?
+
+18:11 - Johann
+Sí, pero igual ahorita podemos trabajar en ajustarlos.
+
+18:16 - Araceli Sanchez Jimenez
+Pues si ya los tienen, a lo mejor trabajemos sobre esos y ya ahorita los rechecamos.
+
+18:24 - Pedro Alberto Ayala Elizondo1
+Muy bien, entonces...
+
+18:26 - Noe Rocha
+Voy a ponerlos aquí en el chat. Voy a ponerlo aquí en el chat. Porque creo que son los de... Es que sabes que Arturo no me mandó exactamente de dónde sacó esta pantalla. Pero tú la identificas, Pedro. Ah, es esta, Gordo.
+
+18:46 - Araceli Sanchez Jimenez
+La que te está... Es administración general. Es un ticket genérico. Y esa no me sirve mucho. Entonces, si quieres, yo te los puedo dictar porque yo hago las cotizaciones. Es más, mira. Lo que podemos hacer es agarrar de las cotizaciones, si me entiendes. O sea, aquí tengo un cliente, por ejemplo, este. Mira, esta es la cotización que yo genero por sistema.
+
+19:15 - Araceli Sanchez Jimenez
+Por ejemplo, es la empresa.
+
+19:17 - Araceli Sanchez Jimenez
+Pero esto ya me lo carga el ERP, ¿verdad? Y luego empresa y luego quién es el cliente. Y es en automático me lo hace y ya después de eso es la descripción verdad que es y yo le pondré la descripción el precio unitario y que me diga la moneda si es pesos o dólares ok sí y bueno que ella y ya o sea si es pesos o dólares pues le calcula el sistema en calcula automático eso y es todo lo que tiene la cotización. Yo lo que hago en la parte comercial o esto es nada más un comercio. Ahora sí, un comentario. Así que, por ejemplo, yo como vendo, ejemplo horas de consultoría proyecto soda pues eso no le dice nada al cliente yo siempre le mando esto adjunto del alcance sí o de do de mi propuesta más granular tantos o sea ya como todos los pasos y todo eso pero yo siempre le mando esto porque al final de día la factura va sobre esta descripción muy bien Listo.
+
+20:38 - Noe Rocha
+Si puede. Johann, qué tan puntuales hay que ser con la información? Porque. Porque si todos estos campos. Tienen que ser llenados en vain. El campo que no venga en el formulario no lo va a poder, no lo va a poder poner verdad?
+
+20:56 - Araceli Sanchez Jimenez
+Mira, te voy a decir cuáles campos no son, no están. Esto está cargado en vain todo esto porque es Así se configura. El receptor también. ¿Por qué? Porque yo lo que ayer te decía, que el único requisito para yo generar, para que existe en el sistema, es que esté dado de alta el cliente. ¿Sí? Y eso ya no es tema de este alcance. ¿Sí? Entonces, la parte comercial, cuando tiene un nuevo cliente, su responsabilidad, pedir en el RP que lo den de alta. Entonces, cuando la dan de alta, esto está en automático. Y ya esto se carga, esto lo hace, ya está por default, esto también es por el sistema, porque es fecha de creación. La fecha de vencimiento, ahí sí, Pedro, la fecha de vencimiento hay que preguntarla, la fecha de creación es cuando tú la solicitas, pero la fecha de vencimiento es la vigencia de la cotización, eso sí lo tendríamos que nosotros preguntar, porque eso sí yo lo hago. Esto elaborado por ISOCURSAL, eso está por default en el sistema. Y yo luego nada más lo que agarro es esto, horas de consultoría.
+
+22:14 - Noe Rocha
+¿Es un campo que existe o es un campo que llenas?
+
+22:20 - Araceli Sanchez Jimenez
+Es un campo que existe.
+
+22:22 - Araceli Sanchez Jimenez
+¿En combo? ¿Cómo que en combo? Es decir, una lista desplegable Sí, hay nada más, por ejemplo, en el ERP, pero eso ya es fuera del alcance de Johann. Miren, me voy a meter en Vine para explicarles mejor.
+
+22:43 - Pedro Alberto Ayala Elizondo
+Ya está también el formulario en Jira.
+
+22:47 - Noe Rocha
+Ah, órale. Un momentito, voy a ponerme cargado.
+
+22:53 - Unidentified Speaker
+Sí.
+
+22:54 - Araceli Sanchez Jimenez
+Mira, Johann, yo cuando hago una cotización, me meto aquí a ventas, me voy a cotizaciones y me voy a agregar. Sí, le doy a agregar. Por ejemplo, aquí voy a hacer la cotización de Cemex. Entonces, mira, aquí son las opciones. Por ejemplo, esto es lo que te tendría que preguntar qué moneda es, pesos. Aquí la fecha, te la pone por default y es la de hoy. Y aquí es la vigencia, ¿no? Entonces yo ya le pongo la vigencia. Y luego aquí ya busco el cliente. Este cliente ya tiene que estar dado de alta. Entonces aquí me aparecen las opciones de los clientes. Entonces yo le pongo CEMEX. Y luego aquí, agregar producto o servicio. Pues nosotros, normalmente vendemos intangibles, o sea, servicios. ¿Pero por qué te digo normalmente? Porque casos excepcionales, clientes nos piden equipo o accesorios como de ADM, mouse, y entonces, estas las tengo que poner aquí. Aquí yo he visto que hay un tema de depuración del ERP. Por ejemplo, yo le pongo agregar producto o servicio. Y si te das cuenta, hay varios repetidos en que, por ejemplo, consultoría y horas de servicio, este es 040 y 029, esto es absolutamente lo mismo, te das cuenta. Luego está desarrollador, aquí está equipo iPad, equipo telefónico, headhunting, pero luego, por ejemplo, pusieron ya números específicos de personas, si me entiendes, aquí habría que depurarlo, o monitor Samsung o no sé qué. Aquí lo único que debieron de haber puesto es un genérico, Por ejemplo, ¿en qué sentido? ¿Horas de consultoría? ¿Por qué? Porque si yo le doy estas horas de consultoría, yo aquí lo puedo editar. ¿Sí me entiendes? No tiene caso que haya otras horas de consultoría. Por ejemplo, esta es la 040, el código, y no tiene caso que haya un 029 porque no hay un diferenciador. Estos números nada más son de uso interno en el sentido que esto, el SAT, Entonces, con lo que se timbra, por ejemplo, aquí voy, mira. Cuando yo tengo, esta es la unidad del SAT, la E48. Entonces, las horas de consultoría tienen esta unidad ante el SAT, ¿sí? Entonces, aquí nosotros, de nuestro lado, lo que hay que hacer es, cuando dice Noe que están en un combo, debería de estar en un combo aquí. Lo depuramos para que nada más haya las opciones genéricas. ¿Sí me estoy explicando? Mira, porque aquí de servicios profesionales, mira, ve cuántos hay. Y, por ejemplo, aquí también hay código servicios profesionales, 16 horas. Y aquí, aquí habría que, mira, por ejemplo, hay unos que dieron de alta hasta con los periodos y así. Entonces, habría que depurarlo. Mira, aquí hay muchos nombres. Entonces aquí nada más debería de ser que tú pongas si es servicios y consultoría o que pongas nada más aquí el el desglose de lo que necesitas que lleve la cotización bueno pero entonces nada más para estar seguro y lo que se pueda hacer Johann si es como antes yo antes aquí nada más lo que hacer es en el espacio de la pantalla de JIRA que se desplieguen nada más esas opciones. Por ejemplo, servicios de consultoría, equipo de cómputo o eso ya yo lo definiría con Pedro en la cotización, porque dependiendo de eso sí es la unidad del SAT correspondiente.
+
+27:04 - Noe Rocha
+Actividad pendiente, depurar los campos que se van a usar en la cotización, para que sean los mismos que van a estar en el combo desplegable y coincidan con los campos que se van a estar planchando en Vine.
+
+27:22 - Unidentified Speaker
+¿De acuerdo?
+
+27:23 - Araceli Sanchez Jimenez
+Para propósitos de la prueba ahorita, ¿usaríamos cuál? El de servicios y consultoría. Está aquí en facturación, verdad, Pedro?
+
+27:34 - Pedro Alberto Ayala Elizondo
+O en dónde lo pusiste? Debe estar ahí en facturación.
+
+27:39 - Araceli Sanchez Jimenez
+No me aparece.
+
+27:40 - Pedro Alberto Ayala Elizondo
+Debe de estar. Está en general. A ver, déjame ver si yo.
+
+27:46 - Araceli Sanchez Jimenez
+En la administración general.
+
+27:48 - Pedro Alberto Ayala Elizondo
+No, no, no.
+
+27:49 - Unidentified Speaker
+En facturación.
+
+27:50 - Unidentified Speaker
+Mira, a mí sí me parece.
+
+27:53 - Araceli Sanchez Jimenez
+Si le puedo dar un refresco a todo.
+
+27:57 - Araceli Sanchez Jimenez
+Super ya cotización vain. Bueno, Empresa Origen, Malam, Sumari. Aquí en Sumari, ¿a qué te refieres, Pedro?
+
+28:08 - Pedro Alberto Ayala Elizondo
+Pues es como el título del Gira, del Ticket. Del Ticket.
+
+28:13 - Noe Rocha
+Ese es del Ticket. OK, entonces aquí luego lo ajustamos.
+
+28:18 - Araceli Sanchez Jimenez
+Sí, ponle Cotición Semex Prueba, si quieres.
+
+28:21 - Pedro Alberto Ayala Elizondo
+Esa, la descripción, hoy por hoy es texto, pero como usted dice, va a haber la lista, el convito desplegable.
+
+28:31 - Araceli Sanchez Jimenez
+Sí. Este. Horas de consultoría. Proyecto. OK. Aquí nombre del cliente se mix. También debería ser combo.
+
+28:42 - Unidentified Speaker
+Ajá.
+
+28:43 - Araceli Sanchez Jimenez
+Aquí yo no sé cómo le haríamos, porque debería de ser nada más los clientes que están dados de alta en en vain. El rp pero bueno eso eso ya lo vemos nosotros no semex tipo de moneda montos iniba esos como box tendrían exactamente el nombre de los combo box del rp va a tratar de homologar nombres y todo ok aquí la fecha de vencimiento me imagino que es la vigencia de la cotización verdad ok Bueno, luego los ajustamos bien. Ajá. Pues creo que ya. Ok. Y en este caso a estos tipos de tickets les quitaría el SLA para que no impacten métricas. Como son accionables.
+
+29:52 - Unidentified Speaker
+Ah, ok.
+
+29:53 - Unidentified Speaker
+Muy bien.
+
+29:54 - Unidentified Speaker
+Listo.
+
+29:55 - Unidentified Speaker
+Muy bien.
+
+29:56 - Unidentified Speaker
+Ok.
+
+29:57 - Unidentified Speaker
+¿Y ahora qué más?
+
+29:59 - Pedro Alberto Ayala Elizondo
+Necesito ver alguna otra pantalla o de gira.
+
+30:08 - Johann
+Ahorita estoy probando y ya se vio reflejado el ticket que hicimos aquí de prueba.
+
+30:21 - Unidentified Speaker
+¡Hija!
+
+30:22 - Unidentified Speaker
+Déjeles comprar tu pantalla.
+
+30:26 - Johann
+¡Qué emoción! Aquí, por ejemplo, Sí, ahorita, por ejemplo, la forma en la que se estaba mapeando el cliente conforme los campos, era a partir del summary o a partir de aquí, el resumen. Entonces, con el campo, Me haría falta mapearlo ahora sí, con el combo box.
+
+31:04 - Pedro Alberto Ayala Elizondo
+Ya, o sea, el summary con...
+
+31:07 - Unidentified Speaker
+o más bien, el summary o la description.
+
+31:11 - Unidentified Speaker
+Sí.
+
+31:12 - Johann
+Sí, los campos que ahorita resulten como nulos o que no los detecte, ya me haría falta ajustarlos con los nuevos campos de este nuevo formulario.
+
+31:25 - Noe Rocha
+Bueno, nada más hay que homologar entonces a Ara y Pedro, porque una de las respuestas que le dimos a Johann es que todos los requests type iban a tener el mismo tipo de formato, para que a partir de una solicitud de factura se hiciera la cotización. Entonces habría que estar seguros Porque todos los tipos de recuestas que tenemos, como ahorita es facturación recurrente también, tratar de homologar todo a lo mismo. Entendería yo que en el caso de facturación recurrente, ese trailer trae un campo adicional. ¿Te puedes devolver tantito, Johann? Que aquí mismo lo menciona. De hecho, sí lo trae mapeado. Y lo vi.
+
+32:17 - Unidentified Speaker
+Recurrencia. Recurrencia, sí.
+
+32:19 - Noe Rocha
+Sí viene.
+
+32:20 - Noe Rocha
+Ahora Johann, aquí tenemos una duda y que estuvimos discutiendo cómo resolverlo de forma interna, si lo resolvíamos a través de nosotros en el sistema o veíamos la forma de resolverlo contigo y te voy a plantear el caso. Pero antes de seguir, esto que hicimos, esta prueba que hicimos nada más para ir por pasito, ¿lo vas a convertir en una cotización?
+
+32:49 - Araceli Sanchez Jimenez
+Oigan, yo tengo un comentario. En la parte comercial pasa muchísimo que, por ejemplo, le mando la cotización y siempre hay ajustes. O sea, y yo lo que hago en Vine, porque, por ejemplo, ya generé la cotización, esta, por ejemplo, esta cotización de Cemex, ¿no? Entonces, me dijo, no, ahora sube los amasadoras, quítale, bájale, no sé qué. Entonces, a esta cotización, yo en Vine me meto y le pongo modificar, ¿sí? Y modifico aquí alcance, precio y todo eso. Entonces aquí se modifica la cotización. ¿Yo voy a tener opción también de modificar la cotización o no?
+
+33:32 - Johann
+Aquí ahora mismo no está implementada la parte de editar la cotización. Pero igual la podemos trabajar.
+
+33:42 - Araceli Sanchez Jimenez
+Sí, eso sí, Johann.
+
+33:45 - Araceli Sanchez Jimenez
+Yo lo que haría hace cuenta tendría que cancelar hasta que sea la buena y sería todo un rollo para la parte comercial. O si ustedes creen también por. Bueno, es que yo llevo el historial en mi carpeta, pues porque de repente es cotización. Digo, porque eso sí, me he dado cuenta que cada vez que modificas la cotización no te conserva el. Según yo, el mismo número o no estoy tan segura. Si te conserva el número o no.
+
+34:15 - Noe Rocha
+Yo sugiero que eso sea regla de negocio, que sería mejor o llevar un historial de las cotizaciones o estar modificando la misma cotización. En mi experiencia, a veces funciona tener el historial porque ese historial te permite saber cuántas veces le estás cotizando a alguien algún producto y en caso de que te diga Bueno, ya sabes que tienes la primera cotización origen o la base, pero es regla de negocio.
+
+34:47 - Araceli Sanchez Jimenez
+Habría que definir.
+
+34:48 - Araceli Sanchez Jimenez
+Yo creo que sí es bueno que conservemos el historial.
+
+34:53 - Noe Rocha
+Pues tendría que ser en lugar de modificar, tendríamos que generar tickets diferentes.
+
+34:59 - Pedro Alberto Ayala Elizondo1
+Y no se puede hacer algo así como. Que sea que si sea editar la cotización dentro aquí del sistema. Pero que haya un modulito de historial de facturas. Que sea la factura tal, se ha modificado tantas veces y está nacido su historial de versiones, por así decirlo.
+
+35:19 - Noe Rocha
+En teoría el historial se queda en BIND, Pedro. Y JIRA solamente sería como informativo. De decir, ah, bueno, mira, aquí en JIRA tuve cotizaciones 1, 2, 3, como informativo. Pero el documento viviría en BIND, porque va a cambiar el número de cotización. En todo caso, este caso de uso tendría que plantearse de dos formas. Como ya lo mencionamos. O generamos un nuevo ticket para generar una nueva cotización. O planteamos con Johann, con el mismo ticket, simplemente volver a pedir que genere la cotización. Los campos con los que nos están pidiendo, pero no modificar la cotización entera, simplemente volver a generar otra, pues no sé si me explica. Pero creo que como regla tenemos que definirlo nosotros, claro, para saber, para no andar trayendo a Johann arriba y abajo con Quita y Pong, ¿verdad?
+
+36:21 - Araceli Sanchez Jimenez
+Oye, nada más dejen, llámeme, estoy en Vine, reconfirmar que efectivamente cambia el número de cotización, porque si no, no se conserva el historial, no me hará sentido, pero nada más dejen Dejen ver si editar. 19. Disculpa, ese historial de personas que maneja internamente Bind, ¿cómo se genera?
+
+36:41 - Johann
+¿Es cuando editas una cotización y dentro de ahí, por ejemplo, te metes una cotización y aparece un apartado de historial que nosotros podemos acceder? ¿O cómo funciona esa parte? Pregunto para irme imaginando cómo es que se en el sistema. De pronto es un catálogo.
+
+37:04 - Araceli Sanchez Jimenez
+Oigan, fíjate que ahorita no les dije mal, no, no te da otro número de cotización. Miren, les voy a, les voy a compartir pantalla. Se mantiene, te modifica la que sobre la que estás trabajando.
+
+37:24 - Noe Rocha
+Entonces debe tener su.
+
+37:26 - Pedro Alberto Ayala Elizondo
+su historial de versiones con...
+
+37:29 - Noe Rocha
+Si tú lo modificas, no te cambia el número de cotización.
+
+37:35 - Araceli Sanchez Jimenez
+Tienes que hacer otra. Exactamente. Miren.
+
+37:38 - Unidentified Speaker
+Aquí estoy en la cotización.
+
+37:40 - Araceli Sanchez Jimenez
+Ya hay una cotización a 10.19. Entonces aquí yo en acciones me da esto, marcar como surtida, generar pedido, generar venta, copia, la, la, la. No entonces yo le voy yo le voy a dar en editar entonces yo la edito y aquí pues yo nada más le pongo cantidad 2 no y era las 10 19 perdón no sé si vieron el número de cotización si yo le voy a guardar y me mantiene esta y nada más y ahora me pone la modificación que aquí fueron dos le puede dar en actividades, si algo aparece ahí no mira, archivos no, documentos relacionados no, el detalle pues es este y desde ahí mismo se manda a facturación? Fíjate que curioso porque no sé si...
+
+38:57 - Pedro Alberto Ayala Elizondo
+O sea, usted dice de cotización 1019 a factura 1019?
+
+39:05 - Araceli Sanchez Jimenez
+Es que fíjate que aquí sí en cotización. De aquí me pasaba No me acuerdo en qué, en dónde está para facturar. No sé si es captura-venta, pero bueno, déjenlo checo, porque hace cuenta que ya con la cotización está en algún lugar todas las cotizaciones y tú nada más le pones en uno prefactura o factura y ya con eso en otro módulo en otro módulo sí pero no sé en qué en qué módulo es tendría que preguntar al al despacho tenemos la grabación si quieres Ah, súper. A ver. Bueno. Muy bien.
+
+40:12 - Noe Rocha
+¿Qué sigue, Johann, para la prueba? OK. El siguiente paso sería, con el ticket de Gira y los campus, mandar a la cotización hacia Vine.
+
+40:25 - Johann
+Será la primera prueba de escritura que haría. Lo vamos a hacer.
+
+40:32 - Noe Rocha
+Sí. Muy bien. Pues, ¿lo grabamos de una vez?
+
+40:37 - Unidentified Speaker
+Sí.
+
+40:38 - Johann
+¿Se pueden ver en pantalla? Sí. Va. Entonces, esta es la que hicimos ahorita, o la que Mercedes nos ayudó a hacer de cotización de Max Prueba. Y, por ejemplo, aquí el cliente no lo detectó. Entonces, aquí utilicé un endpoint de Bind para conseguir los clientes. Y aquí se puede conseguir. En este caso, ¿cuál selecciono?
+
+41:06 - Unidentified Speaker
+SEMEX.
+
+41:07 - Araceli Sanchez Jimenez
+¿El SEMEX?
+
+41:08 - Johann
+Sí, por favor.
+
+41:09 - Unidentified Speaker
+OK.
+
+41:10 - Johann
+Entonces, aquí como prueba estoy usando el objeto que se va a mandar para termas de depuración por si hay algún campo que falta o hay algo que deba colocarse más.
+
+41:26 - Unidentified Speaker
+OK.
+
+41:27 - Johann
+Entonces, voy a darle aquí. A ver, un momento. Esto es lo que voy a revisar. Es un error 500. Entonces, permítame revisar cuál fue el error.
+
+41:51 - Unidentified Speaker
+El error.
+
+41:53 - Johann
+Quería preguntar, con este tema de las cotizaciones y ¿Cómo es el proceso de cancelarlas? Porque, por ejemplo, si no tienen efecto fiscal como una factura, de pronto pudieran funcionar como un, no quiero decir sandbox, pero pudiéramos realizar pruebas y después cancelarlas.
+
+42:18 - Unidentified Speaker
+Sí.
+
+42:19 - Araceli Sanchez Jimenez
+Mientras tú no timbres, o sea, mientras no las compartamos en CFDI, podemos cancelar y hacer las prefacturas que queramos.
+
+42:29 - Noe Rocha
+Hasta Prefectura no hay un timbrado, pero suponiendo que nos vayamos al timbrado, ahí sí platícalo cómo se cancela.
+
+42:38 - Araceli Sanchez Jimenez
+En el timbrado, cuando ya se timbró, tienes que primero ponerte de acuerdo con el cliente, avisarle al cliente, y si está de acuerdo, primero por correo que te diga, ok, adelante, cancélala. Lo que nosotros hacemos es, le pedimos cancelación, la cancelamos en el sistema, en nuestro RP, y el despacho es una cancelación ante el SAT. Y esa cancelación tiene una vigencia para que el cliente la acepte. Entonces, nos dice el despacho, ya la cancelé en el SAT. Entonces, nosotros agarramos y le decimos al cliente, ya te aparece la cancelación, búscala. Entonces, él tiene que aceptar la cancelación y es en una liga del SAT, ¿verdad? Entonces acepta la cancelación y sólo así está cancelada ante el SAT, porque si no nosotros nada más la cancelamos en nuestro sistema, en nuestro ARP, pero no ante el SAT. Entonces ese es el proceso.
+
+43:39 - Noe Rocha
+Entonces un tema es con el cliente, otro tema es en el sistema y otro tema...
+
+43:45 - Araceli Sanchez Jimenez
+Que nos apoye en el despacho.
+
+43:47 - Noe Rocha
+Ajá. Para que quede oficialmente cancelada ante el SAT.
+
+43:51 - Araceli Sanchez Jimenez
+Ajá.
+
+43:52 - Araceli Sanchez Jimenez
+Por eso es todo un rollo, porque en algunas ocasiones... Es todo un rollo, porque también qué pasaba, que a veces las personas te cancelaban una factura sin pedir tu visto bueno. Y luego, por ejemplo, luego cancelaban facturas que tú ya habías pagado. Entonces es otro rollo. Entonces por eso pusieron todos estos requisitos, ¿no?
+
+44:17 - Noe Rocha
+Pero creo que... ¿En este desarrollo no vamos a contemplar las cancelaciones?
+
+44:23 - Araceli Sanchez Jimenez
+No, eso ya lo... Ya veríamos. Lo que sí, sí habría que contemplarlas porque, de manera extraordinaria, Cemex o los clientes nos piden cancelarla. Entonces, en el sistema para la conciliación, a lo mejor habría que ponerle, esta factura se canceló y fue sustituida por esta. No es sustituida, ¿verdad? Pero que la cancelación no la haga el sistema, a eso voy. Pero que sí lleve el récord, porque sí hay cosas o facturas que se llegan a cancelar.
+
+45:06 - Johann
+Ok, entiendo. Igual, si les parece, también en mis procesos de prueba también en comunicación con Pedro comentarles cuando vaya a hacer por ejemplo escritura a una cotización o prefactura ok sí OK. Estoy viendo que puede ser que el error que haya salido es por omitir algunos campos que el endpoint necesita y que el portal manda como en ceros. Entonces, voy a revisar si los puedo mandar ahorita como prueba y vuelvo a hacer la prueba.
+
+46:01 - Araceli Sanchez Jimenez
+OK. Si no, no te preocupes, Johann. Haz la prueba y podemos agendar otra sesión. Si quieres, si es de minutos te esperamos, como tú digas.
+
+46:14 - Johann
+Permítame hacer un momento más la prueba. Ok. Y si ya no se soluciona con esto, lo pruebo en local y le Ok. Subtítulos realizados por la comunidad de Amara.org Subtítulos por la comunidad de Amara.org Ya, ya veo.
+
+47:02 - Johann
+Me falta la lista de precios.
+
+47:05 - Unidentified Speaker
+OK.
+
+47:05 - Noe Rocha
+Lista de precios.
+
+47:07 - Araceli Sanchez Jimenez
+Nosotros realmente no tenemos una lista de precios, Johann.
+
+47:12 - Araceli Sanchez Jimenez
+Ese lo podríamos agarrar del monto, del Gira. Ya ves que te pusieron monto sin IVA. Ese sería nuestra lista de precios.
+
+47:24 - Noe Rocha
+Pero yo creo que lo menciona Johann. Porque Bain lo que... Me lo estoy imaginando. Lo que hace Bain dice cantidad. Y de acuerdo al servicio tiene un precio. Y eso lo convierte en el número final de la cotización.
+
+47:44 - Araceli Sanchez Jimenez
+Pero nosotros lo estamos poniendo directo.
+
+47:47 - Unidentified Speaker
+Ok.
+
+47:47 - Unidentified Speaker
+Si es así, ¿verdad Araceli?
+
+47:50 - Noe Rocha
+O sea, no hay una lista de precios mismo. Más bien es... Se pone en forma directa el número.
+
+47:58 - Pedro Alberto Ayala Elizondo
+Como campo abierto.
+
+47:59 - Unidentified Speaker
+Un saludo.
+
+48:37 - Johann
+Déjenme probar con un ítem existente para esta publicación de prueba, para ver si eso soluciona el error.
+
+48:53 - Araceli Sanchez Jimenez
+OK. Muchas gracias.
+
+49:59 - Johann
+Sí, creo y ya les comento cuando vuelva a hacer una prueba en cotización. Ok, perfecto.
+
+50:11 - Araceli Sanchez Jimenez
+Y mientras nosotros, nada más para resumir, nos quedamos con el pendiente de pulir muy bien el de este de Jira, todos los conceptos muy mapeados, los scrolls y todo, Pedro. Y no sé si haga falta algo adicional, Noe, aparte de esto.
+
+50:28 - Noe Rocha
+No, a partir de esto, no, porque esta es la primera prueba de escritura que íbamos a tener en Vine y habíamos acordado con Joseph muy puntuales en la prueba, de no hacer más pruebas de lo que definiéramos, para evitar pues errores, de repente, o cosas en producción que puedan afectar. Entonces, ya que una vez nos valide Johann, volvemos con él y seguimos con las siguientes actividades. Adelante, Pedro.
+
+50:59 - Araceli Sanchez Jimenez
+Yo nada más una duda con los campos de enlista que vamos a armar.
+
+51:05 - Pedro Alberto Ayala Elizondo1
+Estos campos de lista que están en vine hay una manera de dentro de vain de exportar esos esos campos o si los tengo que hacer con de manera con el api no sé si yo junto que se ha explorado más el api de vine que si hay forma de explorar eso verdad si igual te los pudiera compartir en formato json o excel como te sea más útil si esta bien al igual ahí me platico para ver de qué manera se puede obtener, o si yo lo puedo obtener yo por mi propia cuenta, ya te estaré avisando.
+
+51:43 - Noe Rocha
+Es que lo que va a querer hacer Pedro y Johann es algo parecido. Va a querer conectarse de Jirabai y jalar los datos para no tener que traer datos manuales. Entonces a lo mejor te va a preguntar un par de cosas para ir muy puntualmente por la data. Pero bueno, eso lo tenemos interno, ¿verdad? Claro.
+
+52:03 - Araceli Sanchez Jimenez
+Bueno, muchas gracias a todos. Gracias. Gracias a ustedes.
+
+52:11 - Johann
+Estamos en contacto.
+
+52:14 - Unidentified Speaker
+¡Adiós!

fuentes/2026-08-18 a 2026-08-20 - WhatsApp - Pedro formulario 17 categorias y sesion 21-ago.md

@@ -0,0 +1,47 @@
+# WhatsApp — 18 al 20 ago 2026 · Johann ↔ Pedro Ayala (+52 1 81 2352 2958)
+
+Volcado literal aportado por Johann el 20-ago-2026. Continúa el hilo de correo de campos de cotización ([REGISTRO #66](../bitacora/REGISTRO.md)) y cierra con la convocatoria de la sesión del **viernes 21-ago, 7:00 am**.
+
+---
+
+## 18-ago — comentarios al Excel: 17 categorías y campos marcados "Sí"
+
+- **11:41 Johann:** Que tal Pedro, buenos días, cómo estás?
+- **11:41 Pedro:** Que tal Johan buenos días / bien bien y tu?
+- **11:42 Johann:** Tambien bien gracias, ya no te mandé mensaje acerca de lo del formulario con los nuevos campos
+- **11:43 Pedro:** sii justo tengo comentarios al respecto
+- **11:43 Pedro:** **logré reducirlo a 17 categorías pero tengo que verlas con Noé y Ara antes**
+- **11:44 Pedro:** hablando del catálog[o]
+- **11:44 Pedro:** **del formulario son lo que marcaste en "Si" en el excel compartido**
+- **11:44 Johann:** Tenía pensado hacer una prueba con ese formulario y avisarte para ya hacer una prueba para mandar una cotización sobre bind, para que pronto también puedan hacer pruebas desde la plataforma
+- **11:45 Pedro:** Entendido Johan, / que necesitas de nuestra parte / o cuando podríamos estar teniendo la siguiente sesión de seguimiento
+- **11:47 Johann:** *(citando "logré reducirlo a 17 categorías…")* Ohh va
+- **11:47 Johann:** *(citando "son lo que marcaste en Si…")* Sii, con esos ya podemos hacer una escritura en bind
+- **11:49 Johann:** *(citando "que necesitas de nuestra parte")* **Estaría bien un ticket de prueba con este nuevo formulario, pudiendo pasando el ticket a una cotización sería un gran paso**
+- **11:51 Johann:** *(citando "cuando la siguiente sesión")* Pudiera ser después de hacer la prueba con ese ticket, si es posible en esta semana, cómo están ustedes de tiempos?
+- **11:53 Pedro:** si Johan esta semana nos viene bien. / entonces dejame definir el formulario con los campos que nos comentas que existen y regreso contigo
+- **12:02 Johann:** Va, cualquier cosa estoy al pendiente
+- **12:18 Pedro:** Gracias Johan
+
+## 19-ago — Balam modificó formularios y campos; pide sesión con Noé y Ara
+
+- **16:16 Pedro:** Que tal Johan buenas tardes / Como estas?
+- **16:17 Pedro:** oye Johan para comentarte que **ya hemos realizado algunas modificaciones en nuestros formularios y campos** por lo que te solicito un espacio de tu tiempo para juntarnos a verlo con Noé y Ara
+- **16:17 Pedro:** crees poder **este viernes a las 7**?
+- **16:33 Johann:** Que tal Pedro, buenas tardes
+- **16:34 Johann:** Sí claro, para esta junta **puedo preparar el caso de escritura**, o prefieren solo ver el formulario y lo trabajo después de la reunión
+
+## 20-ago — se confirma la sesión y llega el ticket FAC-106
+
+- **08:59 Pedro:** Que tal Johan / **si me parece bien el caso** / mando la invitación para mañana a las 7 am
+- **09:47 Johann:** Buen día Pedro
+- **09:48 Johann:** Sí claro, **podrías decirme algún ticket con el que pueda hacer ese ejercicio de escritura?**
+- **10:47 Pedro:** si Johan / dame un momento / y te paso el numero de ticket
+- **15:43 Pedro:** que tal Johan, **de momento no pude crear el ticket debido a que surgieron varios comentarios internos**, dejame tocar base con Noé para ver si tenemos la sesión el día de mañana
+- **15:44 Johann:** Hola Pedro, okay, quedo al pendiente
+- **16:23 Pedro:** **ya me confirmaron Johan, mañana a las 7 am**
+- **16:24 Pedro:** te paso el link del ticekt **https://balam-jsm-temp.atlassian.net/browse/FAC-106**
+- **16:24 Pedro:** **no te dejará entrar debido a la licencia** pero no se si necesites algun pantallazo de la estructura o si mañana los vems ya en sesión
+- **16:24 Pedro:** te genero el meeting
+- **16:28 Pedro:** te dejo el link de la sesión por aqui también *(→ correo "Seguimiento - PAF", 16:25)*
+- **16:54 Johann:** entendido, gracias Pedro

fuentes/2026-08-20 - Correo - Pedro Seguimiento PAF.md

@@ -0,0 +1,15 @@
+# Correo — 20 ago 2026, 4:25 PM · Pedro Ayala → Noé Rocha, Johann
+
+**Asunto:** Seguimiento - PAF
+
+Correo con la convocatoria de la sesión del **viernes 21-ago, 7:00 am** (acordada por WhatsApp minutos antes) y la liga del ticket del ejercicio de escritura.
+
+---
+
+> https://balam-jsm-temp.atlassian.net/browse/FAC-106
+>
+> Reunión de Microsoft Teams
+> Id. de reunión: 280 788 665 449 275
+> Código de acceso: Xt6AH9nA
+
+**Nota:** el cuerpo no indica fecha ni hora; la confirmación (viernes 21-ago, 7:00 am) consta en el hilo de WhatsApp con Pedro del mismo día, 4:23 pm.

planeacion/Borradores-seguimiento-tecnico.md

@@ -32,3 +32,19 @@ Johann Velázquez
 ## 3. Confirmación al recibir el repositorio
 
 > Listo, ya recibí la invitación y confirmé que tengo acceso de escritura al repositorio. Muchas gracias. Voy a publicar la estructura inicial del backend y les aviso cuando quede disponible.
+
+## 4. WhatsApp a Erika — status lunes 3-ago + lo que falta de Balam (preparado 1-ago)
+
+> Hola Erika, buen día. Te comparto avance del fin de semana:
+>
+> ✅ Cierre técnico de la Etapa 1 (lo que no estaba bloqueado): sincronización automática cada 15 min, datos de demostración, y suite de pruebas del API (61 pruebas en verde).
+> ✅ Adelanté el frontend de la Etapa 2 (parte de consulta): inicio de sesión por roles, cartera por moneda, listado de facturas con filtros y búsqueda, detalle con descarga del PDF del CFDI y catálogo de clientes con exportación a Excel/CSV. Todo el código ya está en el repositorio de Balam.
+> ✅ La base técnica de la integración con Jira (lectura) quedó lista y probada.
+>
+> Para seguir avanzando solo me falta de su lado:
+> 1. ☁️ El acceso a Azure que quedó con el inge Noé (grupo de recursos con Contributor) — es lo que libera el ambiente de pruebas y el despliegue.
+> 2. 📅 La fecha de la sesión del flujo de facturación — desbloquea la capa de escritura (cotización→factura) y las pantallas de emisión.
+> 3. 🧾 Tres definiciones de la integración Jira→BIND (pueden salir en una sola sesión con Pedro y Arturo): ¿qué tipo de solicitud se automatiza (Facturación o Facturación adicional)?, ¿qué estatus dispara la cotización?, y ¿de dónde tomamos monto y conceptos del ticket?
+>
+> Si te parece, el viernes les muestro todo funcionando en la demo semanal.
+

planeacion/Correo-error-resuelto-2026-08-21.md

@@ -0,0 +1,25 @@
+# Correo — 21-ago-2026 · Johann → Pedro (CC Noé, Araceli) · causa del error encontrada
+
+**Hilo:** RE: Seguimiento - PAF
+**Para:** Pedro · **CC:** Noé, Araceli
+
+---
+
+Buenas tardes, espero se encuentren bien.
+
+Les comparto el resultado después de la sesión de hoy: ya encontré la causa del error y la cotización desde el ticket FAC-106 ya se genera correctamente en BIND.
+
+El problema no era de los datos del ticket ni del formulario nuevo, que quedó muy bien. Eran dos detalles de la API de BIND que no están en su documentación y que solo se pueden descubrir probando:
+
+1. Cada partida lleva un campo "Type" que le indica a BIND si el concepto es un producto o un servicio. La documentación no dice qué valor corresponde a cada uno; con el valor de producto BIND buscaba nuestro servicio en el catálogo equivocado y devolvía el error genérico de "comunicarte con soporte técnico". Con el valor correcto para servicio, pasó.
+2. El IVA por partida se envía como tasa (0.16) y no como monto. Por eso la primera cotización que sí se creó (folio 1026) salió con un IVA incorrecto; [ya quedó cancelada / les pido de favor cancelarla], no tiene ningún efecto.
+
+Con ambos ajustes, la cotización de prueba quedó generada con el folio [____], a nombre de CEMEX, por $1,234.00 + IVA $197.44 = $1,431.44 MXN, tal como venía en el ticket. La pueden ver en Ventas → Cotizaciones.
+
+Dos notas que creo les darán tranquilidad:
+- Los intentos fallidos de la mañana no dejaron nada en BIND; lo verifiqué por lectura después de cada uno.
+- La plataforma ahora rechaza con un mensaje claro cualquier dato que venga en la escala equivocada, para que esto no pueda repetirse por error de captura.
+
+Sobre los siguientes pasos: ya pueden crear tickets con el formulario nuevo para seguir probando el paso a cotización. Si prefieren, repetimos la emisión en vivo en una sesión corta de 15 minutos cuando les acomode. El alcance sigue siendo hasta la cotización, como acordamos.
+
+Quedo atento. Saludos.

planeacion/Guion-sesion-2026-08-21.md

@@ -0,0 +1,74 @@
+# Guion — sesión del viernes 21-ago-2026, 7:00 am (Noé, Araceli, Pedro)
+
+**Objetivo:** emitir la **primera cotización real** en BIND desde `FAC-106` y validar las 17 categorías. **Alcance:** termina en la cotización (sin prefactura, sin timbrado, sin tocar Jira). Sondeo y diagnóstico de anoche: [`Sondeo-FAC-106-y-payload-2026-08-20.md`](Sondeo-FAC-106-y-payload-2026-08-20.md).
+
+---
+
+## 0 · Esta noche (5 min)
+
+- [ ] **Avisar a Pedro por WhatsApp** — cumple el compromiso del 12-ago de avisar antes de cada escritura, y corrige el shape que se compartió entonces (llevaba `VATRate: 16`; el correcto es `0.16`). Borrador:
+
+> *Pedro, ya quedó listo el caso sobre FAC-106: la plataforma ya lee el formulario nuevo (cliente, servicio, cantidad, IVA) y encontré la causa del error de la sesión pasada — la tasa de IVA iba en porcentaje y BIND la espera como fracción (0.16), ya corregido y probado en simulación. Mañana muestro la vista previa y, con su ok, emitimos la cotización real y Araceli la cancela al terminar. Nos vemos a las 7.*
+
+## 1 · Antes de las 7:00 (6:35–6:55)
+
+- [ ] `docker compose up -d` (Postgres ya suele estar arriba) · levantar API y frontend.
+- [ ] **Verificar que el modo diga `ReadOnly`** al entrar a la pantalla de emisión (quedó así anoche; el candado se abre solo en el paso 4).
+- [ ] Re-sondeo exprés de `FAC-106` (Pedro anduvo moviendo formularios): abrir la solicitud en la plataforma y confirmar que siga prellenando **CEMEX / Servicio de Enlace / 1 / 16% / 1234 / MXN**. Si algo cambió, el fallback manual sigue funcionando — se captura a mano en la misma pantalla.
+- [ ] Terminal lista con los dos comandos del candado (paso 4 y cierre).
+- [ ] Abrir el [sondeo](Sondeo-FAC-106-y-payload-2026-08-20.md) en una pestaña (plan B §4 y preguntas).
+
+## 2 · Al abrir la sesión — ANUNCIAR ANTES DE EJECUTAR (pendiente arrastrado del 12-ago)
+
+1. **Destino de la cotización:** se emite real sobre CEMEX con los datos de `FAC-106`; **al terminar, Araceli la cancela en vivo** (ella confirmó el 12-ago: sin timbrar, se cancela sin efecto). Así el ejercicio además demuestra la reversa.
+2. **La prefactura pertenece a otra sesión** (candados: cotización → prefactura → aprobación humana → timbrado).
+3. Qué se corrigió del 500: escala de la tasa, IVA de partida como monto, lista de precios omitida.
+
+## 3 · Demo en ReadOnly (el camino feliz, sin riesgo)
+
+Abrir bandeja → `FAC-106` → **Cotizar**: la partida se prellena sola desde el formulario nuevo y la **vista previa (dry-run) se genera automática** — enseñar el body exacto. Aquí se valida con Araceli que los datos son los que ella capturaría.
+
+## 4 · Emisión real (una sola vez)
+
+```bash
+dotnet user-secrets set "Bind:Mode" "Write" --project src/Balam.Api   # + reiniciar API
+```
+
+**Confirmar** → folio y total en pantalla → **"véanlo en su BIND"** (Ventas → Cotizaciones) → Araceli cancela → candado de vuelta:
+
+```bash
+dotnet user-secrets set "Bind:Mode" "ReadOnly" --project src/Balam.Api
+```
+
+**Si BIND rechaza:** el body del error se lee en pantalla (ya no es 500 ciego). Orden de ataque: (1) agregar `PriceListID` de una cotización reciente del cliente; (2) mandar el GUID del servicio en `ID`; (3) probar `Type`. Y si no sale en vivo, Araceli ya dijo la vez pasada: *"haz la prueba y podemos agendar otra sesión"* — el dry-run mostrado ya es entregable.
+
+## 5 · Preguntas que SOLO se resuelven con ellos (en orden de impacto)
+
+1. 🔴 **`Empresa origen` = Balam / RegioTurk / Helmstone — ¿cuentas de BIND distintas?** Hay un solo token; si cada empresa factura en su cuenta, cambia el alcance.
+2. 🔴 **El combo IVA no tiene `0%`** y hay clientes de exportación en el combo (ACUNTIA S.A.U., VictTec, IAMCFORWARDER). ¿Se agrega la opción?
+3. 🔴 **"Servicio de Enlace" existe 5 veces en BIND** con unidad SAT y ChargeVAT distintos — ¿quién depura BIND y cuál es el mapeo etiqueta→ítem? (segunda mitad de lo que pidió Araceli el 12-ago).
+4. **Validar las 17 categorías** (Pedro las condicionó a Noé+Ara — es esta junta).
+5. **Regla de edición:** ¿historial de cotizaciones o modificar la misma? (quedó como "regla de negocio de Balam" el 12-ago).
+6. ☁️ **Azure** — tercera semana; Noé dijo "lo resuelvo con Pedro" y Pedro ahora es el responsable. Requisitos: grupo de recursos + Contributor (app+BD+Key Vault), sin Global Admin.
+7. 👤 Con el relevo a Pedro: **¿a quién se reportan horas/avances/facturación ahora?** (todo el circuito iba por Erika).
+8. Recordatorios menores: fijar que **manda el combo Cliente (11598)** sobre el texto libre (11596); quitar el **SLA** a estos tickets (Pedro lo dijo, confirmar que se hizo); **grabaciones de BIND** que Pedro ofreció el 12-ago.
+
+## 6 · Protocolo si la emisión FALLA (decidido en frío, la noche anterior)
+
+**Primeros 30 segundos — narrar, no disculparse.** Leer el error de BIND **en voz alta** desde la pantalla: *"BIND lo rechazó con este mensaje — exactamente para esto era la prueba acompañada."* El 12-ago el 500 fue ciego; que hoy el diagnóstico se lea en vivo ES la mejora. No silencio, no disculpa larga, no cerrar la ventana.
+
+**Regla de intentos: máximo 2 reintentos, ~10 minutos.** Solo los del plan B y en orden (PriceListID → GUID en `ID` → `Type`) — nada de mutaciones improvisadas: cada reintento es un intento de escritura y el acuerdo con Noé es no probar más de lo definido. **Antes de cada reintento, verificar por lectura que el intento anterior NO haya creado la cotización** (un 500 puede escribir de todos modos) — evita duplicados y de paso demuestra el control.
+
+**Al parar (guion literal):** *"Ya tengo el diagnóstico exacto en el mensaje de BIND. Lo corrijo hoy mismo y la emisión son 15 minutos — les propongo repetir solo ese paso mañana o el lunes; les confirmo a Pedro en cuanto esté."* Compromiso corto y específico; nada de "lo reviso y les aviso" vago. Araceli ya ofreció ese formato el 12-ago (*"haz la prueba y podemos agendar otra sesión"*).
+
+**Pivotear la hora a lo que vale más que el POST:** las preguntas del §5 (17 categorías, Empresa origen/token, IVA 0%, mapeo, Azure). Si la sesión cierra esas definiciones, fue una buena sesión **aunque no haya folio**. El dry-run mostrado ya es entregable: el flujo Jira→plataforma quedó demostrado; lo que falló es la última milla contra BIND.
+
+**Higienes aunque falle:** regresar `Bind:Mode` a ReadOnly antes de cerrar (decirlo en voz alta: *"y regreso el candado a solo-lectura"*) · mencionar que cada intento quedó auditado en `WriteOperations` (es argumento de confianza, no de vergüenza) · mismo día: resultado por WhatsApp a Pedro + entrada en la bitácora.
+
+**Qué NO decir:** no culpar al formulario ni a BIND ni a Pedro; no abrir prefactura/timbrado "para compensar"; no aceptar en caliente compromisos de fecha más allá del re-intento de 15 min.
+
+## Qué NO hacer
+
+- ❌ Emitir antes de la sesión o sin anunciar el destino (candado de Noé, [REGISTRO #65](../bitacora/REGISTRO.md) §8).
+- ❌ Dejar `Bind:Mode=Write` al cerrar.
+- ❌ Abrir el tema de prefactura/timbrado aunque salga bien a la primera — gradualismo explícito de Arturo.

planeacion/Investigacion-API-Jira.md

@@ -409,3 +409,31 @@ Se ven tres bandejas de origen: **HH** (headhunting), **SA** (staff augmentation
 > **10 de 69 tickets nacen de `Automation for Jira`** desde HH/SA/IN/RH, sin request type y sin ningún campo estructurado; los datos van en el `summary` y la `description` (ADF), con el origen en `issuelinks`. Persistir el `issue.id` numérico además de la llave.
 >
 > Pendientes técnicos: parser de ADF para `Nombre del Cliente` (no trae RFC), armado de la cotización cuando se defina el tema de conceptos, y diseñar un script de escritura de una sola operación para revisión previa. El script debe ser idempotente, no incluir credenciales y ejecutarse únicamente en el sandbox propio o acompañado en el ticket de prueba acordado. **No habrá `FACTEST`.**
+
+---
+
+## Sondeo del 6-ago-2026 — customfield IDs capturados (cierre del pendiente de mapeo)
+
+Corridas: `pruebas-jira-lectura.sh` (todo 200; token renovado funciona, el 401 del 29-jul quedó atrás) + `GET /rest/api/3/field` + `search/jql` con los customfields sobre los **69 tickets** de FAC. Bodies en `/tmp/jira-probes-20260806-004526` (fuera del repo).
+
+| Campo | ID | Tipo real | Poblado (de 69) |
+|---|---|---|---|
+| Request Type | `customfield_10010` | `sd-customerrequesttype` (`{requestType:{name}}`) | 59 |
+| Nombre del Cliente | `customfield_10202` | ⚠️ **ADF** (schema dice string, el valor es doc) | 54 |
+| Cliente Nuevo | `customfield_10052` | option (`{value:"No"}`) — el duplicado `10094` está vacío, no usarlo | 48 |
+| Tipo de Moneda | `customfield_10053` | option | 48 |
+| Días de Crédito | `customfield_10054` | option (`{value:"45"}`) | 48 |
+| Periodo de Incidencias | `customfield_10203` | ⚠️ **ADF** | 46 |
+| Facturación recurrente | `customfield_10552` | option (`Si`) | 32 |
+| Periodo de recurrencia | `customfield_10553` | string (`"12"`) | 32 |
+| Empresa origen | `customfield_11423` | option (ej. `Helmstone`) | **7** — casi vacío; NO sirve como filtro hoy |
+| Monto sin IVA | `customfield_11556` | number | **2** |
+| Monto con IVA | `customfield_11522` | number | 0 |
+
+Hallazgos que corrigen al Bloque 2 del 30-jul:
+- **Sí existen campos estructurados de monto** (`Monto sin IVA` / `Monto con IVA`), pero casi nadie los llena (2/69 y 0/69). La pantalla los lee (`MontoEstimado = customfield_11556`) y muestra "—" cuando falten; si Balam empieza a llenarlos, aparecen solos.
+- "Nombre del Cliente" y "Periodo de Incidencias" llegan como **ADF**, no texto plano — el mapper aplana con `AdfText.Flatten`.
+- El filtro del prototipo "empresa origen = Balam" no es viable aún (7/69 poblados, y con valores como `Helmstone`): la bandeja muestra todo FAC con nota honesta.
+- Distribución real: 48 Facturación adicional · 6 Bajas · 4 Automatización · 1 Facturación · 10 sin RT. Estatus: 65 Facturado · 2 Cancelado · 1 En proceso · 1 En validación nacional.
+
+Los IDs quedaron en `balam-plataforma/backend/src/Balam.Api/appsettings.Development.json` (sección `Jira:Fields`, config-driven — los IDs no son secretos).

planeacion/Script-cotizacion-sesion-2026-08-12.md

@@ -0,0 +1,60 @@
+# Script de la prueba acompañada — cotización BIND desde un ticket de Jira
+
+**Sesión:** miércoles 12-ago-2026, 7:00 am · **Alcance:** el ejercicio termina en la **cotización** en BIND (sin prefactura, sin timbrado, sin tocar Jira).
+
+> Para enviar a Noé/Pedro (correo o WhatsApp) ANTES de la sesión — cumple el compromiso del 24-jul de compartir el script de escritura para revisión previa.
+
+---
+
+## Qué se va a ejecutar (una sola operación)
+
+`POST https://api.bind.com.mx/api/Quotes` — la operación `Quotes_NewQuote` del portal de desarrolladores de BIND. Crea **una** cotización. La respuesta es el ID del documento creado, que verificamos al momento con una lectura (`GET /api/Quotes/{id}`) para ver folio y total, y que ustedes pueden ver en su pantalla de Ventas → Cotizaciones.
+
+**Body de ejemplo** (los valores reales salen del ticket de ejemplo y del catálogo de BIND; este es el shape exacto):
+
+```json
+{
+  "CurrencyID": "<GUID de la moneda, del catálogo de BIND>",
+  "VATRate": 16,
+  "Comments": "Generada desde el ticket FAC-nnn (prueba acompañada).",
+  "ClientProspect": {
+    "isNew": false,
+    "Client": {
+      "ClientId": "<GUID del cliente en BIND>",
+      "ClientName": "<nombre tal como está en BIND>"
+    }
+  },
+  "Items": [
+    {
+      "Title": "<concepto según el ticket>",
+      "Unit": "Servicio",
+      "Price": 0.0,
+      "Qty": 1,
+      "VAT": 0.0,
+      "IEPS": 0,
+      "IndexNumber": 1
+    }
+  ]
+}
+```
+
+Datos que se toman del ticket de Jira: **cliente** (confirmado a mano contra el catálogo sincronizado de BIND — el ticket no trae RFC), **monto sin IVA**, **moneda** y el **resumen** como concepto. No se usa ningún dato del adjunto.
+
+## Candados (ADR-001, ya operando en el código)
+
+1. **Dry-run primero, en pantalla.** Antes de emitir se muestra el body EXACTO que saldría — lo revisamos juntos en la sesión. Cualquier edición invalida el dry-run.
+2. **La escritura está apagada por default.** El servidor corre en modo solo-lectura; el modo escritura se enciende al iniciar la sesión y **se apaga al terminar**. Fuera de ese modo, el botón de emitir no funciona (el servidor lo rechaza).
+3. **Una operación por confirmación humana explícita** (diálogo de confirmación con cliente y total). Sin lotes, sin reintentos automáticos de escritura.
+4. **Todo queda auditado**: cada dry-run y cada confirmación se persisten (usuario, fecha, payload, resultado) en la bitácora de operaciones de la plataforma.
+5. **Permisos por rol**: solo los roles de Finanzas/Administración de la plataforma pueden usar la pantalla de emisión.
+
+## Reversa
+
+La cotización **no tiene efecto fiscal**. Al cierre de la sesión, ustedes deciden: **cancelarla** en BIND (queda el rastro, sin efecto) o **conservarla** si el ticket de ejemplo es un caso real que va a facturarse. Ambas salidas son de un clic en su pantalla de cotizaciones.
+
+## Qué NO hace este ejercicio
+
+- No crea prefactura ni factura, no timbra (eso queda para la siguiente sesión, con los candados acordados: cotización → prefactura → aprobación humana → timbrado).
+- No escribe nada en Jira (ni transiciones ni comentarios).
+- No crea ni modifica clientes en BIND.
+- No corre nada automático: el disparo es manual en esta prueba; la versión automática (detección del cruce a "En proceso de facturación") depende del ambiente en Azure.

planeacion/Seguimiento-horas.csv

@@ -34,3 +34,16 @@ fecha,semana,etapa,actividad_id,actividad,horas,estado_hora,fuente_evidencia,fac
 2026-07-23,2026-W30,0,E0-07,Preparación del guion de validación del prototipo,0.45,validada,planeacion/Guion-validacion-prototipo-2026-07-23.md,si,"Guion del recorrido de la demo del 24-jul; ajustada a la baja por Johann 27-jul"
 2026-07-24,2026-W30,0,E0-07,"Sesión de validación del prototipo Etapa 0 con Noé, Arturo y Araceli — APROBADO",1.05,confirmada,bitacora/REGISTRO.md#55,si,"Duración ~1 h 4 min según transcript; Etapa 0 validada, queda 1 definición de proceso (flujo Jira)"
 2026-07-27,2026-W31,1,E1-07,"Sesión de API de Jira con Pedro (token PAF, bandeja FAC)",0.20,confirmada,bitacora/REGISTRO.md#56,si,~12 min; token PAF comprometido (1 año) por correo; integración inicia tras definición del flujo 28-jul
+2026-07-28,2026-W31,1,E1-05,Requisitos de Azure comunicados a Erika (Contributor + Key Vault) y status de avance por WhatsApp,0.25,validada,bitacora/REGISTRO.md#59,si,validada por Johann 1-ago
+2026-07-28,2026-W31,1,E1-08,"Propuesta v1.3 (ajuste Jira→BIND 7-10 h), Excel de etapas Avance-Balam-2026-07-28 y scripts del plan completo",2.50,validada,bitacora/REGISTRO.md#60,si,"commits ab7cc00..7502915; validada por Johann 1-ago"
+2026-07-29,2026-W31,1,E1-05,"Envío de la v1.3 y el Excel por WhatsApp (8:18 am) y por correo (3:56 pm), coordinación con Erika",0.75,validada,bitacora/REGISTRO.md#59-60,si,validada por Johann 1-ago
+2026-07-29,2026-W31,2,AJ-01,Primeras pruebas del token de Jira (401) y respuesta al correo de Pedro sobre la API,1.00,validada,planeacion/Investigacion-API-Jira.md,si,"Bloque 0; validada por Johann 1-ago"
+2026-07-30,2026-W31,2,AJ-01,"Desbloqueo del acceso a la API de Jira (token regenerado → 200) e investigación completa (FAC, estatus, request types, límites)",3.00,validada,planeacion/Investigacion-API-Jira.md,si,"commit 980baf0; validada por Johann 1-ago"
+2026-08-01,2026-W31,1,E1-05,Bitácora #59-#60 (aprobación de Noé) y actualización de pendientes,0.50,validada,bitacora/REGISTRO.md#59-60,si,"commit 2b862ee; validada por Johann 1-ago"
+2026-08-01,2026-W31,1,E1-01,"B5 scheduler + B6 verificación RLS (rol balam_app) + B8 suite de integración (25 pruebas) + B9 seeder demo",1.50,confirmada,bitacora/REGISTRO.md#61,si,"Sesión asistida por IA; tiempo real de sesión"
+2026-08-01,2026-W31,2,E2-01,"Frontend de lectura E2: login JWT, shell de marca, cartera por moneda, listado con filtros, detalle+PDF, clientes+CSV",1.00,confirmada,bitacora/REGISTRO.md#61,si,"Sesión asistida por IA; tiempo real de sesión"
+2026-08-01,2026-W31,2,AJ-01,Cliente de lectura de la API de Jira (Balam.Integrations.Jira) con 10 pruebas y script de sondeo,0.50,confirmada,bitacora/REGISTRO.md#61,si,"Sesión asistida por IA; incluye prueba local nocturna"
+2026-08-06,2026-W32,2,AJ-01,"Sondeo de customfields en FAC (IDs capturados y documentados), token a user-secrets y endpoints de lectura /api/jira/solicitudes (+converter de fechas de Jira)",0.50,confirmada,planeacion/Investigacion-API-Jira.md,si,"Sesión asistida por IA; tiempo real de sesión; commits 4ce5640 (privado) y e2c2d18 (cliente)"
+2026-08-06,2026-W32,2,AJ-01,"Bandeja de solicitudes y detalle de ticket fieles al prototipo leyendo FAC en vivo (estatus reales, solo lectura) + adjuntos descargables vía proxy",0.50,confirmada,bitacora/PENDIENTES.md,si,"Sesión asistida por IA; tiempo real de sesión; commits e2c2d18 y 76ad7b1 (cliente)"
+2026-08-06,2026-W32,2,E2-01,"Shell con el chrome del prototipo aplicado a toda la app (sidebar con grupos y logo oficial, breadcrumb, chips de sync y módulos próximamente)",0.25,confirmada,prototipo/Prototipo-Etapa0.html,si,"Sesión asistida por IA; tiempo real de sesión; commit e2c2d18 (cliente)"
+2026-08-06,2026-W32,2,E2-01,"Wizard de emisión asistida (5 pasos, solo UI) fiel al prototipo: cotizaciones BIND reales seleccionables, datos de factura con PPD/PUE y alerta SAT, IVA por regla con totales reactivos, prefactura simulada con marca de agua y aprobación humana visual; timbrado bloqueado hasta B7",1.00,confirmada,prototipo/Prototipo-Etapa0.html,si,"Sesión asistida por IA; tiempo real de sesión; commits 2164f6c, 90f7633 y 0600f2f (cliente)"

planeacion/Seguimiento-horas.md

@@ -15,6 +15,8 @@ Fuente local de horas efectivamente trabajadas para el proyecto Balam. Se mantie
 4. No convertir porcentajes de avance en horas: el avance mide entregable; las horas miden esfuerzo real.
 5. No completar retrospectivamente una duración sin respaldo. Si solo se conoce la actividad, dejarla en la lista de reconstrucción hasta que Johann confirme el tiempo.
 6. Al habilitarse Jira, conciliar ambos registros y evitar duplicados.
+7. El esfuerzo real de una sesión incluye TODO su alrededor, no solo el desarrollo: el análisis/pensamiento previo para decidir qué se hace, la documentación de cada parte (bitácora, pendientes, investigación), y la comunicación asociada (cada correo, cada mensaje de WhatsApp, minutas y reportes). Definido por Johann el 6-ago.
+8. Para proyectar el costo final del proyecto, las horas no comprimibles (sesiones con Balam, pruebas acompañadas, capacitación, demos, gestión y comunicación) son el piso, y el objetivo de cierre es ese piso y un poco más — no el piso pelón ni el rango completo de la propuesta. Los cortes ya reportados a Erika nunca se recalculan retroactivamente (ajustado por Johann el 6-ago).
 
 ## Corte al 27-jul
 

planeacion/Sondeo-FAC-106-y-payload-2026-08-20.md

@@ -0,0 +1,108 @@
+# Sondeo de `FAC-106` y payload de cotización — 20-ago-2026, noche
+
+Preparación para la sesión del **viernes 21-ago, 7:00 am**. Todo lo de aquí es **solo lectura**: sondeo del ticket por API de Jira, lectura de catálogos de BIND y **dry-run** del endpoint de emisión (ninguna escritura). Ver [REGISTRO #65](../bitacora/REGISTRO.md) (la sesión del 12-ago que terminó en 500) y [#67](../bitacora/REGISTRO.md).
+
+---
+
+## 1 · `FAC-106` — el formulario nuevo existe y es mucho mejor de lo esperado
+
+Creado por **Pedro** el 20-ago 4:12 pm, asignado a **Araceli**. Request type nuevo: **`Cotización Bind`** (id 1196, portal 35). Estatus `Open` (⚠️ **no** `En proceso de facturación`: mañana el disparo es manual, como estaba previsto).
+
+| Campo | ID | Tipo | Valor en FAC-106 |
+|---|---|---|---|
+| Empresa origen | `customfield_11423` | select | **Balam** |
+| Cliente | `customfield_11598` | **select** | **CEMEX** |
+| Servicio/Producto | `customfield_11599` | **select** | **Servicio de Enlace** |
+| Cantidad | `customfield_11600` | number | **1.0** |
+| Monto sin IVA | `customfield_11556` | number | **1234.0** |
+| IVA | `customfield_11601` | select | **16%** |
+| Tipo de Moneda | `customfield_10053` | select | **MXN** |
+| Fecha de vencimiento | `customfield_11597` | date | **2026-08-27** |
+
+⭐ **El hueco de conceptos/partidas quedó resuelto.** `Servicio/Producto` + `Cantidad` + `IVA` son campos estructurados: ya hay con qué armar una partida sin parsear texto ni adjuntos.
+
+⭐ **`Cliente` dejó de ser ADF y ahora es combo** con **17 opciones** que corresponden a los clientes de BIND: ACUNTIA S.A.U. · ATC CONSOLIDADOS · BANCA AFIRME · CEMEX · DEACERO · FRISA FORJADOS · (persona física) · HELMSTONE · IAMCFORWARDER · PLAN CREDI · Público en General · REGIOTURK · SERVICIOS COMPARTIDOS TSM · SERVICIOS LOGISTICOS DYLO · TRANSPORTES LOGISTICOS ESPECIALIZADOS · TRASLADOS Y LOGISTICA ESPECIALIZADA · VictTec LLC.
+
+⭐ **Las 17 categorías de servicio de Pedro, confirmadas** en `Servicio/Producto`: Consultoría y Administración Corporativa · Servicios Profesionales Generales · Gestión de Proyectos Senior / PMO · Gestión de Mesa de Servicio (SDM) · Soporte Especializado L1 · Soporte Especializado L2 · Gestión de Incidentes · Gestión de Cambios · Gestión de Capacidad · Mesa de Ayuda / Service Desk · Desarrollo de Software · Reclutamiento (Headhunting) · Servicio de Enlace · Horas Extraordinarias · Viáticos · Licencias y Software · Liquidaciones y Finiquitos.
+
+### Pendientes que deja el formulario
+
+- 🔴 **`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? El token actual es uno solo. **Preguntarlo mañana.**
+- 🔴 **`IVA` solo ofrece `16%`.** No hay `0%` — y hay clientes de exportación en el combo (ACUNTIA S.A.U., VictTec LLC, IAMCFORWARDER). El Discovery registró **IVA 16%/0%**. Además, en BIND existe al menos una cotización real con `VAT = 0` pese a `VATRate = 0.16`. **Falta la opción 0%.**
+- ⚠️ **Sobrevive `Nombre del cliente` (`customfield_11596`, texto libre)** además del combo `11598`. Dos campos de cliente en el mismo sitio: hay que fijar por escrito que **manda el combo**.
+- ⚠️ **`customfield_10202`, el campo de cliente que la plataforma leía, ya no aplica.** Era la causa de que el 12-ago *"el cliente no se detectó"*. **Corregido** en `appsettings.Development.json` → `customfield_11598`.
+
+---
+
+## 2 · El catálogo de BIND está peor de lo que se vio en la sesión
+
+`GET /api/Services` devuelve **67 servicios**; `GET /api/Products`, **3 productos**. Buscando el que trae el ticket:
+
+**"SERVICIO DE ENLACE" existe 5 veces**, con IDs distintos y **atributos fiscales que no coinciden entre sí**:
+
+| Code | Unit | SATUnit | ChargeVAT |
+|---|---|---|---|
+| `81111500` | *(vacío)* | 3984 | **true** |
+| `Código - 00000` | E48 | 4376 | false |
+| `Código - 00000` | E48 | 4376 | false |
+| `Código - 00000` | Servicio | 4376 | false |
+| `027` | E48 | 3984 | false |
+
+> 🔴 **Riesgo directo para mañana:** el combo de Jira manda **una etiqueta**, "Servicio de Enlace", y en BIND hay **cinco filas** que difieren en unidad, unidad SAT e incluso en si cobran IVA. **La correspondencia etiqueta → ítem de BIND es ambigua y nadie la ha definido.** Es la segunda mitad de la depuración que Araceli pidió el 12-ago: se depuró el combo de Jira, **falta depurar BIND y fijar el mapeo**.
+
+---
+
+## 3 · Los tres errores que explican el 500 del 12-ago
+
+Verificado leyendo **4 cotizaciones reales** de BIND (folios 1001, 1005, 1012, 1021):
+
+1. 🔴 **`VATRate` va como fracción, no como porcentaje.** Todas las cotizaciones reales traen **`VATRate = 0.16`**. Mandar `16` es un factor de 100 de diferencia.
+2. 🔴 **`VAT` de partida es un MONTO, no una tasa.** Comprobado en 3 de 4: `Price × Qty × 0.16 = VAT` (p. ej. 32,422.04 → 5,187.5264). El endpoint **pasa el valor tal cual**, así que quien llame tiene que calcularlo. Para FAC-106: 1234 × 1 × 0.16 = **197.44**.
+3. 🟠 **`PriceListID`: cada cotización real usa una lista distinta** (`041d4514…`, `0c4bb05e…`, `0dfbe083…`, `1087dac9…`) y **ninguna coincide** con la única que devuelve `GET /api/PriceLists` (`03e4bb2d…`, "A"). Mandar la lista equivocada es candidato serio al 500. **Recomendación: omitirlo** y dejar que BIND aplique su default — el cliente ya omite los nulos.
+
+Además, sin confirmar:
+
+- ⚠️ **`ID` de partida.** El read model distingue `ID` (renglón) de `ProductID` (ítem del catálogo); el write model **solo tiene `ID`**. Mandar el GUID del servicio en `ID` puede ser justo lo que BIND rechaza. El body de abajo **omite `ID`** y manda la partida como texto con `Title`/`Unit` — que además es como Araceli captura.
+- ⚠️ `Type` y `SelectedUnit` siguen sin documentar; van omitidos.
+
+---
+
+## 4 · Body listo para mañana (dry-run ejecutado, operación #18)
+
+IDs resueltos contra BIND en vivo: **MXN** `b7e2c065-bd52-40ca-b508-3accdd538860` · **Matriz** `65ee189a-a163-4f23-8466-87627a5ba776` (única ubicación) · **CEMEX** `6f17c5bd-e7a0-4152-9702-4a486c1b7c69` (RFC `CEM880726UZA`, 90 días de crédito).
+
+```json
+{
+  "LocationID": "65ee189a-a163-4f23-8466-87627a5ba776",
+  "CurrencyID": "b7e2c065-bd52-40ca-b508-3accdd538860",
+  "ExchangeRate": 1.0,
+  "Items": [
+    { "Title": "SERVICIO DE ENLACE", "Unit": "E48", "Price": 1234.0,
+      "Qty": 1.0, "VAT": 197.44, "IEPS": 0, "IndexNumber": 1 }
+  ],
+  "ClientProspect": {
+    "isNew": false,
+    "Client": { "ClientId": "6f17c5bd-…", "ClientName": "CEMEX" }
+  },
+  "VATRate": 0.16,
+  "Comments": "Generada desde el ticket FAC-106 (prueba acompañada)."
+}
+```
+
+**Si BIND vuelve a rechazar**, el orden de ataque es: (1) agregar `PriceListID` con el de una cotización reciente del mismo cliente; (2) mandar el GUID del servicio en `ID`; (3) probar `Type`. El endpoint ya expone `ex.Body` de BIND en el 502, así que el diagnóstico se lee en pantalla — no se repite el 500 ciego del 12-ago.
+
+---
+
+## 5 · ⚠️ Seguridad: `Bind:Mode` está en **Write** ahora mismo
+
+`GET /api/emision/estado` responde `{"modo":"Write"}` — el candado de ADR-001 está **abierto** fuera de la sesión acompañada, contra lo que se le prometió a Noé ([REGISTRO #31a](../bitacora/REGISTRO.md)). Una confirmación accidental escribiría en producción. **Regresarlo a `ReadOnly`** y encenderlo solo durante la sesión:
+
+```bash
+dotnet user-secrets set "Bind:Mode" "ReadOnly" --project src/Balam.Api
+```
+
+---
+
+## 6 · Lo que falta cablear (no bloquea la prueba manual)
+
+El dry-run de arriba se armó **a mano** con los datos de `FAC-106`. Para que la pantalla lo arme sola faltan cuatro campos en la configuración y en el DTO de detalle: `Servicio/Producto` (11599), `Cantidad` (11600), `IVA` (11601) y `Fecha de vencimiento` (11597). Con eso el wizard prellena la partida completa desde el ticket.

planeacion/generar_avance_2026_08_01.py

@@ -0,0 +1,214 @@
+"""Genera Avance-Balam-2026-08-01.xlsx a partir del canónico del 28-jul.
+
+Corte del sábado 1-ago (REGISTRO #61): cierre técnico de la Etapa 1 en lo no
+bloqueado (B5 scheduler, B6 RLS verificado, B8 suite de integración, B9 seeder
+demo), frontend de LECTURA de la Etapa 2 completo (adelantando las filas del
+29-jul al 5-ago y la exportación CSV) y cliente de lectura de la API de Jira.
+La propuesta v1.3 fue APROBADA por Noé el 30-jul (REGISTRO #60).
+
+Las horas se leen de `Seguimiento-horas.csv` (fuente de la verdad, corte
+52.58 h) y se reparten por fila con el mismo criterio trazable del generador
+del 27-jul; el script aborta si el reparto no cuadra con el CSV.
+"""
+import csv
+import os
+from collections import defaultdict
+
+import openpyxl
+from openpyxl.styles import Alignment, Font, PatternFill
+
+BASE = os.path.dirname(os.path.abspath(__file__))
+SRC = os.path.join(BASE, "Avance-Balam-2026-07-28.xlsx")
+DST = os.path.join(BASE, "Avance-Balam-2026-08-01.xlsx")
+CSV_HORAS = os.path.join(BASE, "Seguimiento-horas.csv")
+
+CAFE, GRIS = "331F0E", "595959"
+V_FILL, V_FONT = "C6EFCE", "006100"
+A_FILL, A_FONT = "FFEB9C", "9C6500"
+R_FILL, R_FONT = "FFC7CE", "9C0006"
+G_FILL, G_FONT = "F2F2F2", "595959"
+
+C_PCT, C_EST, C_TRAB, C_STAT = 4, 5, 6, 7
+
+# --- CSV: totales por etapa y por actividad -----------------------------------
+por_act, por_etapa = defaultdict(float), defaultdict(float)
+with open(CSV_HORAS, encoding="utf-8", newline="") as fh:
+    for r in csv.DictReader(fh):
+        if not (r.get("fecha") or "").strip():
+            continue
+        por_act[r["actividad_id"]] += float(r["horas"])
+        por_etapa[r["etapa"]] += float(r["horas"])
+
+E0, E1 = por_etapa["0"], por_etapa["1"]
+AJ = por_act["AJ-01"]                    # ajuste Jira→BIND (vive dentro de la etapa 2 del CSV)
+E2 = por_etapa["2"] - AJ                 # Etapa 2 propiamente (frontend de lectura)
+TOTAL = E0 + E1 + E2 + AJ
+assert abs(TOTAL - sum(por_etapa.values())) < 0.01
+PCT_GLOBAL = round(TOTAL / ((119 + 146) / 2), 2)
+
+# --- Reparto por fila del delta 28-jul→1-ago (11.00 h nuevas) ------------------
+# Trazabilidad (mismas reglas que el generador del 27-jul):
+#   E1-05 +1.50 (Azure/status 0.25 + envíos v1.3 0.75 + bitácora 0.50) → fila de seguimiento semanal
+#   E1-08 +2.50 (propuesta v1.3 + Excel de etapas + plan completo)     → fila "Definición de alcance Jira"
+#   E1-01 +1.50 del 1-ago repartida por naturaleza: B5+B8 → backend; B6 → multi-tenant; B9 → modelo
+#   AJ-01  4.50 (pruebas 401 + investigación + cliente de lectura)     → fila "Cliente de la API de Jira"
+#   E2-01  1.00 repartida entre las filas de frontend que cubrió la sesión
+DELTAS_TRAB = {
+    "Demostración semanal": 1.50,
+    "Definición de alcance Jira": 2.50,
+    "Backend base": 0.50,
+    "Arquitectura multi-tenant": 0.50,
+    "Modelo de facturas": 0.50,
+    "Cliente de la API de Jira": 4.50,
+    "Andamiaje del frontend": 0.30,
+    "Layout base": 0.15,
+    "Listado de facturas": 0.25,
+    "Detalle de factura": 0.15,
+    "Catálogo de clientes": 0.10,
+    "Exportación de facturas": 0.05,
+}
+assert abs(sum(DELTAS_TRAB.values()) - 11.00) < 0.01, "El reparto no suma las 11.00 h nuevas"
+
+# Encabezados de etapa: trab y % (Etapa 1: 7 de 8 entregables terminados — solo
+# queda la capa de escritura, bloqueada por Balam; % por entregable cerrado).
+ENCABEZADOS = {
+    "Integracion de plataformas Balam": (TOTAL, PCT_GLOBAL),
+    "Etapa 0": (E0, 1.0),
+    "Etapa 1": (E1, 0.875),
+    "Etapa 2": (E2, 0.50),
+    "» Ajuste dentro de la Etapa 2": (AJ, 0.45),
+    "Etapa 3": (None, 0),
+}
+
+# (pct, estatus, fill, font, bold) por prefijo de fila — refleja el 1-ago.
+FILAS = {
+    "Modelo de facturas": (1.0, "✅ Completada (modelo, migraciones y seeder de datos demo)", V_FILL, V_FONT, False),
+    "Demostración semanal": (None, "🟡 En curso (semanal) · demo del vie 7-ago con material listo", A_FILL, A_FONT, False),
+    "Definición de alcance Jira": (0.95, "🟡 v1.3 APROBADA por Noé (30-jul) · falta el estatus disparador", A_FILL, A_FONT, False),
+    "Capa de escritura controlada": (0.40, "🔴 Diseño listo · impl. en pausa (flujo en revisión interna de Balam)", R_FILL, R_FONT, True),
+    "Configuración de infraestructura en Azure": (0, "🔴 Bloqueada · acceso Contributor escalado a Noé (28-jul)", R_FILL, R_FONT, True),
+    "CI/CD": (0, "🔴 Pendiente · depende de Azure", R_FILL, R_FONT, True),
+    # Ajuste Jira
+    "Cliente de la API de Jira": (0.85, "🟡 Cliente de lectura listo y probado (1-ago) · faltan muestreos en FAC", A_FILL, A_FONT, False),
+    "Disparador por estatus": (0, "🔴 Bloqueada · decisiones de Balam (request type, estatus, monto/conceptos)", R_FILL, R_FONT, True),
+    "Trazabilidad ticket↔cotización↔factura": (0, "🔴 Bloqueada · requiere el disparador y sesión de escritura acompañada", R_FILL, R_FONT, True),
+    # Etapa 2 (lectura adelantada el 1-ago)
+    "Andamiaje del frontend": (1.0, "✅ Completada (1-ago)", V_FILL, V_FONT, False),
+    "Layout base": (1.0, "✅ Completada (1-ago)", V_FILL, V_FONT, False),
+    "Listado de facturas": (1.0, "✅ Completada (1-ago, adelantada) · filtros y paginación en servidor", V_FILL, V_FONT, False),
+    "Detalle de factura": (0.8, "🟡 PDF listo (1-ago, adelantada) · XML pendiente de confirmar con BIND", A_FILL, A_FONT, False),
+    "Catálogo de clientes": (0.7, "🟡 Catálogo y búsqueda listos (adelantada) · lista blanca editable pendiente", A_FILL, A_FONT, False),
+    "Tipo de cambio del DOF": (0, "⚪ Próxima · la captura al facturar depende del flujo definido", G_FILL, G_FONT, False),
+    "Exportación de facturas": (0.8, "🟡 CSV listo (adelantada) · XLSX pendiente", A_FILL, A_FONT, False),
+}
+
+
+def pinta(celda, fill, font_color, bold=False, size=9, align="left"):
+    celda.fill = PatternFill("solid", fgColor=fill)
+    celda.font = Font(color=font_color, bold=bold, size=size)
+    celda.alignment = Alignment(horizontal=align, vertical="center", wrap_text=True)
+
+
+wb = openpyxl.load_workbook(SRC)
+ws = wb.active
+
+ws["A2"] = ("Plan y avance al 1-ago-2026 · horas trabajadas al corte del sábado 1-ago · "
+            "frontend de consulta de la Etapa 2 adelantado; escritura y Azure en espera de Balam")
+ws["A2"].font = Font(size=10, italic=True, color=GRIS)
+
+aplicado = set()
+for row in range(5, ws.max_row + 1):
+    nombre = str(ws.cell(row=row, column=1).value or "").strip()
+    if not nombre:
+        continue
+
+    for prefijo, (trab, pct) in ENCABEZADOS.items():
+        if nombre.startswith(prefijo):
+            if trab is not None:
+                c = ws.cell(row=row, column=C_TRAB, value=round(trab, 2))
+                c.number_format = "0.00"
+            p = ws.cell(row=row, column=C_PCT, value=pct)
+            p.number_format = "0%"
+            if pct >= 1:
+                pinta(p, V_FILL, V_FONT, bold=True, size=10, align="center")
+            elif pct > 0:
+                pinta(p, A_FILL, A_FONT, bold=True, size=10, align="center")
+            break
+
+    for prefijo, delta in DELTAS_TRAB.items():
+        if nombre.startswith(prefijo):
+            actual = ws.cell(row=row, column=C_TRAB).value
+            actual = float(actual) if isinstance(actual, (int, float)) else 0.0
+            c = ws.cell(row=row, column=C_TRAB, value=round(actual + delta, 2))
+            c.number_format = "0.00"
+            aplicado.add(prefijo)
+            break
+
+    for prefijo, (pct, txt, fill, fcolor, bold) in FILAS.items():
+        if nombre.startswith(prefijo):
+            if pct is not None:
+                p = ws.cell(row=row, column=C_PCT, value=pct)
+                p.number_format = "0%"
+                if pct >= 1:
+                    pinta(p, V_FILL, V_FONT, bold=True, size=10, align="center")
+                elif pct > 0:
+                    pinta(p, A_FILL, A_FONT, bold=True, size=10, align="center")
+                else:
+                    p.font = Font(size=10, color=GRIS)
+            s = ws.cell(row=row, column=C_STAT, value=txt)
+            pinta(s, fill, fcolor, bold)
+            break
+
+faltan = set(DELTAS_TRAB) - aplicado
+assert not faltan, f"Filas no encontradas en el Excel: {faltan}"
+
+# --- Notas: se reemplaza el bloque del 28-jul ---------------------------------
+primera_nota = None
+for row in range(5, ws.max_row + 1):
+    v = str(ws.cell(row=row, column=1).value or "")
+    if v.startswith("✅ Completada ·"):
+        primera_nota = row
+    if primera_nota and row >= primera_nota:
+        ws.cell(row=row, column=1).value = None
+
+notas = [
+    ("✅ Completada · 🟡 En curso · 🔴 Pendiente/bloqueada · ⚪ Próxima · "
+     "(adelantada) = ejecutada antes de su fecha plan", True),
+    (f"Horas trabajadas al corte del sábado 1-ago: Etapa 0 {E0:.2f} h (cerrada y validada) · "
+     f"Etapa 1 {E1:.2f} h (rango 32–39) · Etapa 2 {E2:.2f} h · ajuste Jira {AJ:.2f} h "
+     f"(de 7–10 aprobadas) · total {TOTAL:.2f} h. Base de facturación a $600/h + IVA.", True),
+    ("Etapa 1: 7 de 8 entregables contractuales terminados. El 1-ago se cerraron el "
+     "seeder de datos de demostración, la verificación real del aislamiento RLS, el "
+     "sincronizador automático (cada 15 min) y la suite de pruebas de integración "
+     "(61 pruebas). Solo queda la capa de escritura, en pausa por la definición del "
+     "flujo de facturación.", False),
+    ("Etapa 2: el frontend de CONSULTA quedó adelantado al 1-ago (inicio de sesión por "
+     "roles, cartera por moneda, listado de facturas con filtros/búsqueda/paginación, "
+     "detalle con descarga del PDF del CFDI y catálogo de clientes con exportación). "
+     "Las filas de emisión (cotizaciones y conversión) siguen sujetas al flujo definido.", False),
+    ("Integración Jira → BIND (7–10 h, v1.3 aprobada por el Ing. Noé el 30-jul): el "
+     "cliente técnico de lectura quedó construido y probado; el disparador y la "
+     "trazabilidad esperan las definiciones de negocio (request type, estatus "
+     "disparador y origen de monto/conceptos) y la prueba de escritura acompañada.", False),
+    ("En espera de Balam: acceso a Azure (grupo de recursos con Contributor — con el "
+     "Ing. Noé desde el 28-jul; bloquea ambiente, staging y CI/CD), fecha de la sesión "
+     "del flujo de facturación, y las tres definiciones de la integración Jira.", False),
+]
+r = primera_nota if primera_nota else ws.max_row + 2
+for txt, bold in notas:
+    c = ws.cell(row=r, column=1, value=txt)
+    c.font = Font(italic=True, size=9, color=CAFE, bold=bold)
+    c.alignment = Alignment(wrap_text=True, vertical="top")
+    try:
+        ws.merge_cells(start_row=r, start_column=1, end_row=r, end_column=7)
+    except ValueError:
+        pass  # ya estaba fusionada desde el archivo origen
+    ws.row_dimensions[r].height = 28 if len(txt) > 120 else 14
+    r += 1
+
+ws.print_area = f"A1:G{r}"
+wb.save(DST)
+
+print("OK ->", DST)
+print(f"   E0 {E0:.2f} · E1 {E1:.2f} · E2 {E2:.2f} · Jira {AJ:.2f} · TOTAL {TOTAL:.2f} h "
+      f"· avance global {PCT_GLOBAL:.0%}")

planeacion/generar_avance_2026_08_06.py

@@ -0,0 +1,192 @@
+"""Genera Avance-Balam-2026-08-06.xlsx a partir del corte del 1-ago.
+
+Corte del jueves 6-ago (sesión nocturna, previa a la demo del vie 7-ago): la
+LECTURA de la bandeja FAC quedó completa y en la plataforma — sondeo de
+customfields (IDs capturados), endpoints /api/jira/solicitudes, bandeja de
+solicitudes y detalle fieles al prototipo con datos reales (solo lectura),
+adjuntos descargables vía proxy, y el shell con el chrome del prototipo
+aplicado a toda la app. Disparador y trazabilidad siguen bloqueados por las
+definiciones de negocio de Balam.
+
+Las horas se leen de `Seguimiento-horas.csv` (fuente de la verdad, corte
+53.83 h); el script aborta si el reparto por fila no cuadra con el CSV.
+"""
+import csv
+import os
+from collections import defaultdict
+
+import openpyxl
+from openpyxl.styles import Alignment, Font, PatternFill
+
+BASE = os.path.dirname(os.path.abspath(__file__))
+SRC = os.path.join(BASE, "Avance-Balam-2026-08-01.xlsx")
+DST = os.path.join(BASE, "Avance-Balam-2026-08-06.xlsx")
+CSV_HORAS = os.path.join(BASE, "Seguimiento-horas.csv")
+
+CAFE, GRIS = "331F0E", "595959"
+V_FILL, V_FONT = "C6EFCE", "006100"
+A_FILL, A_FONT = "FFEB9C", "9C6500"
+R_FILL, R_FONT = "FFC7CE", "9C0006"
+G_FILL, G_FONT = "F2F2F2", "595959"
+
+C_PCT, C_EST, C_TRAB, C_STAT = 4, 5, 6, 7
+
+# --- CSV: totales por etapa y por actividad -----------------------------------
+por_act, por_etapa = defaultdict(float), defaultdict(float)
+with open(CSV_HORAS, encoding="utf-8", newline="") as fh:
+    for r in csv.DictReader(fh):
+        if not (r.get("fecha") or "").strip():
+            continue
+        por_act[r["actividad_id"]] += float(r["horas"])
+        por_etapa[r["etapa"]] += float(r["horas"])
+
+E0, E1 = por_etapa["0"], por_etapa["1"]
+AJ = por_act["AJ-01"]                    # ajuste Jira→BIND (vive dentro de la etapa 2 del CSV)
+E2 = por_etapa["2"] - AJ                 # Etapa 2 propiamente (frontend)
+TOTAL = E0 + E1 + E2 + AJ
+assert abs(TOTAL - sum(por_etapa.values())) < 0.01
+PCT_GLOBAL = round(TOTAL / ((119 + 146) / 2), 2)
+
+# --- Reparto por fila del delta 1-ago→6-ago (1.25 h nuevas) --------------------
+# Trazabilidad:
+#   AJ-01 +1.00 (sondeo de customfields + endpoints + bandeja/detalle + adjuntos)
+#         → fila "Cliente de la API de Jira" (su entregable es la lectura de FAC)
+#   E2-01 +0.25 (shell con el chrome del prototipo) → fila "Layout base"
+DELTAS_TRAB = {
+    "Cliente de la API de Jira": 1.00,
+    "Layout base": 0.25,
+}
+assert abs(sum(DELTAS_TRAB.values()) - 1.25) < 0.01, "El reparto no suma las 1.25 h nuevas"
+
+ENCABEZADOS = {
+    "Integracion de plataformas Balam": (TOTAL, PCT_GLOBAL),
+    "Etapa 0": (E0, 1.0),
+    "Etapa 1": (E1, 0.875),
+    "Etapa 2": (E2, 0.50),
+    "» Ajuste dentro de la Etapa 2": (AJ, 0.55),
+    "Etapa 3": (None, 0),
+}
+
+# (pct, estatus, fill, font, bold) — solo lo que cambió respecto al 1-ago.
+FILAS = {
+    "Cliente de la API de Jira": (1.0, "✅ Completada (6-ago): bandeja de solicitudes y detalle en la plataforma "
+                                       "leyendo FAC en vivo (solo lectura) · customfields mapeados · adjuntos vía proxy",
+                                  V_FILL, V_FONT, False),
+    "Layout base": (1.0, "✅ Completada · chrome del prototipo aplicado a toda la app (6-ago)", V_FILL, V_FONT, False),
+}
+
+
+def pinta(celda, fill, font_color, bold=False, size=9, align="left"):
+    celda.fill = PatternFill("solid", fgColor=fill)
+    celda.font = Font(color=font_color, bold=bold, size=size)
+    celda.alignment = Alignment(horizontal=align, vertical="center", wrap_text=True)
+
+
+wb = openpyxl.load_workbook(SRC)
+ws = wb.active
+
+ws["A2"] = ("Plan y avance al 6-ago-2026 · horas trabajadas al corte del jueves 6-ago · "
+            "lectura de la bandeja Jira (FAC) completa y en pantalla; disparador y escritura en espera de Balam")
+ws["A2"].font = Font(size=10, italic=True, color=GRIS)
+
+# Las notas del corte anterior van fusionadas A:G y algunas empiezan con
+# "Etapa 1: …", que colisiona con los prefijos de encabezado: se localizan y
+# limpian ANTES del bucle principal, y este se detiene donde empezaban.
+primera_nota = None
+for row in range(5, ws.max_row + 1):
+    v = str(ws.cell(row=row, column=1).value or "")
+    if v.startswith("✅ Completada ·"):
+        primera_nota = row
+    if primera_nota and row >= primera_nota:
+        for rango in list(ws.merged_cells.ranges):
+            if rango.min_row == row:
+                ws.unmerge_cells(str(rango))
+        ws.cell(row=row, column=1).value = None
+tope = primera_nota if primera_nota else ws.max_row + 1
+
+aplicado = set()
+for row in range(5, tope):
+    nombre = str(ws.cell(row=row, column=1).value or "").strip()
+    if not nombre:
+        continue
+
+    for prefijo, (trab, pct) in ENCABEZADOS.items():
+        if nombre.startswith(prefijo):
+            if trab is not None:
+                c = ws.cell(row=row, column=C_TRAB, value=round(trab, 2))
+                c.number_format = "0.00"
+            p = ws.cell(row=row, column=C_PCT, value=pct)
+            p.number_format = "0%"
+            if pct >= 1:
+                pinta(p, V_FILL, V_FONT, bold=True, size=10, align="center")
+            elif pct > 0:
+                pinta(p, A_FILL, A_FONT, bold=True, size=10, align="center")
+            break
+
+    for prefijo, delta in DELTAS_TRAB.items():
+        if nombre.startswith(prefijo):
+            actual = ws.cell(row=row, column=C_TRAB).value
+            actual = float(actual) if isinstance(actual, (int, float)) else 0.0
+            c = ws.cell(row=row, column=C_TRAB, value=round(actual + delta, 2))
+            c.number_format = "0.00"
+            aplicado.add(prefijo)
+            break
+
+    for prefijo, (pct, txt, fill, fcolor, bold) in FILAS.items():
+        if nombre.startswith(prefijo):
+            if pct is not None:
+                p = ws.cell(row=row, column=C_PCT, value=pct)
+                p.number_format = "0%"
+                if pct >= 1:
+                    pinta(p, V_FILL, V_FONT, bold=True, size=10, align="center")
+                elif pct > 0:
+                    pinta(p, A_FILL, A_FONT, bold=True, size=10, align="center")
+                else:
+                    p.font = Font(size=10, color=GRIS)
+            s = ws.cell(row=row, column=C_STAT, value=txt)
+            pinta(s, fill, fcolor, bold)
+            break
+
+faltan = set(DELTAS_TRAB) - aplicado
+assert not faltan, f"Filas no encontradas en el Excel: {faltan}"
+
+# --- Notas: se escribe el bloque del 6-ago donde estaba el del 1-ago ----------
+notas = [
+    ("✅ Completada · 🟡 En curso · 🔴 Pendiente/bloqueada · ⚪ Próxima · "
+     "(adelantada) = ejecutada antes de su fecha plan", True),
+    (f"Horas trabajadas al corte del jueves 6-ago: Etapa 0 {E0:.2f} h (cerrada y validada) · "
+     f"Etapa 1 {E1:.2f} h (rango 32–39) · Etapa 2 {E2:.2f} h · ajuste Jira {AJ:.2f} h "
+     f"(de 7–10 aprobadas) · total {TOTAL:.2f} h. Base de facturación a $600/h + IVA.", True),
+    ("Etapa 1: 7 de 8 entregables contractuales terminados. Solo queda la capa de "
+     "escritura, en pausa por la definición del flujo de facturación.", False),
+    ("Integración Jira → BIND (7–10 h, v1.3 aprobada por el Ing. Noé el 30-jul): la "
+     "LECTURA quedó completa el 6-ago — la plataforma muestra la bandeja de solicitudes "
+     "y el detalle de cada ticket de FAC en vivo (solo lectura), con los campos del "
+     "formulario mapeados y los adjuntos descargables. El disparador de cotización y la "
+     "trazabilidad esperan las definiciones de negocio (request type, estatus disparador "
+     "y origen de monto/conceptos) y la prueba de escritura acompañada.", False),
+    ("Etapa 2: además del frontend de consulta (1-ago), toda la aplicación estrenó la "
+     "interfaz del prototipo aprobado (navegación por módulos, marca y estado del "
+     "sistema). Las filas de emisión siguen sujetas al flujo definido.", False),
+    ("En espera de Balam: acceso a Azure (Contributor — con el Ing. Noé desde el "
+     "28-jul), fecha de la sesión del flujo de facturación, y las tres definiciones de "
+     "la integración Jira.", False),
+]
+r = primera_nota if primera_nota else ws.max_row + 2
+for txt, bold in notas:
+    c = ws.cell(row=r, column=1, value=txt)
+    c.font = Font(italic=True, size=9, color=CAFE, bold=bold)
+    c.alignment = Alignment(wrap_text=True, vertical="top")
+    try:
+        ws.merge_cells(start_row=r, start_column=1, end_row=r, end_column=7)
+    except ValueError:
+        pass  # ya estaba fusionada desde el archivo origen
+    ws.row_dimensions[r].height = 28 if len(txt) > 120 else 14
+    r += 1
+
+ws.print_area = f"A1:G{r}"
+wb.save(DST)
+
+print("OK ->", DST)
+print(f"   E0 {E0:.2f} · E1 {E1:.2f} · E2 {E2:.2f} · Jira {AJ:.2f} · TOTAL {TOTAL:.2f} h "
+      f"· avance global {PCT_GLOBAL:.0%}")

planeacion/generar_avance_2026_08_06b.py

@@ -0,0 +1,192 @@
+"""Genera Avance-Balam-2026-08-06b.xlsx a partir del corte de la tarde del 6-ago.
+
+Segundo corte del jueves 6-ago (sesión vespertina, previa a la demo del vie
+7-ago): el wizard de emisión asistida quedó construido en la plataforma como
+interfaz navegable de simulación — 5 pasos fieles al prototipo aprobado, con
+las cotizaciones reales de BIND y el ticket FAC vivo (solo lectura), prefactura
+simulada con marca de agua y aprobación humana visual. El timbrado queda
+deshabilitado hasta que Balam autorice la escritura (B7). El corte de la
+mañana (Avance-Balam-2026-08-06.xlsx) no se toca.
+
+Las horas se leen de `Seguimiento-horas.csv` (fuente de la verdad, corte
+54.83 h); el script aborta si el reparto por fila no cuadra con el CSV.
+"""
+import csv
+import os
+from collections import defaultdict
+
+import openpyxl
+from openpyxl.styles import Alignment, Font, PatternFill
+
+BASE = os.path.dirname(os.path.abspath(__file__))
+SRC = os.path.join(BASE, "Avance-Balam-2026-08-06.xlsx")
+DST = os.path.join(BASE, "Avance-Balam-2026-08-06b.xlsx")
+CSV_HORAS = os.path.join(BASE, "Seguimiento-horas.csv")
+
+CAFE, GRIS = "331F0E", "595959"
+V_FILL, V_FONT = "C6EFCE", "006100"
+A_FILL, A_FONT = "FFEB9C", "9C6500"
+R_FILL, R_FONT = "FFC7CE", "9C0006"
+G_FILL, G_FONT = "F2F2F2", "595959"
+
+C_PCT, C_EST, C_TRAB, C_STAT = 4, 5, 6, 7
+
+# --- CSV: totales por etapa y por actividad -----------------------------------
+por_act, por_etapa = defaultdict(float), defaultdict(float)
+with open(CSV_HORAS, encoding="utf-8", newline="") as fh:
+    for r in csv.DictReader(fh):
+        if not (r.get("fecha") or "").strip():
+            continue
+        por_act[r["actividad_id"]] += float(r["horas"])
+        por_etapa[r["etapa"]] += float(r["horas"])
+
+E0, E1 = por_etapa["0"], por_etapa["1"]
+AJ = por_act["AJ-01"]                    # ajuste Jira→BIND (vive dentro de la etapa 2 del CSV)
+E2 = por_etapa["2"] - AJ                 # Etapa 2 propiamente (frontend)
+TOTAL = E0 + E1 + E2 + AJ
+assert abs(TOTAL - sum(por_etapa.values())) < 0.01
+PCT_GLOBAL = round(TOTAL / ((119 + 146) / 2), 2)
+
+# --- Reparto por fila del delta corte matutino→vespertino (1.00 h nueva) -------
+# Trazabilidad:
+#   E2-01 +1.00 (wizard de emisión asistida, 5 pasos en simulación)
+#         → fila "Conversión cotización→factura" (el wizard ES su interfaz;
+#           la conversión real sigue bloqueada por B7)
+DELTAS_TRAB = {
+    "Conversión cotización→factura": 1.00,
+}
+assert abs(sum(DELTAS_TRAB.values()) - 1.00) < 0.01, "El reparto no suma la 1.00 h nueva"
+
+ENCABEZADOS = {
+    "Integracion de plataformas Balam": (TOTAL, PCT_GLOBAL),
+    "Etapa 0": (E0, 1.0),
+    "Etapa 1": (E1, 0.875),
+    "Etapa 2": (E2, 0.55),
+    "» Ajuste dentro de la Etapa 2": (AJ, 0.55),
+    "Etapa 3": (None, 0),
+}
+
+# (pct, estatus, fill, font, bold) — solo lo que cambió respecto al corte matutino.
+FILAS = {
+    "Conversión cotización→factura": (0.4, "🟡 Interfaz completa en simulación (6-ago): wizard de 5 pasos con "
+                                           "cotizaciones y tickets reales, prefactura simulada y aprobación humana "
+                                           "visual · el timbrado real espera la autorización de escritura (B7)",
+                                      A_FILL, A_FONT, False),
+}
+
+
+def pinta(celda, fill, font_color, bold=False, size=9, align="left"):
+    celda.fill = PatternFill("solid", fgColor=fill)
+    celda.font = Font(color=font_color, bold=bold, size=size)
+    celda.alignment = Alignment(horizontal=align, vertical="center", wrap_text=True)
+
+
+wb = openpyxl.load_workbook(SRC)
+ws = wb.active
+
+ws["A2"] = ("Plan y avance al 6-ago-2026 (2.º corte del día) · lectura de la bandeja Jira (FAC) "
+            "completa y wizard de emisión asistida en simulación; timbrado y escritura en espera de Balam")
+ws["A2"].font = Font(size=10, italic=True, color=GRIS)
+
+# Las notas del corte anterior van fusionadas A:G y algunas empiezan con
+# "Etapa 1: …", que colisiona con los prefijos de encabezado: se localizan y
+# limpian ANTES del bucle principal, y este se detiene donde empezaban.
+primera_nota = None
+for row in range(5, ws.max_row + 1):
+    v = str(ws.cell(row=row, column=1).value or "")
+    if v.startswith("✅ Completada ·"):
+        primera_nota = row
+    if primera_nota and row >= primera_nota:
+        for rango in list(ws.merged_cells.ranges):
+            if rango.min_row == row:
+                ws.unmerge_cells(str(rango))
+        ws.cell(row=row, column=1).value = None
+tope = primera_nota if primera_nota else ws.max_row + 1
+
+aplicado = set()
+for row in range(5, tope):
+    nombre = str(ws.cell(row=row, column=1).value or "").strip()
+    if not nombre:
+        continue
+
+    for prefijo, (trab, pct) in ENCABEZADOS.items():
+        if nombre.startswith(prefijo):
+            if trab is not None:
+                c = ws.cell(row=row, column=C_TRAB, value=round(trab, 2))
+                c.number_format = "0.00"
+            p = ws.cell(row=row, column=C_PCT, value=pct)
+            p.number_format = "0%"
+            if pct >= 1:
+                pinta(p, V_FILL, V_FONT, bold=True, size=10, align="center")
+            elif pct > 0:
+                pinta(p, A_FILL, A_FONT, bold=True, size=10, align="center")
+            break
+
+    for prefijo, delta in DELTAS_TRAB.items():
+        if nombre.startswith(prefijo):
+            actual = ws.cell(row=row, column=C_TRAB).value
+            actual = float(actual) if isinstance(actual, (int, float)) else 0.0
+            c = ws.cell(row=row, column=C_TRAB, value=round(actual + delta, 2))
+            c.number_format = "0.00"
+            aplicado.add(prefijo)
+            break
+
+    for prefijo, (pct, txt, fill, fcolor, bold) in FILAS.items():
+        if nombre.startswith(prefijo):
+            if pct is not None:
+                p = ws.cell(row=row, column=C_PCT, value=pct)
+                p.number_format = "0%"
+                if pct >= 1:
+                    pinta(p, V_FILL, V_FONT, bold=True, size=10, align="center")
+                elif pct > 0:
+                    pinta(p, A_FILL, A_FONT, bold=True, size=10, align="center")
+                else:
+                    p.font = Font(size=10, color=GRIS)
+            s = ws.cell(row=row, column=C_STAT, value=txt)
+            pinta(s, fill, fcolor, bold)
+            break
+
+faltan = set(DELTAS_TRAB) - aplicado
+assert not faltan, f"Filas no encontradas en el Excel: {faltan}"
+
+# --- Notas: se escribe el bloque vespertino donde estaba el matutino ----------
+notas = [
+    ("✅ Completada · 🟡 En curso · 🔴 Pendiente/bloqueada · ⚪ Próxima · "
+     "(adelantada) = ejecutada antes de su fecha plan", True),
+    (f"Horas trabajadas al 2.º corte del jueves 6-ago: Etapa 0 {E0:.2f} h (cerrada y validada) · "
+     f"Etapa 1 {E1:.2f} h (rango 32–39) · Etapa 2 {E2:.2f} h · ajuste Jira {AJ:.2f} h "
+     f"(de 7–10 aprobadas) · total {TOTAL:.2f} h. Base de facturación a $600/h + IVA.", True),
+    ("Etapa 1: 7 de 8 entregables contractuales terminados. Solo queda la capa de "
+     "escritura, en pausa por la definición del flujo de facturación.", False),
+    ("Integración Jira → BIND (7–10 h, v1.3 aprobada por el Ing. Noé el 30-jul): la "
+     "LECTURA quedó completa el 6-ago — la plataforma muestra la bandeja de solicitudes "
+     "y el detalle de cada ticket de FAC en vivo (solo lectura), con los campos del "
+     "formulario mapeados y los adjuntos descargables. El disparador de cotización y la "
+     "trazabilidad esperan las definiciones de negocio (request type, estatus disparador "
+     "y origen de monto/conceptos) y la prueba de escritura acompañada.", False),
+    ("Etapa 2: al frontend de consulta y al chrome del prototipo se sumó el wizard de "
+     "emisión asistida (6-ago): 5 pasos sobre cotizaciones y tickets reales, con regla "
+     "PPD/PUE y advertencia SAT, IVA automático, prefactura simulada y aprobación humana "
+     "visual. El timbrado queda deshabilitado hasta que Balam autorice la escritura (B7).", False),
+    ("En espera de Balam: acceso a Azure (Contributor — con el Ing. Noé desde el "
+     "28-jul), fecha de la sesión del flujo de facturación, y las tres definiciones de "
+     "la integración Jira.", False),
+]
+r = primera_nota if primera_nota else ws.max_row + 2
+for txt, bold in notas:
+    c = ws.cell(row=r, column=1, value=txt)
+    c.font = Font(italic=True, size=9, color=CAFE, bold=bold)
+    c.alignment = Alignment(wrap_text=True, vertical="top")
+    try:
+        ws.merge_cells(start_row=r, start_column=1, end_row=r, end_column=7)
+    except ValueError:
+        pass  # ya estaba fusionada desde el archivo origen
+    ws.row_dimensions[r].height = 28 if len(txt) > 120 else 14
+    r += 1
+
+ws.print_area = f"A1:G{r}"
+wb.save(DST)
+
+print("OK ->", DST)
+print(f"   E0 {E0:.2f} · E1 {E1:.2f} · E2 {E2:.2f} · Jira {AJ:.2f} · TOTAL {TOTAL:.2f} h "
+      f"· avance global {PCT_GLOBAL:.0%}")

planeacion/generar_plan_completo_2026_07_28.py

@@ -0,0 +1,359 @@
+"""Genera Avance-Balam-2026-07-28.xlsx — plan y avance COMPLETO para Erika.
+
+Pedido por Erika el 27-28 jul: el conteo de horas de cada etapa (base de la
+facturación) en el mismo formato de los exceles anteriores, extendido a las
+Etapas 2 y 3 desglosadas por actividades diarias.
+
+Etapas 0-1 (hechas/en curso) se leen del Excel interno
+(`Plan-actividades-avance-2026-07-27.xlsx`), que a su vez sale de
+`Seguimiento-horas.csv` — una sola fuente de datos. Las Etapas 2-3 y el ajuste
+Jira → BIND se planifican aquí con los rangos contractuales de la propuesta
+v1.3 (§2 y §4): E2 38–46 h · E3 24–29 h · Jira 7–10 h · total 119–146 h.
+"""
+import os
+import re
+from datetime import date
+
+import openpyxl
+from openpyxl.styles import Alignment, Border, Font, PatternFill, Side
+from openpyxl.utils import get_column_letter
+
+BASE = os.path.dirname(os.path.abspath(__file__))
+SRC = os.path.join(BASE, "Plan-actividades-avance-2026-07-27.xlsx")
+DST = os.path.join(BASE, "Avance-Balam-2026-07-28.xlsx")
+
+# Marca Balam
+CAFE, AMARILLO, CREMA = "331F0E", "F7BD0C", "FDF3D8"
+V_FILL, V_FONT = "C6EFCE", "006100"   # verde
+A_FILL, A_FONT = "FFEB9C", "9C6500"   # amarillo
+R_FILL, R_FONT = "FFC7CE", "9C0006"   # rojo
+GRIS = "595959"
+BORDE = "D9D9D9"
+
+thin = Side(style="thin", color=BORDE)
+box = Border(left=thin, right=thin, top=thin, bottom=thin)
+
+# Columnas del origen (interno 27-jul)
+O_NOMBRE, O_INI, O_FIN, O_PCT, O_EST, O_TRAB, O_STAT = 1, 3, 4, 7, 9, 10, 11
+
+# Estatus del interno que quedaron amarrados a la "sesión del 28-jul" —
+# la sesión se movió a revisión interna de Balam (REGISTRO #58).
+REEMPLAZOS_STAT = {
+    "🔴 Diseño listo · impl. en pausa (def. Balam 28-jul)":
+        "🔴 Diseño listo · impl. en pausa (flujo en revisión interna de Balam)",
+    "🟡 Conectividad lista · falta regla 28-jul":
+        "🟡 Conectividad lista · falta regla (revisión interna de Balam)",
+}
+
+# Los rangos por actividad del interno sumaban 34–42 h en Etapa 1, fuera del
+# rango contractual de 32–39 (tope de facturación $23,400). Se recortan las
+# tres actividades cuyas horas reales quedaron muy por debajo del estimado,
+# para que la descomposición sume exactamente 32–39.
+REEMPLAZOS_EST = {
+    "Sincronización de clientes": "1.5–2",                        # antes 2.5–3 (real: 0.5)
+    "Sincronización de facturas y cotizaciones": "4–4.5",         # antes 4.5–5.5 (real: 0.5)
+    "Modelo de facturas + migraciones + datos de prueba": "3–3.5" # antes 3.5–4.5 (real: 0.5)
+}
+
+
+def limpia_fecha(txt):
+    """'vie 24/07/26' -> '24/07/2026'."""
+    m = re.search(r"(\d{2})/(\d{2})/(\d{2})", str(txt or ""))
+    return f"{m.group(1)}/{m.group(2)}/20{m.group(3)}" if m else ""
+
+
+# --- Lee Etapas 0-1 del interno ----------------------------------------------
+wsrc = openpyxl.load_workbook(SRC).active
+hechas = []          # filas E0/E1 (encabezados de etapa + actividades)
+trab_por_etapa = {}
+for row in range(2, wsrc.max_row + 1):
+    nombre = str(wsrc.cell(row=row, column=O_NOMBRE).value or "").strip()
+    if not nombre or nombre.startswith(("✅", "▬", "Horas:", "Etapa 1:", "🔴", "Pendientes",
+                                        "API de Jira", "Núcleo")):
+        continue
+    if nombre.startswith("Integracion"):
+        trab_por_etapa["TOTAL"] = float(wsrc.cell(row=row, column=O_TRAB).value or 0)
+        continue
+    es_etapa = nombre.startswith("Etapa")
+    if es_etapa:
+        trab_por_etapa[nombre] = float(wsrc.cell(row=row, column=O_TRAB).value or 0)
+    stat = str(wsrc.cell(row=row, column=O_STAT).value or "").strip()
+    est = str(wsrc.cell(row=row, column=O_EST).value or "")
+    hechas.append({
+        "nombre": nombre,
+        "ini": limpia_fecha(wsrc.cell(row=row, column=O_INI).value),
+        "fin": limpia_fecha(wsrc.cell(row=row, column=O_FIN).value),
+        "pct": wsrc.cell(row=row, column=O_PCT).value or 0,
+        "est": REEMPLAZOS_EST.get(nombre, est),
+        "trab": wsrc.cell(row=row, column=O_TRAB).value,
+        "stat": REEMPLAZOS_STAT.get(stat, stat),
+        "etapa": es_etapa,
+    })
+
+E0, E1 = trab_por_etapa["Etapa 0"], trab_por_etapa["Etapa 1"]
+TOTAL = trab_por_etapa["TOTAL"]
+assert abs((E0 + E1) - TOTAL) < 0.01, f"Horas no cuadran: {E0}+{E1} != {TOTAL}"
+
+
+def suma_est(filas):
+    lo = hi = 0.0
+    for f in filas:
+        est = f["est"] if isinstance(f, dict) else f
+        if not est or est == "—":
+            continue
+        p = est.replace("–", "-").split("-")
+        lo += float(p[0])
+        hi += float(p[-1])
+    return lo, hi
+
+
+# Las actividades de E0 y E1 deben sumar exactamente su rango contractual.
+_secciones = {}
+_actual = None
+for f in hechas:
+    if f["etapa"]:
+        _actual = f["nombre"]
+    else:
+        _secciones.setdefault(_actual, []).append(f)
+assert suma_est(_secciones["Etapa 0"]) == (18, 22), \
+    f"Etapa 0: actividades suman {suma_est(_secciones['Etapa 0'])} != (18, 22)"
+assert suma_est(_secciones["Etapa 1"]) == (32, 39), \
+    f"Etapa 1: actividades suman {suma_est(_secciones['Etapa 1'])} != (32, 39)"
+
+# --- Plan de Etapas 2-3 y ajuste Jira (actividades diarias) -------------------
+PROX = "⚪ Próxima"
+PROX_FLUJO = "⚪ Próxima · requiere flujo de facturación definido"
+PROX_JIRA = "⚪ Próxima · sujeta a aprobación (v1.3) y flujo definido"
+
+# (nombre, ini, fin, est_min, est_max, estatus)
+ETAPA2 = ("Etapa 2 — Facturación (consulta y emisión), catálogo y multimoneda",
+          "29/07/2026", "12/08/2026", 38, 46, [
+    ("Andamiaje del frontend (Angular): proyecto, login y guardias por rol",
+     "29/07/2026", "30/07/2026", "4–5", PROX),
+    ("Layout base con la identidad de marca; gestión de estado y caché",
+     "30/07/2026", "31/07/2026", "3–4", PROX),
+    ("Listado de facturas: filtros, búsqueda, paginación y ordenamiento",
+     "31/07/2026", "03/08/2026", "6–7", PROX),
+    ("Detalle de factura con descarga de PDF/XML desde BIND",
+     "04/08/2026", "04/08/2026", "3–4", PROX),
+    ("Catálogo de clientes con lista blanca configurable (editable por rol Administración)",
+     "05/08/2026", "05/08/2026", "3–4", PROX),
+    ("Tipo de cambio del DOF: proceso programado y captura al facturar",
+     "06/08/2026", "06/08/2026", "2", PROX),
+    ("Creación de cotizaciones desde la plataforma (con simulación dry-run)",
+     "06/08/2026", "07/08/2026", "5–6", PROX_FLUJO),
+    ("Conversión cotización→factura con confirmación humana (MXN con IVA / USD sin IVA)",
+     "10/08/2026", "11/08/2026", "5–6", PROX_FLUJO),
+    ("Exportación de facturas y clientes a CSV/XLSX",
+     "11/08/2026", "11/08/2026", "2", PROX),
+    ("Pruebas integrales del flujo de emisión + manual de usuario",
+     "12/08/2026", "12/08/2026", "5–6", PROX),
+])
+
+ETAPA3 = ("Etapa 3 — Cobranza, tablero, reportes y cierre",
+          "13/08/2026", "21/08/2026", 24, 29, [
+    ("Módulo de cobranza: antigüedad de cartera 30/60/90 y vistas por vencer/vencidas",
+     "13/08/2026", "14/08/2026", "5–6", PROX),
+    ("Alertas internas configurables + aplicación de la lista blanca",
+     "14/08/2026", "17/08/2026", "4–5", PROX),
+    ("Tablero directivo con indicadores de cuentas por cobrar",
+     "17/08/2026", "18/08/2026", "4–5", PROX),
+    ("Reporte operativo configurable (frecuencia, destinatarios, CSV/XLSX/PDF)",
+     "19/08/2026", "19/08/2026", "3–4", PROX),
+    ("Endurecimiento de seguridad, secretos, respaldos y plan de recuperación",
+     "20/08/2026", "20/08/2026", "3–4", PROX),
+    ("Documentación técnica: README, runbook y ADRs",
+     "20/08/2026", "21/08/2026", "2", PROX),
+    ("Sesión de capacitación grabada + transferencia y cierre",
+     "21/08/2026", "21/08/2026", "3", PROX),
+    ("Soporte posterior al lanzamiento (2 semanas, corrección de defectos — sin costo)",
+     "24/08/2026", "04/09/2026", "—", "⚪ Incluida en el cierre · sin costo"),
+])
+
+JIRA = ("» Ajuste dentro de la Etapa 2: Integración Jira → BIND (en aprobación, v1.3)",
+        "27/07/2026", "29/07/2026", 7, 10, [
+    ("Cliente de la API de Jira (token PAF): lectura de tickets FAC y control de límites",
+     "27/07/2026", "27/07/2026", "2–3", PROX_JIRA),
+    ("Disparador por estatus → generación automática de la cotización en BIND",
+     "28/07/2026", "28/07/2026", "3–4", PROX_JIRA),
+    ("Trazabilidad ticket↔cotización↔factura, alimentación del tablero y prueba observada",
+     "29/07/2026", "29/07/2026", "2–3", PROX_JIRA),
+])
+
+
+def suma_rangos(acts):
+    lo = hi = 0
+    for _, _, _, est, _ in acts:
+        if est == "—":          # filas sin costo (soporte incluido) no suman
+            continue
+        p = est.split("–")
+        lo += float(p[0])
+        hi += float(p[-1])
+    return lo, hi
+
+
+for titulo, _, _, lo, hi, acts in (ETAPA2, ETAPA3, JIRA):
+    slo, shi = suma_rangos(acts)
+    assert (slo, shi) == (lo, hi), f"{titulo}: actividades {slo}–{shi} != rango {lo}–{hi}"
+
+TOT_MIN = 18 + 32 + ETAPA2[3] + ETAPA3[3] + JIRA[3]    # 119
+TOT_MAX = 22 + 39 + ETAPA2[4] + ETAPA3[4] + JIRA[4]    # 146
+PCT_GLOBAL = round(TOTAL / ((TOT_MIN + TOT_MAX) / 2), 2)
+
+# --- Construcción -------------------------------------------------------------
+wb = openpyxl.Workbook()
+ws = wb.active
+ws.title = "Plan y avance"
+
+ws["A1"] = "Proyecto Balam · Plataforma de Automatización Financiera"
+ws["A1"].font = Font(bold=True, size=14, color=CAFE)
+ws["A2"] = ("Plan y avance al 28-jul-2026 · horas trabajadas al corte del lunes 27-jul · "
+            "Etapas 2-3 y ajuste Jira desglosados por actividad diaria")
+ws["A2"].font = Font(size=10, italic=True, color=GRIS)
+
+ENC = ["Actividad", "Inicio", "Fin", "Avance", "Horas\nestimadas", "Horas\ntrabajadas", "Estatus"]
+ANCHOS = [56, 12, 12, 9, 11, 11, 40]
+FILA_ENC = 4
+
+for i, (txt, ancho) in enumerate(zip(ENC, ANCHOS), start=1):
+    c = ws.cell(row=FILA_ENC, column=i, value=txt)
+    c.font = Font(bold=True, size=10, color=CAFE)
+    c.fill = PatternFill("solid", fgColor=AMARILLO)
+    c.alignment = Alignment(horizontal="center", vertical="center", wrap_text=True)
+    c.border = box
+    ws.column_dimensions[get_column_letter(i)].width = ancho
+ws.row_dimensions[FILA_ENC].height = 26
+
+
+def pinta_fila(r, nombre, ini, fin, pct, est, trab, stat, etapa=False, fill=None):
+    c = ws.cell(row=r, column=1, value=nombre)
+    c.font = Font(bold=etapa, size=10, color=CAFE)
+    c.alignment = Alignment(vertical="center", wrap_text=True, indent=0 if etapa else 1)
+
+    for col, val in ((2, ini), (3, fin)):
+        cc = ws.cell(row=r, column=col, value=val)
+        cc.font = Font(size=9, color=GRIS)
+        cc.alignment = Alignment(horizontal="center", vertical="center")
+
+    cp = ws.cell(row=r, column=4, value=pct)
+    cp.number_format = "0%"
+    cp.alignment = Alignment(horizontal="center", vertical="center")
+    if pct >= 1:
+        cp.font = Font(bold=True, size=10, color=V_FONT)
+        cp.fill = PatternFill("solid", fgColor=V_FILL)
+    elif pct > 0:
+        cp.font = Font(bold=True, size=10, color=A_FONT)
+        cp.fill = PatternFill("solid", fgColor=A_FILL)
+    else:
+        cp.font = Font(size=10, color=GRIS)
+
+    ce = ws.cell(row=r, column=5, value=est)
+    ce.font = Font(bold=etapa, size=10, color=CAFE)
+    ce.alignment = Alignment(horizontal="center", vertical="center")
+
+    ct = ws.cell(row=r, column=6, value=trab if trab not in (None, "") else "—")
+    if isinstance(trab, (int, float)):
+        ct.number_format = "0.00"
+    ct.font = Font(bold=etapa, size=10, color=CAFE)
+    ct.alignment = Alignment(horizontal="center", vertical="center")
+
+    cs = ws.cell(row=r, column=7, value=stat)
+    cs.alignment = Alignment(horizontal="left", vertical="center", wrap_text=True)
+    cs.font = Font(size=9, color=GRIS)
+    if stat.startswith("✅"):
+        cs.font = Font(size=9, color=V_FONT); cs.fill = PatternFill("solid", fgColor=V_FILL)
+    elif stat.startswith("🟡"):
+        cs.font = Font(size=9, color=A_FONT); cs.fill = PatternFill("solid", fgColor=A_FILL)
+    elif stat.startswith("🔴"):
+        cs.font = Font(size=9, bold=True, color=R_FONT); cs.fill = PatternFill("solid", fgColor=R_FILL)
+
+    for col in range(1, 8):
+        ws.cell(row=r, column=col).border = box
+        if etapa and col in (1, 2, 3):
+            ws.cell(row=r, column=col).fill = PatternFill("solid", fgColor=fill or CREMA)
+
+
+r = FILA_ENC + 1
+pinta_fila(r, "Integracion de plataformas Balam", "01/07/2026", "21/08/2026",
+           PCT_GLOBAL, f"{TOT_MIN:.0f}–{TOT_MAX:.0f}", TOTAL, "", etapa=True)
+r += 1
+
+for f in hechas:
+    pinta_fila(r, f["nombre"], f["ini"], f["fin"], f["pct"], f["est"], f["trab"],
+               f["stat"], etapa=f["etapa"])
+    r += 1
+
+titulo, ini, fin, lo, hi, acts = ETAPA2
+pinta_fila(r, titulo, ini, fin, 0, f"{lo}–{hi}", None, "", etapa=True)
+r += 1
+
+# El ajuste Jira se pinta ANIDADO justo debajo del encabezado de Etapa 2 (mismo
+# lugar en la propuesta) y ANTES de las actividades propias de la Etapa 2: sus
+# 3 días (27-29 jul) son cronológicamente anteriores al arranque de la Etapa 2
+# (29 jul), así que leer de arriba a abajo también respeta el calendario.
+# Relleno ámbar "pendiente" en vez del crema de una etapa contractual, y
+# prefijo "»" para que no se lea como una 5ª etapa.
+jtitulo, jini, jfin, jlo, jhi, jacts = JIRA
+pinta_fila(r, jtitulo, jini, jfin, 0, f"{jlo}–{jhi}", None, "", etapa=True, fill=A_FILL)
+r += 1
+for nombre, aini, afin, est, stat in jacts:
+    pinta_fila(r, nombre, aini, afin, 0, est, None, stat)
+    r += 1
+
+for nombre, aini, afin, est, stat in acts:
+    pinta_fila(r, nombre, aini, afin, 0, est, None, stat)
+    r += 1
+
+titulo, ini, fin, lo, hi, acts = ETAPA3
+pinta_fila(r, titulo, ini, fin, 0, f"{lo}–{hi}", None, "", etapa=True)
+r += 1
+for nombre, aini, afin, est, stat in acts:
+    pinta_fila(r, nombre, aini, afin, 0, est, None, stat)
+    r += 1
+
+# --- Leyenda y notas ----------------------------------------------------------
+r += 1
+leyenda = "✅ Completada · 🟡 En curso · 🔴 Pendiente/bloqueada · ⚪ Próxima"
+notas = [
+    (leyenda, False),
+    (f"Horas trabajadas al corte del lunes 27-jul: {E0:.2f} h en Etapa 0 (cerrada y "
+     f"validada, rango 18–22 h) y {E1:.2f} h en Etapa 1 ({TOTAL:.2f} h en total). "
+     "Las horas por etapa son la base de la facturación (tarifa $600/h + IVA).", True),
+    ("Etapas 2 y 3 desglosadas por actividad diaria con sus rangos estimados "
+     "(38–46 h y 24–29 h). Las fechas planificadas asumen media jornada en promedio "
+     "y están sujetas a la definición del flujo de facturación (en revisión interna "
+     "de Balam) y al acceso a Azure. El soporte post-lanzamiento (2 semanas, sin "
+     "costo) corre del 24-ago al 4-sep, después del cierre.", False),
+    ("Integración Jira → BIND (7–10 h), señalada con » dentro de la Etapa 2: "
+     "ajuste no contemplado en la propuesta original, incorporado en la propuesta "
+     "ajustada v1.3; se ejecuta tras su aprobación por escrito y una vez definido "
+     "el flujo. Se agrupa junto a la Etapa 2 porque automatiza el mismo entregable "
+     "(creación de cotizaciones); se programó a partir del lunes 27-jul —día en que "
+     "Pedro entregó el token PAF— en paralelo con el cierre de la Etapa 1 y el "
+     "arranque de la Etapa 2.", False),
+    (f"Total del plan con el ajuste: {TOT_MIN:.0f}–{TOT_MAX:.0f} h. El avance global "
+     f"({PCT_GLOBAL:.0%}) se calcula sobre el plan completo; el corte anterior (80%) "
+     "se calculaba solo sobre las Etapas 0-1.", False),
+    ("En Etapa 1 siguen abiertos: capa de escritura (en pausa por la definición del "
+     "flujo), datos de prueba, y Azure/CI-CD (accesos del lado de Balam).", False),
+]
+for txt, bold in notas:
+    c = ws.cell(row=r, column=1, value=txt)
+    c.font = Font(italic=True, size=9, color=CAFE, bold=bold)
+    c.alignment = Alignment(wrap_text=True, vertical="top")
+    ws.merge_cells(start_row=r, start_column=1, end_row=r, end_column=7)
+    ws.row_dimensions[r].height = 28 if len(txt) > 120 else 14
+    r += 1
+
+ws.freeze_panes = f"A{FILA_ENC + 1}"
+ws.sheet_view.showGridLines = False
+ws.print_area = f"A1:G{r}"
+ws.page_setup.orientation = "landscape"
+ws.page_setup.fitToWidth = 1
+ws.sheet_properties.pageSetUpPr.fitToPage = True
+
+wb.save(DST)
+print("OK ->", DST)
+print(f"   E0 {E0:.2f} h · E1 {E1:.2f} h · trabajadas {TOTAL:.2f} h · "
+      f"plan {TOT_MIN:.0f}–{TOT_MAX:.0f} h · avance global {PCT_GLOBAL:.0%} · "
+      f"filas E2 {len(ETAPA2[5])} · E3 {len(ETAPA3[5])} · Jira {len(JIRA[5])}")

planeacion/pruebas-jira-lectura.sh

@@ -0,0 +1,99 @@
+#!/usr/bin/env bash
+# Pruebas de SOLO LECTURA contra la instancia real de Jira (FAC) — Bloques 2,
+# 3 (inventario), 4 y 5 de Investigacion-API-Jira.md. Ninguna llamada muta nada.
+#
+# Requisitos: el token en propuesta/token-jira.txt (gitignoreado) o en $JIRA_TOKEN.
+# Uso:  ./pruebas-jira-lectura.sh [directorio_salida]
+# La salida VA FUERA DEL REPO por default (los tickets traen datos reales de
+# clientes): /tmp/jira-probes-<fecha>. Al repo solo se llevan los hallazgos
+# agregados, transcritos a mano a Investigacion-API-Jira.md.
+set -euo pipefail
+
+SITE="https://balam-jsm-temp.atlassian.net"
+EMAIL="pedro.ayala@balamtalentoestrategico.com"
+REPO_DIR="$(cd "$(dirname "$0")/.." && pwd)"
+TOKEN="${JIRA_TOKEN:-$(cat "$REPO_DIR/propuesta/token-jira.txt" 2>/dev/null || true)}"
+if [ -z "$TOKEN" ]; then
+  echo "ERROR: token no encontrado (propuesta/token-jira.txt o \$JIRA_TOKEN)." >&2
+  exit 1
+fi
+
+OUT="${1:-/tmp/jira-probes-$(date +%Y%m%d-%H%M%S)}"
+mkdir -p "$OUT"
+AUTH="$EMAIL:$TOKEN"
+
+req() { # req <nombre> <ruta>  — guarda body y headers, imprime status + rate limit
+  local name="$1" path="$2"
+  local hdr="$OUT/$name.headers" body="$OUT/$name.json"
+  local status
+  status=$(curl -sS -u "$AUTH" -H "Accept: application/json" \
+    -D "$hdr" -o "$body" -w "%{http_code}" "$SITE$path")
+  local rate
+  rate=$(grep -i "x-ratelimit" "$hdr" | tr -d '\r' | paste -sd' ' - || true)
+  echo "[$status] $name  ${rate:-（sin headers de rate limit）}"
+}
+
+echo "== Bloque 0 · auth =="
+req myself "/rest/api/3/myself"
+
+echo "== Bloque 4 · búsqueda vigente, fields acotados y tope de maxResults =="
+req search-recientes "/rest/api/3/search/jql?jql=$(python3 -c 'import urllib.parse;print(urllib.parse.quote("project = FAC ORDER BY updated DESC"))')&maxResults=10&fields=summary,status,updated,created,issuetype,reporter"
+req search-tope "/rest/api/3/search/jql?jql=$(python3 -c 'import urllib.parse;print(urllib.parse.quote("project = FAC"))')&maxResults=5000&fields=id"
+req search-delta "/rest/api/3/search/jql?jql=$(python3 -c 'import urllib.parse;print(urllib.parse.quote("project = FAC AND updated >= \"-20m\" ORDER BY updated ASC"))')&fields=updated"
+
+echo "== Bloque 5 · origen de los tickets (changelog de los 8 más recientes) =="
+python3 - "$OUT" <<'PY'
+import json, sys, subprocess, os
+out = sys.argv[1]
+data = json.load(open(f"{out}/search-recientes.json"))
+keys = [(i["id"], i["key"]) for i in data.get("issues", [])][:8]
+open(f"{out}/ids-muestra.txt", "w").write("\n".join(f"{i} {k}" for i, k in keys))
+print("muestra:", ", ".join(k for _, k in keys))
+PY
+while read -r id key; do
+  req "issue-$key" "/rest/api/3/issue/$id?expand=changelog&fields=summary,status,issuetype,created,reporter,attachment,description,resolution"
+done < "$OUT/ids-muestra.txt"
+
+echo "== Bloque 3 · transiciones con campos obligatorios (2 tickets de la muestra) =="
+head -2 "$OUT/ids-muestra.txt" | while read -r id key; do
+  req "transitions-$key" "/rest/api/3/issue/$id/transitions?expand=transitions.fields"
+done
+
+echo "== Bloque 2 · request types faltantes (12 Facturación, 389 Automatización) =="
+req requesttype-12 "/rest/servicedeskapi/servicedesk/35/requesttype/12/field"
+req requesttype-389 "/rest/servicedeskapi/servicedesk/35/requesttype/389/field"
+
+echo "== Resumen para transcribir a Investigacion-API-Jira.md =="
+python3 - "$OUT" <<'PY'
+import json, sys, glob, os
+out = sys.argv[1]
+
+def load(n):
+    try: return json.load(open(f"{out}/{n}.json"))
+    except Exception: return None
+
+tope = load("search-tope")
+if tope: print(f"- maxResults efectivo con 5000 pedidos: {len(tope.get('issues', []))} issues devueltos; isLast={tope.get('isLast')}")
+delta = load("search-delta")
+if delta is not None: print(f"- delta 20m: {len(delta.get('issues', []))} tickets actualizados en la ventana")
+
+moves = 0
+for f in sorted(glob.glob(f"{out}/issue-*.json")):
+    d = load(os.path.basename(f)[:-5])
+    if not d: continue
+    key = d.get("key", "?")
+    fields = d.get("fields", {})
+    hist = (d.get("changelog") or {}).get("histories", []) or (d.get("changelog") or {}).get("values", [])
+    key_changes = [i for h in hist for i in h.get("items", []) if i.get("field") in ("Key", "project")]
+    if key_changes: moves += 1
+    att = fields.get("attachment") or []
+    desc = fields.get("description")
+    desc_len = len(json.dumps(desc)) if desc else 0
+    total_hist = (d.get("changelog") or {}).get("total", len(hist))
+    print(f"- {key}: type={ (fields.get('issuetype') or {}).get('name') } · status={(fields.get('status') or {}).get('name')} · "
+          f"resolution={(fields.get('resolution') or {}).get('name') if fields.get('resolution') else None} · "
+          f"adjuntos={len(att)} · descripcion_adf={desc_len}B · changelog(total={total_hist}, en_expand={len(hist)})"
+          f"{' · ⚠️ MOVE/KEY-CHANGE detectado' if key_changes else ''}")
+print(f"- tickets con move/cambio de llave en la muestra: {moves}")
+print(f"\nBodies completos en: {out} (NO copiar al repo: contienen datos reales)")
+PY

propuesta/00 - PROPUESTA-COMERCIAL.md

@@ -5,8 +5,8 @@
 |---|---|
 | **Preparada para** | Noe Rocha (CTO) · Araceli Sánchez Jiménez (CEO/Operaciones) · Erika Chávez (PM) · Pedro Alberto Ayala Elizondo (Contacto técnico) |
 | **Preparada por** | Johann Velazquez — Consultor de Software · Monterrey, N.L. |
-| **Fecha** | Mayo 2026 (actualizada julio 2026) |
-| **Versión** | 1.2 — facturación inicial de 30 h explícita y condiciones comerciales consolidadas (ajuste post-kickoff, 1-jul-2026). Base: v1.1 con ajustes acordados el 8-jun-2026 |
+| **Fecha** | Mayo 2026 (actualizada al 28 de julio de 2026) |
+| **Versión** | 1.3 — integración Jira → BIND incorporada al alcance conforme al control de cambios (§10), ajuste del 28-jul-2026. Base: v1.2 (facturación inicial de 30 h explícita y condiciones comerciales consolidadas, 1-jul-2026) |
 | **Vigencia** | 30 días naturales a partir de la fecha de emisión |
 
 ---
@@ -15,16 +15,16 @@
 
 Balam opera hoy un proceso financiero fragmentado: facturación, cobranza, conciliación y contabilidad viven en sistemas que no se comunican, y el trabajo de unirlos recae en personas. Cada traspaso manual introduce error, retrabajo y demoras de cobranza que erosionan la relación con los clientes estratégicos.
 
-Esta propuesta plantea una **primera etapa enfocada**: una plataforma web que centraliza la facturación y las cuentas por cobrar sobre **BIND ERP**, el sistema ya confirmado como fuente de verdad. El MVP permite **emitir facturas en MXN y USD** desde la plataforma —creando la cotización y convirtiéndola en factura a través de la API de BIND, que conserva el timbrado CFDI— y entrega además visibilidad, dashboard, alertas y reglas de cobranza. Toda emisión opera con **confirmación humana y modo de simulación**, de modo que la prioridad #1 de Balam (facturación) se atiende sin asumir riesgos fiscales. La arquitectura queda preparada para incorporar conciliación bancaria, pagos en línea, contabilidad e integraciones adicionales conforme se validen.
+Esta propuesta plantea una **primera etapa enfocada**: una plataforma web que centraliza la facturación y las cuentas por cobrar sobre **BIND ERP**, el sistema ya confirmado como fuente de verdad. El MVP permite **emitir facturas en MXN y USD** desde la plataforma —creando la cotización y convirtiéndola en factura a través de la API de BIND, que conserva el timbrado CFDI— y entrega además visibilidad, dashboard, alertas y reglas de cobranza. Toda emisión opera con **confirmación humana y modo de simulación**, de modo que la prioridad #1 de Balam (facturación) se atiende sin asumir riesgos fiscales. Con el **ajuste de julio de 2026**, el alcance incorpora además la **integración con Jira**: los tickets de la bandeja de Facturación generan automáticamente su cotización en BIND, conservando los mismos candados de control. La arquitectura queda preparada para incorporar conciliación bancaria, pagos en línea, contabilidad e integraciones adicionales conforme se validen.
 
 En síntesis:
 
-- **Alcance:** MVP de facturación (consulta y **emisión asistida** MXN/USD) y cobranza sobre la API de BIND ERP.
-- **Plazo:** 6 a 7 semanas, a media dedicación.
-- **Inversión:** **$67,200 – $81,600 MXN** + IVA, bajo esquema de tiempo y materiales con tope por etapa.
+- **Alcance:** MVP de facturación (consulta y **emisión asistida** MXN/USD) y cobranza sobre la API de BIND ERP, más la **integración acotada con Jira** (generación automática de cotizaciones desde la bandeja de Facturación — ajuste jul-2026).
+- **Plazo:** 6 a 8 semanas, a media dedicación.
+- **Inversión:** **$71,400 – $87,600 MXN** + IVA, bajo esquema de tiempo y materiales con tope por etapa (incluye el ajuste Jira → BIND de 7 – 10 h).
 - **Modelo:** transparencia total de horas, entregables verificables semana a semana, y código propiedad de Balam desde el primer día.
 
-El enfoque responde directamente a la indicación del CTO de priorizar facturación e integrar únicamente BIND en esta primera fase, evitando comprometer alcance que dependa de integraciones aún no disponibles o no prioritarias.
+El enfoque responde directamente a la indicación del CTO de priorizar facturación y BIND en esta primera fase, evitando comprometer alcance que dependa de integraciones aún no disponibles o no prioritarias. La integración con Jira —originalmente diferida— se incorporó en julio de 2026 como ajuste de alcance, una vez que la propia dirección confirmó que el proceso de facturación se gobierna en Jira y que su API cubre lo necesario.
 
 ---
 
@@ -36,11 +36,12 @@ Durante la sesión con el equipo directivo, la lectura del requerimiento fue cla
 
 ### 1.2 Contexto que define el alcance
 
-Tras la sesión de seguimiento y las actualizaciones del CTO del 25 de mayo, tres factores reordenan el alcance del MVP:
+Tras la sesión de seguimiento y las actualizaciones del CTO del 25 de mayo, cuatro factores reordenan el alcance del MVP:
 
 1. **BIND ERP cuenta con API oficial** (`api.bind.com.mx`, OData v3, 20,000 solicitudes/día). Esto permite una integración por API en tiempo cercano a real, superando el supuesto inicial de exportación manual de archivos.
 2. **La dirección técnica priorizó la facturación.** Conforme a la indicación de considerar "únicamente BIND ERP en una primera etapa", funcionalidades como pagos en línea, conciliación bancaria, recordatorios automáticos a clientes y asientos contables se difieren de manera explícita a fases posteriores.
 3. **BUK dispone de API**, confirmada por el equipo de Balam, aunque no constituye una prioridad inmediata. Queda contemplada en el roadmap sin condicionar el MVP.
+4. **El proceso interno evolucionó hacia Jira** (confirmado por la dirección en julio de 2026): hoy todo el flujo de facturación nace y se gobierna en Jira — *"lo que no está en Jira no se procesa"* — con una bandeja dedicada (**Facturación**, llave `FAC-`) y un flujo de estatus formal. Por ello, la integración con Jira se incorporó al alcance como **ajuste conforme al control de cambios** (§10), detallado en la §2.
 
 ### 1.3 Sistemas actuales
 
@@ -48,7 +49,7 @@ Tras la sesión de seguimiento y las actualizaciones del CTO del 25 de mayo, tre
 |---|---|---|
 | **BIND ERP** | Facturación y contabilidad con PAC integrado | Integración principal (API confirmada) |
 | **BUK** | Recursos humanos, contratos, nómina | Fuera de alcance (API disponible, fase posterior) |
-| **Jira** | Gestión de proyectos y servicios | Fuera de alcance |
+| **Jira** | Gestión de proyectos y servicios; origen operativo del proceso de facturación | **Integración acotada (ajuste jul-2026):** lectura de la bandeja Facturación y generación automática de cotizaciones en BIND |
 | **Banca (3 instituciones)** | 2 México + IBC Bank Texas, estados en PDF | Fuera de alcance |
 
 ### 1.4 Solución propuesta
@@ -58,6 +59,7 @@ Se propone una **capa de operaciones financieras sobre BIND ERP**, no un reempla
 **Alcance funcional del MVP:**
 
 - Integración con BIND ERP vía API: lectura primero y **escritura asistida** una vez validada en Discovery.
+- **Integración con Jira (ajuste jul-2026):** lectura de los tickets de la bandeja **Facturación (`FAC-`)** y generación automática de la cotización en BIND al alcanzar el estatus disparador que Balam defina, mediante la misma capa de escritura controlada y con trazabilidad ticket ↔ cotización ↔ factura.
 - **Emisión de facturas desde la plataforma:** creación de cotización y conversión a factura en MXN (con IVA) y USD (sin IVA, para clientes extranjeros) a través de la API de BIND, con timbrado a cargo del PAC de BIND, confirmación humana obligatoria y modo de simulación (*dry-run*) previo a cada emisión.
 - Catálogo central de clientes con lista blanca configurable (ACUNTIA + Top 3).
 - Vista unificada de facturación: estados, vencimientos, filtros y descarga de PDF/XML.
@@ -87,6 +89,7 @@ La incorporación posterior de pagos en línea, recordatorios automáticos, conc
 - Reducción medible del trabajo manual de consulta y reporteo sobre BIND.
 - Aplicación correcta de la lista blanca: ACUNTIA y Top 3 nunca reciben recordatorios automáticos masivos.
 - Entrega del MVP funcional en el plazo comprometido, con alcance acotado y sin desviaciones.
+- Trazabilidad ticket de Jira → cotización → factura sin captura manual duplicada, una vez definido el flujo de facturación.
 - Control fiscal: ninguna factura se emite sin confirmación humana explícita; el timbrado CFDI permanece a cargo del PAC de BIND.
 
 ### 1.6 Escala operativa de referencia
@@ -122,7 +125,7 @@ La selección tecnológica privilegia robustez empresarial, mantenibilidad a lar
 
 > **Sobre las versiones.** Las versiones indicadas son la referencia vigente a mayo de 2026; se fijan al inicio del proyecto sobre la rama estable/LTS de cada tecnología. Se prioriza **.NET 10** por ser versión de soporte extendido (LTS), apropiada para una aplicación financiera de largo plazo.
 
-El proyecto se organiza en cuatro etapas secuenciales. Cada una concluye con un entregable demostrable y se factura conforme a horas reales (ver §3).
+El proyecto se organiza en cuatro etapas secuenciales, más el **ajuste Jira → BIND** incorporado en julio de 2026 dentro de la Etapa 2 (ver más abajo). Cada bloque concluye con un entregable demostrable y se factura conforme a horas reales (ver §3).
 
 ### Etapa 0 — Discovery, infraestructura y prototipo visual · *Semana 1 · 18 – 22 h*
 
@@ -176,6 +179,27 @@ El proyecto se organiza en cuatro etapas secuenciales. Cada una concluye con un
 
 > **Fuera de esta etapa:** generación automática de facturas desde eventos de negocio (Jira → BUK → factura), soporte EUR e integración con BUK. El timbrado CFDI permanece a cargo del PAC de BIND.
 
+#### » Ajuste dentro de la Etapa 2 — Integración Jira → BIND (jul-2026) · *inicia el lunes 27 de julio (token PAF ya entregado) · 7 – 10 h*
+
+**Antecedente.** La versión anterior de esta propuesta dejó Jira fuera del alcance conforme a la información disponible al cotizar. En las sesiones del 22, 24 y 27 de julio la dirección confirmó que el proceso interno evolucionó — todo el flujo de facturación nace y se gobierna en Jira — y quedó confirmada la viabilidad técnica: la API de Jira cubre lectura y escritura de tickets, se entregó el token de integración (**"PAF"**, vigente al 27-jul-2027) y se documentaron los límites de consumo de Atlassian. La estimación (~10 h) se comunicó a la PM el 21 de julio; esta sección la formaliza conforme al control de cambios (§10). Se agrupa aquí, dentro de la Etapa 2, porque automatiza exactamente el mismo entregable de esa etapa — **creación de cotizaciones** — solo que a partir de un ticket de Jira en vez de captura manual.
+
+**Entregables:**
+
+- **Conexión con la API de Jira** mediante el token PAF y lectura de los tickets de la bandeja **Facturación (`FAC-`)**, con consumo autorregulado conforme a los límites de velocidad documentados por Atlassian.
+- **Generación automática de la cotización en BIND** cuando un ticket alcanza el estatus disparador que Balam defina (candidato natural: la entrada del ticket al proceso de facturación, previo a "resuelto"), a través de la misma capa de escritura controlada del MVP.
+- **Trazabilidad ticket ↔ cotización ↔ prefactura/factura**, visible en la plataforma y registrada en la bitácora de auditoría; los tickets leídos alimentan además la vista *"qué necesita atención"* del tablero.
+- **Pruebas controladas:** scripts de consulta y de creación/edición sobre un registro de prueba, y una **prueba observada** con el equipo de Balam antes de habilitar la generación automática en operación.
+
+```
+Ticket Jira (FAC) → Cotización BIND (automática) → Prefactura → Aprobación humana → Timbrado (PAC de BIND)
+```
+
+> **El control fiscal no cambia.** La integración crea **cotizaciones, nunca facturas**: se mantiene la cadena acordada — cotización → prefactura → **aprobación humana** → timbrado por el PAC de BIND — con modo de simulación (*dry-run*), feature flag y registro en bitácora. No existe timbrado automático.
+
+**No incluye:** (a) el **alta automática de clientes en BIND** — si el cliente del ticket no existe, la plataforma lo detecta y lo notifica; darlo de alta automáticamente es una decisión de proceso abierta que, de aprobarse, se estima por separado; (b) **tickets con múltiples facturas** — el supuesto es *un ticket → una cotización*; el manejo del caso masivo se define junto con Balam y, si requiere desarrollo adicional, se estima por separado; (c) **otros usos de Jira** (reporteo de horas de consultores, tableros sobre otras bandejas, espacio comercial) y los módulos del Anexo B.
+
+> **Dependencia clave.** La implementación inicia una vez que Balam cierre la **definición del flujo de facturación** (en revisión interna), de la cual salen el estatus disparador y las reglas de prefactura.
+
 ### Etapa 3 — Cobranza, tablero, reportes y cierre · *Semanas 6-7 · 24 – 29 h*
 
 **Objetivo.** Cerrar el flujo operativo con visibilidad para Dirección y realizar la entrega formal.
@@ -212,7 +236,7 @@ A cambio de esta flexibilidad, el esquema ofrece controles concretos:
 
 ### 3.2 Dedicación y plazo
 
-La dedicación es de **media jornada (aproximadamente 20 h/semana**, con flexibilidad hasta 25 h en semanas de mayor carga). Sobre esa base, la primera etapa requiere **112 a 136 horas**, equivalentes a **6 – 7 semanas** de calendario.
+La dedicación es de **media jornada (aproximadamente 20 h/semana**, con flexibilidad hasta 25 h en semanas de mayor carga). Sobre esa base, la primera etapa requiere **119 a 146 horas** (incluido el ajuste Jira → BIND), equivalentes a **6 – 8 semanas** de calendario.
 
 ### 3.3 Condiciones comerciales
 
@@ -254,10 +278,13 @@ La inversión de la primera etapa se desglosa por entregable, conforme al esquem
 | 0 | Discovery, infraestructura Azure y **prototipo visual navegable** | 18 – 22 | $10,800 – $13,200 |
 | 1 | Plataforma base, sincronización con BIND y capa de escritura | 32 – 39 | $19,200 – $23,400 |
 | 2 | Facturación (consulta y **emisión** MXN/USD), catálogo y multimoneda | 38 – 46 | $22,800 – $27,600 |
+| » Ajuste (dentro de la Etapa 2) | **Integración Jira → BIND** (lectura de la bandeja FAC, cotización automática, trazabilidad y pruebas) — jul-2026 | 7 – 10 | $4,200 – $6,000 |
 | 3 | Cobranza, tablero, reportes y cierre | 24 – 29 | $14,400 – $17,400 |
-| **Total primera etapa** | | **112 – 136 h** | **$67,200 – $81,600** |
+| **Total primera etapa** | | **119 – 146 h** | **$71,400 – $87,600** |
 
-> Cifras antes de IVA. Plazo estimado: **6 – 7 semanas** a media jornada (~20 h/semana, con flexibilidad hasta 25 h en semanas pico).
+> Cifras antes de IVA. Plazo estimado: **6 – 8 semanas** a media jornada (~20 h/semana, con flexibilidad hasta 25 h en semanas pico).
+
+> **Sobre el ajuste Jira → BIND:** se incorporó conforme al control de cambios (§10) a partir de la confirmación de julio de 2026 (ver §2); el rango es consistente con la estimación de ~10 h comunicada el 21 de julio y su ejecución inicia una vez que Balam cierre la definición del flujo de facturación.
 
 > **Facturación inicial (vinculante para el primer pago):** el primer pago corresponde a **30 horas — $18,000 MXN + IVA**, que cubren la **Etapa 0 completa (18–22 h) y el inicio de la Etapa 1**; se factura al arranque del proyecto y su pago corre a 30 días naturales (ver §3.3). Los avances posteriores se facturan semanalmente (viernes) por horas efectivamente trabajadas.
 
@@ -302,7 +329,7 @@ Los siguientes son servicios de infraestructura externos, independientes de los
 | Azure Key Vault + Application Insights | Secretos (Standard) + observabilidad (5 GB/mes incluidos, luego por GB) | $0 – $15 |
 | Monitoreo de disponibilidad / Sentry *(opcional)* | Plan gratuito → Team | $0 – $26 |
 | PAC para CFDI | Ya incluido en BIND | Sin costo adicional |
-| **Total mensual estimado** | | **$30 – $160 USD/mes** |
+| **Total mensual estimado** | | **$30 – $162 USD/mes** |
 
 > **Configuración esperada en producción** (App Service B2 + PostgreSQL B2s con respaldo + observabilidad básica): **≈ $90 – $110 USD/mes**. El extremo bajo de la tabla corresponde a una configuración mínima; el alto, a una holgada con redundancia y monitoreo de pago.
 
@@ -327,6 +354,8 @@ El cumplimiento de las estimaciones depende de las siguientes condiciones. De no
 7. **Acuerdo de uso de la metodología asistida por IA**, con el compromiso de no entrenamiento sobre datos del cliente.
 8. **El PAC integrado de BIND** atiende los volúmenes actuales y futuros sin costo adicional; el timbrado CFDI permanece a cargo de BIND, no de la plataforma.
 9. **El comportamiento de escritura de la API de BIND** (creación de cotización, conversión a factura y timbrado) se valida en Discovery; la emisión productiva se habilita únicamente tras esa validación. Balam designa al rol responsable de confirmar cada emisión.
+10. **Token de Jira ("PAF") vigente** con visibilidad de la bandeja Facturación (`FAC-`), que opera como bandeja "padre" del proceso; si algún disparador nace en otra bandeja sin reflejarse en FAC, el ajuste se revisa en conjunto. Entregado el 27-jul-2026.
+11. **Definición del flujo de facturación** cerrada por Balam (estatus disparador y reglas de prefactura) y **diagrama del flujo Jira en tamaño legible** entregado, antes de iniciar la implementación del ajuste Jira → BIND.
 
 ---
 
@@ -371,7 +400,8 @@ Más allá del código funcional, la entrega incluye:
 1. Sesión de revisión de esta propuesta (1 h) para resolver dudas y ajustar lo que corresponda.
 2. **Firma del contrato / orden de trabajo** (prestación de servicios y confidencialidad) — formaliza el compromiso para arrancar sin anticipo.
 3. **Facturación inicial** (30 horas — **$18,000 MXN** + IVA), que cubre la Etapa 0 y el inicio de la Etapa 1 (ver §3.3), con pago a 30 días naturales, para iniciar Discovery.
-4. Arranque del proyecto, con entrega del MVP en **6 – 7 semanas**.
+4. Arranque del proyecto, con entrega del MVP en **6 – 8 semanas**.
+5. **Aprobación por escrito de la versión 1.3** (basta la confirmación por correo electrónico) para ejecutar el ajuste Jira → BIND de 7 – 10 h una vez definido el flujo de facturación.
 
 ---
 
@@ -393,7 +423,7 @@ Leyenda: ✅ Cubierto · ⚠️ Parcial · ❌ Diferido a fase posterior (Anexo
 
 | Funcionalidad PRD | Cobertura | Detalle |
 |---|---|---|
-| Generación automatizada de facturas | ⚠️ | **Incluida la creación asistida:** cotización → factura desde la plataforma vía API de BIND, con confirmación humana; el timbrado lo realiza el PAC de BIND. La generación **automática desde eventos** (Jira→BUK→Factura) depende de APIs no disponibles hoy — fase posterior. |
+| Generación automatizada de facturas | ⚠️ | **Incluida la creación asistida:** cotización → factura desde la plataforma vía API de BIND, con confirmación humana; el timbrado lo realiza el PAC de BIND. Con el **ajuste jul-2026**, los tickets de Jira (bandeja Facturación) **generan automáticamente su cotización**; la cadena completa sin intervención (Jira→BUK→Factura) sigue en fase posterior. |
 | Multimoneda para clientes internacionales (USD sin IVA) | ✅ | **Emisión en MXN (con IVA) y USD (sin IVA)** con tipo de cambio del DOF capturado al momento de facturación. **EUR queda fuera del MVP.** |
 | Descarga automática de facturas / reporte | ✅ | Listado con filtros, búsqueda, detalle con PDF/XML y exportación a Excel. |
 
@@ -433,7 +463,7 @@ Leyenda: ✅ Cubierto · ⚠️ Parcial · ❌ Diferido a fase posterior (Anexo
 
 | ID | Descripción | Cobertura | Notas |
 |---|---|---|---|
-| RF-01 | Generar facturas automáticamente desde eventos | ⚠️ | Creación manual (cotización→factura) incluida; la generación automática desde eventos requiere Jira/BUK — fase posterior |
+| RF-01 | Generar facturas automáticamente desde eventos | ⚠️ | Creación asistida (cotización→factura) incluida; con el ajuste jul-2026, los tickets de Jira generan automáticamente la **cotización**. La factura siempre requiere aprobación humana; la cadena BUK→Factura sigue en fase posterior |
 | RF-02 | Multimoneda USD/EUR/MXN | ⚠️ | Emisión MXN + USD en el MVP; EUR en fase posterior |
 | RF-03 | Integración con sistemas existentes (BUK / nómina) | ❌ | API de BUK confirmada, no prioritaria |
 | RF-04 | Registrar pagos desde fuentes bancarias | ❌ | Fase posterior |
@@ -461,7 +491,7 @@ Leyenda: ✅ Cubierto · ⚠️ Parcial · ❌ Diferido a fase posterior (Anexo
 
 ### A.4 Diferidos — resumen
 
-**Bloqueado por terceros o sin prioridad actual:** generación automática de facturas (Jira→BUK→Factura); integración bancaria en vivo (Belvo/Plaid/IBC Texas); integración con BUK; integración con Jira.
+**Bloqueado por terceros o sin prioridad actual:** generación automática de facturas de punta a punta (Jira→BUK→Factura); integración bancaria en vivo (Belvo/Plaid/IBC Texas); integración con BUK. *(La integración con Jira dejó de estar diferida: se incorporó como ajuste jul-2026 — ver §2.)*
 
 **Diferido por decisión de alcance:** pagos en línea; recordatorios automáticos a clientes; conciliación bancaria; asientos contables automáticos; EUR; flujo de efectivo proyectado; detección avanzada de anomalías; portal de cliente; multi-tenant comercial; cumplimiento avanzado Texas.
 
@@ -486,7 +516,7 @@ Los siguientes son **rangos indicativos**, no compromisos contractuales. Se reco
 
 ### B.2 Roadmap posterior (sin cotización)
 
-Se cotiza al cierre de la fase anterior, priorizando con datos reales de uso: integración bancaria en vivo (Belvo, Plaid); conector con BIND para asientos contables automáticos; integración con Jira; flujo de efectivo proyectado (30/60/90 días); gestión cambiaria automática; pagos recurrentes; detección avanzada de anomalías; soporte EUR; clasificación asistida por IA; portal de cliente; multi-tenant comercial; aplicación móvil para tickets; y cumplimiento avanzado para Texas.
+Se cotiza al cierre de la fase anterior, priorizando con datos reales de uso: integración bancaria en vivo (Belvo, Plaid); conector con BIND para asientos contables automáticos; ampliaciones de la integración con Jira (otras bandejas, reporteo de horas, espacio comercial); flujo de efectivo proyectado (30/60/90 días); gestión cambiaria automática; pagos recurrentes; detección avanzada de anomalías; soporte EUR; clasificación asistida por IA; portal de cliente; multi-tenant comercial; aplicación móvil para tickets; y cumplimiento avanzado para Texas.
 
 ### B.3 Activación
 

propuesta/Propuesta-Balam.html

@@ -4,6 +4,16 @@
 <meta charset="UTF-8">
 <title>Propuesta Comercial — Plataforma de Automatización Financiera · Balam</title>
 <style>
+  @font-face{ font-family:"Caladea"; font-style:normal; font-weight:400; src:url("fonts/Caladea-Regular.ttf")    format("truetype"); }
+  @font-face{ font-family:"Caladea"; font-style:normal; font-weight:700; src:url("fonts/Caladea-Bold.ttf")       format("truetype"); }
+  @font-face{ font-family:"Caladea"; font-style:italic; font-weight:400; src:url("fonts/Caladea-Italic.ttf")     format("truetype"); }
+  @font-face{ font-family:"Caladea"; font-style:italic; font-weight:700; src:url("fonts/Caladea-BoldItalic.ttf") format("truetype"); }
+  @font-face{ font-family:"Carlito"; font-style:normal; font-weight:400; src:url("fonts/Carlito-Regular.ttf")    format("truetype"); }
+  @font-face{ font-family:"Carlito"; font-style:normal; font-weight:700; src:url("fonts/Carlito-Bold.ttf")       format("truetype"); }
+  @font-face{ font-family:"Carlito"; font-style:italic; font-weight:400; src:url("fonts/Carlito-Italic.ttf")     format("truetype"); }
+  @font-face{ font-family:"Carlito"; font-style:italic; font-weight:700; src:url("fonts/Carlito-BoldItalic.ttf") format("truetype"); }
+  @font-face{ font-family:"DejaVu Sans Mono"; font-style:normal; font-weight:400; src:url("fonts/DejaVuSansMono.ttf") format("truetype"); }
+
   :root{
     --ink:#1C2B39;        /* deep slate navy — headings, dark fields */
     --ink-2:#3C4A57;      /* body text */
@@ -172,6 +182,14 @@
   .etapa .et-t{ font-family:var(--serif); font-size:13pt; font-weight:700; color:var(--ink); line-height:1.2; }
   .etapa .et-meta{ font-family:var(--sans); font-size:8.5pt; font-weight:700; letter-spacing:.05em; text-transform:uppercase; color:var(--accent-d); margin-top:3pt; }
 
+  /* nested sub-block: an add-on that belongs to the PRECEDING .etapa, not a phase of its own */
+  .ajuste-anidado{ margin:12pt 0 14pt 10pt; padding:10pt 14pt 11pt; background:var(--cream); border-left:2.5pt solid var(--accent); border-radius:0 5pt 5pt 0; break-inside:avoid; }
+  .ajuste-anidado .aj-kick{ font-family:var(--sans); font-size:7.6pt; font-weight:700; letter-spacing:.14em; text-transform:uppercase; color:var(--accent-d); }
+  .ajuste-anidado .aj-t{ font-family:var(--serif); font-size:12pt; font-weight:700; color:var(--ink); line-height:1.2; margin-top:2pt; }
+  .ajuste-anidado .aj-meta{ font-family:var(--sans); font-size:8.5pt; font-weight:700; letter-spacing:.03em; color:var(--muted); margin-top:3pt; }
+  .ajuste-anidado > .aj-body{ margin-top:9pt; }
+  .ajuste-anidado p, .ajuste-anidado ul{ margin:6pt 0; }
+
   /* ---------------- TABLES ---------------- */
   table{ width:100%; border-collapse:collapse; margin:10pt 0; font-size:9.2pt; }
   thead{ display:table-header-group; }
@@ -212,6 +230,8 @@
   }
   .chip.accent{ background:var(--accent); color:#fff; border-color:var(--accent); }
   .arrow{ color:var(--accent); font-weight:700; font-size:11pt; }
+  .aw{ font-family:var(--sans); }          /* flechas →/↔ en títulos serif (Caladea no trae el glifo) */
+  .keep{ break-inside:avoid; }
 
   /* ---------------- SYNTHESIS CARDS ---------------- */
   .synthesis{ display:grid; grid-template-columns:1fr 1fr; gap:9pt; margin:12pt 0; break-inside:avoid; }
@@ -250,10 +270,10 @@
       <dd>Johann Velazquez — Consultor de Software · Monterrey, N.L.</dd>
 
       <dt>Fecha</dt>
-      <dd>29 de mayo de 2026</dd>
+      <dd>29 de mayo de 2026 · actualizada el 28 de julio de 2026</dd>
 
       <dt>Versión</dt>
-      <dd>1.2 — ajustes comerciales acordados 1-jul-2026</dd>
+      <dd>1.3 — integración Jira → BIND incorporada al alcance (§10, control de cambios), 28-jul-2026 · base: v1.2 (1-jul-2026)</dd>
 
       <dt>Vigencia</dt>
       <dd>30 días naturales a partir de la fecha de emisión</dd>
@@ -284,7 +304,7 @@
   <div class="toc-row section"><span class="n">09</span><span class="t">Fuera del alcance de esta etapa</span><span class="dots"></span><span class="pg">{{PG_9}}</span></div>
   <div class="toc-row section"><span class="n">10</span><span class="t">Garantía y condiciones generales</span><span class="dots"></span><span class="pg">{{PG_10}}</span></div>
   <div class="toc-row section"><span class="n">11</span><span class="t">Próximos pasos</span><span class="dots"></span><span class="pg">{{PG_11}}</span></div>
-  <div class="toc-row annex"><span class="n">A</span><span class="t">Anexo A — Trazabilidad PRD ↔ MVP</span><span class="dots"></span><span class="pg">{{PG_anexoA}}</span></div>
+  <div class="toc-row annex"><span class="n">A</span><span class="t">Anexo A — Trazabilidad PRD <span class="aw">↔</span> MVP</span><span class="dots"></span><span class="pg">{{PG_anexoA}}</span></div>
   <div class="toc-row annex"><span class="n">B</span><span class="t">Anexo B — Cotización indicativa de fases posteriores</span><span class="dots"></span><span class="pg">{{PG_anexoB}}</span></div>
 </div>
 
@@ -299,23 +319,23 @@
     <p>Balam opera hoy un proceso financiero fragmentado: facturación, cobranza, conciliación y contabilidad viven en sistemas que no se comunican, y el trabajo de unirlos recae en personas. Cada traspaso manual introduce error, retrabajo y demoras de cobranza que erosionan la relación con los clientes estratégicos.</p>
   </div>
 
-  <p>Esta propuesta plantea una <strong>primera etapa enfocada</strong>: una plataforma web que centraliza la facturación y las cuentas por cobrar sobre <strong>BIND ERP</strong>, el sistema ya confirmado como fuente de verdad. El MVP permite <strong>emitir facturas en MXN y USD</strong> desde la plataforma —creando la cotización y convirtiéndola en factura a través de la API de BIND, que conserva el timbrado CFDI— y entrega además visibilidad, dashboard, alertas y reglas de cobranza. Toda emisión opera con <strong>confirmación humana y modo de simulación</strong>, de modo que la prioridad #1 de Balam (facturación) se atiende sin asumir riesgos fiscales. La arquitectura queda preparada para incorporar conciliación bancaria, pagos en línea, contabilidad e integraciones adicionales conforme se validen.</p>
+  <p>Esta propuesta plantea una <strong>primera etapa enfocada</strong>: una plataforma web que centraliza la facturación y las cuentas por cobrar sobre <strong>BIND ERP</strong>, el sistema ya confirmado como fuente de verdad. El MVP permite <strong>emitir facturas en MXN y USD</strong> desde la plataforma —creando la cotización y convirtiéndola en factura a través de la API de BIND, que conserva el timbrado CFDI— y entrega además visibilidad, dashboard, alertas y reglas de cobranza. Toda emisión opera con <strong>confirmación humana y modo de simulación</strong>, de modo que la prioridad #1 de Balam (facturación) se atiende sin asumir riesgos fiscales. Con el <strong>ajuste de julio de 2026</strong>, el alcance incorpora además la <strong>integración con Jira</strong>: los tickets de la bandeja de Facturación generan automáticamente su cotización en BIND, conservando los mismos candados de control. La arquitectura queda preparada para incorporar conciliación bancaria, pagos en línea, contabilidad e integraciones adicionales conforme se validen.</p>
 
   <p class="mini-label">En síntesis</p>
   <div class="synthesis">
     <div class="scard">
       <div class="lab">Alcance</div>
-      <div class="val">MVP de facturación (consulta y <strong>emisión asistida</strong> MXN/USD) y cobranza sobre la API de BIND ERP.</div>
+      <div class="val">MVP de facturación (consulta y <strong>emisión asistida</strong> MXN/USD) y cobranza sobre la API de BIND ERP, más la <strong>integración acotada con Jira</strong> (generación automática de cotizaciones desde la bandeja de Facturación — ajuste jul-2026).</div>
     </div>
     <div class="scard">
       <div class="lab">Plazo</div>
-      <div class="big">6 a 7 semanas</div>
+      <div class="big">6 a 8 semanas</div>
       <div class="sm">a media dedicación.</div>
     </div>
     <div class="scard">
       <div class="lab">Inversión</div>
-      <div class="big">$67,200 – $81,600 MXN</div>
-      <div class="sm">+ IVA · tiempo y materiales con tope por etapa.</div>
+      <div class="big">$71,400 – $87,600 MXN</div>
+      <div class="sm">+ IVA · tiempo y materiales con tope por etapa · incluye el ajuste Jira → BIND (7 – 10 h).</div>
     </div>
     <div class="scard">
       <div class="lab">Modelo</div>
@@ -323,7 +343,7 @@
     </div>
   </div>
 
-  <p>El enfoque responde directamente a la indicación del CTO de priorizar facturación e integrar únicamente BIND en esta primera fase, evitando comprometer alcance que dependa de integraciones aún no disponibles o no prioritarias.</p>
+  <p>El enfoque responde directamente a la indicación del CTO de priorizar facturación y BIND en esta primera fase, evitando comprometer alcance que dependa de integraciones aún no disponibles o no prioritarias. La integración con Jira —originalmente diferida— se incorporó en julio de 2026 como ajuste de alcance, una vez que la propia dirección confirmó que el proceso de facturación se gobierna en Jira y que su API cubre lo necesario.</p>
 </section>
 
 <!-- ===== 1. ENTENDIMIENTO DEL PROYECTO ===== -->
@@ -334,11 +354,12 @@
   <p>Durante la sesión con el equipo directivo, la lectura del requerimiento fue clara: <em>"El proceso está tan desvinculado… pasa por varias manos… cada parte humana se está equivocando."</em> El reto no es de naturaleza técnica, sino operativa y económica. Cada traspaso manual entre nómina, facturación, cobranza, conciliación y contabilidad genera errores que se traducen en dinero perdido, retrabajo y deterioro en la relación con clientes clave.</p>
 
   <h3><span class="sn">1.2</span>Contexto que define el alcance</h3>
-  <p>Tras la sesión de seguimiento y las actualizaciones del CTO del 25 de mayo, tres factores reordenan el alcance del MVP:</p>
+  <p>Tras la sesión de seguimiento y las actualizaciones del CTO del 25 de mayo, cuatro factores reordenan el alcance del MVP:</p>
   <ol>
     <li><strong>BIND ERP cuenta con API oficial</strong> (<code>api.bind.com.mx</code>, OData v3, 20,000 solicitudes/día). Esto permite una integración por API en tiempo cercano a real, superando el supuesto inicial de exportación manual de archivos.</li>
     <li><strong>La dirección técnica priorizó la facturación.</strong> Conforme a la indicación de considerar "únicamente BIND ERP en una primera etapa", funcionalidades como pagos en línea, conciliación bancaria, recordatorios automáticos a clientes y asientos contables se difieren de manera explícita a fases posteriores.</li>
     <li><strong>BUK dispone de API</strong>, confirmada por el equipo de Balam, aunque no constituye una prioridad inmediata. Queda contemplada en el roadmap sin condicionar el MVP.</li>
+    <li><strong>El proceso interno evolucionó hacia Jira</strong> (confirmado por la dirección en julio de 2026): hoy todo el flujo de facturación nace y se gobierna en Jira — <em>"lo que no está en Jira no se procesa"</em> — con una bandeja dedicada (<strong>Facturación</strong>, llave <code>FAC-</code>) y un flujo de estatus formal. Por ello, la integración con Jira se incorporó al alcance como <strong>ajuste conforme al control de cambios</strong> (§10), detallado en la §2.</li>
   </ol>
 
   <h3><span class="sn">1.3</span>Sistemas actuales</h3>
@@ -347,7 +368,7 @@
     <tbody>
       <tr><td class="k">BIND ERP</td><td>Facturación y contabilidad con PAC integrado</td><td>Integración principal (API confirmada)</td></tr>
       <tr><td class="k">BUK</td><td>Recursos humanos, contratos, nómina</td><td>Fuera de alcance (API disponible, fase posterior)</td></tr>
-      <tr><td class="k">Jira</td><td>Gestión de proyectos y servicios</td><td>Fuera de alcance</td></tr>
+      <tr><td class="k">Jira</td><td>Gestión de proyectos y servicios; origen operativo del proceso de facturación</td><td><strong>Integración acotada (ajuste jul-2026):</strong> lectura de la bandeja Facturación y generación automática de cotizaciones en BIND</td></tr>
       <tr><td class="k">Banca (3 instituciones)</td><td>2 México + IBC Bank Texas, estados en PDF</td><td>Fuera de alcance</td></tr>
     </tbody>
   </table>
@@ -358,6 +379,7 @@
   <p><strong>Alcance funcional del MVP:</strong></p>
   <ul>
     <li>Integración con BIND ERP vía API: lectura primero y <strong>escritura asistida</strong> una vez validada en Discovery.</li>
+    <li><strong>Integración con Jira (ajuste jul-2026):</strong> lectura de los tickets de la bandeja <strong>Facturación (<code>FAC-</code>)</strong> y generación automática de la cotización en BIND al alcanzar el estatus disparador que Balam defina, mediante la misma capa de escritura controlada y con trazabilidad ticket ↔ cotización ↔ factura.</li>
     <li><strong>Emisión de facturas desde la plataforma:</strong> creación de cotización y conversión a factura en MXN (con IVA) y USD (sin IVA, para clientes extranjeros) a través de la API de BIND, con timbrado a cargo del PAC de BIND, confirmación humana obligatoria y modo de simulación (<em>dry-run</em>) previo a cada emisión.</li>
     <li>Catálogo central de clientes con lista blanca configurable (ACUNTIA + Top 3).</li>
     <li>Vista unificada de facturación: estados, vencimientos, filtros y descarga de PDF/XML.</li>
@@ -393,6 +415,7 @@
     <li>Reducción medible del trabajo manual de consulta y reporteo sobre BIND.</li>
     <li>Aplicación correcta de la lista blanca: ACUNTIA y Top 3 nunca reciben recordatorios automáticos masivos.</li>
     <li>Entrega del MVP funcional en el plazo comprometido, con alcance acotado y sin desviaciones.</li>
+    <li>Trazabilidad ticket de Jira → cotización → factura sin captura manual duplicada, una vez definido el flujo de facturación.</li>
     <li>Control fiscal: ninguna factura se emite sin confirmación humana explícita; el timbrado CFDI permanece a cargo del PAC de BIND.</li>
   </ul>
 
@@ -432,7 +455,7 @@
 
   <div class="callout"><strong>Sobre las versiones.</strong> Las versiones indicadas son la referencia vigente a mayo de 2026; se fijan al inicio del proyecto sobre la rama estable/LTS de cada tecnología. Se prioriza <strong>.NET 10</strong> por ser versión de soporte extendido (LTS), apropiada para una aplicación financiera de largo plazo.</div>
 
-  <p>El proyecto se organiza en cuatro etapas secuenciales. Cada una concluye con un entregable demostrable y se factura conforme a horas reales (ver §3).</p>
+  <p>El proyecto se organiza en cuatro etapas secuenciales, más el <strong>ajuste Jira → BIND</strong> incorporado en julio de 2026 dentro de la Etapa 2 (ver más abajo). Cada bloque concluye con un entregable demostrable y se factura conforme a horas reales (ver §3).</p>
 
   <div class="etapa"><div class="et-t">Etapa 0 — Discovery, infraestructura y prototipo visual</div><div class="et-meta">Semana 1 · 18 – 22 h</div></div>
   <p><strong>Objetivo.</strong> Validar el comportamiento real de la API de BIND con la cuenta de Balam, preparar la infraestructura en Azure, dejar el repositorio operativo y <strong>entregar un prototipo visual navegable</strong> que alinee expectativas de producto antes de iniciar el desarrollo del backend.</p>
@@ -480,6 +503,38 @@
   </ul>
   <div class="callout cool"><strong>Fuera de esta etapa:</strong> generación automática de facturas desde eventos de negocio (Jira → BUK → factura), soporte EUR e integración con BUK. El timbrado CFDI permanece a cargo del PAC de BIND.</div>
 
+  <div class="ajuste-anidado">
+    <div class="aj-kick">Ajuste dentro de la Etapa 2</div>
+    <div class="aj-t">Integración Jira <span class="aw">→</span> BIND (jul-2026)</div>
+    <div class="aj-meta">Inicia el lunes 27 de julio (token PAF ya entregado) · 7 – 10 h</div>
+
+    <div class="aj-body">
+    <p><strong>Antecedente.</strong> La versión anterior de esta propuesta dejó Jira fuera del alcance conforme a la información disponible al cotizar. En las sesiones del 22, 24 y 27 de julio la dirección confirmó que el proceso interno evolucionó — todo el flujo de facturación nace y se gobierna en Jira — y quedó confirmada la viabilidad técnica: la API de Jira cubre lectura y escritura de tickets, se entregó el token de integración (<strong>"PAF"</strong>, vigente al 27-jul-2027) y se documentaron los límites de consumo de Atlassian. La estimación (~10 h) se comunicó a la PM el 21 de julio; esta sección la formaliza conforme al control de cambios (§10). Se agrupa aquí, dentro de la Etapa 2, porque automatiza exactamente el mismo entregable de esa etapa —<strong>creación de cotizaciones</strong>— solo que a partir de un ticket de Jira en vez de captura manual.</p>
+
+    <p><strong>Entregables:</strong></p>
+    <ul>
+      <li><strong>Conexión con la API de Jira</strong> mediante el token PAF y lectura de los tickets de la bandeja <strong>Facturación (<code>FAC-</code>)</strong>, con consumo autorregulado conforme a los límites de velocidad documentados por Atlassian.</li>
+      <li><strong>Generación automática de la cotización en BIND</strong> cuando un ticket alcanza el estatus disparador que Balam defina (candidato natural: la entrada del ticket al proceso de facturación, previo a "resuelto"), a través de la misma capa de escritura controlada del MVP.</li>
+      <li><strong>Trazabilidad ticket ↔ cotización ↔ prefactura/factura</strong>, visible en la plataforma y registrada en la bitácora de auditoría; los tickets leídos alimentan además la vista <em>"qué necesita atención"</em> del tablero.</li>
+      <li><strong>Pruebas controladas:</strong> scripts de consulta y de creación/edición sobre un registro de prueba, y una <strong>prueba observada</strong> con el equipo de Balam antes de habilitar la generación automática en operación.</li>
+    </ul>
+
+    <div class="flow">
+      <span class="chip">Ticket Jira <small>(FAC)</small></span><span class="arrow">→</span>
+      <span class="chip accent">Cotización BIND <small>(automática)</small></span><span class="arrow">→</span>
+      <span class="chip">Prefactura</span><span class="arrow">→</span>
+      <span class="chip">Aprobación humana</span><span class="arrow">→</span>
+      <span class="chip">Timbrado <small>(PAC de BIND)</small></span>
+    </div>
+
+    <div class="callout"><strong>El control fiscal no cambia.</strong> La integración crea <strong>cotizaciones, nunca facturas</strong>: se mantiene la cadena acordada — cotización → prefactura → <strong>aprobación humana</strong> → timbrado por el PAC de BIND — con modo de simulación (<em>dry-run</em>), feature flag y registro en bitácora. No existe timbrado automático.</div>
+
+    <p><strong>No incluye:</strong> (a) el <strong>alta automática de clientes en BIND</strong> — si el cliente del ticket no existe, la plataforma lo detecta y lo notifica; darlo de alta automáticamente es una decisión de proceso abierta que, de aprobarse, se estima por separado; (b) <strong>tickets con múltiples facturas</strong> — el supuesto es <em>un ticket → una cotización</em>; el manejo del caso masivo se define junto con Balam y, si requiere desarrollo adicional, se estima por separado; (c) <strong>otros usos de Jira</strong> (reporteo de horas de consultores, tableros sobre otras bandejas, espacio comercial) y los módulos del Anexo B.</p>
+
+    <div class="callout cool"><strong>Dependencia clave.</strong> La implementación inicia una vez que Balam cierre la <strong>definición del flujo de facturación</strong> (en revisión interna), de la cual salen el estatus disparador y las reglas de prefactura.</div>
+    </div>
+  </div>
+
   <div class="etapa"><div class="et-t">Etapa 3 — Cobranza, tablero, reportes y cierre</div><div class="et-meta">Semanas 6-7 · 24 – 29 h</div></div>
   <p><strong>Objetivo.</strong> Cerrar el flujo operativo con visibilidad para Dirección y realizar la entrega formal.</p>
   <div class="mini-label">Entregables</div>
@@ -512,7 +567,7 @@
   </ul>
 
   <h3><span class="sn">3.2</span>Dedicación y plazo</h3>
-  <p>La dedicación es de <strong>media jornada (aproximadamente 20 h/semana</strong>, con flexibilidad hasta 25 h en semanas de mayor carga). Sobre esa base, la primera etapa requiere <strong>112 a 136 horas</strong>, equivalentes a <strong>6 – 7 semanas</strong> de calendario.</p>
+  <p>La dedicación es de <strong>media jornada (aproximadamente 20 h/semana</strong>, con flexibilidad hasta 25 h en semanas de mayor carga). Sobre esa base, la primera etapa requiere <strong>119 a 146 horas</strong> (incluido el ajuste Jira → BIND), equivalentes a <strong>6 – 8 semanas</strong> de calendario.</p>
 
   <h3><span class="sn">3.3</span>Tarifa y facturación</h3>
   <ul>
@@ -546,18 +601,21 @@
   <div class="sec-head"><div class="sec-num">04</div><div><h2>Inversión</h2></div></div>
   <p>La inversión de la primera etapa se desglosa por entregable, conforme al esquema de tiempo y materiales:</p>
 
+  <div class="keep">
   <table>
     <thead><tr><th>Etapa</th><th>Entregable principal</th><th class="num">Rango (horas)</th><th class="num">Inversión (MXN)</th></tr></thead>
     <tbody>
       <tr><td class="k ctr">0</td><td>Discovery, infraestructura Azure y <strong>prototipo visual navegable</strong></td><td class="num">18 – 22</td><td class="num">$10,800 – $13,200</td></tr>
       <tr><td class="k ctr">1</td><td>Plataforma base, sincronización con BIND y capa de escritura</td><td class="num">32 – 39</td><td class="num">$19,200 – $23,400</td></tr>
       <tr><td class="k ctr">2</td><td>Facturación (consulta y <strong>emisión</strong> MXN/USD), catálogo y multimoneda</td><td class="num">38 – 46</td><td class="num">$22,800 – $27,600</td></tr>
+      <tr><td class="k ctr">»</td><td><strong>Integración Jira → BIND</strong> (dentro de la Etapa 2 — lectura de la bandeja FAC, cotización automática, trazabilidad y pruebas) — jul-2026</td><td class="num">7 – 10</td><td class="num">$4,200 – $6,000</td></tr>
       <tr><td class="k ctr">3</td><td>Cobranza, tablero, reportes y cierre</td><td class="num">24 – 29</td><td class="num">$14,400 – $17,400</td></tr>
-      <tr class="total"><td colspan="2">Total primera etapa</td><td class="num">112 – 136 h</td><td class="num">$67,200 – $81,600</td></tr>
+      <tr class="total"><td colspan="2">Total primera etapa</td><td class="num">119 – 146 h</td><td class="num">$71,400 – $87,600</td></tr>
     </tbody>
   </table>
+  </div>
 
-  <div class="callout cool">Cifras antes de IVA. Plazo estimado: <strong>6 – 7 semanas</strong> a media jornada (~20 h/semana, con flexibilidad hasta 25 h en semanas pico).</div>
+  <div class="callout cool">Cifras antes de IVA. Plazo estimado: <strong>6 – 8 semanas</strong> a media jornada (~20 h/semana, con flexibilidad hasta 25 h en semanas pico). <strong>El ajuste Jira → BIND</strong> se incorporó conforme al control de cambios (§10) a partir de la confirmación de julio de 2026 (ver §2); el rango es consistente con la estimación de ~10 h comunicada el 21 de julio y su ejecución inicia una vez que Balam cierre la definición del flujo de facturación.</div>
   <div class="callout">El esquema de control por etapa busca que la inversión se concentre en la parte baja del rango; el margen superior cubre eventualidades del Discovery con BIND. Toda variación se comunica antes de incurrir en ella.</div>
 </section>
 
@@ -601,7 +659,7 @@
       <tr><td class="k">Azure Key Vault + Application Insights</td><td>Secretos (Standard) + observabilidad (5 GB/mes incluidos, luego por GB)</td><td class="num">$0 – $15</td></tr>
       <tr><td class="k">Monitoreo de disponibilidad / Sentry <em>(opcional)</em></td><td>Plan gratuito → Team</td><td class="num">$0 – $26</td></tr>
       <tr><td class="k">PAC para CFDI</td><td>Ya incluido en BIND</td><td class="num">Sin costo adicional</td></tr>
-      <tr class="total"><td colspan="2">Total mensual estimado</td><td class="num">$30 – $160 USD/mes</td></tr>
+      <tr class="total"><td colspan="2">Total mensual estimado</td><td class="num">$30 – $162 USD/mes</td></tr>
     </tbody>
   </table>
 
@@ -628,6 +686,8 @@
     <li><strong>Acuerdo de uso de la metodología asistida por IA</strong>, con el compromiso de no entrenamiento sobre datos del cliente.</li>
     <li><strong>El PAC integrado de BIND</strong> atiende los volúmenes actuales y futuros sin costo adicional; el timbrado CFDI permanece a cargo de BIND, no de la plataforma.</li>
     <li><strong>El comportamiento de escritura de la API de BIND</strong> (creación de cotización, conversión a factura y timbrado) se valida en Discovery; la emisión productiva se habilita únicamente tras esa validación. Balam designa al rol responsable de confirmar cada emisión.</li>
+    <li><strong>Token de Jira ("PAF") vigente</strong> con visibilidad de la bandeja Facturación (<code>FAC-</code>), que opera como bandeja "padre" del proceso; si algún disparador nace en otra bandeja sin reflejarse en FAC, el ajuste se revisa en conjunto. Entregado el 27-jul-2026.</li>
+    <li><strong>Definición del flujo de facturación</strong> cerrada por Balam (estatus disparador y reglas de prefactura) y <strong>diagrama del flujo Jira en tamaño legible</strong> entregado, antes de iniciar la implementación del ajuste Jira → BIND.</li>
   </ol>
 </section>
 
@@ -677,7 +737,8 @@
   <ol>
     <li>Firma del contrato u orden de trabajo (prestación de servicios y confidencialidad).</li>
     <li>Emisión de la primera factura por 30 horas de arranque (<strong>$18,000 MXN</strong> + IVA) e inicio del Discovery; pago a 30 días naturales.</li>
-    <li>Arranque del proyecto, con entrega del MVP en <strong>6 – 7 semanas</strong>.</li>
+    <li>Arranque del proyecto, con entrega del MVP en <strong>6 – 8 semanas</strong>.</li>
+    <li><strong>Aprobación por escrito de la versión 1.3</strong> (basta la confirmación por correo electrónico) para ejecutar el ajuste Jira → BIND de 7 – 10 h una vez definido el flujo de facturación.</li>
   </ol>
 
   <div class="signoff">
@@ -687,7 +748,7 @@
 </section>
 <!-- ===== ANEXO A — TRAZABILIDAD PRD ↔ MVP ===== -->
 <section class="sec" style="break-before:page;">
-  <div class="sec-head"><div class="sec-num">A</div><div><span class="kick">Anexo</span><h2>Trazabilidad PRD ↔ MVP</h2></div></div>
+  <div class="sec-head"><div class="sec-num">A</div><div><span class="kick">Anexo</span><h2>Trazabilidad PRD <span class="aw">↔</span> MVP</h2></div></div>
 
   <p class="lede">Este anexo relaciona cada funcionalidad y requerimiento del <strong>PRD de Balam</strong> con el alcance comprometido en la primera etapa, como referencia para alinear expectativas sobre lo incluido, lo parcial y lo diferido.</p>
 
@@ -701,7 +762,7 @@
   <table>
     <thead><tr><th>Funcionalidad PRD</th><th class="ctr" style="width:62pt;">Cobertura</th><th>Detalle</th></tr></thead>
     <tbody>
-      <tr><td class="k">Generación automatizada de facturas</td><td class="cov">⚠️</td><td><strong>Incluida la creación asistida:</strong> cotización → factura desde la plataforma vía API de BIND, con confirmación humana; el timbrado lo realiza el PAC de BIND. La generación <strong>automática desde eventos</strong> (Jira→BUK→Factura) depende de APIs no disponibles hoy — fase posterior.</td></tr>
+      <tr><td class="k">Generación automatizada de facturas</td><td class="cov">⚠️</td><td><strong>Incluida la creación asistida:</strong> cotización → factura desde la plataforma vía API de BIND, con confirmación humana; el timbrado lo realiza el PAC de BIND. Con el <strong>ajuste jul-2026</strong>, los tickets de Jira (bandeja Facturación) <strong>generan automáticamente su cotización</strong>; la cadena completa sin intervención (Jira→BUK→Factura) sigue en fase posterior.</td></tr>
       <tr><td class="k">Multimoneda para clientes internacionales (USD sin IVA)</td><td class="cov">✅</td><td><strong>Emisión en MXN (con IVA) y USD (sin IVA)</strong> con tipo de cambio del DOF capturado al momento de facturación. <strong>EUR queda fuera del MVP.</strong></td></tr>
       <tr><td class="k">Descarga automática de facturas / reporte</td><td class="cov">✅</td><td>Listado con filtros, búsqueda, detalle con PDF/XML y exportación a Excel.</td></tr>
     </tbody>
@@ -751,7 +812,7 @@
   <table class="compact">
     <thead><tr><th style="width:46pt;">ID</th><th>Descripción</th><th class="ctr" style="width:62pt;">Cobertura</th><th>Notas</th></tr></thead>
     <tbody>
-      <tr><td class="k">RF-01</td><td>Generar facturas automáticamente desde eventos</td><td class="cov">⚠️</td><td>Creación manual (cotización→factura) incluida; la generación automática desde eventos requiere Jira/BUK — fase posterior</td></tr>
+      <tr><td class="k">RF-01</td><td>Generar facturas automáticamente desde eventos</td><td class="cov">⚠️</td><td>Creación asistida (cotización→factura) incluida; con el ajuste jul-2026, los tickets de Jira generan automáticamente la <strong>cotización</strong>. La factura siempre requiere aprobación humana; la cadena BUK→Factura sigue en fase posterior</td></tr>
       <tr><td class="k">RF-02</td><td>Multimoneda USD/EUR/MXN</td><td class="cov">⚠️</td><td>Emisión MXN + USD en el MVP; EUR en fase posterior</td></tr>
       <tr><td class="k">RF-03</td><td>Integración con sistemas existentes (BUK / nómina)</td><td class="cov">❌</td><td>API de BUK confirmada, no prioritaria</td></tr>
       <tr><td class="k">RF-04</td><td>Registrar pagos desde fuentes bancarias</td><td class="cov">❌</td><td>Fase posterior</td></tr>
@@ -782,8 +843,10 @@
   </table>
 
   <h3><span class="sn">A.4</span>Diferidos — resumen</h3>
+  <div class="keep">
   <p class="mini-label">Bloqueado por terceros o sin prioridad actual</p>
-  <p>Generación automática de facturas (Jira→BUK→Factura); integración bancaria en vivo (Belvo / Plaid / IBC Texas); integración con BUK; integración con Jira.</p>
+  <p>Generación automática de facturas de punta a punta (Jira→BUK→Factura); integración bancaria en vivo (Belvo / Plaid / IBC Texas); integración con BUK. <em>(La integración con Jira dejó de estar diferida: se incorporó como ajuste jul-2026 — ver §2.)</em></p>
+  </div>
   <p class="mini-label">Diferido por decisión de alcance</p>
   <p>Pagos en línea; recordatorios automáticos a clientes; conciliación bancaria; asientos contables automáticos; EUR; flujo de efectivo proyectado; detección avanzada de anomalías; portal de cliente; multi-tenant comercial; cumplimiento avanzado Texas.</p>
 </section>
@@ -810,7 +873,7 @@
   <div class="callout">El monto de esta fase es comparable al del MVP porque incorpora <strong>cinco módulos nuevos completos</strong>, cada uno con su propio diseño, integración y pruebas. No se trata de extensiones menores, sino de capacidades adicionales sobre la base ya construida.</div>
 
   <h3><span class="sn">B.2</span>Roadmap posterior (sin cotización)</h3>
-  <p>Se cotiza al cierre de la fase anterior, priorizando con datos reales de uso: integración bancaria en vivo (Belvo, Plaid); conector con BIND para asientos contables automáticos; integración con Jira; flujo de efectivo proyectado (30/60/90 días); gestión cambiaria automática; pagos recurrentes; detección avanzada de anomalías; soporte EUR; clasificación asistida por IA; portal de cliente; multi-tenant comercial; aplicación móvil para tickets; y cumplimiento avanzado para Texas.</p>
+  <p>Se cotiza al cierre de la fase anterior, priorizando con datos reales de uso: integración bancaria en vivo (Belvo, Plaid); conector con BIND para asientos contables automáticos; ampliaciones de la integración con Jira (otras bandejas, reporteo de horas, espacio comercial); flujo de efectivo proyectado (30/60/90 días); gestión cambiaria automática; pagos recurrentes; detección avanzada de anomalías; soporte EUR; clasificación asistida por IA; portal de cliente; multi-tenant comercial; aplicación móvil para tickets; y cumplimiento avanzado para Texas.</p>
 
   <h3><span class="sn">B.3</span>Activación</h3>
   <p>Al cierre del MVP se realiza una sesión de priorización (1 h) y se formaliza una orden de trabajo por módulo seleccionado. La tarifa, el esquema, la comunicación y la garantía aplican en los mismos términos que en la primera etapa (sin anticipo; facturación al inicio de cada módulo, pago a 30 días).</p>

propuesta/pdf.config.json

@@ -9,8 +9,8 @@
   "metadata": {
     "title": "Propuesta Comercial — Plataforma de Automatización Financiera · Balam",
     "author": "Johann Velazquez",
-    "subject": "MVP de facturación y cobranza sobre BIND ERP — propuesta v1.2",
-    "keywords": "propuesta, Balam, BIND ERP, facturación, MVP, v1.2"
+    "subject": "MVP de facturación y cobranza sobre BIND ERP + integración Jira → BIND — propuesta v1.3",
+    "keywords": "propuesta, Balam, BIND ERP, Jira, facturación, MVP, v1.3"
   },
 
   "footer": {
@@ -25,7 +25,7 @@
   },
 
   "fonts": {
-    "footer_ttf": "C:\\Windows\\Fonts\\calibri.ttf"
+    "footer_ttf": "fonts/Carlito-Regular.ttf"
   },
 
   "toc": {