Árvore de páginas

01. DATOS GENERALES


Producto

TOTVS Backoffice

Línea de producto: 

Línea Protheus

Segmento:

Backoffice

Módulo:SIGAFIN - Financiero
Función:
RutinaNombre TécnicoFecha
FINA887.PRWModelo genérico para todos los países en TOTVS recibo.07/11/2023
FINA887ARG.PRWModelo para Argentina en TOTVS recibo.01/11/2023
FINA887MEX.PRWModelo para México en TOTVS recibo.01/11/2023
FINA887PAR.PRWModelo para Paraguay en TOTVS recibo.01/11/2023
FINA887PER.PRWModelo para Perú en TOTVS recibo.01/11/2023
PAYMENTFORM.SERVICE.TLPPServicio de formas de pago.07/11/2023
FINA998.APPAplicativo TOTVS Recibo
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.


  1. Realizar un respaldo del repositorio (RPO).
  2. Aplicar el parche correspondiente al issue DMINA-21170.
  3. Aplicar el paquete de expedición continua Financiero - Totvs Recibo MI con fecha de corte superior a este comunicado.
  4. Validar que las rutinas actualizadas en el repositorio, coincidan con las descritas en el encabezado del presente Documento Técnico.
  5. A través de la rutina “Productos”, ubicada en el módulo de SIGAFIN (Actualizaciones | Archivos), incluir un producto.
  6. A través de la rutina “Bancos”, ubicada en el módulo de SIGAFIN (Actualizaciones | Archivos), incluir un banco.
  7. A través de la rutina “Clientes”, ubicada en el módulo de SIGAFIN (Actualizaciones | Archivos), incluir un cliente.

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

  1. Por medio del Módulo Configurador (SIGACFG) :
    1. Crear el campo con las siguientes características:
      1. Sección campó 
        1. Campo = EL_WHEN
        2. Tipo = 1-Caracter
        3. Tamaño = 5
        4. Formato = @!
        5. Contexto = 1 - Si
        6. Propiedad = 1 - Modificar
      2. Sección informaciones
        1. Tit. Español = Campo when
        2. Desc. Español = Campos que se activa si se cumple el when
      3. Sección Opciones
        1. Inic. Estándar = ""
        2. 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: 

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

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

      4. Sección Uso
        1. Usado (x)
        2. Browse (x)
  2. Compilar la siguiente función de usuario:
    1. 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)

  1. Por medio del Módulo Configurador (SIGACFG):
    1. Crear el campo (Contra dominio) con las siguientes características:
      1. Sección campó 
        1. Campo = EL_DEPEN
        2. Tipo = 1-Caracter
        3. Tamaño = 5
        4. Formato = @!
        5. Contexto = 1 - Si
        6. Propiedad = 1 - Modificar
      2. Sección informaciones
        1. Tit. Español = DEPENDENCIA
        2. Desc. Español = Campos que se activa si se cumple la regla de dependencia
      3. Sección Opciones
        1. Inic. Estándar =""  
      4. Sección Uso
        1. Usado (x)
        2. Browse (x)
  2. Realizamos la configuración del campo (Dominio) Valor (EL_VALOR):
    1. Editamos la pestaña Reglas de dependencia (XXA):
      1. Secuencia = 501
      2. Contra dominio = EL_DEPEN
      3. Tipo = 3 - Pre y Post validación (Para más información, consulte el siguiente link: XXA - Reglas de Dependencia entre Campos)

Se realiza la captura de un recibo de cobro en TOTVS Recibo (SIGAFIN >> Movimientos | Cuentas por Cobrar | TOTVS Recibo)

  1. Se ingresa a la opción de "Nuevo recibo".
  2. Capturar los datos del encabezado.
    1. Cliente: Indicar el cliente configurado en la sección Pre-condiciones.
  3. Seleccionar la Factura de Venta generada en la sección Pre-condiciones.

PRUEBA DEL WHEN

  1. 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:
    1. 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.
  2. Llenar los campos marcados como obligatorios.
  3. Confirmar la forma de pago y guardar el recibo.

PRUEBA DE LA REGLA DE DEPENDENCIA

  1. 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:
    1. 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.
  2. Llenar los campos marcados como obligatorios.
  3. 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

¡IMPORTANTE!

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.


05. ASUNTOS RELACIONADOS

  • TOTVS Recibo
  • XXA - Reglas de Dependencia entre Campos
  • 8 - Expedición Continua - TOTVS Recibo