Na operação real de uma indústria que recebe 5.000 NF-e/mês, a importação automática via Transmite raramente roda 100% no piloto automático. Sempre tem um conjunto de XMLs que caem no monitor com erro — e o operador precisa parar, escolher manualmente o que fazer, ou pior: corrigir cadastro pra reprocessar.

Os dois cenários mais comuns que travam o fluxo Transmite → Protheus são:

1. CNPJ duplicado no destinatário quando o cliente tem várias filiais Protheus com o mesmo CNPJ raiz (Inscrição Estadual centralizada)
2. Série da nota com menos de 3 caracteres (ex: <SERIE>1</SERIE>) gerando rejeição na MATA103 / MATA140

Este post detalha os dois cenários, mostra por que o Protheus padrão não resolve, e apresenta a solução técnica via Pontos de Entrada COLFILDUP e A140IDOC — abordagem aprovada pela TOTVS para clientes do segmento que precisam de 100% de automação.

O que é Transmite e como ele conversa com o Protheus

O Transmite é a plataforma TOTVS de recebimento de XML de NF-e a partir dos fornecedores. Funciona em modo escuta: empresa habilita o ambiente, divulga a chave de NSU/CT-e, e a SEFAZ entrega os XMLs no Transmite — que por sua vez encaminha automaticamente ao Protheus via API REST ou Job AdvPL.

Quando o XML chega no Protheus, a esteira padrão é:

Transmite → recebe XML → encaminha ao Protheus →
MATA103 (Pré-Nota de entrada) →
  ↓
identifica filial destino via SM0 (CNPJ raiz) →
identifica fornecedor via SA2 (CNPJ) →
identifica série via cabeçalho XML →
grava cabeçalho + itens →
gera duplicata via MATA460 →
atualiza estoque via SB1/SB2

A esteira funciona 90% das vezes. Os outros 10% caem em três armadilhas — e duas delas são puramente cadastrais (não bug TOTVS, mas situação que o padrão não cobre).

Armadilha 1: CNPJ duplicado em múltiplas filiais

O cenário

Empresa-cliente tem 4 filiais Protheus, todas com o mesmo CNPJ raiz mas IEs distintas (caso típico de Inscrição Estadual centralizada — comum em distribuidoras com depósitos em mais de uma UF, ou em redes de varejo).

Quando o XML do fornecedor chega no Transmite com o CNPJ do destinatário, o Protheus consulta a tabela SM0 (Sistema de Empresas) e encontra 4 matches — não sabe pra qual filial direcionar.

O comportamento padrão Protheus

O comportamento nativo varia:

• Em algumas versões, o Protheus direciona pra primeira filial encontrada na SM0
• Em outras versões mais recentes, abre o XML no monitor de pré-nota com status "Aguardando definição de filial"

Em ambos os casos, operador precisa intervir — escolher manualmente a filial. Pra uma operação com 50 XMLs/dia caindo nessa armadilha, isso significa 2 a 3 horas de operador por dia só pra escolher filial.

A solução: PE COLFILDUP + tabela auxiliar ZCN

A solução adotada em operações grandes é criar uma tabela auxiliar (alias ZCN) com o de-para CNPJ × Filial destino, e um Ponto de Entrada COLFILDUP que avalia a tabela e desvia automaticamente.

Estrutura da ZCN:

O PE COLFILDUP é acionado na leitura do XML, antes da MATA103. Lógica básica:

User Function COLFILDUP()
    Local cFilDest := ''
    Local cCNPJFor := PARAMIXB[1]  // CNPJ do fornecedor
    
    // Kill switch
    If !GetMV('MV_XZCNATV', .F., .T.)
        Return ''  // PE inativo, fluxo padrão
    EndIf
    
    // Gate por contexto (só Transmite + MATA103/MATA140)
    If !(FunName() $ "MATA103|MATA140|TRANSMIT")
        Return ''
    EndIf
    
    // Consulta ZCN
    DbSelectArea('ZCN')
    DbSetOrder(1)
    If DbSeek(xFilial('ZCN') + cCNPJFor) .And. ;
       ZCN->ZCN_ATIVO == '1' .And. ;
       (Empty(ZCN->ZCN_DTINI) .Or. ZCN->ZCN_DTINI <= dDataBase) .And. ;
       (Empty(ZCN->ZCN_DTFIM) .Or. ZCN->ZCN_DTFIM >= dDataBase)
        cFilDest := ZCN->ZCN_FILDES
        // Auditoria
        RecLock('ZCN', .F.)
        ZCN->ZCN_QTDUSO := ZCN->ZCN_QTDUSO + 1
        ZCN->ZCN_DTUSO := dDataBase
        MsUnlock()
    EndIf
    
    Return cFilDest
Return

Pontos críticos da implementação:

• Kill switch via parâmetro MV_XZCNATV — permite desativar o PE sem recompilar
• Gate por FunName() — atua só no contexto Transmite/MATA103/MATA140, evita interferir em outros fluxos
• Validação de vigência — DT_INI e DT_FIM permitem agendar mudanças
• Auditoria automática — contador de uso e última data, sem mexer em log externo
• Fallback limpo — retorna '' em qualquer caso de exceção, deixando o fluxo padrão rodar

Armadilha 2: série com menos de 3 caracteres

O cenário

Alguns fornecedores emitem NF-e com série numérica curta — <SERIE>1</SERIE> ou <SERIE>10</SERIE> em vez de <SERIE>001</SERIE> ou <SERIE>010</SERIE>.

O Protheus, em algumas configurações de SX3 do campo F1_SERIE, exige 3 caracteres. Quando o XML chega com série curta, a MATA103 falha na validação de cabeçalho e a nota cai no monitor com erro "Série inválida".

A solução: PE A140IDOC

O A140IDOC é o Ponto de Entrada oficial da MATA140 chamado na preparação do cabeçalho da pré-nota. Aí dá pra interceptar o campo F1_SERIE e padronizar.

User Function A140IDOC()
    Local cSerie := AllTrim(SF1->F1_SERIE)
    
    If !Empty(cSerie) .And. Len(cSerie) < 3
        If IsDigit(cSerie)  // série puramente numérica
            cSerie := StrZero(Val(cSerie), 3)  // "1" → "001"
        Else
            cSerie := PadL(cSerie, 3, '0')  // "A1" → "0A1" (alfanumérica)
        EndIf
        SF1->F1_SERIE := cSerie
    EndIf
    
Return

Detalhe técnico importante: algumas UFs aceitam série alfanumérica (raro, mas existe — ex: "AB1"). Por isso o PE testa IsDigit() antes de aplicar StrZero(). Se for alfanumérica, usa PadL que preenche à esquerda preservando os caracteres não-numéricos.

Onde a abordagem falha (e como mitigar)

Mesmo com COLFILDUP + A140IDOC, alguns cenários ainda exigem intervenção:

1. CNPJ do fornecedor não cadastrado na SA2 — PE COLFILDUP só atua na filial destino, não cadastra fornecedor. Solução: ter um job paralelo que crie SA2 automaticamente via API ReceitaWS/BrasilAPI a partir do CNPJ do XML.

1. NCM inválida ou descontinuada — o item da NF-e pode trazer NCM que não está no SB1 do cliente. Solução: cadastro automático de SB1 com sugestão de NCM via IA (também coberto no Acelerador Implantação Bee IT).

1. Operações de devolução com CFOP errado — Transmite pode receber NF de devolução de venda com CFOP que não bate com o fluxo cadastrado na TES. Solução: lista de CFOPs aceitos por TES + validação prévia.

1. Reforma Tributária 2026 — novos campos NF-e — a partir de 2026, NF-e ganha <vCBS>, <vIBSE>, <vIBSM>, <vIS>. O Transmite deve repassar e o Protheus deve processar via versões 12.1.2410+. Veja o que muda em 2026.

Critérios de aceite recomendados

Pra considerar a solução homologada em produção, recomendamos validar todos esses casos no ambiente de testes:

Estimativa de esforço

Pra uma implementação clean dos dois PEs em um cliente novo:

• Dicionário ZCN (SX2/SX3/SIX) + parâmetro MV_XZCNATV: 6h
• PE COLFILDUP com log de uso: 10h
• PE A140IDOC com tratamento alfanumérico: 5h
• Cadastro inicial via MATA010 ou tela MVC: 4h
• QA dos 10 cenários: 7h
• Total: 32h (~ R$ 6.400 a R$ 12.800 com consultor sênior brasileiro 2026)

Com margem de segurança +20%: 38h.

Como acelerar com Acelerador Implantação Bee IT

O Acelerador entrega isso pronto. O fluxo Transmite + COLFILDUP + A140IDOC vem como template homologado no agente MIT Dev, com:

• Inventário estrutural automático da MIT importada
• Geração do fonte AdvPL pronto pra compilação
• Simulação pixel-perfect Protheus 12.1.2510 antes de subir
• Casos de teste já cobrindo os 10 cenários acima
• ClickSign integrado pra aceite formal

Cria conta gratuita pra 14 dias ou calcule sua economia antes.

Sobre o autor. Daniel Silva Moreira é fundador da Bee IT Inovação, canal homologado TOTVS Protheus e RM. A Bee IT opera há mais de uma década com integração fiscal Protheus, com foco em SIGACOM, SIGAFAT, SIGAFIS e fluxos NF-e/Transmite. Contato: contato@beeit.com.br.

← Voltar pro blog