Appearance
Relacion Movimiento de Caja - Bridge de Ventas (UUID)
Modulo: Tesoreria - Integracion con Ventas Tipo: Resource Estado: Planificado Fecha: 2025-12-29
Descripcion
Problema de Negocio Actual
Actualmente, los movimientos de caja (tesoreria) que se originan por comprobantes de venta se relacionan con dichos comprobantes mediante una referencia compuesta que utiliza dos campos: el identificador del comprobante de venta (id_venta) y el identificador del tipo de comprobante (id_tipo_comprobante). Esta arquitectura presenta las siguientes limitaciones:
Complejidad en las consultas: Para localizar el comprobante de venta asociado a un movimiento de caja, se requiere realizar busquedas utilizando dos campos de forma simultanea, lo que complica las consultas y la logica de negocio.
Inconsistencia con el patron bridge: El sistema ha evolucionado hacia el uso de identificadores globales unicos (UUID) para comprobantes de venta a traves del bridge de ventas (documentado en bridge-ventas-resource.md). Los movimientos de caja aun utilizan el metodo antiguo de referencia compuesta, generando inconsistencia en la arquitectura.
Desalineacion con cuenta corriente: El modulo de cuenta corriente ya tiene planificada la adopcion del UUID del bridge para sus movimientos (documentado en mov-ctacte-bridge-uuid-resource.md). Mantener el metodo antiguo en tesoreria crearia una asimetria entre modulos que referencian los mismos comprobantes.
Dificultad en conciliaciones y reportes: Los reportes de tesoreria (planilla de caja, libro de caja) y las conciliaciones entre modulos deben manejar la logica de referencia compuesta, aumentando la complejidad y el riesgo de errores.
Impacto en procesos de cierre: Los cierres de caja y arqueos que necesitan validar movimientos contra comprobantes de venta deben trabajar con dos campos de referencia, complicando los procesos de verificacion.
Necesidad del Negocio
El sistema requiere que los movimientos de caja que se originan por comprobantes de venta utilicen el UUID del bridge de ventas como mecanismo de vinculacion. Esta evolucion proporcionara:
Referencia unica e inequivoca: Cada movimiento de caja estara vinculado a un comprobante de venta mediante un identificador global unico, eliminando la necesidad de referencias compuestas.
Consistencia arquitectonica: Todos los modulos que referencian comprobantes de venta (ventas, cuenta corriente, tesoreria) utilizaran el mismo mecanismo (UUID del bridge), creando un patron uniforme en todo el sistema.
Simplificacion de consultas: Las consultas para localizar comprobantes asociados a movimientos de caja se simplificaran al requerir un solo campo de referencia.
Alineacion con cuenta corriente: La tesoreria y la cuenta corriente utilizaran el mismo patron de referencia, facilitando consultas cruzadas y conciliaciones.
Preparacion para el futuro: La adopcion del patron bridge prepara al sistema para futuras integraciones y evoluciones, manteniendo una arquitectura coherente.
Valor de Negocio
La implementacion de esta funcionalidad aportara los siguientes beneficios:
Trazabilidad mejorada: Cada movimiento de caja podra rastrearse directamente al comprobante de venta que lo origino mediante un identificador unico y universal.
Integridad de datos garantizada: La relacion mediante UUID permite validaciones de integridad referencial mas robustas y confiables.
Eficiencia operativa: Los usuarios y procesos del sistema podran consultar y relacionar informacion de forma mas rapida y directa.
Reduccion de errores: La eliminacion de referencias compuestas reduce la posibilidad de errores por asociaciones incorrectas entre movimientos y comprobantes.
Reportes simplificados: Los reportes de tesoreria (planilla de caja, libro de caja) podran obtener informacion de comprobantes de forma directa y eficiente.
Cierres y arqueos mas confiables: Los procesos de cierre de caja y arqueo tendran una relacion directa con los comprobantes origen, facilitando la verificacion.
Consolidacion confiable: Los reportes consolidados a nivel empresa podran relacionar movimientos de caja con comprobantes de venta de cualquier sucursal sin ambiguedades.
Contexto en el Proceso de Negocio
Esta funcionalidad se integra en los siguientes flujos de negocio:
Flujo de registro de comprobantes de venta al contado:
- El usuario registra un comprobante de venta con condicion de pago "Contado" o "Tarjeta"
- El sistema genera automaticamente el identificador global unico (UUID) en el bridge de ventas
- El sistema genera el movimiento de caja correspondiente (entrada de efectivo)
- [Esta funcionalidad] El sistema registra el UUID del bridge de ventas en el movimiento de caja
- La relacion queda disponible para consultas, reportes y procesos de cierre
Flujo de registro de recibos de cobranza:
- El usuario registra un recibo de cobranza por facturas de cuenta corriente
- El sistema genera el identificador global unico (UUID) en el bridge de ventas para el recibo
- El sistema genera el movimiento de caja por el cobro (entrada de efectivo)
- [Esta funcionalidad] El sistema registra el UUID del bridge del recibo en el movimiento de caja
- La relacion permite rastrear el ingreso de caja hasta el recibo especifico
Flujo de migracion de datos existentes:
- El proceso de migracion identifica movimientos de caja que utilizan la referencia compuesta
- Para cada movimiento, localiza el comprobante de venta asociado mediante id_venta + id_tipo_comprobante
- El sistema obtiene el UUID del bridge de ventas correspondiente al comprobante
- El sistema actualiza el movimiento de caja con el UUID del bridge
- El sistema valida la integridad de los datos migrados
Flujo de cierre de caja:
- El usuario inicia el proceso de cierre de caja
- El sistema obtiene todos los movimientos de la caja en el periodo
- [Esta funcionalidad] Para movimientos de venta, el sistema utiliza el UUID del bridge para validar y detallar comprobantes
- El sistema genera el resumen de cierre con trazabilidad completa
- El cierre queda documentado con referencias directas a comprobantes
Frontend
NO APLICA
Esta funcionalidad corresponde a un cambio relacional interno en la base de datos que no afecta la interfaz de usuario del frontend de la aplicacion web/movil. La relacion entre movimientos de caja y comprobantes de venta mediante UUID del bridge es transparente para el usuario final.
Modulo de Reportes PDF
El componente afectado es el modulo de generacion de reportes en formato PDF. Especificamente, los siguientes reportes del modulo de tesoreria:
Reportes Afectados
Planilla de Caja:
- Muestra el detalle de movimientos de caja de una jornada o periodo
- Impacto: Actualmente usa id_venta + id_tipo_comprobante para obtener informacion de comprobantes de venta
- Cambio requerido: Utilizar UUID del bridge para consultar comprobantes de venta asociados
- Funcionalidad afectada: Columnas que muestran numero de comprobante, tipo y cliente del comprobante origen
Libro de Bancos:
- Muestra el registro historico de movimientos de caja
- Impacto: Trabaja con movimientos de caja y sus referencias a comprobantes de venta
- Cambio requerido: Actualizar consultas para usar UUID del bridge
- Funcionalidad afectada: Detalle de comprobantes origen en cada movimiento
Nota importante: Estos cambios en los reportes PDF son internos a la logica de consulta de datos. La presentacion visual y el contenido del reporte para el usuario final permanecen sin cambios. El UUID del bridge se utiliza para consultas mas eficientes y consistentes, pero no se expone al usuario en el documento PDF. Las modificaciones seran transparentes para los usuarios finales.
Backend
Entidades de Negocio
Esta funcionalidad involucra las siguientes entidades de negocio:
Movimiento de Caja
Representa cada registro de entrada o salida de efectivo en la caja de tesoreria. Los movimientos originados por comprobantes de venta (facturas al contado, recibos de cobranza, notas de credito) deben estar vinculados al comprobante que los genero.
Caracteristicas de negocio relevantes:
- Cada movimiento tiene un tipo (entrada o salida de efectivo)
- Los movimientos pertenecen a una caja especifica en un periodo determinado
- Los movimientos originados por ventas deben referenciar al comprobante origen
- El movimiento afecta el saldo de la caja
- Los movimientos son inmutables una vez que la caja es cerrada
- Los movimientos impactan directamente en arqueos y cierres de caja
Identificador Global de Comprobante de Venta (Bridge de Ventas)
Representa el mapeo entre el identificador local de un comprobante de venta y su identificador unico a nivel empresa (UUID). Este bridge permite referenciar cualquier comprobante de venta de forma univoca.
Caracteristicas de negocio relevantes:
- El UUID es unico en toda la empresa
- El UUID es inmutable una vez asignado
- El bridge contiene la informacion del tipo de comprobante y sucursal de origen
- Todos los comprobantes de venta tienen un registro en el bridge
Relacion Movimiento de Caja - Bridge de Ventas
Representa el vinculo entre un movimiento de caja y el comprobante de venta que lo origino, mediante el UUID del bridge de ventas.
Caracteristicas de negocio:
- La relacion es de uno a uno: un movimiento de caja originado por venta tiene exactamente un UUID de bridge asociado
- La relacion es obligatoria para movimientos originados por comprobantes de venta
- La relacion no aplica para movimientos manuales o de otros origenes (anticipos, ajustes, transferencias)
- Un comprobante de venta puede generar uno o mas movimientos de caja (por ejemplo, pagos parciales en diferentes momentos)
Diferencias con Cuenta Corriente
Es importante destacar las diferencias entre los movimientos de caja y los movimientos de cuenta corriente:
| Aspecto | Movimiento de Caja | Movimiento de Cuenta Corriente |
|---|---|---|
| Naturaleza | Flujo de efectivo real | Saldo contable de deuda/credito |
| Momento de registro | Cuando hay entrada/salida de efectivo | Cuando se genera/cancela una deuda |
| Comprobantes origen | Ventas al contado, recibos, devoluciones | Ventas a credito, notas de credito, pagos |
| Impacto en cierres | Afecta arqueo y cierre de caja | No tiene relacion con cierres de caja |
| Eliminacion de comprobante | El movimiento se elimina en cascada | El movimiento se elimina en cascada |
| Estado de la caja | Si la caja esta cerrada, no se puede modificar | No tiene restriccion por estado de caja |
Datos Necesarios
Para la relacion con el bridge de ventas
| Dato | Descripcion | Obligatoriedad |
|---|---|---|
| Identificador del movimiento | Identificador unico del movimiento de caja | Obligatorio |
| UUID del bridge de ventas | Identificador global unico del comprobante de venta asociado | Obligatorio para movimientos originados por ventas |
| Referencia compuesta (temporal) | id_venta + id_tipo_comprobante | Obligatorio durante periodo de transicion |
Nota sobre compatibilidad temporal: Durante el periodo de transicion, el sistema mantendra ambos metodos de referencia (UUID del bridge y referencia compuesta) para garantizar la continuidad operativa y permitir rollback si fuera necesario.
Relaciones de Negocio
Movimiento de Caja ---- (N:1) ---- Identificador Global de Venta (Bridge)Cardinalidades:
- Un movimiento de caja originado por venta tiene exactamente un UUID de bridge asociado
- Un UUID de bridge (comprobante de venta) puede estar asociado a uno o mas movimientos de caja
Ejemplos de relacion:
- Una factura al contado genera una entrada de caja (un movimiento, un UUID)
- Un recibo de cobranza genera una entrada de caja (un movimiento, un UUID)
- Una nota de credito con devolucion de efectivo genera una salida de caja (un movimiento, un UUID)
- Un cobro parcial de factura puede generar multiples entradas de caja en diferentes momentos (multiples movimientos, un UUID por cada recibo)
Validaciones de Negocio
Para el registro de la relacion
Existencia del UUID:
- El UUID del bridge de ventas referenciado debe existir en el sistema
- El sistema debe rechazar movimientos con referencias a UUID inexistentes
Validez del UUID:
- El UUID debe corresponder a un comprobante de venta existente en el bridge
- El UUID debe corresponder a un comprobante de la misma empresa
Unicidad de la relacion por movimiento:
- Un movimiento de caja solo puede tener un UUID de bridge asociado
- El sistema debe rechazar intentos de asignar multiples UUID a un mismo movimiento
Consistencia de tipo de operacion:
- El tipo de movimiento de caja (entrada/salida) debe ser coherente con el tipo de comprobante de venta
- Facturas y recibos generan entradas de caja
- Notas de credito con devolucion generan salidas de caja
Obligatoriedad para movimientos de venta:
- Todo movimiento de caja originado por un comprobante de venta debe tener asociado el UUID del bridge
- Los movimientos manuales, anticipos, transferencias u otros origenes pueden no tener UUID asociado
Inmutabilidad de la relacion en caja cerrada:
- Una vez que la caja es cerrada, la relacion entre movimiento y UUID no puede modificarse
- La relacion se elimina unicamente cuando el movimiento o el comprobante se eliminan (y la caja esta abierta)
Reglas de Negocio
RN-001: Asignacion obligatoria del UUID al crear movimiento de venta
Descripcion: Cuando se crea un movimiento de caja originado por un comprobante de venta, el sistema debe asignar automaticamente el UUID del bridge de ventas correspondiente.
Condicion: Se registra un nuevo comprobante de venta que genera movimiento en caja (factura al contado, recibo de cobranza, nota de credito con devolucion).
Accion:
- El sistema obtiene el UUID del bridge de ventas del comprobante registrado
- El sistema registra el UUID en el movimiento de caja generado
- La asignacion es atomica con la creacion del movimiento
Fundamento: Garantiza que todo nuevo movimiento de caja originado por venta tenga la relacion con el bridge desde el momento de su creacion, manteniendo la integridad de datos.
RN-002: Validacion de existencia del UUID
Descripcion: El UUID del bridge de ventas debe existir y ser valido antes de asociarlo a un movimiento de caja.
Condicion: Se intenta crear o asociar un UUID de bridge a un movimiento de caja.
Accion:
- El sistema verifica que el UUID exista en el bridge de ventas
- El sistema verifica que el comprobante asociado sea valido y no haya sido eliminado
- Si el UUID no existe, el sistema rechaza la operacion con mensaje descriptivo
Fundamento: Asegura la integridad referencial entre movimientos de caja y comprobantes de venta.
RN-003: Inmutabilidad de la relacion en caja cerrada
Descripcion: Una vez cerrada la caja, la relacion entre un movimiento de caja y el UUID del bridge no puede modificarse.
Condicion: Se intenta modificar el UUID del bridge de un movimiento cuya caja ya fue cerrada.
Accion:
- El sistema verifica el estado de la caja del movimiento
- Si la caja esta cerrada, el sistema rechaza cualquier intento de modificar el UUID del bridge
- Si la caja esta abierta, las modificaciones son permitidas (aunque no recomendadas)
Fundamento: Los cierres de caja representan cortes contables. Modificar relaciones de movimientos en cajas cerradas desbalancearia los saldos consolidados.
RN-004: Compatibilidad temporal durante transicion
Descripcion: Durante el periodo de transicion, el sistema debe soportar ambos metodos de referencia (UUID del bridge y referencia compuesta).
Condicion: Existen movimientos de caja creados antes de la implementacion que utilizan referencia compuesta.
Accion:
- El sistema mantiene la referencia compuesta para movimientos historicos no migrados
- El sistema puede consultar movimientos utilizando cualquiera de los dos metodos
- Las nuevas consultas priorizan el UUID del bridge cuando esta disponible
- Se marca claramente que metodo de referencia utiliza cada movimiento
Fundamento: Permite una transicion gradual sin interrumpir las operaciones del negocio ni perder acceso a datos historicos.
RN-005: Migracion de referencias existentes
Descripcion: Los movimientos de caja existentes que utilizan referencia compuesta deben migrarse al nuevo esquema con UUID del bridge.
Condicion: Existen movimientos de caja con referencia compuesta sin UUID de bridge asignado.
Accion:
- El proceso de migracion localiza el comprobante de venta mediante la referencia compuesta
- El sistema obtiene el UUID del bridge del comprobante encontrado
- El sistema actualiza el movimiento con el UUID correspondiente
- Se registra la migracion en el log de auditoria
- Si no se puede determinar el UUID, el movimiento se marca para revision manual
Fundamento: Garantiza que todos los movimientos historicos tengan la nueva relacion para consultas unificadas.
RN-006: Eliminacion del movimiento al eliminar comprobante
Descripcion: Cuando se elimina un comprobante de venta (mediante baja de comprobantes), los movimientos de caja asociados deben eliminarse de forma consistente.
Condicion: Se elimina un comprobante de venta que tiene movimientos de caja asociados.
Accion:
- El sistema identifica los movimientos de caja asociados al UUID del bridge
- El sistema verifica que la caja de cada movimiento este abierta (RN-003)
- Si la caja esta abierta, los movimientos se eliminan fisicamente en cascada
- Si la caja esta cerrada, la eliminacion del comprobante se rechaza
- La eliminacion debe ser parte de la misma transaccion que elimina el comprobante
- Se registra la eliminacion en el log de auditoria antes de ejecutarla
Fundamento: Mantiene la consistencia referencial entre comprobantes y movimientos. La eliminacion fisica asegura que no queden registros huerfanos en caja que referencien comprobantes inexistentes.
RN-007: Preservacion de trazabilidad historica
Descripcion: El sistema debe preservar la informacion de la referencia compuesta original para fines de auditoria, incluso despues de la migracion.
Condicion: Se migra un movimiento de caja de referencia compuesta a UUID.
Accion:
- El sistema mantiene los campos de la referencia compuesta original (id_venta, id_tipo_comprobante)
- Se registra la fecha y hora de migracion
- Se registra el metodo de localizacion del UUID (automatico o manual)
- La informacion historica permanece disponible para consultas de auditoria
Fundamento: Permite auditorias completas y verificacion de la integridad de la migracion.
RN-008: Movimientos manuales sin relacion de bridge
Descripcion: Los movimientos de caja que no se originan por comprobantes de venta no requieren UUID de bridge.
Condicion: Se registra un movimiento de caja manual (anticipo, ajuste, transferencia, retiro, etc.).
Accion:
- El sistema permite crear movimientos sin UUID de bridge asociado
- El campo de UUID permanece vacio para estos movimientos
- El sistema distingue claramente entre movimientos con y sin relacion a comprobantes de venta
Fundamento: No todos los movimientos de caja provienen de comprobantes de venta, y el sistema debe soportar todos los tipos de movimiento.
RN-009: Impacto en cierres de caja
Descripcion: Los procesos de cierre de caja deben utilizar la nueva relacion UUID para validacion y reportes.
Condicion: Se ejecuta un proceso de cierre o arqueo de caja con movimientos que tienen UUID de bridge.
Accion:
- El proceso de cierre/arqueo obtiene la informacion de comprobantes mediante el UUID del bridge
- Los totales por tipo de comprobante se calculan correctamente
- El resumen de cierre incluye la trazabilidad a comprobantes especificos
- Las discrepancias entre movimientos y comprobantes se detectan y reportan
Fundamento: Los cierres requieren precision en la relacion con comprobantes para garantizar la integridad financiera.
RN-010: Coherencia con reglas de baja de comprobantes
Descripcion: La restriccion de caja cerrada para baja de comprobantes debe considerar la nueva relacion con UUID.
Condicion: Se intenta dar de baja un comprobante de venta que tiene movimientos de caja asociados.
Accion:
- El sistema localiza los movimientos de caja asociados mediante el UUID del bridge
- Para cada movimiento encontrado, verifica el estado de su caja
- Si alguna caja esta cerrada, la baja del comprobante se rechaza
- El mensaje de error indica cual caja esta cerrada
Fundamento: Mantiene la consistencia con las reglas existentes de baja de comprobantes (RN-002 de baja-comprobantes-manual-process.md).
Casos de Uso
CU-001: Crear movimiento de caja desde comprobante de venta al contado
Actor: Usuario de Ventas / Sistema (proceso automatico)
Objetivo: Registrar un movimiento de caja (entrada de efectivo) que quede vinculado a una factura al contado mediante el UUID del bridge.
Precondiciones:
- Usuario autenticado con permisos de facturacion
- Caja abierta para el usuario/sucursal
- Comprobante de venta con condicion de pago "Contado" o "Tarjeta"
- Comprobante de venta registrado con UUID de bridge asignado
Flujo principal:
- El usuario completa y confirma una factura de venta al contado
- El sistema valida y registra el comprobante de venta
- El sistema genera el identificador global (UUID) en el bridge de ventas
- El sistema genera automaticamente el movimiento de caja por entrada de efectivo
- El sistema asigna el UUID del bridge al movimiento de caja
- El sistema confirma la operacion exitosa al usuario
Postcondiciones:
- El comprobante de venta queda registrado con su UUID de bridge
- El movimiento de caja queda registrado con el UUID del bridge asociado
- El saldo de la caja se actualiza con la entrada de efectivo
- La relacion esta disponible para consulta inmediata y procesos de cierre
Flujos alternativos:
- Error en generacion de UUID: Si falla la generacion del UUID del bridge, se revierte toda la operacion incluyendo el comprobante y el movimiento de caja
- Caja no abierta: Si no hay caja abierta, el sistema solicita apertura de caja antes de continuar
CU-002: Consultar movimientos de caja y visualizar comprobante relacionado
Actor: Usuario de Tesoreria / Cajero / Contador
Objetivo: Consultar los movimientos de caja y acceder al comprobante de venta asociado de forma directa.
Precondiciones:
- Usuario autenticado con permisos de consulta de tesoreria
- Movimientos de caja existentes con UUID de bridge asignado
Flujo principal:
- El usuario accede a la consulta de movimientos de caja
- El sistema muestra la lista de movimientos del periodo seleccionado
- El usuario identifica un movimiento originado por una venta
- El sistema muestra el indicador de comprobante asociado junto con informacion basica (tipo, numero)
- El usuario selecciona la opcion de ver el comprobante completo
- El sistema utiliza el UUID del bridge para localizar el comprobante
- El sistema muestra el detalle completo del comprobante de venta
Postcondiciones:
- El usuario visualiza la informacion del comprobante de venta asociado al movimiento
- La navegacion es directa sin busquedas intermedias
Flujos alternativos:
- Movimiento sin UUID (pendiente de migracion): El sistema intenta localizar el comprobante mediante la referencia compuesta y muestra un indicador de que el movimiento utiliza el metodo antiguo
- Movimiento manual sin comprobante: El sistema muestra un mensaje indicando que el movimiento no esta asociado a un comprobante de venta
- Comprobante no encontrado: Si el comprobante fue eliminado o hay inconsistencia, el sistema muestra un mensaje de error y registra la incidencia
CU-003: Migrar movimientos existentes de referencia compuesta a UUID
Actor: Administrador del Sistema
Objetivo: Actualizar los movimientos de caja existentes para que utilicen el UUID del bridge en lugar de la referencia compuesta.
Precondiciones:
- Usuario con permisos de administracion de migracion de datos
- Existen movimientos de caja con referencia compuesta sin UUID asignado
- El bridge de ventas tiene UUIDs asignados para los comprobantes existentes
- El sistema esta en un estado que permite ejecutar la migracion
Flujo principal:
- El administrador inicia el proceso de migracion de movimientos de caja
- El sistema identifica todos los movimientos con referencia compuesta sin UUID
- Por cada movimiento identificado:
- El sistema localiza el comprobante de venta mediante id_venta + id_tipo_comprobante
- El sistema obtiene el UUID del bridge del comprobante encontrado
- El sistema actualiza el movimiento con el UUID del bridge
- El sistema registra la migracion en el log de auditoria
- El sistema genera un reporte de migracion con resumen de movimientos procesados
- El sistema confirma la migracion exitosa
Postcondiciones:
- Los movimientos procesados tienen UUID de bridge asignado
- Se preserva la referencia compuesta original para auditoria
- El reporte de migracion esta disponible para revision
- Los movimientos con problemas quedan marcados para revision manual
Flujos alternativos:
- Comprobante no encontrado en bridge: Si no se puede localizar el UUID para un comprobante, el movimiento se marca para revision manual y se continua con los demas
- Movimiento de caja cerrada: Los movimientos de cajas cerradas se procesan normalmente (la migracion no modifica datos financieros, solo agrega referencia)
- Error durante migracion: El sistema puede reiniciar desde el punto de fallo (proceso idempotente)
CU-004: Generar reporte de caja con detalle de comprobantes
Actor: Usuario de Tesoreria / Contador / Gerente
Objetivo: Generar un reporte de caja (planilla de caja, libro de caja) que incluya informacion detallada de los comprobantes de venta asociados a cada movimiento.
Precondiciones:
- Usuario autenticado con permisos de generacion de reportes de tesoreria
- Caja existente con movimientos registrados
- Criterios de reporte definidos (caja, periodo, tipos de movimiento)
Flujo principal:
- El usuario accede a la generacion de reportes de tesoreria
- El usuario selecciona el tipo de reporte (planilla de caja, libro de caja)
- El usuario define la caja y el periodo del reporte
- El usuario solicita la generacion del reporte
- El sistema obtiene los movimientos de caja segun los criterios
- Para cada movimiento originado por venta, el sistema obtiene la informacion del comprobante mediante el UUID del bridge
- El sistema genera el reporte incluyendo:
- Datos del movimiento (fecha, tipo, monto)
- Datos del comprobante asociado (numero, tipo, cliente)
- Totales por tipo de comprobante
- Saldo de caja
- El sistema presenta el reporte al usuario
Postcondiciones:
- El reporte muestra la informacion completa de movimientos y comprobantes
- El usuario puede exportar o imprimir el reporte
- La trazabilidad entre movimientos y comprobantes es evidente
Flujos alternativos:
- Movimientos con referencia compuesta: Para movimientos no migrados, el sistema utiliza la referencia compuesta y lo indica en el reporte
- Sin movimientos en el periodo: El sistema informa que no hay movimientos para los criterios seleccionados
CU-005: Realizar arqueo/cierre de caja con trazabilidad de comprobantes
Actor: Cajero / Supervisor de Caja / Contador
Objetivo: Ejecutar el proceso de arqueo o cierre de caja con validacion completa de movimientos contra comprobantes de venta.
Precondiciones:
- Usuario autenticado con permisos de cierre de caja
- Caja abierta con movimientos del periodo
- Todos los movimientos del periodo debidamente registrados
Flujo principal:
- El usuario inicia el proceso de arqueo/cierre de caja
- El sistema obtiene todos los movimientos de la caja en el periodo
- Para cada movimiento de venta, el sistema valida la existencia del comprobante mediante UUID del bridge
- El sistema calcula totales por tipo de comprobante de venta
- El sistema genera el resumen del arqueo/cierre incluyendo:
- Total de entradas por ventas al contado
- Total de entradas por recibos de cobranza
- Total de salidas por devoluciones
- Detalle de cada comprobante con su UUID
- El usuario verifica el efectivo fisico contra el saldo calculado
- El usuario confirma el cierre de caja
- El sistema registra el cierre con toda la trazabilidad
Postcondiciones:
- El cierre de caja queda registrado con referencias directas a comprobantes
- Los movimientos quedan inmutables (caja cerrada)
- La trazabilidad completa esta disponible para auditoria
- El saldo de cierre queda documentado
Flujos alternativos:
- Discrepancia entre movimiento y comprobante: Si un movimiento referencia un UUID inexistente, el sistema lo reporta como inconsistencia antes del cierre
- Movimientos pendientes de migracion: El sistema permite el cierre pero indica que algunos movimientos usan referencia compuesta
- Diferencia de arqueo: El usuario puede registrar el ajuste con explicacion
Consideraciones
Seguridad
Proteccion de datos:
- Los UUIDs del bridge son datos de referencia que no deben poder modificarse por usuarios sin permisos especiales
- El acceso a la informacion de relacion hereda los permisos del modulo de Tesoreria
- Los registros de migracion deben estar protegidos contra modificaciones no autorizadas
Control de acceso:
- La consulta de movimientos y sus comprobantes asociados requiere permisos de tesoreria y ventas
- El proceso de migracion solo puede ejecutarse por usuarios con rol de administrador
- Las consultas inter-modulo respetan los permisos de cada modulo involucrado
Validacion de integridad:
- Toda operacion que modifique la relacion debe validar permisos del usuario
- Los intentos de operaciones no autorizadas deben registrarse en el log de seguridad
- Las modificaciones en cajas cerradas estan bloqueadas a nivel de sistema
Auditoria
Operaciones que se auditan:
| Operacion | Datos Auditados | Motivo |
|---|---|---|
| Asignacion de UUID a nuevo movimiento | Movimiento, UUID, comprobante, caja | Trazabilidad de creacion |
| Migracion de movimiento existente | Movimiento, UUID, referencia compuesta original, fecha migracion | Control del proceso de migracion |
| Consulta de comprobante desde movimiento | Usuario, movimiento, comprobante | Registro de acceso a informacion |
| Eliminacion de movimiento por baja de comprobante | Movimiento, UUID, caja, estado de caja | Trazabilidad de eliminaciones |
| Errores de validacion | Tipo de error, datos involucrados | Deteccion de problemas de integridad |
Informacion preservada:
- Referencia compuesta original para movimientos migrados (id_venta, id_tipo_comprobante)
- Fecha y hora de cada operacion
- Usuario que ejecuto la operacion
- Metodo utilizado (UUID o referencia compuesta)
- Resultado de la operacion (exito o error)
- Estado de la caja al momento de la operacion
Retencion de datos de auditoria:
- Los registros de auditoria de migracion deben preservarse indefinidamente
- Los registros de operaciones normales siguen la politica de retencion estandar del sistema
Rendimiento
Volumenes esperados:
- Cantidad de movimientos de caja existentes a migrar (depende del historial del sistema)
- Nuevos movimientos generados diariamente proporcionales a las ventas al contado y cobranzas
- Consultas frecuentes de estado de caja, arqueos y reportes
- Cierres de caja diarios por sucursal/caja
Expectativas de tiempo de respuesta:
- La asignacion del UUID no debe agregar latencia perceptible al registro de comprobantes
- La consulta de comprobante desde movimiento debe ser rapida (menos de 100 milisegundos)
- Los reportes de caja con detalle de comprobantes deben generarse en tiempos aceptables
- Los procesos de cierre de caja no deben verse afectados en tiempo de ejecucion
Migracion de datos:
- El proceso de migracion debe poder ejecutarse en horario de baja actividad
- La migracion debe ser incremental y reiniciable
- Se debe estimar el tiempo de migracion segun el volumen de datos
- Los movimientos de cajas cerradas pueden migrarse sin restriccion (no afecta datos financieros)
Migracion
Estrategia de migracion:
- Fase 1 - Preparacion: Validar que todos los comprobantes de venta historicos tengan UUID en el bridge
- Fase 2 - Migracion incremental: Procesar movimientos en lotes para minimizar impacto en el sistema
- Fase 3 - Validacion: Verificar integridad de datos migrados mediante reportes de conciliacion
- Fase 4 - Monitoreo: Mantener alertas para detectar movimientos sin UUID
Periodo de compatibilidad:
- Durante la transicion (estimado: 3-6 meses), el sistema soportara ambos metodos de referencia
- Las consultas priorizaran el UUID cuando este disponible
- Los reportes indicaran claramente que metodo se utiliza para cada movimiento
Tratamiento de casos especiales:
- Movimientos muy antiguos sin comprobante localizable: Marcar para revision manual
- Comprobantes eliminados: Los movimientos asociados deben haber sido eliminados previamente
- Movimientos manuales: No requieren UUID, permanecen sin cambios
- Movimientos de cajas cerradas: Se migran normalmente (la migracion agrega referencia, no modifica montos)
Rollback:
- El proceso de migracion es reversible: los campos de referencia compuesta se mantienen
- En caso de problemas, se puede volver a utilizar la referencia compuesta temporalmente
- Los reportes y procesos deben soportar ambos metodos durante el periodo de transicion
Dependencias
Funcionalidades Relacionadas
Identificadores Globales para Comprobantes de Venta (Bridge de Ventas) (Ver documento): Proporciona el UUID global que se utilizara para vincular movimientos de caja. Esta funcionalidad es prerequisito para la implementacion.
Relacion Movimiento de Cuenta Corriente - Bridge de Ventas (Ver documento): Funcionalidad analoga para el modulo de cuenta corriente que sirve como patron de referencia. Ambas implementaciones deben seguir el mismo patron para consistencia.
Baja de Comprobantes de Venta (Ver documento): El proceso de baja debe considerar la relacion con movimientos de caja para mantener la consistencia. La restriccion de caja cerrada aplica mediante esta relacion.
Registro de Comprobantes de Ventas: El proceso de registro de facturas al contado, recibos de cobranza y notas de credito debe extenderse para asignar el UUID del bridge al movimiento de caja generado.
Modulos de Negocio Involucrados
| Modulo | Rol en esta Funcionalidad |
|---|---|
| Tesoreria | Modulo principal afectado. Los movimientos de caja recibiran el nuevo campo de UUID del bridge |
| Ventas | Proporciona los comprobantes de venta y el bridge con UUIDs globales |
| Configuracion | Almacena parametros de transicion y configuracion de migracion |
| Auditoria | Registra todas las operaciones de migracion y cambios en relaciones |
Impacto en Otros Procesos
| Proceso | Impacto |
|---|---|
| Registro de factura de venta al contado | Genera movimiento de caja con UUID del bridge |
| Registro de recibo de cobranza | Genera movimiento de caja con UUID del bridge |
| Registro de nota de credito con devolucion | Genera movimiento de caja (salida) con UUID del bridge |
| Eliminacion/baja de comprobante de venta | Verifica estado de caja mediante UUID y elimina movimiento si caja abierta |
| Reportes de planilla de caja | Utilizan UUID para obtener informacion de comprobantes |
| Reportes de libro de caja | Utilizan UUID para obtener informacion de comprobantes |
| Arqueo de caja | Valida correspondencia mediante UUID |
| Cierre de caja | Genera resumen con trazabilidad de comprobantes mediante UUID |
| Exportacion de datos | Incluyen el UUID como identificador del comprobante relacionado |
Criterios de Aceptacion
La funcionalidad se considera completa cuando se cumplan los siguientes criterios:
Criterios para registro de nuevos movimientos
[ ] AC-001: Al registrar un nuevo comprobante de venta al contado que genera movimiento en caja, el sistema asigna automaticamente el UUID del bridge de ventas al movimiento creado.
[ ] AC-002: Al registrar un nuevo recibo de cobranza que genera movimiento en caja, el sistema asigna automaticamente el UUID del bridge de ventas al movimiento creado.
[ ] AC-003: El UUID asignado al movimiento de caja corresponde exactamente al UUID del comprobante de venta que lo origino.
[ ] AC-004: El sistema valida que el UUID exista en el bridge de ventas antes de asignarlo al movimiento de caja.
Criterios para consulta de movimientos
[ ] AC-005: Los usuarios pueden consultar el comprobante de venta asociado a un movimiento de caja utilizando el UUID del bridge de forma directa.
[ ] AC-006: La informacion basica del comprobante (numero, tipo, cliente) se muestra junto al movimiento de caja sin necesidad de navegacion adicional.
[ ] AC-007: La navegacion desde un movimiento de caja al detalle del comprobante de venta es directa y no requiere busquedas intermedias.
Criterios para migracion de datos
[ ] AC-008: El proceso de migracion asigna correctamente el UUID del bridge a los movimientos de caja existentes que utilizaban referencia compuesta.
[ ] AC-009: Los movimientos que no pueden migrarse automaticamente quedan marcados para revision manual con informacion del problema detectado.
[ ] AC-010: La migracion preserva la referencia compuesta original (id_venta, id_tipo_comprobante) para fines de auditoria.
[ ] AC-011: El proceso de migracion genera un reporte detallado con estadisticas de movimientos procesados, exitosos y con errores.
[ ] AC-012: Los movimientos de cajas cerradas pueden migrarse correctamente (la migracion no modifica datos financieros).
Criterios de compatibilidad temporal
[ ] AC-013: Durante el periodo de transicion, el sistema soporta consultas tanto por UUID del bridge como por referencia compuesta.
[ ] AC-014: Los movimientos con referencia compuesta (no migrados) pueden consultarse y muestran la informacion del comprobante asociado.
[ ] AC-015: El sistema indica claramente que metodo de referencia utiliza cada movimiento (UUID o referencia compuesta).
Criterios para reportes de tesoreria
[ ] AC-016: Los reportes de planilla de caja muestran la informacion completa del comprobante de venta utilizando el UUID del bridge.
[ ] AC-017: Los reportes de libro de caja muestran la informacion de comprobantes utilizando el UUID del bridge.
[ ] AC-018: Los reportes de cierre de caja incluyen la trazabilidad a comprobantes mediante UUID.
Criterios para cierres y arqueos
[ ] AC-019: El proceso de cierre de caja funciona correctamente con movimientos que tienen UUID del bridge.
[ ] AC-020: El proceso de arqueo de caja puede validar movimientos contra comprobantes utilizando el UUID del bridge.
[ ] AC-021: Los cierres de caja registran la trazabilidad completa a comprobantes de venta.
Criterios de integridad
[ ] AC-022: El sistema rechaza la creacion de movimientos de caja con UUID de bridge inexistente.
[ ] AC-023: El UUID del bridge no puede modificarse una vez asignado a un movimiento de caja cuya caja esta cerrada.
[ ] AC-024: Al dar de baja un comprobante de venta, el sistema verifica el estado de la caja del movimiento asociado mediante el UUID.
Criterios de auditoria
[ ] AC-025: Todas las operaciones de asignacion de UUID a movimientos quedan registradas en el log de auditoria.
[ ] AC-026: Las operaciones de migracion registran la referencia compuesta original, el UUID asignado y la fecha de migracion.
[ ] AC-027: Los errores de validacion durante asignacion o migracion quedan registrados con detalle suficiente para diagnostico.
Notas Adicionales
Diferencia entre metodos de referencia
| Aspecto | Referencia Compuesta (Actual) | UUID del Bridge (Nuevo) |
|---|---|---|
| Campos utilizados | id_venta + id_tipo_comprobante | UUID unico |
| Unicidad | Unica por sucursal y tipo | Unica en toda la empresa |
| Complejidad de consulta | Requiere dos campos | Requiere un solo campo |
| Consistencia arquitectonica | Patron antiguo | Alineado con bridge de ventas y cuenta corriente |
| Ambiguedad multi-sucursal | Posible | Eliminada |
Tipos de movimientos de caja afectados
| Tipo de Movimiento | Origen | Requiere UUID de Bridge |
|---|---|---|
| Entrada por factura al contado | Factura de venta con pago en efectivo | Si |
| Entrada por recibo de cobranza | Recibo de cobro de facturas a credito | Si |
| Entrada por venta con tarjeta | Factura de venta con pago con tarjeta | Si |
| Salida por devolucion de efectivo | Nota de credito con devolucion | Si |
| Anticipo de cliente | Ingreso por anticipo | No (no es comprobante de venta) |
| Ajuste manual | Operacion administrativa | No |
| Transferencia entre cajas | Operacion interna | No |
| Retiro de efectivo | Operacion interna | No |
Consideraciones sobre la baja de comprobantes
La integracion con el proceso de baja de comprobantes (baja-comprobantes-manual-process.md) debe considerar:
Restriccion de caja cerrada: Al intentar dar de baja un comprobante, el sistema debe localizar los movimientos de caja asociados mediante el UUID del bridge y verificar si alguna caja esta cerrada.
Eliminacion en cascada: Si la caja esta abierta, el movimiento de caja se elimina fisicamente junto con el comprobante de venta.
Orden de verificacion: La verificacion del estado de caja debe realizarse antes de cualquier eliminacion.
Consideraciones para integraciones externas
Si en el futuro se exponen movimientos de caja a sistemas externos:
- Utilizar el UUID del bridge como identificador del comprobante asociado
- No exponer la referencia compuesta para evitar complejidad y ambiguedades
- El UUID es autosuficiente para localizar cualquier comprobante de venta
Preguntas frecuentes
Se eliminara la referencia compuesta?
- No inmediatamente. La referencia compuesta se mantendra para compatibilidad y auditoria. En el futuro, podria depreciarse una vez que todos los movimientos esten migrados.
Que pasa con los movimientos muy antiguos?
- Se intentara migrarlos automaticamente. Los que no puedan migrarse quedaran marcados para revision manual y seguiran funcionando con la referencia compuesta.
Como afecta esto al rendimiento?
- Las consultas por UUID son mas eficientes que las consultas por referencia compuesta. El rendimiento general deberia mejorar.
Se requiere tiempo de inactividad para la migracion?
- No. La migracion es incremental y puede ejecutarse mientras el sistema esta en operacion.
Que pasa si se elimina un comprobante de venta?
- El sistema verifica el estado de la caja del movimiento asociado. Si la caja esta abierta, el movimiento se elimina en cascada. Si la caja esta cerrada, la baja del comprobante se rechaza.
Que diferencia hay con cuenta corriente?
- La principal diferencia es la restriccion por estado de caja. En cuenta corriente no existe esta restriccion. En tesoreria, los movimientos de cajas cerradas no pueden eliminarse.
Los cierres de caja se veran afectados?
- No negativamente. Los cierres de caja funcionaran igual pero con mejor trazabilidad a los comprobantes de venta asociados.
Historial de Cambios
| Fecha | Version | Autor | Descripcion |
|---|---|---|---|
| 2025-12-29 | 1.0 | Sistema | Creacion del documento de requerimientos de negocio para la relacion de movimientos de caja con el bridge de ventas mediante UUID. Incluye diferencias especificas con cuenta corriente: restriccion por estado de caja, impacto en cierres y arqueos, y tipos de movimientos afectados. |