Johann
61 lines
3.3 KiB
Markdown
61 lines
3.3 KiB
Markdown
# 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):
|
|
|
|
```json
|
|
{
|
|
"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.
|