Bitácora #32: validación API BIND completada (adelantada); pendientes de escalación a Pedro
This commit is contained in:
JohannVelazquez
@@ -2,7 +2,7 @@
|
||||
|
||||
> **Fuente de la verdad del proyecto.** Este repositorio concentra todo: propuesta, comunicaciones, fuentes y prototipos. Si pasa algo (llamada, correo, mensaje, decisión), se registra en la [bitácora](bitacora/). Empieza por aquí.
|
||||
|
||||
**Estado:** 🟢 **Discovery en marcha (Etapa 0)** — contrato firmado (26-jun), kickoff realizado (1-jul), **primera sesión de Discovery realizada (6-jul: proceso de facturación mapeado end-to-end con Ara y Arturo)**. Cambios de reglas del 6-jul: **lista blanca eliminada** (recordatorios a todos) y **cotización BIND obligatoria**. Johann trabaja el **prototipo** con el flujo real. ✅ **Token BIND ENTREGADO** (6-jul, 12:40 pm, por correo) — arranca la validación técnica de la API. Sesión de **cobranza** propuesta para el mar 7-jul (Erika confirma agenda). Bloqueadores restantes: (1) repo GitHub y Azure; (2) confirmación de Balam a la propuesta v1.2 (enviada 2-jul) para emitir la **factura de 30 h**.
|
||||
**Estado:** 🟢 **Discovery en marcha (Etapa 0)** — contrato firmado (26-jun), kickoff realizado (1-jul), **primera sesión de Discovery realizada (6-jul: proceso de facturación mapeado end-to-end con Ara y Arturo)**. Cambios de reglas del 6-jul: **lista blanca eliminada** (recordatorios a todos) y **cotización BIND obligatoria**. Johann trabaja el **prototipo** con el flujo real. ✅ **Token BIND entregado y VALIDACIÓN TÉCNICA de la API completada** (6-jul, adelantada al plan): **Plan A del saldo confirmado** (sin horas extra), flujo MVP sostenible 100% en lectura, PDF del CFDI por API; hueco: sin recurso de pagos/REP (escalar a Pedro). Detalle en [`bind-api-sandbox/VALIDACION-API.md`](bind-api-sandbox/VALIDACION-API.md). Sesión de **cobranza** propuesta para el mar 7-jul (Erika confirma agenda). Bloqueadores restantes: (1) repo GitHub y Azure; (2) confirmación de Balam a la propuesta v1.2 (enviada 2-jul) para emitir la **factura de 30 h**.
|
||||
_Última actualización: 2026-07-06._
|
||||
|
||||
---
|
||||
|
||||
@@ -13,7 +13,9 @@ _Última actualización: 2026-07-06 (Discovery realizado: proceso mapeado, lista
|
||||
- [x] ~~📧 **Responder el correo de Pedro**~~ → **Enviado (6-jul, ~3:28 pm):** acuse de recibo + usuario de Arturo documentado + arranque de trabajo con la API, sin comprometer entregas adicionales. Ver [REGISTRO #29](REGISTRO.md).
|
||||
- [ ] 📧⚠️ **Responder el correo de Noé (importancia alta, 4:33 pm)** describiendo las **salvaguardas** ya operando: solo-lectura bloqueado en código, consultas acotadas, token en gestor de secretos fuera del repo, sin datos reales en documentos, escritura solo con autorización + candados de la propuesta. Borrador listo. Ver [REGISTRO #31](REGISTRO.md).
|
||||
- [ ] ⚠️ **No atar nada al token actual:** Pedro está revisando permisos y puede **reemplazarlo** por uno de un usuario nuevo de solo lectura — mantener el token como variable de entorno intercambiable (ya es así en el sandbox). Ver [REGISTRO #31](REGISTRO.md).
|
||||
- [ ] 🔑 **Validar la API de BIND con el token real** (mar 7 – mié 8 del plan; puede adelantarse) — guardar el token en **gestor de secretos** (no dejarlo en el correo/.txt), correr el sandbox (`bind-api-sandbox/`) contra `api.bind.com.mx` en **solo lectura**, documentar cobertura de endpoints (facturas, clientes, pagos, cotizaciones) y confirmar si caduca. Entregar resumen de hallazgos. Ver [REGISTRO #28](REGISTRO.md).
|
||||
- [x] ~~🔑 **Validar la API de BIND con el token real**~~ → ✅ **Hecha (6-jul, adelantada un día):** 117 peticiones GET-only, Plan A del saldo CONFIRMADO, flujo MVP 100% sostenible en lectura, PDF por API. Hallazgo duro: **sin recurso de pagos/REP**. Documento: [`../bind-api-sandbox/VALIDACION-API.md`](../bind-api-sandbox/VALIDACION-API.md). Ver [REGISTRO #32](REGISTRO.md).
|
||||
- [ ] 📨 **Escalar a Pedro las preguntas técnicas de la API** (juntas, esta semana): (1) ¿existe endpoint de **pagos individuales / complementos de pago (REP)** no documentado? — es el hueco más relevante para el flujo PPD; (2) **tabla de mapeo `CFDIUse`** interno → clave SAT; (3) shape del endpoint `/{id}/xml`; (4) ¿webhooks/eventos o solo polling? Ver [REGISTRO #32](REGISTRO.md) §10.
|
||||
- [ ] 🔐 **Higiene del token:** moverlo a un gestor de secretos y **borrar `bind_token_api.txt`** de la raíz del repo y del correo/descargas (está gitignoreado, pero sigue en disco).
|
||||
- [ ] ⚠️ **Aclarar expectativa de recordatorios a clientes:** lo que Ara/Arturo describieron el 6-jul son recordatorios automáticos **a clientes**, que están **diferidos al Anexo B** (el MVP trae alertas *internas*). Aclararlo pronto o anticipar que pidan ese módulo al cierre del MVP. Igual con la idea de **agentes observando Jira** (Nivel 3, fase posterior) y el deseo **multi-empresa** (Regiotour, Elmstone). Ver [REGISTRO #27](REGISTRO.md).
|
||||
- [x] ~~**Ajustar la propuesta** (30 h explícitas, sin "Etapa 0", términos comerciales en una sección)~~ → **Hecho (1-jul):** propuesta **v1.2** — se agregó el concepto **"Facturación inicial: 30 h / $18,000 + IVA"** (cubre Etapa 0 + inicio de Etapa 1; Etapa 0 se mantiene en 18–22 h) y se consolidó **§3.3 Condiciones comerciales**. Fuente MD actualizada; **falta regenerar el PDF** (lo hace el agente de PDF de Johann con el mismo cambio).
|
||||
- [x] ~~📧 **Enviar el correo** (Noé, CC Pedro, Ara, Erika) con la propuesta v1.2 ajustada, vinculando la **facturación inicial de 30 h** al acuerdo~~ → **Hecho (2-jul, 5:39 PM):** enviado con `Propuesta-Balam.pdf` adjunto, sin esperar el correo de Erika+Paola. Ver [REGISTRO #26](REGISTRO.md).
|
||||
|
||||
@@ -620,6 +620,29 @@ Noé responde al hilo de la entrega del token con dos instrucciones:
|
||||
|
||||
---
|
||||
|
||||
## 32 · Jul 6, 2026 — tarde · Validación técnica de la API de BIND con la cuenta real ⭐ ✅
|
||||
|
||||
> Actividad del plan "Validación técnica de la API de BIND" (mar 7 – mié 8) — **ejecutada un día antes**, el mismo día en que llegó el token. Evidencia completa: [`../bind-api-sandbox/VALIDACION-API.md`](../bind-api-sandbox/VALIDACION-API.md) (117 peticiones, exclusivamente GET, solo estructura — cero datos reales persistidos).
|
||||
|
||||
**Veredictos clave:**
|
||||
|
||||
1. ✅ **Plan A del saldo CONFIRMADO** — el riesgo central de la propuesta quedó resuelto a favor: cada fila de `Invoices` trae `Total`, `Payments` (acumulado) y `CreditNotes`; el saldo por factura es una resta local, verificada aritméticamente. **No se activa el Plan C (+6–8 h)** — la inversión apunta a la parte baja del rango.
|
||||
2. ✅ **El flujo del MVP es 100% sostenible en lectura:** cotizaciones legibles (con partidas y comercial), prefacturas distinguibles (`UUID null` / `IsFiscalInvoice false`), PPD/PUE y días de crédito auditables (en el detalle), IVA por partida (habilita la validación 16%/0%), **PDF del CFDI descargable por API** (insumo del módulo de envío), aging viable con `ExpirationDate` + saldo.
|
||||
3. ❌ **No existe recurso de pagos individuales ni de complementos de pago (REP)** — 20 nombres probados, todos 404. La cobranza operativa del MVP funciona igual (detecta pago por transición de estatus/residual), pero la fecha valor del pago y los REP del flujo PPD no son visibles. **Escalar a Pedro.**
|
||||
4. ⚠️ **Sin vínculo cotización→factura en la API** — la trazabilidad la llevará la plataforma (registrar el par al orquestar la conversión).
|
||||
5. ⚠️ **Rarezas a cablear con cuidado:** token inválido responde 500 (no 401); `$select` y conteos no funcionan (paginación manual con `$top=100`); nomenclatura CFDI **invertida** vs SAT (`CFDIPaymentTerm` = PPD/PUE); `CFDIUse` es código interno (falta tabla de mapeo); typo real del API (`Loctaion`); campos clave solo en el detalle → **sync incremental obligatorio**.
|
||||
6. ✅ **Token acotado a una sola empresa** (la de Arturo → Balam) — multi-empresa confirmado fuera del alcance por API.
|
||||
7. **Presupuesto de sync:** ~1,000 req/día con polling cada 15 min ≈ 5% del límite de 20K. Holgado.
|
||||
|
||||
**Preguntas que quedan para Pedro/doc (§10 del documento):** endpoint de pagos/REP no descubierto · tabla `CFDIUse` interno→clave SAT · shape del endpoint `/xml` · códigos de `Status` >2 · webhooks/eventos.
|
||||
|
||||
> **Lectura estratégica:**
|
||||
> - **El Discovery técnico ya pagó:** el Plan A confirmado elimina la mayor incertidumbre de horas de la propuesta, y todo lo que el MVP necesita en lectura existe. La actividad del plan se cerró **anticipada** — buen dato para el corte de Erika del lunes.
|
||||
> - El hueco de REP/pagos es real pero **no bloquea el MVP** (cobranza operativa funciona por transición de estatus); importa para el flujo PPD completo y para conciliación (Anexo B). Escalarlo con Pedro esta semana, idealmente junto con la tabla de `CFDIUse`.
|
||||
> - Las salvaguardas prometidas a Noé ([#31](#31--jul-6-2026--433-pm--correo--noé--johann-pedro-cc-erika--salvaguardas-sobre-el-token-)) se cumplieron al pie: GET-only por construcción, presupuesto de peticiones, reporte sanitizado, token fuera de git.
|
||||
|
||||
---
|
||||
|
||||
## Resumen ejecutivo del hilo (para contexto rápido)
|
||||
|
||||
### Datos duros confirmados por Balam
|
||||
|
||||
Reference in New Issue
Block a user