4. Inventario y compras

Cubre inventory (vista general + ajuste directo de cantidad), adjustments, purchases y contacts tipo supplier.

Historial de ejecución

Inventario general

CP INV-01: Ver inventario filtrado por tienda

• Resultado esperado: solo muestra los registros de la tienda elegida, con cantidad y valor (price * quantity) correctos.
• Resultado obtenido: Pendiente.

CP INV-02: Ajuste directo de cantidad (PUT /inventory/:id/adjust) con delta negativo mayor al stock actual

• Pasos: producto con 5 unidades → ajustar con delta: -20.
• Resultado esperado: el código limita el resultado a 0 (no permite inventario negativo) — confirmar que efectivamente queda en 0 y no en -15.
• Resultado obtenido: Pendiente.

CP INV-03: Alerta de stock mínimo

• Pasos: producto con min_stock=10, bajar cantidad a 5 vía ajuste.
• Resultado esperado: debe marcarse/resaltarse como “stock bajo” en el listado (verificar visualmente).
• Resultado obtenido: Pendiente.

CP INV-04: Editar inventario cambiando el store_id a una tienda distinta a la original

• Resultado esperado a verificar: Update en el repositorio reescribe ProductID/StoreID desde el registro existente, ignorando lo que venga en el body — confirmar que el frontend no permite (o no tiene sentido) cambiar la tienda de un registro de inventario ya creado desde el formulario de edición.
• Resultado obtenido: Pendiente.

Ajustes de inventario

CP AJ-01: Ajuste tipo addition con varios productos en el mismo ajuste

• Resultado esperado: suma correctamente la cantidad de cada ítem al inventario de la tienda indicada.
• Resultado obtenido: Pendiente.

CP AJ-02: Ajuste tipo subtraction que deja el inventario en 0

• Resultado esperado: igual que INV-02, no debe quedar negativo.
• Resultado obtenido: Pendiente.

CP AJ-03: Ajuste con cantidad negativa dentro de un ítem (ej. quantity: -5 en un ajuste de tipo addition)

• Objetivo: el signo real del movimiento depende del campo type del ajuste, no del signo de quantity en cada ítem — probar si alguien pone un número negativo “por costumbre” y así invierte el efecto esperado.
• Resultado esperado a verificar: ¿el backend usa abs(quantity) o toma el valor literal? Si toma el literal, un addition con quantity: -5 en realidad restaría — confirmar y documentar como hallazgo si es así.
• Resultado obtenido: Pendiente.

CP AJ-04: Tipo de ajuste inválido (ej. "ajuste" en vez de addition/subtraction)

• Resultado esperado: error 400 claro.
• Resultado obtenido: Pendiente.

CP AJ-05: Ajuste sin productos (items: [])

• Resultado esperado a verificar: ¿se permite crear un ajuste vacío sin ítems? Si sí, es un “ajuste fantasma” sin efecto real — confirmar si el frontend lo previene.
• Resultado obtenido: Pendiente.

Compras

CP COMP-01: Compra con proveedor existente (supplier_id)

• Resultado esperado: al guardar, debe aumentar el inventario de los productos comprados en la tienda de la compra (vía evento PurchaseCreatedEvent).
• Resultado obtenido: Pendiente.

CP COMP-02: Compra con proveedor “libre” (sin supplier_id, solo supplier_name de texto)

• Resultado esperado: debe permitir registrar una compra sin tener el proveedor dado de alta como contacto.
• Resultado obtenido: Pendiente.

CP COMP-03: Compra con status: "outstanding" y paid_amount menor al total

• Resultado esperado: debe quedar reflejado como saldo pendiente en el reporte de compras.
• Resultado obtenido: Pendiente.

CP COMP-04: Compra con total que no coincide matemáticamente con subtotal + tax_amount

• Objetivo: estos totales se calculan en el frontend y se envían ya calculados — el backend no los recalcula.
• Resultado esperado a verificar: confirmar que efectivamente el backend guarda los números tal cual se los manden, sin validar la coherencia matemática. Si es así, un error de cálculo en el frontend (o una manipulación directa de la petición) generaría una compra con cifras inconsistentes sin ningún aviso.
• Resultado obtenido: Pendiente.

CP COMP-05: Compra sin ítems

• Resultado esperado a verificar: similar a AJ-05 — ¿se permite una compra con items: [] pero con un total distinto de cero?
• Resultado obtenido: Pendiente.

CP COMP-06: Eliminar una compra ya recibida (que ya incrementó inventario)

• Resultado esperado a verificar: ¿al borrar la compra se revierte el inventario que había aumentado, o queda “flotando” (inventario aumentado pero sin el registro de compra que lo justifica)? Confirmar comportamiento real — probablemente no se revierte, lo cual es un hallazgo a documentar (no hay rollback de inventario al borrar compras/ajustes/devoluciones).
• Resultado obtenido: Pendiente.

Proveedores (contactos tipo supplier)

CP PROV-01: Crear proveedor con solo nombre

• Resultado esperado: se crea sin problema (email/phone/extra opcionales).
• Resultado obtenido: Pendiente.

CP PROV-02: Crear contacto con type distinto a "client"/"supplier" (ej. "otro")

• Objetivo: el DTO solo exige binding:"required" en type, sin oneof — probar si acepta cualquier string.
• Resultado esperado a verificar: si acepta cualquier valor, confirmar si ese contacto aparece correctamente clasificado en las pantallas de “Clientes” y “Proveedores” (que probablemente filtran por type="client" / type="supplier" exactos) — un typo en el tipo dejaría el contacto invisible en ambas listas.
• Resultado obtenido: Pendiente.

Notas de usabilidad y sugerencias

Se completa durante la ejecución.