diff --git a/bitacora/REGISTRO.md b/bitacora/REGISTRO.md index 4a839b5..eb48b3a 100644 --- a/bitacora/REGISTRO.md +++ b/bitacora/REGISTRO.md @@ -1595,6 +1595,13 @@ Se aplicó el protocolo del guion §6: parar, anunciar el diagnóstico, pivotear - ⭐ **El discriminador observable es la SECUENCIA DE FOLIOS:** las prefacturas de la UI comparten numeración con las facturas (2384 → 2385 → 2386 fue nuestro incidente); nuestros `false` por API caen en la secuencia de remisiones (arrancó en 1000, virgen porque Balam no usa remisiones). Hipótesis operativa: la UI etiqueta por secuencia/typo interno; el body de `Invoices_AddInvoice` trae `Number` y `Serie` — **candidato a experimento seguro**: POST con `false` + `Number` apuntando a la secuencia compartida (+ espejo exacto de 2384: `CFDIUse=23`, `ShowIEPS=true`, plazo), verificar en UI cómo cae, y borrar si cae mal. Riesgo máximo: un documento no fiscal borrable con folio raro. Solo con go-ahead explícito y `Bind:Mode=Write` en sesión. - **Detección construible YA sin tocar nada:** prefactura de UI = fila `false` nueva (ligable a cotización/ticket por cliente+monto+fecha) y su facturación = fila pasa a 2 + gemela `true` timbrada. El flujo "plataforma cotiza → Araceli genera prefactura en BIND → plataforma detecta, liga y avisa el timbrado" funciona con el API actual, sin escribir. +**ADENDA 2 (27-ago, madrugada) — el API público queda agotado por eliminación TOTAL.** Experimentos autorizados de la sesión Write con Johann (todos con `false`, todos borrables): +- **Op #79 (folio 1002, $580, FAC-109/cotización 1029):** se mandó `Number: 2387` (siguiente de la secuencia compartida) + espejo de la 2384 (`ShowIEPS`, plazo 30) → **BIND IGNORÓ el `Number`** y asignó 1002 en la secuencia de remisiones. La palanca del folio no existe hacia adentro. +- **Sonda de campos no documentados (folio 1003, $116, borrada → "Cancelada"):** un POST con 12 candidatos a campo interno de tipo (`UseStock`, `ApplyStock`, `AffectsInventory`, `DocumentType/DocType/SaleType/InvoiceType: 2`, `IsPreInvoice/IsPrefactura/IsPreliminary/IsDraft/Prefactura: true`) → **todos ignorados** (folio de remisiones, sin cambio de tipo). `DELETE /api/Invoices/{id}` funciona (204) pero es borrado suave: deja la fila como Cancelada. +- Dump crudo del APIM: **98 operaciones** (no 130), ninguna de prefactura/conversión. `/api/Series?docType=0..20` todo vacío; `CompanyProfile` sin foliado. La web app (app.bind.com.mx) es ASP.NET MVC con login — su creación de ventas NO pasa por api.bind.com.mx. +- **Conclusión definitiva:** `Invoices_AddInvoice` produce Remisión (`false`) o CFDI timbrado (`true`); el tipo Prefactura se decide en un camino interno de su UI al que el API público no llega por ningún campo, folio ni recurso. +- **La manera que SÍ queda** (además de detección y de soporte BIND): capturar el endpoint interno de la UI con un navegador instrumentado (Playwright, script `captura-prefactura.mjs` — registra POST/PUT a bind.com.mx excluyendo login/credenciales) y evaluar replicarlo con sesión de cookies (RPA ligero) o usarlo como evidencia ante BIND para pedir el campo en su API. + > **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.