Wiki

Has cargado una revisión vieja del documento! Si la guardas crearás una versión nueva con estos datos.

====== Conciliación (Carga de Datos) ======

En esta ventana podemos subir al sistema la información que el banco nos ha suministrado de los movimientos realizados en nuestras cuentas, a través del archivo de extracto bancario.

Contiene tres pestañas:

===== Pestaña Bancos Conciliados =====

Seleccionando el un mes y un año, podemos visualizar los datos de identificación de los archivos de extractos bancarios actualmente existentes en el sistema,

Usando el botón Nuevo, podemos ingresar un archivo de extracto bancario al sistema

{{:ada:sicoferp:financiero:tesoreria:conciliacionbancaria:conciliacioncargardatos.png?400|}}

===== Pestaña Detalle del Banco =====

Sirve para incluir los datos de identificación el archivo de extracto bancario subido al sistema: Codigo de la cuenta, saldo inicial y final, período a conciliar, etc

{{:ada:sicoferp:financiero:tesoreria:conciliacionbancaria:datosextractobancario.png?400|}}

===== Pestaña Inconsistencias =====

Esta es la pestaña de trabajo de la conciliación bancaria, en ella podemos identificar claramente que partidas están actualmente conciliadas y cuáles faltan por conciliar, tanto de nuestro sistema como del extracto bancario.

{{:ada:sicoferp:financiero:tesoreria:conciliacionbancaria:2018-06-15_09h43_23.png?400|}}

Cuando se suben los datos de la conciliación de forma manual se puede agregar un NIT de terceros, para identificación posterior, en los reportes.

{{:ada:sicoferp:financiero:tesoreria:conciliacionbancaria:conciliacion_manual_terceros_001.png?600|}}

==== Notas del proceso ====

- Cuando el mes de la anulación sea mayor al mes del documento, y ambos meses sean menores o iguales al mes a conciliar entonces se muestren ambos documentos.

- Los datos del extracto de la conciliación bancaria puede incluir terceros; en este momento, solamente se puede agregar terceros cuando se ingresan manualmente los datos de información del extracto.

- Las partidas conciliatorias se pueden conciliar así sean de meses anteriores.

- Se modifica la validación de errores al importar archivo de conciliacion bancaria, para que en caso de no tener ningúna linea con la estructura, el sistema posterior a esto no debe sacar error, y posterior a esto, traer las partidas conciliatoras del mes anterior.

===== Corrección de Estado en Conciliación Bancaria =====
1. Descripción del Problema
Se detectó un comportamiento inconsistente en la ventana w_conciliacion_bancos. Al realizar una conciliación (ya sea manual o por importación) que resultaba en un cuadre perfecto en la primera transacción, el sistema asignaba erróneamente el estado "Incompleto" (I) en lugar de "Completado" (C).

Para corregir esto, el usuario debía:
Salir de la conciliación.
Volver a entrar al registro.
Realizar un cambio manual trivial (desmarcar y marcar algo) para que el sistema recalculara el estado a "Completado".

== 2. Causa Raíz (Análisis Técnico) ==
Desincronización de Buffers: El código realizaba validaciones de totales antes de ejecutar AcceptText(), lo que causaba que el motor de PowerBuilder evaluara valores antiguos en los campos calculados del DataWindow.
Campos Calculados no Refrescados: Al usar grupos y totales en el pie del DataWindow, estos no siempre se recalculan inmediatamente. Se requería una llamada explícita a GroupCalc().
Lógica de Estado Fragmentada: El evento ue_grabar contenía múltiples bloques IF y bucles FOR redundantes para evaluar si la conciliación estaba completa. Si el flujo de importación automática terminaba el proceso, estos bloques no siempre se ejecutaban en el orden correcto o con los datos frescos.

== 3. Solución Implementada ==
Se reestructuró el evento ue_grabar bajo los siguientes pilares:

Sincronización Total: Se agregaron llamadas a AcceptText() y GroupCalc() para todos los DataWindows involucrados (idw_det_bancos, idw_coincidentes, idw_incoincidentes, etc.) al inicio del evento.

Unificación de la Lógica de Estado:

Se reemplazaron los bucles manuales por una función .Find() de alto rendimiento que busca registros pendientes (conciliado = 0) que no sean partidas conciliatorias.

Aseguramiento de Transacción: 
Se garantiza que el cambio de estado a 'C' ocurra dentro del mismo bloque atómico antes del Update() y el COMMIT.

4. Cambios en el Código (w_conciliacion_bancos.srw)
A continuación se detalla el cambio realizado en el evento ue_grabar:

// Si no hay registros pendientes (conciliado=0) que NO sean partidas conciliatorias, 
// el estado es Completo ('C'), de lo contrario es Incompleto ('I')

If idw_datos_incoincidentes.Find('conciliado = 0 AND conciliatoria = "N"', 1, idw_datos_incoincidentes.RowCount()) = 0 AND &
   idw_incoincidentes.Find('conciliado = 0', 1, idw_incoincidentes.RowCount()) = 0 Then
    ls_estado = 'C'
Else
    ls_estado = 'I'
End If

idw_det_bancos.SetItem(1, "estado", ls_estado)

===== Corrección del Proceso de Eliminación de Conciliaciones =====

=== 1. Resumen del Problema ===

Módulo: Tesorería / Conciliación Bancaria.

Bug ID: [#53269]

Descripción: El sistema no permitía eliminar conciliaciones en estado "Incompleto" ('I'). Aunque el usuario ingresaba la descripción de eliminación y guardaba, el registro persistía en la base de datos con su estado original. Además

=== 2. Análisis de Causa Raíz ===

Se identificaron tres factores técnicos que provocaban el fallo:

Sobreescritura de Estado en Memoria: El evento ue_grabar de la ventana w_conciliacion_bancos recalculaba el estado de la conciliación basándose en los registros pendientes. Este cálculo ignoraba si el usuario había marcado el registro como "Eliminado" ('E'), sobreescribiendo el cambio justo antes de enviar los datos a la DB.
Persistencia de Buffers: La ventana de descripción no limpiaba los campos al inicializarse, mostrando datos residuales de sesiones previas.

=== 3. Cambios Realizados ===

B. Lógica de la Ventana (w_conciliacion_bancos.srw)
Evento ue_grabar
Se añadió una condicional para evitar que la lógica de cálculo automático de estado (Incompleto/Completo) se ejecute cuando el proceso actual es una eliminación.

// Solo recalcular estado si NO es una eliminación
	If lista_elementos <> 'eliminar_conciliacion' Then
		If idw_datos_incoincidentes.Find('conciliado = 0 AND conciliatoria = "N"', 1, idw_datos_incoincidentes.RowCount()) = 0 AND &
		   idw_incoincidentes.Find('conciliado = 0', 1, idw_incoincidentes.RowCount()) = 0 Then
			ls_estado = 'C'
		Else
			ls_estado = 'I'
		End If
		
		idw_det_bancos.SetItem(1, "estado", ls_estado)
		idw_det_bancos.accepttext( )
	End If

===== Estándar de Persistencia y Manejo de Transacciones (Appeon) =====

=== 1. Contexto ===

En aplicaciones desplegadas bajo la arquitectura Appeon PowerServer, el manejo de sesiones de base de datos es dinámico. Para garantizar que las operaciones de actualización (Update) y el SQL embebido se ejecuten dentro de la transacción correcta y no queden "colgadas" o se confirmen accidentalmente por otros procesos, es obligatorio sincronizar el contexto transaccional.

=== 2. Definición: of_sql_embedded_context ===

Esta función de objeto de usuario global (guo_app) establece el manejador de la base de datos para las sentencias que siguen en el script. Actúa como un "puente" que le dice al servidor de aplicaciones: "Todo lo que viene a continuación debe viajar por este túnel transaccional específico".

=== 3. Directriz de Implementación ===

Se establece como estándar obligatorio invocar la sentencia antes de cualquier operación de persistencia de DataWindows o DataStores que utilice objetos de transacción distintos a ts_transaccion o cuando se requiera asegurar la integridad en procesos críticos (como Conciliación Bancaria).

Patrón de Código Sugerido
Fragmento de código
// 1. Sincronizar el contexto antes de la persistencia
guo_app.of_sql_embedded_context(ts_transaccion)

// 2. Ejecutar la actualización con control de flags (Recomendado para visualización previa)
IF idw_datos_conciliacion.Update(True, False) = 1 THEN
    // La operación fue exitosa en el contexto de ts_transaccion
    // NOTA: El COMMIT se debe realizar solo cuando el usuario confirme la acción final
ELSE
    // En caso de error, limpiar el contexto inmediatamente
    ROLLBACK USING ts_transaccion;
    MessageBox("Error", "Falla al actualizar el contexto de datos.")
END IF

=== 4. Problemas que resuelve esta implementación ===
Aislamiento de Transacciones: Evita que un COMMIT en una ventana B confirme datos cargados erróneamente en la ventana A (Conciliación).

Compatibilidad Appeon: Corrige errores donde el servidor de aplicaciones pierde el rastro de la transacción activa tras procesos largos de importación.

Integridad en el "Deshacer": Al estar el contexto correctamente mapeado, un ROLLBACK USING ts_transaccion limpiará efectivamente todas las inserciones temporales realizadas por las funciones de importación (wf_import_extracto, etc.).

Resumen de la edición

Wiki

Herramientas de usuario

Herramientas del sitio

Herramientas de la página