Documenta las definiciones Jira→BIND y su validación por API

Consolida el disparador, los huecos de datos y el protocolo de prueba para continuar el desarrollo con decisiones trazables.

.gitignore

@@ -4,13 +4,22 @@ Thumbs.db
 .vscode/
 .idea/
 
-# Secretos — NUNCA versionar (token API de BIND, producción)
+# Secretos — NUNCA versionar (tokens de API de BIND y Jira, producción)
 bind_token_api.txt
+propuesta/token-jira.txt
 *.env
 
+# Repo de código del cliente (github.com/pedro-balam-itsm/BALAM) — clon local, tiene su propio git
+balam-plataforma/
+
 # Evidencia financiera sensible local — no subir al repositorio
 Resumen de movimientos.pdf
 
+# Respaldos de la BD local (pg_dump formato custom) — traen datos REALES de
+# clientes de BIND; jamás al historial de git.
+# Restaurar: docker exec -i balam-postgres-dev pg_restore -U balam -d balam --clean --if-exists < respaldos/<archivo>
+respaldos/
+
 # Python (skill proposal-pdf)
 __pycache__/
 *.pyc

bitacora/PENDIENTES.md

@@ -2,7 +2,27 @@
 
 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-07-16 (prototipo con validación agendada para el 23-jul; sesión de reglas de Etapa 1 el 22-jul; invitación al repo GitHub recibida y acceso de escritura por validar; procedimientos por cliente recibidos por correo y pendientes de revisión; avance de Etapa 1 solicitado por Erika)._
+_Ú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))._
+
+## 🔥 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.**
+- [ ] 🔴 **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).
+- [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`.**
+- [ ] **Balam — ¿nacional vs extranjero cambia la cotización** o solo el paquete de salida (PDF+XML vs PDF)? Hay dos estatus de validación y una aprobación por rama.
+- [ ] **Balam/Pedro — migrar a cuenta de servicio** en vez de la cuenta personal de Pedro. Planteado el 29-jul, sin respuesta: hoy todo lo que escriba la plataforma queda firmado como Pedro y una rotación suya mata la integración.
+- [ ] **Johann — levantar el sandbox Jira Cloud propio** (plan Free, proyecto JSM que replique el workflow de FAC). Con `FACTEST` descartado, es el único lugar donde se puede equivocar sin costo.
+- [ ] ⚠️ **Johann — implementar la detección por changelog, no por estatus actual.** `FAC-100` estuvo **2m44s** en el estatus disparador; un poller de 15 min que consulte el estado actual se pierde la mayoría de los disparos. Refuerza el caso de pedir un webhook / regla de Automation a Pedro.
+- [ ] **Johann — mover el token de Jira a user-secrets/Key Vault** y borrarlo de disco (ya está en `.gitignore:9`). Mismo pendiente que arrastra `bind_token_api.txt`.
 
 ## 🔴 Johann (proveedor) — inmediato
 
@@ -11,13 +31,15 @@ _Última actualización: 2026-07-16 (prototipo con validación agendada para el
 - [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).
 - [x] ~~📧 **Enviar por correo el prototipo (imágenes) + comentarios**~~ → **Hecho (10-jul).** Balam respondió que lo revisaría internamente.
 - [x] ~~📊 **Responder a Erika el % de avance de Fase 0**~~ → **Atendido mediante el Excel de avance ajustado y entrega del prototipo.** La validación final sigue abierta.
-- [ ] 📅 **Preparar y asistir a la sesión de reglas/dudas de Etapa 1 (mié 22-jul)** con Arturo + CEO: alta de cliente nuevo, fee en BIND, particularidades de envío, estatus disparador de Jira y confirmación de alcance Jira→BIND. Ver [REGISTRO #42](REGISTRO.md).
-- [ ] 📅 **Preparar y asistir a la validación del prototipo (jue 23-jul, 7:00 pm).** Llevar decisiones que requieren visto bueno y separar MVP de Anexo B. Ver [REGISTRO #42](REGISTRO.md).
-- [ ] 📊 **Compartir con Erika el corte de avance de la Etapa 1 solicitado el 16-jul.** Usar cifras verificables: 8 h registradas de 32–39 h; cliente BIND terminado con 13/13 pruebas; scaffold base parcial; base de datos, autenticación/roles, sincronización y cartera en construcción. Ver [REGISTRO #46](REGISTRO.md).
+- [x] ~~📅 **Preparar y asistir a la sesión de reglas/dudas de Etapa 1 (mié 22-jul)**~~ → **Hecha (22-jul, 7 am):** alta de cliente/proveedor mapeada (Arturo en pantalla), fee = lo registra el despacho (plataforma solo detecta), Jira confirmado en el proceso (estatus final "resuelto"; validación PDF+XML nacional / PDF internacional). No se tocaron particularidades de envío ni PUE/PPD. Ver [REGISTRO #54](REGISTRO.md) y minuta en `../planeacion/Sesion-Etapa1-2026-07-22.md`.
+- [ ] 📅 **Preparar y asistir a la validación del prototipo (jue 23-jul, 7:00 pm).** Llevar decisiones que requieren visto bueno y separar MVP de Anexo B. **Aprovechar para meter la pregunta PUE/PPD que no se alcanzó el 22-jul.** Ver [REGISTRO #42](REGISTRO.md).
+- [x] ~~📊 **Compartir con Erika el corte de avance de la Etapa 1 solicitado el 16-jul**~~ → **Hecho (16-jul, 8:40 pm):** Excel `Plan-actividades-avance-2026-07-16.xlsx` enviado por WhatsApp; Erika acusó recibo ("Ntp, gracias"). Ver [REGISTRO #46](REGISTRO.md).
 - [ ] 📄 **Revisar los procedimientos de carga de facturas por cliente enviados por correo el 16-jul.** Conservar correo/adjuntos como evidencia y contrastar destinatarios, adjuntos, asunto, cuerpo y nomenclatura contra el Discovery y el prototipo. Ver [REGISTRO #46](REGISTRO.md).
-- [ ] 🔐 **Validar permiso de escritura en el repositorio privado de Balam.** Johann confirmó que puede acceder, pero falta comprobar `clone/push` o el nivel de permiso antes de mover el trabajo local. Ver [REGISTRO #46](REGISTRO.md).
+- [x] ~~🔐 **Validar permiso de escritura en el repositorio privado de Balam**~~ → **Comprobado (16-jul):** push exitoso del scaffold inicial (backend .NET 10 + Angular 21, commits `220942a..1f7f098`) a `pedro-balam-itsm/BALAM`. Ver [REGISTRO #46](REGISTRO.md).
 - [ ] ⏱️ **Validar el corte reconstruido de 30 h** en `../planeacion/Seguimiento-horas.csv`: 22 h de Etapa 0 + 8 h de Etapa 1. Solo 3.08 h corresponden a sesiones con duración comprobable; las otras 26.92 h están marcadas como reconstruidas. Ajustarlas si la memoria/evidencia indica otra distribución y después conciliar con Jira. Ver [REGISTRO #45](REGISTRO.md).
 - [ ] 📝 **Cerrar el documento de hallazgos + ADRs** (`../planeacion/Hallazgos-y-decisiones-Etapa0.md`) después de las sesiones del 22–23 jul.
+- [ ] 🔐 **Decidir/aplicar el rol local `balam_app` para que RLS aplique en desarrollo:** la política RLS de B6 está aplicada, pero el usuario `balam` del contenedor es superuser (BYPASSRLS) y la ignora. Falta: `CREATE ROLE balam_app LOGIN NOSUPERUSER NOBYPASSRLS` + `REASSIGN OWNED` + apuntar la cadena de conexión de desarrollo (appsettings.Development y DesignTimeDbContextFactory) a ese rol + repetir la verificación psql. En Azure no existe este hueco (el usuario de app no es superuser). Ver [REGISTRO #53](REGISTRO.md).
+- [ ] ⚠️ **Preguntar a Arturo: ¿por qué TODO el histórico se factura PUE?** 1,374/1,374 facturas con método de pago = PUE, cero PPD, aunque cobran a crédito 30–90 días. Toca la regla "PPD default" de la capa de escritura (B7) y el requerimiento del SAT que ellos mismos sufrieron. **No se alcanzó a preguntar en la sesión del 22-jul** — reintentar el 23-jul (validación del prototipo) o en la sesión de API Jira con Pedro. Ver [REGISTRO #52](REGISTRO.md), [#54](REGISTRO.md).
 - [x] ~~📅 **Proponer a Erika usar la sesión del martes 7-jul para COBRANZA**~~ → **Propuesto (6-jul, 3:01 pm) y CONFIRMADO (6-jul, 6:36 pm):** convocatoria de Teams enviada para el martes 7-jul, 7:00–8:00 am, con Araceli y Arturo (CC Noé). Ver [REGISTRO #34](REGISTRO.md).
 - [x] ~~📅 **Asistir a la sesión de cobranza (mar 7-jul, 7:00 am)**~~ → **Hecha (7-jul).** Sin grabación. Ver [REGISTRO #35](REGISTRO.md).
 - [x] ~~📝 **Documentar el proceso de cobranza** de la sesión del 7-jul (sin grabación)~~ → **Hecho (7-jul):** reconstruido de memoria el mismo día. Notas en `../fuentes/2026-07-07 - Notas - Proceso actual de cobranza (sin grabacion).md`; entrada [REGISTRO #35](REGISTRO.md).
@@ -67,7 +89,9 @@ _Última actualización: 2026-07-16 (prototipo con validación agendada para el
 - [ ] **Pedro + Noé:** **configurar Azure** y permisos (Noé otorga donde Pedro tiene limitantes).
 - [x] ~~**Erika:** **coordinar la sesión de Discovery con Arturo + Araceli**~~ → **Hecho:** agendada (1-jul) y **realizada (6-jul, 7am)**. Ver [REGISTRO #24](REGISTRO.md), [#27](REGISTRO.md).
 - [ ] 📊 **Ara + Arturo:** enviar el **Excel de particularidades de envío por cliente** (destinatarios + adjuntos + nomenclatura). Erika confirmó el 13-jul que continúa en preparación y que esperan entregarlo durante la semana. Ver [REGISTRO #41](REGISTRO.md).
-- [ ] **Arturo:** definir el proceso para cuando el **cliente NO esté dado de alta en BIND** (alta de cliente como flujo aparte de la automatización) — pregunta que él mismo dejó abierta el 6-jul. Ver [REGISTRO #27](REGISTRO.md).
+- [ ] **Arturo:** definir el proceso para cuando el **cliente NO esté dado de alta en BIND** — el ASIS del alta ya quedó mapeado en la sesión del 22-jul ([REGISTRO #54](REGISTRO.md)); **sigue abierta la decisión de MVP: ¿la plataforma solo detecta que falta el cliente o también lo crea?** (cruza con la estimación Jira→BIND de ~10 h). Ver [REGISTRO #27](REGISTRO.md), [#51](REGISTRO.md).
+- [ ] 📤 **Arturo/Pedro:** enviar a Johann el **diagrama del flujo Jira de facturación** en tamaño legible (comprometido en la sesión del 22-jul; el screenshot era ilegible). Ver [REGISTRO #54](REGISTRO.md).
+- [ ] 📅 **Erika:** agendar la **sesión con Pedro (+Arturo)** para explorar la **API de Jira** (conexión, campos, webhook), la **facturación recurrente** (~30 facturas/mes) y qué facturas son automáticas vs manuales — acordada en la sesión del 22-jul. Ver [REGISTRO #54](REGISTRO.md).
 - [ ] **Erika + Paola / Noé:** confirmar la propuesta v1.2 para emitir las 30 h. Erika confirmó recepción; validación pendiente por viaje de Noé y CEO. Ver [REGISTRO #41](REGISTRO.md).
 - [ ] **Arturo:** dar acceso/contexto de **bancos** (para conciliación). _Las reglas de negocio de facturación ya quedaron mapeadas en la sesión del 6-jul ([REGISTRO #27](REGISTRO.md)); bancos sigue pendiente._
 

bitacora/REGISTRO.md

@@ -11,7 +11,7 @@
 - **Pedro Alberto Ayala Elizondo** — Desarrollador / contacto técnico, Balam — `pedro.ayala@balamtalentoestrategico.com`
 - **Paola** — Recursos Humanos, Balam — coordinó la firma del contrato (WhatsApp)
 
-**Periodo:** 30 abr 2026 → 10 jul 2026 (última actualización: avance de Fase 0 + envío del prototipo por correo, 10-jul)
+**Periodo:** 30 abr 2026 → 22 jul 2026 (última actualización: sesión de reglas Etapa 1 — alta de clientes, fee y flujo Jira, 22-jul)
 **Orden:** cronológico (más antiguo arriba)
 
 ---
@@ -834,18 +834,356 @@ Se cargan 3.08 h de sesiones con duración comprobable y se reconstruye retrospe
 
 Erika informa que Pedro envió el 15-jul la invitación al repositorio privado y pide validar el acceso. Johann confirma por WhatsApp que ya puede entrar; queda pendiente comprobar que también tenga permisos de escritura. Erika envía por correo los procedimientos de carga de facturas por cliente y Johann confirma recepción.
 
-Erika solicita un corte del avance de la Etapa 1. Johann se compromete a prepararlo y compartirlo por WhatsApp.
+Erika solicita un corte del avance de la Etapa 1. Johann se compromete a prepararlo y compartirlo por WhatsApp. **Esa misma noche (8:40 pm) Johann envía por WhatsApp el Excel `Plan-actividades-avance-2026-07-16.xlsx`; Erika acusa recibo a las 8:44 pm ("Ntp, gracias").**
 
 **Acciones derivadas:**
 
-- [ ] Johann — validar permisos de escritura en el repositorio de Balam.
+- [x] ~~Johann — validar permisos de escritura en el repositorio de Balam~~ → **Comprobado (16-jul):** push exitoso del scaffold inicial (backend .NET 10 + frontend Angular 21) al repo de Balam.
 - [ ] Johann — revisar el correo y los procedimientos de carga de facturas; documentar reglas o diferencias frente al Discovery.
-- [ ] Johann — enviar a Erika el corte de avance de Etapa 1.
+- [x] ~~Johann — enviar a Erika el corte de avance de Etapa 1~~ → **Hecho (16-jul, 8:40 pm):** Excel enviado por WhatsApp con acuse de Erika.
 
 **Estado técnico comprobado al preparar el corte:** repositorio local limpio; solución .NET 10 y cliente BIND compilando; 13/13 pruebas del cliente BIND aprobadas; endpoints base `/health` y `/api/bind/status`. La base de datos, autenticación/roles, sincronización y endpoints de cartera siguen en construcción.
 
 ---
 
+## 47 · Jul 19, 2026 · Gestión interna · demo del 18-jul no realizada; entorno local montado en la Mac
+
+La **demo semanal planeada para el viernes 18-jul no ocurrió** (confirmado por Johann el 19-jul). Causa señalada: la validación del prototipo de la Etapa 0 sigue pendiente (quedó para el jue 23-jul) y eso ha retrasado el avance de la etapa. Los días 17–18 jul no registran trabajo en `../planeacion/Seguimiento-horas.csv`. La próxima demo queda apuntada al **viernes 24-jul** (cierre de Etapa 1), donde también conviene comunicar que la capa de escritura se entrega en dry-run (ver nota en `../planeacion/Agenda-semana-2026-07-20.md`).
+
+El mismo 19-jul se montó el entorno local en la Mac: repo del cliente clonado en `balam-plataforma/` (convención de `../planeacion/Plan-Etapa1.md`), SDK .NET 10 instalado en usuario, token cargado en user-secrets, API corriendo (`/health` y `/api/bind/status` verificados, modo ReadOnly, 13/13 pruebas verdes) y frontend Angular servido. Se creó la agenda por día de la semana 20–24 jul (`../planeacion/Agenda-semana-2026-07-20.md`) y se actualizó el CSV de horas con los cortes del 16 y 19 jul.
+
+---
+
+## 48 · Jul 19, 2026 — noche · Desarrollo · B0+B1 completados (adelantados del lunes) + Scalar UI
+
+Trabajo adelantado la noche del domingo siguiendo `../planeacion/Plan-Etapa1.md` al pie, con asistencia de IA (Claude Code). Tiempo real registrado en `../planeacion/Seguimiento-horas.csv` (~1.25 h de sesión — el plan estimaba 4–5.5 h manuales; el registro es de horas efectivamente trabajadas, conforme al contrato).
+
+**B0 — Preparación local:** `docker-compose.yml` con Postgres 17 en puerto **5438** (5433–5437 ocupados por otros proyectos locales — difiere del 5433 que asume el plan en la otra máquina); cadena de conexión en `appsettings.Development.json`; `DesignTimeDbContextFactory`; referencia Infrastructure → Integrations.Bind; `dotnet-ef` 10.0.10.
+
+**B1 — Fundación de datos:** entidades `Tenant`, `Client`, `Invoice` (modelo central: `Uuid` null ⇒ prefactura, `OpenBalance`, `CfdiPaymentTermRaw`, `PaidDetectedAtUtc`), `Quote`, `QuoteInvoiceLink` (ADR-003, con `JiraTicketKey` ADR-006), `InvoiceStatusChange` (ADR-004, fecha de detección), `WriteOperation` (pipeline Draft→DryRun→Confirmed, ADR-001); `TenantId` en `SyncCheckpoint`/`AuditLogEntry`; `BalamDbContext` → `IdentityDbContext` con llaves Guid; convenciones fechas BIND sin zona vs `*Utc` timestamptz y `decimal(18,2)`/`ExchangeRate(18,6)`; migración `Inicial` aplicada (16 tablas); `DbSeeder` idempotente verificado: tenant Balam (GUID fijo), 4 roles, 5 usuarios ficticios `*@balam.dev` (password en user-secrets `Seed:DefaultPassword`).
+
+**Extra:** UI del OpenAPI con **Scalar** en `/scalar/v1` (solo Development). Estado verificado: API arriba con BD, 13/13 pruebas verdes, seed comprobado por consulta directa a Postgres. **Cambios sin commitear** en el repo del cliente — commit pendiente de Johann.
+
+**Efecto en la agenda:** el lunes 20 queda libre para gestión + arrancar B2 (auth JWT + roles + bitácora) directamente.
+
+---
+
+## 49 · Jul 19, 2026 — noche · Desarrollo · B2 completado (adelantado del lunes): auth JWT + policies + bitácora
+
+Continuación de la sesión nocturna asistida por IA (~0.5 h reales registradas en el CSV). Con esto el trabajo técnico planeado para el lunes 20 queda hecho; el lunes queda solo la gestión + arrancar B3 (sync de clientes).
+
+**B2 conforme al plan:** `POST /api/auth/login` (Identity + JWT propio, sin `MapIdentityApi`, sin refresh en E1) y `GET /api/auth/me`; `Jwt:SigningKey` en user-secrets con fail-fast; policies nombradas (`PuedeVerCartera`, `PuedeDispararSync`, `PuedeVerBitacora`, `PuedeOperarEscritura`) con matriz provisional hasta la sesión del 22-jul; roles como constantes (`BalamRoles`); bitácora en dos piezas — `AuditMiddleware` (mutantes + 401/403) e `IAuditLogger` explícito — y `GET /api/audit` (Direccion/Administracion). Decisión aplicada del plan: **BD obligatoria con fail-fast**.
+
+**Verificado end-to-end contra el API corriendo:** login fallido 401 (auditado una sola vez), login Finanzas 200 con token, `/me` 200, `/me` sin token 401, `/api/audit` con Finanzas 403 (auditado), con Dirección 200 mostrando toda la secuencia. 13/13 pruebas verdes.
+
+Repo del cliente: 3 commits locales (`5631f55` Scalar, `6264ea3` B0+B1, `4617070` B2) — **push pendiente por decisión de Johann** (no se hace push sin su orden explícita).
+
+---
+
+## 50 · Jul 19, 2026 — noche · Desarrollo · B3 completado: sync de clientes CONTRA PRODUCCIÓN + hallazgo de datos
+
+Cierre de la sesión nocturna (~0.5 h reales más). **Primer dato real de BIND viviendo en la plataforma:** 16 clientes sincronizados con detalle (días de crédito 0/30/45/60/90), checkpoint registrado y ciclo auditado en bitácora.
+
+**Hallazgo de producción:** hay clientes con `LocationID`/`LoctaionID` **null** — caso que la validación del 6-jul no encontró. Se hicieron nullable todos los GUIDs de referencia de los modelos BIND (commit `fb0f066`); los IDs propios siguen no-nulos. Vale mencionarlo a Pedro junto con las 5 preguntas técnicas.
+
+**B3 conforme al plan:** full-scan de lista + `SourceHash`, detalle solo nuevos/cambiados con tope por ciclo, normalización RFC/nombre, dedup por RFC exacto excluyendo genéricos — verificado en real: el único RFC repetido es `XEXX010101000` (2 clientes extranjeros) y quedó correctamente FUERA del dedup. Idempotencia comprobada: segundo run = 16 sin cambio, 1 sola petición. Consumo total del día: ~42 peticiones de 20,000.
+
+`POST /api/sync/run` (Finanzas/Administración; Operaciones→403 verificado) y `GET /api/sync/status`. 13/13 pruebas verdes. Repo: **5 commits locales, push pendiente por decisión de Johann.**
+
+**Estado de bloques al cierre del domingo: B0 ✅ · B1 ✅ · B2 ✅ · B3 ✅** — el lunes queda gestión + B4 (sync de facturas/cotizaciones + cartera, el bloque más grande) con margen de un día completo vs. el plan.
+
+---
+
+## 51 · Jul 21, 2026 · WhatsApp Erika ↔ Johann · estimación Jira→BIND comunicada (10 h) y alcance confirmado por Erika ⭐
+
+Erika pidió en la mañana la estimación del cambio nuevo "para tenerla a la mano" antes de su sesión con directores. Secuencia clave:
+
+1. **Johann comunicó: ~10 h de desarrollo, a confirmar el miércoles 22 en la sesión con Arturo** (primero cerrar reglas del flujo y validar la escritura de BIND). Quedó por escrito que "no estaba contemplado al inicio; es una mejora que surgió en el Discovery".
+2. Erika retó con la §1.4 de la propuesta ("¿no es esto lo de las cotizaciones?"). Aclaración que quedó asentada: **crear cotizaciones manualmente desde la plataforma SÍ está en el MVP** (capa de escritura); lo nuevo es que **los tickets de Jira las generen automáticamente**. Erika encontró ella misma la §1.3 donde Jira dice "Fuera de alcance" y lo confirmó con 👍. Erika lo valida internamente con los directores.
+3. Erika preguntó por 2 actividades vencidas en fechas del Excel (backend base y multi-tenant); Johann respondió "esas ya quedaron". Backend base ✅ real (B2); multi-tenant al ~80% — **hacer B6 (RLS real) de inmediato para que la afirmación quede cubierta.**
+4. **Nuevo compromiso:** compartir las horas semanalmente por Excel mientras Pedro habilita Jira, **con entregable + actividad + horas de cada etapa** (formato pedido por Erika, lunes de corte).
+
+---
+
+## 52 · Jul 21, 2026 — noche · Desarrollo · B4 completado: sync de facturas/cotizaciones + cartera por moneda + SYNC HISTÓRICO ⭐
+
+Sesión nocturna asistida por IA (~1 h real registrada en el CSV). **La plataforma ya tiene la cartera completa de producción viviendo en Postgres.**
+
+**B4 conforme al plan:** `InvoiceStatusMapper` como **función pura en Domain con 13 pruebas xUnit** (precedencia Cancelada→Pagada→Emitida→Vencida→Vigente; "hoy" en hora MX vía `MexicoTime`; la frontera Emitida/Vigente se ajusta en minutos si la sesión del 22 la cambia). `InvoiceSyncService` con ventana única (delta por `Date` + re-barrido de abiertas viejas, solape 1 día, cursor que solo avanza al completar la pasada) y `QuoteSyncService` con sonda del filtro `CreationDate` + fallback a full-scan. Detección de pagos ADR-004: transición → `InvoiceStatusChanges` con fecha de DETECCIÓN; **facturas nuevas NO generan transición** (el histórico fotografía, no detecta). Campo nuevo `DetailSyncedAtUtc` (migración `DetalleSyncPendiente`) para tope de detalle 50/ciclo + backfill B5. Endpoints: `GET /api/cartera` (por moneda, jamás suma monedas; primer uso de `PuedeVerCartera`), `GET /api/invoices|clients|quotes`. Normalización PPD/PUE desde la etiqueta larga de BIND.
+
+**Sync histórico corrido y verificado esta noche (jamás en demo):** 1,494 facturas y 43 cotizaciones, **detalle 1,494/1,494 (0 pendientes)**, idempotencia comprobada (2ª pasada = 100% sinCambio), `InvoiceStatusChanges` = 0 (cero pagos falsos), 24.5 min, ~1,700 peticiones (~8.5% de cuota; cierre del día ~1,750 de 20,000). **Cartera verificada BD ↔ endpoint exacto:** MXN 17 abiertas $1,568,772.32 · USD 92 abiertas $320,379.06.
+
+**Hallazgos de producción:** (1) el filtro `CreationDate` de Quotes SÍ funciona (pendiente §10 de VALIDACION-API resuelto de facto); (2) ⚠️ **las 1,374 facturas con método de pago traen PUE — ninguna PPD** (120 con el campo vacío). Todo el histórico se factura "pago en una sola exhibición" aunque cobran a crédito 30–90 días — preguntar a Arturo en la sesión del 22 (toca la regla PPD-default de la capa de escritura y el riesgo SAT que ellos mismos reportaron).
+
+Commit `2e1ae82`. 26/26 pruebas verdes. **7 commits locales, push pendiente por decisión de Johann.**
+
+---
+
+## 53 · Jul 21, 2026 — noche · Desarrollo · B6: RLS real de Postgres (contractual) — código completo; verificación local pendiente de rol de app
+
+Cierre de la sesión (~0.5 h real). **B6 conforme al plan:** `ITenantOwned` en las 8 entidades de negocio; `ICurrentTenantProvider` + `FixedTenantProvider` (ADR-005: tenant único); `TenantConnectionInterceptor` (`set_config('app.tenant_id',…)` en cada conexión, vías sync y async); filtros globales EF por entidad como segunda capa; migración `RlsPorTenant` a mano con `ENABLE/FORCE ROW LEVEL SECURITY` + política `tenant_isolation` (USING + WITH CHECK, fail-closed sin GUC) en las 8 tablas. Migración **aplicada** (catálogo confirma `relrowsecurity=t, relforcerowsecurity=t` en las 8); app end-to-end igual que antes (login, cartera, sync). Commit `fedb376`.
+
+**⚠️ Verificación de aislamiento local INCOMPLETA:** la prueba psql devolvió filas sin GUC y con tenant ajeno porque `balam` (usuario bootstrap del contenedor) es **superuser con BYPASSRLS** — FORCE somete al *owner*, pero ningún candado somete a un superuser. El fix (pendiente de decisión de Johann, quedó en PENDIENTES): crear rol local `balam_app` (LOGIN, NOSUPERUSER, NOBYPASSRLS), transferirle la propiedad y apuntar la cadena de conexión de desarrollo a ese rol — replica cómo será Azure, donde el usuario de la app tampoco es superuser. Las políticas en sí son correctas; el hueco es del entorno local, no del código.
+
+---
+
+## 54 · Jul 22, 2026 — 7:00 AM · Llamada · Sesión de reglas Etapa 1: alta de clientes, fee bancario y flujo Jira ⭐
+
+> Participan: Noe Rocha (sala de juntas), Arturo Rosas, Araceli (se suma ~min 21 para el tema del fee) y Johann. Erika no participó. Duración ~48 min. Transcripción: `../fuentes/2026-07-22 - Flujo para dar de alta clientes nuevos,_ Transcript.txt`. Agenda preparada en [`../planeacion/Sesion-Etapa1-2026-07-22.md`](../planeacion/Sesion-Etapa1-2026-07-22.md).
+
+**Resumen:** Se resolvieron 3 de los temas de la agenda: **alta de cliente/proveedor en BIND** (demostrada en pantalla por Arturo), **tratamiento del fee bancario** (lo registra el despacho, no Balam) y **flujo Jira de facturación** (estatus, validaciones y confirmación de que Jira ya es parte del proceso). Quedaron fuera: particularidades de envío, la pregunta PUE/PPD y el cierre técnico (repo/Azure/Jira horas).
+
+**1 · Alta de cliente/proveedor en BIND (ASIS, demostrado por Arturo):**
+- **Mismo procedimiento** para clientes (módulo Ventas→Clientes) y proveedores (Compras→Proveedores). Botón **Agregar** → 2 pestañas: **Detalle** y **Direcciones**.
+- **Detalle:** razón social, RFC, nombre comercial y categoría se toman de la **constancia de situación fiscal**; banco y CLABE del **estado de cuenta** del cliente. **Días y monto de crédito vienen de la negociación comercial** (no de un documento). Además: correo de comunicación, sucursal (solo existe matriz), teléfono, uso CFDI (mayoría "gastos en general", según constancia), régimen fiscal e **idioma de documentos** (p. ej. BICTEX → inglés). Clientes agregan: ventas esperadas, lista de precios, descuento pactado.
+- **Direcciones:** país/estado/municipio/calle/CP, también de la constancia. Al guardar, BIND asigna un **ID interno consecutivo** (ej. 1016), exclusivo de la instancia de Balam.
+- En **editar** se pueden adjuntar archivos: constancia, carátula bancaria, NDA, contrato marco — todo en un solo lugar.
+- **El alta nace del área comercial:** cuando una propuesta pasa a firme, administración da de alta al cliente. Caso reciente: **Frisa**.
+- **Extranjeros (ej. Acuntia):** documento legal/fiscal del país en lugar de constancia; BIND propone un **RFC genérico**; uso CFDI = **"sin efectos fiscales"**; la factura al extranjero genera **solo PDF, sin XML ni timbrado SAT** (se registra como gasto/ingreso extranjero sin obligaciones fiscales).
+- No se hizo alta en vivo (producción, sin datos de prueba). **Arturo se comprometió a grabar y documentar** los procesos nuevos conforme ocurran (Frisa está por facturarse; hará manuales Word/PowerPoint).
+
+**2 · Fee/comisión bancaria (con Araceli):**
+- El fee **NO lo registra Balam: lo registra y deduce contablemente el despacho**, para que la factura quede saldada al 100% sin residual de deuda del cliente. Balam solo concilia estado de cuenta ↔ facturas pagadas.
+- El fee **solo aplica a pagos internacionales que mueven dinero hacia México** (ej. Europa→Banorte; varía según banco emisor). Los **pagos nacionales cuadran a centavos**, sin fee. **BigTech** paga de banco americano a banco americano de Balam → sin fee.
+- El monto del fee **no es predecible** (no hay reglas conocidas), pero **siempre viene marcado en el estado de cuenta** ("comisión", "IVA sobre comisión"). Por eso es crítico **pedir el estado de cuenta al cliente** — además Accent/Axios tiene **muchas facturas por el mismo monto** y sin estado de cuenta no se sabe cuál pagaron.
+- **Regla para la plataforma:** el agente de conciliación solo debe **identificar la diferencia como fee bancario**; quién autoriza saldar la factura con diferencia es **el despacho**, a nivel contable. Hoy el caso vivo es Acuntia.
+
+**3 · Jira (flujo de facturación) — confirmado que SÍ entra en la fórmula:**
+- Noe reconoció explícitamente que el alcance inicial decía "sin Jira" pero **el proceso interno evolucionó y hoy todo pasa por Jira**; la integración se pone sobre la mesa como ajuste.
+- **Space "Facturación"** separado (hay otros: administración general, GEDEX, RH), con un solo request type hoy (facturación adicional/recurrente) — el universo de tickets de facturación está cerrado y filtrable.
+- **Flujo de estatus del ticket:** inicia → abierto → **proceso de facturación** (confirmar monto, cliente dado de alta, constancia vigente, cuenta bancaria) → **validación** (nacional: adjuntar **PDF + XML obligatorios**; internacional: **solo PDF**) → facturado → **resuelto**. El estatus que confirma facturación válida es **"resuelto"** (el anterior solo es validación en curso). Las validaciones nacieron de desaciertos operativos reales ("ya facturé" sin evidencia).
+- **Facturación recurrente:** ~30 facturas/mes salen de un flujo recurrente por contratos establecidos — es **proceso de Balam ejecutado en BIND**, no capacidad nativa de BIND, y siempre con intervención humana (los montos pueden variar mes a mes). **Pedirá sesión aparte con Pedro** para entenderlo.
+- **Forecast contractual a largo plazo:** BIND solo proyecta sobre lo ya facturado (por plazo de pago); Noe quisiera a futuro proyección por contrato — **explícitamente NO es para ahora**.
+
+**4 · Escritura en BIND / prueba Jira→cotización:** Johann planteó probar el flujo ticket Jira → cotización BIND (cotización→prefactura→factura). Noe accedió a explorarlo pero con advertencia fuerte: **no hay ambiente de pruebas, es producción directa** — "muy, muy medida la prueba… para no hacernos harakiri". La escritura será acordada y controlada llegado el momento.
+
+**Acuerdos / próximos pasos que anotó Noe:**
+- [ ] Balam (Arturo/Pedro) — **enviar a Johann el diagrama del flujo Jira** en tamaño legible (el screenshot se veía ilegible en la llamada).
+- [ ] Balam (Erika coordina) — **sesión con Pedro (+Arturo)** para: **API de Jira** (explorar conexión), facturación **recurrente** y facturas automáticas vs manuales.
+- Confirmado: **mañana jueves 23-jul, sesión de validación del prototipo**.
+
+> **Lectura estratégica:**
+> - **Jira→BIND avanza:** Noe aceptó en voz alta que Jira ya es parte del proceso y encaminó API + sesión con Pedro — coherente con la estimación de ~10 h comunicada a Erika el 21-jul ([#51](REGISTRO.md)). El disparador de facturación es el estatus **"resuelto"**; para crear cotizaciones el candidato natural es un estatus previo (a confirmar con Pedro en la sesión de API).
+> - **El fee simplifica el MVP de conciliación:** la plataforma NO registra ajustes contables — solo detecta y etiqueta la diferencia como fee bancario en pagos internacionales. El asiento es del despacho. Esto acota el alcance justo donde la agenda temía ambigüedad.
+> - **Alta de clientes:** quedó mapeado el ASIS completo, pero **no se decidió** si la plataforma solo detecta clientes faltantes o también los crea — la pregunta del MVP sigue abierta y toca la estimación Jira→BIND ([#51](REGISTRO.md)): un ticket de un cliente inexistente en BIND cruza ambas piezas.
+> - **No se tocaron:** la pregunta **PUE vs PPD** (1,374 facturas históricas todas PUE, [#52](REGISTRO.md)) — reintentarla el 23-jul o con Pedro—, las **particularidades de envío** (Excel sigue pendiente de Ara/Arturo) y el cierre técnico (Azure/Jira horas).
+> - **Factura extranjera sin XML** confirma el diseño del prototipo (PDF-only para internacionales) y explica por qué la validación de Jira solo exige PDF en ese ramal.
+
+---
+
+## 55 · Jul 24, 2026 — 11:00 AM · Llamada · Validación del prototipo Etapa 0 — APROBADO (queda 1 definición de proceso) ⭐
+
+> Participan: Erika Chávez (abre), Johann (presenta), Noe Rocha, Araceli Sánchez, Arturo Rosas. Duración ~1 h 4 min. La sesión estaba agendada para el **jueves 23-jul 7 am** pero se corrió al **viernes 24-jul 7 am** porque Araceli (dueña del proceso) tuvo un tema personal (reagenda documentada en [#57](REGISTRO.md)). Transcripción: `../fuentes/2026 - 07 - 24 - Validación de prototipo etapa 0- proyec_ Transcript.txt`. Guion usado: [`../planeacion/Guion-validacion-prototipo-2026-07-23.md`](../planeacion/Guion-validacion-prototipo-2026-07-23.md).
+
+**Veredicto: Etapa 0 validada.** Johann recorrió el PDF y luego el prototipo navegable (URL). Ara: *"Johann nos captó absolutamente todo lo indispensable y más… de momento no le pondría nada"*, *"Me encantó", "Sí a todo"*. Arturo: *"yo no le pondría nada más… esto es lo mínimo que necesitamos"*. Ambos aprobaron el MVP tal cual. **Queda pendiente UNA sola cosa del lado de Balam: redefinir el flujo de facturación en Jira** (ver abajo) antes de volver con Johann para hacer el MVP productivo. Erika confirmó que esto **no bloquea** a Johann, que ya está en Etapa 1.
+
+**El único bloqueo real — definición de proceso (no de sistema):** hoy el CIS de Jira exige que la factura se haga **antes** de cerrar el ticket, es decir el proceso de facturación ya no arrancaría desde el sistema. Hay que decidir si la ejecución (prefactura) se **dispara desde la plataforma** (lo deseable, para que el sistema optimice) o se sigue haciendo antes y solo se presenta al sistema. **Arturo pidió explícitamente que sea PREFACTURA, no timbrado automático:** validación previa (nacional vs extranjera, montos, datos fiscales) para evitar cancelaciones que el SAT observa; *"para ir monitoreando la eficiencia de la IA. Tal vez en algún futuro daremos independencia completa"*. **Ara sale de viaje mié/jue/vie; propuso el martes 28-jul para esa sesión; Erika coordina.** Es prerrequisito para que Johann conecte el frontend a la escritura.
+
+**Decisiones y aclaraciones que quedaron asentadas:**
+1. **Cotización SIEMPRE, sin excepciones (Ara).** Incluso las **recurrentes** (contrato AXIANS 3–4 años) deben nacer de una cotización → prefactura/factura. Es un punto de control para cazar cambios (sueldos, viáticos, ajustes) y errores. *"El esfuerzo es el mismo"*: la cotización vive en BIND y se convierte a prefactura/factura con un clic. Noe lo cerró como **3 candados: cotización → prefactura → aprobación humana → timbrado.**
+2. **Nada de agente de IA en este MVP** (Noe, muy vocal, lo repitió 3 veces): esto es **reglas de negocio + procesos + integración de sistemas** para homologar pantallas, no LLM. La IA llega después; el candidato claro para agente es **conciliación** (hoy 100% manual). Primero la base de proceso, *"si le metemos IA de inicio va a ser una fiesta"*. Johann alineado: el MVP asienta el proceso para montar los modelos encima.
+3. **Roles:** la plataforma ya los soporta; por ahora Ara y Arturo ven todo, se acotan cuando entre un analista.
+4. **Dashboard:** las 4 tarjetas son propuesta, todo customizable. *"Qué necesita atención"* se alimentaría de Jira + estatus de facturación. Posible acople con el Power BI de aging de Pedro (no duplicar reporteo).
+5. **Fuente única = BIND (Vine) o Jira.** No hay fuente alterna. Cartera vencida sale de BIND; lo que no esté en BIND requeriría carga/capa manual.
+6. **Un ticket = una factura (hoy).** Caso ACUNTIA/Accions: un solo ticket con un Excel de 40–48 facturas. Queda **abierto** si se maneja como ticket-por-factura o un ticket con múltiples hijos (definición de proceso, va con el punto del bloqueo).
+7. **Todo nace en Jira — política de empresa:** *"Lo que no está en JIRA no se procesa."* Ni correo ni mensaje; incluso los correos se reenvían a una dirección que auto-crea el ticket.
+8. **Envío con particularidades por cliente:** validado y les gustó (CEMEX bloqueado por faltar Excel de horas; ACUNTIA = zip con PDF+XML+estado de cuenta). El **módulo de configuración** de reglas de envío queda **cerrado/hardcodeado al inicio**; si cambian reglas, se cobra como horas de servicio. No se desarrolla ahora.
+9. **NAFINSA / cadenas productivas (solo CEMEX):** facturas ya *programadas para pago* (p. ej. cae 24-sep, 120 días) que **no existen como estatus en BIND**. Quieren una **capa/pantalla extra "programado para pago"** para planeación financiera (Arturo: *"la cerecita del pastel"*). Idea de Ara: **ticket Jira automático cada 15 días** para revisar el portal Nafinsa, adjuntar Excel/pantallazos y alimentar cuentas por cobrar, haciendo match por folio. A evaluar con Johann.
+10. **Fee:** tolerancia configurable por cliente (% o fijo); se muestra como *"pagada pero con tolerancia"*. (Consistente con [#54](REGISTRO.md): el asiento contable es del despacho, la plataforma solo detecta/etiqueta.)
+11. **Recordatorios internos en el MVP:** D+1 → Arturo, D+15 → Araceli. Los **correos al cliente (D+5, D+30) NO son alcance** ("no está definida la regla"). Excepciones de seguimiento por cliente contempladas.
+12. **Bitácora/auditoría:** *"Me encanta, sí a todo."*
+
+**Observaciones que anotó Noe sobre el prototipo:** (a) un ticket rotulado "facturación nacional" era extranjera → pedía XML+PDF cuando extranjera es solo PDF (ajuste menor); (b) los estatus del prototipo son placeholders previos a explorar Jira ("listo para facturar" ≈ "facturado" en Jira real) y se adaptarán al flujo que Balam defina.
+
+**Cierre y próximos pasos:**
+- Balam hace **teamback** para separar *must* vs *nice-to-have* y define el flujo de facturación/prefacturación (**sesión martes 28-jul, Erika coordina**).
+- Antes del **go-live** habrá una **prueba muy observada de prefacturación** (primera escritura real sobre BIND), paso a paso y validada.
+- **Sesión con Pedro para el API de Jira** queda encaminada (se materializó el 27-jul, [#56](REGISTRO.md)).
+- Johann: **montar el frontend**, conectarlo al backend ya construido (cliente BIND, auth, multi-tenant, BD) y hacer las pruebas.
+
+> **Lectura estratégica:**
+> - **Etapa 0 cerrada en la práctica** con validación entusiasta de los dueños del proceso (Ara y Arturo) y respaldo de Noe. El entregable de Etapa 0 quedó aprobado; el único hilo suelto es una **definición de proceso de Balam**, no una carencia del prototipo.
+> - **"Cotización siempre" es una decisión firme** que simplifica la capa de escritura (B7): un solo camino cotización→prefactura→aprobación→timbre, sin ramas de excepción para recurrentes. Elimina ambigüedad que la agenda temía.
+> - **PUE/PPD no se retomó** en esta sesión — sigue abierta desde [#52](REGISTRO.md) (1,374 facturas históricas todas PUE). Reintentarla con Arturo en la sesión del 28-jul o con el flujo Jira.
+> - **Dos capacidades nuevas asomaron fuera del MVP core:** "programado para pago"/planeación financiera (Nafinsa) y el espacio "comercial" en Jira para generar cotizaciones. Ambas son candidatas a ampliación (horas extra), útiles para el pipeline comercial, pero **no deben inflar el MVP** — es justo lo que Noe pidió filtrar con el teamback.
+> - **La prueba observada de prefacturación es el hito de riesgo** antes del go-live: es la primera escritura real sobre producción. Los candados acordados (dry-run, confirmación humana por factura, feature flag) son el seguro.
+
+---
+
+## 56 · Jul 27, 2026 — mañana · Llamada · Sesión API de Jira con Pedro: token comprometido y bandeja "Facturación" (FAC) identificada ⭐
+
+> Participan: Noe Rocha, Erika Chávez, Pedro Ayala (TI, dueño de Jira), Johann. Duración ~12 min. Transcripción: `../fuentes/2026-07-27 - API de conexión con JIRA Transcript.txt`. Es el Discovery de API que quedó encaminado el 22-jul ([#54](REGISTRO.md)) y ratificado el 24-jul ([#55](REGISTRO.md)).
+
+**Objetivo (Noe):** el Discovery mostró que buena parte del proceso de facturación llega por Jira, conectividad que originalmente no se contempló y que ahora **sí será necesaria**. Pedro explica cómo se conecta hoy vía API.
+
+**Lo que confirmó Pedro:**
+- Usa el API de Jira para varios tableros de TI (limpieza de usuarios, aprobadores, conectores, SLAs). Funciones: crear y consultar actividades/tickets, aprobaciones, documentos adjuntos, cambio de estatus. **Es de lectura Y escritura — todo accionable** ("cualquier creación que se haría manual se puede hacer por API"). Cubre el CRUD que Johann necesita.
+- **Token comprometido:** Pedro genera una API key llamada **"PAF" (Plataforma de Automatización Financiera)**, **expiración a 1 año — 27-jul-2027**. La envía **por correo en TXT** junto con la **documentación de desarrolladores de Atlassian** (informativa). Ya la tenía lista al cierre de la llamada.
+- **Límites de consumo:** a diferencia de BIND (20K/día), Pedro cree que Jira **no tiene tope por día**; lo investigará en Atlassian y lo revisa con Johann. Noe quiere saber el límite de transacciones por escritura/consulta para planear la operación.
+- Los tokens se generan desde la cuenta de Pedro, diferenciados por nombre; buena práctica rotarlos.
+
+**Identificación de dónde consultar (aclaración importante):** no es "tablero" (eso es Power BI) sino el **Space** de Jira. Los tickets de facturación viven en la bandeja/space **"Facturación", con llave `FAC-`** + número. Otras bandejas: Administración General (AG), ITS (DITCM), Recursos Humanos (RH), Facturación (FAC), HD. **El API es global** (extrae de todas), pero la que importa es **Facturación**, que funciona como **bandeja "padre"**: procesos que se cierran en RH o Administración General **caen en Facturación**. Este es el insumo que Johann pidió el 24-jul para saber de dónde extraer los tickets.
+
+**Próximos pasos acordados:**
+- **Pedro** → enviar por correo: token TXT (PAF) + documentación Atlassian; investigar límites de consumo. → **CUMPLIDO el mismo día (ver seguimiento).**
+- **Johann** → revisar la documentación de Jira/Atlassian; con la key, integrar la consulta al prototipo. Construir un **script de consulta** y también scripts de **creación/edición/eliminación** sobre un registro de prueba. Noe: no existe un CRUD previo por API; cuando llegue el momento se hace una **prueba en vivo** de creación. **Johann es el checkpoint** — avisa cuando necesite prueba o tenga dudas.
+
+**Seguimiento — correo de Pedro del mismo día (27-jul, 7:40 am; CC Noe y Erika):** `../fuentes/2026-07-27 - Correo - Pedro medicion de consumo API Jira y token.md`. Johann acusó recibo ("Enterado, muchas gracias Pedro! Saludos").
+- **No hay límite de volumen** ("X llamadas al mes") ni costo extra de licencia por usar la API. Hay **3 límites de velocidad en paralelo**, cualquiera devuelve **HTTP 429** (`RateLimit-Reason` indica cuál):
+  1. **Cuota por puntos/hora:** 1 punto base + 1 por objeto de dominio (issues, proyectos) o 2 por objeto de identidad (usuarios, grupos, roles); **las escrituras solo cobran el punto base**. Bolsa por defecto **65,000 puntos/hora**.
+  2. **Burst por segundo:** 100 req/s GET y POST, 50 PUT y DELETE, bucket por endpoint y por tenant. Consulta de clientes de service desk topada a **5/s**.
+  3. **Por issue en escrituras:** 20 ops/2 s y 100/30 s sobre un mismo ticket.
+- **No existe dashboard de consumo** (limitante de Atlassian): consola de desarrolladores solo muestra el tier de apps propias; el detalle por token exige **Atlassian Guard Premium** (licencia aparte); las apps de Marketplace estiman por muestreo. **Única fuente confiable = headers de respuesta:** `X-RateLimit-Limit/Remaining/NearLimit` (NearLimit se activa con <20% de capacidad) y en 429 además `X-RateLimit-Reset`, `Retry-After`, `RateLimit-Reason`.
+- **Token entregado** vía enlace de Google Drive (carpeta compartida). ⚠️ Tratar como credencial: mover a user-secrets/Key Vault, no dejar en texto plano.
+
+> **Lectura estratégica:**
+> - **Desbloqueo clave para B7/Jira→BIND:** con token de escritura a 1 año y la bandeja FAC identificada, se habilita tanto la lectura de tickets como la automatización Jira→cotización BIND estimada en ~10 h ([#51](REGISTRO.md)). El API confirmado como read+write despeja el mayor riesgo de la integración.
+> - **"Facturación como bandeja padre"** es un dato de arquitectura relevante: consultar solo FAC puede no bastar si el disparador nace en RH/AG y cae en FAC — validar en las pruebas si conviene escuchar la bandeja padre o rastrear los procesos origen.
+> - **Límite de consumo resuelto (correo 27-jul):** no hay tope mensual; 3 límites de velocidad (puntos 65k/h, burst/s, por-issue en escrituras) sin dashboard nativo → el sync debe **autorregularse leyendo los headers `X-RateLimit-*`** (pausar en NearLimit, respetar `Retry-After` en 429). **Las escrituras son baratas en puntos** (solo el base), lo que favorece la capa de escritura frente a las consultas de identidad (2 puntos c/u).
+> - **Pendiente de proceso aún abierto:** qué estatus de Jira dispara qué (facturación vs cotización) sigue amarrado a la definición del martes 28-jul ([#55](REGISTRO.md)) — la conectividad ya está, la regla de negocio no.
+
+---
+
+## 57 · Jul 21–27, 2026 · WhatsApp Erika ↔ Johann · coordinación de sesiones, envío del flujo de facturación y reagenda 23→24 jul
+
+> Hilo de coordinación que **complementa** la parte de fondo del 21-jul ([#51](REGISTRO.md)) y enlaza la sesión de reglas del 22-jul ([#54](REGISTRO.md)), la validación del 24-jul ([#55](REGISTRO.md)) y la sesión de API de Jira del 27-jul ([#56](REGISTRO.md)). Transcripción completa (con imágenes inferidas): `../fuentes/2026-07-21 a 2026-07-27 - WhatsApp - Erika coordinacion sesiones validacion y API Jira.md`.
+
+**21-jul (tarde):** Johann propuso compartir las horas por Excel mientras se habilita Jira; Erika pidió el formato **entregable + actividad + horas por etapa**. Erika cuestionó si lo de las cotizaciones ya estaba (📷 captura) → Johann aclaró que **crear cotizaciones sí está en el MVP** y que lo nuevo (Jira genere la cotización en BIND automáticamente) requeriría acceso técnico a Jira + escritura controlada en BIND. Erika confirmó por su cuenta que Jira dice **"fuera de alcance"**.
+
+**22-jul:** Erika se disculpó por **no asistir a la sesión de reglas** de esa mañana ([#54]; avisó a los ingenieros para que la tomaran igual). Preguntó **dos veces si se ajustará la propuesta** por el cambio de la integración Jira → **compromiso de Johann: enviar el conteo de horas + la propuesta ajustada "entre hoy y mañana" (para el 23-jul).** Erika propuso la **sesión de API de Jira** con Noe y Pedro y confirmó que **ya envió por correo el flujo de facturación de Jira** (2:26 pm).
+
+**23-jul (reagenda):** por un tema personal de **Araceli** (dueña del proceso), la **validación del prototipo** se movió de jueves 23-jul 7 am a **viernes 24-jul 7 am**. La **sesión de API de Jira** se movió de viernes 24-jul 7 am → 7 pm → finalmente **lunes 27-jul 7 am** por disponibilidad de Pedro. Erika preguntó si "esta actividad se acabó ayer" (📷 captura del plan) → Johann: sí, **falta la prueba de escritura en BIND** pero ya está.
+
+**24-jul:** intercambio de arranque; se conectan a la sesión de validación ([#55]).
+
+**27-jul (mañana):** Erika pidió **los avances de la Etapa 1**; Johann preguntó si **ya existe el Jira del proyecto** — justo antes de la sesión de API donde Pedro compromete el token PAF ([#56]).
+
+**Pendientes que deja el hilo:**
+- [ ] Johann — **enviar conteo de horas (Excel: entregable + actividad + horas por etapa) + propuesta ajustada** por la integración Jira→BIND. ⚠️ Comprometido para el 23-jul — **verificar si ya se envió.**
+- [ ] Johann — **entregar avances de Etapa 1** solicitados el 27-jul.
+- [ ] Conservar el **correo del flujo de facturación de Jira** (Erika, 22-jul) como evidencia/insumo.
+
+> **Nota de imágenes:** las capturas no vienen en el volcado; se infieren tres adjuntos por los deícticos ("esto", "esta actividad") — cotizaciones (21-jul 12:58), "fuera de alcance" (21-jul 1:03, confianza media) y actividad del plan (23-jul 11:29). Detalle en el archivo de `fuentes`.
+
+---
+
+## 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).
+
+**27-jul, mañana — avance de Etapa 1 entregado por mensaje:** Erika pidió los avances de Etapa 1 (📷 captura del plan, 7:11 am). Johann preguntó si ya existe **un Jira para el seguimiento de este proyecto** —es decir, dónde llevar sus actividades y horas, no la instancia a integrar— (7:14 am) → **respuesta de Erika (7:54 am): "aún estamos viendo lo de alguna licencia... pero estamos viendo una segunda opción y no Jira precisamente".** Johann ofreció trabajar en un Excel compartido; Erika contestó que le comentó a Pedro que **pudiera ser un Drive para subir la documentación, pero están en espera de la validación** (8:57 am).
+
+> ⚠️ **Precisión importante:** este intercambio es sobre la **herramienta de gestión del proyecto** (dónde se registran actividades y horas de Johann), NO sobre la integración técnica. El Jira a integrar es la **instancia productiva de TI que administra Pedro** —bandeja FAC, token PAF a 1 año, API read+write confirmada ([#56](REGISTRO.md))— y ese no está en duda. Consecuencia práctica: **mientras no haya herramienta de gestión, el Excel de horas de Johann ES el sistema de seguimiento del proyecto**, lo que explica la insistencia de Erika en el desglose por etapa.
+
+Johann envió el **avance por actividad en texto** (8:12 am), con 👍 de Erika y "gracias" (8:58 am):
+> ✅ Sincronización de clientes — hecho y verificado · ✅ Sincronización de facturas/cotizaciones — hecho, 1,494 facturas cuadran · ✅ Modelo + migraciones + datos de prueba — hecho · ⏸️ Capa de escritura — en la junta del viernes comentaron que iban a definir el flujo de facturación; en cuanto quede, la implemento (Balam) · ⏳ Config. Azure (+ staging) — espera el acceso a Azure de Pedro/Noé (Balam) · ⏳ CI/CD + secretos — depende de Azure (Balam)
+
+**27-jul, tarde — la fila de escritura y la sesión del proceso:** Erika preguntó (3:35 pm) si la capa de escritura *"es la que está pendiente de lo que se mencionó el viernes de que validarían el flujo"* → Johann confirmó. Erika: **"es que lo tengo al 100%"** (3:40 pm) → **Johann corrigió: "lo volví a marcar como pendiente porque se iba a validar el proceso"** y preguntó cuándo podrían tener la junta revisando el proceso validado (3:44–3:45 pm). Erika: le comentó a Arturo, y como **Ara sale de viaje**, mañana en la oficina ve cuándo **revisarlo internamente y después pasarlo con Johann**; queda en avisar (3:49 pm). ⚠️ **La sesión del 28-jul no quedó confirmada — se movió a revisión interna de Balam primero.**
+
+**27-jul, 4:59 pm — pedido formal de horas:** *"johan un favor, me puedes pasar en un excel tus horas que llevas de cada etapa por favor"* → **Johann envió `Avance-Balam-2026-07-27.xlsx` a las 6:45 pm** (versión simplificada). Johann ofreció además pasar un Excel para las siguientes etapas; Erika (7:57 pm): *"Y las ya completas más que nada para ver cuántas son"*.
+
+**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).
+
+**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.
+> - **Erika creía la capa de escritura al 100%** y Johann la corrigió a pendiente. Buena decisión: si se hubiera dejado al 100%, la definición del proceso habría reabierto una actividad cerrada. Valida el criterio de reportar 40% y no más.
+> - **Sin herramienta de gestión para el proyecto** (licencia en revisión; Erika evalúa una alternativa a Jira para ese fin). **No afecta la integración técnica** —esa va contra la instancia de TI de Pedro, ya disponible—, pero sí significa que **el Excel de horas de Johann es el registro oficial de seguimiento** y el insumo de facturación. Mantenerlo trazable y al día no es opcional.
+> - **La propuesta ajustada por Jira sigue sin enviarse** (comprometida el 22-jul, re-preguntada el 28-jul). Es el pendiente comercial más viejo del hilo y ahora Erika lo pide por segunda vez.
+> - **La sesión del flujo de facturación no está agendada:** Balam la revisa internamente primero (Ara de viaje). El desbloqueo de B7 se corre de fecha.
+
+**Pendientes que deja el hilo:**
+- [ ] ⚠️🔥 Johann — **enviar la propuesta/adenda ajustada por la integración Jira→BIND** (comprometida 22-jul, re-preguntada 28-jul 9:12 am). Estimación ya comunicada: ~10 h ([#51](REGISTRO.md)).
+- [ ] Johann — **enviar el Excel de horas de las etapas siguientes** (2, 3) que Erika pidió el 27-jul 6:46 pm ("las ya completas más que nada para ver cuántas son").
+- [ ] Balam/Erika — **avisar fecha de la sesión del flujo de facturación** tras su revisión interna. Desbloquea B7.
+- [ ] Balam/Erika — **definir la herramienta de gestión del proyecto** (licencia en revisión). Mientras no exista, el Excel de Johann es el registro oficial.
+- [ ] Balam/Pedro/Noé — **entregar el acceso a Azure**; Erika iba a preguntar (28-jul 11:01 am). Johann pidió el contexto de lo que se requiere.
+
+---
+
+## 59 · Jul 30 – Ago 10, 2026 · Correo · Balam define el flujo Jira→BIND: disparador, campos y prueba acompañada ⭐🔥
+
+> 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)).
+
+**Cronología (8 días de latencia):**
+
+| Fecha | Movimiento |
+|---|---|
+| 30-jul 10:28–11:44 am | Pedro confirma su correo, **regenera el token** y comparte la URL `https://balam-jsm-temp.atlassian.net`. Cierra el 401 del 29-jul. |
+| 30-jul 1:07 pm | **Johann pregunta las 4 definiciones** (disparador, alcance de request types, fuente de monto/conceptos, y FACTEST vs prueba acompañada) + reporta el hallazgo de que el monto no está en campos estructurados. |
+| 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. |
+
+**Las 4 definiciones, cerradas:**
+
+1. ⭐ **La cotización BIND se genera al entrar a `En proceso de facturación`.** Y: *"por el momento todo se tramitará como facturación normal, hasta el explorar el módulo de proyectos en BIND"* → **el caso de facturación recurrente queda fuera de alcance por ahora.**
+2. ⭐ **Se observan TODOS los request types** de la bandeja de facturación, no solo `Facturación adicional`.
+3. ⭐ **Monto y conceptos van como campos de Jira**, no del adjunto. Noé: *"resta rapidez, pero garantiza consistencia de datos"*. Arturo: *"de acuerdo, deben ser los campos de JIRA (omitir el campo recurrencia)"*.
+4. ⭐ **No habrá proyecto `FACTEST`:** *"Preferimos una prueba acompañada sobre un ticket"* (Noé).
+
+**Verificación por API el 10-ago (solo lectura; detalle en `../planeacion/Investigacion-API-Jira.md`):**
+
+- ✅ **El acuerdo ya está implementado en Jira:** `Monto sin IVA` existe como `customfield_11556` (number/float, obligatorio) en el request type 83. Desapareció `Periodo de Incidencias`.
+- 🔴 **Pero solo 2 de 69 tickets lo tienen poblado** — `FAC-100` y `FAC-101`, ambos creados el **4-ago**, el mismo día de la respuesta de Arturo. Sin histórico contra el cual validar el mapeo.
+- 🔴 **`conceptos`/partidas NO existe como campo en todo el sitio.** El catálogo completo solo tiene `Monto sin IVA` (11556), `Monto con IVA` (11522, sin usar en el formulario) y `Total forms` (de JSM). **El acuerdo resolvió el monto pero no los conceptos.**
+- 🔴 **"Todos los request types" incluye tickets sin request type:** el filtro de la bandeja muestra 6 opciones (las 4 del portal + `Empty` + `Emailed request`). **10 de 69 tickets no tienen request type ni un solo campo estructurado**; nacen de `Automation for Jira` desde HH/SA/IN/RH, con los datos codificados en el `summary`. **No son ruido:** `FAC-91` es uno de ellos y está vivo en `En validación nacional` (`[FACTURA COMPLETA - Staff Augmentation] Axians — RH-36`).
+- 🔴 **El estatus disparador dura minutos.** `FAC-100` estuvo **2m44s** en `En proceso de facturación` (11:51:25 → 11:54:09 del 5-ago) y 25 min de punta a punta. Solo 1 de 69 tickets está parado ahí hoy. **Un poller que consulte el estatus actual se pierde la mayoría de los disparos → la detección por changelog pasa de preferencia a requisito.**
+- ⭐ **Hallazgo nuevo: el workflow tiene aprobaciones de JSM**, con **Araceli Sánchez** como aprobadora en las ramas de validación nacional/extranjera (`customfield_10003`/`10025`). El paso a `Facturado` es una aprobación formal, no una transición simple. La plataforma no debe aprobar nunca.
+- ✅ `FAC-100` cierra con `status = Facturado` **y** `resolution = Done` consistentes (resuelve la trampa documentada el 30-jul).
+- ✅ Headers de rate limit confirmados: `X-RateLimit-Limit: 350`, `X-RateLimit-Remaining: 348`, más los estándar `RateLimit-Policy`/`RateLimit`. **El límite observado es 350, no los 100/s que mencionó Pedro** → leer el header, no hardcodear.
+- ✅ El origen es **creación por Automation, no move entre proyectos**: sin cambios de `project`/`key` en los changelogs, con `issuelinks` al ticket origen. **Escuchar FAC basta.**
+- ⚠️ `Facturación recurrente` sigue siendo obligatorio y se está llenando (`FAC-100`: `Si`, periodo `12`) pese al acuerdo de omitirlo.
+- ⚠️ `Nombre del Cliente` es **ADF**, no string, y **no trae RFC** — la llave de match contra BIND queda en el nombre escrito a mano.
+- ⚠️ **ACUNTIA ya tiene caso real:** `FAC-100` es `Julio/CONSULTORIA Y SERVICIOS (Eduardo Fiallo CEMEXUSA)/ACUNTIA`, `Helmstone`, USD, 45 días, **un solo `Monto sin IVA` de 7,594.00** — para el ticket que históricamente representa 40–48 facturas ([#55](REGISTRO.md) punto 6).
+
+> **Lectura estratégica:**
+> - **B7 queda desbloqueado en su mayor parte.** El disparador está definido y el campo de monto ya existe: se puede implementar lectura, detección por changelog, parser de ADF y mapeo. **Lo único que sigue bloqueado es el armado final de la cotización**, por la definición de conceptos.
+> - **El acuerdo del 4-ago resolvió el monto y olvidó los conceptos.** Es el hueco más caro del hilo: sin partidas, la cotización BIND sale de una sola línea. Puede ser aceptable, pero tiene que ser una decisión explícita de Balam, no un default silencioso.
+> - **"Todos los request types" no es implementable literalmente.** ~14% de los tickets no tiene datos con los que armar nada. Hay que acotar el alcance por escrito o pedir que la regla de Automation propague los campos — y eso es trabajo de Balam.
+> - **Sin `FACTEST`, el sandbox propio deja de ser opcional.** Se escribirá en producción una sola vez, acompañado; todo el desarrollo previo tiene que ocurrir en un sitio Jira Cloud gratuito propio.
+> - **8 días de latencia en la definición**, con el agravante de que la pregunta se hizo el 30-jul y el escalamiento interno no arrancó hasta el 3-ago. Suma al patrón ya documentado: la definición del flujo lleva bloqueando desde el 24-jul.
+> - **Araceli entra al hilo como aprobadora**, tanto en el correo como en el workflow de Jira. Es un interlocutor nuevo para las definiciones que faltan.
+> - **PUE/PPD gana evidencia:** hay tickets `Seguimiento del Ticket con pago anticipado:`, lo que sugiere casos PUE reales y refuerza la pregunta que lleva cuatro sesiones sin hacerse ([#52](REGISTRO.md)).
+
+**Respuesta de Johann — ENVIADA el 10-ago, tarde.** Texto completo y borradores previos en `../planeacion/Correo-respuesta-Noe-2026-08-10.md`:
+
+> Buenas tardes, espero se encuentren bien.
+> Gracias por las definiciones, quedan claras y ya retomé el desarrollo, ya validé que el campo "Monto sin IVA" está creado y funcionando.
+> Para aterrizar los detalles que faltan sería de ayuda que hoy o mañana se cree un ticket de ejemplo capturado "como debería ser", con todos los campos llenos tal como quieren que se capture de aquí en adelante. Contra ese molde llego a la sesión con el flujo ya funcionando.
+> Para la sesión, ¿les funciona el miércoles 12 o el jueves 13, a las 7:00 am?
+> El ejercicio termina en la cotización en BIND.
+> Sigo pendiente del acceso a Azure para publicar el ambiente.
+> Quedo atento. Saludos.
+
+**Decisión de enfoque:** en lugar de resolver los tres huecos con otra ronda de correos, se pide **un ticket de ejemplo capturado "como debería ser"**. Balam ya está adoptando el llenado completo de campos, así que el molde resuelve por evidencia lo que la prosa tardaría dos semanas en definir, y permite preparar el script contra datos reales para llegar a la sesión con el flujo funcionando.
+
+**La tarea se dejó deliberadamente sin asignar** ("sería de ayuda que se cree"), para que Balam la ruteé internamente: Arturo no estaba en el CC del correo de Noé, y Noé ya venía haciendo ese papel de router desde el escalamiento del 3-ago. Nombrar a un ausente habría sido peor que dejarlo abierto.
+
+**Alcance del ejercicio fijado: termina en la COTIZACIÓN, no en la prefactura.** Razones: 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 el 24-jul; y una cotización se cancela sin efecto fiscal, mientras que en BIND la prefactura es un registro en `Invoices` con `UUID = null` y los shapes de los POST nunca se han probado. Respeta los tres candados de Noé: **cotización → prefactura → aprobación humana → timbrado** ([#55](REGISTRO.md)).
+
+**Lo que el correo final dejó fuera y ahora se resuelve verbalmente en la sesión** (sin constancia escrita previa):
+- Que el ejercicio **genera una cotización real en BIND producción** y que se cancela al terminar. **Anunciarlo al abrir la sesión, antes de ejecutar.**
+- El compromiso de **compartir el script antes** (condición de Noé del 24-jul). Mandarlo por separado cuando esté listo.
+- Que el **disparo es manual** en esta prueba (pipeline `Draft→DryRun→Confirmed` de ADR-001 con flags apagados) y que la versión automática **depende de Azure**.
+- **ACUNTIA** y el **supuesto de los tickets de `Automation for Jira`**.
+
+**Pendientes que deja el hilo:**
+- [x] ~~🔥 Johann — **responder el correo**~~ → **Enviado el 10-ago** (texto arriba).
+- [ ] 🔴 Balam/Arturo — **definir de dónde salen los conceptos/partidas** de la cotización.
+- [ ] 🔴 Balam/Arturo — **decidir qué pasa con los tickets creados por Automation** (10 de 69, sin campos).
+- [ ] 🔴 Balam/Arturo — **confirmar si ACUNTIA es un ticket → una cotización** o sigue siendo 40–48 facturas.
+- [ ] Balam/Noé — **fecha para la prueba acompañada** de escritura.
+- [ ] Balam — **¿nacional vs extranjero cambia la cotización** o solo el paquete de salida?
+- [ ] Balam/Pedro — **cuenta de servicio** en vez de la cuenta personal de Pedro (planteado el 29-jul, sin respuesta).
+- [ ] Johann — **levantar el sandbox Jira Cloud propio** (plan Free) para desarrollar sin tocar producción.
+- [ ] Johann — mover el token de Jira a **user-secrets/Key Vault** y borrarlo de disco (ya está gitignoreado).
+
+---
+
 ## Resumen ejecutivo del hilo (para contexto rápido)
 
 ### Datos duros confirmados por Balam

fuentes/2026 - 07 - 24 - Validación de prototipo etapa 0- proyec_ Transcript.txt

@@ -0,0 +1,506 @@
+Validación de prototipo etapa 0- proyecto integración IA Balam
+Fri, Jul 24, 2026
+
+10:44 - Arturo Rosas Hernandez
+Está tranquila, pero constante.
+
+10:46 - Arturo Rosas Hernandez
+No ha dejado de llover. No sé, por allá. Por aquí sí está. Mucho, mucho, mucha agua. Pero de a poquito. ¿Qué tal, Araceli?
+
+10:57 - Unidentified Speaker
+Buenos días.
+
+10:58 - Unidentified Speaker
+¿Cómo estás?
+
+10:59 - Unidentified Speaker
+Buenos días, Karol.
+
+11:01 - Unidentified Speaker
+Buenos días.
+
+11:02 - Araceli Sanchez Jimenez
+Ya, ya sé.
+
+11:03 - Araceli Sanchez Jimenez
+Buenos días.
+
+11:04 - Araceli Sanchez Jimenez
+Oigan, Noe. Ah, ya está. Bueno. Listo. Ya estamos todos listos. ¿Listo?
+
+11:10 - Erika Chavez
+Bueno, este, esta sesión es para ver lo de la validación de la etapa cero, que es el prototipo navegable que aquí mi compañero Johann realizó.
+
+11:24 - Johann
+Entonces, el foro es todo, Johann, adelante. De acuerdo, voy a compartir pantalla y voy a presentar el prototipo. Cualquier duda me pueden preguntar. Gracias. Aquí pueden ver mi pantalla.
+
+11:40 - Unidentified Speaker
+Sí, ya.
+
+11:41 - Johann
+Ok, les voy a presentar el PDF que les compartí, en donde hay capturas del prototipo y una pequeña descripción. Voy a ir explicando cómo es cada pantalla y el proceso que se reflejó en este prototipo. Entonces, este proceso consta de cinco pasos en cuanto a la facturación. Todo comienza en una solicitud en Jira. Después de la solicitud en Jira, se pasa a una cotización en Bind, pasa a prefactura y, antes del CFDI y la facturación, necesita una aprobación humana. Hay algunas reglas que se levantaron durante el Discovery, durante las sesiones, como, por ejemplo, el PPD por defecto, y PUE solo consciente. También la regla prefactura que siempre va a estar antes de timbrar, el IVA de 16% nacional, la cotización al principio de manera obligatoria y un recordatorio interno de monosías de los clientes. Esto es para el proceso de facturación.
+
+12:54 - Noe Rocha
+Estamos hablando del proceso de facturación, el primero que se está abordando como parte de la automatización que se está buscándose las diferentes fuentes de información en un punto único de ejecución.
+
+13:12 - Unidentified Speaker
+Así es.
+
+13:13 - Johann
+Comenzamos por esa pantalla que es la de iniciación. De esta manera, cada persona logueada verá las facturas que le corresponden y podrá ver todo lo relacionado a su cuenta.
+
+13:30 - Araceli Sanchez Jimenez
+Aquí ya tengo una pregunta. Aquí en el inicio de sesión, me imagino que hay un solo usuario. O sea, todos vamos a tener, bueno, o los que demos acceso aquí, vamos a ser administradores, ¿no? O sea, no va a haber privilegios. Es nada más, o sea, yo tengo y si yo entro o Juanito o Pedrito, vamos a ver absolutamente todos lo mismo.
+
+13:57 - Johann
+Aquí, por ejemplo, como a ustedes les convenga más, necesitan que un usuario tenga más acceso que otro, ya está preparada la plataforma para los roles. Ah, super. OK. Perfecto. Muchas gracias, Johann.
+
+14:09 - Araceli Sanchez Jimenez
+O sea, de momento, como somos nada más dos personas que llevamos todo este tema, digo, podemos ver todo. Pero yo nada más viendo a lo mejor en algún momento que a lo mejor tengamos un analista que vea cierto punto, pues no necesita ver todo lo demás, ¿verdad? Es nada más un tema de cultura general para saber qué Ahora comenzamos con este apartado del dashboard, en donde se muestran estos cuatro valores en forma de cartas y que se necesita atención.
+
+14:42 - Johann
+Entonces, en esta pantalla se busca que estén a la mano los datos, el resumen de los datos de las facturas y la cartilla de datos. Como por ejemplo, facturado en julio en pesos mexicanos y dólares, cuántas facturas emitidas hay y cuántas pendientes, cuánto, qué cantidad hay en cartera vencida. También aquí hay algunos ítems de qué se necesita atención y qué responsable hay y cuánto tiempo tiene de antigüedad. Además, aquí debajo se muestra en forma de dashboard, la facturación mensual en forma de gráfico de barras y facturas por cliente de mayor a menor. De esta manera se puede ver un resumen de los datos de forma resumida. Aquí habría que validar qué datos ustedes quieren ver. Esta es una propuesta de cómo se vería y algunos datos que podrían interesar. Pero ustedes me comentan qué datos son los que hoy día quieren ver, porque entiendo que también bien comentado que ya tenían un dashboard en Power BI con Pedro, entonces de pronto pudiéramos ahí acoplarlo en esta parte.
+
+16:02 - Johann
+Oye Johann, una pregunta.
+
+16:03 - Araceli Sanchez Jimenez
+Aquí en los datos que pones, ¿qué necesita atención? ¿Estos los jalaste de Jira? ¿Serían los tickets que los jalas de Jira? ¿O cómo determinas o sacas esta información? Sí, podría.
+
+16:16 - Johann
+Jira y el estatus del estado de facturación podría ser un criterio para mostrarlos aquí Ya.
+
+16:22 - Unidentified Speaker
+Ya, ok, ok, ok.
+
+16:24 - Araceli Sanchez Jimenez
+Y realmente, como tú dices, esto es customizable, ¿no? O sea, nosotros lo podemos decir, oye, Johann, esta información ponla aquí, por ahí, digo, ok, perfecto. Sí, justamente. Pero de entrada, en la propuesta, tú propones mostrarlo así. Así es.
+
+16:41 - Johann
+Si ustedes me comentan, de pronto, que estos datos no son los que les interesa ver y ocupan otros, o visualizarlos de otra manera, y lo acomodamos. Mi propuesta es ver en esa pantalla de Dashboard un resumen de los datos que ustedes quieran ver. Pero sí, como me comentas, cualquier detalle a cambiar lo ajustamos sin problema.
+
+17:05 - Araceli Sanchez Jimenez
+Oye, a lo mejor me estoy adelantando, pero, por ejemplo, aquí en el tema de la cartera vencida, en este tema nosotros tendremos que alimentarlo manual, o sea, bajar todos los estados se cuenta de VanNorte de manera diaria o cómo está alimentado?
+
+17:25 - Johann
+Si no está en Bind, ahorita mismo se puede sincronizar desde Bind, pero si no se puede sincronizar desde Bind, sí tendría que hacerse una carga al sistema.
+
+17:41 - Noe Rocha
+O sea, en este momento La cartera vencida es lo que informe Bind. Sí. Específicamente la fuente de información de esto es o es Bind o es Jira. No hay una fuente alterna.
+
+18:00 - Araceli Sanchez Jimenez
+Así es. Perfecto. Ya, ya entiendo. Ok.
+
+18:04 - Unidentified Speaker
+Gracias.
+
+18:04 - Unidentified Speaker
+Excelente.
+
+18:05 - Johann
+Después del Dashboard pasamos a esta pantalla de facturación. Aquí estamos en el módulo de facturación. Aquí venían las solicitudes de facturación que vienen desde Jira. Aquí cada registro corresponde a un ticket levantado en Jira, en donde mostramos la información y el estatus que hay en Jira. Y ahora, de esta manera, se pueden ver todos los tickets de Jira en un solo lugar, que es aquí en la plataforma. Y poder llevar el seguimiento desde aquí.
+
+18:44 - Araceli Sanchez Jimenez
+Oh, wow.
+
+18:45 - Noe Rocha
+Además aclarando que los status son status, no como aparecen actualmente en Jira, porque este prototipo fue antes de explorar los flujos de Jira. Porque, por ejemplo, ese status que dice listo para facturar en Jira es facturado, si mal no recuerdo. Nada más para hacer la observación, pero como prototipo, Esto es una propuesta y se va a adaptar a los flujos que nosotros definamos.
+
+19:15 - Johann
+Sí, justamente. Muchas gracias, Noe. Así es. Aquí en estatus iría reflejado el proceso que ustedes ya llevan.
+
+19:23 - Araceli Sanchez Jimenez
+Ok. Perfecto. De acuerdo.
+
+19:25 - Johann
+Entonces, aquí... Aquí a la derecha hay un botón de ver detalle. Y cuando se le da click, podemos nosotros ver de este ticket, así como se lleva algunos archivos adjuntos. Y desde aquí se va a poder iniciar la facturación. Y ahora, en esta parte, es en donde también necesitaremos ver el API key de Jira y toda esa parte para comenzar a sincronizar las facturas. Y ahora, cuando se tiene esta parte, y cuando ya se revisó el ticket de Jira, ahora sí, aquí también podemos ver este ticket desde Jira, si se quiere ver desde la plataforma de Jira. Y desde aquí tenemos la oportunidad de comenzar la facturación.
+
+20:23 - Araceli Sanchez Jimenez
+Yo aquí tengo una pregunta, es como de funcionamiento. Normalmente, o sea, levantamos un ticket en es Jira, un ticket por factura, no? Pero, por ejemplo, en el caso de Accions es un ticket y ese contiene un Excel y ese Excel tiene N cantidad. O sea, ese Excel puede tener un varia el número, pero 40, 45, 48 facturas. Pero no abrimos un ticket por las por Entonces, ¿tendría la guía la habilidad de decir OK, es un ticket, leer el archivo en Excel y decir OK? Entonces, ¿va a ser una factura por cada columna que haga?
+
+21:05 - Johann
+No, ahora mismo sería una factura por ticket.
+
+21:09 - Araceli Sanchez Jimenez
+OK.
+
+21:09 - Noe Rocha1
+Ahora mismo, a ver, ahora mismo, ¿cómo está el proceso, verdad? ¿Hay ciertos asegúnes que habría que ver cómo los vamos a manejar? Por ejemplo ese particular, en donde es un solo ticket con múltiples facturas. Entonces tendría que evaluar cómo hacerlo, si lo vamos a llevar a ticket por factura o un ticket con múltiples facturas, con múltiples hijos. Pero aquí por ejemplo hay un tema que me gustaría platicar con ustedes, porque el proceso como se definió Arturo y Araceli es que cuando Pone el proceso de GIRA para facturar como está en la CIS. La CIS de hoy es que la factura debe hacerse antes de que se cierre el ticket. Por lo tanto, no iniciaría el proceso de facturación desde el sistema, sino que desde antes se tiene que estar haciendo.
+
+22:06 - Araceli Sanchez Jimenez
+¿Sí me explicó? No. A ver, más lento.
+
+22:09 - Noe Rocha
+A ver un ejemplo. Arturo tiene un proceso de facturación. Ábrete, GIRA, por favor, para ver tus casos. Vamos a pasarlo muy bien. Gráfico. Voy a quitar la pantalla aquí tantito, Johann, Arturo. Entonces, por ejemplo, Arturo recibe un ticket. Ahorita vamos a ver el flujo. ¿Sí? Beta facturación, Arturo. Y esto sí tendríamos que definirlo, ¿verdad? Porque es una definición de proceso, no es una definición del sistema.
+
+22:39 - Araceli Sanchez Jimenez
+Ah, mira, justo esta es la que te digo. Tenemos la factura es un solo ticket, pero si tú le das clic son múltiples facturas.
+
+22:50 - Noe Rocha
+No, es que ahí yo veo un error porque dice facturación nacional y es extranjera.
+
+22:57 - Unidentified Speaker
+Ah, invalidación nacional.
+
+22:58 - Noe Rocha
+Entonces te va a pedir el xml y el pdf cuando solamente es el pdf. Bueno, independientemente de eso voy al punto que quiero explicar. Vámonos a cualquier flujo de facturación. ¿Facturación, Arturo?
+
+23:12 - Unidentified Speaker
+Dale clic donde dice facturado y dale ver flujo.
+
+23:17 - Noe Rocha
+Muy bien, y dale si quieres un zoom. Lo vamos recorriendo hacia arriba. Aquí me va a tratar de explicar gráficamente, a ver si me va a entender. Primero, se genera el ticket para la facturación. Por cualquier área que necesite un proceso o por un proceso ya automatizado de facturación, como son las recurrencias. Segundo, se pasa a un estatus de abierto. Después de eso se va al proceso de facturación. ¿Qué quiere decir esto? Que aquí en esta parte, en este proceso de facturación, ya se fue a Bain a hacer la factura. ¿Se explicó? Entonces, Si nos devolvemos a la pantalla de Johann, Johann tiene desde ahí que se haga la facturación.
+
+24:13 - Araceli Sanchez Jimenez
+Entonces... Oye, yo tengo una duda, porque por ejemplo en Vine hay una diferencia entre prefactura y factura. Entonces, en este caso, ¿es ya la factura en sí o es una prefactura? La diferencia es que no está timbrada. O sea, generalmente nosotros hacemos prefacturas para darle un doble Y ya una vez que le dijimos que sí, entonces ya la timbramos con el SAT. Aquí, en el proceso que ustedes están considerando en proceso de facturación, ¿ahí es ya facturarla, ya timbrarla?
+
+24:44 - Noe Rocha
+No, porque este proceso es lo que se va a definir con las reglas de negocio nuevas que vamos a hablar, que es el propósito de esto, ¿no? Es decir, ¿cómo la vamos a hacer? Porque si antes dijimos que el proceso de facturación de Jira era, aquí ya tengo que tener la facturación, entonces vamos a tener que hacer un ajuste. O lo hacemos aquí y luego se lo presentamos al sistema, lo cual no sería lo práctico porque la intención del sistema es que el sistema nos ayude a optimizar, a hacer las cosas, ¿no? O definimos que en esta parte del proceso de facturación sea donde se dispare esa ejecución ahora sí. En la pantalla de Johann. ¿Sí me explicó? No sé si me estoy explicando.
+
+25:32 - Arturo Rosas Hernandez
+Sí, sí, sí, estoy de acuerdo.
+
+25:35 - Arturo Rosas Hernandez
+Nada más que sí es muy importante. Bueno, como dices, ahorita lo estamos definiendo. Sí, sería muy importante que sea prefactura. ¿Para qué? Justo, justo, justo para continuar con este flujo, que es bueno en proceso de facturación. Sabemos que inicia en Bind, pero debe haber una validación de justo de lo que acabas de ver, no de que sí nacional y a lo mejor la generó extranjera o es extranjera y la genera nacional y después pues hacer una validación nacional extranjera y y revisar no revisar que los datos sean correctos que no haya ninguna inconsistencia de que los los el tema fiscal esté registrado correctamente los montos las descripciones etcétera sean todas correctas entonces pero sí que hay una validación previa y que no caigamos en incumplimiento porque se supone cuando generas demasiadas facturas y cancelas demasiadas facturas, también puede ser observado por el SAT. Entonces, evitar en la medida de lo posible la cancelación de facturas como tal. Por eso es necesario que lo que haga la herramienta sea para facturas, para poder revisar. Tal vez en algún futuro ya daremos independencia completa y pediremos que facture directamente. Pero por ahora, para ir monitoreando el uso o la eficiencia de la IA, si tendría que ser ProFacture.
+
+26:57 - Noe Rocha
+Es que recordemos algo, este flujo de Jira, no me quiero atorar mucho aquí porque hay más pantallas que explorar, pero sí tenemos que volvernos a Arturo y a Araceli para redefinir cómo va a quedar este flujo, porque dependiendo de cómo quede este flujo es cómo vamos a ejecutar en el modelo que Johann nos está poniendo sobre la mesa, pero no es algo ni que Johann ni mío que definimos es cómo el proceso lo vamos a definir para el uso dentro del área de facturación.
+
+27:30 - Araceli Sanchez Jimenez
+Ok, entonces si quieres lo dejemos pendiente y si quieres nada más, ya que Erika nos ayudé a coordinarlo, yo salgo de viaje otra vez el miércoles jueves y viernes no voy a estar, entonces si lo podemos ver el martes estaría perfecto porque el lunes ya lo tengo saturado, para que ya no... Porque de esto depende que Johann pueda seguir avanzando, ¿no?
+
+27:54 - Noe Rocha
+Va a avanzar en otras cosas, pero como tal, el prototipo en esta parte está saturado por esta definición de nosotros.
+
+28:00 - Erika Chavez
+Ok, de hecho Johann sigue, ya está en la etapa 1, este es lo de la etapa 0, el entregable, entonces en cuanto él ya le... Ya tiene indicaciones en cuanto a él le detenga algo, pues me va a levantar la mano, pero si esto no le detiene a Johann para seguir avanzando en la etapa 1. Sí.
+
+28:18 - Unidentified Speaker
+Gracias.
+
+28:19 - Noe Rocha
+Esta es una regla de negocio, regla de nosotros. Hay que definirla.
+
+28:27 - Unidentified Speaker
+Adelante, Johann.
+
+28:29 - Johann
+Aquí, de acuerdo. En esta parte de iniciar facturación, voy a compartir pantalla del prototipo navegable, que es este que les compartí. Entonces, en... Solicitud de gira, al abrir una solicitud, después...
+
+28:50 - Arturo Rosas Hernandez
+Creo que no vemos tu pantalla. Yo no la veo.
+
+28:56 - Unidentified Speaker
+Listo, ¿la pueden ver?
+
+28:58 - Johann
+Listo, ahora sí.
+
+29:00 - Arturo Rosas Hernandez
+Ahora sí, pero vemos a nosotros mismos. Listo.
+
+29:04 - Noe Rocha
+Este ya es el prototipo navegable.
+
+29:07 - Noe Rocha
+O sea, no es el PDF, es como tal el URL.
+
+29:15 - Unidentified Speaker
+Así es.
+
+29:16 - Johann
+Aquí estoy dentro de una facturación. Me fui aquí a solicitudes Jira y abrí un ticket de Jira. Ahora, aquí, al iniciar una facturación, se me abrirán estos pasos para completar desde la cotización hasta la aprobación humana que timbra la factura. Ahora, aquí, cada ticket tendrá una cotización. En Bind. Puede ser que se cree por parte comercial o del despacho, entiendo que era quien creaba estas cotizaciones o quien las quería, o el sistema puede crearlas automáticamente utilizando... Apenas se crea el ticket, por ejemplo, va a Bind y lo crea. Después se ligan, no? Ese ticket y esa cosa. Eso estaría genial.
+
+30:15 - Araceli Sanchez Jimenez
+Quisiéramos un ticket en gira porque, por ejemplo, ahorita ese Johann lo hacemos manual, o sea, yo generalmente este soy la parte comercial, entonces yo me meto y como ya están pre configurados los clientes, o sea, sí debe de haber un pre requisito, verdad que ya estén dados de alta en el RP, pero una vez así te vas a cotización y entonces yo escojo los diferentes rubros y ahí ya yo hago la cotización, que es algo muy rápido y ya con esa cotización generalmente ya en los tickets para facturación anexa esa cotización para que facturación nada más haga la búsqueda y pues la convierte en prefactura lo necesario, pero si con levantar el ticket, ya se genera la cotización en el sistema estaría más que genial.
+
+30:55 - Arturo Rosas Hernandez
+De hecho, perdón por la interrupción, pero de hecho ayer, justo ayer en la comida platicábamos Pedro y yo, que yo le decía que en algún momento se fuera preparando porque yo sugería que hubiera un espacio para comercial con su debido proceso en gira. Entonces, si ya tenemos facturación, si ya tenemos cuentas por pagar, cuentas por cobrar RH, etcétera, creo que vamos a tener que crear un espacio para comercial y en ese espacio de comerciales, donde subiríamos los tickets, es donde la IA, que habrá que irle poniendo un nombre a la IA para nombrarla como herramienta. Bueno, a la IA va a ir a buscar los tickets y de donde va a tocar tomar la información para generar la cotización. Eso justo estábamos, se lo prometo, estábamos platicándolo Pedro y yo ayer en la hora de comida. Entonces creo que habrá que considerarlo también como parte de la regla de negocio, como dice Noe. Para dejar todo ordenado.
+
+31:51 - Noe Rocha
+Disculpen porque lo mencionan mucho, pero sí quiero ser muy vocal de lo que estamos viendo. Este es un desarrollo y todavía no está dentro de este desarrollo, en dentro, enbebido en este desarrollo, agentes LLM. Lo que están son reglas de negocio de procesamiento de información e integración con diferentes sistemas. ¿Para qué? Para homologarlo a pantallas. Entonces sí quiero dejar muy claro, no es un agente, es un LLM que está haciendo todo tras BarbaLimna. Es un desarrollo que sí está pensado y sí lo hablamos con Johann, que en un cierto momento le íbamos a tener que meter LLMs, pero como esto todavía no está digamos que en el scope inicial todavía no está el agente. Sí está entendido que lo vamos Pero para esto, que es simplemente regla de negocio y proceso, no es IA.
+
+32:50 - Araceli Sanchez Jimenez
+Nada más quiero aclararlo. En esto, en todo lo que nos han explicado, o en esto, es de preparación, aprobación y emisión de CFDI.
+
+33:00 - Arturo Rosas Hernandez
+En general, en todo.
+
+33:02 - Araceli Sanchez Jimenez
+En general, yo fue lo que entendí también. Entonces esto no es IA.
+
+33:08 - Noe Rocha
+No, es desarrollo. Es desarrollo... Con integración de pantallas.
+
+33:12 - Araceli Sanchez Jimenez
+Ah, y yo pensé que esto era agente de IA. No, no, no, no.
+
+33:17 - Noe Rocha
+Esto es desarrollo a la medida que sí, sí va a tener un componente de IA, pero en este momento todavía no va a estar, porque esto se resuelve con reglas y con procesos. Todavía no es necesario meter un agente como tal para hacer, pues, todas las, todo esto. Sí, lo están mencionando mucho. Y nada más aclarando ese punto, Johann, sí tenemos la intención de meter agentes, pero en este momento es regla de negocio con procesos e integración de sistemas. ¿Por qué? Porque ahorita tenemos todo desvinculado y todo lo tenemos que hacer manualmente, con diferentes pantallas, diferentes procesos, diferentes cálculos. Pero esto, como tal, lo que va a venir a hacer es, va a pivotear todos los sistemas para hasta automatizarlo. Ok. A través de reglas y procesos. Sí. Muy bien. No sé si quede claro.
+
+34:12 - Unidentified Speaker
+Sí.
+
+34:12 - Unidentified Speaker
+Sí.
+
+34:13 - Noe Rocha
+Johann, ¿quieres complementar algo de lo que comenté?
+
+34:17 - Johann
+Sí, justamente en este MVP se busca asentar el proceso que ustedes tienen para en un futuro implementar los modelos ya sobre este sistema bien fundamental.
+
+34:30 - Araceli Sanchez Jimenez
+Esta es la base.
+
+34:31 - Noe Rocha
+Sí, necesitamos una base de un proceso bien claro de cómo va a ser, porque si le metemos IA de inicio va a ser una fiesta.
+
+34:41 - Araceli Sanchez Jimenez
+Y qué haría la IA que no hace, o sea, qué plus nos daría la IA sobre esto?
+
+34:47 - Araceli Sanchez Jimenez
+Ponme un ejemplo.
+
+34:48 - Noe Rocha
+A ver, Johann, ayúdame con esta pregunta, porque ahorita de inicio a mí lo único que lo tengo claro que a lo mejor cosas como una gente que yo le pueda mandar información para que me lo procese ya dentro del sistema, ya no que yo tenga que estar interviniendo todo el tiempo manualmente.
+
+35:04 - Johann
+Pero con una regla, con una regla de vas a hacer A, B, C, D, E, A, B, C en este sistema, por ejemplo, se pudieran implementar en esta parte de tomar decisiones o saber cuándo, por ejemplo, una cotización lleva mucho tiempo parada, por ejemplo, o tomar decisiones y dejar preparadas facturas para que Araceli y Arturo simplemente tomen la decisión final. En ese apartado de dejar listo para que Araceli y Arturo vean un listado de facturas o de consideraciones que, por ejemplo, puedan estar en el riesgo o en el área de este apartado tiene algo raro, en esa parte la IA nos podría ayudar a prevenir Esos casos. Y eso ahorraría tiempo, por ejemplo, para estar leyendo todas las facturas. Y podría presentarlos, por ejemplo, cada mañana en el dashboard, por ejemplo. O de pronto podemos meterlo en la parte de conciliación como extra. Aparte de esa...
+
+36:41 - Noe Rocha
+Ahí sí, por ejemplo, entraría directamente la IA. Oye, ¿cómo hacemos la conciliación ahora? A mano. Sácate un estado de cuenta. Fíjate cómo está Vine, ¿verdad Arturo? Y Concilio, ¿qué se pagó? Bueno, ahí sí metemos la idea, porque es un proceso hoy por hoy que no nos lo resuelve nada manualmente. O sea, todo lo tenemos manual y no hay un proceso que nos ayude muy claramente a machar las conciliaciones. Entonces ahí sí entra, ahí sí entra la parte de un agente. Y después ya con la raíz de la cara clara de es el camino, lo que tiene que hacer para diferentes pasos de facturación. El sistema ya como está hecho, ahora sí, el agente lo puede hacer más automatizado. Ejecútame los pasos de facturación. Básicamente, échatelo, no? Sin que tengamos que estar interviniendo pantalla por pantalla.
+
+37:39 - Araceli Sanchez Jimenez
+Perfecto, ya entendí.
+
+37:40 - Noe Rocha
+Pero parte de que tengamos claras las reglas, porque si no, sin reglas claras, un agente no es eficiente.
+
+37:50 - Unidentified Speaker
+Gracias.
+
+37:50 - Noe Rocha
+Ahora yo hago otra observación aquí, muy importante, porque se menciona que la cotización es necesaria para esto que estamos viendo aquí con Johann, el 1, 2, 3, 4 y 5. Pero por ejemplo, y aquí lo pongo solo en la mesa, las recurrencias no existe una cotización para cada factura. ¿A qué voy? Tenemos facturas que son recurrentes porque ya hay un acuerdo y un contrato, Johann. Significa que no tenemos que tener una cotización para facturar porque ya está vendido un proyecto. ¿Te acuerdas lo que te platicaba la sesión pasada? Oye, tengo un contrato de servicio con un cliente y. Pues ese contrato.
+
+38:35 - Araceli Sanchez Jimenez
+Como el de AXIANS que está pagando por cuatro años, tres años. Y esperemos que ganemos otro.
+
+38:41 - Noe Rocha
+Ahí sí tendríamos que tener. Sí, sí, correcto. Ahí sí tendríamos que tener.
+
+38:45 - Araceli Sanchez Jimenez
+tener una una excepción de que no si es recurrente no necesita una cotización si me explicó o a lo mejor que nunca bueno no sé ustedes saben pero a mí me gustaría que nunca hiciéramos excepciones o sea al final del día todo no ha sido una cotización aunque sea recurrente o no entonces podría siempre generarse la cotización y de la cotización siempre se pasa prefactura o factura bueno dependiendo de lo que definamos no Estoy de acuerdo con Ara, porque al final de cuentas son puntos de revisión, oportunidades para revisar y evitar errores o mitigar los riesgos de errores humanos o errores en las configuraciones, sobre todo al inicio, ¿no?
+
+39:28 - Arturo Rosas Hernandez
+Al inicio de la implementación de esta herramienta, pues sí estar monitoreando en cada fase, en cada paso, todo lo que suceda para asegurar que todo suceda de manera correcta y o, algunas veces, como en Big Brother, las reglas cambian. Entonces, no obviar que cada mes todo es igual, sino estar asegurando que cada mes, si hay algún cambio en la descripción, en los montos, en lo que sea, ese mes se corrija y se emita conforme el nuevo acuerdo, conforme las nuevas reglas.
+
+40:09 - Noe Rocha
+donde entraría algo que no sé si debe vivir aquí y lo pongo sobre la mesa para ver si es algo que más adelante lo ponemos. No ahorita porque si no, no vamos a salir nunca porque va a haber muchos supuestos. Pero por ejemplo, en videos pasados, si tú te acuerdas Arturo, teníamos los contratos. Y ese contrato decía, este contrato por un año vale 12 pesos. Entonces cada orden de compra que yo haga por este contrato me del debe contrato de descontar lo contar que ya se facturó y se pagó de tal forma que si al mes seis yo tengo que ya se facturaron seis pesos y se cobraron seis pesos no puedo cobrar más allá de otros seis pesos porque ese Más o menos, amigo, porque más o menos, porque justo con el ejemplo de Axios, o sea, las personas suben, bajan, los precios cambian, se ajustan, aumentos de sueldo, disminución, nuevos acuerdos, etc.
+
+41:04 - Arturo Rosas Hernandez
+Entonces, por eso diría sí, pero no por eso yo digo que sí o bueno, estoy de acuerdo con lo que dijo Ara, de que siempre generemos la conciliación, porque es una oportunidad para revisar de oye, para el empleado, para colaboradora eran 6 pesos, pero acuérdate que esta vez son 5 por RENECOSA o son 6 más 1 que es viáticos o son 6 más lo que sea, ¿no? Entonces, sí debes tener la oportunidad.
+
+41:35 - Noe Rocha
+Pero aquí entra mi pregunta, porque esto sería un trabajo adicional. ¿Significa que cada vez que se tenga que facturar vas a hacer una cotización, Araceli? Significa que, por ejemplo, vamos a poner el caso de AXS, para cerrar la pregunta. ¿Sería práctico que cada mes tendría que hacer la cotización?
+
+41:58 - Araceli Sanchez Jimenez
+Es lo mismo. Si tú haces una cotización, el esfuerzo es el mismo. Por ejemplo, no hacemos cotización, pero al final del día se captura a mano la factura. Entonces da lo mismo. Porque cuando tú haces una cotización, esa cotización es en el RP, nada más te vas a un menú y esa cotización la conviertes. Nada más le haces un clic a prefactura o a factura. Y cuando tú también, entonces tú nada más es un clic. Y por ejemplo, cuando tú vas a facturar, hace el capturas lo mismo y nada más le haces un clic y lo timbras. Entonces el esfuerzo es el mismo.
+
+42:35 - Noe Rocha
+Ah, entonces miren, fíjense que hay un dato importante.
+
+42:38 - Araceli Sanchez Jimenez
+No sé si tú lo estás viendo, Johann, pero por no sé si nos explicamos o quieren que les expliquemos porque el esfuerzo es lo mismo, o sea, por eso a mí me hace sentido que todo nazca de una cotización, porque todos los datos son todos los mismos y nada más la diferencia en la cotización que, por ejemplo, cuando es un tema comercial, yo nada más la cotización la convierto a PDF, pero cuando ya se vendió, esa cotización yo la subo y entonces Artur lo que hace es, oye, factúrala y baja, nos da un número de folio, se va el sistema, el número de folio, aparece la cotización y nada más le da un clic factura o prefactura.
+
+43:20 - Noe Rocha
+Entonces es lo mismo. Entonces aquí es un arreglo interesante. Si la cotización sirve para que se convierta en factura o prefactura, entonces en estos pasos hace sentido. Primero cotización, los datos, los conceptos y luego ya validado, ya conocido información, se va a prefactura, no a se va a ir a prefactura, se va a tener una aprobación humana que va a ser una... Esa aprobación y después, después ya se timbra. Entonces tenemos candado 1 cotización, candado 2 prefactura, candado 3 aprobación y ya al final pues la factura como tal. Entonces son 3 candados para validar que esa factura tiene que salir pues como tenga que salir, ¿verdad?
+
+44:10 - Unidentified Speaker
+De forma correcta.
+
+44:12 - Noe Rocha
+Sí. ¿Hace sentido ese flujo entonces?
+
+44:15 - Unidentified Speaker
+Sí.
+
+44:16 - Noe Rocha
+Ok, de acuerdo. Gracias. Valente, Johanna. Ok, de acuerdo.
+
+44:20 - Johann
+Ahora, en esa parte donde comentan, así como comentario extra, también para tenerlo presente, ¿va a haber cotizaciones y, bueno, facturas que no van a vivir en Gira? O si esas cotizaciones o esas facturas que no tienen cotización a día de hoy están reflejadas en Gira, porque ahorita este ejercicio comienza desde un ticket de Gira. Entonces, si hay alguna cotización. Que no esté en Gira, no va a ser reflejado, entonces pregunto para, por ejemplo, considerarlas aquí para la regla.
+
+44:58 - Araceli Sanchez Jimenez
+Si no, no, Johann, ya por regla y política de la empresa, los únicos y Lo que no está en JIRA no se procesa, ya sea en facturación, cobranza u otras solicitudes de la operación de la empresa. Entonces, ahora sí, el único punto de inicio en donde realmente se detonan los procesos es JIRA. Entonces, todo debe de estar contenido ahí para que no nos vayamos por otro. Nada más es JIRA. Sí, que no sea un correo, que no sea un mensaje. Si no está en JIRA, no es oficial. Sí, y de hecho, por ejemplo, en mi caso, que luego me llegan correos con facturas cosas así como para yo no capturar de manera manual y un ticket en gira y yo ya tengo una dirección establecida de correo yo lo reenvío ese correo aún y a una dirección de gira y giren automático me hace un ticket entonces todo está por girar ya aquí aquí entiendo muchas gracias Ahora, continuando con estos pasos, así como comentan, sí, aquí los candados serían primero la cotización, después la prefactura, la aprobación y por último el timbrado, que es lo que sucede cuando avanzamos con este proceso de facturar.
+
+46:18 - Johann
+Entonces, primero vemos los datos que tiene la factura. Aquí se selecciona el método de pago, está por defecto el PPD. Ajá. Los conceptos EIVA de esta factura, bueno, de esta cotización. Después, se ve una previsualización de la prefactura. Aquí se puede dejar y guardar para validarla después, o podemos enviarla directamente a aprobación. Y ahora cuando se envía a aprobación, aquí, por ejemplo, se puede dejar lista para que o Arturo o Araceli la aprueben desde su cuenta una vez se apruebe ya se puede timbrar, primero se aprueba y luego se timbra y después pueden o emitir otra factura o continuar y enviar la factura con los documentos para esta parte del correo te tendría que dar un buzón o algo por el estilo, ¿verdad? Sí, ocuparemos un buzón de.
+
+47:33 - Noe Rocha
+Sí. Así es.
+
+47:35 - Araceli Sanchez Jimenez
+Oye, Johann, yo por ejemplo, aquí ya ves que tenemos algunos asegúnes, es decir, hay algunos que nada más le mandamos la factura, es decir, le echa un rollito ahí el por ejemplo, en el en el tema de Accions, le mandamos las cuarenta y tantas facturas en una carpeta zip, o sea, no le mandamos un correo por factura, pero además de de mandárselas todas en un en un solo correo, nos pide el estado de cuenta de esas facturas, es decir, les mandamos así y entonces se le manda un archivo que eso también se se saca de del sistema de entonces veinte y cincuenta, estas son tuyas y corresponde veinte, veinte, Araceli Sánchez del Perú, no sé qué, cinco mil y algo, o sea, se les manda todo eso, o sea, además de la factura. Aquí, por ejemplo, nada más se adicionaría en la factura, y nosotros a este correo le podemos anexar cosas o.
+
+48:45 - Johann
+Sí, sí, justamente, por ejemplo, tenga sus propios requisitos y, por ejemplo, aquí en el ejemplo de Cemex, me parece envío bloqueado porque me faltan las horas, el Excel de horas.
+
+48:59 - Araceli Sanchez Jimenez
+Sí, órale, sí, me gusta. Yay, jubilados, Artur, ya. Ya. Bueno, está en la playa. Exactamente, así desde la playa, autorizar, enviar. Mira, pues de hecho ahí está, ¿eh?
+
+49:13 - Noe Rocha
+Ahí no menciona. ¿Dónde estaba el zip? Acuntia. Ahí viene, .zip, pdf.xml, más estado de cuenta. Ya lo menciona.
+
+49:21 - Araceli Sanchez Jimenez
+Andale, super, sí. O sea, decirlo con particularidad por cliente. Sí, Johann, y ya ves que aquí luego los clientes es como el Big Brother, las reglas cambian. Entonces, por ejemplo, si de repente nos piden otra cosa por sistema, se puede anexar esa o quitar o poner la nueva regla, ¿verdad?
+
+49:41 - Johann
+Ok, habría que desarrollar ese módulo de configuración? Al principio esto estaría cerrado, directo, cerrado, sí, pero si se puede, nada más que ahora mismo sería desarrollar el módulo.
+
+49:52 - Araceli Sanchez Jimenez
+Sí, no, no, y si no, pues te contactamos, nos cobras unas horas de servicio y nos haces el ajuste, ¿no? Sí. Ok, sí, digo, de momento yo creo que no es necesario desarrollar el otro de configuración porque realmente, pues, es pequeño, pero yo nada más porque luego nos cambian la y si sí, nada más saber que la podemos poner ahí, porque al final del día esto nos libera mucho, Johann, porque luego, de entrada, la curva de aprendizaje nos las hace muy laxa o muy soft porque por ejemplo a lo mejor ya le dimos la capacitación a alguien y lo quiere mandar y va a decir ah si cierto tengo que mandar a b c d entonces así quita también mucha vigilancia humana no o acompañamiento de cierta forma gracias así es ok entonces esta parte es todo el proceso por la parte de facturación.
+
+50:55 - Johann
+¿Aquí hay alguna duda? Porque seguiría después cobranza. No. Yo ninguna, no sé si ustedes.
+
+51:02 - Noe Rocha
+No, nada más las reglas, nada más arrañar un poco nosotros para la regla específica de lo que comentamos antes. Pero de ahí en fuera el módulo es bastante, creo que se ve muy visual e intuitivo.
+
+51:19 - Unidentified Speaker
+Sí.
+
+51:20 - Araceli Sanchez Jimenez
+Me encantó.
+
+51:21 - Johann
+De acuerdo, continúo. Ahora, esta parte de cobranza. En el módulo de cobranza vamos a tener las facturas abiertas y los estados de cuenta. Entonces, toda esta información del módulo de cobranza, aquí la podemos ver, tendrá los estados de cuentas asociados. Y ahora aquí, nosotros tenemos dos pantallas. En la primera vamos a ver las cuentas por cobrar. Y aquí se pretende que el segundo reemplazo, no reemplazo, pero que sea el equivalente al Excel que compartió Arturo, en donde pueden ver las facturas y cuánto tiempo llevan de morosidad por cliente.
+
+52:17 - Johann
+Johann, esto se alimenta de Vine, ¿verdad?
+
+52:19 - Noe Rocha
+O sea, si Vine no está conciliado en algún dato, pues no nos va a dar la información. Al día. Si primero no está en Vine. Porque la fuente oficial de información es Vine. Así es. Ok.
+
+52:35 - Johann
+Sí, justamente como mencionas, viene desde Vine.
+
+52:38 - Arturo Rosas Hernandez
+Aquí tengo una duda y es la parte en la finza. Digamos que están los estatus obvios, ¿no? Por pagar, pagada, cancelada o... No veo el resto de estatus. Ok, entonces, pero hay unas facturas especiales que digamos que ya están programadas para pago, que de cierta manera las estamos ahorita categorizando de otra manera, ¿no? Entonces ahorita justo unas facturas que ya están programadas para pago, es decir, hoy mismo me apareció una factura que dice que se va a pagar el 24 de septiembre. Esas le llamamos NAFINSA y las categorizamos con esa tipificación, NAFINSA. La pregunta es, para este módulo de cuentas por cobrar, ¿habría la posibilidad de categorizar de manera diferente este tipo Si no está en Bind, no.
+
+53:43 - Noe Rocha
+Si el estatus no existe en Bind, no. Pero ahora sí ya. Sigue tú Johann. ¿Qué Workaround podemos tener? Muchas gracias Noe.
+
+53:54 - Johann
+Así es como esta información se jala de Bind. Si no existe en Bind, nosotros habría que agregar una capa extra aquí en el sistema. A lo mejor añadirle o o un campo de estatus o agregárselo aquí.
+
+54:12 - Noe Rocha
+Nada más que ahí tendríamos que definir la regla Arturo. Hoy por hoy, ¿cómo se define el estatus de una factura con un estatus diferente en Vine? Para visualizarlo y ponerle esa capa que dice Johann, oye esto no existe en Vine. ¿Cómo lo queremos ver y cuál es la regla para tipificarlo? Para entonces ponerle sobre lo es una capa adicional, es decir, y estas facturas las necesito ver así, pero es una capa arriba de.
+
+54:43 - Araceli Sanchez Jimenez
+Si son solo las de Cemex, el único cliente que tiene cadenas productivas, que es Nafinsa y Cemex. Entonces, por ejemplo, cómo es el proceso de Cemex? Cuando un proveedor está dado de alta en cadenas productivas, nosotros vemos todo el proceso y entonces Cemex dice ok, ya está, se pasa a aprobar a pago y lugar de que nos se nos tenga y porque nos paga 120 días lo que hace es pasar esa factura ya autorizada pago a la finza y entonces nosotros en la finza vemos todas las facturas que ya están en firme en pago sí entonces las cadenas productivas bueno no sé si ustedes sepan pero bueno sino cadenas productivas es es un apoyo que se le da a los proveedores porque es decir si Yo necesito bajar ese dinero antes de los 120 días. Yo lo bajo y me cobran un interés respectivo diferente, dependiendo del banco el que yo decida. Verá, entonces al final del día es como una ayuda, un apoyo al proveedor de crisis. Oye, yo no puedo esperar 120 días, lo bajo ahí. Entonces todas las facturas que nos aparecen en la finza ya están en pago en firme. Entonces, pero, están en pago en firme, en Bain a nivel contable, no se registra hasta que cae en la cuenta. Entonces, este dato nosotros ni siquiera si lo compartimos al despacho contable, porque nos va a decir a mí de qué me sirve, o sea, a mí no me des algo que esté en el aire. Pero para nosotros, de manera interna, sí nos sirve, porque entonces sabemos que ya tenemos ahí en firme el pago de dichas facturas, y las que no aparecen en la finza, entonces sí empezamos a correr porque quiere decir que no están autorizadas. Pero nada más pasa eso para CEMEX. De ahí en fuera, para ningún cliente tenemos NAFINSA o cadenas productivas.
+
+56:38 - Noe Rocha
+Y ese dato, como nada más para ver y pensarlo con Johann. Estos son los datos de Vine. Y la capa siguiente para ver esto, ¿cómo les serviría o cómo lo ven hoy? ¿Cómo les funciona ver ese dato?
+
+56:55 - Araceli Sanchez Jimenez
+y a la mejor nosotros lo podríamos alimentar o manual o por ejemplo nosotros tenemos un portal, un usuario de una contraseña y ahí en ese portal le damos emics, le damos consultar y nos explica todas las facturas con el el cfdi y a cuántos días nos los van a pagar, de hecho nosotros tenemos ahí ya parece el día exacto 4, 3 de agosto, septiembre, entonces este nosotros lo que hacemos por eso le con Artur una capa adicional porque esas no están pendiente de pago o sea si están pendiente de pago pero ya están programadas pero no han caído en la cuenta a fin de cuentas no han caído no han caído entonces nada más yo como lo veo esta pantalla nos dice lo que ya cayó necesitarían otra pantalla para ver lo que está programado para pago cuentas estos son cuentas por cobrar estas son las que no han pagado, o las que no nos han pagado.
+
+57:56 - Noe Rocha
+Sí, las que no se han pagado. Esto solamente nos dice si está pagado o no está pagado. Y cuántos días tiene desde que no se ha pagado a la fecha. Como dice aquí, tiene de 1 a 30 días vencidas, de 30 a 60 días vencidas, etc. Esto no nos dice eso, pero no nos dice o no viene, y como no existe en Vine, también es necesario definirlo. ¿Podemos tener una pantalla para ver lo que ya está programado?
+
+58:25 - Arturo Rosas Hernandez
+Mi respuesta corta, si me permite interrumpirte, Ara, es sí. Sí, porque en algún momento tenemos que ser preventivos o podemos planear nuestras finanzas a futuro. Y poco a poco pudiéramos hacerlo con los clientes. Yo estoy pensando, me estoy imaginando un futuro Balam, que por cierto, ahí viene otra pregunta porque falta el resto de empresas, pero bueno, ahorita voy a enfocarme con Balam, estoy pensando que vamos a crecer en la cantidad de clientes, en la cantidad de facturación, etcétera, etcétera. Y tal vez esos clientes ya van a empezar a tener portales. O sea, caso Frisa, caso Frisa ya tiene su portal, ya tiene un portal de proveedores. Y entonces, si ya tiene el portal, ya nos va a decir o ya nos va a permitir saber cuándo están programadas nuestras facturas. Como con este, con estos casos que mencionara de ya, ya es seguro, o sea, ya es seguro. Que el 24 de septiembre me va a caer una factura y con eso nosotros podemos planear nuestras finanzas, es decir, si tomo del ahorro o tomo de un préstamo o no considero pago para esa semana o la considero para la siguiente o para ese mes o para el otro mes, o sea, poder planear nuestros pagos porque ahorita estamos siendo reactivos, estamos reaccionando a las necesidades financieras de la empresa Y sí, estamos adelantando en unos cuantos meses en el futuro, pero yo quisiera que pudiéramos adelantarnos un poco más, pero de manera por proceso. Que en algún momento alguien nos diga o una pantalla nos diga cuánto dinero tenemos programado en los siguientes meses y qué podemos hacer con ese dinero con base a la facturación que tenemos, a las cuentas por cobrar, qué tenemos, a los ingresos, etcétera. O sea, una planeación financiera. Y ese es el último toque, la cerecita del pastel, diré yo. Adelante, perdón.
+
+1:00:23 - Noe Rocha
+Entonces sería entonces, a mí se me ocurre lo siguiente, muy rápido, nada más antes de perder la idea. A mí se me ocurre lo siguiente, y dígame si les funciona, que de esto, y ya lo veo con Johann, se pueda seleccionar qué factura ya la tenemos por lo menos programada en un portal de algún cliente, este es el que sea, y que manualmente le podamos poner un estatus que diga programada y con la fecha, como para poder decidir mínimo, por lo menos, ya sé que el mes de julio me van a pagar el 50% de las facturas vencidas. Pero yo creo que eso sería para ponerlo en otra pantalla diferente a esta. Esta sería nada más como que, o me pagaste o no me pagaste. Y en la otra, qué es lo que sí tengo programado. No sé si le sirva.
+
+1:01:13 - Araceli Sanchez Jimenez
+Oigan, a mí se me ocurre algo. Yo pensando en que cada vez dependamos menos de nosotros. O sea, de nosotros meternos al portal así. También lo que puede hacer es, por ejemplo, que cada 15 días se genere un ticket en Jira automático de checar portal Nafinsa, no sé, desde Jira, ¿no? Entonces, ese checar que diga, oye, ¿sabes qué? Y que pongas un Excel y que a lo mejor se haga un ticket para que se vaya directamente a cuentas por cobrar. Entonces, al menos cada 15 días, porque tampoco es tanta la transaccionalidad que tenemos con SEMED, como para decir, oye, es que hay que checarlo diario, porque, o sea, no. Entonces, a lo mejor cada 15 días que nosotros se genere un ticket en automático, pongamos lo que nos aparezca en Afinsa, el pantallazo, los FDIs, y ya se cierre. Y ese ticket automático lo jalen ustedes y lo meten en cuentas por cobrar. Y puedan hacer el match, si me entiendes, porque es el número de folio. El número de folio que nos aparece en Afinsa es el mismo número de Entonces que tú digas, ah, mira, en Cemex está el follow 100 y está en Afinsa, ah, ok, entonces aquí, en automático, en Afinsa. No me gustaría que quedara tan manual porque se nos va a ir otra vez de las manos.
+
+1:02:35 - Noe Rocha
+¿Podría ser eso o no?
+
+1:02:37 - Arturo Rosas Hernandez
+Lo veo con Johann.
+
+1:02:39 - Noe Rocha
+Bueno. Sí.
+
+1:02:40 - Unidentified Speaker
+Gracias.
+
+1:02:40 - Unidentified Speaker
+Muy bien.
+
+1:02:41 - Johann
+Adelante, Johann.
+
+1:02:42 - Johann
+Ok. Entonces. En cada factura se ve el detalle de las facturas. También aquí tenemos consideradas la tolerancia por fees. Por ejemplo, si tienen una diferencia que sea considerada un fee, eso se tendría que configurar. Por ejemplo, si es el 5% o una cantidad así fija de fee por cliente, aquí se configuraría y entraría aquí en pagada pero con tolerancia. Esto es por esta pantalla y en la siguiente pantalla de pagos y recordatorios, aquí es para informar o para ver, por ejemplo, los pagos detectados que han ocurrido últimamente en Bind, por ejemplo, hoy. Y aquí se verían los pagos de las facturas que se han hecho hoy y el resultado que se ha hecho. También aquí vemos algunas reglas de recordatorio. Por ejemplo, todas las alertas por el momento serán internas. Aquí, por ejemplo, si lleva un día vencido de la factura, se le avisará a Arturo. Si lleva 15 días, ya se enviar un mensaje a Araceli y también por el momento no está desarrollado pero podría ser en un proceso posterior de si lleva cinco días se le envía un correo al cliente y a 30 otro correo al cliente.
+
+1:04:26 - Araceli Sanchez Jimenez
+¿No está configurado porque no es el alcance?
+
+1:04:30 - Noe Rocha
+No está definida la regla todavía.
+
+1:04:34 - Araceli Sanchez Jimenez
+Gracias.
+
+1:04:34 - Johann
+Y aquí abajito ya aparecerán las alertas internas, que son estas reglas de recordatorio.
+
+1:04:42 - Johann
+Entonces, por ejemplo, si estoy aquí como el usuario de Arturo, aquí me aparecerán todas las facturas que tengan más de un día vencidas.
+
+1:04:55 - Araceli Sanchez Jimenez
+OK.
+
+1:04:55 - Johann
+Y aquí, por ejemplo, esta parte iba para lo de las excepciones de seguimientos está pensado para por ejemplo si había un cliente que no se le quisiera enviar un correo porque era un cliente que ya pagaba pero también esta parte puede no estar ok gracias esto por esta parte y como último este módulo de auditoría Es una bitácora de los movimientos que se han hecho y qué usuario los hizo, a qué hora los hizo. Entonces, de esta forma, por ejemplo, se puede llevar un seguimiento de las facturas que se hicieron, las aprobaciones que se hicieron, las cotizaciones que se vincularon y todas las acciones que se hicieron dentro del sistema. Aquí se puede ver para llevar una transabilidad.
+
+1:05:57 - Araceli Sanchez Jimenez
+OK. Me encanta la idea. Sí a todo.
+
+1:06:02 - Noe Rocha
+Ahora, este MVP y lo importante de la definición del MVP, qué significa MVP? Y lo vuelvo a repetir, porque ya lo habíamos dicho hace tiempo, pero nada más para no perdernos. El MVP es lo mínimo necesario para operar. Yo sé que ahorita vimos muchos temas, muchos segundos, muchos detalles, pero yo sí los invitaría a decir sí, si el cielo, esto nos funciona para empezar a operar algo el día de hoy, lo ideal sería hacerlo. ¿Por qué? Porque ¿qué pasa? Cuando se le da una revisada a un sistema, empiezan a salir muchos hacegúnes, como ya lo hemos visto. Y en esos hacegúnes empezamos a sumarle, sumarle, sumarle. Y al final de cuentas, cuando llegamos ya al momento de querer operarlo, pues nos damos cuenta de que hay cosas que se empiezan a decir. Ah, ¿sabes qué? Esto no, esto sí, esto lo ocupaba así, esto ya no. Entonces El MVP tiene como propósito salir rápido, operar rápido y descubrir sobre eso lo que, si bien ya documentamos ahorita, cosas que a lo mejor ni siquiera habíamos visto porque no lo estamos operando. Entonces. Hay cosas que sí son de reglas, que sí, definitivamente las tenemos que definir para que queden dentro del sistema. Y hay otras cosas, son como los nice to have. Oye, estaría padre que tuviera esto. Entonces, si los nice to have ahorita, nos impiden o no serían impedimento para poder salir a operar con algo. Yo sí les pediría que hagamos team back, veamos los puntos que mencionamos en esta sesión y digamos qué es nice to have y qué es un must. Si es un must, volver con Johann o Johann, esto es must. Por favor, vamos a quitar, poner, subir, bajar, lo que tengamos que hacer. Y lo que no, podamos empezar a avanzar para que Johann en un tiempo corto nos pueda empezar a dar ya algo operativo. Y lo que sí pasa mucho es que ya cuando sales a operación con algo, ahí es cuando se descubren muchos asegúnes. Muchísimos más de los que estamos viendo ahorita, porque ahorita ni siquiera lo estamos operando, nada más lo estamos viendo.
+
+1:08:12 - Araceli Sanchez Jimenez
+¿Sale? Mira, yo tengo la respuesta rápida. La verdad que Johann nos captó absolutamente todo lo indispensable y más o sea a mí me parece fabuloso yo lo único que de mi lado queda es que revisemos el proceso de facturación prefacturación nada más para no hacer si revisamos ese proceso de mi lado está o sea está perfecto porque justo lo como ya habíamos tenido otras sesiones con Johann nos captó súper bien entonces para mí esto se me hace algo súper maravilloso yo de momento no le pondría nada más o sea es como y ya obviamente entiendo que ya después él montaría la IA para pues obviamente ya que nos dé otra analítica y otras cosas. Pero de momento a mí me parece excepcional, o sea, siento que tiene absolutamente todo. ¿Tú qué opinas, Artur?
+
+1:09:00 - Arturo Rosas Hernandez
+Sí, la verdad es que lo dijiste muy bien. Yo no le pondría nada más. Incluso el reporteo está muy bueno, que es lo que nos va a permitir dar visibilidad de lo que falta, lo que se hace, lo que no se hace, etcétera, incumplimientos o omisiones. Entonces, yo lo veo bien, como lo dice Noe, lo conecto con el MVP. Sí, esto es lo mínimo que necesitamos y obviamente esto va a ir creciendo con todo esto que dijimos y más porque sabemos cómo somos, ya nos conocemos para que nos invitan. Sí, le podemos agregar muchas cosas porque sí, seguramente hay muchas cosas por mejorar, pero también dependen mucho de nuestros procesos, ¿no? De los procesos, de cómo los estamos creando o cómo lo estamos mejorando día a día. Entonces, yo también lo dejaría así como está. Sobre todo el tema de la facturación. O sea, si el tema de facturación me va a permitir hacerlo en segundos y no en horas o en minutos y no en horas, yo voy y ya estoy de acuerdo. O sea, con que nos reduzca el tiempo que dedicamos a la facturación, que tampoco es mucho. Y al reporteo, está genial.
+
+1:10:12 - Araceli Sanchez Jimenez
+Sí, sobre todo como tú dices, yo creo que la consolidación, o sea, el tenerlo, porque vamos de uno a otro, y luego agarras el giri, y luego agarras esto, y luego el vine, y O luego sea, no son sé muchos qué, temas y y luego, luego abrimos el archivo de Excel de la cobranza y luego esto. Entonces, yo creo que aquí y además que tengamos los dos o una sola previsualización. Por ejemplo, yo cuando apruebo cosas me tengo que meter al portal de JIR en aprobación y no sé qué. Y aquí ya está todo consolidado. Entonces, no me tengo que. Y luego, por ejemplo, veo las aprobaciones y porque apruebo no nada más las de administración, sino otras. Entonces, cuando veo la lista de aprobaciones, siempre le doy prioridad a facturación y a pagos. Entonces, yo ando seleccionando. Entonces, aquí ya sé que si yo me meto en el portal, yo nada más priorizo esto, ¿no? O sea, desde un solo dashboard, porque en el Jira, pues, sí, yo tengo que, por los títulos me dejo llevar y, bueno, este sí, ahorita este lo veo y cosas así. Entonces, a mí me parece que todo está bien, nada más hagamos Timback para rechecar el flujo de facturación o prefacturación. Y con eso, Johann, muchas gracias. Creo que, este, le decía, no, de que tú tienes, yo veo que tú tienes, digo, tienes muchas cualidades, pero de la cualidad que tiene que ver con lo laboral y que yo he visto que tienen pocas personas, hablas poco y escuchas muchísimo. Y eso hace que nos entiendas mucho. Generalmente la gente te interrumpe. Mucho entonces yo tú eres o sea yo puedo estar hablando una hora y tú jamás me interrumpes y ya al final que termino oye y ya me haces entonces generalmente las personas que que son así tienen mucha capacidad de de percibir y de de atención y de entender y tú eres una de ellas muchas gracias nos entendiste aquí está el ejemplo y el bebé y el bebé balama ahí está de ejemplo exactamente entonces está perfecto yo la verdad lo veo super bien. Muchas gracias. Pues listo, Johann.
+
+1:12:19 - Noe Rocha
+Queda pendiente de nuestro lado nada más una parte de definición del proceso y ya para volver contigo y hacer este MVP ya algo productivo. Que, ojo, nada más Ara y Arturo, vamos a tener que hacer una prueba y esa prueba va a ser muy muy observada, muy segura de lo que sería un flujo normal para la prefacturación. Porque eso ya implicaría ir a escribir sobre Vine, pero eso ya lo haríamos sobre... Ahora sí queda, como dices ahora, bien plenito, ¿no? Bien, paso por paso, valida. Oye, sí está súper seguro de que lo que estamos haciendo esté funcionando y no está afectando a otra cosa.
+
+1:13:07 - Araceli Sanchez Jimenez
+Ok, sí, me late.
+
+1:13:08 - Noe Rocha
+Ese ya sería el final, ya cuando cuando tengamos toda la fase definida del proceso, antes de hacer un go live del sistema.
+
+1:13:19 - Unidentified Speaker
+Ok, perfecto.
+
+1:13:20 - Noe Rocha
+Johann, ¿comentarios?
+
+1:13:21 - Johann
+Muchas gracias, Arturo, Araceli, por sus palabras, las aprecio mucho. Justamente, me han servido mucho las explicaciones que me han dado. Me han dejado espacio para dudas. Entonces, ha sido muy valiosa la información que me han brindado. También cómo mostraban ejemplos, cómo traían casos que no eran tan comunes también para considerarlos, cómo explicaban el proceso porque lo vio en día a día, fue muy útil y fue muy cómodo para mí trabajarlo y entender qué les iba a servir. Me alegra mucho que esta solución, este MVP, les haya agradado, les haya sido de gusto y vamos a trabajar sobre ello. Entonces, pues, mis siguientes pasos serán ya montar o comenzar con el desarrollo de la parte visual. En ese tiempo, he estado trabajando en la parte que va por detrás. En el backend, sí. He estado trabajando en el cliente de cómo se va a conectar con Bind, en la parte de usuario, en la parte de soportar el multitenant, en la base de datos. Entonces, falta conectar a CloudFrontend y hacer las pruebas que comentan hoy. Entonces, esos, por mi parte, serán los siguientes pasos. Y con mucho gusto de seguir trabajando en este proyecto, en el Bebé Balán, como dicen.
+
+1:14:45 - Araceli Sanchez Jimenez
+Ya sé. Muy bien, Johann. Muchas gracias a todos.
+
+1:14:48 - Noe Rocha
+Ya tenemos que ir, porque la parte de gira, pues, ya habíamos, tenemos una sesión pendiente con Pedro, ¿no?, para hacer ese Discovery. Sí, es correcto. En un principio, pero ahora, dado la necesidad del proceso, hay que incluirlo. ¿Vale?
+
+1:15:03 - Johann
+Vale, ok.
+
+1:15:04 - Araceli Sanchez Jimenez
+Bueno, ya está. Gracias, gracias. Feliz viernes y igualmente. Gracias, bye. Bye.

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

@@ -46,12 +46,22 @@
 
 - “va, en cuanto los tenga te los comparto”
 
+**Johann · 8:40 pm** *(mismo día, en la noche)*
+
+- Envía el archivo **`Plan-actividades-avance-2026-07-16.xlsx`** (11 kB).
+- “Buenas noches, una disculpa por la hora”
+
+**Erika · 8:44 pm**
+
+- “Buenas noches johan”
+- *(respondiendo al documento)* “Ntp, gracias”
+
 ## Acciones derivadas
 
-1. Validar que el acceso al repositorio privado permita lectura y escritura.
+1. ~~Validar que el acceso al repositorio privado permita lectura y escritura.~~ → **Comprobado el 16-jul:** push exitoso del scaffold inicial (`04d8388..1f7f098`).
 2. Revisar los procedimientos de carga de facturas enviados por correo y contrastarlos con el flujo levantado en Discovery.
-3. Compartir con Erika un corte verificable del avance de la Etapa 1.
+3. ~~Compartir con Erika un corte verificable del avance de la Etapa 1.~~ → **Hecho (16-jul, 8:40 pm):** Excel de avance enviado por WhatsApp; Erika acusó recibo.
 
 ## Observación
 
-En el chat Johann confirmó que ya podía acceder al repositorio y que recibió el correo. Aún falta conservar el correo o sus adjuntos como evidencia y realizar la revisión de contenido.
+En el chat Johann confirmó que ya podía acceder al repositorio y que recibió el correo. Aún falta conservar el correo o sus adjuntos como evidencia y realizar la revisión de contenido (insumo para la sesión del 22-jul).

fuentes/2026-07-21 a 2026-07-27 - WhatsApp - Erika coordinacion sesiones validacion y API Jira.md

@@ -0,0 +1,112 @@
+# WhatsApp — Erika Chávez (PM, Balam) ↔ Johann · coordinación de sesiones (validación de prototipo + API Jira), envío del flujo de facturación y reagenda 23→24 jul
+
+**Canal:** WhatsApp
+**Fechas:** 2026-07-21 (tarde) a 2026-07-27 (mañana)
+**Evidencia:** copia del chat compartida por Johann el 27-jul-2026.
+**Relación con la bitácora:** continúa el hilo del 21-jul ([#51](../bitacora/REGISTRO.md)); cruza con la sesión de reglas del 22-jul ([#54](../bitacora/REGISTRO.md)), la validación del prototipo del 24-jul ([#55](../bitacora/REGISTRO.md)) y la sesión de API de Jira del 27-jul ([#56](../bitacora/REGISTRO.md)).
+
+> **Nota sobre imágenes:** las capturas no se conservan en el volcado de texto; se infieren por el contexto y se marcan como **📷 [imagen inferida]**.
+
+---
+
+## Transcripción
+
+### Martes 21-jul (tarde) — horas por Excel y aclaración de cotizaciones/MVP
+
+**Johann · 12:51 pm** — “Disculpa acerca de las horas, mientras se habilita el flujo de Jira, ¿te las comparto por Excel?”
+**Erika · 12:52 pm** — “Sí por favor con el entregable y act y horas” · “De cada etapa por favor”
+**Johann · 12:52 pm** — “De acuerdo”
+
+**Erika · 12:58 pm** — “disculpa ¿no es esto lo de las cotizaciones?”
+> 📷 **[imagen inferida — confianza alta]:** captura señalando el punto de cotizaciones (probablemente §1.4 de la propuesta o la fila del Excel).
+
+**Johann · 1:00 pm** — “Sí pero desde el MVP”
+**Johann · 1:01 pm** — “También identifiqué un punto que no aparece todavía en el Excel: durante el Discovery surgió la posibilidad de que los tickets de Jira generen automáticamente las cotizaciones en BIND. Para eso eventualmente necesitaríamos acceso técnico a Jira y permisos controlados de escritura en BIND. Esto es para que cuando se cree un ticket de Jira, se cree automáticamente la cotización en BIND.”
+**Erika · 1:01 pm** *(citando “Sí pero desde el mvp”)* — “¿Qué es MVP?”
+**Johann · 1:02 pm** — “Esta aplicación que estamos trabajando”
+**Erika · 1:03 pm** — “Okey” · “ya vi que dice fuera de alcance”
+> 📷 **[imagen inferida — confianza media]:** posible captura de la §1.3 (Jira “Fuera de alcance”).
+
+**Johann · 1:04 pm** — “Okay, cualquier cosa me avisas”
+
+### Miércoles 22-jul — disculpa por la sesión de reglas, propuesta a ajustar, agenda de API Jira y envío del flujo por correo
+
+**Erika · 11:35 am** — “buenos días Johan, primero que nada una disculpa por no estar en la sesión de hoy, tuve un compromiso personal, sin embargo les avisé a los ingenieros mi ausencia para que pudieran tomar esa reunión importante contigo. Veo que se mencionó lo del ajuste de la integración del sistema Jira ¿vrdd?”
+**Erika · 11:35 am** — “¿ajustarás la propuesta?”
+**Erika · 11:35 am** — “y quedó pendiente de nuestro lado la revisión de la API con Jira y el flujo de facturación de Jira ¿vrdd?”
+**Johann · 11:55–11:56 am** — “Hola buen día” · *(citando su disculpa)* “No hay problema” · *(citando lo del pendiente)* “Sí, así es”
+**Erika · 11:58 am** — “Okey de acuerdo, deja valido la información correspondiente para mandarte lo solicitado”
+**Erika · 11:59 am** *(citando “ajustarás la propuesta?”)* — “¿Se ajustará?”
+**Johann · 12:05 pm** — “Sí, de igual manera entre hoy y mañana te comparto el conteo de horas y la propuesta ajustada”
+
+**Erika · 1:21 pm** — “Johan, ¿pudieras tener una sesión el viernes a las 7 am para ver lo de la API de Jira junto con el Ing. Noe y mi compañero Pedro?” · “¿Cómo ves?”
+**Johann · 1:22 pm** — “Sí, me parece bien”
+**Erika · 1:22 pm** — “Va, deja la agendo, gracias”
+
+**Erika · 2:26 pm** — “Johan, te confirmo: el correo del flujo de facturación de Jira ya lo mandé” · “Quedo al pendiente de cualquier duda o comentario :)”
+**Johann · 2:40 pm** — “De acuerdo, muchas gracias :)”
+**Erika · 2:47 pm** — “A ti, igual la sesión ya se agendó, la del viernes”
+
+### Jueves 23-jul — reagenda por tema personal de Araceli; validación se mueve a viernes; API Jira se mueve a lunes
+
+**Erika · 6:53 am** — “Buenos días Johan” · “¿Ya listo?”
+**Johann · 6:53 am** — “Hola Erika, buenos días” · “¡Listo!”
+**Erika · 6:54 am** — “¡Súper!” · “Igual comenzaremos con que expliques el prototipo y si hay dudas que se comenten” · “Ten a la mano el archivo que nos compartiste para que proyectes por favor”
+**Johann · 6:55 am** — “¿Cuál archivo disculpa?”
+**Erika · 6:55 am** — “El que nos enviaste”
+**Johann · 6:55 am** — “Oh, el PDF con las capturas”
+**Erika · 6:55 am** — “Sí”
+
+**Erika · 7:00–7:01 am** — “Johan” · “Una disculpa, me van avisando que Araceli trae un tema personal y no podrá conectarse, y es de gran importancia que esté ella ya que es la del proceso completo” · “¿Podemos cambiar esta sesión a mañana a las 7 am?” · “Y la que tenías mañana conmigo de la API de Jira moverla a la tarde, no sé cuál sea tu disponibilidad”
+**Johann · 7:01–7:02 am** — “Entiendo” · “¿En qué horario en la tarde podrían para lo de la API de Jira?”
+**Erika · 7:02 am** — “A la hora que indiques” · “¿Puedes a las 4-5-6?”
+**Johann · 7:03 am** — “¿Podría ser después de las 6:30 de casualidad?”
+**Erika · 7:03 am** — “Sí claro, 6:30 a 7:30 va”
+**Johann · 7:05 am** — “¿Un poco más cercano a las 7 habrá oportunidad? ¿O ya sería muy tarde?”
+**Erika · 7:09 am** — “¿A las 7 entonces?”
+**Johann · 7:10 am** — “Sí, a esa hora me quedaría súper”
+**Erika · 7:11 am** — “Listo, nos vemos a las 7 am mañana para prototipo y en la tarde 7 pm para lo de la API” · “Gracias Johan y una disculpa”
+**Johann · 7:27 am** — “Enterado, muchas gracias Erika”
+
+**Erika · 9:45–9:46 am** — “Johan” · “¿Puedes el lunes a las 7 am?” · “Es que me comenta Pedro que lo puede mañana a esa hora”
+**Johann · 9:56 am** — “Sí sin problema”
+**Erika · 10:06 am** — “Súper” · “gracias”
+**Erika · 10:08 am** — “Listo ya la moví”
+**Johann · 10:09 am** — “Listo, ya la acepté”
+**Erika · 10:23 am** — “gracias”
+
+**Erika · 11:29 am** — “Johan ¿esta actividad se acabó ayer?”
+> 📷 **[imagen inferida — confianza alta]:** captura de una actividad del Excel/plan (la de escritura/sync en BIND).
+
+**Johann · 11:37 am** — “Sí, aún no he hecho pruebas de escritura en BIND, pero ya está”
+**Erika · 11:37 am** — “Okey de acuerdo”
+
+### Viernes 24-jul — arranque de la sesión de validación del prototipo
+
+**Erika · 6:57 am** — “Buenos días Johan” · “¿Cómo estás?” · “¿Todo listo?”
+**Johann · 6:57 am** — “Hola Erika, buenos días” · “Sii” · “Listo” · *(citando “como estas?”)* “Bien ¿y tú?”
+**Erika · 6:57–6:59 am** — “Bien gracias” · “Pues ahorita le damos entonces va” · “Vamos a conectarnos”
+**Johann · 6:58 am** — “Va”
+**Erika · 7:00 am** — “Ya estamos”
+*(→ inicia la sesión de validación del prototipo, [#55](../bitacora/REGISTRO.md))*
+
+### Lunes 27-jul — solicitud de avances de Etapa 1
+
+**Erika · 7:11 am** — “Buenos días Johan, disculpa ¿me puedes pasar los avances de la etapa 1 pls?”
+**Johann · 7:13 am** — “Buenos días Erika, sin problema”
+**Johann · 7:14 am** — “Disculpa, ¿de casualidad ya tenemos el Jira para este proyecto?”
+*(→ este mismo día por la mañana ocurre la sesión de API de Jira con Pedro, [#56](../bitacora/REGISTRO.md), donde se compromete el token PAF)*
+
+---
+
+## Acciones derivadas
+
+1. **Johann — enviar conteo de horas (Excel con entregable + actividad + horas por etapa) + propuesta ajustada** por la integración Jira→BIND. Comprometido “entre hoy y mañana” el 22-jul (es decir, para el 23-jul). ⚠️ **Verificar si ya se envió.**
+2. **Johann — preparar y entregar los avances de la Etapa 1** solicitados por Erika el 27-jul (7:11 am).
+3. **Conservar el correo del flujo de facturación de Jira** que Erika envió el 22-jul (2:26 pm) — insumo para la integración.
+4. **Pregunta abierta de Johann (27-jul):** ¿ya existe el Jira del proyecto? → se atiende en la sesión de API del 27-jul ([#56](../bitacora/REGISTRO.md)): Pedro genera el token **PAF** (1 año).
+
+## Observaciones
+
+- **Saga de reagenda:** la **validación del prototipo** pasó de jueves 23-jul 7 am → **viernes 24-jul 7 am** (Araceli, dueña del proceso, tuvo un tema personal). La **sesión de API de Jira** pasó de viernes 24-jul 7 am → viernes 24-jul 7 pm → **lunes 27-jul 7 am** (por disponibilidad de Pedro).
+- Erika reiteró dos veces la pregunta de si **se ajustará la propuesta** por el cambio de la integración Jira — es un pendiente comercial, no solo técnico.

fuentes/2026-07-22 - Flujo para dar de alta clientes nuevos,_ Transcript.txt

@@ -0,0 +1,473 @@
+Flujo para dar de alta clientes nuevos, registros en BIND las diferencias por comisión/fee-Proyecto integraciones Balam
+Wed, Jul 22, 2026
+
+0:01 - Johann
+¡Gracias por ver el vídeo! Buenos días, ¿cómo estás?
+
+0:33 - Johann
+¿Qué tal? Bien, ¿y tú?
+
+0:37 - Unidentified Speaker
+¿Qué tal todo?
+
+0:39 - Conference Room (Noe Rocha) - Speaker 1
+Bien, gracias a Dios. A ver, ya nada más faltaría... Este...
+
+0:46 - Unidentified Speaker
+¿Arturo?
+
+0:47 - Unidentified Speaker
+Y ahorita arrancamos. Va, sin problema.
+
+0:50 - Unidentified Speaker
+Bien.
+
+0:51 - Johann
+Sí, me comentan que estuvieron fuera del país.
+
+0:56 - Conference Room (Noe Rocha) - Speaker 1
+Sí, estuvimos con...
+
+0:58 - Conference Room (Noe Rocha) - Speaker 1
+algunos temas con clientes y sí nos enfrentamos bastantes días aquí de la oficina. Pero ya de vuelta para retomar actividades y avanzar con este tema que nos interesa mucho. ¿Y qué tal fue?
+
+1:12 - Unidentified Speaker
+¿A qué país fueron?
+
+1:14 - Conference Room (Noe Rocha) - Speaker 1
+Estuvimos en España con unos clientes de España y aprovechamos y dimos una vuelta allá a Polonia en Cracovia para conocer. En Europa Central Es muy bonito viajar por allá y conocer otras culturas, otras ciudades, otras lenguas. Los polacos no entienden nada. Lo bueno es que hablan muy bien inglés. Hablan muy bien inglés. Entonces te puedes entender bien.
+
+1:46 - Unidentified Speaker
+Sí, sí, sí.
+
+1:48 - Conference Room (Noe Rocha) - Speaker 1
+Sí, sí, sí. Así fue. Estuvo muy padre. Bastante recomendable. Bien lejos, está muy lejos.
+
+1:56 - Johann
+Sí, me imagino hasta el otro lado del océano.
+
+1:59 - Conference Room (Noe Rocha) - Speaker 1
+Sí, y luego todavía llegando al otro lado es, tríncate otras cuatro horas para llegar a esos lugares en vuelo, entonces, tres horas y media, cuatro horas, depende de dónde vayas. Pero sí, es impresionante, o sea, mucho bosque, mucho verde, muy bonito.
+
+2:16 - Johann
+Muy bonito.
+
+2:17 - Unidentified Speaker
+¿Qué tal, Arturo?
+
+2:18 - Johann
+Buenos días.
+
+2:19 - Unidentified Speaker
+Hola Arturo, buenos días.
+
+2:22 - Unidentified Speaker
+¿Dónde te escuchas Arturo?
+
+2:25 - Unidentified Speaker
+¿Ahí me escuchan?
+
+2:27 - Arturo Rosas Hernandez
+Ahí te escuchamos. Excelente. Buenos días, ¿cómo están? Todo muy bien.
+
+2:34 - Conference Room (Noe Rocha) - Speaker 1
+Bien, ¿y tú? Que bueno, que bueno, todo bien.
+
+2:40 - Arturo Rosas Hernandez
+Gusto saludarte Johann, ¿cómo estás?
+
+2:44 - Arturo Rosas Hernandez
+También, también, buenos días.
+
+2:48 - Arturo Rosas Hernandez
+Buenos días, buenos días.
+
+2:49 - Unidentified Speaker
+Bueno, pues listo.
+
+2:51 - Arturo Rosas Hernandez
+Pues empecemos, Johann.
+
+2:52 - Conference Room (Noe Rocha) - Speaker 1
+Yo sé que por ahí habías pedido un foro con Erika y era para ver flujos, ¿no? El flujo de clientes nuevos, los registros de Vine, las diferencias por comisión, los fideiproyectos. Esto supongo que para ajustar o documentar lo que necesitas dentro del propio desarrollo y entendimiento de cómo suceden las cosas, ¿verdad?
+
+3:17 - Johann
+Sí, justamente.
+
+3:18 - Conference Room (Noe Rocha) - Speaker 1
+Pues mira, aquí tenemos a Arturo, y un poquito escuchando también la conversación, aunque no va a estar en la presentación porque está en otros temas, está Araceli. Entonces, pues, si quieres, ve preguntando y aquí vamos aclarando con Arturo el ASIS, ¿no?, cómo está funcionando ahorita.
+
+3:37 - Johann
+Ok, de acuerdo, me parece bien. Ahora mismo, estaría bien si pudiéramos comenzar con cómo se da de alta un cliente en Bind. Los ejercicios que habíamos visto previamente eran cuando el cliente de Vine ya existía. Y esa parte ya me quedó claro y Arturo nos lo explicó muy bien. No sé si pudiéramos ver un ejemplo de cómo se crea.
+
+4:02 - Conference Room (Noe Rocha) - Speaker 1
+En la plataforma, directamente en Vine.
+
+4:04 - Arturo Rosas Hernandez
+Sí, creo que se cortó un poquito. Te cortas un poquito, Johann. Te preguntaba, Johann, ¿sería sobre la plataforma?
+
+4:12 - Conference Room (Noe Rocha) - Speaker 1
+O sea, ¿entrar a la plataforma y que desde principio a fin cómo se da un Dalton cliente, ¿verdad?
+
+4:21 - Unidentified Speaker
+En Bain.
+
+4:22 - Unidentified Speaker
+Sí.
+
+4:23 - Conference Room (Noe Rocha) - Speaker 1
+A ver, adelanta tú.
+
+4:25 - Arturo Rosas Hernandez
+Ok, déjenme para eso entonces les muestro mi pantalla y me confirman por favor cuando ya la aprenda.
+
+4:34 - Unidentified Speaker
+Ya, está bien.
+
+4:36 - Arturo Rosas Hernandez
+Ok, déjenme ver si me acuerdo, porque esto no sucede muy a menudo así que en el apartado de compras en el módulo de proveedores ahí existen todos los proveedores que tenemos dados de alta actualmente ahí los podemos consultar y me gustaría empezar con la opción de modificar entonces modificar existen dos opciones en esta pantalla que es la de editar, editar el producto como tal o simplemente eliminar. Y agregarlo.
+
+5:15 - Conference Room (Noe Rocha) - Speaker 1
+Sí, obviamente y agregarlo.
+
+5:17 - Arturo Rosas Hernandez
+Entonces, bueno, no sé qué tan importante sea la parte de modificar y eliminar, pero bueno, está aquí en esta pantalla. Y lo siguiente, la siguiente opción que nos da es obviamente exportar, importar o generar notas de crédito. Una lista de EFOS y el apartado de agregar. Entonces en el botón de agregar simplemente le damos clic y nos abre una siguiente pantalla que es la pantalla de agregar proveedor y nos pide dos pestañas de información. Una es la de detalle que incluye o pide todo el tema fiscal, por decirlo de alguna manera, y la dirección. Entonces hace poco justo dimos de alta la razón social de Frisa, entonces la información para esta pantalla de detalle se toma básicamente de la constancia de situación fiscal del cliente. Y el estado de cuenta. Exacto. Hasta aquí, hasta la parte de aquí, razón social, RFC, nombre comercial y categoría, sería la parte fiscal. Y lo siguiente es su estado de cuenta, como bien lo dijo Noe, su estado de cuenta bancaria, que sería el banco, y nada más. El banco es la cuenta clave porque los días de crédito y el monto de crédito vienen de la parte comercial, desde la parte de negociación comercial, de los acuerdos exactos, ahí la parte comercial decide o negocia con el cliente la cantidad de crédito o de días de créditos que se tendrá, el correo electrónico que se usará o se para la comunicación y la sucursal, digo aquí nosotros no tenemos sucursales todavía en BIND pero si en algún momento hubiera más de una sucursal aquí estaría la matriz como actualmente la tenemos que es la que utilizamos para todos y pudiera haber más sucursales de BALAM pues sí sobre todo de BALAM obviamente el teléfono, el teléfono de contacto o de comunicación y algunos comentarios también podemos definir la parte del lenguaje de los documentos si tenemos clientes que por ejemplo BICTEX si no mal recuerdo que la comunicación debe ser en inglés entonces para ese caso o para casos como ese elegiremos el formato o lenguaje inglés y le damos siguiente no sé si quieran que hagamos una una alta de prueba para que veamos el flujo, o solo así platicado es suficiente Johann?
+
+8:32 - Conference Room (Noe Rocha) - Speaker 1
+No sé si algo pase adicional, porque si no tenemos datos, supongo que algunos datos reales para esto. Tú dime Johann, si al menos esta primera vista te es suficiente para entender un poco ¿Cómo dar datos a un cliente? Se pide la información fiscal, su CFDI, luego su estado de cuenta. Con esa información, ahora sí volvemos aquí y aquí lo alimentamos y le damos de alta. Vamos a suponer que le dimos de alta a alguien. Vámonos a la opción de editar un usuario para ver qué datos aparecen. Digo, falta la parte de las direcciones.
+
+9:13 - Arturo Rosas Hernandez
+Ah, ok. Adelante de dirección. Obviamente, en la pestañita de direcciones pide el país. ¿A qué país corresponde? Si tenemos clientes, por ejemplo, en España, podríamos tener algún cliente en España o en Estados Unidos. Entonces, ahí hay que definirlo. El estado, el municipio, la localidad, la calle. Esta parte también viene de la constancia de situación fiscal. La colonia, el código postal, si tiene número exterior, si tiene número interior. El código de la colonia código es de opcional. La localidad. Y ahora sí, una vez que terminamos de llenar esta documentación, de esta información, le damos guardar. Y ahora sí, la pestaña anterior.
+
+9:57 - Conference Room (Noe Rocha) - Speaker 1
+Yo sumaría, Arturo, a lo que dices, es que agregar a clientes es lo mismo que agregar a proveedores, ¿verdad, Arturo?
+
+10:06 - Arturo Rosas Hernandez
+Sí, sí, correcto.
+
+10:07 - Conference Room (Noe Rocha) - Speaker 1
+Es el mismo procedimiento clientes como proveedores. Correcto. Te lo digo porque estaba viendo que había algunos proveedores también dado de alta y después de agregarlo supongo que lo que pasa es que te genera un ID de proveedor.
+
+10:25 - Arturo Rosas Hernandez
+Sí, entonces justo lo que dice Noe, la parte de agregar proveedores y agregar clientes, esta es la pestaña de agregar clientes, digo la pantalla, esa está en el módulo de ventas y clientes entonces la anterior es compras y proveedores y esta es venta y clientes ok la información como lo dijimos básicamente inicia en el botón de agregar también tiene las mismas dos pestañas detalle y direcciones básicamente se llena la misma información que mencionábamos hace un rato razón social nombre comercial y rfc Los días de crédito, el monto de crédito. Las ventas esperadas y los créditos negociados. Lista de precios, si existe lista de precios. El correo electrónico de comunicación. El número de cuenta. El descuento pactado, si existe un descuento pactado al inicio. Los teléfonos de contacto. Cómo se enteró de nosotros. Hasta ahorita este apartado no lo usamos. El uso SFDI. En algunos casos, Si tienen un CFDI específico, la mayoría de las veces todos aceptan gastos en general, pero depende de su constancia de situación fiscal. El régimen fiscal, este también viene dado por su constancia de situación fiscal y algunos comentarios finales. En el apartado de direcciones, este sí es idéntico al de proveedores, le damos guardar. Y hasta aquí, no sé si haya duda, Johann.
+
+12:02 - Unidentified Speaker
+OK.
+
+12:03 - Johann
+Hasta ahora me quedan claros los detalles que se tienen que dar de alta cuando se agrega un cliente y un proveedor. Igual, como comentan hoy, si es verdad que crear uno nuevo implicaría datos reales, ¿no? Entonces, con este proceso que la platicadito, me queda claro que datos son los que se piden.
+
+12:28 - Arturo Rosas Hernandez
+Sí, y apenas tiene unos cuantos días esta frisa, entonces hubiera sido buena oportunidad para guardarlo. Justo ayer platicábamos Sara y yo que voy a ir grabando algunos procesos que surjan como nuevos, entonces los voy a grabar y después estos tipos muy sencillos manualitos que compartí ahí con Eric para el tema de cómo generar las facturas de algunos clientes, algo parecido a hacer, ¿no? Pero grabarlo y luego generar un Word y tal vez un PowerPoint con algunas imágenes y así, hacer un tipo proceso, procedimiento muy sencillo, ir haciéndolo cada vez que se presente la oportunidad de procesos o de clientes nuevos, proveedores, facturación. O sea, Frisa ahorita justo ya vamos proceso de facturación ya tengo un caso entonces justo lo voy a grabar y lo voy a documentar para que en necesidades como esta pues ya se tenga la información y se hagan ejemplos reales bueno ok entonces una vez que se guarda la información ya podemos regresar al apartado de clientes que es básicamente como el de proveedores y aparece en listados todos los clientes que tenemos lo que decía que Freeza por aquí ya debe estar, si no mal recuerdo. Lo que está acá también es el último que registramos y justo lo que decía Noe, se le asigna un ID que es el 1016. Este ID es interno, es exclusivo de Vine y de Valamp. Si tuviéramos en algún momento Vine para diferentes empresas, pues no, serían IDs diferentes. Existen dos opciones, que es la opción de editar, como lo comentaba al inicio, en esta, si entramos, ahí vamos a ver toda la información que nosotros registramos, la parte de detalle, la parte de direcciones, la parte de los contactos, si hay adicionales, información adicional que se tenga la necesidad de agregar, y algunos archivos. Aquí podemos agregar la contancia de situación fiscal, la cuenta bancaria con la que se dio de alta, tal vez algún tema de NDA o algún contrato marco. Bueno, pues aquí lo podemos subir y quedaría ahí en un solo lugar. Desde aquí tenemos el módulo de acciones que en las diferentes pestañas, nos muestra opciones adicionales esta pantalla solamente es de visualización es editable hasta que le damos clic en el botón de editar ahí sí una vez que se cambie cualquier información pues nos dará la opción de guardarla al final antes de salir principalmente en la pestaña de detalles ahorita le voy a dar cancelar para no borrar no modificar nada que no quiera modificar y pues básicamente no sé si haya alguna duda alguna información adicional y yo nada más cuando se va a dar de alta un cliente o un proveedor pero en este caso el cliente nace primero de la propuesta comercial de la del acuerdo comercial que sigue con ese cliente y entonces si se les da se empieza a dar de alta pero primero viene del área comercial hoy vamos a tener un nuevo cliente o de evolución a esta propuesta a algo ya en firme entonces hay que empezar a darlo de alta ese es para los nacionales para los internacionales ese me imagino que no te ha tocado Arturo este pero creo que es algunos algunos datos son diferentes como el caso de Acuntia que es de europeo si no no me ha tocado pero bueno podemos ver el ejemplo de Acuntia también debería haber algún documento legal o fiscal del país o de la región en donde esté dado de alta el proveedor entonces igual pediríamos una un documento de este tipo similar al al RFC o la constancia de situación fiscal de la de la empresa pero es aterrizada a la el CFDI que dice sin efectos fiscales al ser una expresa extranjera.
+
+17:08 - Unidentified Speaker
+Correcto.
+
+17:09 - Conference Room (Noe Rocha) - Speaker 1
+Tiene una pequeña variación.
+
+17:11 - Arturo Rosas Hernandez
+Y el RFC te da un genérico, te da simplemente un consecutivo genérico y te lo propone la herramienta, entonces ahí no hay mucho que hacer. Aquí sí, lo importante, como decía Noe, es que el uso de CFDI sea sin efectos fiscales, porque esto no declara impuestos. O deduzca impuestos de ningún tipo, ni ESR ni van a nada. Adelante.
+
+17:37 - Conference Room (Noe Rocha) - Speaker 1
+Oye Arturo, no me queda duda, obviamente la factura se hace solamente PDF, no se genera XML ni se timbra nada ante el SAT, ¿verdad?
+
+17:46 - Arturo Rosas Hernandez
+Correcto, sí, qué buen comentario. Entonces, para los nacionales, una vez que generas una factura, pues te genera dos archivos, el PDF y el XML. En temas de fiscalía mexicana, el XML es el que realmente lee sobre todo los bueno cualquier sistema o los sistemas que se habían creado pero sobre todo el del SAT este es el que realmente lee la información que trae la información trae el código y es el que lee los sistemas del SAT y el pdf es simplemente una representación gráfica una imagen de lo que contiene el xml pero el xml es importante y el otro es solamente pues visual un documento visual que normalmente se usa para transacciones de personas de morales o físicas etcétera pero para los sistemas la lectura de los sistemas se hace a través del xml y porque lo menciono porque para para los proveedores nacionales por eso es sin efectos fiscales porque estos no le no se leen de ninguna forma entre sistemas o sea no genera código por decirlo de alguna manera sólo genera un archivo pdf y ese no hay forma de que lo lean los sistemas no simplemente se registra como gasto extranjero y no genera obligaciones fiscales. La información que se llena básicamente es esta, muy parecida a lo que se llena de lado mexicano, las direcciones pues también la dirección que viene contenida en el documento fiscal o legal que los puedan compartir, los contactos normalmente los que nos que tenemos. Este cliente no lo di de alta yo, entonces ahí a lo mejor faltaron algunas información. Pero hay que agregarlas. Pero sí es importante llenarlas. De hecho, que bueno, ahorita me la voy a anotar porque voy a revisar los contactos que una tenemos vez y voy de a ir llenando la información que se tenga y que no esté registrada aquí en la herramienta, básicamente.
+
+19:49 - Conference Room (Noe Rocha) - Speaker 1
+Muy bien.
+
+19:50 - Conference Room (Noe Rocha) - Speaker 1
+¿Qué más de esta parte de clientes, Johann, podrías ver? No, por esta parte ya entiendo mejor el proceso.
+
+19:59 - Johann
+Por esta parte de clientes sería todo. Mi siguiente pregunta, si es que ya no hay nada que contar en ¿Cómo es que se registra en Bind? ¿O qué se hace con esa comisión?
+
+20:36 - Conference Room (Noe Rocha) - Speaker 1
+Sí.
+
+20:37 - Arturo Rosas Hernandez
+Tengo un poco de duda, si quieres comentarlo, pero el proceso que creamos ya no nos permite ver a nosotros, o a mí, o a nosotros, o al puesto actual.
+
+20:54 - Conference Room (Noe Rocha) - Speaker 1
+A ver, si quieres, vuelvo a preguntar, Johann, solo para que ahora te escuche. A ver, dime.
+
+21:04 - Johann
+Bueno, ¿ahí me escuchó bien?
+
+21:06 - Conference Room (Noe Rocha) - Speaker 2
+Buenos días.
+
+21:07 - Conference Room (Noe Rocha) - Speaker 2
+¿Qué tal?
+
+21:08 - Conference Room (Noe Rocha) - Speaker 1
+Buenos días.
+
+21:08 - Johann
+¿Me escuchó bien? Sí. De acuerdo. Buenos días, Araceli. Buenos días. Aquí. Mi pregunta era, me comentaban que había momentos en donde los montos de factura no coincidían por una fee que ustedes pagaban, ¿cierto? Sí. Entonces, mi pregunta era, ¿qué sucedía con esa fee? Si se registraba en Pero eso ya no nos corresponde a nosotros.
+
+21:33 - Conference Room (Noe Rocha) - Speaker 2
+Quien lo registra es el despacho. Hace cuenta que nuestro proceso nada más es en hacer la conciliación y ahí siempre viene un FII y el FII depende del banco que lo mande. Por ejemplo, cuando es de Accent, si es cierto banco, nos cobra un FII. Pero, por ejemplo, si es un banco texano, nos cobra otro FII, aunque sea el depósito al mismo Banorte. Entonces, cuando se hace la conciliación, lo que nosotros pedimos es el estado de cuenta, por eso es importante, del lado del cliente, para saber cuáles facturas nos pagaron, porque nos llega un monto más o menos parecido sin el FII. Pero ese FII, quien lo hace a nivel contable y quien lo deduce y quien hace todo lo necesario, es el despacho. De nuestro lado no hay nada que hacer, No hay nada que conciliar. La conciliación nada más de nuestro lado viene del estado de cuenta de las facturas que pagaron con lo que nos depositó.
+
+22:39 - Johann
+Pero de esa parte nosotros no hacemos el asiento contable. Ok, entiendo. Entonces es el despacho quien registra este fee en BIM, ¿cierto?
+
+22:50 - Conference Room (Noe Rocha) - Speaker 2
+Exactamente. Ellos hacen un manejo contable para empatar y mapear y que no se nos vaya quedando un residual como como deuda del lado del cliente porque pues eso debería de ser, no? O sea, oye, no me pagaste los ciento cincuenta, me llegaron ciento cuarenta y dos, me debes ocho pesos. No, ellos hacen esa deducción para a nivel fiscal y contable. Siempre que digas o sabes que me pagaste el cien por ciento, aunque no haya sido así con un FI, verdad?
+
+23:19 - Conference Room (Noe Rocha) - Speaker 2
+Pero eso ya es por parte del despacho que son FIS bancarios.
+
+23:23 - Conference Room (Noe Rocha) - Speaker 2
+Exactamente.
+
+23:24 - Conference Room (Noe Rocha) - Speaker 1
+Sí, la transacción. Es lo que cobra el banco por mover el dinero de donde está a las cuentas mexicanas.
+
+23:33 - Conference Room (Noe Rocha) - Speaker 2
+Pero esa parte ya no nos corresponde a nosotros, Johann. Nada más si habría que, por ejemplo, cuando el agente de IA haga la conciliación, que identifique que ese es un fin bancario.
+
+23:47 - Johann
+¿Verdad?
+
+23:48 - Unidentified Speaker
+El proceso.
+
+23:48 - Johann
+El proceso. Ok, entiendo.
+
+23:51 - Conference Room (Noe Rocha) - Speaker 1
+sería el despacho que autoriza o por saldada una factura con con dicha diferencia exactamente a nivel contable a nivel contable digamos a nivel cuenta nosotros no vamos a poder vamos a tener a lo mejor al momento de la conciliación antes de llevar un tema contable vamos a ver la diferencia pero esa diferencia corresponde al fin no sabemos no tenemos los reyes exactos de cuánto va a ser el fin si es por un monto si es por una cantidad, si es porque ese día es el Día de la Virgen y se lo quiero cobrar más.
+
+24:26 - Conference Room (Noe Rocha) - Speaker 2
+Pero siempre viene marcado en el estado de cuenta. Por ejemplo, no es sorpresa en el sentido de que, por ejemplo, dice IVA sobre comisión, comisión de IVA. Yo lo digo porque la gente lo lee y sabe que es una comisión bancaria. Y nada más en los pagos que se reciben de moneda extranjera, es en donde tenemos un FII. Los pagos nacionales no hay ningún FII. Ahí sí nos tiene que cuadrar centavos, verdad? Y nada más en los extranjeros. Por eso en los extranjeros es súper importante que nos pasen en el estado de cuenta. El cliente, el cliente y por ejemplo, no siempre es así, porque por ejemplo, Axios nos paga a nuestra cuenta de Banorte de dólares. Pero por ejemplo, tenemos también la de Y hay otro cliente que se llama Big Tech, que nos paga directamente de un banco americano a otro banco americano. Ahí no nos quitan el fee, la comisión.
+
+25:27 - Conference Room (Noe Rocha) - Speaker 1
+O sea, la única forma que tenemos de saber el dato del fee en un pago internacional es pedirle el estado de cuenta al cliente.
+
+25:38 - Conference Room (Noe Rocha) - Speaker 2
+O por ejemplo, en Big Tech te hace match la factura con el deporte.
+
+25:44 - Conference Room (Noe Rocha) - Speaker 1
+¿Por qué? Porque ese es cuenta americana.
+
+25:47 - Conference Room (Noe Rocha) - Speaker 2
+Banco, banco americano.
+
+25:48 - Conference Room (Noe Rocha) - Speaker 1
+Pero en el caso específico del ingreso que es Europa a México. Ahí sí. Y ese fin no lo podemos identificar a menos de que nos manden del estado de cuenta.
+
+25:59 - Conference Room (Noe Rocha) - Speaker 2
+Se identifica porque en el estado de cuenta viene la comisión. Pero de todas maneras, acuérdate de que diga Johann aquí ya entramos en otro tema. En este caso de ACCIONS hay muchas facturas. Por el mismo monto. Entonces, por eso tenemos que pedir el estado adecuado.
+
+26:19 - Johann
+Para estar seguro de que la factura corresponde a qué monto. Exactamente. Entiendo. Esa parte ya me queda clara. Muchas gracias. Gracias. Entonces, este monto de fee se registra en Bain por parte del despacho.
+
+26:39 - Conference Room (Noe Rocha) - Speaker 1
+¿En los internacionales específicamente? Y para que no se obtenga un margen, una deuda por parte del cliente. Prácticamente esto lo vamos a ver más con este proveedor, con Acuntia, hoy por hoy. Puede pasar con otro cliente, sí, si tenemos otro proyecto que esté en la misma situación, que sea un banco europeo, que nos tenga que mover el dinero hasta México. Y ahí, evidentemente, pues va a venir la comisión.
+
+27:08 - Johann
+Ok. Listo. Muchas gracias por esa explicación. Ya me quedo más claro y voy a trabajar en el productivo también.
+
+27:17 - Conference Room (Noe Rocha) - Speaker 1
+Sí, y en el caso de los nacionales pues está identificado directamente en el estado de cuenta.
+
+27:24 - Unidentified Speaker
+No hay sorpresa.
+
+27:26 - Johann
+Ok, de acuerdo. Ahora, sí, por esta parte ya me quedo muy claro. Muchas gracias. Y otra cosa que me gustaría ver también es respecto a lo de Jira. Comentaba con Erika que durante las sesiones previas me mostraron el proceso y cómo es que de las solicitudes de Jira es donde nacían los tickets para una facturación. De esta manera, aunque no está la propuesta inicial, me gustaría ver la la posibilidad o proponer la solución de que desde Jira se carguen a Bind como cotizaciones, que es el primero de los pasos para llegar a hacer una factura ¿no? Porque sería cotización, prefactura y factura. Sí, yo entiendo eso perfectamente Johann.
+
+28:23 - Conference Room (Noe Rocha) - Speaker 1
+Cuando lo hablamos en su momento no estaba, no se tenía en uso Jira para el tema de las propuestas. Entonces sí, yo recuerdo perfectamente que habíamos dicho que inicialmente ni BUC ni GIRA iban a estar dentro del proceso. Lo que pasó en el tiempo es que evolucionó el proceso interno a que todo se fuera por GIRA, hoy por hoy. Entonces de lo que dijimos a lo que está pasando ahorita, hay una variante, que GIRA sí entra en la fórmula hoy por hoy. Para este tema de GIRA y explorar el tema de GIRA, cómo se va a conectar si hay un Si hay un API para extraer la información. No lo explotó yo, habría que verlo con Pedro. Y si quieres, en esta etapa que ahorita estamos de exploración, contemplarlo y ya me dices, oye, bueno, pues a lo mejor aquí va a tener que ser un pequeño ajuste y lo vemos, lo ponemos sobre la mesa, ¿sí?
+
+29:16 - Johann
+OK. Sí, me parece bien. Porque en ese caso, les quería preguntar acerca de, dentro de los tickets de gira, ¿cuál es el estatus que un ticket listo para llegar a ser facturación? Sí, mira.
+
+29:32 - Conference Room (Noe Rocha) - Speaker 1
+En teoría debe estar en completo. Hay un estatus muy específico de Jira que dice resuelto. Porque mira, aquí lo vemos. Por ejemplo, estos son todos los inicia, dale flujos un actuales. Poquito de zoom Arturo, ahí inicia, luego se va abierto y luego de abierto hacia abajo se va en proceso de facturación, ese proceso de facturación también se puede cancelar, o sea puede ser que ya no ya no ocurra nada y se cancela y ahí muere, pero vamos a seguir suponiendo que ya que se vuelve en factura.
+
+30:10 - Conference Room (Noe Rocha) - Speaker 2
+Dale para abajo.
+
+30:11 - Conference Room (Noe Rocha) - Speaker 1
+Luego se va a una validación, porque puede ser lo que vimos ahorita, es una validación para una factura nacional o es una factura extranjera. Y esas dos requieren dos procesos diferentes, como ya vimos ahorita. Y la otra nada más la pura factura. Después, ya que está en esa validación, qué tipo de moneda, qué tipo de facturación, en términos generales.
+
+30:32 - Arturo Rosas Hernandez
+Y ahora sí, se manda a facturar con todos esos preámbulos, con todos esos detalles, se van directamente a facturar en BIND aquí no dice que se facture en BIND simplemente que aquí todo lo que se tiene que facturar de ese periodo ya está digamos este ya lo tenemos claro que se tiene que ir a facturar para que quede facturado el sistema que después de esto aquí nosotros esto no cubre todo el flujo porque después esto sería a cuentas por cobrar pero digamos que hasta aquí llega el proceso ahorita al día de hoy de la facturación y por qué lo usamos en gira porque son tantos temas que de repente traemos que porque necesitamos tener una visualización de cuántas facturas hay que hacer y si ya están listas para facturar correcto y las evidencias es la documentación el histórico y las evidencias de que se facturó algo no y aparte las autorizaciones porque de repente pudiera suceder que una factura se genera por un peso cuando realmente tuvo que haber sido por 90 centavos y esa diferencia no se observó porque no hubo un flujo o un proceso de autorizaciones o revisiones entonces para eso JIRA nos sirve para crear un proceso estándar de a ver antes de que antes de que envíe esa validación nacional o a validación del pdf y xml mete la proceso de facturación y en este proceso de facturación es confirma el monto, confirma si el proveedor está dado de alta, si con su constancia de situación fiscal está vigente, si su cuenta bancaria, si tiene sus datos de cuenta bancaria o etcétera. Si tienes toda la información necesaria para facturar de manera correcta, incluido el monto que tienes que facturar.
+
+32:20 - Conference Room (Noe Rocha) - Speaker 1
+Y en teoría facturado es que ya lo hiciste en la plataforma y ya incluso en facturado ya subiste el xml.
+
+32:28 - Arturo Rosas Hernandez
+A ver no, No, no, no, estaba recopilando toda la información necesaria y ya estaba metiendo a Bind toda la información, pero resultó que decían que ya habían facturado, o sea, alguien tomó el ticket, dijo que ya había facturado, pero no había evidencia, no había evidencia de que había facturado, no había número de factura, ni cliente, no había un pdf, un xml, no había nada de evidencia y en los próximos procesos de revisión de que, oye, facturamos junio, oye, facturamos mayo, oye, ¿qué pasó en enero de dos mil veinticinco? No, pues, ¿quién sabe? Ah, bueno, no hay evidencia, entonces, nos dimos cuenta que teníamos que meter un proceso obligado de que se adjuntara un PDF, no podemos asegurar que se suba un PDF justo de la factura que se generó, o sea, no puedo asegurar que es la pero sí obligar a que suban un pdf y un xml ya si alguien no sube la factura correcta pues ya es una mentira muy grande pero la podemos detectar y para eso se metió esa validación y para lo internacional el pdf no obligado subir un pdf y obviamente tiene que ser de la factura generada esto se hizo yo nada más con lo que dice Arturo, porque si tuvimos desaciertos operativos en donde decían, es que ya facturé, y dices, pues dónde está la factura, no, pues no, ah no, pues es que sí facturé, pero facturé otra cosa, dices, o sea no, necesito que factures esto, entonces internamente necesitamos esta validación para decir, oye, ok, ya lo facturaste, ok, validame que efectivamente Aquí en Gira.
+
+34:45 - Conference Room (Noe Rocha) - Speaker 1
+Lo que hiciste en Bind. Puedes subirme los archivos a Gira. Porque lo vamos a validar, que efectivamente existe. Y ahora sí, ya podemos decir que está facturado correctamente. Entonces, a tu respuesta, ya para volver. ¿Qué estatus es el que tomamos para saber si algo ya está facturado? Facturado, que diga facturado. ¿Qué es el último status? El resuelto. Porque el anterior solamente es un proceso de validación, pero no nos dice, o sea, no nos confirmas si está bien todo lo que se hizo. Correcto. ¿Correcto?
+
+35:32 - Johann
+OK, correcto. Entiendo. Muchas gracias por este diagrama. Me queda ahora sí claro el flujo que se sigue y primero toman un ticket de Jira después hacen todo el proceso online y a la par están actualizando el ticket ¿verdad? El Jira ok de acuerdo ya me quedo claro disculpa Arturo ¿te podría pedir este diagrama?
+
+36:01 - Arturo Rosas Hernandez
+sí ¿Le saca un screen o...?
+
+36:05 - Unidentified Speaker
+Sí.
+
+36:06 - Arturo Rosas Hernandez
+Nada más que sale muy pequeño. La única forma es screenshot. Sale muy pequeño.
+
+36:15 - Johann
+El click derecho, ¿no habrá algo de copiar?
+
+36:21 - Arturo Rosas Hernandez
+Uy, se ve muy chiquito. Sí.
+
+36:25 - Unidentified Speaker
+Si no...
+
+36:26 - Unidentified Speaker
+Dale ahí donde dice...
+
+36:30 - Conference Room (Noe Rocha) - Speaker 1
+Porque también es interesante los comentarios. Hoy no, no se va a alcanzar a ver. Mira, si lo compartes. Dile a Pedro que si hay forma de verlo en una pantalla más grande. Si no, aquí en la oficina lo proyectamos en una pantalla más grande y de ahí se lo mandamos. Pero la respuesta sí, se te puede mandar. Sí, sí, sí te lo mandamos.
+
+36:50 - Arturo Rosas Hernandez
+Mejor te lo mandamos, porque se va a ver muy muy mal y no te va a servir de mucho, entonces mejor enviarlo en buen tamaño para que te sirva realmente para lo que necesites.
+
+37:04 - Johann
+De acuerdo, me parece excelente.
+
+37:07 - Arturo Rosas Hernandez
+Y ya nada más como perrequisito o como pre, que seguramente será algo que como platicábamos se puede incluir de Jira, tenemos spaces en Jira, ¿no? Entonces, ¿qué son los spaces? Déjame te lo enseño. Son diferentes módulos grandes que concentran actividades, ¿no? Actividades o tickets, tipos de tickets. Entonces, ¿por qué lo menciono? Porque está el request type, digo, el space facturación, y ahí es donde se concentra todo el tema de facturación, hay otro de administración general, otro de GEDEX y otro de recursos humanos, pero es importante mencionar que el de facturación tiene un un espacio específico, único, que es donde se concentra todo el tema de facturación, entonces creo que vale la pena mencionarlo para saber que no está revuelto con el resto de tickets, o sea que hay una forma de cerrar ese universo a un solo tipo de Que se llama, perdón, de SPACE, que se llama... FACTURACIÓN.
+
+38:25 - Unidentified Speaker
+FACTURACIÓN.
+
+38:25 - Arturo Rosas Hernandez
+Y con diferentes REQUEST TYPE. Pero ahorita solamente uno que es FACTIVACIÓN ADICIONAL, RECURRENTE. Podría haber RECURRENTE ADICIONAL o NUEVA. Pero de momento el tema de los REQUEST TYPE no cambia. Eso es para la facturación.
+
+38:41 - Conference Room (Noe Rocha) - Speaker 1
+Pero creo que en la sesión anterior platicaron con Araceli. Que también habían propuesto... Que salían de Gira, ¿no?
+
+38:49 - Arturo Rosas Hernandez
+¿Propuestas? ¿O no? ¿Propuestas?
+
+38:51 - Conference Room (Noe Rocha) - Speaker 1
+No, además vieron el puro flujo de facturación en la sesión anterior. Johannes, que yo no estuve, por eso pregunto.
+
+38:59 - Johann
+Sí, en la sesión anterior vimos el tema de cobranza.
+
+39:04 - Johann
+¿Cobranza en Gira?
+
+39:05 - Conference Room (Noe Rocha) - Speaker 1
+Ah, no, en Gira no vimos cobranza.
+
+39:08 - Johann
+Cuando estuvimos viendo Gira.
+
+39:10 - Conference Room (Noe Rocha) - Speaker 1
+La pura cobranza, sí. ¿Y el tema de Gira surgió hasta cuándo?
+
+39:16 - Johann
+Fue el primer paso dentro de la facturación, que fue una sesión antes.
+
+39:21 - Conference Room (Noe Rocha) - Speaker 1
+Ah, ya. ¿Y qué? ¿Hablaba de esto precisamente? ¿De este tema de facturación?
+
+39:26 - Unidentified Speaker
+Sí.
+
+39:27 - Johann
+Arturo me mostró un ejemplo de cómo es que o dónde es que se registra un ticket. Me mostró los campos que un ticket te pide para hacer una facturación y después ya se va al taller de y entiendo que se va a este apartado de facturación, y a partir de ahí es donde le dan seguimiento a una factura.
+
+39:52 - Conference Room (Noe Rocha) - Speaker 1
+Sí, correcto. Muy bien, aquí entonces lo único es que en esta etapa de descubrimiento, Johann, también te tendría que pasar el API para que exploraras la conexión, ¿verdad, Pedro?
+
+40:03 - Johann
+Sí, entonces con ese API yo vendría a buscar la información dentro del grupo de facturación. Y esas serían las facturas con las que se están trabajando.
+
+40:16 - Conference Room (Noe Rocha) - Speaker 1
+Con las que se trabajan. En teoría, si toda facturación se ejecuta aquí como proceso inicial y se maquila en Bind. Ok. Y algunas facturas son procesos manuales y otras son procesos ya automáticos de facturación. Que eso si quieres lo platicamos con Pedro. Yo creo que a lo mejor sería bueno tener una sesión adicional con Pedro de este tema, si te parece, para que entiendas cómo son la facturación. Hay un proceso que se llama facturación recurrente y eso sí debo explicártelo por separado, nada más para entender cómo nace, porque no es que alguien se meta y lo pida, sino es un proceso que ya está programado. Y por ejemplo Acuntia, la mayoría de las facturas de Acuntia Vienen automáticamente, ¿verdad Arturo? Como recurrentes.
+
+41:04 - Arturo Rosas Hernandez
+Sí, ya tenemos un flujo recurrente como de 30 facturas. Un poco menos. Más o menos. Entonces, en ese flujo de recurrencia, como sea, hay intervención humana. Porque los temas comerciales pueden variar. Es decir, de un mes a otro puede subir o bajar la facturación. No la cantidad de facturas, porque esa más o menos se mantiene constante. Pero a lo mejor el costo de una de esas facturas, el monto, puede variar de un mes a otro.
+
+41:37 - Conference Room (Noe Rocha) - Speaker 1
+Y esa recurrencia obedece que hay temas contractuales ya establecidos por un periodo con un proveedor, con un cliente. Entonces si yo ya tengo, es como la casa. Oye, estoy en una casa, tengo que pagar el agua, pues yo sé que mensualmente me va a llegar. Entonces mensualmente nosotros proceso de facturarle al cliente ese servicio que ya tenemos por contrato. Para no tener que hacerlo manual, ya lo hicimos en un proceso que se llama recurrencia. Y son esas facturas que comenta Arturo.
+
+42:08 - Unidentified Speaker
+Correcto. Ok.
+
+42:09 - Unidentified Speaker
+Entiendo.
+
+42:09 - Johann
+Pero eso no está en Vine.
+
+42:11 - Conference Room (Noe Rocha) - Speaker 1
+Eso lo hicimos aquí para ejecutarlo en Vine. Porque Vine no tiene, hasta donde sé, no tiene esa esa bondad de poder, oye, pues este es un contrato que vale, no sé, todo inventar. 100 pesos. Entonces, de estos 100 pesos, yo lo tengo que facturar mensualmente, no sé. Bueno, son 12 pesos y tengo que facturarle un peso por mes. Entonces, para mí estaría bien padre, te lo digo para mí, pero ahorita no estamos en ese punto. Es decir, ok, si yo sé que tiene que al final pagar 12 pesos de un contrato fijo para lo que es fijo, pues por mes me tendría que estar descontando un pesito, un pesito y se me va viendo bien. Pues todavía falta por cobrar esto y este es el efectivamente cobrado. ¿Para qué? Pues para saber que no nos estemos pasando o que está ocurriendo algo diferente en la facturación de lo que contractualmente se estableció en un acuerdo comercial. Si ya después eso cambia y hay adegregados o cosas nuevas o cosas que se agregaron, pues a lo mejor verlo por separado. Porque es importante, porque yo creo que eso también nos ayudaría a futuro y no es para ahorita, no es para meterle más leña a la situación. Que si ya tenemos un contrato y un acuerdo, pues también tengo una... ¿Cómo te lo diré? Yo ya sé cuánto es un monto a recibir durante cierto tiempo, para que ya en un tema de dinero o de movimientos fiscales o movimientos internos de lo que va a llegar, oye, ¿cuál va a ser la proyección? Ah, pues por lo menos esto, porque tenemos un contrato y esto nos da una visualización de tanto Entonces, no hemos llegado a ese punto, pero te lo platico porque probablemente después algo así busquemos explorar en todo lo que estamos haciendo.
+
+43:54 - Unidentified Speaker
+La proyección.
+
+43:55 - Conference Room (Noe Rocha) - Speaker 1
+Ahorita simplemente estamos tratando de resolver lo que tenemos. Es una forma más ágil. Pero ya una vez afinando la máquina, la proyección es importante. Y lo malo es que Vine, hasta donde yo sé, no tiene eso, ¿verdad Arturo?
+
+44:10 - Arturo Rosas Hernandez
+Sí te puede generar, pero depende de que alguien lo alimenta, entonces esa parte de alimentar pues si vendría de tus comentarios.
+
+44:18 - Conference Room (Noe Rocha) - Speaker 1
+Sí, pero a ver, por ejemplo un contrato que yo tengo por tres años con un cliente que va a ser fijo en teoría por tantos recursos, no me da esa proyección hoy por hoy. Sí, hoy por hoy no. No tengo forma de saber cuál es la proyección de un flujo de efectivo a lo largo de más de un año por lo menos. Es, al día, al corte y a lo que tú haces Arturo, es decir, oye, pues tenemos estas fracturas y el flujo es tanto porque es lo que me tiene que pagar. Es lo que me tiene que pagar.
+
+44:54 - Arturo Rosas Hernandez
+No es el acuerdo comercial que tenemos a largo plazo. Exacto. El forecast o el futuro te lo da, pero sobre lo facturado, es decir, oye, y el plazo de pago, es decir, tienes una factura a 30, 60, 90 días plazo de pago, pues entonces dices, esta factura que voy a cobrar 10 pesos me la van a pagar dentro de tres meses entonces para octubre para octubre me debería de caer el dinero no en mi cuenta bancaria entonces el forecast viene de ahí derivado de ahí pero en las cuentas por cobrar un forecast o un pronóstico a largo plazo como este que menciona 9 hoy en un contrato que se gestó o se negoció a un año a 12 24 36 meses No hay forma de declararlo en Vine.
+
+45:40 - Arturo Rosas Hernandez
+Y ahorita no es para eso, Johann.
+
+45:42 - Conference Room (Noe Rocha) - Speaker 1
+Nada más te lo platico porque a futuro quisiéramos ir afinando las cosas para ahora sí tener un forecast más real. No de lo inmediato, porque tenemos un forecast a corto plazo. Aunque tenemos contratos anuales o por más periodo, hoy por hoy no sabemos, más allá de lo que ya está en Vine por cobrar, qué es lo que esperamos recibir a lo largo del tiempo. ¿Sale? OK.
+
+46:07 - Conference Room (Noe Rocha) - Speaker 1
+Muy bien.
+
+46:08 - Unidentified Speaker
+¿Qué más, Johanna?
+
+46:09 - Conference Room (Noe Rocha) - Speaker 1
+OK.
+
+46:09 - Johann
+Por esa parte, ya me queda muy claro que esas eran las preguntas con las que venía el día de hoy. Entiendo que mañana hay una sesión para revisar y validar el prototipo. Sí, ya el prototipo con RSL. Excelente. Entonces, por el día de hoy, esas 3 preguntas acerca de los clientes, del fee. Esta parte de Gira ya me respondió muy bien. Muchas gracias. Y ya me quedó claro.
+
+46:41 - Conference Room (Noe Rocha) - Speaker 1
+Y con esto puedo seguir trabajando. JUAN MANUEL LUCERO. Muy bien, Johann. Aquí nomás estoy poniendo un penetre, mandar el flujo desde una visualización más amplia para que lo veas a detalle. Y sesión con Arturo, con Pedro, para explorar lo que es el API. Conexión en Jira. Y ya sobre eso, este, siguientes pasos para platicar.
+
+47:08 - Johann
+De acuerdo, ahora mismo estoy utilizando el token que me pasaron de Bind únicamente como lectura. Y desde Jira valdría la pena revisar esta parte de escritura para el ticket de Jira, pasarlo a cotización en Bind y hacer una prueba.
+
+47:31 - Conference Room (Noe Rocha) - Speaker 1
+Algo más controlado. Sí. Allí te pediría mucho cuidado Johann cuando lleguemos a esa instancia. Porque no tenemos ambiente de prueba. Es producción. Entonces, nada más ser muy cuidadosos de lo que vamos a hacer. Te lo pediría mucho. O sea, muy, muy medida la prueba de lo que vamos a hacer a escritura. Para no hacernos jaraquiri nosotros.
+
+47:54 - Unidentified Speaker
+¿Sale?
+
+47:54 - Unidentified Speaker
+Sale.
+
+47:55 - Conference Room (Noe Rocha) - Speaker 1
+Bueno, muy bien.
+
+47:56 - Conference Room (Noe Rocha) - Speaker 1
+Ya llegando el momento. Lo acordamos muy bien. No se nos puede salir de las manos de la plataforma. Porque en serio, se nos hace una fiesta. Y nos ha costado mucho tener el RP como lo tenemos. Entonces, listo. Sería todo. Gracias por tu tiempo, Johann. Muchas gracias a ustedes.
+
+48:14 - Johann
+Que tengan un buen día. Hasta luego. Gracias, bye.
+
+48:17 - Unidentified Speaker
+Bye.

fuentes/2026-07-27 - API de conexión con JIRA Transcript.txt

@@ -0,0 +1,173 @@
+API de conexión con JIRA
+Mon, Jul 27, 2026
+
+0:03 - Noe Rocha
+Hola Erika, buenos días. ¿Cómo estás? Bien, gracias. Todo muy bien, también. ¿Te confirmó Pedro? Sí. Vamos a esperar. Hola Johann, buenos días. Hola, ¿qué tal? Buenos días.
+
+0:21 - Unidentified Speaker
+Hola Erika, hola Pedro.
+
+0:23 - Unidentified Speaker
+Buenos días. Hola, buenos días.
+
+0:27 - Pedro Alberto Ayala Elizondo
+¿Qué tal? Buenos días.
+
+0:31 - Noe Rocha
+Bueno, pues ya estamos todos. Espero que hayan tenido un buen fin de semana. Caluroso, pero buen fin de semana. Bueno, a ver, como propósito del tema, dentro del descubrimiento que está haciendo Johann, Pedro, se ha visto que muchas partes del proceso, que en un principio no se habían especificado, están llegando a través de JIRA. Específicamente para temas de facturación. Como están haciendo de Jira, originalmente no habíamos contemplado la conectividad, pero ahorita ya vemos que va a ser necesario. Entonces, aquí lo que queremos ver contigo y que le expliques a Johann, bueno, más allá de cómo funciona Jira, sino cómo se conecta a través de un API Jira actualmente para extraer información y darle un poquito de vista de... No sé si quieras ver también el proceso ¿O nos vamos directamente a cómo funciona? ¿Cómo estamos haciendo hoy la conectividad a través del API? Sí, con la conectividad a través del API me es suficiente.
+
+1:38 - Johann
+Vale, ya está.
+
+1:39 - Noe Rocha
+Te dejo el micrófono, Pedro.
+
+1:41 - Noe Rocha
+Adelante, por favor. Muy bien.
+
+1:43 - Pedro Alberto Ayala Elizondo
+Bueno, con el API de Jira, hoy actualmente se está utilizando... Bueno, yo lo utilizo para varios tableros de servicio de TI. Entonces, yo lo utilizo para varios tableros de TI. Entonces, algunos los tengo para limpieza de usuarios, otros los hago para aprobadores, otros simplemente para conectores. Pero sus principales funciones, más que nada, es para crear y consultar actividades, tickets, el tema de aprobaciones, aprobaciones pendientes, el tema de documentos adjuntos. Sí tiene una muy amplia variedad en temas de extracción. En el que sí tiene mucho de dónde agarrar. Entonces, pues, no sé si tienes alguna pregunta en específico de la API, cómo se gestiona o cómo funciona. O si en verdad no sé si necesitas la llave como tal para generar una con alguna fecha de expiración en específica.
+
+2:46 - Johann
+Sí, una API key y también entender por ejemplo ahora que me mencionas que si tiene la posibilidad de extraer por ejemplo los ítems de un tablero y consultar el estatus y cambiar el estatus de esa tarea es es muy útil sí sí todo todo es es accionable es tanto de lectura como de edición entonces vas a poder hacer cualquier tipo de creación que se podría hacer manual pero se puede hacer de manera entonces te paso igual quieres alguna por reporte xt te funciona?
+
+3:25 - Noe Rocha
+disculpa con reporte txt?
+
+3:28 - Pedro Alberto Ayala Elizondo
+si osea con un documento txt con el api si perfecto dejeme entonces lo genero vamos a llamarle De momento vamos a llamarle... Le estamos llamando Plataforma de Automatización Financiera. Vamos a llamarlo PAF, el token, para que no haya... Vamos a hacerlo de un año de expiración. Hasta el... 27 de julio del 2027. Y te la comparto, ya la tengo, si quieres ahorita te la por correo. Excelente.
+
+4:51 - Johann
+No sé si quieren ver algo más, algo que tengan dudas del API en general.
+
+4:57 - Pedro Alberto Ayala Elizondo
+Yo creo que van a salir las dudas ya una vez estando en acción con la herramienta, empezar a extraer los datos, empezar a jugar con las consultas. Yo tengo una duda.
+
+5:12 - Noe Rocha
+El consumo de APIs es algo parecido a Vine, que te limita en cuanto a extracción?
+
+5:19 - Pedro Alberto Ayala Elizondo
+Déjeme ver, porque creo que sí tiene el consumo al lado, pero estaba viendo que no tiene como una página como la de Bind, que es Bind de desarrolladores. Entonces creo que sí tiene una que es Atlassian.
+
+5:40 - Noe Rocha
+Si quieres, nomás investiga y luego lo vemos con Johann. En este momento. Porque si voy a tener un límite de transacción por escritura o por consulta, entonces tendremos que ver cómo funciona esto sobre la operación.
+
+5:58 - Pedro Alberto Ayala Elizondo
+Sí, creo que no existe uno por día. O sea, por día no hay, por así decirlo.
+
+6:05 - Noe Rocha
+Y las APIs las generas desde tu cuenta o... Desde mi cuenta. Las puedes diferenciar, ¿verdad? Con nombre. Con el nombre.
+
+6:15 - Pedro Alberto Ayala Elizondo
+Sí, justo así las tengo diferenciadas. De hecho, una práctica sí es ir renovando constantemente, bueno, no constantemente, pero ir renovando en cierto punto los tokens para evitar ambigüedades. Entonces, todavía están ahí todas en la base de datos y van a seguir apareciendo.
+
+6:34 - Unidentified Speaker
+Ok.
+
+6:34 - Noe Rocha
+¿Qué otra consideración importante es ahí con el uso de la API? De Argentina, particularmente.
+
+6:43 - Pedro Alberto Ayala Elizondo
+Pues, como tal, es algo muy intuitivo. Es como cualquier extracción de datos mediante un API. Simplemente haciendo los comandos correctos mediante SQL o algún lenguaje, se pueden extraer los datos de manera clara. Yo, más que nada, lo utilizo para temas de SLA. Yo tengo unos SLA configurados en cada uno de los procesos que tenemos dentro de Jira. Entonces, tengo la configuración para que este, para que este API me esté arrastrando este tipo de información. Y también el tema de la facturación. ¿Con quién está la prover? ¿En qué estatus está? También han habido temas para cambiar estatus que se han podido lograr con el API.
+
+7:29 - Unidentified Speaker
+Ok.
+
+7:29 - Noe Rocha
+Muy bien. Se fue realmente bastante rápido. Entonces, ¿el acuerdo se lo mandas en un TXT? Sí, ya lo tengo.
+
+7:37 - Pedro Alberto Ayala Elizondo
+Y no sé si así como...
+
+7:40 - Noe Rocha
+hay una página de desarrolladores de Jira. Simplemente para temas de consulta que tenga que tener Johann sobre el uso.
+
+7:51 - Unidentified Speaker
+Ok.
+
+7:52 - Pedro Alberto Ayala Elizondo
+Sí, eso todo te lo incluyo ahorita en el correo como informativo. Va, de acuerdo.
+
+8:00 - Unidentified Speaker
+Muy bien.
+
+8:01 - Noe Rocha
+Johann, ya con esta información, ¿cuál sería su idea?
+
+8:06 - Johann
+¿Cuáles serían los siguientes pasos? Los siguientes pasos, de mi parte, yo revisaría la documentación de Jira. También, si me pudieran compartir pronto el nombre exacto del tablero en donde vamos a consultar los tickets, también sería útil para saber a dónde o de dónde extraer esos tickets. Entonces, yo investigo la documentación y con la piqui que me comparte Pedro, ya puedo integrarlo al prototipo que estamos haciendo.
+
+8:35 - Noe Rocha
+Pedro. Pero no sé si está identificable a través de la API. O con un nombre. Supongo que con el nombre del tablero.
+
+8:46 - Pedro Alberto Ayala Elizondo
+Pero el tablero se refiere al de Power BI.
+
+8:50 - Noe Rocha
+No, no. Es que el tablero...
+
+8:53 - Pedro Alberto Ayala Elizondo
+Corrígeme, Johann.
+
+8:54 - Noe Rocha
+Si te refieres más bien a la... Al Space? Sí, al Space. Así es.
+
+9:01 - Pedro Alberto Ayala Elizondo
+Ah, ok, ok. ¿Dónde están almacenados todos los tickets? De facturación. Sí, en la bandeja de facturación.
+
+9:10 - Noe Rocha
+Sí, porque hay varias bandejas. Entonces, para que no tengas que buscar en todas. Ser muy específico de a cuál nos referimos.
+
+9:20 - Pedro Alberto Ayala Elizondo
+Esas son las bandejas que hay por hoy. Administración General, ITS, Medilo, Recursos Humanos, Facturación. Y por hoy, donde se encuentra lo bueno es aquí.
+
+9:31 - Noe Rocha
+Ya. Y si, por ejemplo, cuando tú has hecho la revisión o has usado el API, ¿cómo identificas cuál bandeja es? Por la llave.
+
+9:44 - Pedro Alberto Ayala Elizondo
+Por la llave. Esta tiene llave AG, llave DITCM, este es RH, este es FAC y este es HD.
+
+9:54 - Noe Rocha
+Ok, entonces la llave para el tablero de facturación debería ser FC. Sí, FAC.
+
+10:00 - Unidentified Speaker
+FAC.
+
+10:01 - Pedro Alberto Ayala Elizondo
+FAC guión y el numerito. Y esos son todos los correspondientes al... Sí, lo bueno que la API de Jira es global, entonces vas a poder extraer información de todas las banderas, pero la bandeja que nos importa es facturación, pero es que hay ciertas cosas que pasan en recursos humanos que al momento de cerrarse en recursos humanos genera cosas en facturación, también en administración general. Haz de cuenta que facturación es como el, la bandeja padre y se va, es la que se alimenta de varios, de varios que vienen siendo las demás.
+
+10:41 - Unidentified Speaker
+Por procesos diferentes.
+
+10:43 - Pedro Alberto Ayala Elizondo
+Ajá.
+
+10:44 - Noe Rocha
+Que todas vienen cayendo en facturación. Muy bien.
+
+10:49 - Pedro Alberto Ayala Elizondo
+Bien, pero, eh, reviso.
+
+10:51 - Noe Rocha
+¿Qué más, Johann? Creo que con esto es suficiente.
+
+10:57 - Johann
+Igual, cuando comience a ser ya las pruebas, les comparto mis dudas, o si me hablan Hasta entonces voy a estar haciendo un script de consulta. Y si pudieran apoyarme, me gustaría también hacer un script de creación, eliminación y edición de un registro de prueba. Para ver que todo esté correcto y ya de ahí implementarlo.
+
+11:29 - Noe Rocha
+O sea ya, digamos, probar una creación de un documento, dices tú?
+
+11:35 - Unidentified Speaker
+Sí.
+
+11:36 - Noe Rocha
+Si te parece, ya cuando sea el momento de hacer la creación. Hacemos una prueba en vivo. Y veremos cómo funciona.
+
+11:48 - Johann
+Sí, sin problema. O también si tienen a la mano un script. Donde ya tengan un CRUD.
+
+11:57 - Noe Rocha
+Fíjate que no tenemos algo así, ¿verdad Pedro? A través de API no. No hemos tenido la necesidad de hacerlo. Bueno, si es el checkpoint, entonces tú nos dices, Johann, para hacer para las dudas o para alguna prueba en específico. ¿Te parece? Sí, me parece bien. Vale, pues. Bueno, pues entonces es todo. Gracias por su desmañanada.
+
+12:29 - Pedro Alberto Ayala Elizondo
+Buen inicio de semana. Igualmente. Igualmente. Bye. Muchas gracias.

fuentes/2026-07-27 - Correo - Pedro medicion de consumo API Jira y token.md

@@ -0,0 +1,57 @@
+# Correo — Pedro Ayala → Johann · medición de consumo de la API de Jira y entrega del token
+
+**Canal:** Correo
+**Fecha:** 2026-07-27, 07:40 am
+**De:** Pedro Alberto Ayala Elizondo `<pedro.ayala@balamtalentoestrategico.com>`
+**Para:** Johann · **CC:** Noe Rocha, Erika Chávez
+**Asunto:** Seguimiento: medición de consumo API de Jira y accesos
+**Relación:** cumple los compromisos de Pedro en la sesión de API de Jira del mismo día ([REGISTRO #56](../bitacora/REGISTRO.md)): entregar el token e investigar los límites de consumo.
+
+---
+
+## Transcripción del correo
+
+> Buenos días, Johan. Espero te encuentres bien.
+>
+> Gracias por la sesión y por tu tiempo. Te comparto el detalle de cómo se mide el consumo de la API de Jira, porque tiene un par de puntos que hay que tener claros.
+>
+> **Cómo funciona el límite:**
+>
+> No existe un límite de volumen del tipo "X llamadas por mes". El uso de la API tampoco genera costo adicional sobre la licencia. Lo que sí existen son los **límites de velocidad**, y actualmente son **tres independientes que operan en paralelo**:
+>
+> 1. **Cuota por puntos (por hora).** Cada llamada consume puntos según el trabajo que implica: 1 punto base más 1 punto por objeto de dominio (issues, proyectos) o 2 puntos por objeto de identidad (usuarios, grupos, roles). **Las escrituras solo cobran el punto base.** La bolsa por defecto es de **65,000 puntos por hora**.
+> 2. **Burst por segundo.** Aplica a todo el tráfico, incluido el de API token. Los defaults son **100 request por segundo para GET y POST, y 50 para PUT y DELETE**, con un bucket independiente por endpoint y por tenant. Hay endpoints con límites propios más bajos; el más notable es el de consulta de clientes de un service desk, **restringido a 5 por segundo**.
+> 3. **Límite por issue en escrituras.** **20 operaciones de escritura cada 2 segundos y 100 cada 30 segundos** sobre un mismo ticket.
+>
+> Cualquiera de los tres devuelve **HTTP 429**. El header **`RateLimit-Reason`** indica cuál se activó.
+>
+> **Sobre la página de desarrolladores para revisar consumo:** aquí la respuesta es que **no existe y es una limitante de Jira**.
+>
+> - No hay dashboard de consumo en la administración de Jira. No hay pantalla de administrador ni reporte nativo.
+> - El Developer Console de Atlassian solo sirve si uno publica una app propia, y ahí únicamente se ve el tier asignado, no el consumo de la instancia.
+> - El detalle de uso por API token requiere **Atlassian Guard Premium**, que es una licencia aparte.
+> - Existen apps de terceros en Marketplace que estiman el consumo, pero trabajan por muestreo, no con telemetría real de Atlassian.
+>
+> La **única fuente confiable son los headers de respuesta**: `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-NearLimit` (que se activa cuando queda menos del 20% de capacidad), y en respuestas 429 también `X-RateLimit-Reset`, `Retry-After` y `RateLimit-Reason`.
+>
+> Te comparto el API token en el siguiente link de Google Drive:
+>
+> `https://drive.google.com/drive/folders/1J4GZcV7gndpXJ6qlXtcpK6ZiNZbvkM_0?usp=sharing`
+>
+> Si se presenta algún problema con el acceso, estoy al pendiente.
+>
+> Saludos,
+
+## Respuesta de Johann
+
+> Enterado, muchas gracias Pedro! Saludos
+
+---
+
+## Notas e implicaciones para el desarrollo
+
+- **Cierra el pendiente de la sesión #56:** ya no hay incógnita sobre el límite. **No hay tope mensual** ni costo por uso; el diseño del sync debe respetar **límites de velocidad**, no un cupo diario como en BIND (20K/día).
+- **El sync debe autorregularse leyendo los headers** `X-RateLimit-*`: pausar/reducir ritmo cuando `X-RateLimit-NearLimit` aparezca (<20% de capacidad) y respetar `Retry-After` ante un 429. No hay dashboard, así que la telemetría vive en las respuestas.
+- **Las escrituras son baratas en puntos** (solo el punto base): favorece la capa de escritura (crear cotizaciones/tickets) frente a las consultas de identidad (2 puntos c/u).
+- **Cuidado con el límite por-issue en escrituras** (20/2 s, 100/30 s por ticket): relevante si la automatización hiciera varias escrituras sobre el mismo ticket en ráfaga.
+- ⚠️ **El token vive en el enlace de Google Drive** de arriba — tratar como credencial: descargarlo, moverlo a user-secrets / Key Vault y **no** dejarlo en texto plano en el repo ni en el disco. (El conector de Google Drive de claude.ai requiere autorización; el token no se consultó desde aquí.)

planeacion/Agenda-semana-2026-07-20.md

@@ -0,0 +1,57 @@
+# Agenda por día — semana del 20 al 24 de julio 2026
+
+Cierre de la Etapa 1. Cruza los compromisos externos del Excel enviado a Erika el 16-jul
+(`Plan-actividades-avance-2026-07-16.xlsx`), los bloques técnicos B0–B9 de [Plan-Etapa1.md](Plan-Etapa1.md)
+y los pendientes de gestión de [PENDIENTES.md](../bitacora/PENDIENTES.md). Quedan ~24–31 h de construcción.
+
+> ⚠️ Desfase a comunicar en la demo del viernes: el Excel compromete la "capa de escritura controlada"
+> al mar 22, pero por ADR-001 está bloqueada hasta después de la sesión del mié 22. Se entrega jue 23
+> en modo dry-run con flags apagados. El "modelo de facturas + migraciones" (Excel: 23–24 jul) en
+> realidad se construye primero (B1, lun 20) porque todo el sync depende de él.
+
+## Lunes 20 — fundación de datos + gestión (día de corte de Erika)
+
+**Gestión (primera hora):**
+- [ ] 📧 Enviar el correo a Noé + Pedro: salvaguardas + 5 dudas técnicas del API (borrador 1 de [Borradores-seguimiento-tecnico.md](Borradores-seguimiento-tecnico.md)). Le da a Pedro 2 días para investigar antes de la sesión del miércoles.
+- [ ] 💬 WhatsApp a Erika/Pedro: flujo de horas en Jira (borrador 2) — lunes es su día de corte.
+- [ ] 💬 Recordatorio a Erika: acceso Azure programado esta semana (condiciona el CI/CD del viernes).
+- [ ] ⏱️ Validar las horas reconstruidas en [Seguimiento-horas.csv](Seguimiento-horas.csv) (26.92 h estimadas) y confirmar/ajustar las filas del 16–19 jul.
+- [ ] 📄 Revisar los procedimientos de carga de facturas por cliente (correo de Erika 16-jul); volcar diferencias vs Discovery/prototipo en el punto 3 de [Sesion-Etapa1-2026-07-22.md](Sesion-Etapa1-2026-07-22.md).
+
+**Técnico:** ✅ **B0, B1, B2 y B3 quedaron ADELANTADOS el domingo 19 en la noche** (ver [REGISTRO #48–50](../bitacora/REGISTRO.md)): Postgres 17 local (5438), modelo migrado y sembrado, auth completa con matriz verificada, y **sync de clientes corriendo contra BIND real** (16 clientes, idempotente, dedup correcto). Hallazgo: GUIDs null en producción → modelos corregidos; mencionarlo a Pedro. 5 commits locales — **push pendiente de decisión de Johann**. El lunes queda: gestión en la mañana + **B4** (sync de facturas/cotizaciones + estados + cartera, 4.5–5.5 h) — con un día completo de colchón vs. el plan.
+
+## Martes 21 — seguridad y primer sync real (~6–8 h)
+
+- B2 Auth JWT + 4 roles + policies + bitácora de auditoría (4–5 h).
+- B3 Sync de clientes con normalización y dedup por RFC (2.5–3.5 h) — el Excel lo compromete terminando hoy.
+- Seguimiento a Pedro/Noé: arranque de la configuración de Azure (de su lado; no bloquea lo local).
+
+## Miércoles 22 — sesión de definiciones + sync de facturas
+
+✅ **B4 y B6 quedaron ADELANTADOS la noche del martes 21** (ver [REGISTRO #52–53](../bitacora/REGISTRO.md)): sync de facturas/cotizaciones con histórico completo verificado (1,494 facturas, cartera MXN/USD cuadrada contra BIND), mapper de estados puro con pruebas, y RLS aplicado (falta solo el rol local `balam_app` para la verificación de aislamiento). Hallazgo para la sesión: **todo el histórico es PUE, cero PPD** — preguntar a Arturo.
+
+- 📅 **Sesión de reglas Etapa 1 (Arturo + CEO).** Llevar [Sesion-Etapa1-2026-07-22.md](Sesion-Etapa1-2026-07-22.md) con la minuta lista y los hallazgos de los procedimientos por cliente. Salidas esperadas: alta de cliente, fee, envío, alcance Jira→BIND, frontera Emitida/Vigente, autorización de escritura.
+- Post-sesión: registrar la minuta y actualizar [Hallazgos-y-decisiones-Etapa0.md](Hallazgos-y-decisiones-Etapa0.md) (ADRs afectados).
+- Ajustar `InvoiceStatusMapper` con la frontera Emitida/Vigente definida en la sesión (es función pura: minutos).
+- Restante técnico de la semana: B5 scheduler, B7 (post-autorización), B8/B9, CI/CD viernes.
+
+## Jueves 23 — escritura controlada + validación del prototipo
+
+- Cerrar B4 si quedó cola; **correr el sync inicial del histórico en la noche — jamás en vivo en demo**.
+- B7 Capa de escritura controlada Draft→DryRun→Confirm con flags apagados y cero llamadas reales (3–4 h), ya con las definiciones del miércoles.
+- Avanzar el cierre del documento de hallazgos + ADRs (el Excel lo compromete hoy).
+- 📅 **7:00 pm — Validación del prototipo Etapa 0.** Llevar la lista de decisiones que requieren visto bueno y la separación MVP vs Anexo B (recordatorios a clientes = Anexo B; multiempresa = fuera; agentes Jira = Nivel 3).
+
+## Viernes 24 — robustez, CI/CD y cierre de etapa
+
+- B5 Scheduler 15 min con guarda de cuota + backfill (2–3 h) · B6 RLS real de Postgres (1.5–2.5 h, contractual, no recortable).
+- B8 pruebas de flujos críticos + B9 seeder + runbook (recortables a lo mínimo si aprieta).
+- CI/CD + gestión de secretos con Pedro (según acceso Azure).
+- 📅 **Demo semanal + reporte de horas.** Meta: login + roles + sync real en Postgres + cartera. Comunicar ahí el ajuste de la capa de escritura (dry-run, pendiente de autorización para escritura real).
+- Registrar cierre en bitácora y actualizar Excel de avance para Erika.
+
+## Si aprieta el tiempo (recortes ya identificados en el plan, ≈ −5 h)
+
+`GET /api/audit` y middleware post-demo (−1) · dedup solo RFC exacto (−0.5) · quotes full-scan simple (−0.5) ·
+equivalente MXN (−0.5) · backfill con tope fijo (−0.5) · B7 sin modelos provisionales si el 22 cambia el alcance (−1) ·
+seeder mínimo (−0.5). La demo del viernes exige como mínimo: login + roles + sync + cartera.

planeacion/Avance-Etapa1-2026-07-27.md

@@ -0,0 +1,69 @@
+# Corte de avance — Etapa 1
+
+**Fecha:** 27-jul-2026 (corte de los lunes, formato pedido por Erika: entregable + actividad + horas por etapa)
+**Etapa:** Plataforma base y sincronización con BIND
+**Rango estimado contractual:** 32–39 h · **Horas registradas de Etapa 1:** 19.75 h (total del proyecto: 41.58 h)
+**Adjunto:** `Plan-actividades-avance-2026-07-27.xlsx`
+
+> Documento interno de Johann. El mensaje para Erika va abajo; el resto es sustento propio (no se comparte).
+
+---
+
+## Mensaje breve para Erika (WhatsApp)
+
+> Hola Erika, buen día. Te comparto el avance de la Etapa 1 al corte de hoy (Excel adjunto, con entregable · actividad · horas por etapa como lo pediste).
+>
+> El **núcleo de la plataforma ya está construido y probado contra producción**: autenticación con roles y bitácora de auditoría, arquitectura multi-tenant con aislamiento por RLS, el cliente de la API de BIND, la sincronización de clientes, facturas y cotizaciones, el modelo central de facturas con sus estados y la cartera separada por moneda. La sincronización del histórico ya corrió y cuadró: **1,494 facturas** con sus totales de cartera coincidiendo con BIND.
+>
+> Lo que sigue pendiente es, sobre todo, la **capa de escritura (cotización→factura), que dejé en pausa a propósito hasta que definan el flujo de facturación en la sesión del martes**, ya que de ahí dependen las reglas. También quedan por cerrar el afinado de datos de prueba y la parte de Azure/CI-CD, que depende de los accesos de su lado.
+>
+> En horas voy en **19.75 h de Etapa 1** (rango estimado 32–39 h), con **6 de los 8 entregables de la etapa ya terminados**. Con la key de Jira que nos pasó Pedro hoy y las definiciones del martes, arranco la integración con Jira y la capa de escritura. Cualquier duda quedo al pendiente. 🙌
+
+*(Nota: el ajuste de la propuesta y el conteo de horas formal van por separado; este mensaje es solo el avance de Etapa 1.)*
+
+---
+
+## Sustento interno
+
+### Terminado y verificado contra producción
+- **Backend base:** autenticación con JWT propio, matriz de roles (Finanzas, Dirección, Operaciones, Administración) con policies, y **bitácora de auditoría universal** (logins, sync, transiciones, escritura). — *entregable contractual 1* ✅
+- **Multi-tenant + RLS real de Postgres** (no solo filtro EF): políticas `tenant_isolation` fail-closed en las 8 tablas de negocio + interceptor de conexión. — *entregable 2* ✅ *(verificación de aislamiento local pendiente de rol de app no-superusuario; las políticas ya están correctas — ver REGISTRO #53)*
+- **Cliente productivo de BIND** en C#: paginación OData, reintentos, control de cuota y errores; solo lectura por defecto. — *entregable 3* ✅
+- **Sync de clientes** (full-scan barato + hash + detalle solo de nuevos/cambiados, normalización RFC/nombre, dedup por RFC exacto). — *entregable 5* ✅
+- **Sync de facturas y cotizaciones** con estados normalizados, tipo de cambio y detección de pagos (fecha de detección, ADR-004). — *entregable 6* ✅
+- **Modelo central de facturas con estados** (Emitida, Vigente, Vencida, Pagada, Cancelada) como función pura con pruebas. — *entregable 7* ✅
+- **Cartera por moneda** (jamás suma monedas): `GET /api/cartera` verificado BD↔endpoint — MXN 17 abiertas $1,568,772.32 · USD 92 abiertas $320,379.06.
+- **Sync histórico corrido y verificado** (jamás en vivo): 1,494 facturas + 43 cotizaciones, detalle 1,494/1,494, idempotencia comprobada, 0 pagos falsos. (REGISTRO #52)
+- 26/26 pruebas unitarias verdes.
+
+### En construcción / en pausa
+- **Capa de escritura controlada (cotización→factura)** — *entregable 4*. **Al 40 %: diseño y modelo listos, implementación en pausa.** Ya hecho: entidad `WriteOperation` con el pipeline `Draft→DryRun→Confirmed` migrada, policy `PuedeOperarEscritura`, ADR-001, el diseño del `BindWriteClient` con flags apagados por default y la regla PPD/PUE (informada por el hallazgo de que 1,374/1,374 facturas del histórico son PUE). Falta el `BindWriteClient`, el pipeline implementado, los shapes reales de los POST y las pruebas. 🔴 **Pausa deliberada** hasta la definición del flujo de facturación (sesión martes 28-jul con Arturo/Araceli): de ahí salen las reglas de prefactura, PPD/PUE, alta de cliente y qué estatus de Jira dispara qué.
+- **Scheduler + backfill** (sync programado cada 15 min) — el sync ya funciona en manual; falta automatizarlo.
+- **Datos de prueba (seeder) + runbook** — *entregable 8*, **al 85 %**: modelo central de facturas con el `InvoiceStatusMapper` (13 pruebas) ✅, migraciones ✅; falta el seeder de datos ficticios y el runbook.
+- **Suite de pruebas de flujos críticos** (integración) — pendiente.
+
+### Dependencias externas (lado Balam)
+- **Definición del flujo de facturación/prefacturación** — sesión martes 28-jul (Erika coordina). Desbloquea la capa de escritura.
+- **Correo del flujo de facturación de Jira** (Erika lo envió 22-jul) — a incorporar.
+- **Alcance Jira → cotización BIND al 90 %:** conectividad resuelta el 27-jul (token PAF con vigencia a 1 año, API confirmada de lectura **y** escritura, bandeja **Facturación (FAC)** identificada, límites de consumo aclarados por correo de Pedro: sin tope mensual, 3 límites de velocidad, autorregulación por headers `X-RateLimit-*`). Falta el 10 %: **qué estatus de Jira dispara qué** (amarrado a la definición del 28-jul) y validar si basta escuchar FAC o hay que rastrear los procesos que nacen en RH/Administración General y caen ahí.
+- **Acceso a Azure + CI/CD** (Pedro/Noé) — condiciona el despliegue.
+
+## Criterio de medición
+- **Entregables contractuales:** **6 de 8 terminados** (1, 2, 3, 5, 6, 7). Los dos restantes van parciales y su avance se muestra en su propia fila del Excel, no promediado en el encabezado: el **8 al 85 %** (migraciones sí, seeder no) y el **4 al 40 %** (escritura: diseño y modelo listos, implementación en pausa por definición de Balam). → **El Excel reporta 75 % de Etapa 1**, contando solo entregables cerrados, que es lo verificable.
+- **Horas de Etapa 1:** 19.75 h de un rango de 32–39 h (**~51–62 % del esfuerzo estimado**).
+- Se reporta por **entregable terminado**, no por promedio ponderado de actividades. El corte anterior mostraba 82 % ponderado, que era optimista e indefendible: no distinguía entre trabajo hecho y trabajo bloqueado. "6 de 8" dice exactamente qué falta y de quién depende.
+- La brecha entre 75 % de entregables y ~55 % de horas **no es un error**: refleja que las sesiones de desarrollo asistidas por IA produjeron el núcleo en mucho menos tiempo de reloj que la estimación manual (ver la nota en `Seguimiento-horas.md`).
+
+## Horas: estado de la validación (resuelto el 27-jul)
+- **41.58 h en total** — Etapa 0: 21.83 h · Etapa 1: 19.75 h.
+- **Cero horas pendientes de validar.** 9.13 h con duración documentada (`confirmada`) y 32.45 h reconstruidas y confirmadas por Johann contra evidencia fechada (`validada`).
+- Correcciones aplicadas en este corte:
+  - Se corrigió un error de formato del CSV que ocultaba **1.00 h** del 19-jul (entorno local).
+  - Se re-etiquetó el 10-jul: la mayor parte eran 6 commits de pulido del prototipo (E0-05), no el entregable de cierre (E0-06). Mismo total, etiquetas correctas.
+  - Se incorporaron **3.50 h** de trabajo real que no estaba cobrado: diseño del plan de Etapa 1 (2.00 h, `Plan-Etapa1.md`) y preparación de las sesiones del 22 y 24-jul (1.50 h, agenda y guion de validación).
+  - **Ajustes a la baja** en las horas reconstruidas de Etapa 0: análisis del Discovery de facturación 1.92 → 1.00 h, documentación del de cobranza 1.50 → 0.75 h, guion de validación 0.75 → 0.45 h. Las duraciones de sesión documentadas en transcript no se tocaron.
+  - Cada celda de horas del Excel se genera desde el CSV y el script **falla** si el detalle no cuadra con el total.
+- **Etapa 0 cerró en 21.83 h, dentro del rango contractual de 18–22 h.**
+
+## Punto abierto (no bloquea el envío)
+- **Tono del mensaje:** el borrador enmarca la capa de escritura como "en pausa por la definición del 28-jul" — pone la pelota de su lado, y es verdad. Si prefieres suavizarlo, se ajusta.

planeacion/Correo-respuesta-Noe-2026-08-10.md

@@ -0,0 +1,56 @@
+# Correo — Respuesta a Noé/Arturo: ticket de ejemplo "como debería ser" + fecha de la prueba acompañada
+
+Enviado · 10-ago-2026
+
+Responder a todos sobre el hilo `RV: Seguimiento: medición de consumo API de Jira y accesos`
+**Para:** Noé Rocha · **CC:** Arturo Rosas; Araceli Sánchez; Pedro Ayala; Erika Chávez
+**Asunto:** (el del hilo, con `RE:`)
+
+> ⚠️ **Agregar a Arturo y a Erika al CC:** Noé mandó su correo del 7-ago solo con Araceli y Pedro en copia, pero Arturo es quien captura y define. Erika coordina agendas.
+
+**Contexto:** Noé reenvió el 7-ago las respuestas de Arturo del 4-ago, más la definición de que las pruebas serán acompañadas. Las cuatro preguntas del 30-jul quedan cerradas.
+
+**Estrategia — versión mínima.** Solo cinco cosas: agradecer, pedir el ticket de ejemplo, proponer fecha, decir dónde termina el ejercicio y recordar Azure. Todo lo demás se resuelve en la sesión o con el molde. El ticket capturado "como debería ser" hace el trabajo que antes hacían tres párrafos de preguntas: si los conceptos no caben en ningún campo, se ve en el ejemplo.
+
+**Lo que se sacó del correo y ahora hay que llevar A LA SESIÓN** (ninguno se pierde, pero ya no tienen registro escrito previo):
+
+1. 🔴 **ACUNTIA** — que el molde no cubre si Arturo captura un caso normal. `FAC-100` trae un solo monto de 7,594.00 USD para el ticket que históricamente son 40–48 facturas. **Es el riesgo más grande de alcance y ya no está pidiéndose por escrito** → preguntarlo en la sesión, o mandar un correo aparte si quieres constancia.
+2. ⚠️ **El supuesto de los tickets de `Automation for Jira`** (10 de 69, sin campos, `FAC-91` activo). Ya no queda asentado por escrito que siguen manuales, así que la carga de objetar no está de su lado. Plantearlo en la sesión.
+3. **Conceptos/partidas** — se resuelve solo con el molde, pero conviene mirar el ejemplo con esto en mente antes de la sesión.
+4. **PUE vs PPD** y **cuenta de servicio** — ya estaban diferidos a la sesión desde la versión anterior.
+
+**Alcance del ejercicio — cotización, NO prefactura.** Razones: (1) es literalmente lo que Arturo contestó el 4-ago; (2) la aprobación de Araceli está entre `En proceso de facturación` y `Facturado`, así que la prefactura pertenece *después* — Noé lo cerró como tres candados: **cotización → prefactura → aprobación humana → timbrado** ([REGISTRO #55](../bitacora/REGISTRO.md)); (3) Arturo pidió gradualismo explícito (*"para ir monitoreando la eficiencia de la IA"*); (4) una cotización se cancela sin efecto fiscal, mientras que en BIND la prefactura **no es un recurso aparte** sino un registro en `Invoices` con `UUID = null`, y los *shapes* de los POST nunca se han probado.
+
+**El disparo es manual en esta prueba.** No es un modo inventado para la ocasión: son las etapas del pipeline ya modelado `Draft → DryRun → Confirmed` (ADR-001) con los feature flags apagados. La versión automática es el mismo código con el flag encendido, y **depende de Azure** para correr continuo.
+
+> ⚠️ **Contradicción pendiente que el ticket de ejemplo resolverá solo:** el 6-jul Ara describió que **el comercial genera la cotización en BIND** y la plataforma la *convierte* a prefactura ([REGISTRO #27](../bitacora/REGISTRO.md)); el 4-ago Arturo dijo que la plataforma la *genera*; y el formulario sigue exigiendo **adjuntar la cotización**. Si ambas cosas ocurren, **quedan dos cotizaciones por ticket**. El adjunto que Arturo ponga en el ejemplo lo dirá.
+
+======================================================================
+
+## VERSIÓN FINAL (la que Johann envía)
+
+Buenas tardes, espero se encuentren bien.
+
+Gracias por las definiciones, quedan claras y ya retomé el desarrollo, ya validé que el campo "Monto sin IVA" está creado y funcionando.
+
+Para aterrizar los detalles que faltan sería de ayuda que Arturo cree hoy o mañana un ticket de ejemplo capturado "como debería ser", con todos los campos llenos tal como quieren que se capture de aquí en adelante. Contra ese molde llego a la sesión con el flujo ya funcionando.
+
+Para la sesión, ¿les funciona el miércoles 12 o el jueves 13, a las 7:00 am?
+
+El ejercicio termina en la cotización en BIND.
+
+Sigo pendiente del acceso a Azure para publicar el ambiente.
+
+Quedo atento.
+
+Saludos.
+
+======================================================================
+
+**Lo que la versión final deja fuera y por tanto pasa a la sesión (verbal, sin constancia escrita previa):**
+
+- **El destino de la cotización de prueba.** El correo ya no dice que el ejercicio genera una cotización real en BIND producción ni que se cancela al terminar. Anunciarlo al abrir la sesión, antes de ejecutar.
+- **El compromiso de compartir el script antes.** Era la condición de Noé del 24-jul. Mandarlo igual por separado cuando esté listo.
+- **La prefactura como paso siguiente** y los tres candados. Explicarlo en la sesión para que no esperen ver el flujo completo.
+- **ACUNTIA** y **el supuesto de los tickets de `Automation for Jira`** (ver arriba).
+- ✅ **El ticket de ejemplo ya tiene dueño nombrado** (Arturo). Solo falta **agregarlo al CC**: no venía en el correo de Noé del 7-ago.

planeacion/Guion-validacion-prototipo-2026-07-23.md

@@ -0,0 +1,119 @@
+# Guion — Validación del prototipo Etapa 0 (jue 23-jul, 7:00 pm)
+
+**Material:** `../prototipo/Prototipo-Balam-Etapa0.pdf` (11 páginas) + demo en paputec.mx/balam.
+**Meta de la sesión:** que digan "sí, así opera Balam" pantalla por pantalla → cierra la Etapa 0.
+**Regla de oro:** en cada pantalla, terminar con UNA pregunta de validación. No presentar; validar.
+
+---
+
+## Apertura (2 min)
+
+> "Gracias por el tiempo. Lo que van a ver es el proceso que ustedes me enseñaron en las sesiones con Araceli y Arturo, convertido en pantallas. Todo es dato ficticio. El objetivo de hoy es que me digan qué SÍ refleja su operación y qué corregimos — cada 'así no es' de hoy me ahorra semanas de desarrollo."
+
+Aviso útil: "Ayer con Arturo y Araceli aprendí cosas nuevas (fee, flujo Jira); les voy a ir señalando dónde ya sé que hay ajustes."
+
+---
+
+## Pág. 2 · El flujo de principio a fin (3 min)
+
+Recorre los 5 pasos: **Solicitud Jira → Cotización BIND → Prefactura → Aprobación humana → CFDI + Envío**.
+
+> "Este es el mapa de todo. La automatización está donde ustedes la pidieron: después de Jira, y con validación humana antes de timbrar. Aprobar y timbrar son acciones separadas — nada se timbra solo."
+
+**⚠️ AQUÍ VA LA PREGUNTA GRANDE (caja de reglas, primera línea "PPD por defecto"):**
+> "Esta regla salió del Discovery: PPD por defecto porque cobran a crédito 30–90 días. Pero al sincronizar el histórico real encontré que las 1,374 facturas con método de pago son TODAS PUE, cero PPD. ¿Es política del despacho o práctica que quieren corregir? Cambia el default de la plataforma y toca el requerimiento del SAT que ya vivieron."
+
+Anotar la respuesta — define B7 (capa de escritura).
+
+- Validar también: "¿Recordatorios de morosidad a todos los clientes, sin excepciones — sigue firme?" (lo decidió Ara el 6-jul).
+
+## Pág. 3 · Acceso (30 seg — no gastar tiempo)
+
+> "Ingreso con cuenta interna, control de sesión y roles — cada quien ve lo suyo. Esto ya está construido en el backend real."
+
+## Pág. 4 · Panel de control (4 min)
+
+Señalar en orden: facturado del mes **separado MXN/USD (nunca se suman monedas)** · emitidas vs pendientes · cartera vencida · bandeja "Qué necesita atención".
+
+> "La bandeja es el corazón: bloqueos por falta de cotización, facturas vencidas escaladas, prefacturas esperando aprobación, clientes nuevos sin cédula, facturas emitidas sin enviar. Cada línea tiene responsable y antigüedad."
+
+Dato para credibilidad: "Esto ya no es dibujo — el backend real ya sincroniza la cartera de producción: 1,494 facturas, y los totales cuadran contra BIND al centavo."
+
+**Pregunta:** "¿Son estos los 4 números que quieren ver al abrir? ¿Falta o sobra una tarjeta?" (Recordar: Pedro ya tiene Power BI de aging — esto es operación, no reporteo; no duplico lo suyo.)
+
+## Pág. 5 · Solicitudes (Jira) (3 min)
+
+> "La entrada del flujo: sin ticket, no se factura — tal como operan hoy. Filtros por estatus: por validar, listos, bloqueados, facturados."
+
+Conectar con ayer:
+> "Con lo que me mostró Arturo ayer, esto mapea directo a su space 'Facturación' y su flujo de estatus — donde 'resuelto' es el que confirma facturación válida. La sesión con Pedro para el API de Jira nos dirá si estos tickets entran solos o se capturan."
+
+**Pregunta:** "¿Las columnas (tipo, cliente, moneda, monto, crédito, recurrente, estatus) son las que Arturo necesita para decidir qué facturar?"
+
+## Pág. 6 · Detalle de la solicitud (3 min)
+
+Señalar: datos del ticket, adjuntos (cotización, OC, horas con VoBo), doble check de administración, **cotización BIND vinculada como requisito**.
+
+**Nota ⚠️ (fila "Cliente nuevo"):**
+> "Ayer Arturo me mostró el alta completa en BIND. La decisión que les pido hoy: cuando el ticket trae un cliente que NO existe en BIND, ¿la plataforma solo lo detecta y avisa a administración, o también lo da de alta? Mi recomendación para el MVP: detectar y bloquear; el alta la hace administración en BIND como hoy."
+
+Anotar decisión — cruza con la estimación de ~10 h de Jira→BIND.
+
+## Pág. 7 · Preparación, aprobación y emisión (4 min)
+
+> "Asistente de 5 pasos: cotización BIND (sin cotización no se puede continuar) → datos de factura → conceptos e IVA 16%/0% con alerta si no cuadra → prefactura en simulación, sin timbrar → aprobación humana. Aprobar NO timbra: son dos clics distintos, de dos momentos distintos."
+
+Reforzar seguridad (le importa a Noé):
+> "Y cuando llegue la escritura real: dry-run, confirmación humana por factura y feature flag apagado por defecto — como acordamos ayer, con todo el cuidado de que es producción."
+
+**Pregunta:** "¿Quién aprueba en la vida real — siempre Arturo, o hay segundo aprobador?"
+
+## Pág. 8 · Envío al cliente (3 min)
+
+> "El proceso NO termina al timbrar: termina cuando el correo sale con los adjuntos correctos. Checklist bloqueante por cliente — ejemplo CEMEX: PDF+XML automático, Excel de horas con VoBo, asunto con su nomenclatura exacta. Si falta algo, el envío se bloquea — hoy un error de estos rebota la factura y con 90 días de crédito cada rebote empuja el cobro."
+
+**Pregunta / pendiente:** "Para cargar las reglas reales necesito el Excel de particularidades por cliente que quedó con Ara y Arturo — ¿cómo va? Ya revisé los procedimientos que me mandaron el 16-jul; el Excel me completa destinatarios y nomenclaturas."
+
+## Pág. 9 · Cuentas por cobrar (3 min)
+
+> "El aging que hoy llevan en Excel, leído de BIND: por vencer, 1–30, 31–60, 61–90, +90 — MXN y USD siempre separados, el tipo de cambio DOF es solo informativo. Saldo y días de mora por factura."
+
+Credibilidad: "Los números reales ya viven en el backend: la cartera sincronizada cuadra exacta contra BIND."
+
+**Pregunta:** "¿Estos rangos de aging son los que usan? ¿Les sirve el corte por factura o necesitan también por cliente?"
+
+## Pág. 10 · Pagos y recordatorios (4 min) — LA PANTALLA CON MÁS AJUSTES DE AYER
+
+1. **Fee (caja "Tolerancia por comisión"):**
+> "Ayer Araceli me aclaró el proceso real: el fee bancario lo registra y deduce EL DESPACHO — Balam no hace ese asiento. Entonces esta pantalla se ajusta: la plataforma DETECTA la diferencia en pagos internacionales, la ETIQUETA como probable fee y avisa; quien salda es el despacho. ¿De acuerdo con ese ajuste?"
+
+2. **Fecha de detección:** "La fecha que muestro es la del registro en BIND (lo captura el despacho), no la fecha valor del banco — BIND no expone pagos individuales. ¿Les funciona así para el MVP?"
+
+3. **Recordatorios (columna derecha) — poner el límite con suavidad:**
+> "Ojo con esta parte: las alertas D+1 y el escalamiento D+15 son INTERNAS y van en el MVP. Los correos automáticos AL CLIENTE (D+5, D+30) están cotizados en el Anexo B — aquí los dejo visibles y preparados para activarse, pero no son parte de esta fase. Lo señalo para que no haya sorpresa al cierre."
+
+## Pág. 11 · Bitácora (2 min)
+
+> "Todo queda registrado: quién aprobó, quién emitió, qué override de IVA se hizo y por qué, con ticket Jira y folio BIND. Esto responde exactamente al problema que me contó Arturo ayer: 'dijeron que ya facturaron y no había evidencia'. Aquí la evidencia es automática. Y la bitácora ya existe en el backend real, no solo en el prototipo."
+
+---
+
+## Cierre (5 min)
+
+1. **Pedir el veredicto explícito:**
+> "¿Validan que este flujo representa su operación? Con su OK doy por cerrada la Etapa 0, aplico los ajustes que anotamos y el demo público lo doy de baja como quedamos."
+
+2. **Recap de decisiones tomadas hoy** (leerlas en voz alta): PUE/PPD · alta de cliente (detectar vs crear) · fee = despacho confirmado · recordatorios internos vs Anexo B · rangos de aging.
+
+3. **Siguientes pasos** (recordar compromisos de ayer): diagrama del flujo Jira en tamaño legible · sesión con Pedro (API Jira + facturación recurrente) · Excel de particularidades de envío · Azure esta semana.
+
+4. **Si el ambiente lo permite, la comercial:**
+> "Ing. Noé, ya de regreso del viaje — ¿pudieron revisar la propuesta v1.2 para lo de la facturación inicial de las 30 horas?"
+
+## Chuleta de respuestas rápidas
+
+- **"¿Y si queremos que también mande correos al cliente?"** → Está cotizado en Anexo B; la pantalla ya lo deja preparado. Lo activamos como ampliación cuando cierre el MVP.
+- **"¿Esto ya jala con BIND de verdad?"** → La lectura sí: clientes, facturas, cotizaciones y cartera ya sincronizan de producción, en solo-lectura. La escritura va con los candados acordados.
+- **"¿Cuándo estará?"** → Etapa 1 va adelantada (backend, auth, sync y seguridad por tenant ya construidos). Las fechas finas dependen de Azure y de las decisiones de hoy.
+- **"¿Multiempresa / Regiotour?"** → Fuera del MVP (un token BIND por empresa); el diseño ya lo soporta a futuro.
+- **"¿Forecast por contrato?"** → Lo dijo Noé ayer: no es para ahorita; queda anotado para una fase posterior.

planeacion/Investigacion-API-Jira.md

@@ -0,0 +1,411 @@
+# Investigación de la API de Jira — qué probar exactamente
+
+**Fecha:** 30-jul-2026 · **Actualizado:** 10-ago-2026
+**Propósito:** lista cerrada de pruebas y preguntas para habilitar la integración **Jira → cotización BIND** (estimada en ~10 h, [REGISTRO #51](../bitacora/REGISTRO.md)). Documento de trabajo interno; sirve también como briefing para el agente/chat especializado en la API de Jira.
+
+**Estado validado (30-jul):**
+- Sitio: `https://balam-jsm-temp.atlassian.net`. El token regenerado de Pedro, usado con Basic auth y `pedro.ayala@balamtalentoestrategico.com`, respondió **200** a `GET /rest/api/3/myself`.
+- Facturación es el proyecto JSM **`FAC`** (`projectId: 10034`, `serviceDeskId: 35`), de tipo `service_desk` y estilo `classic` (company-managed).
+- La búsqueda de FAC devolvió **66 tickets**. La API vigente es `GET /rest/api/3/search/jql`, con paginación por `nextPageToken`; el endpoint clásico `/rest/api/3/search` responde **410 Gone**.
+- Estatus confirmados: `Open`, `En proceso de facturación`, `En espera por colaborador`, `En validación nacional`, `En validación extranjera`, `Facturado` y `Cancelado`. No se observó un estatus llamado “Resuelto”.
+- Límites de consumo ya aclarados por Pedro (sin tope mensual; 3 límites de velocidad; telemetría solo en headers `X-RateLimit-*`).
+
+---
+
+## ⭐ Decisiones de negocio recibidas (correo del 7-ago) y su verificación por API (10-ago)
+
+Balam contestó las tres preguntas del 30-jul. Arturo respondió el **4-ago** (en verde sobre el correo de Noé), Noé lo reenvió el **7-ago**. Fuente: `RV_ Seguimiento_ medición de consumo API de Jira y accesos.eml`.
+
+| Decisión de Balam | Quién / cuándo | Verificación por API (10-ago) |
+|---|---|---|
+| La cotización BIND **se genera al entrar a `En proceso de facturación`** | Arturo, 4-ago | ✅ Estatus y transición `Iniciar facturación` ya inventariados (Bloque 3) |
+| **Todo se tramita como facturación normal**; el caso recurrente espera a que se explore el módulo de Proyectos de BIND | Arturo, 4-ago | ⚠️ El campo `Facturación recurrente` sigue siendo **obligatorio** y se está llenando (FAC-100: `Si`, periodo `12`) |
+| Se observan **todos los request types** de la bandeja de facturación, no solo `Facturación adicional` | Arturo, 4-ago | 🔴 **10 de 69 tickets no tienen request type alguno** y ninguno trae campos de facturación (ver Bloque 1) |
+| Monto y conceptos van **como campos de Jira**, no del adjunto; **omitir el campo de recurrencia** | Arturo, 4-ago | ⚠️ `Monto sin IVA` ya existe y funciona; **`conceptos` no existe como campo en todo el sitio** (ver Bloque 2) |
+| Las pruebas de escritura son **prueba acompañada sobre un ticket**, no proyecto `FACTEST` | Noé, 7-ago | Se descarta el sandbox en la instancia de Balam → aplica el protocolo del Bloque 6 sin excepción |
+
+**Lo que sigue abierto tras estas respuestas:** de dónde salen los **conceptos/partidas** de la cotización, qué hacer con los tickets sin campos estructurados, si nacional/extranjero cambia la cotización o solo el paquete de salida, **PUE vs PPD**, la fecha de la prueba acompañada y la migración a cuenta de servicio.
+
+---
+
+## Bloque 0 — Acceso autenticado ✅
+
+El 401 del 29-jul quedó explicado por la combinación de token previo y datos de conexión incompletos. Pedro confirmó el correo, regeneró el token y compartió el dominio del sitio.
+
+**Configuración que funcionó:**
+```text
+GET https://balam-jsm-temp.atlassian.net/rest/api/3/myself
+Authorization: Basic base64(pedro.ayala@balamtalentoestrategico.com:<token>)
+Accept: application/json
+```
+
+El resultado fue **HTTP 200**. Por tanto, para esta integración se usará la API directa del sitio con Basic auth; no hay evidencia de que se requiera una ruta `api.atlassian.com/ex/jira/{cloudId}`.
+
+**Prueba canónica de auth (la primera que debe correrse siempre):**
+```
+GET /rest/api/3/myself
+```
+Interpretación de la respuesta:
+- **200** → auth OK; además devuelve `accountId` (identidad con la que la plataforma va a escribir — dato de gobierno, ver Bloque 7).
+- **401** → credencial inválida/inactiva o esquema mal armado.
+- **403** → credencial VÁLIDA pero sin permiso → problema de permisos, no de token. Distinguir 401 de 403 es el diagnóstico más barato que existe.
+
+> ⚠️ **Registrar siempre los headers de la respuesta 401 completos.** Ahí vive la pista (`WWW-Authenticate`, `X-Seraph-LoginReason`, `X-Failure-Category`).
+
+---
+
+## Bloque 1 — Topología: Jira Service Management confirmado ✅
+
+FAC está confirmado como **Jira Service Management (JSM)**. Por ello la integración requiere dos familias de API:
+
+| API | Para qué | Cuándo usarla |
+|---|---|---|
+| `/rest/api/3/...` | Issues genéricos: JQL, campos, transiciones, adjuntos, changelog | Lectura/sync, transiciones, trazabilidad |
+| `/rest/servicedeskapi/...` | Requests de portal: request types, campos del formulario, aprobaciones, SLA, comentarios públicos vs internos | Crear tickets como los crea un humano; leer aprobaciones y SLA |
+
+**Resultados:**
+```
+GET /rest/api/3/project/FAC
+```
+→ `projectTypeKey: service_desk`, `style: classic`, `id: 10034`.
+
+```
+GET /rest/servicedeskapi/servicedesk
+```
+→ FAC corresponde a `serviceDeskId: 35`.
+
+Request types **publicados en el portal** (`GET /rest/servicedeskapi/servicedesk/35/requesttype`, `isLastPage: true`):
+
+| requestTypeId | Nombre | Campos obligatorios |
+|---:|---|---:|
+| 84 | Bajas | 7 |
+| 83 | Facturación adicional | 10 |
+| 389 | Automatización | 1 (solo `summary`) |
+| 12 | Facturación | 1 (solo `summary`) |
+
+Contratos verificados el 10-ago con `/requesttype/{id}/field`:
+
+| Request type | Hallazgo |
+|---|---|
+| **Bajas** (`84`) | Empresa origen, Summary, adjunto de Cálculo/VoBo de Finiquito, Nombre del Cliente, Nombre del Colaborador, Fecha de la Baja y Motivo de la Baja. |
+| **Facturación adicional** (`83`) | Empresa origen, `MES / DESCRIPCIÓN / CLIENTE` (es el `summary`), Cliente Nuevo, Nombre del Cliente, adjunto de cotización/CSF, Tipo de Moneda, Días de Crédito, Facturación recurrente, Periodo de recurrencia y **`Monto sin IVA`**. Es el contrato más completo. ⚠️ **Cambió desde el 30-jul:** se agregó `Monto sin IVA` y desapareció `Periodo de Incidencias`. |
+| **Automatización** (`389`) | Solo exige Summary. |
+| **Facturación** (`12`) | Solo exige Summary. |
+
+### 🔴 “Todos los request types” incluye tickets sin request type
+
+La bandeja de FAC muestra en el filtro de la UI **6 de 6** opciones: las 4 de arriba más **`Empty`** y **`Emailed request`**. Ninguna de esas dos aparece en `servicedeskapi` porque no están publicadas en el portal. El conteo real sobre los **69 tickets** de FAC (10-ago):
+
+| Request type | Tickets | c/Monto | c/Moneda | c/Cliente | c/Adjunto |
+|---|---:|---:|---:|---:|---:|
+| 83 — Facturación adicional | 48 | **2** | 48 | 48 | 48 |
+| **(sin request type)** | **10** | 0 | 0 | 0 | 3 |
+| 84 — Bajas | 6 | 0 | 0 | 6 | 6 |
+| 389 — Automatización | 4 | 0 | 0 | 0 | 4 |
+| 12 — Facturación | 1 | 0 | 0 | 0 | 1 |
+
+Los **10 tickets sin request type** tienen `creator` y `reporter` = **`Automation for Jira`**: nacen de una regla de Automation desde otras bandejas (HH, SA, IN, RH), no del portal. Y **no son ruido**: `FAC-91` es uno de ellos, está vivo en `En validación nacional` y su summary es `[FACTURA COMPLETA - Staff Augmentation] Axians - Incident Manager — RH-36`. Es decir, **hay facturación real entrando por una vía que no tiene ni un solo campo estructurado** — los datos viajan codificados en el `summary` y en la `description` (ADF), más 2 adjuntos.
+
+`Emailed request` hoy tiene 0 tickets, pero existe en la configuración: cualquier correo a la bandeja aterriza ahí, también sin campos.
+
+**Implicación:** el acuerdo literal “todos los request types” significa que **~14% de los tickets no puede generar una cotización automática** con el diseño de campos estructurados. Hay dos salidas y conviene que Balam elija explícitamente: (a) acotar la automatización a los request types que sí traen campos y dejar los demás en tratamiento manual, o (b) que Automation for Jira propague los campos al crear el ticket en FAC. La opción (b) es trabajo del lado de Balam, no de la plataforma.
+
+---
+
+## Bloque 2 — Modelo de datos del ticket FAC (el mapeo) 🔴
+
+Esto es lo que decide si la integración es de 10 h o de 25. **La pregunta de fondo: ¿los datos de facturación vienen en campos estructurados o en texto libre?** Si vienen en texto libre, hay que negociar campos nuevos con Pedro o meter parsing frágil.
+
+**Lo que la plataforma necesita de cada ticket para armar una cotización en BIND:**
+
+| Dato requerido | Por qué | Qué verificar |
+|---|---|---|
+| Cliente | Match contra `Clients` de BIND (por RFC o nombre normalizado) | ¿Campo custom? ¿Lista desplegable? ¿Texto libre? ¿Trae RFC? |
+| Monto y moneda | Cotización BIND; la cartera **jamás mezcla monedas** | ¿Campo numérico? ¿Viene la moneda separada o embebida en el texto? |
+| Nacional vs internacional | Determina PDF+XML (nacional) vs solo PDF (extranjero) | ¿Se deduce del cliente o hay campo/etiqueta? |
+| Concepto / descripción | Línea de la cotización | Ver formato (ver ⚠️ ADF abajo) |
+| Tipo de solicitud | adicional / recurrente / baja / headhunting / staff augmentation | ¿Request type, issue type, o campo? |
+| Folio `FAC-nnn` | Trazabilidad ticket ↔ cotización ↔ factura (persistir en el modelo) | Confirmar formato y estabilidad (ver Bloque 5, ⚠️ moves) |
+| Solicitante / área | Auditoría | `reporter` vs `requester` de JSM (no son lo mismo) |
+| Adjuntos | Constancia fiscal, Excel de horas (CEMEX), estado de cuenta | Cómo se descargan y con qué auth |
+
+**Resultados de lectura:**
+```
+GET /rest/api/3/issue/FAC-98?expand=names,renderedFields
+```
+→ caso real de tipo Bajas: cliente Axians, colaborador, fecha y motivo de baja en campos estructurados; una evidencia adjunta; sin descripción. Los valores de texto enriquecido regresan como ADF.
+
+### Mapeo de campos confirmado (10-ago)
+
+| Campo de Jira | `fieldId` | Tipo | Valores | → BIND |
+|---|---|---|---|---|
+| Empresa origen | `customfield_11423` | option | `Balam`, `RegioTurk`, `Helmstone` | Emisor (multi-empresa) |
+| MES / DESCRIPCIÓN / CLIENTE | `summary` | string | texto libre | Referencia / parseo de respaldo |
+| Cliente Nuevo | `customfield_10052` | option | `Si`, `No` | Decide si hay que dar de alta el cliente |
+| Nombre del Cliente | `customfield_10202` | **ADF** (textarea) | texto enriquecido | Match contra `Clients` de BIND |
+| Tipo de Moneda | `customfield_10053` | option | `MXN`, `USD`, `OTRO` | Moneda de la cotización |
+| Días de Crédito | `customfield_10054` | option | `30`, `45`, `NA` | Condiciones de pago |
+| Facturación recurrente | `customfield_10552` | option | `Si`, `No` | Fuera de alcance por ahora (Arturo, 4-ago) |
+| Periodo de recurrencia | `customfield_10553` | string | texto | Fuera de alcance por ahora |
+| **Monto sin IVA** | **`customfield_11556`** | **number/float** | — | **Total de la cotización** |
+| Approvers | `customfield_10003` | array/user | — | Gobierno (ver Bloque 3) |
+
+⚠️ **`Nombre del Cliente` es ADF, no string.** El match contra BIND tiene que extraer texto plano de un documento estructurado, no leer un campo de texto. Nada garantiza que el nombre escrito a mano coincida con la razón social en BIND; **el campo no trae RFC**, que sería la llave confiable.
+
+### 🔴 Dos huecos que el acuerdo del 4-ago no cierra
+
+1. **`Monto sin IVA` existe pero está prácticamente vacío.** Solo **2 de 69** tickets lo tienen: `FAC-100` y `FAC-101`, ambos creados el **4-ago** — el mismo día en que Arturo contestó el correo. El campo se agregó en ese momento; los 67 tickets anteriores lo tienen en `null`. Es buena noticia (el acuerdo ya se implementó) con dos consecuencias: no hay histórico para validar el mapeo contra facturas reales, y la obligatoriedad solo aplica al crear por portal — un ticket nacido de Automation entra con `null` igual.
+
+2. **`conceptos` / partidas no existe como campo en NINGUNA parte del sitio.** `GET /rest/api/3/field` filtrado por monto/concepto/partida/importe/precio/cantidad/RFC devuelve únicamente:
+   - `customfield_11556` — `Monto sin IVA` (en uso)
+   - `customfield_11522` — `Monto con IVA` (existe, **no está en el formulario 83**)
+   - `customfield_10031` — `Total forms` (de JSM, no es de facturación)
+
+   Con un solo monto agregado **no se pueden armar partidas**: la cotización BIND queda de una sola línea con la descripción del `summary`. Eso puede ser aceptable como decisión, pero **hay que tomarla explícitamente**, y no cubre el caso ACUNTIA. Que exista `Monto con IVA` sin usar además abre la pregunta de si el IVA lo calcula BIND o viene dado.
+
+**El caso ACUNTIA ya tiene evidencia:** `FAC-100` es exactamente eso — summary `Julio/CONSULTORIA Y SERVICIOS (Eduardo Fiallo CEMEXUSA)/ACUNTIA`, `Helmstone`, `USD`, 45 días, `Monto sin IVA = 7594.00`, con 2 adjuntos. **Un solo monto para un ticket que históricamente representa 40–48 facturas** ([REGISTRO #55](../bitacora/REGISTRO.md) punto 6). El supuesto “un ticket → una cotización” necesita confirmarse contra este caso antes de codificar.
+
+> ⚠️ **ADF (Atlassian Document Format).** En Jira Cloud v3, `description` y los comentarios **no son texto plano ni wiki markup: son JSON estructurado**. Hay que decidir ya si se parsea ADF o se pide `expand=renderedFields` (HTML). Y al **escribir** comentarios/descripciones hay que **construir ADF válido**, no mandar un string. Es la trampa que más tiempo cuesta si se descubre tarde.
+
+> ⚠️ **Adjuntos:** confirmar si `content` (URL de descarga) requiere el mismo Basic auth y si redirige. Y aplica la misma regla que con BIND: los adjuntos traen **datos reales de clientes** (constancias, estados de cuenta) — no van a disco del repo ni a documentos.
+
+---
+
+## Bloque 3 — Workflow, estatus y transiciones (el disparador) ✅🟡
+
+**Disparador confirmado por Arturo el 4-ago: la cotización BIND se crea al entrar a `En proceso de facturación`.** El inventario técnico ya estaba levantado, así que la regla de negocio queda cerrada.
+
+**Inventario confirmado:**
+```
+GET /rest/api/3/project/FAC/statuses          → estatus por tipo de issue, con id y statusCategory
+```
+
+| Estatus | ID | Categoría |
+|---|---:|---|
+| Open | 1 | To Do |
+| En proceso de facturación | 10305 | In Progress |
+| Facturado | 10306 | Done |
+| En espera por colaborador | 10339 | In Progress |
+| Cancelado | 10372 | Done |
+| En validación nacional | 10635 | In Progress |
+| En validación extranjera | 10669 | In Progress |
+
+**Transiciones de lectura confirmadas** (son contextuales al estatus actual):
+
+| Ticket / estatus actual | transitionId | Destino |
+|---|---:|---|
+| FAC-98 / En proceso de facturación | 6 | En espera por colaborador |
+| FAC-98 / En proceso de facturación | 8 | En validación nacional |
+| FAC-98 / En proceso de facturación | 9 | En validación extranjera |
+| FAC-98 / En proceso de facturación | 2 | Cancelado |
+| FAC-91 / En validación nacional | 2 | Cancelado |
+| FAC-89 / Cancelado | 12 | Open |
+
+`FAC-97` ya está Facturado y no expone transiciones. Las respuestas consultadas no devolvieron campos obligatorios para las transiciones anteriores. Aun así, no se ejecutará ninguna transición sin la sesión acompañada.
+
+**Diagrama de workflow compartido por Balam:** confirma la ruta completa y los nombres de transición:
+
+```text
+Open --[Iniciar facturación]--> En proceso de facturación
+En proceso de facturación --[Pausar actividad]--> En espera por colaborador
+En espera por colaborador --[Retomar actividad]--> En proceso de facturación
+En proceso de facturación --[Validar documentación nacional]--> En validación nacional
+En proceso de facturación --[Validar documentación extranjera]--> En validación extranjera
+En validación nacional o extranjera --[Facturación completa]--> Facturado
+En validación nacional o extranjera --[Rechazar actividad]--> En proceso de facturación
+```
+
+El diagrama también contempla cancelación desde los estados de trabajo y reapertura; la API confirmó al menos `Cancelado --[Reabrir Ticket]--> Open` en FAC-89. **No existe un estado “Resuelto” en el workflow.** Con la respuesta del 4-ago, la regla queda: **`Iniciar facturación` (Open → En proceso de facturación) dispara la cotización**; `Facturado` confirma que la factura se emitió.
+
+### 🔴 Hallazgo crítico: el estatus disparador dura minutos, no horas
+
+Recorrido real de `FAC-100` (4–5 ago), desde su changelog:
+
+| Hora | Transición | Autor |
+|---|---|---|
+| 05-ago 11:51:25 | `Open` → **`En proceso de facturación`** | Arturo Rosas |
+| 05-ago 11:54:09 | → `En validación extranjera` | Arturo Rosas |
+| 05-ago 12:16:37 | → `Facturado` | **Araceli Sánchez** |
+
+**El ticket estuvo 2 minutos 44 segundos en el estatus disparador**, y 25 minutos de punta a punta. Hoy solo **1 de los 69 tickets** está parado en `En proceso de facturación` (65 ya están `Facturado`).
+
+**Consecuencia de diseño, no negociable:** un poller de 15 min que pregunte *“¿qué tickets están hoy en `En proceso de facturación`?”* **se pierde la mayoría de los disparos**. La detección **tiene que leer el changelog** y buscar el *cruce* de estado dentro de la ventana, exactamente como se resolvió la detección de pagos en BIND (ADR-004). Esto confirma y vuelve obligatorio lo que antes era una preferencia de arquitectura, y refuerza el caso de los webhooks (Bloque 4) para reducir la latencia.
+
+### ⭐ Hallazgo nuevo: el workflow tiene aprobaciones de JSM
+
+Ni FAC-98 ni el diagrama lo mostraban. Tanto `FAC-100` como `FAC-91` traen:
+- `customfield_10003` **Approvers** = `Araceli Sánchez`
+- `customfield_10025` **Approvals** = el estatus donde vive la aprobación (`En validación extranjera` / `En validación nacional`)
+
+Es decir, **el paso a `Facturado` pasa por una aprobación formal de Araceli**, no por una transición simple. Implicaciones: (1) la plataforma **no debe intentar aprobar** — eso es decisión humana; (2) si algún día tuviera que transicionar a `Facturado`, la vía correcta es `/rest/servicedeskapi/request/{id}/approval`, no `/transitions`; (3) la aprobación es un buen punto de trazabilidad para saber quién autorizó cada factura.
+
+⚠️ **Trampas:**
+1. ~~**`Facturado` como estatus ≠ campo `resolution`.**~~ **Resuelto (10-ago):** en `FAC-100`, `status = Facturado` **y** `resolution = Done` **y** `resolutiondate` poblada, todo consistente. Ambas señales sirven; se usará el cruce de estatus en el changelog por coherencia con el resto del diseño.
+2. **Las transiciones son contextuales**: `/transitions` solo devuelve las salidas del estado actual, y pueden tener **pantallas con campos obligatorios**. Probar con `expand=transitions.fields` para saber si transicionar por API exige llenar algo.
+3. **`issuetype` de FAC es `admon`**, no “Service Request”. Cualquier JQL o creación por API debe usar ese nombre.
+
+**Changelog = la fuente de la detección.** `expand=changelog` da cada cambio de estatus con timestamp y autor. Verificado en FAC-100 (`total: 6`) y FAC-91 (`total: 8`): vienen completos y sin paginar en tickets de este tamaño. Para tickets con mucho historial hay que usar `/rest/api/3/issue/{key}/changelog`, que sí pagina.
+
+---
+
+## Bloque 4 — Estrategia de sincronización: polling vs webhooks 🟡
+
+El scheduler de la plataforma ya existe (`BackgroundService` + `PeriodicTimer` a 15 min). La pregunta es qué le pega a Jira.
+
+**a) Búsqueda por JQL — validado.**
+El endpoint clásico `GET /rest/api/3/search` respondió **410 Gone**. La integración debe usar `GET /rest/api/3/search/jql`, con `nextPageToken`. La lectura de FAC recuperó 66 tickets con ese mecanismo.
+
+JQL de delta a validar:
+```
+project = FAC AND updated >= "-20m" ORDER BY updated ASC
+```
+⚠️ **`updated` en JQL tiene granularidad de minuto**, no de segundo → el checkpoint necesita **ventana de solape** (igual que el re-barrido de facturas abiertas de BIND) o se pierden tickets en el borde.
+
+Validar también: `fields=` para pedir solo lo necesario (menos payload, menos puntos), y el tope real de `maxResults`.
+
+**b) Webhooks.** Tres caminos, con dueños distintos:
+
+| Opción | Quién la configura | Nota |
+|---|---|---|
+| Webhook de sitio (admin) | **Pedro** (requiere admin de Jira) | El más limpio; exige endpoint público |
+| **Regla de Jira Automation** con "Send web request" | **Pedro, sin escribir código** | La más realista a corto plazo; se puede acotar a FAC y a un estatus |
+| Webhook dinámico vía OAuth app | Desarrollo | **Expiran a los 30 días**, hay que refrescarlos |
+
+**Recomendación:** **arrancar con polling** y dejar el webhook para después. Ningún webhook sirve hasta que exista un endpoint público, y Azure sigue pendiente del lado de Balam. El polling además es reversible y no depende de que Pedro toque su instancia.
+
+**c) Rate limits — headers verificados ✅ (10-ago).** La respuesta de `/rest/api/3/search/jql` sí los emite:
+
+```text
+X-RateLimit-Limit: 350
+X-RateLimit-Remaining: 348
+RateLimit-Policy: "jira-burst-based";q=100;w=1
+RateLimit: "jira-burst-based";r=348;t=1
+```
+
+Tres notas: (1) la telemetría existe y el autorregulado por headers es viable, como se le dijo a Erika el 29-jul; (2) el límite observado es **350**, no los 100/s que mencionó Pedro — hay que leer el header y no hardcodear el número; (3) aparecen también los headers estándar `RateLimit-*` (RFC) además de los `X-RateLimit-*`, así que el cliente debe tolerar ambos. `X-RateLimit-NearLimit` no apareció porque no se llegó al 20% del umbral. No se provocó un 429 deliberadamente contra producción.
+
+---
+
+## Bloque 5 — La bandeja padre: de dónde nacen realmente los tickets 🟡
+
+Pedro dijo que procesos que **se cierran en RH o Administración General caen en Facturación**. Técnicamente eso puede ser cuatro cosas distintas, y cada una se sincroniza diferente:
+
+| Mecanismo | Cómo detectarlo | Implicación |
+|---|---|---|
+| **Issue link** (RH-45 relacionado con FAC-89) | `issuelinks` en el issue | Escuchar FAC basta; el link da contexto |
+| **Clon / creación por Automation** | `changelog` + campo `creator` (usuario de automation) | Escuchar FAC basta |
+| **Subtarea / hijo** | `parent` / `subtasks` | Relevante para ACUNTIA (1 ticket ↔ 40 facturas) |
+| **Move entre proyectos** | `changelog` con cambio del campo `project` | 🔴 **La llave del ticket CAMBIA** (RH-45 → FAC-89). Cualquier folio persistido se rompe |
+
+**Resultado de la prueba (10-ago): es creación por Automation, no move. ✅**
+
+Los 10 tickets sin request type tienen `creator` = `reporter` = **`Automation for Jira`**, y sus changelogs (revisados en FAC-91) **no muestran cambios de `project` ni de `key`**. El patrón es: la regla de Automation **crea** un ticket nuevo en FAC y lo **liga** al original con `issuelinks`. Ejemplos de summary, que llevan el origen embebido:
+
+```text
+FAC-91   [FACTURA COMPLETA - Staff Augmentation] Axians - Incident Manager — RH-36
+FAC-1    Seguimiento del Ticket Cerrado: HH-1 - Prueba #1
+FAC-28   Seguimiento del Ticket con pago anticipado: HH-8 - TLE
+```
+
+Se ven tres bandejas de origen: **HH** (headhunting), **SA** (staff augmentation), **IN**, y **RH**. Dos patrones de regla: `Seguimiento del Ticket Cerrado:` y `Seguimiento del Ticket con pago anticipado:` — el segundo probablemente implique PUE y toca la pregunta pendiente de PUE/PPD.
+
+**Conclusiones para el modelo de datos:**
+- **Escuchar FAC basta** para detectar el disparo; el origen se obtiene de `issuelinks` sin salir del proyecto.
+- No hay evidencia de moves, así que la llave `FAC-nnn` **parece** estable. Aun así conviene **persistir el `issue.id` numérico** (FAC-100 = `17308`, FAC-91 = `14348`): es inmutable por diseño y el costo de guardarlo es cero.
+- ⚠️ Estos tickets son la vía sin campos estructurados del Bloque 1. Si la automatización debe cubrirlos, **la regla de Automation de Balam tendría que propagar los campos** al crear el ticket en FAC.
+
+---
+
+## Bloque 6 — Escritura (CRUD): qué probar, cómo aprobarlo y dónde 🔴
+
+**Confirmado por Noé el 7-ago: prueba acompañada sobre un ticket acordado. No habrá proyecto `FACTEST`.** Eso cierra la pregunta pero **deja el riesgo intacto**: se escribirá en producción, y el token tiene permisos para crear, editar, transicionar, comentar, adjuntar e incluso borrar tickets en FAC. El protocolo de abajo pasa de recomendación a requisito, y el sandbox propio (ver recuadro al final del bloque) pasa de opcional a necesario para desarrollar sin tocar Balam.
+
+**Protocolo obligatorio para cualquier prueba de escritura:**
+1. Preparar un script idempotente y de una sola operación; sin bucles, sin búsquedas masivas y sin credenciales embebidas.
+2. Compartir el script y el payload de ejemplo con Pedro/Arturo antes de la sesión; documentar endpoint, ticket destino, efecto esperado y reversión.
+3. Acordar el ticket de prueba y una ventana de ejecución. Preferir un proyecto sandbox (`FACTEST`) o un ticket creado expresamente para la prueba.
+4. Ejecutarlo acompañado, registrar el `HTTP status`, el `issue.id`/`key` y verificar el resultado por API.
+5. No probar `DELETE`; no es una capacidad necesaria para la plataforma y no es reversible en producción.
+
+**Operaciones a validar, en este orden (de menos a más invasivo):**
+
+1. **Comentar** — `POST /rest/api/3/issue/{key}/comment` (cuerpo en ADF).
+   ⚠️ En JSM hay **comentarios públicos (los ve el cliente) vs internos**: `POST /rest/servicedeskapi/request/{id}/comment` con `public: true|false`. **La plataforma debe escribir SIEMPRE internos.** Publicar por error un comentario visible al cliente es el error más caro y menos reversible de este bloque.
+2. **Adjuntar** — `POST /rest/api/3/issue/{key}/attachments`.
+   ⚠️ Exige el header `X-Atlassian-Token: no-check` y `multipart/form-data`. Sin ese header falla con un error que no explica nada. Es la vía para dejar el PDF/XML como evidencia en el ticket.
+3. **Transicionar** — `POST /rest/api/3/issue/{key}/transitions` con el `transition.id` del Bloque 3.
+4. **Crear** — decisión real de diseño: `POST /rest/api/3/issue` (crudo, se salta el request type y el ticket queda "raro" en el portal) vs `POST /rest/servicedeskapi/request` (respeta request type y se ve como uno normal). **Si es JSM, la segunda es la correcta.**
+5. **Editar** — `PUT /rest/api/3/issue/{key}`.
+6. **Borrar** — `DELETE /rest/api/3/issue/{key}`. Requiere permiso de admin de proyecto. **Probablemente ni se tenga ni convenga tenerlo**; en producción el borrado no debe ser una capacidad de la plataforma.
+
+> 🔴 **Dónde probar.**
+> ~~Pedir a Pedro un proyecto de pruebas `FACTEST`~~ → **descartado por Noé el 7-ago:** será prueba acompañada sobre un ticket. Queda entonces una sola vía de mitigación:
+>
+> **Crear un sitio propio y gratuito de Jira Cloud** (plan Free, hasta 10 usuarios) con un proyecto JSM que replique el workflow de FAC. Sirve para desarrollar el cliente, el parser de ADF, la paginación, las aprobaciones y las transiciones **sin tocar nada de Balam** ni depender de que respondan. Es el sandbox que BIND nunca tuvo. Contra producción solo se corre lectura y, al final, la única prueba acompañada.
+>
+> Con el `FACTEST` descartado, esto ya no es una alternativa: es el único lugar donde se puede equivocar sin costo.
+
+---
+
+## Bloque 7 — Gobierno y seguridad 🟡
+
+- ✅ ~~**`propuesta/token-jira.txt` NO está en `.gitignore`**~~ → **Resuelto:** ignorado en [`.gitignore:9`](../.gitignore). Sigue pendiente mover el token a user-secrets / Key Vault y borrarlo de disco. Mismo pendiente que arrastra `bind_token_api.txt`.
+- **Cuenta de servicio vs cuenta personal de Pedro** (ya planteado en el borrador de correo del 29-jul): hoy todo lo que la plataforma escriba en Jira queda firmado con el nombre de Pedro, y una rotación suya deja la integración muerta. Verificar con `GET /rest/api/3/myself` con qué identidad se está actuando. **Sin respuesta al 10-ago.**
+- 🔴 **Alcance de permisos:** validado con `GET /rest/api/3/mypermissions` para FAC. El token puede navegar, crear, editar, transicionar, comentar, adjuntar y borrar tickets. Es un alcance excesivo para producción; la integración no debe implementar borrado y conviene migrar a una cuenta de servicio con permisos mínimos.
+- **Vigencia 27-jul-2027** → dejar registrado el vencimiento y el plan de rotación desde ahora.
+- **Datos de clientes en adjuntos y descripciones** — misma regla que BIND: nunca a disco del repo ni a documentos compartidos.
+
+---
+
+## Bloque 8 — Preguntas para Pedro / Balam (no se resuelven con la API)
+
+**Cerradas con el correo del 7-ago:**
+
+1. ~~**¿Puede crear un proyecto de pruebas `FACTEST`?**~~ → **No.** Prueba acompañada sobre un ticket (Noé, 7-ago).
+2. ~~**¿Debe observarse `Facturación adicional` (83), `Facturación` (12) u otro?**~~ → **Todos los request types** de la bandeja (Arturo, 4-ago). ⚠️ Con la salvedad del Bloque 1: 10 tickets no tienen request type ni campos.
+3. ~~**¿Cuál estatus dispara la cotización?**~~ → **`En proceso de facturación`** (Arturo, 4-ago).
+4. ~~**¿Monto del adjunto o como campo?**~~ → **Campo de Jira.** Ya implementado (`customfield_11556`), omitiendo recurrencia (Arturo, 4-ago).
+
+**Abiertas:**
+
+5. 🔴 **¿De dónde salen los CONCEPTOS/partidas?** El acuerdo resolvió el monto pero no los conceptos, y **no existe campo para ellos en el sitio**. ¿Cotización de una sola línea con el `summary` como descripción, o se agrega un campo?
+6. 🔴 **¿Qué pasa con los tickets creados por Automation for Jira** (10 de 69, sin ningún campo estructurado, incluido `FAC-91` que está vivo)? ¿Se acota la automatización o la regla de Automation propaga los campos?
+7. 🔴 **ACUNTIA / `FAC-100`:** ¿un ticket con `Monto sin IVA` único debe generar **una** cotización, o sigue siendo el caso de 40–48 facturas?
+8. **¿Nacional vs extranjero cambia la cotización** o solo el paquete de salida (PDF+XML vs PDF)? Hay dos estatus de validación distintos y una aprobación por cada rama.
+9. **¿Quién puede crear webhooks o reglas de Automation** apuntando a una URL nuestra, y bajo qué proceso? Gana urgencia: el estatus disparador dura minutos (Bloque 3).
+10. **PUE vs PPD** — la pregunta que no se ha alcanzado a hacer en cuatro sesiones ([REGISTRO #52](../bitacora/REGISTRO.md)). Los tickets `Seguimiento del Ticket con pago anticipado:` sugieren que sí hay casos PUE reales.
+11. **Cuenta de servicio** en lugar de la cuenta personal de Pedro, y fecha para la prueba acompañada.
+
+---
+
+## Orden de ataque sugerido
+
+| # | Acción | Bloqueado por |
+|---|---|---|
+| 1 | ✅ Blindar el token (`.gitignore`) — falta secrets/Key Vault | — |
+| 2 | ✅ Mapeo de campos y contratos de request type verificados (10-ago) | — |
+| 3 | Implementar lectura con `/search/jql`, cursor y ventana de solape | — |
+| 4 | **Detección por changelog del cruce a `En proceso de facturación`** | — (ya desbloqueado por el acuerdo del 4-ago) |
+| 5 | Parser de ADF para `Nombre del Cliente` + match contra `Clients` de BIND | ⚠️ Sin RFC; definir tolerancia del match |
+| 6 | Armado de la cotización BIND | 🔴 Definición de conceptos/partidas (pregunta 5) |
+| 7 | Levantar un sandbox Jira propio (plan Free) | — (ya no depende de Balam) |
+| 8 | Preparar y compartir el script de escritura mínimo para revisión | — |
+| 9 | Ejecutar una única prueba de escritura acompañada | Fecha de Balam + script revisado + ticket acordado |
+
+**Lo que puede avanzar ya:** el cliente de lectura, manejo de ADF, paginación por cursor, mapeo de campos, detección incremental por changelog y el sandbox propio. **Lo único que sigue bloqueado es el armado final de la cotización**, por la definición de conceptos. La escritura queda fuera del flujo automático hasta la sesión acompañada.
+
+---
+
+## Briefing corto para desarrollo / revisión técnica
+
+> Contexto validado: Jira Cloud JSM en `balam-jsm-temp.atlassian.net`; proyecto FAC company-managed (`projectId: 10034`, `serviceDeskId: 35`). La autenticación directa con Basic `email:token` funciona. El token tiene permisos de escritura amplios, pero **no se debe ejecutar ningún POST, PUT o DELETE fuera de una prueba acompañada y aprobada**.
+>
+> Para la capa de lectura, usar `GET /rest/api/3/search/jql`, paginar por `nextPageToken` y aplicar una ventana de solape al checkpoint de `updated`. No usar `/rest/api/3/search`: responde 410.
+>
+> Para JSM, usar `/rest/servicedeskapi` al consultar request types y su contrato de campos. FAC publica 4 request types: Bajas (84), Facturación adicional (83), Automatización (389) y Facturación (12); los cuatro contratos están verificados. **Facturación adicional (83) es el único con datos de facturación** e incluye `Monto sin IVA` (`customfield_11556`, number). **No existe campo de conceptos/partidas en el sitio.**
+>
+> **El disparador acordado es el cruce a `En proceso de facturación`, y dura minutos** (FAC-100: 2m44s). La detección debe leer el changelog y buscar el cruce dentro de la ventana; consultar el estatus actual no sirve. El `issuetype` es `admon`. El workflow tiene **aprobaciones de JSM** con Araceli como aprobadora en las ramas de validación nacional/extranjera: la plataforma nunca aprueba.
+>
+> **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`.**

planeacion/Seguimiento-horas.csv

@@ -1,19 +1,36 @@
 fecha,semana,etapa,actividad_id,actividad,horas,estado_hora,fuente_evidencia,facturable,notas
-2026-07-01,2026-W27,0,E0-01,Sesión de arranque con Noé,1.00,confirmada,bitacora/REGISTRO.md#22,si,"Sesión calendarizada de 7:00 a 8:00 am"
-2026-07-01,2026-W27,0,E0-01,Preparación de plan kickoff y materiales,1.00,reconstruida,planeacion/Kickoff-2026-07-01.md,si,"Estimación retrospectiva; validar antes de facturar"
-2026-07-06,2026-W28,0,E0-02,Discovery de facturación y envío,1.08,confirmada,bitacora/REGISTRO.md#27,si,"Duración documentada: aproximadamente 1 h 5 min"
-2026-07-06,2026-W28,0,E0-02,Preparación y análisis de Discovery de facturación,1.92,reconstruida,bitacora/REGISTRO.md#27,si,"Completa 3.00 h para facturación/envío incluyendo sesión"
-2026-07-06,2026-W28,0,E0-03,Coordinación y validación de accesos BIND y marca,1.00,reconstruida,bitacora/REGISTRO.md#28-31,si,"Recepción documentación y salvaguardas"
-2026-07-06,2026-W28,0,E0-04,Validación técnica de API BIND,4.50,reconstruida,bind-api-sandbox/VALIDACION-API.md,si,"117 GET análisis y reporte técnico"
-2026-07-07,2026-W28,0,E0-02,Discovery de cobranza,1.00,confirmada,bitacora/REGISTRO.md#35,si,"Sesión calendarizada de 7:00 a 8:00 am; sin grabación"
-2026-07-07,2026-W28,0,E0-02,Preparación y documentación de Discovery de cobranza,1.50,reconstruida,fuentes/2026-07-07 - Notas - Proceso actual de cobranza (sin grabacion).md,si,"Estimación retrospectiva"
-2026-07-08,2026-W28,0,E0-05,Diseño y construcción del prototipo,3.00,reconstruida,prototipo/Prototipo-Etapa0.html,si,"Primera mitad del esfuerzo reconstruido"
-2026-07-09,2026-W28,0,E0-05,Ajustes de cobranza navegación y prototipo,3.00,reconstruida,prototipo/Prototipo-Etapa0.html,si,"Segunda mitad del esfuerzo reconstruido"
-2026-07-10,2026-W28,0,E0-06,Entregable hallazgos ADRs PDF correo y plan,3.00,reconstruida,prototipo/Correo-prototipo-Etapa0.md,si,"Incluye preparación del entregable y documentación"
-2026-07-13,2026-W29,1,E1-01,Backend base autenticación roles y auditoría,2.00,reconstruida,planeacion/Plan-actividades.md,si,"Trabajo local; falta conciliar contra evidencia de código"
-2026-07-13,2026-W29,1,E1-02,Coordinación del repositorio GitHub,0.50,reconstruida,bitacora/REGISTRO.md#43,si,"Seguimiento de creación y acceso"
-2026-07-14,2026-W29,1,E1-01,Backend base autenticación roles y auditoría,1.50,reconstruida,planeacion/Plan-actividades.md,si,"Trabajo local; completa 3.50 h"
-2026-07-14,2026-W29,1,E1-03,Arquitectura multi-tenant,1.00,reconstruida,planeacion/Plan-actividades.md,si,"Diseño inicial tenant_id y RLS"
-2026-07-15,2026-W29,1,E1-03,Arquitectura multi-tenant,0.50,reconstruida,planeacion/Plan-actividades.md,si,"Completa 1.50 h"
-2026-07-15,2026-W29,1,E1-04,Cliente productivo de API BIND,2.00,reconstruida,bind-api-sandbox/VALIDACION-API.md,si,"Inicio de reintentos OData y manejo de errores"
-2026-07-15,2026-W29,1,E1-05,Seguimiento ajuste de calendario y corte de horas,0.50,reconstruida,bitacora/REGISTRO.md#41-45,si,"Actualización de plan y control"
+2026-07-01,2026-W27,0,E0-01,Sesión de arranque con Noé,1.00,confirmada,bitacora/REGISTRO.md#22,si,Sesión calendarizada de 7:00 a 8:00 am
+2026-07-01,2026-W27,0,E0-01,Preparación de plan kickoff y materiales,1.00,validada,planeacion/Kickoff-2026-07-01.md,si,validada por Johann 27-jul
+2026-07-06,2026-W28,0,E0-02,Discovery de facturación y envío,1.08,confirmada,bitacora/REGISTRO.md#27,si,Duración documentada: aproximadamente 1 h 5 min
+2026-07-06,2026-W28,0,E0-02,Preparación y análisis de Discovery de facturación,1.00,validada,bitacora/REGISTRO.md#27,si,"Completa 2.08 h con la sesión; ajustada a la baja por Johann 27-jul"
+2026-07-06,2026-W28,0,E0-03,Coordinación y validación de accesos BIND y marca,1.00,validada,bitacora/REGISTRO.md#28-31,si,Recepción documentación y salvaguardas; validada por Johann 27-jul
+2026-07-06,2026-W28,0,E0-04,Validación técnica de API BIND,4.50,validada,bind-api-sandbox/VALIDACION-API.md,si,117 GET análisis y reporte técnico; validada por Johann 27-jul
+2026-07-07,2026-W28,0,E0-02,Discovery de cobranza,1.00,confirmada,bitacora/REGISTRO.md#35,si,Sesión calendarizada de 7:00 a 8:00 am; sin grabación
+2026-07-07,2026-W28,0,E0-02,Preparación y documentación de Discovery de cobranza,0.75,validada,fuentes/2026-07-07 - Notas - Proceso actual de cobranza (sin grabacion).md,si,"Sin grabación; notas escritas a mano; ajustada a la baja por Johann 27-jul"
+2026-07-08,2026-W28,0,E0-05,Diseño y construcción del prototipo,3.00,validada,prototipo/Prototipo-Etapa0.html,si,Primera mitad del esfuerzo reconstruido; validada por Johann 27-jul
+2026-07-09,2026-W28,0,E0-05,Ajustes de cobranza navegación y prototipo,3.00,validada,prototipo/Prototipo-Etapa0.html,si,Segunda mitad del esfuerzo reconstruido; validada por Johann 27-jul
+2026-07-10,2026-W28,0,E0-05,"Pulido final del prototipo (bandeja, modal Edo. cuenta, login, capturas)",1.50,validada,prototipo/Prototipo-Etapa0.html,si,"6 commits 00:44-01:52 (b358570..8da11ea) + 9 capturas + logo oficial; validada por Johann 27-jul"
+2026-07-10,2026-W28,0,E0-06,Entregable de cierre Etapa 0: PDF hallazgos plan refinado y correo,1.50,validada,prototipo/Correo-prototipo-Etapa0.md,si,PDF generado 10:43; hallazgos y plan refinado; validada por Johann 27-jul
+2026-07-13,2026-W29,1,E1-01,Backend base autenticación roles y auditoría,2.00,validada,planeacion/Plan-actividades.md,si,validada por Johann 27-jul
+2026-07-13,2026-W29,1,E1-02,Coordinación del repositorio GitHub,0.50,validada,bitacora/REGISTRO.md#43,si,Seguimiento de creación y acceso; validada por Johann 27-jul
+2026-07-14,2026-W29,1,E1-01,Backend base autenticación roles y auditoría,1.50,validada,planeacion/Plan-actividades.md,si,Trabajo local; completa 3.50 h; validada por Johann 27-jul
+2026-07-14,2026-W29,1,E1-03,Arquitectura multi-tenant,1.00,validada,planeacion/Plan-actividades.md,si,Diseño inicial tenant_id y RLS; validada por Johann 27-jul
+2026-07-15,2026-W29,1,E1-03,Arquitectura multi-tenant,0.50,validada,planeacion/Plan-actividades.md,si,Completa 1.50 h; validada por Johann 27-jul
+2026-07-15,2026-W29,1,E1-04,Cliente productivo de API BIND,2.00,validada,bind-api-sandbox/VALIDACION-API.md,si,Inicio de reintentos OData y manejo de errores; validada por Johann 27-jul
+2026-07-15,2026-W29,1,E1-05,Seguimiento ajuste de calendario y corte de horas,0.50,validada,bitacora/REGISTRO.md#41-45,si,Actualización de plan y control; validada por Johann 27-jul
+2026-07-16,2026-W29,1,E1-06,Scaffold backend .NET 10 + frontend Angular 21 y push al repo de Balam,2.00,validada,bitacora/REGISTRO.md#46,si,Commits 220942a..1f7f098; incluye CLAUDE.md del repo; validada por Johann 27-jul
+2026-07-16,2026-W29,1,E1-05,Corte de avance Etapa 1 para Erika (Excel + mensaje),1.00,validada,planeacion/Avance-Etapa1-2026-07-16.md,si,Enviado 8:40 pm por WhatsApp con acuse; validada por Johann 27-jul
+2026-07-19,2026-W29,1,E1-06,"Preparación de entorno local (clon del repo, SDK .NET 10, secrets, app corriendo)",1.00,validada,bitacora/REGISTRO.md#47,si,API y frontend verificados en local; 13/13 pruebas verdes; validada por Johann 27-jul
+2026-07-19,2026-W29,1,E1-08,"Diseño del plan de ejecución de Etapa 1 (bloques B0-B10, ADRs, orden)",2.00,validada,planeacion/Plan-Etapa1.md,si,Arquitectura y decisiones previas a las sesiones de desarrollo; validada por Johann 27-jul
+2026-07-19,2026-W29,1,E1-06,Scalar UI para el OpenAPI del backend,0.25,confirmada,bitacora/REGISTRO.md#48,si,Sesión asistida por IA; /scalar/v1 verificado
+2026-07-19,2026-W29,1,E1-01,B0+B1: Postgres 17 local + modelo de datos + Identity + migración Inicial + seed,1.00,confirmada,bitacora/REGISTRO.md#48,si,Sesión asistida por IA (noche del domingo); 16 tablas migradas y siembra verificada; tiempo real de sesión
+2026-07-19,2026-W29,1,E1-01,B2: login JWT + policies por rol + bitácora de auditoría,0.50,confirmada,bitacora/REGISTRO.md#49,si,Sesión asistida por IA; matriz 401/403/200 verificada end-to-end; tiempo real de sesión
+2026-07-19,2026-W29,1,E1-01,B3: sync de clientes contra BIND real + fix de modelos (GUIDs null),0.50,confirmada,bitacora/REGISTRO.md#50,si,"Sesión asistida por IA; 16 clientes sincronizados, idempotencia verificada; tiempo real de sesión"
+2026-07-21,2026-W30,1,E1-01,B4: sync de facturas/cotizaciones + estados + cartera por moneda + sync histórico,1.00,confirmada,bitacora/REGISTRO.md#52,si,Sesión asistida por IA; 1494 facturas y 43 cotizaciones sincronizadas de producción; tiempo real de sesión
+2026-07-21,2026-W30,1,E1-03,B6: RLS real de Postgres por tenant (migración + interceptor + filtros EF),0.50,confirmada,bitacora/REGISTRO.md#53,si,Sesión asistida por IA; verificación manual en psql; tiempo real de sesión
+2026-07-21,2026-W30,1,E1-05,Cierre de sesión: Excel de avance regenerado + bitácora + control de horas,0.25,confirmada,bitacora/REGISTRO.md#52-53,si,Sesión asistida por IA; tiempo real de sesión
+2026-07-21,2026-W30,1,E1-05,Preparación de la agenda de la sesión de reglas de Etapa 1,0.75,validada,planeacion/Sesion-Etapa1-2026-07-22.md,si,Agenda y preguntas para la sesión del 22-jul; validada por Johann 27-jul
+2026-07-22,2026-W30,1,E1-05,"Sesión de reglas Etapa 1 con Noé, Arturo y Araceli (alta de clientes, fee, flujo Jira)",0.80,confirmada,bitacora/REGISTRO.md#54,si,Duración real ~48 min según transcript (7:00–7:48 am)
+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

planeacion/Seguimiento-horas.md

@@ -5,7 +5,7 @@ Fuente local de horas efectivamente trabajadas para el proyecto Balam. Se mantie
 **Tarifa contractual:** $600 MXN/h + IVA
 **Cadencia:** corte semanal; factura los viernes; pago a 30 días
 **Datos tabulares:** [`Seguimiento-horas.csv`](Seguimiento-horas.csv)
-**Última actualización:** 2026-07-15
+**Última actualización:** 2026-07-27
 
 ## Reglas de captura
 
@@ -16,47 +16,67 @@ Fuente local de horas efectivamente trabajadas para el proyecto Balam. Se mantie
 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.
 
-## Corte reconstruido al 15-jul
+## Corte al 27-jul
 
 | Etapa | Horas al corte | Rango estimado de la etapa | Estado |
 |---|---:|---:|---|
-| Etapa 0 | **22.00 h** | 18–22 h | Límite superior consumido; prototipo pendiente de validación |
-| Etapa 1 | **8.00 h** | 32–39 h | En curso |
-| **Total** | **30.00 h** |  | Coincide con la facturación inicial propuesta |
+| Etapa 0 | **21.83 h** | 18–22 h | Cerrada y **validada por Balam el 24-jul**; dentro del rango |
+| Etapa 1 | **19.75 h** | 32–39 h | En curso; 6 de 8 entregables terminados |
+| **Total** | **41.58 h** |  |  |
 
-Las **26.92 h** que no corresponden a sesiones con duración documentada se reconstruyeron retrospectivamente por actividad. Deben validarse contra memoria, archivos de trabajo y Jira antes de presentarse como horas efectivamente trabajadas.
+**Estado de validación de las horas (27-jul):**
 
-## Horas con duración comprobable
+| Estado | Horas | Significado |
+|---|---:|---|
+| `confirmada` | 9.13 h | Duración documentada (transcripts, sesiones calendarizadas, tiempo de sesión) |
+| `validada` | 32.45 h | Reconstruida por actividad y **confirmada por Johann el 27-jul** contra evidencia fechada |
+| **Total** | **41.58 h** | Sin horas pendientes de validar |
 
-| Semana | Etapa | Horas confirmadas | Alcance incluido |
-|---|---:|---:|---|
-| 2026-W27 | 0 | 1.00 | Kickoff |
-| 2026-W28 | 0 | 2.08 | Discovery de facturación/envío y cobranza |
-| **Total comprobable** |  | **3.08** | Solo sesiones con duración documentada |
+## Distribución al 27-jul
 
-> Las 3.08 h están incluidas dentro del corte reconstruido de 30 h; no deben sumarse nuevamente.
+| Etapa | Actividad | ID | Horas |
+|---|---|---|---:|
+| 0 | Kickoff y preparación | E0-01 | 2.00 |
+| 0 | Discovery de facturación, envío y cobranza | E0-02 | 3.83 |
+| 0 | Accesos y salvaguardas | E0-03 | 1.00 |
+| 0 | Validación técnica de la API de BIND | E0-04 | 4.50 |
+| 0 | Prototipo navegable (incl. pulido final del 10-jul) | E0-05 | 7.50 |
+| 0 | Entregable de cierre: PDF, hallazgos, plan y correo | E0-06 | 1.50 |
+| 0 | Validación del prototipo con Balam (guion + sesión) | E0-07 | 1.50 |
+| 1 | Backend base, auth, roles, bitácora y syncs (B0–B4) | E1-01 | 6.50 |
+| 1 | Coordinación del repositorio | E1-02 | 0.50 |
+| 1 | Arquitectura multi-tenant y RLS (B6) | E1-03 | 2.00 |
+| 1 | Cliente productivo de la API de BIND | E1-04 | 2.00 |
+| 1 | Gestión, cortes de avance y sesión de reglas | E1-05 | 3.30 |
+| 1 | Entorno local, scaffold y Scalar | E1-06 | 3.25 |
+| 1 | Sesión de API de Jira | E1-07 | 0.20 |
+| 1 | Diseño del plan de ejecución de Etapa 1 | E1-08 | 2.00 |
+|  | **Total** |  | **41.58** |
 
-## Distribución reconstruida
+> **Ajustes a la baja aplicados por Johann el 27-jul:** el análisis del Discovery de facturación bajó de 1.92 a 1.00 h, la documentación del de cobranza de 1.50 a 0.75 h, y el guion de validación de 0.75 a 0.45 h. Las duraciones de sesión documentadas en transcript **no se tocaron**. Con esto Etapa 0 vuelve a quedar dentro del rango contractual de 18–22 h.
 
-Johann debe confirmar esta distribución antes de usarla para facturación:
+### Nota sobre las sesiones asistidas por IA
 
-| Etapa | Actividad consolidada | Horas |
-|---|---|---:|
-| 0 | Kickoff y preparación | 2.00 |
-| 0 | Discovery de facturación, envío y cobranza | 5.50 |
-| 0 | Accesos y salvaguardas | 1.00 |
-| 0 | Validación técnica de BIND | 4.50 |
-| 0 | Prototipo navegable | 6.00 |
-| 0 | Entregable, hallazgos, ADRs y plan | 3.00 |
-| 1 | Backend base | 3.50 |
-| 1 | Arquitectura multi-tenant | 1.50 |
-| 1 | Cliente productivo de BIND | 2.00 |
-| 1 | Repositorio y seguimiento | 1.00 |
-|  | **Total** | **30.00** |
+Los bloques B0–B6 de Etapa 1 (auth, RLS, cliente de BIND, sincronización de 1,494 facturas de producción) se ejecutaron en **3.50 h de tiempo de reloj** contra una estimación manual de 4–5.5 h *por bloque*. Se registra el tiempo efectivamente trabajado, conforme al contrato. El trabajo intelectual que hizo posible esa velocidad —diseño de arquitectura, decisión de ADRs y plan de ejecución— se registra por separado en **E1-08 (2.00 h)**.
+
+Consecuencia a vigilar: **Etapa 1 cerrará por debajo del rango de 32–39 h.** Conviene reportar avance por entregable (6 de 8) y no solo por horas, para que la eficiencia no se lea como alcance faltante.
+
+### Nota sobre el mapeo CSV → Excel
+
+El CSV agrupa por **actividad contractual**; el Excel desglosa por **tarea de proyecto**, y no mapean 1:1. El reparto vive en `HORAS_POR_FILA` dentro de `generar_avance_2026_07_27.py`, con la trazabilidad comentada línea por línea, y el script **aborta** si la suma del detalle no cuadra con el CSV.
+
+Dos casos que conviene recordar:
+- **E1-06 (entorno, scaffold, Scalar — 3.25 h)** no tiene fila propia: se carga a "Backend base", que se renombró y amplió su rango a 8–9 h.
+- **E1-08 (diseño del plan — 2.00 h)** se reparte en dos: **1.00 h** de diseño general va a "Arquitectura multi-tenant y diseño de la solución" (rango 3–4 h) y **1.00 h** del análisis de B7 —pipeline `Draft→DryRun→Confirm`, flags, regla PPD/PUE, ADR-001— va a la fila del **entregable 4 (capa de escritura)**, para que muestre el trabajo hecho aunque la implementación siga en pausa. La entidad `WriteOperation` y la policy `PuedeOperarEscritura` **no** se contabilizan ahí: se hicieron en B1/B2 y ya están en "Backend base" (evita doble conteo).
+- La fila de **seguimiento semanal se queda solo con gestión y cortes de avance (1.75 h)**. Antes acumulaba 7.00 h de trabajo técnico bajo un nombre que no lo describía, lo que se leía como sobrecosto en una actividad trivial.
+- La sesión **B4 (1.00 h)** se reparte entre "Sincronización de facturas" (0.50 h) y "Modelo de facturas" (0.50 h): produjo ambas cosas —el sync y el `InvoiceStatusMapper` con sus 13 pruebas más la migración `DetalleSyncPendiente`—, y antes el modelo aparecía al 85 % con 0 h.
+
+**Criterio general:** ninguna fila debe mostrar avance con 0 h trabajadas. Las únicas excepciones legítimas son Azure y CI/CD, que están en 0 % y 0 h porque dependen de accesos del lado de Balam.
 
 ## Corte comercial
 
 - La propuesta v1.2 contempla una **facturación inicial de 30 h ($18,000 + IVA)** que cubre Etapa 0 e inicio de Etapa 1.
-- Esas 30 h son el concepto comercial autorizado en la propuesta, pero el contrato exige reportar horas efectivamente trabajadas.
-- Antes de emitir, Johann debe validar el desglose reconstruido y conciliarlo contra Jira.
-- La emisión sigue pendiente de confirmación de Balam al correo del 2-jul.
+- Al 27-jul hay **41.58 h trabajadas**, es decir **11.58 h por encima** de esa facturación inicial. A tarifa de $600/h son **$6,948 + IVA** aún no facturados.
+- Todas las horas están validadas (ninguna pendiente de confirmar), por lo que el desglose ya es presentable para facturación.
+- Pendiente: conciliar contra Jira cuando Pedro lo habilite, y confirmar con Balam si la segunda factura va por el excedente o por corte de etapa.
+- La emisión de la factura inicial sigue pendiente de confirmación de Balam al correo del 2-jul.

planeacion/Sesion-Etapa1-2026-07-22.md

@@ -32,6 +32,7 @@ Al terminar deben quedar definidos:
 - ¿Pago parcial con saldo residual, nota de crédito, gasto/comisión o ajuste contable?
 - ¿Existe una tolerancia fija o cambia por cliente/banco?
 - ¿Quién autoriza considerar una factura como saldada con diferencia?
+- 🆕 **Hallazgo del sync histórico (21-jul):** las 1,374 facturas con método de pago registran **PUE — ninguna PPD** — aunque cobran a crédito 30–90 días. ¿Es política deliberada del despacho o práctica a corregir? Impacta la regla "PPD default" de la futura capa de escritura y el requerimiento del SAT que ya sufrieron.
 
 **Decisión a registrar:** fórmula de estado de cobranza y si el umbral es global o por cliente.
 
@@ -60,6 +61,13 @@ Si Balam confirma la automatización, solicitar posteriormente:
 - Identificadores del sitio/proyecto y mapeo de campos.
 - Autorización de escritura controlada en BIND.
 
+**Estimación a comunicar (en dos partes, no dar una sola cifra global):**
+
+1. *Definición del flujo + accesos:* esta misma semana, un par de horas.
+2. *Desarrollo:* **~10 horas, sujeto a validar la API de escritura de BIND** — sin sandbox, endpoints de escritura no documentados y producción directa (por eso lleva dry-run + confirmación humana). Frase preparada: "La definición del flujo y los accesos los resolvemos esta semana. El desarrollo lo estimo en unas 10 horas, sujeto a lo que encontremos en la API de escritura de BIND, que aún no está documentada y es producción directa — por eso va con dry-run y confirmación humana antes de escribir nada."
+
+⚠️ No comprometer el número de desarrollo como cerrado hasta tener las reglas del punto 1 (alta de cliente) — si el ticket puede traer un cliente que no existe en BIND, las dos piezas se tocan y el alcance cambia.
+
 **Decisión a registrar:** incluido, diferido o sujeto a estimación/cambio de alcance.
 
 ### 5. Cierre técnico — 10 min
@@ -76,13 +84,21 @@ Si Balam confirma la automatización, solicitar posteriormente:
 - Escritura en producción: solo con autorización, dry-run, confirmación humana y feature flag.
 - Integración Jira automática: pendiente de confirmación de alcance.
 
-## Minuta para llenar durante la sesión
+## Minuta — sesión realizada (22-jul, 7:00 am, ~48 min)
+
+> Participaron: Noe (sala), Arturo, Araceli (desde ~min 21), Johann. Erika no estuvo. Transcripción: `../fuentes/2026-07-22 - Flujo para dar de alta clientes nuevos,_ Transcript.txt`. Detalle completo en [REGISTRO #54](../bitacora/REGISTRO.md).
 
 | Tema | Decisión | Responsable | Fecha |
 |---|---|---|---|
-| Alta de cliente |  |  |  |
-| Fee/comisión |  |  |  |
-| Particularidades de envío |  |  |  |
-| Jira→BIND |  |  |  |
-| Escritura BIND |  |  |  |
-| Repo/Azure/Jira horas |  |  |  |
+| Alta de cliente | ASIS mapeado: mismo flujo clientes/proveedores, 2 pestañas (Detalle + Direcciones), datos de constancia fiscal + estado de cuenta; crédito viene de negociación comercial; extranjeros con RFC genérico y CFDI "sin efectos fiscales" (solo PDF, sin XML). **Pendiente decidir si la plataforma solo detecta o también crea el cliente.** | Arturo demostró; decisión MVP abierta | 22-jul |
+| Fee/comisión | El fee bancario lo registra y deduce **el despacho contable**, no Balam. Solo aplica en pagos internacionales que mueven dinero a México; nacionales cuadran a centavos. La plataforma solo debe **identificar la diferencia como fee** (visible en el estado de cuenta del cliente). | Despacho (asiento) · Plataforma (detección) | 22-jul |
+| Particularidades de envío | **No se tocó.** Excel sigue pendiente de Ara/Arturo. | Ara + Arturo | — |
+| Jira→BIND | Noe confirmó que **Jira ya es parte del proceso** (evolucionó desde el alcance inicial) y puso el ajuste sobre la mesa. Space "Facturación"; estatus final que confirma facturación = **"resuelto"**; validación exige PDF+XML (nacional) o PDF (internacional). Sesión con Pedro para API de Jira + recurrentes. | Erika coordina sesión con Pedro | Por agendar |
+| Escritura BIND | Explorarla con máxima cautela: **no hay sandbox, es producción**. Prueba Jira→cotización será acordada, medida y controlada llegado el momento. | Johann + Noe/Pedro | Tras sesión API Jira |
+| Repo/Azure/Jira horas | **No se tocó.** | — | — |
+| PUE vs PPD (hallazgo 21-jul) | **No se alcanzó a preguntar.** Reintentar el 23-jul o en la sesión con Pedro. | Johann | Pendiente |
+
+**Compromisos de Balam salidos de la sesión:**
+1. Enviar a Johann el **diagrama del flujo Jira** en tamaño legible (Arturo/Pedro).
+2. Agendar **sesión con Pedro** (API Jira, facturación recurrente, automáticas vs manuales).
+3. Arturo grabará/documentará los procesos nuevos conforme ocurran (caso Frisa en curso).

planeacion/generar_avance_2026_07_21.py

@@ -0,0 +1,159 @@
+"""Genera Plan-actividades-avance-2026-07-21.xlsx desde el del 16-jul.
+Columnas nuevas: Bloque · Horas estimadas (rango) · Horas trabajadas · Estatus.
+Semáforo: verde=completada, amarillo=en curso, rojo=vencida, gris=próxima.
+Línea roja gruesa = HOY (21-jul): lo de arriba debería estar hecho o en curso."""
+import re
+from datetime import date
+import openpyxl
+from openpyxl.styles import Font, Alignment, PatternFill, Border, Side
+
+SRC = "/Users/johann/Desktop/Proyectos personales/BALAM/planeacion/Plan-actividades-avance-2026-07-16.xlsx"
+DST = "/Users/johann/Desktop/Proyectos personales/BALAM/planeacion/Plan-actividades-avance-2026-07-21.xlsx"
+HOY = date(2026, 7, 21)
+
+AMARILLO, CAFE = "F7BD0C", "331F0E"
+CREMA, GRIS_B = "FDF3D8", "D9D9D9"
+V_FILL, V_FONT = "C6EFCE", "006100"   # verde
+A_FILL, A_FONT = "FFEB9C", "9C6500"   # amarillo
+R_FILL, R_FONT = "FFC7CE", "9C0006"   # rojo
+G_FILL, G_FONT = "F2F2F2", "595959"   # gris
+
+# prefijo -> (bloque, estimadas_rango, trabajadas, nuevo_pct o None)
+MAPA = {
+    "Integracion de plataformas Balam": ("", "50–61", 38.0, 0.65),
+    "Etapa 0": ("", "18–22", 22.0, None),
+    "Sesión de arranque (kickoff)": ("—", "2", 2.0, None),
+    "Sesión de Discovery": ("—", "4–5", 5.5, None),
+    "Entrega y validación de accesos": ("—", "1", 1.0, None),
+    "Validación técnica de la API": ("—", "3–4", 4.5, None),
+    "Prototipo visual navegable": ("—", "5–6", 6.0, None),
+    "Documento de hallazgos": ("—", "2–3", 3.0, None),
+    "Sesión de validación del prototipo": ("—", "1", 0.0, None),
+    "Etapa 1": ("", "32–39", 16.0, 0.8),
+    "Demostración semanal": ("—", "2–3", 1.5, None),
+    "Repositorio privado GitHub": ("—", "1", 0.5, None),
+    "Backend base": ("B2", "6–7", 7.25, 1.0),
+    "Arquitectura multi-tenant": ("B1 + B6", "2–3", 2.0, 1.0),
+    "Cliente de la API de BIND": ("—", "2–3", 2.0, None),
+    "Capa de escritura controlada": ("B7", "3–4", 0.0, None),
+    "Sincronización de clientes": ("B3", "2.5–3", 0.5, 1.0),
+    "Configuración de infraestructura en Azure": ("—", "1", 0.0, None),
+    "Sincronización de facturas": ("B4", "4.5–5.5", 1.0, 1.0),
+    "Sesión de reglas y dudas": ("—", "1", 0.0, None),
+    "Definición de alcance Jira": ("—", "1", 0.0, None),
+    "Modelo de facturas": ("B1 + B4 + B9", "3.5–4.5", 1.0, 0.85),
+    "CI/CD": ("—", "1.5–2", 0.0, None),
+}
+
+def fecha(celda):
+    m = re.search(r"(\d{2})/(\d{2})/(\d{2})", str(celda or ""))
+    return date(2000 + int(m.group(3)), int(m.group(2)), int(m.group(1))) if m else None
+
+wb = openpyxl.load_workbook(SRC)
+ws = wb.active
+
+C_BLQ, C_EST, C_TRAB, C_STAT = 8, 9, 10, 11
+for col, titulo in [(C_BLQ, "Bloque (plan interno)"), (C_EST, "Horas estimadas"),
+                    (C_TRAB, "Horas trabajadas"), (C_STAT, f"Estatus (hoy {HOY.day}-jul)")]:
+    ws.cell(row=1, column=col, value=titulo)
+
+thin = Side(style="thin", color=GRIS_B)
+borde = Border(left=thin, right=thin, top=thin, bottom=thin)
+
+def pinta(celda, fill, font_color, bold=False):
+    celda.fill = PatternFill("solid", fgColor=fill)
+    celda.font = Font(color=font_color, bold=bold, size=10)
+    celda.alignment = Alignment(horizontal="center", vertical="center")
+
+fila_hoy = None      # primera actividad de Etapa 1 que arranca DESPUÉS de hoy
+en_etapa1 = False
+
+for row in range(2, ws.max_row + 1):
+    nombre = str(ws.cell(row=row, column=1).value or "").strip()
+    if not nombre:
+        continue
+    if nombre.startswith("Etapa 1"):
+        en_etapa1 = True
+
+    for prefijo, (blq, est, trab, pct) in MAPA.items():
+        if nombre.startswith(prefijo):
+            ws.cell(row=row, column=C_BLQ, value=blq)
+            ws.cell(row=row, column=C_EST, value=est)
+            ws.cell(row=row, column=C_TRAB, value=trab)
+            if pct is not None:
+                ws.cell(row=row, column=7, value=pct)
+            break
+
+    es_etapa = nombre.startswith("Etapa") or nombre.startswith("Integracion")
+    pct = ws.cell(row=row, column=7).value or 0
+    ini, fin = fecha(ws.cell(row=row, column=3).value), fecha(ws.cell(row=row, column=4).value)
+    stat = ws.cell(row=row, column=C_STAT)
+
+    if es_etapa:
+        ws.cell(row=row, column=C_STAT, value="")
+    elif pct >= 1:
+        stat.value = "✅ Completada";  pinta(stat, V_FILL, V_FONT)
+    elif fin and fin < HOY:
+        stat.value = "🔴 Vencida";     pinta(stat, R_FILL, R_FONT, bold=True)
+    elif ini and ini <= HOY:
+        stat.value = "🟡 En curso";    pinta(stat, A_FILL, A_FONT)
+    elif pct > 0:
+        stat.value = "🟢 Adelantada";  pinta(stat, V_FILL, V_FONT)
+    else:
+        stat.value = "⚪ Próxima";     pinta(stat, G_FILL, G_FONT)
+
+    # semáforo también en la celda de %
+    pcel = ws.cell(row=row, column=7)
+    if not es_etapa:
+        if pct >= 1: pinta(pcel, V_FILL, V_FONT, bold=True)
+        elif pct > 0: pinta(pcel, A_FILL, A_FONT, bold=True)
+        elif fin and fin < HOY: pinta(pcel, R_FILL, R_FONT, bold=True)
+
+    if en_etapa1 and fila_hoy is None and not es_etapa and ini and ini > HOY:
+        fila_hoy = row
+
+# estilo general: encabezado marca, filas de etapa, bordes, formatos
+head_fill = PatternFill("solid", fgColor=AMARILLO)
+etapa_fill = PatternFill("solid", fgColor=CREMA)
+for row in range(1, ws.max_row + 1):
+    nombre = str(ws.cell(row=row, column=1).value or "")
+    es_etapa = nombre.startswith("Etapa") or nombre.startswith("Integracion")
+    for col in range(1, C_STAT + 1):
+        c = ws.cell(row=row, column=col)
+        c.border = borde
+        if row == 1:
+            c.fill = head_fill
+            c.font = Font(bold=True, color=CAFE, size=11)
+            c.alignment = Alignment(horizontal="center", vertical="center", wrap_text=True)
+        elif es_etapa and nombre:
+            c.fill = etapa_fill
+            c.font = Font(bold=True, color=CAFE)
+    if row > 1:
+        ws.cell(row=row, column=7).number_format = "0%"
+        ws.cell(row=row, column=C_TRAB).number_format = "0.0"
+        for col in (C_BLQ, C_EST, C_TRAB):
+            ws.cell(row=row, column=col).alignment = Alignment(horizontal="center")
+
+# línea de HOY: borde rojo grueso arriba de la primera actividad futura de Etapa 1
+if fila_hoy:
+    rojo = Side(style="thick", color="C00000")
+    for col in range(1, C_STAT + 1):
+        c = ws.cell(row=fila_hoy, column=col)
+        c.border = Border(left=c.border.left, right=c.border.right,
+                          top=rojo, bottom=c.border.bottom)
+
+# leyenda
+ley = ws.max_row + 2
+ws.cell(row=ley, column=1,
+        value="✅ Completada · 🟡 En curso · 🔴 Vencida (fecha plan pasada, <100%) · ⚪ Próxima").font = Font(italic=True, size=9, color=G_FONT)
+ws.cell(row=ley + 1, column=1,
+        value=f"▬ La línea roja gruesa marca HOY ({HOY.day}-jul): lo de arriba debería estar terminado o en curso.").font = Font(italic=True, size=9, color="C00000")
+
+for letra, ancho in {"A": 48, "B": 9, "C": 12, "D": 12, "E": 12, "F": 22, "G": 12,
+                     "H": 15, "I": 14, "J": 14, "K": 20}.items():
+    ws.column_dimensions[letra].width = ancho
+ws.freeze_panes = "A2"
+ws.oddFooter.center.text = "Avance al 21-jul-2026 · Horas conforme al control local (pendiente conciliar con Jira)"
+
+wb.save(DST)
+print("OK ->", DST, "| línea de hoy en fila:", fila_hoy)

planeacion/generar_avance_2026_07_27.py

@@ -0,0 +1,300 @@
+"""Genera Plan-actividades-avance-2026-07-27.xlsx a partir del del 21-jul.
+
+Diferencia clave vs. versiones anteriores: las HORAS TRABAJADAS ya no se escriben a
+mano — se leen de `Seguimiento-horas.csv` (fuente de la verdad) y se agregan por
+actividad del plan mediante el mapa ACT_POR_TAREA. Así cada celda de horas del
+Excel es trazable a una o varias líneas del CSV, y el total del encabezado de cada
+etapa es la suma real de su detalle.
+
+Corte al 27-jul: validación del prototipo (24-jul, APROBADO) y sesión de reglas
+(22-jul) completadas; API de Jira (27-jul) recibida; capa de escritura EN PAUSA a
+la espera de la definición del flujo de facturación (sesión 28-jul).
+"""
+import csv
+import os
+import re
+from collections import defaultdict
+from datetime import date
+
+import openpyxl
+from openpyxl.styles import Alignment, Font, PatternFill
+
+BASE = os.path.dirname(os.path.abspath(__file__))
+SRC = os.path.join(BASE, "Plan-actividades-avance-2026-07-21.xlsx")
+DST = os.path.join(BASE, "Plan-actividades-avance-2026-07-27.xlsx")
+CSV_HORAS = os.path.join(BASE, "Seguimiento-horas.csv")
+HOY = date(2026, 7, 27)
+
+CAFE, CREMA, GRIS_B, AMARILLO = "331F0E", "FDF3D8", "D9D9D9", "F7BD0C"
+V_FILL, V_FONT = "C6EFCE", "006100"   # verde
+A_FILL, A_FONT = "FFEB9C", "9C6500"   # amarillo
+R_FILL, R_FONT = "FFC7CE", "9C0006"   # rojo
+G_FILL, G_FONT = "F2F2F2", "595959"   # gris
+
+C_PCT, C_BLQ, C_EST, C_TRAB, C_STAT = 7, 8, 9, 10, 11
+
+# --- Horas por fila del Excel --------------------------------------------------
+# Las actividades del CSV no mapean 1:1 con las filas del plan (el CSV agrupa por
+# actividad contractual; el Excel desglosa por tarea de proyecto). Se reparten por
+# fila usando la evidencia de la bitácora, de modo que cada fila muestre el trabajo
+# que realmente le corresponde y la suma siga cuadrando con el CSV.
+#
+# Trazabilidad de Etapa 1 (19.75 h del CSV):
+#   E1-01 6.50 = backend base 3.50 (13-14 jul) + B0/B1 1.00 + B2 0.50 + B3 0.50 + B4 1.00
+#   E1-02 0.50 = repositorio GitHub
+#   E1-03 2.00 = multi-tenant 1.50 (14-15 jul) + B6 RLS 0.50
+#   E1-04 2.00 = cliente de BIND
+#   E1-05 3.30 = gestión 0.50 + corte 16-jul 1.00 + cierre 21-jul 0.25 + prep 0.75 + sesión 0.80
+#   E1-06 3.25 = scaffold 2.00 + entorno local 1.00 + Scalar 0.25
+#   E1-07 0.20 = sesión API de Jira
+#   E1-08 2.00 = diseño del plan de Etapa 1
+HORAS_POR_FILA = {
+    # --- Etapa 0 (21.83 h) — una actividad del CSV por fila
+    #   E0-02 3.83 = sesión facturación 1.08 + análisis 1.00 + sesión cobranza 1.00 + notas 0.75
+    #   E0-07 1.50 = guion 0.45 + sesión de validación 1.05 (transcript: 1 h 4 min)
+    "Sesión de arranque (kickoff)":               2.00,   # E0-01
+    "Sesión de Discovery":                        3.83,   # E0-02
+    "Entrega y validación de accesos":            1.00,   # E0-03
+    "Validación técnica de la API de BIND":       4.50,   # E0-04
+    "Prototipo visual navegable":                 7.50,   # E0-05
+    "Documento de hallazgos":                     1.50,   # E0-06
+    "Sesión de validación del prototipo":         1.50,   # E0-07 (guion 0.45 + sesión 1.05)
+    # --- Etapa 1 (19.75 h)
+    # El trabajo de andamiaje (entorno local, scaffold, Scalar) y el diseño del plan
+    # no tienen fila propia en el plan original: se cargan a la fila técnica que les
+    # corresponde por naturaleza, no a la de seguimiento semanal.
+    "Repositorio privado GitHub":                 0.50,   # E1-02
+    "Backend base":                               8.25,   # E1-01 5.00 + E1-06 3.25 (entorno, scaffold, Scalar)
+    "Arquitectura multi-tenant":                  3.00,   # E1-03 2.00 (incl. B6 RLS) + E1-08 1.00 (diseño general)
+    "Cliente de la API de BIND":                  2.00,   # E1-04
+    "Sincronización de clientes":                 0.50,   # E1-01 parte: B3
+    # B4 produjo dos cosas: el sync de facturas/cotizaciones y el modelo central
+    # (InvoiceStatusMapper con 13 pruebas + migración DetalleSyncPendiente). Se
+    # reparte para que ninguna fila quede en 0 h marcada como avanzada.
+    "Sincronización de facturas":                 0.50,   # E1-01 parte: B4 (sync)
+    "Modelo de facturas":                         0.50,   # E1-01 parte: B4 (mapper + migraciones)
+    "Sesión de reglas y dudas":                   1.55,   # E1-05 parte: prep 0.75 + sesión 0.80
+    "Definición de alcance Jira":                 0.20,   # E1-07
+    "Demostración semanal":                       1.75,   # E1-05 resto: gestión 0.50 + corte 1.00 + cierre 0.25
+    # Análisis y diseño de B7 (pipeline Draft→DryRun→Confirm, flags, regla PPD/PUE,
+    # ADR-001): 1.00 h de E1-08, separada del diseño general para que la fila del
+    # entregable 4 muestre el trabajo que sí se hizo. La implementación sigue en pausa.
+    "Capa de escritura controlada":               1.00,
+    # --- Sin horas aún (trabajo no iniciado o dependiente de Balam)
+    "Configuración de infraestructura en Azure":  0.00,
+    "CI/CD":                                      0.00,
+}
+
+
+def horas_por_actividad(path):
+    """Suma horas del CSV por actividad_id y por etapa."""
+    por_act = defaultdict(float)
+    por_etapa = defaultdict(float)
+    with open(path, encoding="utf-8", newline="") as fh:
+        rdr = csv.DictReader(fh)
+        for i, r in enumerate(rdr, start=2):
+            if not (r.get("fecha") or "").strip():
+                continue
+            if None in r or any(v is None for v in r.values()):
+                raise ValueError(
+                    f"{os.path.basename(path)} línea {i}: número de campos inesperado "
+                    f"(¿falta escapar una coma con comillas?)")
+            h = float(r["horas"])
+            por_act[r["actividad_id"]] += h
+            por_etapa[r["etapa"]] += h
+    return por_act, por_etapa
+
+
+HORAS_ACT, HORAS_ETAPA = horas_por_actividad(CSV_HORAS)
+TOTAL_CSV = sum(HORAS_ETAPA.values())
+
+# % por entregables terminados (dato duro y defendible, no promedio ponderado).
+# Etapa 1: 6 de 8 entregables contractuales TERMINADOS (1,2,3,5,6,7) = 75%. Los dos
+# restantes van parciales y su avance se refleja en su propia fila (entregable 4 al
+# 40%, entregable 8 al 85%), no promediado en el encabezado: la etapa se mide por
+# entregable cerrado, que es lo verificable.
+PCT_ETAPA = {"0": 1.0, "1": 0.75}
+
+OVERRIDES = {
+    "Integracion de plataformas Balam": dict(pct=0.80, trab=TOTAL_CSV),
+    "Etapa 0": dict(pct=PCT_ETAPA["0"], trab=HORAS_ETAPA["0"]),
+    "Etapa 1": dict(pct=PCT_ETAPA["1"], trab=HORAS_ETAPA["1"]),
+    "Documento de hallazgos": dict(pct=1.0),
+    "Sesión de validación del prototipo": dict(pct=1.0, comienzo="vie 24/07/26",
+                                               fin="vie 24/07/26"),
+    # Estas dos filas absorben el andamiaje y el diseño del plan: se renombran y se
+    # amplía su rango estimado para que el nombre refleje el alcance que cubren.
+    "Backend base": dict(
+        nombre="Backend base: entorno, andamiaje, autenticación, roles y bitácora",
+        est="8–9"),
+    "Arquitectura multi-tenant": dict(
+        nombre="Arquitectura multi-tenant (tenant_id + RLS) y diseño de la solución",
+        est="3–4"),
+    "Demostración semanal": dict(est="2–3"),
+    # B7: diseño, ADR-001, entidad WriteOperation (migrada en B1) y policy
+    # PuedeOperarEscritura ya existen; falta BindWriteClient, el pipeline y los
+    # shapes de los POST (dependen de las reglas del 28-jul). Sin horas propias:
+    # las del modelo y la policy ya están cobradas en B1/B2 ("Backend base").
+    "Capa de escritura controlada": dict(pct=0.40),
+    "Sesión de reglas y dudas": dict(pct=1.0),
+    "Sincronización de clientes": dict(pct=1.0),
+    "Sincronización de facturas": dict(pct=1.0),
+    # Conectividad resuelta el 27-jul (token PAF a 1 año, API read+write, bandeja FAC,
+    # límites de consumo). Queda el 10 %: qué estatus dispara qué, amarrado al 28-jul.
+    "Definición de alcance Jira": dict(pct=0.90),
+}
+
+# Estatus a mano (gana sobre el semáforo automático): texto, fill, font, negrita
+K_ESPECIAL = {
+    "Documento de hallazgos": ("✅ Completada", V_FILL, V_FONT, False),
+    "Sesión de validación del prototipo": ("✅ Validado (aprobado)", V_FILL, V_FONT, True),
+    "Demostración semanal": ("🟡 En curso (semanal)", A_FILL, A_FONT, False),
+    "Modelo de facturas": ("🟡 Modelo y migraciones ✓ · falta seeder", A_FILL, A_FONT, False),
+    "Capa de escritura controlada": ("🔴 Diseño listo · impl. en pausa (def. Balam 28-jul)",
+                                     R_FILL, R_FONT, True),
+    "Sesión de reglas y dudas": ("✅ Completada", V_FILL, V_FONT, False),
+    "Definición de alcance Jira": ("🟡 Conectividad lista · falta regla 28-jul",
+                                   A_FILL, A_FONT, False),
+    "Configuración de infraestructura en Azure": ("🟡 Pendiente (Balam)", A_FILL, A_FONT, False),
+    "CI/CD": ("🔴 Pendiente · dep. Azure", R_FILL, R_FONT, True),
+}
+
+
+def fecha(celda):
+    m = re.search(r"(\d{2})/(\d{2})/(\d{2})", str(celda or ""))
+    return date(2000 + int(m.group(3)), int(m.group(2)), int(m.group(1))) if m else None
+
+
+def pinta(celda, fill, font_color, bold=False):
+    celda.fill = PatternFill("solid", fgColor=fill)
+    celda.font = Font(color=font_color, bold=bold, size=10)
+    celda.alignment = Alignment(horizontal="center", vertical="center")
+
+
+wb = openpyxl.load_workbook(SRC)
+ws = wb.active
+
+# 1) Horas trabajadas desde el CSV + overrides de datos por prefijo de nombre
+for row in range(2, ws.max_row + 1):
+    nombre = str(ws.cell(row=row, column=1).value or "").strip()
+    if not nombre:
+        continue
+
+    # 1a) horas por fila (reparto trazable al CSV; ver HORAS_POR_FILA)
+    for prefijo, h in HORAS_POR_FILA.items():
+        if nombre.startswith(prefijo):
+            ws.cell(row=row, column=C_TRAB, value=h)
+            break
+
+    # 1b) overrides de %, fechas, nombre y rango estimado
+    for prefijo, ov in OVERRIDES.items():
+        if nombre.startswith(prefijo):
+            if "pct" in ov:      ws.cell(row=row, column=C_PCT, value=ov["pct"])
+            if "trab" in ov:     ws.cell(row=row, column=C_TRAB, value=round(ov["trab"], 2))
+            if "comienzo" in ov: ws.cell(row=row, column=3, value=ov["comienzo"])
+            if "fin" in ov:      ws.cell(row=row, column=4, value=ov["fin"])
+            if "est" in ov:      ws.cell(row=row, column=C_EST, value=ov["est"])
+            break
+
+# 2) Recalcula el semáforo con HOY=27-jul (mismas reglas que el del 21-jul)
+for row in range(2, ws.max_row + 1):
+    nombre = str(ws.cell(row=row, column=1).value or "").strip()
+    if not nombre or nombre.startswith("✅") or nombre.startswith("▬"):
+        continue
+    es_etapa = nombre.startswith("Etapa") or nombre.startswith("Integracion")
+    pct = ws.cell(row=row, column=C_PCT).value or 0
+    fin = fecha(ws.cell(row=row, column=4).value)
+    ini = fecha(ws.cell(row=row, column=3).value)
+    stat = ws.cell(row=row, column=C_STAT)
+
+    if es_etapa:
+        stat.value = ""
+    elif pct >= 1:
+        stat.value = "✅ Completada";  pinta(stat, V_FILL, V_FONT)
+    elif fin and fin < HOY:
+        stat.value = "🔴 Vencida";     pinta(stat, R_FILL, R_FONT, bold=True)
+    elif ini and ini <= HOY:
+        stat.value = "🟡 En curso";    pinta(stat, A_FILL, A_FONT)
+    elif pct > 0:
+        stat.value = "🟢 Adelantada";  pinta(stat, V_FILL, V_FONT)
+    else:
+        stat.value = "⚪ Próxima";     pinta(stat, G_FILL, G_FONT)
+
+    # semáforo en la celda de %
+    pcel = ws.cell(row=row, column=C_PCT)
+    if not es_etapa:
+        if pct >= 1:                  pinta(pcel, V_FILL, V_FONT, bold=True)
+        elif pct > 0:                 pinta(pcel, A_FILL, A_FONT, bold=True)
+        elif fin and fin < HOY:       pinta(pcel, R_FILL, R_FONT, bold=True)
+    pcel.number_format = "0%"
+    ws.cell(row=row, column=C_TRAB).number_format = "0.00"
+
+# 3) Overrides finos de estatus (bloqueos y dependencias)
+for row in range(2, ws.max_row + 1):
+    nombre = str(ws.cell(row=row, column=1).value or "").strip()
+    for prefijo, (txt, fill, font, bold) in K_ESPECIAL.items():
+        if nombre.startswith(prefijo):
+            stat = ws.cell(row=row, column=C_STAT)
+            stat.value = txt
+            pinta(stat, fill, font, bold)
+            break
+
+# 4) Renombra las filas que absorbieron alcance (al final: los pasos 2-3 buscan por
+#    el nombre original)
+for row in range(2, ws.max_row + 1):
+    nombre = str(ws.cell(row=row, column=1).value or "").strip()
+    for prefijo, ov in OVERRIDES.items():
+        if "nombre" in ov and nombre.startswith(prefijo):
+            ws.cell(row=row, column=1, value=ov["nombre"])
+            break
+
+# 5) Encabezado de la columna de estatus
+ws.cell(row=1, column=C_STAT, value=f"Estatus (hoy {HOY.day}-jul)")
+
+# 6) Reescribe leyenda/notas (borra las viejas)
+for row in range(ws.max_row, 1, -1):
+    v = str(ws.cell(row=row, column=1).value or "")
+    if v.startswith(("✅ Completada ·", "▬ La línea roja", "Núcleo de la Etapa 1",
+                     "🔴 La capa de escritura", "API de Jira:", "Horas:")):
+        for col in range(1, C_STAT + 1):
+            ws.cell(row=row, column=col).value = None
+
+ley = ws.max_row + 2
+notas = [
+    ("✅ Completada · 🟡 En curso · 🔴 Vencida/Pendiente · ⚪ Próxima", G_FONT, True),
+    (f"Horas: {HORAS_ETAPA['0']:.2f} h de Etapa 0 y {HORAS_ETAPA['1']:.2f} h de Etapa 1 "
+     f"({TOTAL_CSV:.2f} h en total), conforme al control local de horas trabajadas. "
+     f"Etapa 1 estimada en 32–39 h.", CAFE, False),
+    ("Etapa 1: 6 de 8 entregables contractuales terminados — autenticación y roles con "
+     "bitácora, multi-tenant con RLS, cliente de BIND, sincronización de clientes, "
+     "sincronización de facturas y cotizaciones, y modelo de facturas con estados y "
+     "cartera por moneda. Verificado contra producción: 1,494 facturas sincronizadas "
+     "con la cartera cuadrada.", CAFE, False),
+    ("🔴 La capa de escritura (cotización→factura) queda EN PAUSA a la espera de la "
+     "definición del flujo de facturación (sesión del martes 28-jul con Arturo y Araceli).",
+     "9C0006", False),
+    ("Pendientes menores: datos de prueba (seeder) y verificación del aislamiento RLS "
+     "con rol no-superusuario. Azure y CI/CD dependen de accesos del lado de Balam.", CAFE, False),
+    ("API de Jira: token recibido el 27-jul; la integración inicia una vez definido el flujo.",
+     CAFE, False),
+]
+for i, (txt, color, bold) in enumerate(notas):
+    c = ws.cell(row=ley + i, column=1, value=txt)
+    c.font = Font(italic=True, size=9, color=color, bold=bold)
+
+ws.freeze_panes = "A2"
+ws.oddFooter.center.text = (f"Avance al 27-jul-2026 · {TOTAL_CSV:.2f} h trabajadas "
+                            "conforme al control local (pendiente conciliar con Jira)")
+
+wb.save(DST)
+
+# --- Verificación: el detalle debe cuadrar con el encabezado de cada etapa -----
+print("OK ->", DST)
+print(f"   Etapa 0: {HORAS_ETAPA['0']:.2f} h · Etapa 1: {HORAS_ETAPA['1']:.2f} h "
+      f"· TOTAL {TOTAL_CSV:.2f} h")
+suma_detalle = sum(HORAS_POR_FILA.values())
+ok = abs(suma_detalle - TOTAL_CSV) < 0.01
+print(f"   Suma del detalle mostrado: {suma_detalle:.2f} h "
+      f"({'cuadra con el CSV' if ok else f'NO CUADRA (CSV {TOTAL_CSV:.2f})'})")
+if not ok:
+    raise SystemExit("El detalle por fila no cuadra con el CSV — revisar HORAS_POR_FILA.")

planeacion/generar_resumen_erika_2026_07_27.py

@@ -0,0 +1,175 @@
+"""Genera Avance-Balam-2026-07-27.xlsx — versión SIMPLE para enviar a Erika.
+
+Se construye desde el Excel interno (`Plan-actividades-avance-2026-07-27.xlsx`),
+que a su vez lee las horas de `Seguimiento-horas.csv`. Así los dos archivos nunca
+se contradicen: este es una vista reducida, no una segunda fuente de datos.
+
+Formato pedido por Erika el 21-jul: entregable + actividad + horas por etapa.
+Se quitan del interno: rangos estimados, bloques del plan (B1/B4/B9), predecesoras
+y duración en días — ruido para quien solo da seguimiento.
+"""
+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-27.xlsx")
+HOY = date(2026, 7, 27)
+
+# 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"
+
+# Columnas del origen
+O_NOMBRE, O_INI, O_FIN, O_PCT, O_TRAB, O_STAT = 1, 3, 4, 7, 10, 11
+
+thin = Side(style="thin", color=BORDE)
+box = Border(left=thin, right=thin, top=thin, bottom=thin)
+
+
+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 ""
+
+
+def es_etapa(nombre):
+    return nombre.startswith(("Etapa", "Integracion"))
+
+
+# --- Lee el interno -----------------------------------------------------------
+wsrc = openpyxl.load_workbook(SRC).active
+filas = []
+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
+    filas.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,
+        "trab": wsrc.cell(row=row, column=O_TRAB).value,
+        "stat": str(wsrc.cell(row=row, column=O_STAT).value or "").strip(),
+        "etapa": es_etapa(nombre),
+    })
+
+# --- Construye el simple ------------------------------------------------------
+wb = openpyxl.Workbook()
+ws = wb.active
+ws.title = "Avance"
+
+ws["A1"] = "Proyecto Balam · Plataforma de Automatización Financiera"
+ws["A1"].font = Font(bold=True, size=14, color=CAFE)
+ws["A2"] = f"Avance al {HOY.day}-jul-2026"
+ws["A2"].font = Font(size=10, italic=True, color=GRIS)
+
+ENC = ["Actividad", "Inicio", "Fin", "Avance", "Horas", "Estatus"]
+ANCHOS = [52, 12, 12, 10, 9, 34]
+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")
+    c.border = box
+    ws.column_dimensions[get_column_letter(i)].width = ancho
+
+r = FILA_ENC + 1
+for f in filas:
+    fill_etapa = PatternFill("solid", fgColor=CREMA) if f["etapa"] else None
+
+    c = ws.cell(row=r, column=1, value=f["nombre"])
+    c.font = Font(bold=f["etapa"], size=10, color=CAFE)
+    c.alignment = Alignment(vertical="center", wrap_text=True,
+                            indent=0 if f["etapa"] else 1)
+
+    for col, val in ((2, f["ini"]), (3, f["fin"])):
+        cc = ws.cell(row=r, column=col, value=val)
+        cc.font = Font(size=9, color=GRIS)
+        cc.alignment = Alignment(horizontal="center", vertical="center")
+
+    # Avance
+    cp = ws.cell(row=r, column=4, value=f["pct"])
+    cp.number_format = "0%"
+    cp.alignment = Alignment(horizontal="center", vertical="center")
+    if f["pct"] >= 1:
+        cp.font = Font(bold=True, size=10, color=V_FONT)
+        cp.fill = PatternFill("solid", fgColor=V_FILL)
+    elif f["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)
+
+    # Horas
+    ch = ws.cell(row=r, column=5, value=f["trab"])
+    ch.number_format = "0.00"
+    ch.font = Font(bold=f["etapa"], size=10, color=CAFE)
+    ch.alignment = Alignment(horizontal="center", vertical="center")
+
+    # Estatus
+    cs = ws.cell(row=r, column=6, value=f["stat"])
+    cs.alignment = Alignment(horizontal="left", vertical="center", wrap_text=True)
+    cs.font = Font(size=9, color=GRIS)
+    if f["stat"].startswith("✅"):
+        cs.font = Font(size=9, color=V_FONT); cs.fill = PatternFill("solid", fgColor=V_FILL)
+    elif f["stat"].startswith("🟡"):
+        cs.font = Font(size=9, color=A_FONT); cs.fill = PatternFill("solid", fgColor=A_FILL)
+    elif f["stat"].startswith("🔴"):
+        cs.font = Font(size=9, bold=True, color=R_FONT); cs.fill = PatternFill("solid", fgColor=R_FILL)
+
+    for col in range(1, 7):
+        ws.cell(row=r, column=col).border = box
+        if fill_etapa and col in (1, 2, 3):
+            ws.cell(row=r, column=col).fill = fill_etapa
+    r += 1
+
+# --- Notas --------------------------------------------------------------------
+tot = next((f["trab"] for f in filas if f["nombre"].startswith("Integracion")), 0)
+e0 = next((f["trab"] for f in filas if f["nombre"].startswith("Etapa 0")), 0)
+e1 = next((f["trab"] for f in filas if f["nombre"].startswith("Etapa 1")), 0)
+
+notas = [
+    ("", False),
+    (f"Horas trabajadas: {e0:.2f} h en Etapa 0 y {e1:.2f} h en Etapa 1 "
+     f"({tot:.2f} h en total).", True),
+    ("Etapa 1: 6 de los 8 entregables terminados — autenticación y roles con bitácora, "
+     "multi-tenant, cliente de la API de BIND, sincronización de clientes, "
+     "sincronización de facturas y cotizaciones, y modelo de facturas con estados y "
+     "cartera por moneda. Verificado contra producción: 1,494 facturas sincronizadas "
+     "con la cartera cuadrada.", False),
+    ("La capa de escritura (cotización→factura) está en pausa a la espera de la "
+     "definición del flujo de facturación (sesión del martes 28-jul).", False),
+    ("Azure y CI/CD esperan la configuración de los recursos del lado de Balam.", False),
+]
+for txt, bold in notas:
+    if txt:
+        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=6)
+        ws.row_dimensions[r].height = 28 if len(txt) > 110 else 14
+    r += 1
+
+ws.freeze_panes = f"A{FILA_ENC + 1}"
+ws.sheet_view.showGridLines = False
+ws.print_area = f"A1:F{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"   {len(filas)} filas · Etapa 0 {e0:.2f} h · Etapa 1 {e1:.2f} h · total {tot:.2f} h")