• Exibida mensagem no Pedido de Vendas informando que...

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)

• No Pedido de Vendas (SC6)

É informado no item um Valor/Qtd “x” porém, ao Liberar / Preparar o documento de saída, esse valor/qtd é levado “y” (SC9 / SD2)

• Campos com conteúdos diferentes, quando deveriam ter conteúdo idêntico

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.

• Alerts na tela que impedem o processo:

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 . sem o uso dos Grupos de Campos Numéricos. 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).
Portanto, é indicado que qualquer alteração neste sentido seja realizado e documentado por um analista in loco (Consultar diretamente seu ESN) para análise pontual de sua base/ seu cenário, inclusive para as manutenções dessas alterações nas Tabelas (já que com as atualizações podem ser criados novos campos e novas tabelas na base)e sempre utilizando os Grupos de Campos Numéricos.