Como validar o XML do TOTVS Transmite no Documento de Entrada do Protheus e evitar divergências fiscais

Se o XML já veio validado… por que ainda existe risco na entrada?

Essa é uma pergunta que pouca gente faz — até tomar um susto.

Você importa o XML pelo TOTVS Transmite.
A informação vai para a tabela SDS.
O usuário entra no Documento de Entrada (MATA100).
Classifica TES, impostos, CFOP…
Confirma.

E pronto.

Mas… e se o valor bruto não bater?
E se a TES alterou a base?
E se um imposto recalculado impactou o total?

O Protheus não vai te impedir automaticamente.

E é exatamente aí que mora o risco.

O problema real: divergência entre XML e Documento de Entrada

Em um cenário hipotético (mas extremamente comum):

1. O XML é importado corretamente via TOTVS Transmite.
2. As informações vão para a tabela SDS.
3. O usuário inicia a digitação/classificação da nota.
4. Durante a classificação, pode ocorrer:
   • TES divergente
   • Imposto que recalcula o total
   • Base alterada
   • Ajuste manual

Se ninguém valida isso, você pode:

• Registrar um valor diferente do XML
• Criar inconsistência fiscal
• Ter problemas em auditorias
• Gerar divergência contábil
• Ter retrabalho na conciliação

A pergunta deixa de ser técnica e passa a ser estratégica:

Você quer descobrir isso depois… ou quer impedir que aconteça?

A solução: bloquear a confirmação quando houver divergência

A lógica ideal é simples:

Se o valor digitado não bater com o XML, a operação deve ser barrada.

E no Protheus, conseguimos fazer isso utilizando o ponto de entrada MT100TOK — executado no momento em que o usuário clica em confirmar no Documento de Entrada.

A estratégia será:

1. Usar o ponto de entrada MT100TOK
2. Buscar o valor da nota na tela via MaFisRet
3. Posicionar na SDS pela chave de acesso
4. Comparar os valores
5. Se houver divergência, impedir a confirmação

Simples, direto e eficiente.

Entendendo a lógica técnica

Dentro do ponto de entrada:

• Pegamos o valor bruto (NF_TOTAL)
• Pegamos o valor das mercadorias (NF_VALMERC)
• Capturamos a chave da NFe (F1_CHVNFE)
• Posicionamos na SDS usando filial + chave
• Comparamos:
  • SDS->DS_TOTAL x Valor digitado
  • SDS->DS_VALMERC x Valor digitado
• Se houver diferença → bloqueia

O retorno do ponto de entrada é um booleano (lContinua).

Se for .F. → o sistema não confirma a nota.

Código fonte

Conforme explicado acima, segue o código completo.
(Não alterado, conforme solicitado.)

//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

Por que essa validação é estratégica?

Muita gente enxerga isso como “apenas uma customização”.

Mas na prática, estamos falando de:

• Governança fiscal
• Redução de risco
• Confiabilidade contábil
• Blindagem contra erro humano
• Segurança em auditorias

Esse tipo de bloqueio transforma o Protheus de um sistema reativo em um sistema preventivo.

E isso muda completamente o nível de maturidade da operação.

Pontos de atenção importantes

Antes de aplicar essa lógica em produção:

• Verifique a ordem da SDS (índice 2 no exemplo)
• Confirme se o Transmite está alimentando corretamente DS_TOTAL e DS_VALMERC
• Avalie se precisa validar mais campos (base ICMS, IPI, ST, etc.)
• Teste com notas com desconto, frete e despesas acessórias

Cada cliente tem um cenário diferente.

Copiar e colar código nunca é estratégia.
Adaptar à realidade do processo é.

Quando vale a pena implementar isso?

Essa validação é altamente recomendada quando:

• A empresa tem alto volume de notas
• Existem múltiplos usuários classificando
• Há recorrência de erro de TES
• Já ocorreram divergências fiscais
• O contador já reclamou pelo menos uma vez

Se você se identificou com algum desses pontos, o risco já existe.

O que a Geeker faz diferente

Aqui na Geeker, a gente não cria customização só para “resolver um chamado”.

Nós avaliamos:

• O processo completo de entrada
• O impacto fiscal
• O impacto contábil
• O risco de auditoria
• A performance da rotina

Muitas vezes, além do bloqueio, implementamos:

• Log de divergência
• Relatório gerencial
• Painel de acompanhamento
• Indicadores de erro por usuário

Porque não é só bloquear.

É evoluir o processo.

Conclusão

Se o XML é a verdade fiscal da operação, o Documento de Entrada precisa respeitar essa verdade.

Permitir divergência é aceitar risco.
Bloquear é assumir controle.

Se você quer elevar o nível de segurança do seu Protheus e evitar retrabalho, multa ou inconsistência fiscal, fale com a Geeker.

A gente não entrega apenas código.
A gente entrega governança.