Linha Microsiga Protheus - Espanhol

Atalhos

Árvore de páginas

Aumento de decimales en el entorno Facturación - SIGAFAT

Producto:

Microsiga Protheus

Ocurrencia:

Aumento de decimales o inconsistencias relacionadas con la modificación

Entorno:

SIGAFAT - Facturación


El aumento de decimales en el Protheus es un asunto delicado. Cuando se realiza sin los debidos criterios o no recibe el debido mantenimiento, puede causar diversas inconsistencias.


KCS: Cross Segmento - TOTVS Backoffice (Línea Protheus) - SIGAFAT - Decimales en la facturación


POSIBLES INCONSISTENCIAS


 

  • Se muestra un mensaje en el Pedido de ventas informando que...

Por tratarse de una Factura de devolución, el valor unitario debe ser igual al de la Factura de origen

(siendo que el valor mostrado en el Pedido está igual al valor mostrado en la Factura de entrada)

 

  • En el Pedido de venta (SC6)

Se informa en el ítem un Valor/Cant “x”, sin embargo, al Liberar / Preparar el documento de salida, este valor/cant se lleva “y” (SC9 / SD2)

 

  • Campos con contenidos diferentes, cuando deberían tener contenido idéntico

Ejemplo: B6_PRUNIT / D2_PRCVEN (precio de la venta) / D2_PRUNIT (precio unitario del producto)

Pudendo inclusive atribuir esta diferencia como descuento indebido en la Factura.

 

  • Avisos en la pantalla que impiden el proceso:

A410UNIDIF | A100VALOR | A410TOTAL |A415TOTAL



CONCEPCIÓN DE CAUSA


Estos comportamientos usualmente se encuentran en el entorno donde hubo aumento en el tamaño de campos o modificación en la configuración de decimales. Son causados debido a que algún campo relacionado a la Factura ha sido grabado con datos incompatibles (generalmente, debido a tamaños diferentes de campos o de decimales, es decir, diccionario/base de datos modificado sin la debida equiparación). Obs: Cuando digo "algún campo relacionado a la Factura" entiéndase que puede ser de cualquier Tabla, de diferentes módulos, que el cliente pueda haber implantado en su negocio y de alguna manera se relacionen, debido a que el sistema es integrado.

 

Es importante aclarar que dichas inconsistencias generalmente no se limitan exclusivamente al Pedido / Factura que se está registrando. Muchas veces se trata de otras Tablas que se utilizaron antes, ya que el sistema valida el historial y relaciones de los movimientos para la ejecución de cálculos y para mantener la integridad de los datos. Es decir, cuando el sistema realiza un cálculo, este va a pasar el valor de un campo X (C6_PRCVEN por ejemplo) por varios otros campos. Si no estuvieran todos estandarizados, conteniendo la misma cantidad y configuración de los datos, los últimos decimales se perderán, impactando de esta manera en el valor FINAL considerado y llevado al campo de destino.

Inclusive es posible que se identifique la inconsistencia después de la actualización, esto debido a que las correcciones se realizan en las validaciones y en los Fuentes actualizados. O también, debido a las Tablas y/o campos que se crearon e involucraron en el proceso desde la última actualización de su Base

 

IMPORTANTE: Cualquier tratamiento relacionado a decimales se considera un desvío del Nativo del Protheus (en el cual es estándar el uso de dos dígitos, solamente para el entorno de Facturación).
Por lo tanto, se indica que cualquier modificación en este sentido se realice y documente por un analista in loco (Consultar directamente a su ESN) para análisis puntual de su base/ escenario, inclusive para los mantenimientos de estas modificaciones en las Tablas (ya que con las actualizaciones pueden crearse nuevos campos y nuevas tablas en la base).

CÓMO SOLUCIONAR


1 - Identificar y ajustar todos los campos relacionados de tal manera que todos tengan configuración compatible para que no se pierdan los datos.

Es decir, todos los campos de cantidad deben tener el mismo tamaño/ máscara. Los campos de valor también deben tener el mismo tamaño/ máscara (sepa más aquí sobre el tamaño Límite decimales).

Con excepción de los campos de Valor total. EN LOS CAMPOS TOTALES NO SE MODIFICAN DECIMALES, estos deben permanecer con 2 casas decimales (evitando inclusive errores en archivos fiscales).

TOTVS no tiene un Documento específico para definición de todas las tablas/campos utilizados en su rutina, y consecuentemente, deben modificarse para mantener la integridad entre sus Tablas; pues se refiere a cada Cliente, puntualmente, de acuerdo con los módulos que están implantados, las rutinas que se utilizan, las tablas que son alimentadas y los campos que se utilizan. De esta manera, si realiza la implementación/ mantenimiento internamente con su equipo de TI, resaltamos la importancia de modificar todas las tablas/ campos utilizados en la integración de sus rutinas; para de no generar inconsistencia en su base de datos.

Podemos citar los campos más usuales PARA El MÓDULO FACTURACIÓN, y algunas de las integraciones más recurrentes (recomendamos que estén con el mismo tamaño del campo y con la misma cantidad de decimales de un campo para otro respectivamente)


SC6 - PEDIDOS DE VENTA: C6_QTDVEN, C6_QTDLIB, C6_QTDLIB2, C6_UNSVEN, C6_SLDALIB, C6_QTDENT, C6_QTDENT2, C6_PRUNIT, C6_PRCVEN, C6_QTDEMP, C6_QTDEMP2, C6_QTDRESE

SC9 - CANT LIBERADAS: C9_QTDLIB, C9_PRCVEN, C9_QTDRESE, C9_QTDLIB2

SD2 - FACTURAS DE SALIDA: D2_QUANT, D2_QTSEGUM, D2_PRCVEN, D2_PRUNIT, D2_QTDEDEV, D2_VALDEV, D2_QTDAFAT, D2_QTDEFAT

SD4 - RESERVAS: D4_QUANT, D4_QTDEORI, D4_QTSEGUM

SCK - PRESUPUESTOS: CK_QTDVEN, CK_PRCVEN, CK_PRUNIT, CK_VALDESC

ADB - CONTRATO DE ASOCIACIÓN: ADB_QUANT, ADB_PRCVEN, ADB_PRUNIT, ADB_UNSVEN, ADB_QTDENT, ADB_QTDEMP

DA1 - ÍTEMS DE LA LISTA DE PRECIOS: DA1_PRCBAS, DA1_PRCVEN, DA1_VLRDES

SC7- PEDIDO DE COMPRAS: C7_QUANT, C7_QTSEGUM, C7_QUJE, C7_QTDACLA, C7_PRECO

SC1 - SOLICITUDES: C1_QUANT, C1_QTSEGUM

SC8 - COTIZACIONES: C8_QUANT, C8_QTDCTR, C8_QTSEGUM, C8_PRECO

SD1 - FACTURAS DE ENTRADA: D1_QUANT, D1_QTSEGUM, D1_QTDPEDI, D1_QTDEDEV, D1_VALDEV, D1_VUNIT

SD3 - MOVIMIENTOS INTERNOS: D3_QUANT, D3_QTSEGUM, D3_PERDA

SB2 - SALDOS FÍSICOS Y FINANCIEROS: B2_QATU, B2_QFIM, B2_QEMPN, B2_QTSEGUM, B2_RESERVA, B2_QPEDVEN, B2_NAOCLAS, B2_QTNP, B2_QNPT, B2_QTER, B2_QFIM2, B2_QEMPN2, B2_RESERV2, B2_QPEDVE2, B2_QFIMFF, B2_VFIM1 / 2 / 3 / 4 / 5, B2_VATU1 / 2 / 3 / 4 / 5, B2_CM1 / 2 / 3 / 4 / 5.

SB6 - SALDOS PODER TERCEROS: B6_QUANT, B6_QTSEGUM, B6_QULIB, B6_PRUNIT, B6_SALDO

SB7 - INVENTARIO: B7_QUANT, B7_QTSEGUM

SB9 - SALDOS INICIALES: B9_QINI, B9_QISEGUM, B9_VINI1 / 2 / 3 / 4 / 5, B9_VINIFF1 / 2 / 3 / 4 / 5

SB8 - SALDOS POR LOTE: B8_QTDORI, B8_QEMPPRE, B8_SALDO, B8_SALDO2, B8_EMPENHO, B8_QACLASS, B8_QTDORI2, B8_EMPENH2, B8_QEPRE2, B8_QACLAS2

SBF - SALDOS POR UBICACIÓN: BF_QUANT, BF_EMPENHO, BF_QEMPPRE, BF_QTSEGUM, BF_EMPEN2, BF_QEPRE2

SBJ - SALDOS INICIALES POR LOTE: BJ_QINI, BJ_QISEGUM

SBK - SALDOS INICIALES POR UBICACIÓN: BK_QINI, BK_QISEGUM

SD5 - REQUERIMIENTOS POR LOTE : D5_QUANT, D5_QTSEGUM

SDD - BLOQUEO DE LOTES: DD_QUANT, DD_SALDO, DD_QTDORIG, DD_QTSEGUM, DD_SALDO2

SDB - MOVIMIENTOS DE DISTRIBUCIÓN: DB_QUANT, DB_EMPENHO, DB_QTSEGUM, DB_EMP2

SDA - SALDOS POR DISTRIBUIR: DA_QTDORI, DA_SALDO, DA_EMPENHO, DA_QTSEGUM, DA_QTDORI2, DA_EMP2

SDC - COMPOSICIÓN DE LA RESERVA: DC_QUANT, DC_QDTORIG, DC_QTSEGUM

SCP - SOLICITUDES AL ALMACÉN: CP_QUANT, CP_QTSEGUM, CP_QUJE, CP_SALBLQ

SCQ - REQUISICIONES PREVIAS: CQ_QUANT, CQ_QTSEGUM, CQ_QTDISP

AF2 - TAREAS DEL PRESUPUESTO: AF2_QUANT, AF2_KVUNIT

AF3 - RECURSOS DEL PRESUPUESTO: AF3_QUANT, AF3_CUSTD

AF4 - GASTOS DEL PRESUPUESTO: AF4_VALOR

AF8 - PROYECTOS: AF8_VALBDI

AFA - RECURSOS DEL PROYECTO: AFA_QUANT, AFA_CUSTD

AFC - ESTRUCTURA DEL PROYECTO: AFC_QUANT, AFC_CUSTO, AFC_CUSTO1/2/3/4/5

SC2 - ÓRDENES DE PRODUCCIÓN: C2_QUANT, C2_PERDA, C2_QTSEGUM, C2_QUJE

SBC - PÉRDIDA POR OP: BC_QUANT, BC_QTDDEST, BC_QTSEGUM, BC_QTDDES2

SD4 - RESERVAS: D4_QSUSP, D4_QTDEORI, D4_QUANT, D4_QTSEGUM

SH6 - MOVIMIENTO DE PRODUCCIÓN: H6_QTDPROD, H6_QTDPERD, H6_QTDPRO2

SUBPRESUPUESTOS: UB_QUANT, UB_VRUNIT, UB_VALDESC, UB_VALACRE, UB_PRCTAB


Consideraciones importantes:

  • La herramienta UPDTAMCPO se descontinuará a partir de la Release 12.1.23 con uso de binario LOBO GUARÁ debido a que no es una herramienta homologada por Totvs. Las modificaciones deben realizarse manualmente vía Configurador - SIGACFG después de las debidas copias de seguridad y validación en entorno de prueba.
  • Como ya se mencionó, todas las tablas utilizadas en su proceso deben estar de acuerdo. Además de las más usuales mencionadas, para consultar tablas involucradas en cada rutina utilizada: Puede verse en el Help Online de la rutina, expandiendo la carpeta 'Datos técnicos'>'Tablas'. EJEMPLO: Al consultar la Rutina Documentos de salida, muestra las Tablas Utilizadas: http://interno.totvs.com/mktfiles/tdiportais/helponlineprotheus/p12/spanish/mata460a_tabelas.htm
  • El parámetro MV_ARREFAT trata solamente si debe redondear o interrumpir el resultado de la Multiplicación "Cantidad" * "Valor unitario", si el total de decimales no considera el resultado completo de la operación. Observación: Si utiliza otras monedas, el Valor unitario también se redondeará en la conversión.

2 - Corregir datos inconsistentes grabados en las Tablas relacionadas

Después de realizar los ajustes de tamaños de los campos en el configurador, corrigiendo de esta manera la compatibilidad en la configuración del Diccionario y Base de datos, aún existe el problema causado, es decir, datos que están grabados en la base (que pueden estar con inconsistencias) no se modifican en la base.

De esta manera, recomendamos como medidas alternativas:


  • Que ejecute (junto con su equipo de TI para debidos procedimientos de análisis y precaución) algunas rutinas de recálculos puestos a disposición por el sistema:

MATA215 - Rehace acumulados / MATA216 - Rehace saldo de/en tercero / Rehace datos CLI/FOR / MATA300 - Rehace saldos que pueden ajustar algunos campos que tienen datos incorrectos.


  • Que valide el proceso desde su inicio de tal manera que no traiga historial inconsistente de Tablas registradas (por ejemplo, traer dato incorrecto de SD1/SB6 a SC6, o de SC9 a SD2).

Es decir, para validar debe rehacerse el procedimiento inicial con un nuevo registro, sin utilizar registros grabados en la base con posibles inconsistencias de datos. Ejemplo: Si el procedimiento se trata de una Factura de devolución...

En este caso, debe incluirse una nueva Factura de origen (idéntica al referido caso) y a continuación realizar el proceso de devolución (total/parcial) de tal manera que los datos tengan la debida integridad para el correcto procesamiento.


Observación final:

Aquí se registran las consideraciones importantes en el análisis de entorno/ base, con relación a los decimales, para que efectúe la validación.

Si realiza las validaciones y los debidos procedimientos indicados, sin embargo, aún ocurra el problema, es necesario solicitar ayuda de la Consultoría Totvs o Consultoría del Módulo para que acceda remotamente a su base, con el objetivo de realizar una evaluación/ debug de la rutina para analizarla e identificar el origen del problema.

Existe la Consultoría In loco (solicitar directamente a su Gerente de atención TOTVS) y la Consultoría técnica (Llamar directamente al 4003-0015 Opciones 2-3-2-4) donde la atención se programa en agenda de acuerdo con la necesidad del cliente y disponibilidad de los consultores.