Quem trabalha com Protheus no dia a dia sabe que a entrada de notas fiscais pode virar um problema quando os valores digitados no documento não batem com as informações que vieram no XML.
E isso acontece mais do que deveria.
TES errada, imposto diferente, valor de mercadoria divergente… tudo isso pode gerar inconsistência contábil, fiscal ou até problemas no fechamento financeiro.
Quando a empresa utiliza o TOTVS Transmite, os dados do XML já ficam disponíveis no sistema, então surge uma pergunta importante:
por que permitir que o usuário confirme uma nota com valores diferentes do XML?
A resposta mais segura é simples: não permitir.
Neste artigo vamos mostrar como criar uma validação no Protheus que compara as informações do TOTVS Transmite com o Documento de Entrada, impedindo a confirmação caso os valores não estejam corretos.
O problema: divergência entre XML e Documento de Entrada
Quando uma nota fiscal é importada pelo TOTVS Transmite, o XML é processado e as informações ficam armazenadas em tabelas internas do Protheus.
Uma das tabelas utilizadas nesse processo é a SDS, que guarda dados importantes da nota fiscal importada.
Durante a digitação ou classificação do Documento de Entrada, o usuário pode alterar TES, impostos ou valores de mercadoria. Dependendo dessas alterações, o valor final da nota pode acabar ficando diferente do valor original do XML.
Esse tipo de divergência pode gerar vários problemas:
- inconsistência fiscal
- erro em apuração de impostos
- diferença entre XML e escrituração
- dificuldade em auditorias fiscais
- erros em integrações contábeis
Por isso, muitas empresas preferem implementar validações automáticas no Protheus, garantindo que o documento só seja confirmado quando os valores estiverem corretos.
A solução: validação via ponto de entrada MT100TOK
Uma forma simples e eficiente de resolver esse problema é utilizar o ponto de entrada MT100TOK.
Esse ponto de entrada é executado no momento em que o usuário confirma o Documento de Entrada, o que torna ele perfeito para validações críticas.
A lógica da solução funciona da seguinte forma:
Primeiro o sistema recupera os valores que estão sendo informados na tela do documento de entrada, utilizando a função MaFisRet. Esses valores representam o total bruto da nota e o valor das mercadorias.
Depois disso, o sistema busca a chave da nota fiscal eletrônica, que é utilizada para localizar o XML que foi importado pelo TOTVS Transmite.
Com essa chave, o sistema acessa a tabela SDS, que contém as informações originais do XML.
Quando a chave é encontrada, o sistema compara os valores armazenados no XML com os valores que estão sendo informados no Documento de Entrada.
Se houver qualquer divergência, o sistema bloqueia a confirmação da nota e apresenta uma mensagem informando que os valores não batem com o XML importado.
Dessa forma, o usuário é obrigado a revisar a classificação da nota antes de prosseguir.
Esse tipo de validação é extremamente útil para garantir integridade fiscal e consistência de dados dentro do ERP.
Como funciona a lógica da validação
A lógica da implementação segue alguns passos bem claros.
Primeiro o código captura o valor total bruto da nota e o valor das mercadorias que estão sendo processados no Documento de Entrada.
Depois o sistema recupera a chave da NF-e informada no documento.
Em seguida o código acessa a tabela SDS, onde estão armazenadas as informações vindas do TOTVS Transmite.
Se a chave da nota existir nessa tabela, o sistema compara os valores do XML com os valores informados na tela.
Caso os valores sejam diferentes, o sistema:
- bloqueia a confirmação da nota
- exibe uma mensagem de erro
- solicita a revisão das informações
Isso evita que notas fiscais com divergência sejam registradas no sistema.
Código da validação no Protheus
Abaixo está o exemplo de implementação dessa lógica utilizando o ponto de entrada MT100TOK.
O código abaixo segue exatamente a lógica explicada neste artigo.
//Bibliotecas
#Include "TOTVS.ch"
/*/{Protheus.doc} MT100TOK
Ponto de Entrada ao clicar no botão confirmar do Documento de Entrada
@type user function
@author Atilio
@since 06/10/2025
@version version
@see https://tdn.totvs.com/pages/releaseview.action?pageId=6085400
/*/
User Function MT100TOK()
Local aArea := FWGetArea()
Local aAreaSDS := SDS->(FWGetArea())
Local lContinua := .T.
Local nValorBrut := MaFisRet(, "NF_TOTAL") // F1_VALBRUT
Local nValorMerc := MaFisRet(, "NF_VALMERC") // F1_VALMERC
Local cChaveNota := M->F1_CHVNFE
Local cMensagem := ""
Local cMascara := PesqPict("SF1", "F1_VALBRUT")
DbSelectArea("SDS")
SDS->(DbSetOrder(2)) // DS_FILIAL + DS_CHAVENF
//Se encontrou a chave vinda do TOTVS Transmite
If ! Empty(cChaveNota) .And. SDS->(MsSeek(FWxFilial("SDS") + cChaveNota))
//Se o valor bruto ou o de produtos não bater
If SDS->DS_TOTAL != nValorBrut .Or. SDS->DS_VALMERC != nValorMerc
lContinua := .F.
cMensagem := ". Bruto: " + Alltrim(Transform(nValorBrut, cMascara)) + " vs " + Alltrim(Transform(SDS->DS_TOTAL, cMascara))
cMensagem += ". Mercadorias: " + Alltrim(Transform(nValorMerc, cMascara)) + " vs " + Alltrim(Transform(SDS->DS_VALMERC, cMascara))
ExibeHelp("Help_MT100TOK", "O Valor da Nota não bate com o que veio do XML no TOTVS Transmite! " + cMensagem, "Analise as informações e faça a correção")
EndIf
EndIf
FWRestArea(aAreaSDS)
FWRestArea(aArea)
Return lContinua
Benefícios de implementar esse tipo de validação
Implementar validações como essa dentro do Protheus traz diversas vantagens para o processo de entrada de notas fiscais.
Primeiro, reduz significativamente o risco de erros humanos durante a digitação ou classificação da nota.
Além disso, garante que os valores registrados no sistema estejam sempre alinhados com o XML oficial da nota fiscal.
Outro ponto importante é a melhoria na confiabilidade das informações fiscais, algo fundamental para auditorias, fechamentos contábeis e apuração de impostos.
Empresas que trabalham com grande volume de notas fiscais costumam se beneficiar bastante desse tipo de automação, porque evitam retrabalho e inconsistências no ERP.
Quando vale a pena usar esse tipo de customização
Esse tipo de validação costuma ser muito útil em cenários como:
- empresas que importam XML via TOTVS Transmite
- processos de classificação manual de notas
- ambientes com alto volume de documentos fiscais
- empresas que precisam garantir consistência fiscal rigorosa
Também é uma ótima prática para organizações que querem deixar o processo de entrada de notas mais seguro e auditável.
Conclusão
Criar validações entre o TOTVS Transmite e o Documento de Entrada no Protheus é uma prática simples, mas extremamente poderosa para evitar inconsistências fiscais dentro do ERP.
Utilizando o ponto de entrada MT100TOK, é possível garantir que os valores informados no documento sempre estejam alinhados com os dados do XML.
Esse tipo de automação ajuda a evitar erros humanos, melhora a qualidade dos dados e deixa o processo fiscal muito mais confiável.
Se a sua empresa trabalha com alto volume de notas fiscais, implementar validações desse tipo pode fazer uma grande diferença na segurança das operações.
Precisa de ajuda com customizações no Protheus?
Se você quer implementar validações, automações ou integrações no Protheus, a Geeker Company pode ajudar.
Nosso time trabalha diariamente com:
- desenvolvimento ADVPL
- automações fiscais
- integrações entre sistemas
- otimização de processos dentro do ERP
Se a ideia é deixar seu Protheus mais seguro, eficiente e preparado para crescer junto com o seu negócio, fale com a gente.




