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 como por exemplo:
·
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) o
Valor/Qtd é registrado “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
o mesmo conteúdo. 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 A410UNIDIF /
A100VALOR / A410TOTAL / ETC.
Estes comportamentos
são comumente demonstrados devido a inconsistência nas configurações da Base de
Dados. Diferenças de Tamanho e Casas Decimais entre os campos das Tabelas
utilizadas no processo e no recálculo. Pois 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, e se não estiver padronizado, as últimas casas decimais serão perdidas,
impactando no valor FINAL considerado e levado para o campo de destino.
*IMPORTANTE: É
possível até mesmo 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*
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 GAR Gerente de
Atendimento e Relacionamentos com a TOTVS) 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).
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 mais
usuais PARA O MÓDULO FATURAMENTO, e algumas das integrações mais usuais (para
demais módulos, consultar as respectivas Equipes de Suporte). Abaixo os campos
de valor e de quantidade mais usuais de alteração (orientamos que estejam com o
mesmo tamanho do campo E com mesma quantidade de casas decimais de um campo
para outro respectivamente):
§ COMPRAS
SC7- PEDIDO DE
COMPRAS: C7_QUANT, C7_QTSEGUM, C7_QUJE, C7_PRECO
SC1 - SOLICITAÇÕES:
C1_QUANT, C1_QTSEGUM
SC8 - COTACOES:
C8_QUANT, C8_QTDCTR, C8_QTSEGUM, C8_PRECO
SD1 - NOTAS DE
ENTRADA: D1_QUANT, D1_QTSEGUM, D1_QTDPEDI, D1_QTDEDEV, D1_VALDEV, D1_VUNIT
§ FATURAMENTO
SC6 - PEDIDOS DE
VENDA: C6_QTDVEN, C6_QTDLIB, C6_QTDLIB2, C6_SLDALIB, C6_QTDENT, C6_QTDENT2,
C6_PRUNIT, C6_PRCVEN, C6_QTDEMP, C6_QTDEMP2, C6_QTDRESE
SC9 - QTD LIBERADAS:
C9_QTDLIB, C9_PRCVEN, C9_QTDRESE, C9_QTDLIB2
SD2 - NOTAS DE SAIDA:
D2_QUANT, D2_QTSEGUM, D2_PRCVEN, D2_PRUNIT, D2_QTDEDEV, D2_VALDEV, D2_QTDAFAT
SD4 - EMPENHOS:
D4_QUANT, D4_QTDEORI, D4_QTSEGUM
SCK - ORCAMENTOS: CK_QTDVEN,
CK_PRCVEN, CK_PRUNIT
§ ESTOQUE
SD3 - MOVIMENTACOES
INTERNAS: D3_QUANT, D3_QTSEGUM, D3_PERDA
SB2 - SALDOS FISICOS E
FINANCEIROS: 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
TERCEIROS: B6_QUANT, B6_QTSEGUM, B6_QULIB, B6_PRUNIT, B6_SALDO
SB7 - INVENTARIO:
B7_QUANT, B7_QTSEGUM
SB9 - SALDOS INICIAIS:
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_EMPENHO, B8_QACLASS, B8_QTDORI2,
B8_EMPENH2, B8_QEPRE2, B8_QACLAS2
SBF - SALDOS POR
ENDEREÇO: BF_QUANT, BF_EMPENHO, BF_QEMPPRE, BF_QTSEGUM, BF_EMPEN2, BF_QEPRE2
SBJ - SALDOS INICIAIS
POR LOTE: BJ_QINI, BJ_QISEGUM
SBK - SALDOS INICIAIS
POR ENDERECO: BK_QINI, BK_QISEGUM
§ PMS – PLANEJAMENTO DE PROJETOS
AF2 - TAREFAS DO
ORÇAMENTO: AF2_ QUANT – AF2_KVUNIT
AF3 - RECUSRSOS DO
ORÇAMENTO: AF3_QUANT – AF3_CUSTD
AF4 - DESPESAS DO
ORÇAMENTO: AF4_VALOR
AF8 - PROJETOS:
AF8_VALBDI
AFA - RECURSOS DO
PROJETO: AFA_QUANT – AFA_CUSTD
AFC - ESTRUTURA DO
PROJETO: AFC_QUANT
§ PCP
SC2 - ORDENS PRODUÇÃO:
C2_QUANT, C2_PERDA, C2_QTSEGUM, C2_QUJE
SBC - PERDA POR OP:
BC_QUANT, BC_QTDDEST, BC_QTSEGUM, BC_QTDDES2
SD4 - EMPENHOS:
D4_QSUSP, D4_QTDEORI, D4_QUANT, D4_QTSEGUM
SH6 - MOVIMENTACAO DA
PRODUÇÃO: H6_QTDPROD, H6_QTDPERD, H6_QTDPRO2
§ CALL CENTER
SUB - ORCAMENTOS:
UB_QUANT, UB_VRUNIT
1) O parâmetro
MV_ARREFAT trata apenas se deve arredondar ou truncar o resultado da
Multiplicação "Quantidade" * "Valor Unitário"; quando o
total de decimais não completa o resultado completo da operação.
2) Como mencionado,
Todas as Tabelas utilizadas em seu processo devem estar de acordo. Além das
mais usuais mencionadas, para consultar tabelas envolvidas em cada rotina
utilizada: Pode ser verificado no Help Online da rotina expandindo a pasta
'Dados Técnicos'>'Tabelas'.
EXEMPLO: Ao consultar a Rotina Documentos
de Saída, exibe as Tabelas Utilizadas: http://interno.totvs.com/mktfiles/tdiportais/helponlineprotheus/p12/portuguese/mata460a_tabelas.htm
3) CAMPOS TOTAIS NÃO
SE ALTERA CASAS DECIMAIS.
4) Após realizar os
ajustes de tamanhos dos campos, os dados que já estão gravados no banco (que
podem estar inconsistentes) não são alterados na base.
Deste modo, sugerimos
que execute (juntamente com seu time de TI para devidos backups) as rotinas de
recálculos: 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.
5) Posteriormente, a
validação deve ser realizada desde o início do processo, de forma que não seja
trazido histórico inconsistente de Tabelas já registradas (por exemplo, trazer
dado já incorreto da SD1/SB6 para SC6, ou da SC9 para a SD2).
Exemplo: Se o
procedimento se trata de Devolução / Retorno, então, deve-se inserir uma nova
Nota de Origem identica e na sequencia realizar o processo de devolução
(total/parcial).
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.
Observação:
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 ainda ocorra o problema, será necessário solicitar auxilio da Consultoria
Totvs (O Suporte N1 não valida mais de duas decimais, realiza o teste no Padrão
nativo) ou Suporte Investigativo 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
Telefônica (Ligar diretamente no 4003-0015 Opções 2-3-2-4) na qual o
atendimento é imediato.
FONTE: http://tdn.totvs.com
EmoticonEmoticon