Wiki

Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.
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
Wiki

Herramientas de usuario

Herramientas del sitio

Herramientas de la página
