Registro #70: el incidente del timbrado y el cierre de la investigación — el API de BIND ni crea ni ve prefacturas; candado triple y experimento decisivo pendiente

bitacora/PENDIENTES.md

@@ -4,6 +4,14 @@ Acciones vivas del proyecto. Formato: `[ ]` abierta · `[x]` cerrada (no se borr
 
 _Última actualización: **2026-08-21, mediodía** — ⭐ primera cotización real emitida (folio 1026; la 2.ª, corregida, pendiente de confirmar). Anterior: **2026-08-20, noche.** Cruce completo del buzón contra la bitácora (MCP ms365): se incorporaron 9 comunicaciones faltantes y se corrigieron 2 errores de registro. **Hay sesión mañana viernes 21-ago, 7:00 am** con Noé, Ara y Pedro sobre el formulario modificado y `FAC-106`. Ver [REGISTRO #65](REGISTRO.md)–[#68](REGISTRO.md)._
 
+## 🔥🔴 26-ago — incidente del timbrado y cierre de la investigación ([REGISTRO #70](REGISTRO.md))
+
+- [ ] 🔥🔴 **CANCELAR EL CFDI 2386 EN BIND** (motivo SAT 02 "sin relación"). ⚠️ **Al 26-ago tarde sigue `Activa` con UUID** — verificado por API. Receptor ACUNTIA (RFC genérico extranjero, $1,160 MXN). Confirmar además que BIND no le haya enviado el correo automático al cliente.
+- [ ] 📧 **Avisar a Noé/Arturo del incidente con transparencia** (qué pasó, por qué, contención aplicada, CFDI cancelado). La plataforma tiene la auditoría completa en `WriteOperations` #73.
+- [ ] 🧪 **Experimento decisivo (riesgo cero): crear UNA prefactura a mano en la UI de BIND** (Generar Venta → Prefactura, cliente de prueba; documento no fiscal y borrable) y avisar a Johann el folio → re-escanear el API para ver si aparece y con qué firma. De esto depende si la plataforma puede siquiera DETECTAR prefacturas, o solo el timbrado posterior.
+- [ ] 📧 **Preguntar a Pedro / soporte BIND:** "¿cómo se crea una venta de tipo *Prefactura* por API? `Invoices_AddInvoice` solo distingue `IsFiscalInvoice` (false=remisión, true=factura timbrada al crear)". Adjuntar la evidencia del #70.
+- [ ] 🧹 **Borrar las remisiones 1000 y 1001** (siguen `Activas`). En la UI, o por API (`DELETE /api/Invoices/{id}`) con autorización expresa.
+
 ## ✅ 21-ago — la cotización ya se emite; lo que deja la sesión ([REGISTRO #69](REGISTRO.md))
 
 - [ ] 🔥 **Cancelar el folio 1026 en BIND** (IVA 243,640.96 por el error de escala). Araceli o Johann, desde Ventas → Cotizaciones.

bitacora/REGISTRO.md

@@ -1573,6 +1573,30 @@ Se aplicó el protocolo del guion §6: parar, anunciar el diagnóstico, pivotear
 
 ---
 
+## 70 · Ago 26, 2026 · Incidente + investigación de cierre · IsFiscalInvoice=true TIMBRA al crear (folio 2386) — y el API de BIND ni crea ni VE prefacturas 🔥⚠️
+
+> Contexto: entre el 23 y el 25-ago se construyó el camino cotización→prefactura (`POST /api/emision/prefactura`, mismo protocolo ADR-001). Los intentos con `IsFiscalInvoice=false` produjeron los folios 1000 y 1001 **como remisiones** (confirmado por Noé por correo), así que se cambió a `true` bajo la hipótesis "true = factura sin timbrar = la prefactura del flujo" — el API no tiene operación de timbrado (130 operaciones revisadas), y de ahí se infirió que crear no podía timbrar.
+
+**El incidente:** el 26-ago, al confirmar desde el wizard (op #73, cotización 1028 / ticket FAC-108), BIND creó la venta **2386 como Factura Electrónica (CFDI) y la timbró en el acto** — UUID `aa70001d-…`, $1,160 MXN, receptor ACUNTIA. **El timbrado vive DENTRO de la creación**, no en una operación aparte; la ausencia de operación de timbrado significaba lo contrario de lo inferido. El tripwire de la plataforma (verificación por lectura post-creación, "⚠️ TIMBRADA" si UUID ≠ null) lo detectó al instante. Contención el mismo día: confirmación de prefactura **bloqueada con 409** en el endpoint (commit `c5143cf`, pusheado), API reiniciado en ReadOnly, instrucciones de cancelación SAT (motivo 02) comunicadas.
+
+**Investigación de cierre (misma fecha, SOLO GETs contra producción):**
+- **El body de `Invoices_AddInvoice` no tiene campo de tipo de documento.** Verificado contra dos fuentes primarias: el portal APIM (27 campos) y el swagger oficial del SDK de Python de BIND — coinciden campo por campo. El `UseStock` que sugieren los resúmenes de IA de Google **no existe** (respuesta fabricada; también da `UseCFDI:"G03"` como string cuando `CFDIUse` es un int interno).
+- **`false` = remisión, comprobado con la verdad impresa:** los PDFs por API (`GET /api/Invoices/{id}/pdf`) de 1000, 1001 y 2384 titulan **"Remision"**; el de 2386 titula "Factura Electrónica (CFDI)".
+- **No existe el estado intermedio:** 0 filas con `IsFiscalInvoice=true and UUID=null` en TODA la cuenta. BIND timbra al crear, siempre.
+- **Censo completo de no fiscales: 58 documentos, todos remisiones.** Únicos activos: nuestros 1000 y 1001; los otros 56, cancelados. **Ni una prefactura visible en `/api/Invoices`** — la afirmación de VALIDACION-API.md (6-jul) "false = prefactura" era una inferencia errada sobre filas que en realidad son remisiones.
+- `Orders` tampoco: 1 pedido (2024, cancelado). El detalle de venta no expone claves ocultas que discriminen tipo.
+- ⚠️ Efecto colateral del API detectado: la **lista** reporta `Status=2` en filas cuyo **detalle** dice `Activa` (1000/1001), y `Number` no es único entre series — la búsqueda por número es ambigua. Confiar solo en detalle por GUID.
+
+**Conclusión:** la "Prefactura" del combo de la UI de BIND **no es expresable ni observable por su API pública** con lo documentado. Queda una incógnita: dónde queda almacenada una prefactura creada por la UI (en esta cuenta nunca ha existido una, así que no hay espécimen que leer).
+
+> **Lectura estratégica:**
+> - **La salvaguarda que funcionó fue la de diseño, no la de inferencia:** dry-run + confirmación humana + verificación por lectura acotaron el daño a un folio cancelable. La lección: contra un API sin sandbox, ninguna inferencia negativa ("no hay operación X ⇒ X no puede pasar") es válida sin prueba positiva.
+> - **Candado triple ya en código** (commit local `fbb31fc`): `IsFiscalInvoice=false` clavado en el builder, `permitirFiscal:false` clavado en la llamada, y el 409 en Confirmed. `EsFiscal` quedó inerte.
+> - **Experimento decisivo pendiente (riesgo cero):** que un humano cree UNA prefactura en la UI de BIND (documento no fiscal, borrable) y re-escanear el API para ver si aparece y con qué firma. Si no aparece, el flujo de plataforma debe asumir que la prefactura es invisible por API y la detección automática solo puede ocurrir al timbrado (la factura sí es visible).
+> - ⚠️ **Al 26-ago (tarde) la 2386 sigue `Activa` con UUID en BIND — la cancelación SAT no se ha ejecutado.** Y 1000/1001 siguen activas (existe `DELETE /api/Invoices/{id}` si se quiere limpiar por API, con autorización).
+
+---
+
 ## Resumen ejecutivo del hilo (para contexto rápido)
 
 ### Datos duros confirmados por Balam