Reporte de QA · CUST-001

CUST-001 — RUT chileno (identificación tributaria) en Cuentas

Cliente: Minera Atacama SpA (Chile)
Tipo: Personalización de cliente
Módulo: Cuentas (backend Rust/Axum + frontend Vue)
Prioridad: Alta. Bloquea la integración con su ERP de facturación electrónica (SII)
Estimación: 3 puntos
Ejecución: 13/10/2026 18:02

APROBADOLa personalización cumple todos los criterios de aceptación.

6/6Escenarios aprobados

7/7Criterios de aceptación

30/30Pasos Gherkin

1:12Duración del video

Video de QA con subtítulos

Los subtítulos del video muestran el escenario en curso (arriba) y el paso Gherkin que se ejecuta (abajo). Haz clic en un capítulo o en la marca de tiempo de un paso para saltar a ese momento.

Criterios de aceptación

ID	Criterio	Escenarios	Resultado
AC1	Al crear o editar una cuenta se puede ingresar un RUT, y el campo es opcional.	E1 E5 E6	APROBADO
AC2	El RUT se guarda y se muestra normalizado como `XX.XXX.XXX-D`, sin importar si se ingresó con o sin puntos o guion, o con `k` minúscula.	E1 E5	APROBADO
AC3	Un RUT con dígito verificador inválido se rechaza con un mensaje claro en el formulario, y también en la API (`400`).	E2	APROBADO
AC4	No pueden existir dos cuentas activas con el mismo RUT. El segundo intento se rechaza (`409`) y el formulario indica que el RUT ya existe.	E3	APROBADO
AC5	El buscador del listado de cuentas encuentra una cuenta por su RUT, con o sin puntos y guion.	E4	APROBADO
AC6	El RUT aparece en una columna del listado y en la ficha de detalle de la cuenta.	E1 E5	APROBADO
AC7	El RUT no es obligatorio: una cuenta se puede crear sin RUT y se muestra «-» en el RUT (no hay regresiones en el alta de cuentas).	E6	APROBADO

Un criterio se aprueba cuando todos los escenarios asociados en la tabla de trazabilidad se aprueban.

Escenarios Gherkin ejecutados

Característica

RUT chileno en Cuentas

Como ejecutivo comercial del cliente
Quiero registrar y buscar el RUT de cada cuenta
Para facturar sin errores y evitar cuentas duplicadas

Antecedentes

APROBADO5.1 s

✓
Dado que inicié sesión en el CRM como carlos.mendez@opencrm.com
✓
Y existe la cuenta Minera Atacama SpA con RUT 96.790.240-3

Escenario E1 · AC1 AC2 AC6

Crear una cuenta con un RUT válido sin formato

APROBADO11.4 s

✓
Cuando abro el formulario Nueva cuenta
✓
Y completo el nombre Distribuidora Andes SpA
✓
Y completo el RUT 771234569
✓
Y guardo la cuenta
✓
Entonces la cuenta Distribuidora Andes SpA aparece en el listado con RUT 77.123.456-9
✓
Y la ficha de detalle muestra el RUT 77.123.456-9

Escenario E2 · AC3

Rechazar un RUT con dígito verificador inválido

APROBADO13.9 s

✓
Cuando abro el formulario Nueva cuenta
✓
Y completo el nombre Comercial Inválida Ltda
✓
Y completo el RUT 77.123.456-0
✓
Y guardo la cuenta
✓
Entonces veo el error El RUT no es válido bajo el campo RUT
✓
Y la cuenta Comercial Inválida Ltda no se crea

Escenario E3 · AC4

Rechazar un RUT duplicado

APROBADO14.1 s

✓
Cuando abro el formulario Nueva cuenta
✓
Y completo el nombre Minera Atacama Duplicada
✓
Y completo el RUT 96.790.240-3
✓
Y guardo la cuenta
✓
Entonces veo el error Ya existe una cuenta con este RUT bajo el campo RUT
✓
Y la cuenta Minera Atacama Duplicada no se crea

Escenario E4 · AC5

Buscar una cuenta por RUT sin puntos ni guion

APROBADO3.9 s

✓
Cuando escribo 967902403 en el buscador de cuentas
✓
Entonces el listado muestra solo la cuenta Minera Atacama SpA

Escenario E5 · AC1 AC2 AC6

Agregar un RUT con "k" minúscula a una cuenta existente

APROBADO8.5 s

✓
Dado que la cuenta Transportes del Sur Ltda no tiene RUT
✓
Cuando edito la cuenta Transportes del Sur Ltda
✓
Y completo el RUT 76354771-k
✓
Y guardo los cambios
✓
Entonces la ficha de detalle muestra el RUT 76.354.771-K

Escenario E6 · AC1 AC7

El RUT es opcional

APROBADO6.5 s

✓
Cuando creo la cuenta Consultora Sin RUT sin completar el RUT
✓
Entonces la cuenta Consultora Sin RUT se crea correctamente
✓
Y la ficha de detalle muestra - en el RUT

Resumen de la tarea

Problema

El cliente factura electrónicamente ante el SII de Chile, y cada cliente se identifica allí por su RUT (Rol Único Tributario). Hoy el CRM no tiene un campo para el RUT. El equipo comercial lo anota en la descripción de la cuenta, en formatos distintos (96790240-3, 96.790.240-3, 967902403). Eso trae tres problemas:

Datos inválidos: se registran RUT con dígito verificador incorrecto, y las facturas se rechazan en el ERP.
Duplicados: la misma empresa se crea dos veces con nombres distintos (por ejemplo «Minera Atacama» y «Minera Atacama SpA»), y nada lo impide.
Búsqueda: cuando el área de cobranza recibe un RUT de un pago, no puede encontrar la cuenta en el CRM.

Definición de terminado

La migración se aplica sin errores sobre una base existente.completado
Las pruebas unitarias de utils::rut pasan con cargo test.completado
El backend compila sin warnings nuevos (cargo build) y el frontend pasa el chequeo de tipos (vue-tsc).completado
Los textos i18n están completos en los 4 idiomas.completado
Se ejecutó el QA E2E de todos los escenarios Gherkin, con video subtitulado y capturas.completado
El reporte de QA en HTML muestra cada AC y cada escenario en estado APROBADO.completado
Revisión de código por un par (pendiente). El QA no encontró regresiones en el módulo de Cuentas.pendiente

Enfoque técnico

Base de datos: una nueva migración agrega la columna accounts.tax_id VARCHAR(20) (opcional) y un índice único parcial sobre las cuentas activas con RUT (deleted_at IS NULL AND tax_id IS NOT NULL).
Backend:
- Un módulo utils::rut con la validación del dígito verificador (módulo 11) y la normalización al formato canónico XX.XXX.XXX-D, con pruebas unitarias.
- AccountService valida y normaliza el RUT al crear y al editar. Un RUT inválido devuelve 400 VALIDATION_ERROR. Un RUT ya usado por otra cuenta activa devuelve 409 CONFLICT. Si se envía un string vacío en la edición, el RUT se elimina.
- La búsqueda del listado (search) también busca por RUT, ignorando puntos y guion.
- tax_id se expone en AccountDto.
Frontend:
- Un campo «RUT» en el formulario de cuenta, con validación en el cliente (misma regla del módulo 11) y formato automático al salir del campo.
- El conflicto 409 del servidor se muestra como error del campo RUT.
- Una columna «RUT» en el listado y el RUT en la ficha de detalle.
- Textos i18n en en, es-419, pt e it.

Fuera de alcance: otros identificadores fiscales de la región (CNPJ, NIT, CUIT, RUC), la consulta en línea al SII y la migración de RUT que hoy están en las descripciones.

Historial de ejecuciones

Ejecución 113/10/2026 17:47 FALLIDO5/6 escenarios

✗ E5 · Agregar un RUT con "k" minúscula a una cuenta existente

Bug preexistente encontrado por el QA en E5. Al guardar la edición de «Transportes del Sur Ltda», la API respondió 500:

PUT /api/accounts/{id} → 500
COALESCE types text and industry cannot be matched (42804)

Causa: en AccountRepository::update, la consulta usaba industry = COALESCE($3, industry), que mezcla un text con el enum industry de PostgreSQL. Por eso fallaba cualquier edición de cuenta, no solo la del RUT.

Corrección: se cambió a COALESCE($3::industry, industry) en backend/src/services/account_repository.rs. Después se reinició el backend y se volvió a ejecutar la suite completa.

Ejecución 2 (actual)13/10/2026 18:02 APROBADO6/6 escenarios

Evidencia técnica

Verificación	Comando	Resultado
Pruebas unitarias RUT	`cargo test --lib rut`	2 de 2 aprobadas (`normalizes_valid_ruts`, `rejects_invalid_ruts`)
Suite unitaria del backend	`cargo test --lib`	12 de 12 aprobadas
Compilación del backend	`cargo build`	OK. Sin warnings nuevos en los archivos modificados (los 11 existentes son anteriores a esta tarea)
Tipos del frontend	`vue-tsc --noEmit -p tsconfig.app.json`	0 errores
Migración	`20240101000021_add_tax_id_to_accounts.sql`	Aplicada (`success = true`) sobre la base existente
API: RUT válido	`POST /api/accounts` con `99500410-0`	`201`, se guardó como `99.500.410-0`
API: RUT duplicado	`POST /api/accounts` con `99.500.410-0`	`409 CONFLICT`
API: RUT inválido	`POST /api/accounts` con `99.500.410-1`	`400 VALIDATION_ERROR`
API: búsqueda	`GET /api/accounts?search=995004`	1 resultado

Cambio adicional fuera del alcance original: migrations/seed_south_american_sme.sql se movió a migrations/seeds/. Su nombre no tiene prefijo de versión, así que sqlx::migrate! impedía compilar el backend.

Observación (no bloqueante, sin corregir): el formulario de cuentas envía industrias como Real Estate. El backend las convierte a minúsculas (real estate), pero el enum espera real_estate. Se recomienda crear una tarea aparte.

Especificación Gherkin

# language: es
Característica: RUT chileno en Cuentas
  Como ejecutivo comercial del cliente
  Quiero registrar y buscar el RUT de cada cuenta
  Para facturar sin errores y evitar cuentas duplicadas

  Antecedentes:
    Dado que inicié sesión en el CRM como "carlos.mendez@opencrm.com"
    Y existe la cuenta "Minera Atacama SpA" con RUT "96.790.240-3"

  Escenario: E1 - Crear una cuenta con un RUT válido sin formato
    Cuando abro el formulario "Nueva cuenta"
    Y completo el nombre "Distribuidora Andes SpA"
    Y completo el RUT "771234569"
    Y guardo la cuenta
    Entonces la cuenta "Distribuidora Andes SpA" aparece en el listado con RUT "77.123.456-9"
    Y la ficha de detalle muestra el RUT "77.123.456-9"

  Escenario: E2 - Rechazar un RUT con dígito verificador inválido
    Cuando abro el formulario "Nueva cuenta"
    Y completo el nombre "Comercial Inválida Ltda"
    Y completo el RUT "77.123.456-0"
    Y guardo la cuenta
    Entonces veo el error "El RUT no es válido" bajo el campo RUT
    Y la cuenta "Comercial Inválida Ltda" no se crea

  Escenario: E3 - Rechazar un RUT duplicado
    Cuando abro el formulario "Nueva cuenta"
    Y completo el nombre "Minera Atacama Duplicada"
    Y completo el RUT "96.790.240-3"
    Y guardo la cuenta
    Entonces veo el error "Ya existe una cuenta con este RUT" bajo el campo RUT
    Y la cuenta "Minera Atacama Duplicada" no se crea

  Escenario: E4 - Buscar una cuenta por RUT sin puntos ni guion
    Cuando escribo "967902403" en el buscador de cuentas
    Entonces el listado muestra solo la cuenta "Minera Atacama SpA"

  Escenario: E5 - Agregar un RUT con "k" minúscula a una cuenta existente
    Dado que la cuenta "Transportes del Sur Ltda" no tiene RUT
    Cuando edito la cuenta "Transportes del Sur Ltda"
    Y completo el RUT "76354771-k"
    Y guardo los cambios
    Entonces la ficha de detalle muestra el RUT "76.354.771-K"

  Escenario: E6 - El RUT es opcional
    Cuando creo la cuenta "Consultora Sin RUT" sin completar el RUT
    Entonces la cuenta "Consultora Sin RUT" se crea correctamente
    Y la ficha de detalle muestra "-" en el RUT