Diferencias

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

--- ada:sicoferp:financiero:tesoreria:conciliacionbancaria:conciliacioncargadedatos [2026/04/20 12:31]
brahian.castaneda
+++ ada:sicoferp:financiero:tesoreria:conciliacionbancaria:conciliacioncargadedatos [2026/06/12 12:47] (actual)
brahian.castaneda
@@ Línea 1: / Línea 1: @@
 ====== Conciliación (Carga de Datos) ======
@@ Línea 159: / Línea 162: @@
 ===== Optimización y Corrección del Proceso de Conciliación Bancaria =====
+Bug ID: [#53442]
 === 1. Descripción del Problema ===
@@ Línea 247: / Línea 252: @@
 				    OR MC.CODIGO_CONCILIACION = :id_cconciliacion
 				)
+	USING sqlca;
+===== Optimización del Proceso de Persistencia en Conciliación Bancaria =====
+=== 1. Descripción del Problema ===
+Se identificaron tres comportamientos anómalos en el objeto w_conciliacion_bancos:
+Pérdida de datos: Al guardar una conciliación como "Completa", los registros de extracto en las pestañas de inconsistencias desaparecían al consultar nuevamente.
+Desmarcado inter-mensual: Movimientos conciliados en meses anteriores (ej. Marzo) se desmarcaban o eliminaban al procesar el mes siguiente (ej. Abril).
+Inconsistencia de Estados: El sistema permitía marcar conciliaciones como "Completas" (Estado 'C') sin que todos los movimientos estuvieran efectivamente cruzados o marcados como partidas conciliatorias.
+=== 2. Análisis de Causas Raíz ===
+Colisión de Actualización (Update Stack): El evento ue_grabar ejecutaba .Update() sobre cuatro DataWindows distintos que apuntan a la misma tabla (TESORE01.DATOS_CONCILIACION). Al no estar sincronizados por ShareData, el buffer de un DataWindow sobreescribía o eliminaba los cambios del anterior.
+Lógica de Limpieza Agresiva: La función wf_puede_guardar ejecutaba un DELETE basado en comparaciones de cadenas para el periodo. Si la conciliación actual no se había persistido totalmente en la transacción, el NOT EXISTS la detectaba como huérfana y borraba el extracto recién importado.
+Falta de Exclusión Explícita: El SQL de limpieza no excluía el ID de la conciliación activa (id_cconciliacion), afectando registros de otros meses que compartían criterios de búsqueda por error de precisión.
+=== 3. Cambios Realizados ===
+A. Refactorización de ue_grabar
+Se modificó la secuencia de grabación para garantizar la integridad transaccional:
+Unificación de Update: Se eliminaron las llamadas a .Update() de los DataWindows filtrados (dw_datos_coincidentes y dw_datos_incoincidentes). Ahora, dw_datos_conciliacion actúa como la única fuente de verdad para la tabla de extractos.
+Gestión de Flags: Se implementó Update(True, False) seguido de un ResetUpdate() manual únicamente después de que el motor de base de datos confirma el éxito de la operación, evitando que los DataWindows pierdan el estado de "modificado" antes de tiempo.
+B. Optimización de wf_puede_guardar
+Se rediseñó el SQL embebido para mayor seguridad:
+Comparación Numérica: Se cambió la concatenación de strings por comparaciones de TO_NUMBER(SUBSTR...) para los campos ANO y PERIODO, mejorando el rendimiento y la precisión del índice.
+Exclusión de la Conciliación Activa: Se añadió la cláusula AND D.CODIGO_CONCILIACION <> :id_cconciliacion. Esto garantiza que los registros que se están procesando actualmente nunca sean tocados por el proceso de limpieza de registros huérfanos.
+Depuración de Esquema: Se eliminó el UPDATE a la tabla DET_ASIENTO_CONTABLE, ya que se validó que las columnas CONCILIADO y PERIODO_CONCILIADO no existen en dicha tabla según el estándar del diccionario de datos.
+C. Validación de Estado 'Completo'
+Se ajustó la lógica de asignación del estado:
+El estado 'C' ahora requiere estrictamente que no existan filas con conciliado = 0 que no estén marcadas explícitamente como conciliatoria = 'S'.
+=== 4. Impacto y Verificación ===
+Verificación: Al realizar Retrieve después de grabar, los conteos de filas deben permanecer idénticos a los del momento previo a la grabación.
+Integridad: Los registros de meses anteriores quedan protegidos gracias al filtro por codigo_conciliacion en la lógica de borrado de la función wf_puede_guardar.
+=== Cambios realizados ===
+== Cambio en función wf_puede_guardar ==
+	guo_app.of_sql_embedded_context( sqlca )
+	UPDATE  TESORE01.DATOS_CONCILIACION D
+	SET CONCILIADO = 0, FECHA_CONCILADO = NULL
+		WHERE     D.CODIGO_BANCO = :ld_cod_inter_banco
+				AND D.ANO IS NOT NULL
+				AND D.PERIODO IS NOT NULL
+				AND D.ANO||(CASE WHEN D.PERIODO < 10 THEN '0'||TO_CHAR(D.PERIODO) ELSE TO_CHAR(D.PERIODO) END) = :ls_periodo
+				AND D.CODIGO_CONCILIACION <> :id_cconciliacion
+				AND NOT EXISTS
+						  (SELECT 1
+							  FROM TESORE01.MAE_CONCILIACION MC
+							 WHERE     MC.CODIGO_BANCO = D.CODIGO_BANCO
+									 AND MC.CODIGO_CONCILIACION = D.CODIGO_CONCILIACION
+									 AND MC.PERIODO = D.ANO||(CASE WHEN D.PERIODO < 10 THEN '0'||TO_CHAR(D.PERIODO) ELSE TO_CHAR(D.PERIODO) END)
+									 AND MC.ESTADO NOT IN ('E')
+						  )
+	USING sqlca;
+	guo_app.of_sql_embedded_context( sqlca )
+	UPDATE PRESUP01.DET_ASIENTO_CONTABLE DAC
+	SET DAC.CONCILIADO = 0,
+	    DAC.PERIODO_CONCILIADO = NULL
+	 WHERE DAC.OTROS = :ld_cod_inter_banco
+	   AND DAC.PERIODO_CONCILIADO = :ls_periodo
+	   AND NOT EXISTS
+				(SELECT 1
+				   FROM TESORE01.MAE_CONCILIACION MC
+				  WHERE MC.CODIGO_BANCO = :ld_cod_inter_banco
+				    AND MC.PERIODO = :ls_periodo
+				    AND MC.ESTADO <> 'E'
+				    OR MC.CODIGO_CONCILIACION = :id_cconciliacion
+				)
 	USING sqlca;
+== Cambio en evento ue_cierra_lista_elementos ==
+	guo_app.of_sql_embedded_context( sqlca )
+		UPDATE TESORE01.DATOS_CONCILIACION
+			SET FECHA_CONCILADO = NULL, CONCILIADO = 0,
+			CONCILIATORIA = 'N', CODIGO_USUARIO_CONCILIA = 0
+		WHERE  CODIGO_CONCILIACION = :id_cconciliacion
+		AND CODIGO_BANCO = :il_banco
+		using sqlca;
+=== Desarrollado por: [Miguel Muñoz] Fecha: [28/04/2026] Versión de PB: 12.5 ===
+===== Optimización en la Conciliación Bancaria - Estado "Completa" (w_conciliacion_bancos.srw) =====
+Fecha: 2024-05-28 Autor: Gemini Code Assist (asistente de desarrollo) Componente Afectado: w_conciliacion_bancos.srw (Ventana de Conciliación Bancaria) Versión de PowerBuilder: 12.5
+=== 1. Descripción del Problema Original ===
+El proceso de conciliación bancaria presentaba un comportamiento incorrecto:
+Una conciliación no se marcaba automáticamente como "Completa" (estado = 'C') cuando no existían movimientos para conciliar (es decir, ni registros del extracto bancario ni movimientos manuales).
+Incluso si se lograba un estado inicial de 'C', la lógica posterior podía revertir el estado a "Incompleta" (estado = 'I') si no se detectaban registros marcados como conciliados, lo cual ocurría en escenarios sin movimientos. Este comportamiento afectaba la correcta gestión y el cierre de los periodos de conciliación, obligando a intervenciones manuales o dejando conciliaciones vacías en estado "Incompleta".
+=== 2. Causas Raíz Identificadas ===
+Se identificaron dos causas principales que contribuían al problema:
+Bloqueo por il_rows_import: El evento ue_grabar de la ventana w_conciliacion_bancos.srw contenía una condición If il_rows_import > 0 Then al inicio del proceso de guardado. Si no se había importado un archivo de extracto (y por ende il_rows_import era 0), toda la lógica de determinación del estado y guardado de la conciliación se omitía, resultando en un MessageBox de advertencia y un estado incorrecto. Esto impedía que conciliaciones sin movimientos de extracto pudieran ser finalizadas como "Completas".
+Reversión Incondicional del Estado a 'I': Existía un bloque de código que, tras evaluar los totales de las DataWindows, verificaba si había algún movimiento marcado como conciliado (conciliado = 1 o conciliatoria = 'S'). Si no encontraba ninguno en ninguna de las DataWindows de movimientos, revertía el estado de la conciliación a 'I', incluso si no había movimientos que conciliar en primer lugar (lo que se consideraría una conciliación completa por ausencia de elementos).
+=== 3. Solución Implementada ===
+Se modificó el evento ue_grabar en w_conciliacion_bancos.srw para abordar las causas identificadas:
+Introducción de lb_any_movements_loaded: Se agregó una nueva variable booleana, lb_any_movements_loaded, que verifica si existe cualquier movimiento (ya sea de tesorería o de extracto, coincidente o incoincidente) cargado en las DataWindows de conciliación. Esta verificación es más robusta que il_rows_import.
+Lógica de Determinación de Estado Condicional:
+Si lb_any_movements_loaded es False (es decir, no hay movimientos en absoluto para conciliar), el estado ls_estado se establece directamente como 'C' (Completa). Esto permite que las conciliaciones "vacías" se marquen correctamente como completas.
+Si lb_any_movements_loaded es True (hay movimientos), se ejecuta la lógica existente de comparación de totales y verificación de conciliación para determinar si el estado debe ser 'C' o 'I'.
+Eliminación del Bloqueo por il_rows_import: La condición If il_rows_import > 0 Then que encapsulaba gran parte de la lógica de guardado fue eliminada. Esto asegura que el proceso de guardado y determinación del estado siempre se ejecute, independientemente de si se importó un archivo de extracto.
+Remoción del Bloque de Reversión Incondicional: El segmento de código que revertía el estado a 'I' si no se encontraban elementos conciliados fue comentado y efectivamente eliminado. Con la nueva lógica, la determinación del estado ('C' o 'I') ya se realiza de forma anticipada y precisa, haciendo este bloque redundante y perjudicial.
+=== Desarrollado por: [Miguel Muñoz] Fecha: [12/05/2026] Versión de PB: 12.5 ===
+===== Mejora en Conciliación Bancaria Manual =====
+=== 1. Descripción General ===
+Se ha optimizado el proceso de conciliación bancaria manual en el objeto w_conciliacion_bancos. El cambio permite que el sistema cargue automáticamente las partidas conciliatorias (pendientes) del mes anterior sin necesidad de importar un archivo plano físico.
+Anteriormente, cuando un periodo no tenía movimientos nuevos en libros ni en bancos, el sistema obligaba al usuario a cargar un archivo plano con valores en "cero" para poder visualizar y conciliar los saldos pendientes del mes anterior.
+=== 2. Problema Técnico ====
+La lógica que recuperaba los registros pendientes de la tabla MAE_CONCILIACION (donde conciliatoria = 'S') estaba encapsulada dentro de la función de importación dinámica de archivos. Si el usuario seleccionaba el modo Manual, esa ruta de código nunca se ejecutaba, resultando en una grilla de inconsistencias vacía a pesar de existir saldos por conciliar del periodo previo.
+=== 3. Solución Implementada ===
+.1. Nueva Función: wf_cargar_partidas_pendientes()
+Se creó una función centralizada en la ventana para:
+Identificar el periodo anterior (manejo de cambio de año en enero).
+Consultar el código de conciliación del mes anterior en estado 'C' (Completada).
+Recuperar los registros mediante el DataStore d_incoincidentes_extracto_ant.
+Insertar dichos registros en el buffer de trabajo idw_datos_conciliacion del periodo actual.
+.2. Cambio de Disparador (Trigger)
+En lugar de depender del botón "Importar", la lógica ahora reside en el evento selectionchanged del control carpeta (Tab Control):
+Momento de ejecución: Cuando el usuario hace clic en la pestaña 3 (Inconsistencias).
+Condición de ejecución: Solo si el modo de conciliación es 'M' (Manual) y si aún no existen registros cargados en la base de datos para el periodo actual (SELECT COUNT preventivo).
+Acción: Carga los pendientes, realiza un Update() automático a la base de datos y ejecuta el motor de conciliación (wf_conciliar_faltante) para cruzar los datos contra los libros contables.
+.3. Mejoras en la Interfaz de Usuario (UI)
+Cierre de Ventana Manual: Se modificó el evento clicked del DataWindow dw_datos_conciliacion para que los botones de "Cancelar" o "Cerrar" oculten correctamente el panel de captura, permitiendo al usuario retractarse sin quedar bloqueado.
+Sincronización: Se añadieron comandos Retrieve explícitos al cambiar a la pestaña de Inconsistencias para asegurar que la grilla siempre refleje los datos guardados.
+=== 4. Impacto y Beneficios ===
+Eliminación de Procesos Manuales Externos: El usuario ya no debe crear archivos Excel/planos ficticios con valores en cero.
+Integridad de Datos: Al automatizar la carga de pendientes al cambiar de pestaña, se reduce el riesgo humano de omitir saldos del mes anterior.
+Eficiencia: El motor de conciliación automática ahora también procesa las partidas manuales apenas el usuario intenta ver los resultados.
+=== Desarrollado por: [Miguel Muñoz] Fecha: [12/06/2026] Versión de PB: 12.5 ===

Wiki

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página