Diferencias

Muestra las diferencias entre dos versiones de la página.

--- aada:sicoferp:financiero:presupuesto:contabilidad:envioderemisiondefacturasacontabilidad [2026/04/09 18:59]
brahian.castaneda
+++ aada:sicoferp:financiero:presupuesto:contabilidad:envioderemisiondefacturasacontabilidad [2026/05/06 19:45] (actual)
brahian.castaneda
@@ Línea 95: / Línea 95: @@
 w_facturas_causadas.srw: Ventana de selección que consume el DataWindow.
 w_remisiones_factura_ela.srw: Ventana principal de proceso
+===== Resolución de Incidente: Remisiones de facturas sin detalle en pantalla de envío =====
+=== . Información General del Ticket ===
+Módulo / Ruta: Presupuesto / Compromisos / Envío de remisión de facturas a contabilidad.
+=== Falla Reportada: Remisiones de facturas sin facturas asociadas se siguen mostrando en la lista.   ===
+Impacto del Error: Las remisiones que quedaban registradas sin detalle de facturas no permitían ser enviadas, quedando bloqueadas en la pantalla de forma permanente (se evidenciaron registros estancados desde el año 2016).
+=== 2. Análisis del Problema ===
+En la ventana de Envío de remisión de facturas a contabilidad, la consulta principal estaba recuperando los registros directamente de la cabecera (MAESTRO_REMISION_FACTURA) basándose únicamente en los filtros de usuario, dependencia, fechas y estado. No existía una condición que verificara la integridad frente a la tabla de detalle (DET_REMISION_FACTURA).
+Aunque la solución esperada por la mesa de servicios sugería que el sistema "elimine" estas remisiones, a nivel de arquitectura y bases de datos es más seguro y eficiente modificar la capa de consulta para omitir estos registros huérfanos, protegiendo así la integridad referencial y el historial de la base de datos en Oracle.
+=== 3. Solución Técnica Implementada (Desarrollo) ===
+Se modificó la consulta principal SQL (Oracle 11g) del módulo. Para evitar la duplicidad de registros que generaría un INNER JOIN tradicional, se implementó una cláusula EXISTS en el bloque WHERE.
+Esta validación funciona como un semi-join, haciendo que el optimizador de Oracle evalúe si la remisión tiene al menos un registro en DET_REMISION_FACTURA. Si la remisión está vacía, simplemente se excluye del resultado que se muestra en pantalla.
+Fragmento del cambio en el código SQL:
+SQL
+-- (...) Consulta original
+WHERE
+    B.CODIGO = '08'
+    -- (...) Filtros de usuario y fechas
+    AND C.CODIGO_ESTADO = A.ESTADO
+    -- NUEVA VALIDACIÓN: Solo retorna la remisión si existe al menos un detalle asociado
+    AND EXISTS (
+        SELECT 1
+        FROM PRESUP01.DET_REMISION_FACTURA DRF_VAL
+        WHERE DRF_VAL.CODIGO_REMISION = A.CODIGO_REMISION
+    );
+=== Desarrollado por: [Miguel Muñoz] Fecha: [28/04/2026] Versión de PB: 12.5 ===

Wiki

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página