Herramientas de usuario

Herramientas del sitio


ada:sicoferp:compras:maestro_de_ubicaciones

Diferencias

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

Enlace a la vista de comparación

Ambos lados, revisión anterior Revisión previa
Próxima revisión
Revisión previa
ada:sicoferp:compras:maestro_de_ubicaciones [2019/06/07 14:26]
192.168.199.30
ada:sicoferp:compras:maestro_de_ubicaciones [2026/04/10 14:41] (actual)
brahian.castaneda
Línea 5: Línea 5:
 Se lista la siguiente información:​ Se lista la siguiente información:​
  
-Código+  * Código 
 +  * Descripción 
 +  * Dirección
  
-Descripción+{{:​ada:​sicoferp:​compras:​mubicaci1.jpg?​400|}}
  
-Dirección+Los datos básicos que se deben de ingresar por ubicación son:
  
  
 +  * Descripción
 +  * Dirección
 +  * Ubicación Principal
 +  * Borrado
  
-{{:​ada:​sicoferp:​compras:​mubicaci1.jpg?400|}}+{{:​ada:​sicoferp:​compras:​mubc2.jpg?400|}}
  
-Los datos básicos que se deben de ingresar por ubicacion son:+(NotaEl campo Cod.ubicación se llena automaticamente con el consecutivo SEQ_CONSECUTIVO_EXT_UBICACION)
  
-Cod Ubicación+===== Documentación de Ajuste Técnico: Módulo de Ubicaciones =====
  
-Descripción+=== 1.Identificación del ProblemaRuta:​ Compras > Maestros > Maestro Ubicaciones (w_mae_ubicaciones.srw). ===
  
-Dirección+Síntoma: El sistema permitía modificar campos (descripción,​ departamento,​ ciudad), reportaba "Datos guardados correctamente",​ pero los cambios no persistían en la base de datos tras cerrar y volver a abrir el módulo. 
 +Causa Raíz: Inconsistencia en el manejo de objetos de transacción. Se realizaba el SetTransObject con ts_transaccion , pero se ejecutaban comandos de control (COMMIT / ROLLBACK) utilizando el objeto SQLCA.  
 +Al no ser el mismo canal de comunicación,​ los cambios quedaban en un "​limbo"​ transaccional y se perdían al cerrar la conexión.
  
-Ubicación Principal+=== 2. Solución AplicadaSe reestructuró el evento ue_grabar bajo los siguientes pilares técnicos: ===
  
-Borrado+A. Unificación del Transaction ObjectSe migraron todas las sentencias SQL y controles de transacción para utilizar exclusivamente ts_transaccion.  
 +Esto garantiza que el Update() y el Commit viajen por el mismo túnel de comunicación. 
 +Antes: COMMIT Using SQLCA;  
 +Después: COMMIT Using ts_transaccion;​
  
 +B. Sincronización de Interfaz (Buffer)Se añadió una validación estricta al inicio del evento de grabado:​Fragmento de códigoIF idw_registro.AcceptText() <> 1 THEN Return
 +Esto asegura que el último dato digitado por el usuario (ej. la nueva descripción) sea validado y trasladado de la UI al buffer del DataWindow antes de iniciar el proceso de guardado.
 +C. Optimización del Ciclo de UpdateSe implementó el uso de Update(TRUE,​ FALSE) seguido de un ResetUpdate() manual tras el éxito del COMMIT.Propósito:​ Evita que el DataWindow limpie sus "​flags"​ de modificación prematuramente. Si el COMMIT falla, el usuario aún tiene los cambios en pantalla para reintentar sin perder su trabajo.
  
-{{:​ada:​sicoferp:​compras:​mubc2.jpg?400|}}+=== 3Fragmento de Código Corregido (Lógica Principal)Fragmento de código// Sincronizar buffer === 
 + 
 +IF idw_registro.AcceptText() <> 1 THEN Return  
 + 
 +// ... validaciones de departamento y ciudad  
 + 
 +// Actualización usando el objeto correcto 
 +IF idw_registro.Update(TRUE,​ FALSE) = 1 THEN 
 +    IF IsValid(idw_lista_ubicaciones) THEN 
 +        idw_lista_ubicaciones.Update(TRUE,​ FALSE) 
 +    END IF 
 +     
 +    COMMIT Using ts_transaccion;​ // Unificación de transacción 
 +     
 +    IF ts_transaccion.SQLCode = 0 THEN 
 +        idw_registro.ResetUpdate() 
 +        // Refrescar UI  
 +    ELSE 
 +        ROLLBACK Using ts_transaccion;​ 
 +    END IF 
 +ELSE 
 +    ROLLBACK Using ts_transaccion;​ 
 +END IF
ada/sicoferp/compras/maestro_de_ubicaciones.1559917577.txt.gz · Última modificación: 2019/06/07 14:26 por 192.168.199.30