Produto: | Microsiga Protheus |
| Ocorrência: | Aumento de casas decimais ou inconsistências relacionadas à alteração |
Ambiente: | SIGAFAT - Faturamento |
O aumento de casas decimais no Protheus é uma questão delicada. Quando realizado sem os devidos critérios, ou não recebe a devida manutenção, pode causar diversas inconsistências.
Por se tratar de uma Nota Fiscal de Devolução, o valor unitário deve ser igual ao da Nota Fiscal de Origem (sendo que o valor exibido no Pedido está sim igual ao valor exibido na Nota de Entrada)
É informado no item um Valor/Qtd “x” porém, ao Liberar / Preparar o documento de saída, esse valor/qtd é levado “y” (SC9 / SD2)
Exemplo: B6_PRUNIT / D2_PRCVEN (preço da venda) / D2_PRUNIT (preço unitário do produto) Podendo inclusive atribuir essa diferença como desconto indevido na Nota.
A410UNIDIF | A100VALOR | A410TOTAL |A415TOTAL |
Estes comportamentos são comumente encontrados em ambiente onde houve aumento no tamanho de campos ou alteração na configuração de casas decimais. São causados devido a algum campo, relacionado à Nota, ter sido gravado com dados incompatíveis (geralmente, devido à tamanhos diferentes de campos ou das decimais, ou seja, dicionário/banco de dados alterado sem devida equiparação). Obs: Quando digo "algum campo relacionado à Nota" entenda-se que pode ser de quaisquer Tabelas, de diversos diferentes módulos, que o cliente possa ter implantado em seu negócio e de algum modo se relacionem, devido o sistema ser integrado. É importante esclarecer que tais inconsistências geralmente não se limitam exclusivamente ao Pedido / Nota que está sendo lançado. Muitas vezes se trata de outras Tabelas que já foram movimentadas antes, uma vez que o sistema valida histórico e relacionamentos das movimentações para execução de cálculos e para manter a integridade de dados. Ou seja, quando o sistema faz um cálculo ele vai passar o valor de um campo X (C6_PRCVEN por exemplo) por vários outros campos. Se não estiverem todos padronizados, comportando a mesma quantidade e configuração dos dados, as últimas casas decimais serão perdidas, impactando assim no valor FINAL considerado e levado para o campo de destino. É possível inclusive que a inconsistência seja identificada após atualização; isso devido às correções que são realizadas nas validações e nos Fontes atualizados! Ou mesmo, devido às Tabelas e/ou campos que foram criados e envolvidos no processo desde sua última atualização da Base IMPORTANTE: Qualquer tratamento relacionado a casas decimais é considerado um desvio do Nativo do Protheus (no qual é padrão o uso de dois dígitos, apenas, para o ambiente Faturamento). |
1 - Identificar e ajustar todos os campos relacionados de modo que todos possuam configuração compatível para que os dados não se percam.Ou seja, campos de quantidade devem todos possuir mesmo tamanho/ máscara. Campos de valor também devem possuir mesmo tamanho/ máscara (saiba mais aqui sobre o tamanho Limite-de-casas-decimais) A TOTVS não possui um Documento específico para definição de todas as tabelas/campos que são utilizados em sua rotina, e consequentemente, precisam ser alterados para manter a integridade entre suas Tabelas; pois é relativo à cada Cliente, pontualmente, de acordo com os módulos que estão implantados, as rotinas que são utilizadas, as tabelas que são alimentadas e os campos que são de uso. Sendo assim, caso realize a implementação/ manutenção internamente com sua equipe de TI, ressaltamos a importância de alterar todas as tabelas/ campos utilizados na integração de suas rotinas; a fim de não gerar inconsistência em sua base de dados. Podemos citar os campos mais usuais PARA O MÓDULO FATURAMENTO, e algumas das integrações mais recorrentes (orientamos que estejam com o mesmo tamanho do campo E com mesma quantidade de casas decimais de um campo para outro respectivamente)
Considerações Importantes:
| |||||||
2 - Corrigir dados inconsistentes gravados nas Tabelas relacionadasApós realizar os ajustes de tamanhos dos campos no configurador, corrigindo assim a compatibilidade na configuração do Dicionário e Banco de Dados, ainda há o problema já causado, ou seja, dados que já estão gravados no banco (que podem estar inconsistentes) não são alterados na base. Deste modo, recomendamos como medidas de contorno:
MATA215 - Refaz Acumulados / MATA216 - Refaz saldo de/em terceiro / Refaz dados CLI/FOR / MATA300 - Refaz Saldos que podem ajustar alguns campos que possuem dados incorretos.
Ou seja, para validar deve-se refazer o procedimento do início com um novo registro, não utilizando registros já gravados na base com possíveis inconsistências de dados. Exemplo: Se o procedimento se trata de uma Nota de Devolução / Retorno... Então neste caso deve-se inserir uma nova Nota de Origem (idêntica ao caso em questão) e, na sequência realizar o processo de devolução (total/parcial) de modo que os dados tenham a devida integridade para correto processamento. |
| Observação Final: | Aqui foram registradas as considerações importantes na análise de ambiente/ base, em relação às casas decimais, para que efetue a validação. Caso realize as validações e os devidos procedimentos indicados, porém, ainda ocorra o problema, será necessário solicitar auxilio da Consultoria Totvs ou Consultoria do Módulo para que acesse remotamente a sua base, visando avaliação/ debug da rotina para investigá-la e identificar a origem do problema. Há a Consultoria In loco (solicitar diretamente à seu Gerente de atendimento TOTVS) e a Consultoria Técnica (Ligar diretamente no 4003-0015 Opções 2-3-2-4) na qual o atendimento é agendado conforme necessidade do cliente e disponibilização dos consultores. |
