Plan de Pruebas — ADR-008: Carta e identificación bloquean el pago
Fecha: 2026-09-12 Decisión: ADR-008 Ambiente: Dev local (./start-dev.sh) — http://localhost:5173
Antes de empezar
Cualquier transacción ACCEPTED del seed sirve — no tienen documentos todavía. Si hace falta una nueva:
bash
docker compose exec backend php artisan tinker --execute="
\$gt = App\Models\Country::where('iso_code','GT')->first();
App\Models\Transaction::create(['soterex_transaction_id'=>'STX-QA-ADR008','mtcn'=>'6666666666','status'=>'ACCEPTED','country_id'=>\$gt->id,'first_name'=>'Prueba','last_name'=>'ADR008','amount'=>100,'fee'=>3.5,'origin_currency'=>'USD','destination_country'=>'GT','sender'=>'US']);
"Usuarios de prueba
| Password | Rol | Alcance | |
|---|---|---|---|
backoffice@cislatam.test | Backoffice123! | Backoffice | Solo GT-CAP-001 |
admin@cislatam.test | Admin123! | Admin | Guatemala, todos los PDVs |
1. Bloqueo — pantalla Pago
| # | Paso | Resultado esperado |
|---|---|---|
| 1.1 | Buscar una ACCEPTED recién creada, sin documentos | Debajo del resultado aparece "Documentos para poder pagar" con 3 pasos numerados (Carta, Identificación anverso, Identificación reverso), badge "Faltan 3" |
| 1.2 | Mirar el botón "Iniciar pago" | Deshabilitado, con tooltip "Faltan: Carta de Soterex, Identificación (anverso), Identificación (reverso)" |
| 1.3 | Subir solo la Carta | Badge pasa a "Faltan 2"; el botón sigue deshabilitado, el tooltip se actualiza a los dos que quedan |
| 1.4 | Subir los tres | Badge "Completa"; el botón se habilita, sin tooltip |
| 1.5 | Click en "Iniciar pago" → "Confirmar pago" | Pago normal — sin diferencias con el flujo de antes de ADR-008 |
| 1.6 | Mirar "Cancelar transacción" en todo momento (con 0, 1 o 3 documentos) | Siempre habilitado — cancelar no depende de estos documentos |
2. Bloqueo — ficha de Transacciones (mismo componente, otra pantalla)
| # | Paso | Resultado esperado |
|---|---|---|
| 2.1 | Como Admin, abrir el detalle de una ACCEPTED sin documentos | Mismo bloque "Documentos para poder pagar" antes de los botones "Cambiar a PAID" / "Cancelar transacción" |
| 2.2 | Con documentos incompletos | "Cambiar a PAID" deshabilitado con el mismo texto "Faltan: ..." visible junto a los botones; "Cancelar transacción" sigue habilitado |
| 2.3 | Subir los tres, click en "Cambiar a PAID" | Pago normal |
3. Carrera / bypass directo a la API (el botón deshabilitado no alcanza como única defensa)
| # | Paso | Resultado esperado |
|---|---|---|
| 3.1 | Con una ACCEPTED sin documentos, pegarle directo a PATCH /transacciones/{id}/pay (Postman/curl con el Bearer del usuario) | 422 con {"code": "MISSING_REQUIRED_DOCUMENTS", "faltan": ["CARTA", "IDENTIFICACION_ANVERSO", "IDENTIFICACION_REVERSO"]} — la transacción sigue ACCEPTED |
| 3.2 | Repetir con solo uno o dos de los tres subidos | faltan solo lista los que realmente faltan |
4. PDV de los documentos pre-pago (bolsa compartida hasta el primer upload)
| # | Paso | Resultado esperado |
|---|---|---|
| 4.1 | Como Backoffice de GT-CAP-001, subir la Carta a una ACCEPTED sin PDV | Se sube sin error (país bolsa compartida) |
| 4.2 | Revisar la transacción en la base (select station_id from transactions where id=...) | station_id = el de GT-CAP-001, aunque la transacción siga ACCEPTED |
| 4.3 | Como Backoffice de otro PDV (ej. GT-QUE-002), intentar ver o subir un documento a esa misma transacción | 404 — ya quedó acotada al PDV que subió el primer documento |
| 4.4 | Como Admin (sin restricción de PDV), pagar esa misma transacción | Se paga normalmente — pay() no está acotado por PDV (bolsa compartida de escritura) |
| 4.5 | Revisar station_id después del pago | Sigue siendo el de GT-CAP-001 — pay() no lo pisó con el PDV de quien pagó (o ninguno, si pagó Admin) |
5. No se rompió nada de lo que ya existía
| # | Paso | Resultado esperado |
|---|---|---|
| 5.1 | Pagar una transacción ACCEPTED con los tres documentos ya subidos, en un país sin módulo Caja | Descuenta prefondeo como siempre |
| 5.2 | Repetir con módulo Caja activo | Descuenta caja + prefondeo como siempre |
| 5.3 | Con los tres documentos subidos pero saldo insuficiente (caja o prefondeo) | El error sigue siendo INSUFFICIENT_PREFUNDING (o el de caja) — el corte por documentos no interfiere una vez que están |
| 5.4 | Después de pagar, mirar la sección de documentación (los 9 tipos, DocumentacionPago.vue) | Los tres ya aparecen con tilde verde — son los mismos documentos, no hace falta volver a subirlos |
| 5.5 | Selfie, papeleta y los 4 de transferencia | Siguen sin aparecer en el bloque pre-pago (que solo muestra los 3) y siguen sin bloquear nada en el resto del flujo |
6. Qué NO es parte de este cambio (no reportar como bug)
- Que "Confirmar pago" pida datos de reporte (
datosPago()) o la papeleta antes de pagar — eso sigue sin bloquear, a propósito (R3 para todo lo que no sea Carta/identificación). - Que un usuario con más de un PDV sin PDV activo configurado no pueda ser el primero en subir un documento a una
ACCEPTED— es la misma ambigüedad de siempre (pregunta #14 del funcional original), no algo nuevo de ADR-008.
Cómo reportarme el feedback
Para cada punto que falle, con el número de la tabla alcanza (ej. "1.3 no actualizó el tooltip").