Identificadores Globales para Comprobantes de Compra

Modulo: Compras Tipo: Resource Estado: Planificado Fecha: 2025-12-24

---

Descripcion

Problema de negocio

En un sistema multi-sucursal con arquitectura de esquemas separados por sucursal, cada sucursal gestiona sus propios comprobantes de compra con identificadores numericos locales (secuenciales dentro de cada sucursal). Esta arquitectura genera el siguiente problema critico:

Superposicion de identificadores: El mismo numero de identificador puede existir en diferentes sucursales. Por ejemplo:

• Sucursal 1 puede tener un comprobante de compra con identificador 500
• Sucursal 2 puede tener un comprobante de compra diferente tambien con identificador 500
• Cuando se requiere referenciar un comprobante de compra desde operaciones a nivel empresa, no es posible determinar univocamente a cual comprobante se refiere el identificador 500

Las operaciones que referencian comprobantes de compra no pueden identificar univocamente el comprobante cuando operan a nivel empresa, generando ambiguedad en la trazabilidad y auditoria.

Necesidad del negocio

El sistema requiere implementar un mecanismo de identificacion global para comprobantes de compra que resuelva la superposicion de identificadores locales, proporcionando:

1. Identificadores unicos a nivel empresa: Cada comprobante de compra debe tener un identificador unico que lo distinga de cualquier otro comprobante de la empresa, independientemente de la sucursal que lo registro

2. Mapeo transparente: El sistema debe mantener un mapeo entre el identificador local de cada sucursal y el identificador global de la empresa

3. Compatibilidad retroactiva: Los comprobantes de compra existentes deben incorporarse al nuevo esquema de identificacion sin perdida de datos ni interrupcion del servicio

4. Trazabilidad mejorada: Los modulos que referencian comprobantes de compra deben utilizar el identificador global para garantizar referencias univocas

5. Migracion de relaciones existentes: Las entidades que actualmente referencian comprobantes mediante identificadores compuestos deben migrar a usar el UUID del bridge:

   • ordcte_subdicom: Relacion comprobante-movimiento de cuenta corriente (actualmente usa id_compra + tipo)
   • movimi: Movimientos de stock (actualmente usa id_compra + tipo)
   • mov_sto: Movimientos de stock alternativos (actualmente usa id_compra + tipo)

Valor de negocio

La implementacion de identificadores globales para comprobantes de compra aportara los siguientes beneficios:

1. Trazabilidad inequivoca de compras: Cada referencia a un comprobante de compra sera unica e irrepetible en toda la empresa, eliminando ambiguedades

2. Referencias confiables entre modulos: Los modulos que necesiten referenciar comprobantes de compra podran hacerlo sin riesgo de confusion

3. Auditoria simplificada: Los procesos de verificacion y control podran rastrear relaciones entre modulos sin ambiguedades

4. Preparacion para integraciones: El sistema estara preparado para exponer identificadores unicos a sistemas externos (AFIP, sistemas de gestion de proveedores, etc.)

5. Escalabilidad: La solucion permite agregar nuevas sucursales sin riesgo de conflictos de identificadores

Contexto en el proceso de negocio

Esta funcionalidad se integra en los siguientes flujos:

Flujo de registro de comprobantes de compra:

1. El usuario registra un comprobante de compra (factura de proveedor) en su sucursal
2. El sistema asigna el identificador local de la sucursal
3. [Esta funcionalidad] El sistema genera y registra un identificador global unico para el comprobante
4. El sistema registra el mapeo: identificador local + sucursal -> identificador global
5. El comprobante queda disponible para operaciones a nivel empresa usando su identificador global

Flujo de migracion de datos existentes:

1. El administrador ejecuta el proceso de migracion
2. El sistema recorre todos los comprobantes de compra existentes en todas las sucursales
3. Por cada comprobante, el sistema genera un identificador global unico
4. El sistema registra el mapeo correspondiente
5. El proceso valida la integridad de los datos migrados

---

Frontend

Vistas

Esta funcionalidad es de infraestructura y no requiere vistas especificas de usuario.

Interacciones del usuario

• Los usuarios no interactuan directamente con los identificadores globales
• El proceso de generacion de identificadores globales es automatico y transparente
• Los usuarios continuan trabajando con los numeros de comprobante habituales
• En reportes consolidados y operaciones a nivel empresa, el sistema utiliza internamente los identificadores globales para garantizar precision

Permisos

• No se requieren permisos especiales para esta funcionalidad
• Los permisos existentes del modulo de compras aplican normalmente
• El proceso de migracion requiere permisos de administracion del sistema

Estados de UI

• No aplica - La funcionalidad opera de forma transparente al usuario

---

Backend

Entidades de negocio

Identificador Global de Comprobante de Compra

Representa el mapeo entre el identificador local de un comprobante de compra en una sucursal y su identificador unico a nivel empresa.

Proposito: Proporcionar un identificador univoco que permita referenciar cualquier comprobante de compra de la empresa sin ambiguedad, independientemente de la sucursal que lo registro.

Caracteristicas de negocio:

• Cada combinacion de identificador local + schema principal tiene exactamente un identificador global
• El identificador global es unico en toda la empresa
• El registro incluye el schema principal de origen para trazabilidad y auditoria
• Una vez creado, el identificador global no puede modificarse
• Si el comprobante de compra es eliminado, su registro de mapeo tambien se elimina

Datos necesarios

Dato	Descripcion	Obligatoriedad
Identificador del registro	Identificador unico del registro de mapeo	Obligatorio (generado por el sistema)
Identificador local de compra	Numero identificador del comprobante de compra dentro de la sucursal	Obligatorio
Identificador global	Identificador unico del comprobante a nivel empresa (UUID)	Obligatorio (generado por el sistema)
Sucursal de origen	Identificador del schema principal de la sucursal que registro el comprobante (formato: nombre del schema PostgreSQL, ej: "suc0001")	Obligatorio

Relaciones de negocio

Comprobante de Compra (Sucursal) ---- (1:1) ---- Identificador Global de Compra

Cardinalidades:

• Un comprobante de compra tiene exactamente un identificador global
• Un identificador global corresponde a exactamente un comprobante de compra

Validaciones de negocio

Para el registro de identificadores globales de compra

1. Unicidad del identificador global:

   • El identificador global generado debe ser unico en toda la empresa
   • No puede existir otro comprobante de compra (de ninguna sucursal) con el mismo identificador global

2. Unicidad del mapeo:

   • La combinacion de identificador local + schema principal debe ser unica
   • No puede existir mas de un identificador global para el mismo comprobante de compra

3. Existencia del comprobante:

   • Al crear el registro de mapeo, el comprobante de compra referenciado debe existir en el schema principal indicado

4. Validez del schema:

   • El schema principal de origen debe ser un schema valido y activo en el sistema

5. Inmutabilidad del identificador global:

   • Una vez asignado, el identificador global no puede modificarse
   • El schema principal de origen no puede modificarse

---

Reglas de Negocio

RN-001: Generacion automatica de identificador global al registrar comprobante de compra

Descripcion: Cuando se registra un nuevo comprobante de compra, el sistema debe generar y registrar automaticamente su identificador global unico.

Condicion: Se esta registrando un nuevo comprobante de compra en cualquier sucursal.

Accion:

• El sistema genera un identificador global unico para el comprobante
• El sistema crea el registro de mapeo con: identificador local, identificador global, schema principal de origen
• La generacion del identificador global es atomica con el registro del comprobante

Fundamento: Garantiza que todo nuevo comprobante de compra tenga un identificador unico a nivel empresa desde el momento de su creacion.

---

RN-002: Unicidad del identificador global a nivel empresa

Descripcion: Cada identificador global debe ser unico en toda la empresa, sin posibilidad de duplicados entre sucursales.

Condicion: Se genera un nuevo identificador global para cualquier comprobante de compra.

Accion:

• El sistema valida que el identificador global no exista previamente
• Si existe conflicto (extremadamente improbable), el sistema genera un nuevo identificador
• El identificador queda reservado de forma exclusiva para ese comprobante

Fundamento: Garantiza que el identificador global cumpla su proposito de identificacion univoca.

---

RN-003: Registro obligatorio de schema principal de origen

Descripcion: Todo registro de identificador global debe incluir el schema principal de la sucursal que registro el comprobante de compra original.

Condicion: Se crea un registro de mapeo de identificador global.

Accion:

• El sistema registra automaticamente el identificador del schema principal donde se esta registrando el comprobante
• Esta informacion no puede modificarse posteriormente

Fundamento: Permite mantener la trazabilidad del origen de cada comprobante para auditorias, reportes y consultas. El schema principal identifica univocamente la sucursal en la arquitectura multi-tenant.

---

RN-004: Inmutabilidad del identificador global

Descripcion: Una vez asignado un identificador global a un comprobante de compra, este no puede modificarse.

Condicion: Existe un registro de mapeo de identificador global.

Accion:

• El sistema rechaza cualquier intento de modificar el identificador global
• El sistema rechaza cualquier intento de modificar el schema principal de origen

Fundamento: Garantiza la integridad de las referencias que utilizan el identificador global.

---

RN-005: Migracion obligatoria de comprobantes existentes

Descripcion: Todos los comprobantes de compra existentes en el sistema deben tener asignado un identificador global antes de la puesta en produccion de esta funcionalidad.

Condicion: Existen comprobantes de compra sin identificador global asignado.

Accion:

• El proceso de migracion recorre todos los comprobantes existentes en todas las sucursales
• Por cada comprobante sin identificador global, genera uno nuevo
• Registra el mapeo correspondiente
• Valida la integridad de los datos migrados

Fundamento: Garantiza que el sistema funcione de forma consistente para comprobantes nuevos y existentes.

---

RN-006: Eliminacion del mapeo al eliminar comprobante

Descripcion: Si un comprobante de compra es eliminado, su registro de identificador global tambien debe eliminarse.

Condicion: Se elimina un comprobante de compra.

Accion:

• El sistema elimina el registro de mapeo de identificador global asociado al comprobante
• Se elimina toda trazabilidad del mapeo

Fundamento: Mantiene la consistencia de datos - si el comprobante no existe, su mapeo de identificador global tampoco debe existir.

---

RN-007: Consulta de comprobante por identificador global

Descripcion: El sistema debe permitir localizar un comprobante de compra utilizando su identificador global, independientemente de la sucursal actual del usuario.

Condicion: Se solicita consultar un comprobante mediante su identificador global.

Accion:

• El sistema busca el registro de mapeo por identificador global
• Obtiene el identificador local y schema principal de origen
• Recupera el comprobante de compra del schema correspondiente
• Retorna la informacion del comprobante

Fundamento: Permite operaciones a nivel empresa que requieren localizar comprobantes de cualquier sucursal.

---

RN-008: Migracion de relaciones existentes a UUID

Descripcion: Las entidades que actualmente referencian comprobantes mediante identificadores compuestos deben migrar para usar el UUID del bridge.

Condicion: Existen registros en ordcte_subdicom, movimi y mov_sto que usan referencias compuestas (id_compra + tipo).

Accion:

• El sistema identifica todos los registros con referencias compuestas
• Para cada registro:
  • Localiza el comprobante mediante la referencia compuesta
  • Obtiene el UUID del bridge del comprobante
  • Actualiza el registro para usar el UUID en lugar de la referencia compuesta
  • Preserva la referencia compuesta original para auditoria
  • Registra la migracion en el log de auditoria
• Valida la integridad de los datos migrados

Fundamento: Garantiza que todas las relaciones con comprobantes de compra usen identificadores unicos globales, eliminando ambiguedades y mejorando la trazabilidad entre modulos.

---

RN-009: Compatibilidad temporal durante transicion

Descripcion: Durante el periodo de transicion, el sistema debe soportar tanto el UUID del bridge como las referencias compuestas para consultas.

Condicion: Se realiza una consulta que involucra comprobantes de compra.

Accion:

• El sistema prioriza el uso de UUID cuando este disponible
• Si el UUID no esta disponible, utiliza la referencia compuesta
• Indica claramente que metodo de referencia se esta utilizando

Fundamento: Permite una transicion gradual sin interrumpir las operaciones del negocio ni perder acceso a datos historicos.

---

Casos de Uso

CU-001: Registrar comprobante de compra con identificador global

Actor: Usuario de Compras

Objetivo: Registrar un nuevo comprobante de compra que automaticamente recibe un identificador global unico

Precondiciones:

• Usuario autenticado con permisos de registro de compras
• Usuario operando en una sucursal especifica

Flujo principal:

1. El usuario completa los datos del comprobante de compra (factura de proveedor, datos del proveedor, items, totales, etc.)
2. El usuario confirma el registro del comprobante
3. El sistema valida y registra el comprobante de compra con su identificador local
4. El sistema genera automaticamente un identificador global unico
5. El sistema crea el registro de mapeo: identificador local + schema principal -> identificador global
6. El sistema confirma la operacion exitosa al usuario

Postcondiciones:

• El comprobante de compra queda registrado con su identificador local habitual
• Existe un identificador global unico asociado al comprobante
• El registro de mapeo esta disponible para consultas y referencias

Flujos alternativos:

• Error en generacion de identificador global: Si ocurre un error al generar el identificador global, se revierte toda la operacion incluyendo el comprobante

---

CU-002: Migrar comprobantes de compra existentes a identificadores globales

Actor: Administrador del Sistema

Objetivo: Asignar identificadores globales a todos los comprobantes de compra existentes que no tienen uno

Precondiciones:

• Usuario con permisos de administracion del sistema
• Existen comprobantes de compra sin identificador global asignado
• El sistema esta en un estado que permite ejecutar la migracion

Flujo principal:

1. El administrador inicia el proceso de migracion de comprobantes de compra
2. El sistema identifica todos los comprobantes de compra sin identificador global en todas las sucursales
3. Por cada comprobante de compra encontrado:
   • El sistema determina el schema principal de origen
   • El sistema genera un identificador global unico
   • El sistema crea el registro de mapeo
4. El sistema valida la integridad de los datos migrados
5. El sistema genera un reporte de la migracion realizada
6. El sistema confirma la migracion exitosa

Postcondiciones:

• Todos los comprobantes de compra tienen identificador global asignado
• No hay registros duplicados de identificadores globales
• El reporte de migracion esta disponible para revision

Flujos alternativos:

• Error durante migracion: El sistema puede reiniciar la migracion desde el punto de fallo (proceso idempotente)
• Comprobante sin sucursal identificable: El sistema registra el caso para revision manual y continua con los demas

---

CU-003: Consultar comprobante de compra por identificador global

Actor: Usuario consultando informacion relacionada con compras

Objetivo: Localizar un comprobante de compra utilizando su identificador global, independientemente de la sucursal

Precondiciones:

• Usuario autenticado con permisos de consulta
• Existe un comprobante de compra con identificador global

Flujo principal:

1. El usuario o sistema solicita consultar un comprobante mediante su identificador global
2. El sistema utiliza el identificador global para localizar el registro de mapeo
3. El sistema obtiene el schema principal de origen y el identificador local del comprobante
4. El sistema recupera y muestra la informacion del comprobante de compra

Postcondiciones:

• El usuario visualiza la informacion del comprobante de compra relacionado
• La consulta funciona correctamente aunque el comprobante sea de otra sucursal

Flujos alternativos:

• Identificador global no encontrado: Si el identificador global no existe, el sistema informa que no se puede localizar el comprobante

---

CU-004: Migrar relaciones existentes para usar UUID del bridge

Actor: Administrador del Sistema

Objetivo: Actualizar las relaciones existentes (ordcte_subdicom, movimi, mov_sto) para que usen el UUID del bridge en lugar de referencias compuestas

Precondiciones:

• Usuario con permisos de administracion del sistema
• Todos los comprobantes de compra tienen UUID asignado (CU-002 completado)
• Existen registros con referencias compuestas (id_compra + tipo) en ordcte_subdicom, movimi y/o mov_sto

Flujo principal:

1. El administrador inicia el proceso de migracion de relaciones
2. El sistema identifica todos los registros con referencias compuestas en:
   • ordcte_subdicom (relacion comprobante-cuenta corriente)
   • movimi (movimientos de stock)
   • mov_sto (movimientos de stock alternativos)
3. Para cada registro encontrado:
   • El sistema localiza el comprobante mediante id_compra + tipo
   • El sistema obtiene el UUID del bridge del comprobante
   • El sistema valida que el UUID exista
   • El sistema actualiza el registro para usar el UUID
   • El sistema preserva la referencia compuesta original para auditoria
   • El sistema registra la migracion en el log
4. El sistema valida la integridad de los datos migrados
5. El sistema genera un reporte detallado de la migracion por entidad
6. El sistema confirma la migracion exitosa

Postcondiciones:

• Las relaciones en ordcte_subdicom, movimi y mov_sto usan UUID del bridge
• Se preserva la referencia compuesta original para trazabilidad
• El reporte de migracion esta disponible para revision
• Las consultas pueden usar UUID para referencias directas

Flujos alternativos:

• Comprobante no encontrado: Si no se puede localizar el comprobante para una referencia, se marca el registro para revision manual y se continua con los demas
• UUID no disponible: Si un comprobante no tiene UUID asignado, se registra el error y se detiene la migracion (requiere ejecutar CU-002 primero)
• Error durante migracion: El proceso es idempotente y puede reiniciarse desde el punto de fallo

---

Consideraciones

Seguridad

Proteccion de datos:

• Los identificadores globales son datos de auditoria que no deben poder modificarse por ningun usuario
• El acceso a la informacion de mapeo hereda los permisos del modulo de compras
• Los registros de mapeo deben estar protegidos contra modificaciones no autorizadas
• Solo procesos autorizados del sistema pueden generar nuevos identificadores globales

Control de acceso:

• La consulta de identificadores globales esta disponible para usuarios con permisos de consulta de compras
• El proceso de migracion solo puede ejecutarse por usuarios con rol de administrador
• No existe funcionalidad para modificar identificadores globales manualmente

Auditoria

Operaciones que se auditan:

Operacion	Datos auditados	Motivo
Generacion de identificador global	Comprobante, identificador global, schema principal	Trazabilidad de asignacion
Migracion de comprobantes	Cantidad migrada, errores, schemas	Control del proceso de migracion
Eliminacion de mapeo	Identificador global eliminado, comprobante asociado	Trazabilidad de eliminaciones

Informacion preservada:

• Identificador global asignado a cada comprobante de compra
• Schema principal de origen del comprobante
• Fecha y hora de creacion del mapeo
• Usuario que genero la operacion que origino el comprobante

Rendimiento

Volumenes esperados:

• Un registro de mapeo por cada comprobante de compra registrado en el sistema
• El volumen crece proporcionalmente con la cantidad de comprobantes de compra emitidos
• Empresas con alta actividad de compras pueden tener miles de registros por mes

Expectativas de tiempo de respuesta:

• La generacion del identificador global no debe agregar latencia perceptible al registro de comprobantes
• La consulta de comprobante por identificador global debe ser inmediata (menos de 100 milisegundos)
• El proceso de migracion puede ejecutarse en horario de baja actividad

Consideraciones de busqueda:

• Las busquedas por identificador global son frecuentes y deben ser eficientes
• Las busquedas inversas (de identificador local a global) tambien son comunes

Migracion de datos

Estrategia de migracion en fases:

Fase 1 - Generacion de UUID para comprobantes:

• Todos los comprobantes de compra existentes reciben UUID
• El proceso es idempotente (puede ejecutarse multiples veces)
• Se genera reporte de migracion para validacion

Fase 2 - Migracion de ordcte_subdicom:

• Actualizar relacion comprobante-cuenta corriente para usar UUID
• Preservar referencia compuesta original para auditoria
• Validar integridad post-migracion

Fase 3 - Migracion de movimi:

• Actualizar movimientos de stock para usar UUID
• Preservar referencia compuesta original
• Validar consistencia con comprobantes

Fase 4 - Migracion de mov_sto:

• Actualizar movimientos de stock alternativos para usar UUID
• Preservar referencia compuesta original
• Validar integridad final

Fase 5 - Validacion integral:

• Verificar que todas las relaciones usen UUID
• Validar integridad referencial completa
• Generar reporte consolidado de migracion

Compatibilidad durante transicion:

• El sistema soporta ambos metodos (UUID y referencia compuesta) durante la transicion
• Las funcionalidades existentes no se ven afectadas
• La transicion es transparente para los usuarios
• Periodo estimado de compatibilidad: 3-6 meses

---

Dependencias

Funcionalidades relacionadas

• Registro de Comprobantes de Compra: El proceso de registro de facturas de proveedores y otros comprobantes debe extenderse para generar automaticamente el identificador global.

• Identificadores Globales de Ventas (Ver documento): Funcionalidad hermana que implementa el mismo concepto para comprobantes de venta.

• Relacion Comprobante-Cuenta Corriente (Ver documento): La entidad ordcte_subdicom debe migrar para usar UUID del bridge en lugar de referencias compuestas.

Modulos de negocio involucrados

Modulo	Rol en esta funcionalidad
Compras	Genera comprobantes de compra y dispara la creacion de identificadores globales
Configuracion	Almacena la entidad de mapeo a nivel empresa (compartida entre sucursales)
Cuenta Corriente	Utiliza UUID del bridge en ordcte_subdicom para relacionar comprobantes con movimientos
Stock	Utiliza UUID del bridge en movimi y mov_sto para relacionar comprobantes con movimientos de stock

Impacto en otros procesos

Proceso	Impacto
Registro de comprobante de compra	Genera automaticamente identificador global
Relacion comprobante-cuenta corriente (ordcte_subdicom)	Migra de referencia compuesta a UUID del bridge
Movimientos de stock (movimi, mov_sto)	Migran de referencia compuesta a UUID del bridge

---

Criterios de Aceptacion

La funcionalidad se considera completa cuando se cumplan los siguientes criterios:

Criterios para comprobantes de compra

• [ ] AC-001: Al registrar un nuevo comprobante de compra, el sistema genera automaticamente un identificador global unico

• [ ] AC-002: El identificador global de compra es unico en toda la empresa (no se repite entre schemas)

• [ ] AC-003: El registro de mapeo incluye: identificador local, identificador global, schema principal de origen

• [ ] AC-004: El mismo identificador local puede existir en diferentes schemas con diferentes identificadores globales

Criterios de migracion

• [ ] AC-005: El proceso de migracion asigna identificadores globales a todos los comprobantes de compra existentes

• [ ] AC-006: La migracion no genera duplicados de identificadores globales

• [ ] AC-007: La migracion no causa perdida de datos

Criterios de integridad

• [ ] AC-008: El identificador global no puede modificarse una vez asignado

• [ ] AC-009: El schema principal de origen no puede modificarse una vez registrado

• [ ] AC-010: Si se elimina un comprobante, su mapeo de identificador global se elimina

• [ ] AC-011: La combinacion de identificador local + schema principal tiene exactamente un identificador global (sin duplicados)

• [ ] AC-012: Un identificador global no puede ser reutilizado

Criterios de rendimiento

• [ ] AC-013: La generacion del identificador global no agrega latencia perceptible al registro de comprobantes

• [ ] AC-014: La consulta por identificador global responde en menos de 100 milisegundos

• [ ] AC-015: El sistema continua funcionando normalmente despues de la migracion

Criterios de migracion de relaciones

• [ ] AC-016: ordcte_subdicom migra correctamente para usar UUID del bridge en lugar de id_compra + tipo

• [ ] AC-017: movimi migra correctamente para usar UUID del bridge en lugar de id_compra + tipo

• [ ] AC-018: mov_sto migra correctamente para usar UUID del bridge en lugar de id_compra + tipo

• [ ] AC-019: Se preserva la referencia compuesta original en todas las entidades migradas para auditoria

• [ ] AC-020: Las consultas funcionan correctamente usando UUID despues de la migracion

• [ ] AC-021: Durante la transicion, el sistema soporta tanto UUID como referencia compuesta

• [ ] AC-022: El proceso de migracion de relaciones es idempotente (puede ejecutarse multiples veces)

• [ ] AC-023: Se genera un reporte detallado por entidad migrada (ordcte_subdicom, movimi, mov_sto)

• [ ] AC-024: Los registros sin UUID disponible se marcan para revision manual sin detener la migracion completa

---

Notas adicionales

Diferencia entre identificador local e identificador global

Aspecto	Identificador Local	Identificador Global
Alcance	Unico dentro de la sucursal	Unico en toda la empresa
Generacion	Secuencial por sucursal	Generado con garantia de unicidad global
Uso actual	Numero de comprobante visible al usuario	Uso interno para referencias entre modulos
Puede repetirse	Si, entre sucursales	No, nunca
Formato	Numerico secuencial	Identificador unico universal

Consideraciones para integraciones externas

Si en el futuro se exponen identificadores de comprobantes de compra a sistemas externos (AFIP, sistemas de proveedores, integraciones B2B, etc.), se recomienda:

1. Utilizar el identificador global como referencia externa
2. No exponer el identificador local para evitar ambiguedades
3. El identificador global es autosuficiente para localizar cualquier comprobante de compra

Entidades que migran a UUID

Las siguientes entidades actualmente usan referencias compuestas (id_compra + tipo) y migraran para usar el UUID del bridge:

Entidad	Proposito	Referencia Actual	Nueva Referencia
ordcte_subdicom	Relacion comprobante-movimiento de cuenta corriente	id_compra + tipo	UUID del bridge
movimi	Movimientos de stock	id_compra + tipo	UUID del bridge
mov_sto	Movimientos de stock alternativos	id_compra + tipo	UUID del bridge

Beneficios de la migracion:

• Referencias univocas sin ambiguedad entre sucursales
• Consultas simplificadas (un solo campo en lugar de dos)
• Integridad referencial mejorada
• Consistencia arquitectonica con el modulo de ventas

Preguntas frecuentes

1. Los usuarios veran el identificador global?

   • No directamente. Los usuarios siguen trabajando con los numeros de comprobante habituales. El identificador global es de uso interno del sistema.

2. Que pasa si se agrega una nueva sucursal?

   • La nueva sucursal funcionara normalmente. Sus comprobantes de compra recibiran identificadores globales unicos que no conflictuaran con ninguna otra sucursal.

3. Se puede migrar en etapas?

   • Si. El proceso de migracion se ejecuta en 5 fases: (1) UUID para comprobantes, (2) ordcte_subdicom, (3) movimi, (4) mov_sto, (5) validacion integral.

4. Que pasa con los reportes existentes?

   • Los reportes existentes no se ven afectados. La funcionalidad opera de forma transparente. Internamente las referencias seran mas robustas.

5. Como se manejan las referencias historicas?

   • Se preserva la referencia compuesta original para auditoria. Durante la transicion, el sistema soporta ambos metodos.

---

Historial de cambios

Fecha	Version	Autor	Descripcion
2025-12-24	1.0	Sistema	Creacion del documento de requerimientos de negocio para mapeo de identificadores globales de comprobantes de compra. Al eliminar un comprobante, se elimina el registro bridge. El documento se enfoca exclusivamente en el mapeo de identificadores - el uso del bridge por otros modulos se documenta en sus respectivos documentos
2025-12-29	1.1	Sistema	Agregado: (1) Migracion de relaciones existentes (ordcte_subdicom, movimi, mov_sto) para usar UUID del bridge, (2) RN-008 y RN-009 sobre migracion y compatibilidad temporal, (3) CU-004 para migracion de relaciones, (4) Estrategia de migracion en 5 fases, (5) Criterios de aceptacion AC-016 a AC-024 para migracion de relaciones, (6) Tabla de entidades que migran a UUID, (7) Referencias a documentacion relacionada (rel-ctacte-compras-resource.md)