Appearance
Validacion de Unicidad de Comprobantes de Compra
Modulo: Compras Tipo: Process Estado: Implementado Fecha: 2026-02-27
Descripcion
Problema que resuelve
El sistema permitia registrar comprobantes de compra duplicados sin ningun control. Un mismo comprobante, identificado por la combinacion de numero de comprobante, tipo de comprobante y proveedor, podia cargarse multiples veces. Esto generaba:
- Inconsistencia en datos contables: Registros duplicados distorsionan los totales de compras y los saldos contables
- Duplicacion de deuda con proveedores: La cuenta corriente del proveedor refleja una deuda mayor a la real
- Dificultad de auditoria: Identificar y corregir duplicados manualmente es costoso y propenso a errores
Solucion
El sistema ahora valida la unicidad de cada comprobante de compra antes de registrarlo. La validacion se basa en la combinacion de tres datos que identifican univocamente un comprobante:
- Numero de comprobante: El numero del documento (por ejemplo, 00001-00000001)
- Tipo de comprobante: El tipo de documento (factura, nota de credito, nota de debito, etc.)
- Proveedor: El proveedor emisor del comprobante
Si ya existe un comprobante con esa misma combinacion, el sistema rechaza el registro y muestra un mensaje de error descriptivo.
Valor para el negocio
- Integridad de datos: Eliminacion de registros duplicados en compras
- Precision financiera: La deuda con proveedores refleja valores reales, no inflados por duplicados
- Confiabilidad contable: Los totales de compras son exactos para reportes y libro IVA
- Ahorro operativo: Se evita la necesidad de detectar y corregir duplicados manualmente
Contexto
El modulo de Ventas ya contaba con una validacion similar para sus propios comprobantes. Esta funcionalidad extiende la misma proteccion al modulo de Compras, manteniendo consistencia de criterio en todo el sistema.
Flujo del Proceso
Registro de un comprobante nuevo
- Usuario ingresa los datos del comprobante de compra (proveedor, tipo, numero, fecha, importes, etc.)
- Usuario confirma el registro
- Sistema verifica si ya existe un comprobante con la misma combinacion de numero, tipo y proveedor
- Si la combinacion es unica: el sistema registra el comprobante normalmente
- Si la combinacion ya existe: el sistema rechaza la operacion y muestra un mensaje indicando que el comprobante ya fue registrado
Edicion de un comprobante existente
- Usuario selecciona un comprobante existente para editar
- Usuario modifica los datos que necesita cambiar
- Usuario confirma la edicion
- Sistema verifica unicidad excluyendo el propio comprobante que se esta editando (para no generar un falso positivo)
- Si los nuevos datos no generan duplicado con otro comprobante: la edicion se guarda correctamente
- Si los nuevos datos coinciden con la combinacion de otro comprobante diferente: el sistema rechaza la edicion y muestra un mensaje de error
Reglas de Negocio
RN-001: Unicidad de comprobante de compra
Descripcion: Un comprobante de compra queda identificado de forma unica por la combinacion de tres datos: numero de comprobante, tipo de comprobante y proveedor. No pueden existir dos comprobantes con la misma combinacion dentro del mismo tenant.
Condicion: Al registrar un nuevo comprobante o al editar uno existente.
Accion:
- El sistema verifica que no exista otro comprobante con la misma combinacion de numero, tipo y proveedor
- Si la combinacion ya existe: el sistema rechaza la operacion con un mensaje de error descriptivo
- Si la combinacion es unica: el sistema permite continuar con el registro o la edicion
Ejemplo:
- Si ya existe una Factura A numero 00001-00000001 del proveedor "Distribuidora Norte", intentar cargar nuevamente una Factura A numero 00001-00000001 del mismo proveedor sera rechazado por el sistema
RN-002: Exclusion del registro en edicion
Descripcion: Al editar un comprobante existente, el sistema no debe comparar el comprobante consigo mismo. Esto evita falsos positivos donde el sistema rechazaria la edicion por detectar "un duplicado" que en realidad es el mismo registro que se esta modificando.
Condicion: Al editar (actualizar) un comprobante de compra existente.
Accion:
- El sistema excluye el propio registro en edicion de la verificacion de duplicados
- Solo se compara contra los demas comprobantes del sistema
Ejemplo:
- Un comprobante con numero 00001-00000001, tipo Factura A, proveedor "Distribuidora Norte" se esta editando para cambiar el importe. Como el numero, tipo y proveedor no cambian, el sistema permite la edicion sin problema
RN-003: Independencia de las tres dimensiones de unicidad
Descripcion: Los tres campos de identificacion actuan conjuntamente. Diferir en cualquiera de los tres es suficiente para que dos comprobantes sean considerados distintos.
Condicion: Al evaluar si un comprobante es duplicado.
Accion:
- Dos comprobantes con el mismo proveedor y tipo pero diferente numero: ambos son validos
- Dos comprobantes con el mismo numero y tipo pero diferente proveedor: ambos son validos
- Dos comprobantes con el mismo numero y proveedor pero diferente tipo: ambos son validos
Ejemplo:
- Factura A 00001-00000001 de "Distribuidora Norte" y Factura A 00001-00000002 de "Distribuidora Norte" pueden coexistir (diferente numero)
- Factura A 00001-00000001 de "Distribuidora Norte" y Factura A 00001-00000001 de "Proveedora Sur" pueden coexistir (diferente proveedor)
- Factura A 00001-00000001 de "Distribuidora Norte" y Nota de Credito A 00001-00000001 de "Distribuidora Norte" pueden coexistir (diferente tipo)
RN-004: Aislamiento por sucursal (multi-tenant)
Descripcion: La validacion de unicidad opera dentro de la sucursal activa. Un comprobante con la misma combinacion en otra sucursal no se considera duplicado.
Condicion: Al verificar duplicados en un entorno multi-tenant.
Accion:
- Cada sucursal valida unicidad de forma independiente
- Comprobantes identicos en sucursales distintas pueden coexistir sin conflicto
Ejemplo:
- Factura A 00001-00000001 de "Distribuidora Norte" en Sucursal 001 y la misma combinacion en Sucursal 002 son registros validos e independientes
RN-005: Sin impacto en otros modulos
Descripcion: Esta validacion aplica exclusivamente al modulo de Compras. El modulo de Ventas mantiene su propia validacion de unicidad independiente, y ningun otro modulo se ve afectado.
Condicion: Cualquier operacion en modulos distintos a Compras.
Accion:
- Las operaciones de Ventas, Tesoreria, Contabilidad y otros modulos continuan funcionando exactamente igual
- No se ejecuta ninguna logica adicional de validacion en modulos ajenos a Compras
RN-006: Integridad al rechazar duplicados
Descripcion: Cuando el sistema detecta un duplicado, no se registra ningun dato parcial. La operacion se rechaza completamente, sin dejar registros incompletos en comprobantes, items, conceptos ni movimientos de cuenta corriente.
Condicion: Al detectar un intento de insercion duplicada.
Accion:
- El sistema detiene la operacion antes de guardar cualquier dato
- No se generan registros parciales en ninguna tabla o entidad relacionada
- La operacion se revierte limpiamente
Actores Involucrados
Usuario de Compras
- Registra comprobantes de compra
- Edita comprobantes existentes
- Recibe mensajes de error cuando intenta registrar un duplicado
Sistema
- Verifica automaticamente la unicidad de cada comprobante antes de registrarlo
- Muestra mensajes de error descriptivos cuando detecta un duplicado
- Garantiza que la operacion se revierte limpiamente en caso de rechazo
Casos de Uso
CU-001: Registro exitoso de comprobante unico
Actor: Usuario de Compras
Precondiciones:
- Usuario autenticado con permiso de registro de compras
- No existe un comprobante con la combinacion de numero, tipo y proveedor que se va a registrar
Flujo principal:
- Usuario accede al formulario de registro de comprobante de compra
- Usuario selecciona proveedor, tipo de comprobante e ingresa numero
- Usuario completa los demas datos (fecha, importes, items, etc.)
- Usuario confirma el registro
- Sistema verifica que no existe otro comprobante con esa combinacion
- Sistema registra el comprobante exitosamente
- Sistema muestra confirmacion con los datos del comprobante registrado
Postcondiciones:
- Comprobante de compra registrado en el sistema
- Movimientos de cuenta corriente generados (si aplica)
- El comprobante queda disponible para consultas y reportes
CU-002: Rechazo de comprobante duplicado
Actor: Usuario de Compras
Precondiciones:
- Usuario autenticado con permiso de registro de compras
- Ya existe un comprobante con la misma combinacion de numero, tipo y proveedor
Flujo principal:
- Usuario accede al formulario de registro de comprobante de compra
- Usuario ingresa los mismos datos de numero, tipo y proveedor de un comprobante existente
- Usuario completa los demas datos y confirma el registro
- Sistema verifica unicidad y detecta que la combinacion ya existe
- Sistema rechaza la operacion
- Sistema muestra mensaje de error indicando que el comprobante ya fue registrado, identificando el numero, tipo y proveedor del duplicado
- No se registra ningun dato
Postcondiciones:
- No se creo ningun comprobante nuevo
- No se generaron movimientos de cuenta corriente
- El usuario puede corregir los datos e intentar nuevamente
Flujo alternativo - Correccion:
- En paso 7, usuario corrige el numero de comprobante, tipo o proveedor
- Usuario reintenta el registro con datos correctos
- Sistema verifica y permite el registro si la nueva combinacion es unica
CU-003: Edicion de comprobante existente sin conflicto
Actor: Usuario de Compras
Precondiciones:
- Existe un comprobante registrado que el usuario necesita modificar
- Los datos de identificacion (numero, tipo, proveedor) no se cambian, o se cambian a valores que no coinciden con otro comprobante existente
Flujo principal:
- Usuario selecciona el comprobante a editar
- Usuario modifica los datos necesarios (por ejemplo, importes, fecha, items)
- Usuario confirma la edicion
- Sistema verifica unicidad excluyendo el propio comprobante en edicion
- Sistema actualiza el comprobante exitosamente
- Sistema muestra confirmacion
Postcondiciones:
- Comprobante actualizado con los nuevos datos
- Movimientos de cuenta corriente actualizados (si aplica)
CU-004: Edicion rechazada por conflicto con otro comprobante
Actor: Usuario de Compras
Precondiciones:
- Existen al menos dos comprobantes registrados
- El usuario intenta cambiar el numero, tipo o proveedor de un comprobante a valores que coinciden exactamente con los de otro comprobante
Flujo principal:
- Usuario selecciona un comprobante para editar
- Usuario modifica el numero de comprobante (u otro dato de la terna) a un valor que ya pertenece a otro comprobante registrado
- Usuario confirma la edicion
- Sistema detecta que la nueva combinacion ya existe en otro comprobante
- Sistema rechaza la edicion
- Sistema muestra mensaje de error indicando el conflicto
Postcondiciones:
- El comprobante original permanece sin cambios
- No se modifican datos parciales
Dependencias
Modulos internos
- Cuenta Corriente de Proveedores: Los comprobantes de compra generan movimientos en la cuenta corriente. La validacion de unicidad previene movimientos duplicados
Modulos no afectados
- Ventas: Mantiene su propia validacion de unicidad independiente; no se modifica
- Tesoreria, Contabilidad, Stock, CRM: Sin cambios
Consideraciones
Mensajes al usuario
- Cuando se detecta un duplicado, el sistema muestra un mensaje claro que identifica el numero de comprobante, el tipo y el proveedor que generan el conflicto
- El mensaje permite al usuario entender exactamente por que se rechazo la operacion y corregir los datos
Datos preexistentes
- La validacion aplica unicamente a nuevas operaciones de registro y edicion
- Los comprobantes duplicados que pudieran existir previamente en la base de datos no se modifican ni eliminan
- La limpieza de duplicados preexistentes queda fuera de alcance (fase futura)
Alcance de la validacion
- La validacion opera en la capa de aplicacion (no a nivel de base de datos)
- Una restriccion de unicidad a nivel de base de datos queda planificada como una fase futura e independiente
Criterios de Aceptacion
- [ ] Al registrar un comprobante con una combinacion unica de numero, tipo y proveedor, el sistema lo guarda exitosamente
- [ ] Al registrar un comprobante con la misma combinacion de numero, tipo y proveedor que un comprobante existente, el sistema rechaza la operacion con un mensaje de error descriptivo
- [ ] Al editar un comprobante sin cambiar su numero, tipo ni proveedor, el sistema permite la edicion sin rechazarla por duplicado
- [ ] Al editar un comprobante cambiando su numero, tipo o proveedor a valores que coinciden con otro comprobante existente, el sistema rechaza la edicion
- [ ] Dos comprobantes con el mismo proveedor y tipo pero diferente numero pueden coexistir
- [ ] Dos comprobantes con el mismo numero y tipo pero diferente proveedor pueden coexistir
- [ ] Dos comprobantes con el mismo numero y proveedor pero diferente tipo pueden coexistir
- [ ] La validacion opera dentro de la sucursal activa; comprobantes identicos en sucursales distintas no generan conflicto
- [ ] El modulo de Ventas no se ve afectado por esta validacion
- [ ] Al rechazar un duplicado, no se registran datos parciales (comprobante, items, cuenta corriente)
Notas Adicionales
- Esta funcionalidad sigue el mismo criterio de unicidad que ya existia en el modulo de Ventas, aplicandolo ahora al modulo de Compras
- La validacion a nivel de base de datos (fase 2) queda planificada como mejora futura independiente de esta implementacion