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:

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

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

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.

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.

- 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.

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”.

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.

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)

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

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.

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

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.

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”.

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

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.).