Muestra las diferencias entre dos versiones de la página.
| 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: | + | (Nota: El 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|}} | + | === 3. Fragmento 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 | ||