Rejeição 887: item de serviço com GTIN diferente de SEM GTIN

A rejeição 887 exige conferir os dois campos de GTIN do item quando foi informado o grupo de tributação do ISSQN. Nesse cenário, cEAN e cEANTrib devem conter o literal SEM GTIN. Corrigir apenas um deles pode deixar o outro incompatível com a regra.

A mensagem atual é “Item de Serviço e informado GTIN diferente de SEM GTIN”, acompanhada do número do item. Ela está associada à U01-30, página 12 da NT 2021.003 v1.50, marcada como obrigatória para os modelos 55/65. O diagnóstico deste artigo pertence à autorização de NF-e/NFC-e; não é uma instrução para o serviço municipal de NFS-e.

O que aciona a validação

A condição documentada é a presença do grupo de tributação ISSQN, identificado como U01, no item. No XML, confira det/imposto/ISSQN e os campos det/prod/cEAN e det/prod/cEANTrib daquele mesmo det. O título ou a descrição comercial do serviço, isoladamente, não substitui essa conferência.

Se o grupo ISSQN está corretamente informado, ambos os campos de GTIN devem receber o literal previsto. A regra não pede que se obtenha um código de barras para o serviço, nem que se informe um código interno de cadastro nesses campos.

A indicação dos modelos na tabela técnica também não autoriza qualquer prestação a ser documentada por NF-e ou NFC-e. A possibilidade de emissão conjugada e o tratamento fiscal da prestação precisam ser compatíveis com as normas aplicáveis à operação. Resolver o preenchimento de GTIN não comprova esse enquadramento.

Primeiro, identifique o arquivo e o item corretos

Preserve o retorno completo, o XML transmitido, a chave, o modelo, o ambiente e a identificação do autorizador. Localize o nItem indicado na mensagem e compare os campos dentro desse item. A sequência exibida na tela pode não corresponder à ordenação usada na integração.

Verifique se algum código numérico foi enviado em cEAN ou cEANTrib, se um deles ficou vazio e se o grupo ISSQN está presente. O XML revela o que foi transmitido; o cadastro consultado depois da rejeição pode conter uma versão diferente dos dados.

Confirme a natureza do item com os documentos da operação. Esse cuidado distingue um serviço corretamente classificado, mas com GTIN indevido, de uma mercadoria que recebeu por erro uma configuração fiscal de serviço. As duas situações exigem correções diferentes.

Cenário 1: serviço correto, com código herdado de um cadastro

Uma integração pode copiar um cadastro utilizado anteriormente para mercadorias e carregar seu código de barras para um item de serviço. Outra possibilidade é um identificador interno ter sido enviado como GTIN. Essas são hipóteses de diagnóstico, não causas comprovadas pelo retorno isolado.

Depois de confirmar que o grupo ISSQN representa corretamente o item, ajuste a informação para que cEAN e cEANTrib contenham SEM GTIN. Corrija também a origem do dado, quando necessário, para evitar que futuras notas repitam a inconsistência.

Não altere a classificação de uma mercadoria verdadeira para serviço apenas para usar esse literal. Da mesma forma, não remova ISSQN ou dados cadastrais verdadeiros para fazer a mensagem desaparecer. O documento deve continuar representando a operação real.

Cenário 2: a tela ficou vazia, mas o XML continua inadequado

Alguns emissores orientam deixar o campo visual vazio porque fazem a conversão automática para SEM GTIN. Isso é uma característica do produto documentado por cada fornecedor. Não significa que uma tag vazia no XML seja equivalente ao literal exigido pela U01-30.

No ALRA, confira o arquivo gerado e solicite ao suporte a identificação dos campos ou do mapeamento utilizados. Este artigo não presume um menu, uma versão de tela ou uma conversão automática. Se o cadastro foi corrigido, verifique também os dados conservados no item da nota que já estava preparada.

Ao gerar novamente o documento, compare os dois valores. Se o novo XML mantiver um número ou continuar sem o literal, investigue a configuração que prevalece na geração, em vez de repetir o envio sem alterar a origem do problema.

Cenário 3: a mercadoria recebeu ISSQN por engano

Se o item é uma mercadoria e o grupo ISSQN foi incluído indevidamente, a correção depende de revisar sua classificação e a tributação com o responsável fiscal. Não basta substituir um GTIN verdadeiro por SEM GTIN: isso pode ocultar a identificação do produto sem resolver o erro que levou ao grupo incorreto.

Também não exclua automaticamente inscrição municipal ou CNAE do emitente. Esses dados não são o predicado da U01-30. Uma orientação genérica de outro emissor para removê-los não demonstra que estejam errados na sua operação.

Exemplo de conferência

Uma empresa fictícia prepara um item de serviço com ISSQN. O arquivo contém SEM GTIN em cEAN, mas cEANTrib ainda recebe um identificador numérico copiado de outro cadastro. A equipe confirma a natureza da prestação e identifica o mapeamento incorreto.

Ajusta-se a origem do preenchimento para que ambos os campos recebam SEM GTIN, preservando o tratamento fiscal correto do serviço. O novo arquivo é conferido antes de uma nova tentativa. O exemplo não representa validação em ambiente de teste ou autorização de uma emissão real.

Versão da regra e outras validações

Confira a mensagem completa junto do número 887. Uma orientação sobre agrupamento de produtos ou GTIN-14 não descreve a condição atual da U01-30. A NT consultada associa este código ao grupo ISSQN e à exigência do literal nos dois campos. Não modifique embalagens ou quantidades por associação apenas ao número da rejeição.

A NT 2024.001 v1.20 estabelece exceções para MEI, CRT=4, nas regras 883 e 888, relativas à falta de informação. Elas não devem ser estendidas automaticamente à U01-30. Tampouco o cronograma do Grupo V de consultas ao CCG, previsto para 2027 na v1.50, suspende esta validação de serviço.

As capturas oficiais de 15 e 16/10/2026 e o índice atual da SVRS sustentam o diagnóstico documental. A matriz da NT registra marcos por aplicação autorizadora, mas não comprova o funcionamento individual de um estabelecimento em determinado ambiente.

Verifique a resposta da nova tentativa

Confirme a situação fiscal das tentativas anteriores e use o fluxo do emissor para gerar e assinar o documento corrigido. Não edite isoladamente o XML assinado. Leia a resposta correspondente ao novo envio e confirme a autorização e o protocolo, quando houver.

Se surgir outro código, trate a nova condição conforme a mensagem recebida. Se a 887 persistir, encaminhe ao suporte o item, o XML efetivamente transmitido e o retorno completo. Uma tela correta ou o desaparecimento de uma rejeição não bastam para concluir que a nota foi autorizada.

Fontes

• NT 2021.003 v1.50: captura oficial de 16/10/2026 reutilizada; páginas 3–14 lidas nesta sequência de autoria. Página 12 conferida pessoalmente em imagem documental existente: U01-30 íntegra, distinta das regras riscadas ao redor.

• NT 2024.001 v1.20: captura de 15/10/2026, páginas 5, 9 e 11 e imagens documentais existentes das exceções, já lidas e vistas na autoria 886 imediatamente anterior e reutilizadas explicitamente.

• Bling, Webmania e TecnoSpeed: três corpos específicos lidos em 16/10/2026. Bling e TecnoSpeed pelo WEB, separados das capturas diretas 403; Webmania também HTTP200. Conversões, menus e remoção genérica de IM/CNAE não foram adotados como instruções do ALRA.

• Hashes, evidências, limites do schema e buscas focais em fontes.v1.json. Não houve emissão, consulta individual de contribuinte, nova imagem ou publicação.