Documenta semana 24-27 jul: validación de prototipo (aprobada), API de Jira y avance de Etapa 1
- REGISTRO #55: validación del prototipo Etapa 0 (24-jul) APROBADA; único bloqueo = definir el flujo de facturación en Jira (sesión propuesta por Araceli para el martes 28) - REGISTRO #56: sesión de API de Jira con Pedro (27-jul) — token PAF a 1 año, bandeja FAC; + seguimiento por correo del mismo día con los límites de velocidad (65k puntos/h, burst/s, por-issue) y entrega del token por Google Drive - REGISTRO #57: hilo de WhatsApp con Erika (21-27 jul) — coordinación, envío del flujo por correo y reagenda 23→24 jul; 3 imágenes inferidas - Transcripciones y correo en fuentes/; guion de validación en planeacion/ - Avance-Etapa1-2026-07-27 (nota + mensaje para Erika) y Excel del corte del 27-jul (núcleo verificado; capa de escritura en pausa por definición de Balam) - Seguimiento-horas: sesiones del 24-jul (validación) y 27-jul (API Jira) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -971,6 +971,102 @@ Cierre de la sesión (~0.5 h real). **B6 conforme al plan:** `ITenantOwned` en l
|
||||
|
||||
---
|
||||
|
||||
## 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`.
|
||||
|
||||
---
|
||||
|
||||
## Resumen ejecutivo del hilo (para contexto rápido)
|
||||
|
||||
### Datos duros confirmados por Balam
|
||||
|
||||
Reference in New Issue
Block a user