01. DATOS GENERALES
Producto | TOTVS Backoffice | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Línea de producto: | Línea Protheus | ||||||||||||||||||||||||
Segmento: | Backoffice | ||||||||||||||||||||||||
Módulo: | SIGAFIN - Financiero | ||||||||||||||||||||||||
Función: |
| ||||||||||||||||||||||||
País: | Todos | ||||||||||||||||||||||||
Ticket: | N/A | ||||||||||||||||||||||||
Requisito/Story/Issue (informe el requisito vinculado): | DMINA-21171 |
02. SITUACIÓN/REQUISITO
Es necesario actualizar la secuencia con la que se ejecutan los disparadores, when y reglas de dependencia al modelo. De esta manera, se logrará una mejora en el rendimiento y la lógica se ejecutará de acuerdo a la lógica del framework.
03. SOLUCIÓN
Se realizaron cambios en los siguientes fuentes para mejorar el rendimiento:
- En el fuente Modelo genérico de Totvs Recibo (FINA887.PRW): En el When del campo Tipo de Crédito (EL_TPCRED), se eliminó un loadvalue vacío que generaba conflictos con la validación (X3_VALID) del mismo campo, resultando en errores al cargar formas de pago tipo CD.
- En el fuente Modelo para Argentina en Totvs Recibo (FINA887ARG.PRW): Se eliminaron reglas de dependencia que ya no eran necesarias debido a la actualización.
- En el fuente Modelo para Argentina en Totvs Recibo (FINA887MEX.PRW): Se eliminaron reglas de dependencia innecesarias gracias a la actualización.
- En el fuente Modelo para Argentina en Totvs Recibo (FINA887PAR.PRW): Se eliminaron reglas de dependencia que ya no eran necesarias gracias a la actualización.
- En el fuente Modelo para Argentina en Totvs Recibo (FINA887PER.PRW): Se eliminaron reglas de dependencia innecesarias gracias a la actualización.
- En el servicio Formas de pago (PAYMENTFORM.SERVICE.TLPP): Se modificó la lógica de los when y disparadores en el modelo, donde el modelo ahora se encarga de verificar el cumplimiento de las reglas de dependencia, así como de los when y validaciones. Esto ha resultado en una mejora notable en el rendimiento del servicio.
- Realizar un respaldo del repositorio (RPO).
- Aplicar el parche correspondiente al issue DMINA-21170.
- Aplicar el paquete de expedición continua Financiero - Totvs Recibo MI con fecha de corte superior a este comunicado.
- Validar que las rutinas actualizadas en el repositorio, coincidan con las descritas en el encabezado del presente Documento Técnico.
- A través de la rutina “Productos”, ubicada en el módulo de SIGAFIN (Actualizaciones | Archivos), incluir un producto.
- A través de la rutina “Bancos”, ubicada en el módulo de SIGAFIN (Actualizaciones | Archivos), incluir un banco.
A través de la rutina “Clientes”, ubicada en el módulo de SIGAFIN (Actualizaciones | Archivos), incluir un cliente.
- A través de la rutina "Tipo de Entrada y Salida", ubicada en el módulo Facturación – SIGAFAT (Actualizaciones | Archivos), se debe tener una TES de salida configurada.
- A través de la rutina "Factura de Venta", ubicada en el módulo Facturación – SIGAFAT (Actualizaciones | Movimientos), capturamos una Factura para el Cliente con el producto y la TES previamente configurada.
Aviso
La siguiente configuración es solamente un ejemplo para verificar el correcto funcionamiento de la solución, no es necesario configurarlo.
CONFIGURACIÓN PARA PRUEBA DEL WHEN (SEL - RECIBOS DE COBRANZA)
- Por medio del Módulo Configurador (SIGACFG) :
- Crear el campo con las siguientes características:
- Sección campó
- Campo = EL_WHEN
- Tipo = 1-Caracter
- Tamaño = 5
- Formato = @!
- Contexto = 1 - Si
- Propiedad = 1 - Modificar
- Sección informaciones
- Tit. Español = Campo when
- Desc. Español = Campos que se activa si se cumple el when
- Sección Opciones
- Inic. Estándar = ""
Modo Edición = U_WHENRET()
Importante
En el campo Modo Edición (X3_WHEN) puede ser ejecutada una función de usuario (Cómo se observa en el punto 2) o configurar directamente una condición lógica que retorne un valor booleano desde el Modo Edición del campo.
Ejemplo de Función de usuario y condición lógica desde el módulo configurador:
- b.
Ambos ejemplos retornan un valor booleano, el cual indica (.T.) si se activa el campo, ya que la condición se cumple o de lo contrario el campo permanece bloqueado (.F.)
Pueden ser mezclados campos de diferentes tablas.
Puede hacerse uso de validaciones, reglas de dependencia, disparadores y condiciones "when" en las formas de pago (SEL) utilizando campos de la tabla Encabezado de recibo (FJT), como se ilustra en el siguiente ejemplo:
En el campo Prefijo (EL_PREFIXO), se configura la siguiente regla en el campo Modo Edición (X3_WHEN):
IIF(!VAZIO(FwFldGet("FJT_COBRAD")),.T.,.F.)
. Esta regla indica que se activará solo si se ha informado el campo Cobrador (FJT_COBRAD) en el encabezado.
- Sección Uso
- Usado (x)
- Browse (x)
- Sección campó
- Crear el campo con las siguientes características:
- Compilar la siguiente función de usuario:
- Esta función tiene la funcionalidad de determinar si se bloquea o no un campo dependiendo el valor del campo Tipo Documento (EL_TIPODOC).
CONFIGURACIÓN PARA PRUEBA DE REGLAS DE DEPENDENCIA (SEL - RECIBOS DE COBRANZA)
- Por medio del Módulo Configurador (SIGACFG):
- Crear el campo (Contra dominio) con las siguientes características:
- Sección campó
- Campo = EL_DEPEN
- Tipo = 1-Caracter
- Tamaño = 5
- Formato = @!
- Contexto = 1 - Si
- Propiedad = 1 - Modificar
- Sección informaciones
- Tit. Español = DEPENDENCIA
- Desc. Español = Campos que se activa si se cumple la regla de dependencia
- Sección Opciones
- Inic. Estándar =""
- Sección Uso
- Usado (x)
- Browse (x)
- Sección campó
- Crear el campo (Contra dominio) con las siguientes características:
- Realizamos la configuración del campo (Dominio) Valor (EL_VALOR):
- Editamos la pestaña Reglas de dependencia (XXA):
- Secuencia = 501
- Contra dominio = EL_DEPEN
- Tipo = 3 - Pre y Post validación (Para más información, consulte el siguiente link: XXA - Reglas de Dependencia entre Campos)
- Editamos la pestaña Reglas de dependencia (XXA):
Se realiza la captura de un recibo de cobro en TOTVS Recibo (SIGAFIN >> Movimientos | Cuentas por Cobrar | TOTVS Recibo)
- Se ingresa a la opción de "Nuevo recibo".
- Capturar los datos del encabezado.
- Cliente: Indicar el cliente configurado en la sección Pre-condiciones.
- Seleccionar la Factura de Venta generada en la sección Pre-condiciones.
PRUEBA DEL WHEN
- Agregar una forma de pago por un valor parcial al valor total de la Factura de venta, seleccionando una forma de pago tipo Retención IVA:
- Verificar que el campo "Campo When" (EL_WHEN) se active solamente si se cumple la regla configurada (Si se selecciona una retención) en la función de usuario o en el módulo configurador.
- Llenar los campos marcados como obligatorios.
- Confirmar la forma de pago y guardar el recibo.
PRUEBA DE LA REGLA DE DEPENDENCIA
- Agregar una forma de pago por un valor parcial al valor total de la Factura de venta, seleccionando una forma de pago tipo Retención IVA:
- Verificar que el campo "Dependencia" (EL_DEPEN) se active solamente si el campo Valor (EL_VALOR) tiene algún valor, de lo contrario permanecerá bloqueado.
- Llenar los campos marcados como obligatorios.
- Confirmar la forma de pago y guardar el recibo.permanecerá
IMPORTANTE
Pueden ser mezcladas reglas de dependencia con when, por ejemplo:
- Se puede configurar un campo B (Contra dominio) que tenga una regla de dependencia de campo A (Dominio) pero a su vez el campo B tenga un WHEN (X3_WHEN) en donde indica que el campo Tipo Valor (EL_TIPODOC) retorne true solamente cuando se seleccione una forma de pago de tipo Efectivo. En este caso, el campo B solamente se activará cuando las combinaciones de estas dos condiciones sea verdadera (En caso de que él contra dominio tenga una validación (X3_VALID) está también tiene que ser validada y retornar un valor verdadero).
04. INFORMACIÓN ADICIONAL
La presente solución aplica para versión 12.1.33 o superior, disponible en el último parche de la expedición continua disponible igual o después de la fecha de este documento.¡IMPORTANTE!