Wiki

Documentación de Cambio: Control de Concurrencia y Duplicidad en Remisiones

Objeto Modificado: w_remisiones_factura_ela.srw Fecha:19/03/2026

Tipo de Cambio: Mejora de Integridad de Datos / Corrección

1. Resumen del cambio Se implementó un mecanismo de validación robusto en el proceso de guardado y envío de remisiones de facturas. El objetivo es prevenir dos escenarios críticos:

Duplicidad: Que un mismo documento sea incluido en múltiples remisiones activas. Colisión de Concurrencia: Que dos usuarios intenten procesar el mismo documento simultáneamente. 2. Descripción Funcional (Para Usuarios) Al momento de hacer clic en Guardar o procesar la remisión, el sistema realiza una verificación automática de cada documento en la lista:

Bloqueo de Seguridad: El sistema verifica si alguien más está trabajando con alguno de los documentos seleccionados en ese preciso instante. Comportamiento: Si detecta uso simultáneo, mostrará el mensaje: “El documento [No. Factura] está siendo procesado por otro usuario en este momento. La operación será cancelada.” Validación de Duplicados: El sistema busca en la base de datos si el documento ya pertenece a otra remisión que esté en proceso, enviada o aprobada (cualquier estado diferente a Rechazada o Anulada). Comportamiento: Si lo encuentra, mostrará el mensaje: “El documento [No. Factura] ya se encuentra incluido en la remisión No. [XXXX] y no puede ser agregado…” En ambos casos, la operación se detiene y no se guardan cambios hasta que se resuelva el conflicto (por ejemplo, eliminando el documento conflictivo de la lista).

3. Detalles Técnicos (Para Desarrolladores) 3.1. Estrategia de Implementación Se optó por realizar la validación en el evento ue_grabar (Commit time) en lugar de línea por línea durante la inserción. Esto garantiza que la validación sea atómica respecto a la transacción final y minimiza el tiempo de bloqueo de recursos.

3.2. Cambios en Código (w_remisiones_factura_ela.srw) Evento ue_grabar Se insertó un bloque de lógica al inicio del evento, antes de cualquier actualización de estado o commit.

Lógica del Algoritmo:

Iteración: Se recorre el DataWindow dw_remision_facturas_det. Identificación: Se obtiene IDENTIFICACION_FACTURA de MAE_RECEPCION_PEDIDOS para usar en mensajes de error (UX). Control de Concurrencia (FOR UPDATE NOWAIT): Se intenta bloquear el registro maestro del documento en MAE_RECEPCION_PEDIDOS. Si la BD retorna SQLDBCode = 54 (ORA-00054: resource busy), se asume concurrencia, se hace Rollback y se retorna. Control de Duplicidad: Se consulta DET_REMISION_FACTURA uniendo con MAESTRO_REMISION_FACTURA. Criterios de búsqueda: Mismo codigo_documento. Diferente codigo_remision (para excluir la actual). Estado activo (No 'J' - Rechazada, ni 'C' - Cancelada/Anulada). Si SQLCode = 0 (se encontró registro), se obtiene el consecutivo de la remisión externa, se muestra error, se hace Rollback y se retorna. Función f_inserte_documento Se mantuvo (o restauró) a su versión ligera. Solo realiza el INSERT en la tabla temporalmente sin COMMIT. La validación pesada se delega a ue_grabar.

3.3. Fragmento de Código Clave (Validación) Control de Concurrencia: Intentar bloquear el documento origen iuo_context.of_sql_embedded_context(ts_transaccion, gd_cempresa) SELECT 1 INTO :li_dummy FROM MAE_RECEPCION_PEDIDOS WHERE CODIGO_RECEPCION = :ld_codigo_documento_actual FOR UPDATE NOWAIT USING ts_transaccion; If ts_transaccion.SQLDBCode = 54 Then ORA-00054: recurso ocupado

  MessageBox("Aviso de Concurrencia", "El documento ...", Exclamation!)
  Rollback Using ts_transaccion;
  Return

End If