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.
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)
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)
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.
A410UNIDIF | A100VALOR | A410TOTAL |A415TOTAL |
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). |
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. Campos de valor también deben tener el mismo tamaño/ máscara. 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)
Consideraciones importantes:
|
2 - Corregir datos inconsistentes grabados en las Tablas relacionadasDespué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:
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.
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. |