Files
balam/planeacion/Script-cotizacion-sesion-2026-08-12.md

3.3 KiB

Script de la prueba acompañada — cotización BIND desde un ticket de Jira

Sesión: miércoles 12-ago-2026, 7:00 am · Alcance: el ejercicio termina en la cotización en BIND (sin prefactura, sin timbrado, sin tocar Jira).

Para enviar a Noé/Pedro (correo o WhatsApp) ANTES de la sesión — cumple el compromiso del 24-jul de compartir el script de escritura para revisión previa.


Qué se va a ejecutar (una sola operación)

POST https://api.bind.com.mx/api/Quotes — la operación Quotes_NewQuote del portal de desarrolladores de BIND. Crea una cotización. La respuesta es el ID del documento creado, que verificamos al momento con una lectura (GET /api/Quotes/{id}) para ver folio y total, y que ustedes pueden ver en su pantalla de Ventas → Cotizaciones.

Body de ejemplo (los valores reales salen del ticket de ejemplo y del catálogo de BIND; este es el shape exacto):

{
  "CurrencyID": "<GUID de la moneda, del catálogo de BIND>",
  "VATRate": 16,
  "Comments": "Generada desde el ticket FAC-nnn (prueba acompañada).",
  "ClientProspect": {
    "isNew": false,
    "Client": {
      "ClientId": "<GUID del cliente en BIND>",
      "ClientName": "<nombre tal como está en BIND>"
    }
  },
  "Items": [
    {
      "Title": "<concepto según el ticket>",
      "Unit": "Servicio",
      "Price": 0.0,
      "Qty": 1,
      "VAT": 0.0,
      "IEPS": 0,
      "IndexNumber": 1
    }
  ]
}

Datos que se toman del ticket de Jira: cliente (confirmado a mano contra el catálogo sincronizado de BIND — el ticket no trae RFC), monto sin IVA, moneda y el resumen como concepto. No se usa ningún dato del adjunto.

Candados (ADR-001, ya operando en el código)

  1. Dry-run primero, en pantalla. Antes de emitir se muestra el body EXACTO que saldría — lo revisamos juntos en la sesión. Cualquier edición invalida el dry-run.
  2. La escritura está apagada por default. El servidor corre en modo solo-lectura; el modo escritura se enciende al iniciar la sesión y se apaga al terminar. Fuera de ese modo, el botón de emitir no funciona (el servidor lo rechaza).
  3. Una operación por confirmación humana explícita (diálogo de confirmación con cliente y total). Sin lotes, sin reintentos automáticos de escritura.
  4. Todo queda auditado: cada dry-run y cada confirmación se persisten (usuario, fecha, payload, resultado) en la bitácora de operaciones de la plataforma.
  5. Permisos por rol: solo los roles de Finanzas/Administración de la plataforma pueden usar la pantalla de emisión.

Reversa

La cotización no tiene efecto fiscal. Al cierre de la sesión, ustedes deciden: cancelarla en BIND (queda el rastro, sin efecto) o conservarla si el ticket de ejemplo es un caso real que va a facturarse. Ambas salidas son de un clic en su pantalla de cotizaciones.

Qué NO hace este ejercicio

  • No crea prefactura ni factura, no timbra (eso queda para la siguiente sesión, con los candados acordados: cotización → prefactura → aprobación humana → timbrado).
  • No escribe nada en Jira (ni transiciones ni comentarios).
  • No crea ni modifica clientes en BIND.
  • No corre nada automático: el disparo es manual en esta prueba; la versión automática (detección del cruce a "En proceso de facturación") depende del ambiente en Azure.