✅ Resumo

Este artigo orienta como resolver o cenário em que a NFS-e é transmitida e autorizada na Prefeitura (Guarujá-SP / GISS Online v2.04), porém o retorno não é processado no Protheus, e no monitoramento do TSS/Protheus ocorre erro V999 / E160 durante a consulta do lote/protocolo.

O caso costuma estar relacionado a duplicidade de registros do prestador na tabela SPED001A (TSS), onde existe mais de um registro para a mesma entidade e algum deles está com a Inscrição Municipal vazia, fazendo com que o TSS monte a consulta com <InscricaoMunicipal/>.

🎯 Aplicabilidade

• TOTVS Protheus (SIGAFAT) + TSS

• Integração NFS-e com Prefeitura de Guarujá-SP

• Provedor GISS Online v2.04

• Sintomas:

  • Nota autorizada no portal da prefeitura;

  • Protheus/TSS sem retorno;

  • Erro na consulta: E160 (normalmente exibido como V999/E160);

  • Tentativa de retransmitir pode gerar: 9999 – RPS já informado.

✅ Pré-requisitos

• Acesso ao ambiente de Produção/Homologação do Protheus e do TSS

• Permissão para:

  • Executar FISA022 (NFS-e) / Monitoramento

  • Consultar e ajustar registros na tabela SPED001A (TSS)

  • Reiniciar serviços do TSS (se necessário)

• Acesso ao portal da prefeitura para validação do documento/protocolo

🧭 Passo a passo

1) Confirmar o sintoma no Protheus/TSS

1. Acesse o Monitoramento de NFS-e (FISA022 / Monitor).

2. Verifique se a nota está sem retorno e se ocorre:

   • V999 / E160 na consulta do lote/protocolo.

✅ Se a nota estiver autorizada no portal da prefeitura, prossiga para o passo 2.

2) Validar cadastro de Inscrição Municipal no Protheus

1. Acesse o cadastro de Empresas/Filiais (SM0/Configuração de Filiais).

2. Confirme o campo Inscrição Municipal (IM) do prestador.

📌 Esse passo garante que a base do Protheus está correta — porém, mesmo com IM correta no Protheus, o problema pode persistir se o TSS estiver com duplicidade na SPED001A.

3) Ativar logs de comunicação do TSS (se necessário)

Quando precisar de evidência técnica, habilite logs conforme padrão:

• [SPED] SPED_SAVEWSDL=1

• [JOB_WS] XMLSAVEALL=1
  Reinicie o TSS, execute a simulação/consulta e colete os XMLs gerados.

📌 Isso ajuda a confirmar o caso típico:

• Envio do lote ok;

• Consulta do lote com <InscricaoMunicipal/> vazio;

• Retorno E160.

4) Corrigir duplicidade na SPED001A (causa mais comum do E160)

Causa raiz típica: existe mais de 1 registro na SPED001A para a mesma Entidade, e algum registro está com IM vazia.

✅ Ações recomendadas (conforme orientação TOTVS):

• Manter apenas 1 registro atualizado para a entidade OU

• Preencher a IM em todos os registros existentes.

Procedimento prático:

1. Localize os registros da SPED001A para a entidade em uso (ex.: Entidade 000004).

2. Identifique registros duplicados do prestador e verifique o campo IM.

3. Ajuste para que:

   • exista apenas 1 registro válido, com IM correta, ou

   • todos os registros tenham IM preenchida.

4. Reinicie os serviços do TSS (recomendado após ajuste).

✅ Resultado esperado: a consulta do lote passa a enviar a IM corretamente, deixando de ocorrer E160.

5) Validar a autorização via Consulta RPS

Após a correção, utilize:

• FISA022 > Outras Ações > Consulta RPS

✅ Se a nota retornar como AUTORIZADA, significa que:

• a prefeitura possui o documento;

• e o TSS/Protheus já consegue consultar corretamente.

6) Entender a rejeição 9999 — “RPS já informado”

Após normalizar a consulta, ao tentar retransmitir, pode ocorrer:

• 9999 — RPS já informado

📌 Esse retorno é esperado quando o RPS já foi recepcionado/autorizado no provedor.
Nesses casos, o caminho correto é consultar/recuperar o retorno e não retransmitir como se fosse envio inicial.

⚠️ Erros comuns

• ✅ IM correta no Protheus, mas não corrigir a SPED001A no TSS.

• Ajustar SPED001A e não reiniciar o TSS (mantém cache e mantém comportamento antigo).

• Insistir em retransmitir RPS já autorizado e interpretar 9999 como erro novo.

• Não validar pelo caminho correto: Consulta RPS.

❓ FAQ

1) A nota está autorizada no portal, mas o Protheus não atualiza. O que fazer?
Verifique se há E160 na consulta e corrija duplicidades na SPED001A. Depois, valide via Consulta RPS.

2) Mesmo com IM correta no cadastro de filiais, continua E160. Por quê?
Porque o TSS pode estar selecionando um registro duplicado na SPED001A onde a IM está vazia e montando <InscricaoMunicipal/>.

3) O que significa 9999 “RPS já informado”?
Que o RPS já existe no provedor (normal quando já foi autorizado). O correto é consultar/recuperar retorno.

4) Preciso contatar a prefeitura?
Somente se, após corrigir SPED001A e validar consulta, a prefeitura continuar retornando erro com XML correto. No caso típico, o ajuste na SPED001A resolve.

📚 Referências

• TOTVS — NFS-e E160: Arquivo enviado fora da estrutura do XML de entrada

• TOTVS — Procedimento para ativar logs de comunicação do TSS

🗂️ Cadastro na Base de Conhecimento

Título sugerido: NFS-e Guarujá (GISS v2.04) — E160 na consulta do lote e retorno não processado no Protheus/TSS
Categoria: Protheus > Faturamento (SIGAFAT) > NFS-e / TSS
Tags sugeridas: nfse, tss, protheus, guaruja, giss, e160, v999, sped001a, consulta rps, fisa022

👤 Autor

Fabrizio Augusto Ventavolo
Consultor Especialista TOTVS — Mastersiga Consultoria