Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anterior Revisión previa | |||
|
ada:sicoferp:financiero:presupuesto:ordenesdepago:consulta [2023/01/02 18:22] 192.168.177.20 |
ada:sicoferp:financiero:presupuesto:ordenesdepago:consulta [2026/04/22 19:35] (actual) brahian.castaneda |
||
|---|---|---|---|
| Línea 37: | Línea 37: | ||
| {{:ada:sicoferp:financiero:presupuesto:ordenesdepago:foto_2_para_la_wiki.png?nolink&400|}} | {{:ada:sicoferp:financiero:presupuesto:ordenesdepago:foto_2_para_la_wiki.png?nolink&400|}} | ||
| - | * Este documento muestra la identificación de la reserva a la que pertenece encima del titulo de orden de pago. | + | * Este documento muestra la identificación de la reserva a la que pertenece encima del titulo de orden de pago. |
| + | |||
| + | ===== Ajuste Formato Orden de Pago Isvimed - Firmas Multimódulo ===== | ||
| + | |||
| + | === 1. Descripción del Problema === | ||
| + | |||
| + | Se detectó que en el formato de Orden de Pago para el cliente Isvimed, la firma y los datos del usuario en la sección "Contabilizó" (y ocasionalmente "Revisó/Elaboró") no se visualizaban cuando la orden era procesada desde la interfaz de Tesorería. | ||
| + | |||
| + | === 2. Causa Raíz === | ||
| + | |||
| + | La consulta SQL del reporte (r_orden_pago_isvimed.srd) tenía una dependencia estricta con el código de aplicación 1 (Presupuesto). Los usuarios creados o activos en el módulo de Tesorería poseen códigos de aplicación distintos, lo que causaba que las subconsultas de firmas y las funciones de nombres devolvieran valores nulos al no encontrar coincidencia con la aplicación 1. | ||
| + | |||
| + | === 3. Solución Aplicada === | ||
| + | |||
| + | Se modificó la sentencia SQL del DataWindow para independizar la obtención de datos del usuario del módulo de aplicación: | ||
| + | |||
| + | Eliminación de Filtros: Se retiró la cláusula AND U.CODIGO_APLICACION = 1 de las subconsultas de imágenes de firma. | ||
| + | Join por Cédula: Se implementó una lógica de búsqueda basada en el CODIGO_USUARIO (que es único por login) pero recuperando la información del tercero asociado a través de la CEDULA del maestro de usuarios. | ||
| + | Uso de Agregados/ROWNUM: Se incorporó MAX() y ROWNUM = 1 para prevenir errores de cardinalidad en caso de que un usuario exista en múltiples aplicaciones dentro de la tabla USUARIOS. | ||
| + | |||
| + | === 4. Archivos Modificados === | ||
| + | |||
| + | r_orden_pago_isvimed.srd: Actualización del SELECT principal y subconsultas. | ||
| + | Ajuste Sugerido en el Código | ||
| + | Para que el cambio sea efectivo y consistente en todas las firmas (Elaboró, Revisó, Contabilizó), te sugiero aplicar este diff al archivo .srd: | ||
| + | |||
| + | r_orden_pago_isvimed.srd | ||
| + | |||
| + | E.NOMBRE AS NOM_USR_APR, | ||
| + | E.CEDULA AS CED_USR_APR , | ||
| + | PRESUP01.F_NOMBRE_USUARIO(PRESUP01.F_USUARIO_CONTABILIDAD(:cod_orden_pago)) AS NOM_USR_REV, | ||
| + | PRESUP01.F_CEDULA_USUARIO(PRESUP01.F_USUARIO_CONTABILIDAD(:cod_orden_pago)) AS CED_USR_REV, | ||
| + | (SELECT MAX(M.NOMBRE) FROM USUARIOS U INNER JOIN MAESTRO_TERCEROS M ON U.CEDULA=TRUNC(M.NIT,0) WHERE U.CODIGO_USUARIO=PRESUP01.F_USUARIO_CONTABILIDAD(:cod_orden_pago)) AS NOM_USR_REV, | ||
| + | (SELECT MAX(U.CEDULA) FROM USUARIOS U WHERE U.CODIGO_USUARIO=PRESUP01.F_USUARIO_CONTABILIDAD(:cod_orden_pago)) AS CED_USR_REV, | ||
| + | (SELECT MAX(M.NOMBRE) FROM USUARIOS U INNER JOIN MAESTRO_TERCEROS M ON U.CEDULA=TRUNC(M.NIT,0) WHERE U.CODIGO_USUARIO=F.CODIGO_USUARIO_CAUSACION) AS NOM_USR_CONT, | ||
| + | (SELECT MAX(U.CEDULA) FROM USUARIOS U WHERE U.CODIGO_USUARIO=F.CODIGO_USUARIO_CAUSACION) AS CED_USR_CONT, | ||
| + | G.NUMERO_CUENTA, G.TIPO_CUENTA, G.BANCO, | ||
| + | A.CONSECUTIVO_EQUI, | ||
| + | |||
| + | === Desarrollado por: [Miguel Muñoz] Fecha: [22/04/2026] Versión de PB: 12.5 === | ||
| [[ada:sicoferp:financiero:presupuesto:ordenesdepago|←Volver atrás]] | [[ada:sicoferp:financiero:presupuesto:ordenesdepago|←Volver atrás]] | ||
| + | |||
| + | |||