Projeto Nota Fiscal Eletrônica

Transcrição

1 Projeto Nota Fiscal Eletrônica de Compartilhamento de Informações entre Órgãos Públicos Versão 2.02a Março 2010 Pág. 1 / 68

2 Controle de Versões Versão Data /04/2008 SP 1.00a 03/05/2008 RS/SP /05/2008 SP /05/2008 Reunião Técnica SP 1.02a 20/08/2008 SP (draft) /04/2009 Reunião Técnica GO (descartada) /09/2009 Reunião Técnica Fortaleza/CE (Alteração CNE) 1.04b 20/10/2009 Revisão SEFAZ/RS e SERPRO /02/2010 SP (Alteração Compartilhamento DF-e) /02/2010 Reunião Técnica Belo Horizonte/MG /03/2010 Revisão SEFAZ/RS e SERPRO 2.02a 13/03/2010 Revisão BT 2010/001 Pág. 2 / 68

3 Identificação e vigência do Versão do manual 2.02 Data de divulgação do manual Mar/10 Pacote de liberação de Schemas XML Compartilhamento PL_CompNFe_200 Data de início de vigência no ambiente de homologação Mar/2010 Data de início de vigência no ambiente de produção Abril/2010 Pacote de liberação de Schemas XML CNE PL_CNE_102c Data de início de vigência no ambiente de homologação a definir Data de início de vigência no ambiente de produção 30/09/2010 Versões de leiautes do PL_CompNFe_200 Leiaute versão Schema XML Observação consprotfaltnfe 2.00 consprotfaltnfe_v2.00.xsd Mensagem de consulta protocolos faltantes distnfe 2.00 distnfe _v2.00.xsd Schema para validar lote de distribuição de DFe descompactado leiauteloterfbnfe 2.00 leiauteloterfbnfe_v2.00.xsd Leiaute do Compartilhamento de DF-e. loterfbnfe 2.00 loterfbnfe_v2.00.xsd Schema para validar lote de envio de lote de DF-e descompactado retconsprotfaltnfe 2.00 retconsprotfaltnfe_v2.00.xsd Mensagem de retorno da consulta protocolos faltantes retdistnfe 2.00 retdistnfe_v2.00.xsd Mensagem de distribuição de lote de DF-e. retloterfbnfe 2.00 retloterfbnfe_v2.00.xsd Mensagem de retorno do envio de lote de DF-e. tiposbasico 1.02 tiposbasico_v1.02.xsd Tipos Básicos Versões de leiautes do PL_CNE_102c Leiaute versão Schema XML Observação conscne 1.01 conscne_v1.01.xsd Mensagem de consulta CNE envcne 1.01 envcne_v1.01.xsd Mensagem para envio do cadastro do CNE leiautecne 1.01 leiautecne_v1.01.xsd Definição das mensagens retconscne 1.01 retconscne_v1.01.xsd Retorno da mensagem de consulta CNE retenvcne 1.01 retenvcne_v1.01.xsd Retorno da mensagem para envio do cadastro do CNE tiposbasico 1.02 tiposbasico_v1.02.xsd Tipos Básicos Pág. 3 / 68

4 Índice 1. Introdução Considerações Iniciais Compartilhamento de DF-e através do TED-DIST Compartilhamento de DF-e através de Web Service Compartilhamento de outras informações através de Web Service Arquitetura de Distribuição Modelo Conceitual da Distribuição de DF-e Modelo Conceitual da Manutenção do Cadastro Nacional de Emissores de DF-e Padrões Técnicos Padrão de documento XML Padrão de Comunicação Padrão de Certificado Digital Padrão de compactação Resumo dos Padrões Técnicos Padrão de mensagens dos Web Services Informações de controle e área de dados das mensagens Validação da estrutura XML das Mensagens dos Web Services Schemas XML das Mensagens dos Web Services Versão dos Schemas Liberação das versões dos Schemas para o WS do Ambiente Nacional Pacote de Liberação Preliminar Pacote de Liberação de Homologação e Pacote de Liberação definitivo Correção de Pacote de Liberação Divulgação de novos Pacotes de Liberação Controle de Versão Web Services Serviço de Recepção de DF-e Web Service NFeRecepcaoRFB Leiaute Mensagem de Entrada Leiaute Mensagem de Retorno Descrição do Processo de Geração de Lotes de DF-e Descrição do Processo de Recepção de Lotes de DF-e Validação do Certificado de Transmissão Validação Inicial da Mensagem no Web Service Validação das informações de controle da chamada ao Web Service Validação da área de Dados Final do Processamento do Lote Serviço de Distribuição de DF-e Web Service NFeDistribuicaoRFB Leiaute Mensagem de Entrada Leiaute Mensagem de Retorno Descrição do Processo de Requisição de distribuição de DF-e Descrição do Processo de Distribuição de Lotes de DF-e Validação do Certificado de Transmissão Validação Inicial da Mensagem no Web Service Validação das informações de controle da chamada ao Web Service Validação da área de Dados Processamento da requisição Serviço de Consulta de Protocolos Faltantes Web Service NFeConsProtFal Leiaute Mensagem de Entrada Leiaute Mensagem de Retorno Descrição do Processo da requisição de consulta de Protocolos Faltantes da UF Descrição do Processo de Consulta de Protocolos Faltantes da UF Validação do Certificado de Transmissão Pág. 4 / 68

5 4.3.7 Validação Inicial da Mensagem no Web Service Validação das informações de controle da chamada ao Web Service Validação da área de Dados Processamento da requisição Serviço de Manutenção do Cadastro Nacional de Emissores de DF-e Web Service CNEManutencao Leiaute Mensagem de Entrada Leiaute Mensagem de Retorno Estrutura do Cadastro Nacional de Emissores Descrição do Processo de envio da mensagem de Manutenção do Cadastro Nacional de Emissores de DF-e Descrição do Processo de recepção da mensagem de atualização do Cadastro Nacional de Emissores de DF-e Validação do Certificado de Transmissão Validação Inicial da Mensagem no Web Service Validação das informações de controle da chamada ao Web Service Validação da área de Dados Final do Processamento Serviço de Distribuição do Cadastro Nacional de Emissores de DF-e Web Service CNEDistribuicao Leiaute Mensagem de Entrada Leiaute Mensagem de Retorno Descrição do Processo de Geração de requisição de distribuição do Cadastro de Nacional de Emissores de DF-e Descrição do Processo de download do Cadastro Nacional de emissores resumido ou das Atualizações de Cadastro ocorridas a partir do NSU informado Validação do Certificado de Transmissão Validação Inicial da Mensagem no Web Service Validação das informações de controle da chamada ao Web Service Validação da área de Dados Processamento da Solicitação pelo WS do Ambiente Nacional Processamento da Solicitação pelo WS do Ambiente Nacional Web Services Informações Adicionais Regras de validação Tabela de códigos de erros e descrições de mensagens de erros Número do protocolo Anexo I - Tabela de órgãos conveniados Anexo II - Endereço dos Web Services Pág. 5 / 68

6 1. Introdução Este documento tem por objetivo a definição das especificações e critérios técnicos necessários para o compartilhamento e distribuição de informações entre as Secretarias de Fazendas dos Estados, SUFRAMA, Receita Federal do Brasil e outros órgãos conveniados. Pág. 6 / 68

7 2. Considerações Iniciais Os Protocolos de Cooperação do ENAT que criam novos documentos fiscais eletrônicos sempre prevêem o compartilhamento dos documentos fiscais eletrônicos entre as administrações tributárias signatárias: O Protocolo de Cooperação n 03/2005 II ENAT de implantação da Nota Fiscal eletrônica prevê o compartilhamento das NF-e entre as administrações tributárias da União, dos Estados, do Distrito Federal e dos Municípios. O Protocolo de Cooperação n 03/2006 II ENAT de implantação do Conhecimento de Transporte Eletrônico prevê o compartilhamento de CT-e entre as administrações tributárias. O processo de compartilhamento de informações é um requisito básico e de fundamental importância para o sucesso do projeto de documentos fiscais eletrônicos. O órgão da administração tributária que autoriza o uso do documento fiscal tem a responsabilidade de compartilhar o documento fiscal eletrônico para o Ambiente Nacional, administrado pela Receita Federal do Brasil, e para os demais órgãos conveniados que tenham o legítimo interesse em receber o documento fiscal eletrônico. 2.1 Compartilhamento de DF-e através do TED-DIST O TED-DIST é um sistema de distribuição de arquivos em uso atualmente. O sistema foi desenvolvido pela SEFAZ/RS, sendo uma evolução do TED Transmissão Eletrônica de Documentos, muito utilizado pelas Secretarias de Fazenda para recepção de informações de contribuintes em meio eletrônico, em especial os arquivos do SINTEGRA. Fluxo de Distribuição de Documentos Fiscais Arquitetura TED-DIST Receita Federal do Brasil (Ambiente Nacional) SEFAZ UF Emissor Rede RIS SEFAZ UF Destino, Embarque, Desembaraço SUFRAMA Meio de Distribuição TED-DIST Outros Órgãos O meio de comunicação utilizado no TED-DIST é a REDE RIS (Rede Intranet SINTEGRA). Modelo operacional A SEFAZ de origem responsável pela autorização do documento fiscal deve depositar os documentos fiscais nos repositórios do TED-DIST, para o Órgão conveniado (administração tributária) interessada naquele documento fiscal. Pág. 7 / 68

8 O TED-DIST monitora os repositórios de saída e transmite os arquivos depositados para o respectivo Órgão conveniado. O Órgão conveniado de destino deve consumir o arquivo que o TED-DIST disponibiliza no repositório de entrada da UF de origem. Atualmente, somente o Ambiente Nacional faz um tratamento dos arquivos recebidos, gerando um arquivo de retorno do resultado do processamento que é transmitido para UF de origem pelo TED- DIST. A UF de origem deve tratar os arquivos de retorno gerados pelo Ambiente Nacional e providenciar o reenvio do arquivo nos casos de falha no tratamento do documento fiscal pelo Ambiente Nacional. Da mesma forma, a UF de origem deve manter controle sobre os arquivos enviados pendentes de retorno pelo Ambiente Nacional. A não realização do tratamento dos arquivos recebidos pelos demais destinatários dos documentos fiscais é um ponto de fragilidade deste modelo de compartilhamento de documento fiscal. O processo de sincronismo do repositório da UF de origem com os repositórios do Ambiente Nacional, UF de destino, SUFRAMA e demais órgãos conveniados é prejudicado em função da inexistência de um processo eficaz de controle de sincronismo, que verifique e promova a sincronização dos repositórios. 2.2 Compartilhamento de DF-e através de Web Service O compartilhamento de informações através de Web Services atende a necessidade de agilização de processos e otimização dos recursos existentes. A sua principal premissa é agilizar o compartilhamento de informações e obtenção da confirmação da entrega em modo síncrono, com garantia de entrega fim-a-fim entre as aplicações. O uso da Internet, a escalabilidade da solução e a centralização do processo no Ambiente Nacional são outros fatores favoráveis para a adoção da solução. O modelo permite a implementação de um controle de sincronismo mais eficiente, que consiga identificar os documentos fiscais faltantes no Ambiente Nacional, além de possibilitar a recuperação do repositório local com base no repositório do Ambiente Nacional. Fluxo de Distribuição de Documentos Fiscais Arquitetura Web Service Ambiente Nacional SEFAZ UF Destino, Embarque, Desembaraço SEFAZ UF Emissor Internet Receita Federal do Brasil (Ambiente Nacional) Internet SUFRAMA Outros Órgãos Meio de Distribuição TED-DIST WS Ambiente Nacional Rede RIS Pág. 8 / 68

9 Modelo Operacional de Compartilhamento para a RFB Neste modelo de compartilhamento, a SEFAZ de origem, responsável pela autorização do documento fiscal, deve transmitir os documentos fiscais para o Web Service de recepção de documentos fiscais do Ambiente Nacional. O Ambiente Nacional oferecerá um Web Service para que os órgãos conveniados possam recuperar os documentos fiscais autorizados, centralizando a comunicação de todos os envolvidos em um único ponto central. Para os órgãos que não desejem recuperar as NF-e por este Web Service, o Ambiente Nacional irá encaminhar os documentos fiscais eletrônicos recebidos pelo Web Service de recepção de documentos fiscais do Ambiente Nacional através do TED-DIST. A unidade federada autorizadora pode continuar utilizando a funcionalidade de transmissão do TED- DIST, caso não tenha interesse de construir a aplicação cliente de envio de documentos fiscais para o Ambiente Nacional. Neste caso, a responsabilidade de compartilhamento de seus documentos fiscais eletrônicos para os demais interessados permanece com a UF autorizadora, pois o Ambiente Nacional só assume a distribuição dos documentos fiscais eletrônicos recepcionados através de seu Web Service. Modelo Operacional de Distribuição pela RFB Para facilitar a operacionalização do processo, além do Web Service de Recepção de documentos fiscais, o Ambiente Nacional oferecerá um Web Service de Distribuição de documentos fiscais que poderá ser acessado pela UF que desejar receber os documentos fiscais que lhe foram destinados pelas demais unidades federadas em um único ponto. Esta arquitetura favorece a implantação do modelo ao não exigir que as UF mantenham WS de alta disponibilidade para recepcionar os documentos fiscais distribuídos pelo Ambiente Nacional, além de ser muito mais simples de construir aplicações clientes para consumir os WS oferecidos pelo Ambiente Nacional. 2.3 Compartilhamento de outras informações através de Web Service Existem outras informações de interesse do Projeto NF-e que precisam ser compartilhadas com todos os envolvidos do projeto, como por exemplo o Cadastro Nacional de Emissores de Documentos Fiscais Eletrônicos. A arquitetura que tem o Ambiente Nacional como repositório central destas informações parece ser a solução mais adequada do ponto de vista operacional e tecnológico para o Projeto da NF-e, devendo ser utilizada sempre que possível. Fluxo de Compartilhamento do Cadastro Nacional de Emissores Órgão gerador da informação Internet Receita Federal do Brasil (Ambiente Nacional) Internet Órgãos consumidores da Informação Modelo Operacional de Compartilhamento do Cadastro Nacional de Emissores A SEFAZ de origem, responsável pelo credenciamento de novos emissores deve transmitir as informações dos novos emissores, bem como as alterações da situação de credenciamento que Pág. 9 / 68

10 ocorrerem para o Web Service de manutenção do Cadastro Nacional de Emissores do Ambiente Nacional. O Ambiente Nacional manterá o Cadastro Nacional de Emissores atualizado disponível para consulta pública e um Web Service para download do cadastro para órgãos públicos conveniados. A consulta pública do Cadastro Nacional de Emissores deve ser oferecida para que o público em geral e os demais interessados consigam verificar se um determinado estabelecimento é credenciado a emitir DF-e em alguma UF. A consulta será por CNPJ, devendo retornar todas as informações existentes no Cadastro Nacional de Emissores que inclui a situação atual e todo o histórico da situação de credenciamento da empresa consultada. Os órgãos conveniados poderão solicitar o download do Cadastro Nacional de Emissores resumido contendo a UF, CNPJ e o tipo do DF-e que está credenciado a emitir. O Cadastro Nacional de Emissores resumido deverá ser utilizado para as UF que oferecem a consulta cadastral de contribuintes do ICMS para verificar se o solicitante da consulta é emissor de DF-e credenciado em alguma UF. O movimento de atualização do Cadastro Nacional de Emissores de um determinado período será oferecido para download e deverá também ser utilizado pelo SCAN e DPEC. Pág. 10 / 68

11 3. Arquitetura de Distribuição 3.1 Modelo Conceitual da Distribuição de DF-e O TED-DIST é o modelo de compartilhamento de documentos fiscais eletrônicos padrão dos projetos de documentos fiscais eletrônicos do ENCAT e maiores detalhes técnicos da arquitetura e de funcionamento devem ser obtidos no respectivo manual técnico da aplicação. Para as administrações tributárias interessadas, o Ambiente Nacional irá oferecer uma opção de compartilhamento de documentos fiscais eletrônicos baseada em WS, com os seguintes serviços: a) Recepção de DF-e; b) Distribuição de DF-e; c) Consulta protocolos faltantes; Para cada serviço oferecido existirá um Web Service específico. O fluxo de comunicação é sempre iniciado pelo aplicativo da administração tributária interessada através do envio de uma mensagem ao Web Service com a solicitação do serviço desejado. O processamento da solicitação de serviço é concluído na mesma conexão, com a devolução de uma mensagem com o resultado do processamento do serviço solicitado. Arquitetura de Distribuição de DF-e - Visão Origem DF-e Ambiente Nacional (RFB) Cliente AN HTTPS Internet HTTPS : Web Services DF-e TED-DIST Destino DF-e Rede RIS TED-DIST Aplicação AN TED-DIST DF-e Cliente AN HTTPS Internet HTTPS Web Services DF-e Pág. 11 / 68

12 3.2 Modelo Conceitual da Manutenção do Cadastro Nacional de Emissores de DF-e O Cadastro Nacional de Emissores de DF-e será administrado pelo Ambiente Nacional que irá oferecer os seguintes serviços para os órgãos públicos interessados: a) Manutenção do Cadastro Nacional de Emissores de DF-e; b) Distribuição do Cadastro Nacional de Emissores de DF-e; Para cada serviço oferecido existirá um Web Service específico. O fluxo de comunicação é sempre iniciado pelo aplicativo do órgão público interessado através do envio de uma mensagem ao Web Service com a solicitação do serviço desejado. O processamento da solicitação de serviço é concluído na mesma conexão, com a devolução de uma mensagem com o resultado do processamento do serviço solicitado. Arquitetura de Manutenção do Cadastro Nacional de Emissores de DF-e Visão simplificada Órgão Conveniado Cliente AN Cadastro de Emissor da UF HTT Internet HTT Ambiente Nacional (RFB) Web Services : cnemanutencao cnedistribuicao Aplicação AN Cadastro Nacional de Emissores Pág. 12 / 68

13 3.3 Padrões Técnicos Padrão de documento XML a) Padrão de Codificação A especificação do documento XML adotada é a recomendação W3C para XML 1.0, disponível em e a codificação dos caracteres será o UTF-8, assim todos os documentos XML serão iniciados com a seguinte declaração: <?xml version="1.0" encoding="utf-8"?> OBS: Lembrando que cada arquivo XML somente poderá ter uma única declaração <?xml version="1.0" encoding="utf-8"?>. Nas situações em que um documento XML pode conter outros documentos XML, como ocorre com o lote de envio de DF-e, deve-se tomar o cuidado para que exista uma única declaração no início do lote. b) Declaração namespace O documento XML deverá ter uma única declaração de namespace no elemento raiz do documento com o seguinte padrão: <loterfbnfe xmlns= > (exemplo para o XML de envio de DF-e) O uso de declaração namespace diferente do padrão estabelecido é vedado. A declaração do namespace da assinatura digital deverá ser realizada na própria tag <Signature>, conforme exemplo abaixo. Cada documento XML deverá ter o seu namespace individual em seu elemento raiz. No caso específico do lote de envio do DF-e, cada DF-e deverá ter declarado o seu namespace individual. Segue abaixo um exemplo: <?xml version="1.0" encoding="utf-8"?> <loterfbnfe xmlns=" versao="1.01"> <NFe xmlns=" <infnfe Id="NFe " versao="1.01">... <Signature xmlns=" </NFe> <NFe xmlns=" <infnfe Id="NFe " versao="1.01">... <Signature xmlns=" </NFe> <NFe xmlns=" <infnfe Id="NFe " versao="1.01">... <Signature xmlns=" </NFe> </loterfbnfe> c) Prefixo de namespace Não é permitida a utilização de prefixos de namespace. Essa restrição visa otimizar o tamanho do arquivo XML. Pág. 13 / 68

14 Assim, ao invés da declaração: <nfe:nfe xmlns:nfe= > (exemplo para o XML do DF-e com prefixo nfe) deverá ser adotado a declaração: <NFe xmlns = > d) Validação de Schema Para garantir minimamente a integridade das informações prestadas e a correta formação dos arquivos XML, as mensagens XML deverão ser submetidas ao respectivo Schema XML (XSD XML Schema Definition) Padrão de Comunicação A comunicação será baseada em Web Services disponibilizados pelo Portal do Ambiente Nacional. O meio físico de comunicação utilizado será a Internet, com o uso do protocolo SSL versão 3.0, com autenticação mútua, que além de garantir um duto de comunicação seguro na Internet, permite a identificação do servidor e do cliente através de certificados digitais, eliminando a necessidade de identificação do usuário através de nome ou código de usuário e senha. O modelo de comunicação segue o padrão de Web Services definido pelo WS-I Basic Profile. A troca de mensagens entre os Web Services do Ambiente Nacional e o aplicativo da administração tributária interessada será realizada no padrão SOAP versão 1.2, com troca de mensagens XML no padrão Style/Enconding: Document/Literal. A chamada de diferentes Web Services de compartilhamento de DF-e é realizado com o envio de uma mensagem XML através do parâmetro nfedadosmsg. A versão do leiaute da mensagem XML contida no parâmetro nfedadosmsg, o indicador de compactação e o código da UF requisitante serão informados nos elementos versaodados, indcomp e cuf, todos do tipo string localizados no elemento nfecabecmsg do SOAP Header. Exemplo de uma mensagem requisição padrão SOAP: <?xml version="1.0" encoding="utf-8"?> <soap12:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap12=" <soap12:header> <nfecabecmsg xmlns=" <cuf>string</cuf> <indcomp>string</indcomp> <versaodados>string</versaodados> </nfecabecmsg> </soap12:header> <soap12:body> <nferecepcaolote xmlns=" <nfedadosmsg>xml</nfedadosmsg> </nferecepcaolote> </soap12:body> </soap12:envelope> Exemplo de uma mensagem de retorno padrão SOAP: <?xml version="1.0" encoding="utf-8"?> Pág. 14 / 68

15 <soap12:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap12=" <soap12:header> <nfecabecmsg xmlns=" <cuf>string</cuf> <indcomp>string</indcomp> <versaodados>string</versaodados> </nfecabecmsg> </soap12:header> <soap12:body> <nferecepcaoloteresponse xmlns=" <nferecepcaoloteresult>xml</nferecepcaoloteresult> </nferecepcaoloteresponse> </soap12:body> </soap12:envelope> Padrão de Certificado Digital O certificado digital utilizado no estabelecimento da conexão segura com autenticação mútua será emitido por Autoridade Certificadora credenciada pela Infra-estrutura de Chaves Públicas Brasileira ICP-Brasil, tipo A1 ou A3, devendo conter o CNPJ da pessoa jurídica titular do certificado digital no campo othername OID = e ter a extensão Extended Key Usage com permissão de "Autenticação Cliente". A identificação do órgão conveniado será feita através do CNPJ do certificado digital. O Ambiente Nacional manterá uma tabela com objetivo de controlar o envio e recepção de DF-e pelos órgãos conveniados, vinculando o CNPJ com o órgão correspondente Padrão de compactação O padrão de compactação adotado para o projeto será o Gzip (GNU zip) que é implementado nas plataformas Java e.net framework 2.0 (classe System.IO.Compression.GZipStream) Resumo dos Padrões Técnicos A tabela a seguir resume os principais padrões de tecnologia utilizados: Característica Descrição Web Services Padrão definido pelo WS-I Basic Profile 1.1 ( Meio lógico de comunicação Web Services, disponibilizados pelo Portal do Ambiente Nacional. Meio físico de comunicação Internet Protocolo Internet SSL versão 3.0, com autenticação mútua através de certificados digitais. Padrão de troca de mensagens SOAP versão 1.2. Padrão da mensagem XML no padrão Style/Encoding: Document/Literal. Padrão de certificado digital X.509 versão 3, emitido por Autoridade Certificadora credenciada pela Infra-estrutura de Chaves Públicas Brasileira ICP-Brasil, do tipo A1 ou A3, devendo conter o CNPJ do proprietário do certificado digital. Padrão de compactação Gzip (GNU zip) 3.4 Padrão de mensagens dos Web Services As chamadas dos Web Services disponibilizados pelo Ambiente Nacional e os respectivos resultados do processamento são realizadas através das mensagens com o seguinte padrão: Pág. 15 / 68

16 Padrão de Mensagem de chamada/retorno de Web Service cuf indcomp versaodados Estrutura XML definida na documentação do Web Service Elemento nfecabecmsg (SOAP Header) Área de dados (SOAP Body) cuf código da UF de origem da mensagem. indcomp indicador de compactação da área de dados (0 sem compactação, 1 compactação padrão Gzip). versaodados - versão do leiaute da estrutura XML informado na área de dados. Área de Dados estrutura XML variável definida na documentação do Web Service acessado. Codificação do cuf adotada: Região Norte Região Nordeste Região Sudeste Região Sul Região Centro- Oeste 11-Rondônia 12-Acre 13-Amazonas 14-Roraima 15-Pará 16-Amapá 17-Tocantins 21-Maranhão 22-Piauí 23-Ceará 24-Rio Grande do Norte 25-Paraíba 26-Pernambuco 27-Alagoas 28-Sergipe 29-Bahia 31-Minas Gerais 32-Espírito Santo 33-Rio de Janeiro 35-São Paulo 41-Paraná 42-Santa Catarina 43-Rio Grande do Sul 50-Mato Grosso do Sul 51-Mato Grosso 52-Goiás 53-Distrito Federal Obs.: A SUFRAMA será identificada com o código Informações de controle e área de dados das mensagens As informações de controle das chamadas dos Web Services são armazenadas no elemento nfecabecmsg do SOAP Header e servem para identificar a UF de origem, o indicador de compactação e a versão do leiaute da estrutura XML armazenada na área de dados da mensagem: <soap12:header> <nfecabecmsg xmlns=" <cuf>string</cuf> <indcomp>string</indcomp> <versaodados>string</versaodados> </nfecabecmsg> </soap12:header> A informação armazenada na área de dados é um documento XML que deve atender o leiaute definido na documentação do Web Service acessado: <soap12:body> <nferecepcaoloteresponse xmlns=" <nferetornomsg>xml</nferetornomsg> </nferecepcaoloteresponse> </soap12:body> Validação da estrutura XML das Mensagens dos Web Services As informações são enviadas ou recebidas dos Web Services através de mensagens no padrão XML definido na documentação de cada Web Service. Pág. 16 / 68

17 As alterações de leiaute e da estrutura de dados XML realizadas nas mensagens são controladas através da atribuição de um número de versão para a mensagem. Um Schema XML é uma linguagem que define o conteúdo do documento XML, descrevendo os seus elementos e a sua organização, além de estabelecer regras de preenchimento de conteúdo e de obrigatoriedade de cada elemento ou grupo de informação. A validação da estrutura XML da mensagem é realizada por um analisador sintático (parser) que verifica se a mensagem atende as definições e regras de seu Schema XML. Qualquer divergência da estrutura XML da mensagem em relação ao seu Schema XML, provoca um erro de validação do Schema XML. A primeira condição para que a mensagem seja validada com sucesso é que ela seja submetida ao Schema XML correto. Assim, os aplicativos clientes devem estar preparados para gerar as mensagens no leiaute em vigor, devendo ainda informar a versão do leiaute da estrutura XML da mensagem no campo versaodados do elemento nfecabecmsg do SOAP Header. <soap12:header> <nfecabecmsg xmlns=" <cuf>35</cuf> <indcomp>0</indcomp> <versaodados>1.00</versaodados> </nfecabecmsg> </soap12:header> Schemas XML das Mensagens dos Web Services Qualquer mudança de leiaute das mensagens dos Web Services implica na atualização do seu respectivo Schema XML. A identificação da versão dos Schemas será realizada com o acréscimo do número da versão no nome do arquivo precedida da literal _v, como segue: nfe_v1.00.xsd (Schema XML da NF-e, versão 1.00); tiposbasico_v10.15.xsd (Schema XML dos tipos básicos da NF-e, versão 10.15). A maioria dos Schemas XML do DF-e utilizam as definições de tipos básicos ou tipos complexos que estão definidos em outros Schemas XML (ex.: tiposbasico_v1.00.xsd, etc.), nestes casos, a modificação de versão do Schema básico será repercutida no Schema principal. Por exemplo, o tipo numérico de 15 posições com 2 decimais é definido no Schema tiposbasico_v1.01.xsd, caso ocorra alguma modificação na definição deste tipo, todos os Schemas que utilizam este tipo básico devem ter a sua versão atualizada e as declarações import ou include devem ser atualizadas com o nome do Schema básico atualizado. Exemplo de Schema XML <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:ds=" xmlns:xs=" xmlns=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:import namespace=" schemalocation="xmldsig-coreschema_v1.01.xsd"/> <xs:include schemalocation="tiposbasico_v1.01.xsd"/> <xs:element name="nfelote"> <xs:annotation> <xs:documentation>lote de documento fiscal eletrônico</xs:documentation> </xs:annotation> Pág. 17 / 68

18 As modificações de leiaute das mensagens dos Web Services podem ser causadas por necessidades técnicas ou em razão da modificação de alguma legislação. As modificações decorrentes de alteração da legislação deverão ser implementadas nos prazos previstos no ato normativo que introduziu a alteração. As modificações de ordem técnica serão divulgadas pela Coordenação Técnica do ENCAT e poderão ocorrer sempre que se fizerem necessárias. 3.5 Versão dos Schemas Liberação das versões dos Schemas para o WS do Ambiente Nacional Os schemas válidos para o WS do Ambiente Nacional serão disponibilizados no sítio nacional do Projeto ( e serão liberados após autorização da Coordenação Técnica do Projeto. A cada nova liberação será disponibilizado um arquivo compactado contendo o conjunto de schemas a serem utilizados pelos Órgãos Públicos para a geração dos arquivos XML. Este arquivo será denominado Pacote de Liberação e terá a mesma numeração da versão do que lhe é compatível. Os pacotes de liberação serão identificados pelas letras PL_CompNFe, seguida do número da versão do correspondente. Exemplificando: O pacote PL_CompNFe_1.00.zip representa o Pacote de Liberação de schemas do WS do Ambiente Nacional compatíveis com o de Compartilhamento de Informações entre Órgãos Públicos versão Os schemas XML das mensagens XML do projeto são identificados pelo seu nome, seguido da versão do respectivo schema. Assim, para o schema XML de Envio de Lotes de Documento Fiscal eletrônico, corresponderá um arquivo com a extensão.xsd, que terá o nome de loterfbnfe_v9.99.xsd, onde v9.99, corresponde à versão do respectivo schema. Para identificar quais os schemas que sofreram alteração em um determinado pacote liberado, devese comparar o número da versão do schema deste pacote com o do pacote anterior. Exemplificando: PACOTE PL_NFe_1.00.ZIP PL_NFe_1.01.ZIP DATA LIBERAÇÃO 01/04/ /06/2008 SCHEMAS loterfbnfe_v1.00.xsd loterfbnfe _v1.30.xsd distnfe_v1.00.xsd distnfe_v1.00.xsd tiposbasico_v1.00.xsd tiposbasico _v1.01.xsd Pacote de Liberação Preliminar Após a divulgação de uma nova versão do de Compartilhamento de Informações entre Órgãos Públicos versão 1.00, será divulgado um pacote de liberação preliminar com vigência limitada até o início da fase de disponibilização do ambiente de homologação. Durante este período, os novos Schemas XML serão avaliados e testados para a identificação de eventuais falhas de implementação das alterações realizadas no de Compartilhamento de Informações entre Órgãos Públicos versão O PL preliminar será identificado com o acréscimo do literal pre na identificação do pacote, como por exemplo: PL_CompNFe_1.00pre.zip Pacote de Liberação de Homologação e Pacote de Liberação definitivo Pág. 18 / 68

19 Para o ambiente de homologação será divulgado um pacote de liberação de homologação identificado com o acréscimo da literal hom na identificação do pacote, como por exemplo: PL_CompNFe_100hom.zip. A principal característica do pacote de liberação de homologação é seu uso estar restrito ao ambiente de homologação por aceitar somente mensagens XML com tpamb=2-homologação. O pacote de liberação definitivo será divulgado na véspera da data de início da vigência do ambiente de produção Correção de Pacote de Liberação Em algumas situações pode surgir a necessidade de correção de um Schema XML por um erro de implementação de regra de validação, obrigatoriedade de campo, nome de tag divergente do definido no leiaute da mensagem, que não modifica a estrutura do Schema XML e nem exige a alteração dos aplicativos da SEFAZ. Nesta situação, divulgaremos um novo pacote de liberação com o Schema XML corrigido, sem modificar o número da versão do PL para manter a compatibilidade com o de Compartilhamento de Informações entre Órgãos Públicos vigente. A identificação dos pacotes mais recentes se dará com o acréscimo de letra minúscula do alfabeto, como por exemplo: NFe_PL_1.00a.ZIP, indicando que se trata da primeira versão corrigida do NFe_PL_1.00.ZIP Divulgação de novos Pacotes de Liberação A divulgação de novos pacotes de liberação ou atualizações de pacote de liberação será realizada através da publicação de Notas Técnicas pela Coordenação do ENCAT com as informações necessárias para a implementação dos novos pacotes de liberação Controle de Versão O controle de versão de cada um dos schemas válidos para o WS do Ambiente Nacional compreende uma definição nacional sobre: qual a versão vigente (versão mais atualizada); quais são as versões anteriores ainda suportadas por todas as SEFAZ. Este controle de versões permite a adaptação dos sistemas de informática de alguns órgãos em diferentes datas. Ou seja, alguns órgãos poderão estar com uma versão de leiaute mais atualizada, enquanto outros poderão ainda estar operando com mensagens em um leiaute anterior. Mensagens recebidas com uma versão de leiaute não suportada serão rejeitadas com uma mensagem de erro específica na versão do leiaute de resposta mais recente em uso. Pág. 19 / 68

20 4. Web Services Os Web Services disponibilizam os serviços que serão utilizados pelos aplicativos das UF interessadas. O mecanismo de utilização dos Web Services segue as seguintes premissas: a) Será disponibilizado um Web Service por serviço, existindo um método para cada tipo de serviço; b) O envio da solicitação e a obtenção do retorno serão realizados na mesma conexão através de um único método. c) As URL dos Web Services encontram-se no Anexo II deste manual. Acessando a URL pode ser obtido o WSDL (Web Services Description Language) de cada Web Service. d) O processo de utilização dos Web Services sempre é iniciado pelo órgão conveniado enviando uma mensagem nos padrões XML e SOAP, através do protocolo SSL com autenticação mútua. e) A ocorrência de qualquer erro na validação dos dados recebidos interrompe o processo com a disponibilização de uma mensagem contendo o código e a descrição do erro. Pág. 20 / 68

21 4.1 Serviço de Recepção de DF-e O Serviço de Recepção de DF-e é o serviço oferecido pelo WS do Ambiente Nacional para atualização do repositório do Ambiente Nacional com os DF-e autorizados pela UF Web Service NFeRecepcaoRFB Recepção Ambiente Nacional SEFAZ Receita Federal do Brasil Envio de Lotes de NF-e, Cancelamento de NF-e, Inutilização de Numeração de NF-e e CC-e Web Service : NFeRecepcaoRFB nferecepcaolote Proc. Ret Recepção Client AN Aplicação AN Retorno Função: serviço destinado à recepção de mensagens de lote de NF-e. Processo: síncrono. Método: nferecepcaolote Leiaute Mensagem de Entrada Entrada: Estrutura XML com o lote documentos fiscais Schema XML: loterfbnfe_v9.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação AP01 loterfbnfe Raiz TAG raiz AP02 versao A AP01 N Versão do leiaute AP03 veraplic E AP01 C Versão da aplicação do órgão autorizador. AP04 loteenvnfecomp CE AP01 B Conjunto de DF-e compactado com o método indicado no indcomp, somente será informado se indcomp <> 0 sem compactação. O tipo do campo é base64binary. Deve conter as mesmas informações do grupo dados (AP05). AP05 loteenvnfe CG AP01 xml Conjunto de DF-e enviados. AP06 versao A AP05 N 1-1 Versão do leiaute AP07 proc G AP Grupo de proc AP08 schema A AP07 C 1-1 Identificação do Schema XML que será utilizado para validar o XML existente no campo seguinte. Vai identificar o tipo do proc e a versão: Ex. procnfe_v1.10.xsd. AP09 (any) G AP07 xml 1-1 Estrutura genérica do proc, o nome da tag pode ser qualquer a de qualquer proc válido Pág. 21 / 68

22 Diagrama simplificado do Schema XML: loterfbnfe_v9.99.xsd Pág. 22 / 68

23 4.1.3 Leiaute Mensagem de Retorno Retorno: Estrutura XML com a mensagem do resultado da transmissão. Schema XML: retloterfbnfe_v9.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação AR01 retloterfbnfe Raiz TAG raiz da Resposta AR02 versao A AR01 N Versão do leiaute AR03 tpamb E AR01 N Identificação do Ambiente: 1 Produção / 2 - Homologação AR04 veraplic E AR01 C Versão da aplicação do AN. AR05 cstat E AR01 N Código do status da resposta (vide item 5.1.1) AR06 xmotivo E AR01 C Descrição literal do status da resposta AR07 retprocnfe G AR Retorno de processamento dos DF-e, somente é gerado se os documentos fiscais forem válidos (sem erro de Schema). AR08 nprot E AR07 N Número de protocolo do DF-e processado, o campo serve para a aplicação da SEFAZ identificar os retornos. AR09 cstat E AR07 N Código do status do processamento do DF-e (vide item 5.1.1) AR10 xmotivo E AR07 C Descrição literal do status do processamento do DF-e AR11 NSU E AR07 N Número seqüencial único do Ambiente Nacional Pág. 23 / 68

24 Diagrama simplificado do Schema XML: retloterfbnfe_v9.99.xsd Descrição do Processo de Geração de Lotes de DF-e As Secretarias de Fazenda autorizadoras de NF-e com aplicação própria, a SEFAZ Virtual RS e a SEFAZ Virtual do Ambiente Nacional são os potenciais usuários deste Serviço de envio de DF-e. Para efeito deste manual é Documento Fiscal eletrônico DF-e: a NF-e e respectiva autorização ou denegação de uso; o Pedido de Cancelamento de NF-e e respectiva homologação de cancelamento; o Pedido de Inutilização de NF-e e respectiva homologação de inutilização; o Evento da NF-e e respectiva homologação de registro; A Secretaria de Fazenda atribui um número do protocolo para identificar univocamente as transações realizadas de autorização de uso, denegação de uso, cancelamento de NF-e, inutilização de numeração de NF-e e o Evento da NF-e. A regra de formação do número do protocolo é: Tipo de Autorizador código da UF ano seqüencial de 10 posições Pág. 24 / 68

25 1 posição com o Tipo de Autorizador (1=SEFAZ normal, 2= Contingência SCAN - RFB, 3=SEFAZ VIRTUAL-RS, 4=SEFAZ VIRTUAL-RFB); 2 posições para o código da UF do IBGE; 2 posições para ano; 10 posições para o seqüencial no ano. É importante que a geração do número de protocolo pela SEFAZ de origem seja única e utilizada por todos os Web Services que precisam atribuir um número de protocolo para o resultado do processamento, pois o número de protocolo é o referencial básico para sincronização de banco de dados. A Secretaria de Fazenda Estadual deverá manter um controle interno em sua aplicação visando garantir que todos os documentos por ela autorizados tenham sido recebidos e processados pelo Ambiente Nacional. Recomendamos fortemente que as aplicações das Secretarias de Fazenda mantenham uma tabela de log de uso dos números de protocolos que contenha, no mínimo, as seguintes informações: código de UF de origem; tipo de autorizador; número do protocolo; identificação da transação para o qual foi atribuído o número do protocolo (chave de acesso para autorização/denegação de uso, cancelamento de NF-e e Evento da NF-e ou o CNPJ, ano, modelo, série, número inicial e final da faixa de numeração inutilizada); código da UF de destino da NF-e; indicador de envio para SUFRAMA; Exemplo de tabela de log: Protocolo Origem Autorizador Trans. Id Trans. Destino Suframa InutNF-e NF-e EventoNF-e NF-e T CancNF-e a) Geração do lote A aplicação cliente do WS deve gerar os lotes respeitando a ordem crescente dos números de protocolos para que seja respeitada a ordem cronológica do processo de geração das transações (o número do protocolo de uma homologação de cancelamento de NF-e é sempre posterior ao número do protocolo da autorização de uso da NF-e cancelada, sendo importante que a autorização de uso da NF-e seja processada antes da homologação de cancelamento de NF-e). A criação do lote de documentos fiscais deve observar as seguintes premissas: ordem crescente de número de protocolos; o lote pode conter qualquer tipo de DF-e; quantidade máxima de documentos fiscais do lote: 50 DF-e; tamanho máximo do lote: 1 MB; A partir da versão 2.0, a estrutura de envio foi modificada para que seja possível o envio de qualquer DF-e, com alterações mínimas no Schema XML de compartilhamento. Para alcançar este objetivo passamos a utilizar uma estrutura genérica proc que tem um atributo schema e um elemento do tipo any que permite o envio de qualquer tipo de DF-e. Pág. 25 / 68

26 Este novo modelo possibilita a montagem de lote com qualquer tipo de DF-e; o DF-e existente no proc será identificado pelo conteúdo do atributo schema que deverá ter a mesma nomenclatura utilizada atualmente no Pacote de Liberação do Schema XML. A SEFAZ ao montar o lote, poderá incluir proc de NF-e, Pedido de Cancelamento, Pedido de inutilização de uso, etc. na estrutura tura proc,, informando o nome do schema no atributo schema e o XML na tag any. Exemplo de lote com NF-e, Pedido de Cancelamento e Pedido de Inutilização: <?xml version="1.0" encoding="utf-8"?> <loterfbnfe xmlns=" versao="2.00"> <veraplic>an100</veraplic> <loteenvnfe versao="2.00"> <proc schema="procnfe_v1.10.xsd"> <nfeproc versao="1.10">(...) (...)</nfeproc> </proc> <proc schema="procnfe_v2.00.xsd"> <nfeproc versao="2.00">(...) (...)</nfeproc> </proc> <proc schema="proccancnfe_v1.07.xsd"> <proccancnfe versao="1.07">(...)</proccancnfe> </proc> <proc schema="procinutnfe_v1.07.xsd"> <ProcInutNFe versao="1.07">(...)</procinutnfe> </proc> <proc schema="procnfe_v1.10.xsd"> <nfeproc versao="1.10">(...) (...)</nfeproc> </proc> <proc schema="proccancnfe_v2.00.xsd"> <proccancnfe versao="2.00">(...)</proccancnfe> </proc> </loteenvnfe> </loterfbnfe> Pág. 26 / 68

27 b) Compactação do lote Será permitido o uso de algoritmo de compactação dos DF-e no padrão Gzip para otimizar o uso da rede. O processo de compactação deve ser aplicado na estrutura padrão de lote (loteenvnfe AP05). A seqüência binária resultante da compactação deve ser convertida em uma representação Base64 e informada no campo loteenvnfecomp (AP04). Estimamos que o processo de compactação reduza o tamanho do lote para 40% do tamanho original, significando uma otimização no tempo de transmissão dos lotes. c) Informações de controle A informação da versão do leiaute dos dados, indicador de compactação dos dados e a UF de origem são informados no elemento nfecabecmsg do SOAP Header (para maiores detalhes vide item 3.4). d) Envio das informações A mensagem do lote será transmitida através do Web Service do Ambiente Nacional, sendo necessário que o CNPJ utilizado na transmissão da SEFAZ esteja previamente cadastrado no Ambiente Nacional. Será permitido o uso do certificado digital da SEFAZ Virtual nos casos em que a transmissão seja realizada pela SEFAZ Virtual Descrição do Processo de Recepção de Lotes de DF-e O WS do Ambiente Nacional é acionado pela SEFAZ que deve enviar um Lote de DF-e que atenda os padrões estabelecidos neste manual Validação do Certificado de Transmissão Validação do Certificado Digital do Transmissor (protocolo SSL) # Regra de Validação Crítica Msg Efeito A01 Certificado de Transmissor Inválido: - Certificado de Transmissor inexistente na mensagem - Versão difere "3" - Se informado o Basic Constraint deve ser true (não pode ser Certificado de AC) - KeyUsage não define "Autenticação Cliente" Obrig. 280 Rej. A02 Validade do Certificado (data início e data fim) Obrig. 281 Rej. A03 Verifica a Cadeia de Certificação: - Certificado da AC emissora não cadastrado na RFB - Certificado de AC revogado - Certificado não assinado pela AC emissora do Certificado A04 LCR do Certificado de Transmissor - Falta o endereço da LCR (CRL DistributionPoint) - LCR indisponível - LCR inválida Obrig. 283 Rej. Obrig. 286 Rej. A05 Certificado do Transmissor revogado Obrig. 284 Rej. A06 Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej. Pág. 27 / 68

28 A07 Falta a extensão de CNPJ no Certificado (OtherName - OID= ) Obrig. 282 Rej. As validações de A01, A02, A03, A04 e A05 são realizadas pelo protocolo SSL e não precisam ser implementadas. A validação A06 também pode ser realizada pelo protocolo SSL, mas pode falhar se existirem outros certificados digitais de Autoridade Certificadora Raiz que não sejam ICP-Brasil no repositório de certificados digitais do servidor de Web Service do Ambiente Nacional Validação Inicial da Mensagem no Web Service Validação Inicial da Mensagem no Web Service # Regra de Validação Aplic. Msg Efeito B01 Tamanho do XML de Dados superior a 1 MB Obrig. 214 Rej. B02 XML de Dados Mal Formado Obrig. 243 Rej. B03 Verifica se o Servidor de Processamento está Paralisado Momentaneamente Obrig. 108 Rej. B04 Verifica se o Servidor de Processamento está Paralisado sem Previsão Obrig. 109 Rej. A mensagem será descartada se o tamanho exceder o limite previsto (1 MB). A aplicação da Secretaria de Fazenda não poderá permitir a geração de mensagem com tamanho superior a 1 MB. Caso isto ocorra, a conexão poderá ser interrompida sem retorno da mensagem de erro se o controle do tamanho da mensagem for implementado por configurações do ambiente de rede do Ambiente Nacional (ex.: controle no firewall). No caso do controle de tamanho ser implementado por aplicativo teremos a devolução da mensagem de erro 214. Caso o Web Service fique disponível, mesmo quando o serviço estiver paralisado, deverão implementar as verificações 108 e 109. Estas validações poderão ser dispensadas se o Web Service não ficar disponível quando o serviço estiver paralisado Validação das informações de controle da chamada ao Web Service Validação das informações de controle da chamada ao Web Service # Regra de Validação Aplic. Msg Efeito C01 Elemento nfecabecmsg inexistente no SOAP Header Obrig. 409 Rej. C02 Campo cuf inexistente no elemento nfecabecmsg do SOAP Header Obrig. 410 Rej. C03 Verificar se a UF informada no campo cuf é válida Obrig. 411 Rej. C04 Campo versaodados inexistente no elemento nfecabecmsg do SOAP Header Obrig. 412 Rej. C05 Versão dos Dados informada é superior à versão vigente Facult. 238 Rej. C06 Versão dos Dados não suportada Obrig. 239 Rej. C07 Campo indcomp inexistente no elemento nfecabecmsg do SOAP Header Obrig. 413 Rej. C08 indcomp com conteúdo inválido (diferente de 0 ou 1) Obrig. 414 Rej. C09 indcomp = 0 e tag loteenvnfe inexistente Obrig. 430 Rej. C10 indcomp = 1 e tag loteenvnfecomp inexistente Obrig. 431 Rej. C11 CNPJ do transmissor não está autorizado a enviar DF-e desta UF (vide Anexo I - Tabela de órgãos conveniados) Obrig. 415 Rej. A informação da versão do leiaute do lote e a UF de origem da mensagem são informados no elemento nfecabecmsg do SOAP Header (para maiores detalhes vide item 3.4). A aplicação deverá validar a UF (cuf), indicador de compactação (indcomp) e versão da mensagem (versaodados), rejeitando a solicitação recebida em caso de informações inexistentes ou inválidas. Pág. 28 / 68

29 4.1.9 Validação da área de Dados a) Validação de forma da área de dados A validação de forma da área de dados da mensagem é realizada com a aplicação da seguinte regra: Validação da área de dados da mensagem # Regra de Validação Aplic. Msg Efeito D01 Verifica Schema XML da Área de Dados Obrig. 215 Rej. D02 Verifica o uso de prefixo no namespace Obrig. 404 Rej. D03 XML utiliza codificação diferente de UTF-8 Obrig. 402 Rej. Importante: A validação não é realizada na proc genérica, pois o campo tem definição: <xs:element name="proc"> <xs:complextype> <xs:sequence> <xs:any processcontents="skip"> <xs:annotation> <xs:documentation>informação do proc</xs:documentation> </xs:annotation> </xs:any> </xs:sequence> <xs:attribute name="schema" type="xs:string" use="required"> <xs:annotation> <xs:documentation>identificação do Schema XML de validação do proc</xs:documentation> </xs:annotation> </xs:attribute> </xs:complextype> </xs:element> b) Validação da área de Dados compactada Validação da área de dados compactada # Regra de Validação Aplic. Msg Efeito D04 Falha na descompactação Obrig. 416 Rej. D05 XML de Dados descompactado Mal Formado Obrig. 243 Rej. D06 Verifica Schema XML da Área de Dados descompactado Obrig. 426 Rej. D07 Verifica o uso de prefixo no namespace nos dados descompactados Obrig. 427 Rej. Caso a área de dados esteja compactada (indcomp <> 0) é necessário descompactar as informações e validar a área de dados descompactada com o Schema LoteRFBNFe_v.101.xsd. c) Validação do Schema XML do proc Validação da área do proc # Regra de Validação Aplic. Msg Efeito D08 Verificar se o conteúdo informado no atributo schema do proc é válido (existe schema com o mesmo nome). D09 Validar o filho da tag proc (any) com o Schema XML informado no atributo schema do proc. Obrig. 569 Rej. Obrig. 569 Rej. Pág. 29 / 68

30 A escolha do Schema XML a ser utilizado é realizada com base no conteúdo informado no atributo schema da tag proc, exemplos de proc: 1. proc de uma NF-e, versão 1.10: <proc schema="procnfe_v1.10.xsd"> <nfeproc versao="1.10">(...)</nfeproc> </proc> 2. proc de uma NF-e, versão 2.00: <proc schema="procnfe_v2.00.xsd"> <nfeproc versao="2.00">(...)</nfeproc> </proc> 3. proc de um pedido de cancelamento de NF-e, versão 1.07: <proc schema="proccancnfe_v1.07.xsd"> <proccancnfe versao="1.07">(...)</proccancnfe> </proc> IMPORTANTE: uma conseqüência desta alteração é que a rejeição por falha de schema XML será documento a documento e não mais do lote como era antes, isto é, somente os documentos com falha de preenchimento serão rejeitados, este comportamento é diverso do anterior que rejeitava o lote todo. d) Validação do Certificado Digital de Assinatura A seguir são extraídos todos os DF-e da mensagem de envio de lote e validada a assinatura digital de cada DF-e: Validação do Certificado Digital utilizado na Assinatura Digital do DF-e # Regra de Validação Aplic. Msg Efeito E01 Certificado de Assinatura inválido: - Certificado de Assinatura inexistente na mensagem (*validado também pelo Schema) - Versão difere "3" - Se informado o Basic Constraint deve ser true (não pode ser Certificado de AC) - KeyUsage não define "Assinatura Digital" e Não Recusa Obrig. 290 Rej. E02 Validade do Certificado (data início e data fim) Obrig. 291 Rej. E03 Falta a extensão de CNPJ no Certificado (OtherName - OID= ) E04 Verifica Cadeia de Certificação: - Certificado da AC emissora não cadastrado na SEFAZ - Certificado de AC revogado - Certificado não assinado pela AC emissora do Certificado Obrig. 292 Rej. Obrig. 293 Rej. E05 LCR do Certificado de Assinatura: - Falta o endereço da LCR (CRLDistributionPoint) - Erro no acesso a LCR ou LCR inexistente Obrig. 296 Rej. E06 Certificado de Assinatura revogado Obrig. 294 Rej. E07 Certificado Raiz difere da ICP-Brasil Obrig. 295 Rej. Importante ressaltar que um proc é composto por um documento gerado pelo contribuinte (NF-e, CancNF-e, InutNF-e, CC-e, etc.) e pelo respectivo protocolo de autorização de uso, homologação, etc da SEFAZ autorizadora, ambos documentos tem previsão de assinatura digital, contudo, os protocolos não têm sido assinado pela SEFAZ atualmente. Pág. 30 / 68

31 Como regra geral, a assinatura é realizada pelo emissor do documento, que é o contribuinte, mas podem existir casos como a NF-e avulsa e outros casos como a confirmação de recebimento que pode ser assinado pela SEFAZ que gerou o documento em nome de seu contribuinte. e) Validação da Assinatura Digital Validação da Assinatura Digital do DF-e # Regra de Validação Aplic. Msg Efeito F01 Assinatura difere do padrão do Projeto: - Não assinado o atributo "ID" (falta "Reference URI" na assinatura) (*validado também pelo Schema) - Faltam os "Transform Algorithm" previstos na assinatura ("C14N" e "Enveloped") Estas validações são implementadas pelo Schema XML da Signature Obrig. 298 Rej. F02 Valor da assinatura (SignatureValue) difere do valor calculado Obrig. 297 Rej. F03 CNPJ-Base do Autor do documento difere do CNPJ-Base do Certificado Digital Obrig. 213 Rej. f) Validação de regras de negócios do DF-e Validação do DF-e Regras de Negócios # Regra de Validação Aplic. Msg Efeito G01 Tipo do ambiente do DF-e difere do ambiente do Web Service Obrig. 252 Rej. G02 Código da UF do DF-e difere do Código da UF do SOAP Header Obrig. 432 Rej. G02a Verificar se a data do protocolo (dhrecbto) é válida Obrig. 571 Rej. G02b Verificar se o cstat do protocolo é válido (100-autorização de uso NF-e, 101- Obrig. 572 Rej. Cancelamento, 102-Inutilização, 135-Evento registrado, 301-denegação Emissor), verificar a necessidade de contemplar o 302. G02c Verificar se o protocolo pertence ao documento (a vinculação pode ser Obrig. 573 Rej. verificada pela chave da NF-e, com exceção da inutilização que envolve outros campos (ano, CNPJ, série, nro inicial, nro final) G03 Número da NF-e (Chave: Ano, CNPJ Emit, Modelo, Série, Nro): número Obrig. 206 Rej. inutilizado G04 NF-e (Chave: Ano, CNPJ Emit, Modelo, Série, Nro): já existe e NF-e Obrig. 218 Rej. cancelada G05 NF-e (Chave: Ano, CNPJ Emit, Modelo, Série, Nro) já existe Obrig. 204 Rej. G06 NF-e (Chave: Ano, CNPJ Emit, Modelo, Série, Nro): já existe e NF-e denegada Obrig. 205 Rej. G07 Cancelamento NF-e (Chave: Ano, CNPJ Emit, Modelo, Série, Nro) para NF-e Obrig. 217 Rej. inexistente G08 Cancelamento NF-e (Chave: Ano, CNPJ Emit, Modelo, Série, Nro) para NF-e Obrig. 419 Rej. denegada G09 Cancelamento NF-e (Chave: Ano, CNPJ Emit, Modelo, Série, Nro) já realizado Obrig. 420 Rej. G09a Inutilização de Numeração de NF-e - exatamente a mesma faixa de numeração já está inutilizada G10 Inutilização de Numeração de NF-e um número da faixa já se encontra inutilizado G11 Inutilização de Numeração de NF-e um número da faixa já se encontra utilizado G12 Evento da NF-e (Chave: Ano, CNPJ Emit, Modelo, Série, Nro) para NF-e inexistente G13 Evento da NF-e (Chave: Ano, CNPJ Emit, Modelo, Série, Nro) para NF-e cancelada Verificar as hipóteses Pág. 31 / 68 Obrig 563 Rej. Obrig. 256 Rej. Obrig. 241 Rej. Obrig. 421 Rej. Obrig. 422 Rej.

32 Validação do DF-e Regras de Negócios # Regra de Validação Aplic. Msg Efeito G14 Evento da NF-e (Chave: Ano, CNPJ Emit, Modelo, Série, Nro) para NF-e denegada Verificar as hipóteses Final do Processamento do Lote A validação do DF-e poderá resultar em: Obrig. 423 Rej. Rejeição o DF-e será descartado, com retorno do código do status do motivo da rejeição; Recebido pelo Ambiente Nacional o DF-e será armazenado no repositório do Ambiente Nacional (cstat=113); O Ambiente Nacional deve atribuir um número seqüencial único NSU para todos os DF-e recepcionados, de todas SEFAZ autorizadoras, independentemente da forma de recepção (WS do Ambiente Nacional ou TED-DIST). Sugerimos a criação de uma tabela de log com pelo menos as seguintes informações: número seqüencial único do Ambiente Nacional NSU pode ser o campo identity da Tabela; número do protocolo da transação vinculada; transação vinculada (NF-e, cancelamento, inutilização, Evento, etc.) identificação da transação vinculada (chave de acesso para autorização/denegação de uso, cancelamento de NF-e e Evento ou o CNPJ, modelo, série, número inicial e final da faixa de numeração inutilizada); código da UF de origem da NF-e; código da UF de destino da NF-e, informar a UF do solicitante no pedido de inutilização de numeração; código da UF do local de entrega do veículo no faturamento direto (tag tpop do grupo veicprod =2 e UF destino diferente da UF do local de entrega UF/entrega); indicador de envio para SUFRAMA; código da UF de Embarque (UFEmbarq, linha 403, item ZA03 do leiaute da NF-e) na exportação diferente da UF de destino ou código da UF de Desembaraço (UFDesemb, linha 122, item I23 do leiaute da NF-e) na importação quando diferente da UF de origem; indicador da forma de recepção (TED-DIST ou WS) Exemplo de tabela de log: NSU* Protocolo original* Trans. Id Trans. Origem Destino NF-e T CancNF-e T InutNF-e W NF-e W EventoNF-e W NF-e T W * chaves Esta tabela será útil para prover os demais serviços de distribuição e pesquisa de protocolos faltantes no Ambiente Nacional. Fatur. direto SUFRA MA COMEX Recep Pág. 32 / 68

33 4.2 Serviço de Distribuição de DF-e O Serviço de Distribuição de DF-e é o serviço oferecido pelo WS do Ambiente Nacional para download dos DF-e existentes no Ambiente Nacional Web Service NFeDistribuicaoRFB Distribuição Ambiente Nacional SEFAZ Receita Federal do Brasil Solicita Distribuição Web Service : NFeDistribuicaoRFB nfedistribuicaolote Proc. Ret Distribuição Client AN Lotes de NF-e, Cancelamento de NF-e, Inutilização de Numeração e CC-e Aplicação AN Função: serviço destinado à distribuição de mensagens de lote de DF-e. Processo: síncrono. Método: nfedistribuicaolote Leiaute Mensagem de Entrada Entrada: Estrutura XML com o pedido de distribuição de DF-e Schema XML: distnfe_v9.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação BP01 distnfe Raiz TAG raiz BP02 versao A BP01 N Versão do leiaute BP03 tpamb E BP01 N Identificação do Ambiente: 1 - Produção 2 Homologação BP04 veraplic E BP01 C Versão do Aplicativo que solicitou a distribuição BP05 indnfe E BP01 N Indicador de DF-e solicitados: 0 - DF-e autorizados pela UF; 1 - DF-e interestaduais destinados para a UF; 2 DF-e autorizados pela SEFAZ Virtual ou SCAN em nome da UF; 8 DF-e interestaduais destinados para a UF (1) e DF-e autorizados pela SEFAZ Virtual ou SCAN em nome da UF (2); 9 - Todos os DF-e. BP06 indcompret E BP01 N Indicador de Compactação da Mensagem de retorno: 0 - sem compactação; 1 - compactação padrão gzip BP07 ultnsu E BP01 N último NSU recebido, caso seja informado com zero, o AN tentará localizar o primeiro DF-e para a UF. Pág. 33 / 68

34 Diagrama simplificado do Schema XML: distnfe_v9.99.xsd Leiaute Mensagem de Retorno Retorno: Estrutura XML com o lote de DF-e encontrados (qtde máxima=50). Schema XML: retdistnfe_v9.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação BR01 retdistnfe Raiz TAG raiz da Resposta Pág. 34 / 68

35 BR02 versao A BR01 N Versão do leiaute BR03 tpamb E BR01 N Identificação do Ambiente: 1 Produção / 2 - Homologação BR04 veraplic E BR01 C Versão do Aplicativo do AN. BR05 cstat E BR01 N Código do status da resposta (vide item 5.1.1) BR06 xmotivo E BR01 C Descrição literal do status da resposta BR07 ultnsu E BR01 N Último NSU pesquisado, deve ser informado pelo WS sempre que realizar alguma pesquisa para que o solicitante possa atualizar o último NSU pesquisado. BR08 lotedistnfecomp CE BR01 B Conjunto de DF-e compactado com o método indicado no indcompret, somente será informado se indcompret <> 0 sem compactação. O tipo do campo é base64binary. Deve conter as mesmas informações do grupo dados (BR09). BR09 lotedistnfe CG BR BR10 versao A BR09 N Versão do leiaute BR11 proc G BR BR12 NSU A BR11 N NSU do documento fiscal BR13 schema A BR11 C 1-1 Identificação do Schema XML que será utilizado para validar o XML existente no campo seguinte. Vai identificar o tipo do proc e a versão: Ex. procnfe_v1.10.xsd. BR14 (any) G BR11 xml 1-1 Estrutura genérica do proc, o nome da tag pode ser qualquer a de qualquer proc válido Pág. 35 / 68

36 Diagrama simplificado do Schema XML: retdistnfe_v9.99.xsd Descrição do Processo de Requisição de distribuição de DF-e Este serviço pode ser consumido por qualquer UF que desejar acessar os DF-e existentes no repositório do Ambiente Nacional. A partir de 01/04/2010, a distribuição de DF-e fica limitado aos 15 meses anteriores da data da requisição, assim, em abril/2010 somente será possível obter a distribuição de DF-e do período de fevereiro/2009 a abril/2010. A SUFRAMA também pode utilizar o serviço para receber as NF-e destinadas para as áreas de livre comércio de sua administração. Para efeito deste manual é Documento Fiscal eletrônico DF-e: Pág. 36 / 68

37 a NF-e e respectiva autorização ou denegação de uso; o Pedido de Cancelamento de NF-e e respectiva homologação de cancelamento; o Pedido de Inutilização de numeração e respectiva homologação de inutilização; o Evento da NF-e e respectiva homologação de registro; a) Geração do pedido de distribuição A aplicação cliente do WS deve informar o último número seqüencial único do Ambiente Nacional NSU que possui. Caso o valor informado seja 0, a aplicação do WS deve iniciar a busca dos DF-e a partir do primeiro NSU existente no Ambiente Nacional. b) Compactação do lote A escolha para receber as informações em formato compactado é da aplicação cliente, que deve informar a opção no campo indcompret (0-sem compactação ou 1-compactação padrão Gzip). c) Indicador de DF-e solicitado O campo indnfe serve para indicar os DF-e que deseja receber e deve ser informado com um dos seguintes valores: 0 - DF-e autorizados pela UF; 1 - DF-e interestaduais destinados para a UF (deve incluir os DF-e, de faturamento direto de veículos); 2 DF-e autorizados pela SEFAZ Virtual ou SCAN em nome da UF; 8 DF-e interestaduais destinados para a UF (1) e DF-e autorizados pela SEFAZ Virtual ou SCAN em nome da UF (2); 9 - Todos os DF-e. d) Informações de controle A informação da versão do leiaute dos dados, indicador de compactação dos dados e a UF de origem são informados no elemento nfecabecmsg do SOAP Header (para maiores detalhes vide item 3.4). A SUFRAMA deverá se identificar com cuf=90. e) Envio das informações O pedido de distribuição será transmitido através do Web Service do Ambiente Nacional, sendo necessário que o CNPJ utilizado na transmissão da SEFAZ esteja previamente cadastrada no Ambiente Nacional (vide Anexo I - Tabela de órgãos conveniados) Descrição do Processo de Distribuição de Lotes de DF-e O WS do Ambiente Nacional é acionado pelo Órgão conveniado que deve enviar uma requisição de distribuição de DF-e que atenda os padrões estabelecidos neste manual Validação do Certificado de Transmissão Validação do Certificado Digital do Transmissor (protocolo SSL) # Regra de Validação Crítica Msg Efeito Pág. 37 / 68

38 A01 Certificado de Transmissor Inválido: - Certificado de Transmissor inexistente na mensagem - Versão difere "3" - Se informado o Basic Constraint deve ser true (não pode ser Certificado de AC) - KeyUsage não define "Autenticação Cliente" Obrig. 280 Rej. A02 Validade do Certificado (data início e data fim) Obrig. 281 Rej. A03 Verifica a Cadeia de Certificação: - Certificado da AC emissora não cadastrado na RFB - Certificado de AC revogado - Certificado não assinado pela AC emissora do Certificado A04 LCR do Certificado de Transmissor - Falta o endereço da LCR (CRL DistributionPoint) - LCR indisponível - LCR inválida Obrig. 283 Rej. Obrig. 286 Rej. A05 Certificado do Transmissor revogado Obrig. 284 Rej. A06 Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej. A07 Falta a extensão de CNPJ no Certificado (OtherName - OID= ) Obrig. 282 Rej. As validações de A01, A02, A03, A04 e A05 são realizadas pelo protocolo SSL e não precisam ser implementadas. A validação A06 também pode ser realizada pelo protocolo SSL, mas pode falhar se existirem outros certificados digitais de Autoridade Certificadora Raiz que não sejam ICP-Brasil no repositório de certificados digitais do servidor de Web Service do Ambiente Nacional Validação Inicial da Mensagem no Web Service Validação Inicial da Mensagem no Web Service # Regra de Validação Aplic. Msg Efeito B01 Tamanho do XML de Dados superior a 10 KB Obrig. 214 Rej. B02 XML de Dados Mal Formado Obrig. 243 Rej. B03 Verifica se o Servidor de Processamento está Paralisado Momentaneamente Obrig. 108 Rej. B04 Verifica se o Servidor de Processamento está Paralisado sem Previsão Obrig. 109 Rej. A mensagem será descartada se o tamanho exceder o limite previsto (10 KB). A aplicação da Secretaria de Fazenda não poderá permitir a geração de mensagem com tamanho superior a 10 KB. Caso isto ocorra, a conexão poderá ser interrompida sem retorno da mensagem de erro se o controle do tamanho da mensagem for implementado por configurações do ambiente de rede do Ambiente Nacional (ex.: controle no firewall). No caso do controle de tamanho ser implementado por aplicativo teremos a devolução da mensagem de erro 214. Caso o Web Service fique disponível, mesmo quando o serviço estiver paralisado, deverão implementar as verificações 108 e 109. Estas validações poderão ser dispensadas se o Web Service não ficar disponível quando o serviço estiver paralisado Validação das informações de controle da chamada ao Web Service Validação das informações de controle da chamada ao Web Service # Regra de Validação Aplic. Msg Efeito C01 Elemento nfecabecmsg inexistente no SOAP Header Obrig. 409 Rej. C02 Campo cuf inexistente no elemento nfecabecmsg do SOAP Header Obrig. 410 Rej. C03 Verificar se a UF informada no campo cuf é válida (SUFRAMA=90) Obrig. 411 Rej. C04 Campo versaodados inexistente no elemento nfecabecmsg do SOAP Header Obrig. 412 Rej. Pág. 38 / 68

39 C05 Versão dos Dados informada é superior à versão vigente Facult. 238 Rej. C06 Versão dos Dados não suportada Obrig. 239 Rej. C07 Campo indcomp inexistente no elemento nfecabecmsg do SOAP Header Obrig. 413 Rej. C08 indcomp com conteúdo diferente de 0 Obrig. 414 Rej. C09 CNPJ do transmissor não está autorizado a solicitar os protocolos desta UF (vide Anexo I - Tabela de órgãos conveniados) Obrig. 433 Rej. A informação da versão do leiaute do lote, indicador de compactação e a UF de origem são informados no elemento nfecabecmsg do SOAP Header (para maiores detalhes vide item 3.4). A SUFRAMA deverá se identificar com cuf=90. A aplicação deverá validar a UF solicitante (cuf), indicador de compactação (indcomp) e versão da mensagem (versaodados), rejeitando a solicitação recebida em caso de informações inexistentes ou inválidas Validação da área de Dados a) Validação de forma da área de dados A validação de forma da área de dados da mensagem é realizada pelo WS do Ambiente Nacional com a aplicação da seguinte regra: Validação da área de dados da mensagem # Regra de Validação Aplic. Msg Efeito D01 Verifica Schema XML da Área de Dados Obrig. 215 Rej. D02 Verifica o uso de prefixo no namespace Obrig. 404 Rej. D03 XML utiliza codificação diferente de UTF-8 Obrig. 402 Rej. b) Validação de regras de negócios do DF-e Validação do DF-e Regras de Negócios # Regra de Validação Aplic. Msg Efeito H01 Tipo do ambiente do DF-e difere do ambiente do Web Service Obrig. 252 Rej Processamento da requisição O Ambiente Nacional deve gerar lotes com até 50 DF-e que tenham o número seqüencial único NSU superior ao NSU informado. A criação do lote de documentos fiscais deve observar as seguintes regras: ordem crescente de NSU; o lote pode conter qualquer tipo de DF-e válido e respectivo NSU; quantidade máxima de documentos fiscais do lote: 50 DF-e; tamanho máximo do lote: 1 MB; a pesquisa no Ambiente Nacional será limitado à registros por pesquisa, assim poderá ocorrer casos em que a pesquisa será finalizada sem a devolução de nenhum DF-e, neste caso o requisitante deve enviar nova requisição indicando o último NSU que foi pesquisado. Esta medida é necessária para evitar que ocorra uma pesquisa com escopo muito grande, quando gerada por uma UF que tem poucos DF-e no Ambiente Nacional. Pág. 39 / 68

40 Caso o requisitante tenha solicitado a compactação da área de dados, a estrutura do lote de NF-e (lotedistnfe) deve ser compactada com o padrão definido no campo indcompret e convertida em uma seqüência BASE64 e informada no campo lotedistnfecomp. A resposta do WS do Ambiente Nacional pode ser: rejeição - com a devolução da mensagem com o motivo da falha informado no cstat. nenhum DF-e localizado não existe documentos fiscais para a UF cstat = 117. O WS deve informar o último NSU (ultnsu) pesquisado na resposta. O Órgão deverá aguardar um tempo mínimo de 3 minutos para efetuar uma nova solicitação de distribuição, informando o último NSU recebido; DF-e localizado com a devolução do lote de documentos fiscais encontrados cstat = 118; Pág. 40 / 68

41 4.3 Serviço de Consulta de Protocolos Faltantes O Serviço de Consulta de Protocolos Faltantes é o serviço oferecido pelo WS do Ambiente Nacional para identificação dos Protocolos Faltantes da UF no Ambiente Nacional Web Service NFeConsProtFal Consulta protocolos faltantes no Ambiente Nacional SEFAZ Receita Federal do Brasil Consulta Protocolos Web Service : NFeConsProtFal nfeconsprotfaltante Proc. Ret Protocolo Faltante Client AN Protocolos faltantes Aplicação AN Função: serviço destinado a informar os números de protocolos faltantes (quebra de seqüência) de uma UF. Processo: síncrono. Método: nfeconsprotfaltante Leiaute Mensagem de Entrada Entrada: Estrutura XML com pedido de consulta protocolos faltantes Schema XML: consprotfaltnfe_v9.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação CP01 consprotfaltnfe Raiz TAG raiz CP02 versao A CP01 N Versão do leiaute CP03 tpamb E CP01 N Identificação do Ambiente: 1 - Produção 2 - Homologação CP04 veraplic E CP01 C Versão do Aplicativo solicitante CP05 nprotini E CP01 N Número do protocolo inicial Pág. 41 / 68

42 Diagrama simplificado do Schema XML: consprotfaltnfe_v9.99.xsd Leiaute Mensagem de Retorno Retorno: Estrutura XML com número de protocolos faltantes (qtde máxima=1000). Schema XML: retconsprotfaltnfe_v9.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação CR01 retconsprotfaltnfe Raiz TAG raiz da Resposta CR02 versao A CR01 N Versão do leiaute CR03 tpamb E CR01 N Identificação do Ambiente: 1 Produção / 2 - Homologação CR04 veraplic E CR01 C Versão do Aplicativo do AN. CR05 cstat E CR01 N Código do status da resposta (vide item 5.1.1) CR06 xmotivo E CR01 C Descrição literal do status da resposta CR07 nprotpesq E CR01 N 1 15 Número do último protocolo pesquisado. CR08 prot G CR01 N Conjunto de número de protocolos faltantes identificados pela aplicação do AN CR09 nprotini E CR08 N Número do protocolo inicial CR10 nprotfim E CR08 N Número do protocolo final Pág. 42 / 68

43 Diagrama simplificado do Schema XML: retconsprotfaltnfe_v9.99.xsd Descrição do Processo da requisição de consulta de Protocolos Faltantes da UF Este serviço pode ser consumido por qualquer UF que deseja consultar a situação de sincronização no repositório do Ambiente Nacional. a) Geração do pedido de consulta de Protocolos Faltantes da UF A aplicação cliente do WS deve informar o primeiro número de protocolo a partir do qual deseja verificar a existência de número de protocolos faltantes. O Ambiente Nacional procederá a verificação de no máximo protocolos. Na consulta deverá ser considerado o órgão gerador do protocolo, o código da UF e o ano. b) Informações de controle Pág. 43 / 68

44 A informação da versão do leiaute dos dados, indicador de compactação dos dados e a UF de origem são informados no elemento nfecabecmsg do SOAP Header (para maiores detalhes vide item 3.4). c) Envio das informações O pedido será transmitido através do Web Service do Ambiente Nacional, sendo necessário que o CNPJ utilizado na transmissão da SEFAZ interessada esteja cadastrada no Ambiente Nacional (vide Anexo I - Tabela de órgãos conveniados) Descrição do Processo de Consulta de Protocolos Faltantes da UF O WS do Ambiente Nacional é acionado pela SEFAZ que deve enviar uma requisição de Consulta Protocolos Faltantes que atenda os padrões estabelecidos neste manual Validação do Certificado de Transmissão Validação do Certificado Digital do Transmissor (protocolo SSL) # Regra de Validação Crítica Msg Efeito A01 Certificado de Transmissor Inválido: - Certificado de Transmissor inexistente na mensagem - Versão difere "3" - Se informado o Basic Constraint deve ser true (não pode ser Certificado de AC) - KeyUsage não define "Autenticação Cliente" Obrig. 280 Rej. A02 Validade do Certificado (data início e data fim) Obrig. 281 Rej. A03 Verifica a Cadeia de Certificação: - Certificado da AC emissora não cadastrado na RFB - Certificado de AC revogado - Certificado não assinado pela AC emissora do Certificado A04 LCR do Certificado de Transmissor - Falta o endereço da LCR (CRL DistributionPoint) - LCR indisponível - LCR inválida Obrig. 283 Rej. Obrig. 286 Rej. A05 Certificado do Transmissor revogado Obrig. 284 Rej. A06 Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej. A07 Falta a extensão de CNPJ no Certificado (OtherName - OID= ) Obrig. 282 Rej. As validações de A01, A02, A03, A04 e A05 são realizadas pelo protocolo SSL e não precisam ser implementadas. A validação A06 também pode ser realizada pelo protocolo SSL, mas pode falhar se existirem outros certificados digitais de Autoridade Certificadora Raiz que não sejam ICP-Brasil no repositório de certificados digitais do servidor de Web Service do Ambiente Nacional Validação Inicial da Mensagem no Web Service Validação Inicial da Mensagem no Web Service # Regra de Validação Aplic. Msg Efeito B01 Tamanho do XML de Dados superior a 10 KB Obrig. 214 Rej. B02 XML de Dados Mal Formado Obrig. 243 Rej. B03 Verifica se o Servidor de Processamento está Paralisado Momentaneamente B04 Verifica se o Servidor de Processamento está Paralisado sem Previsão Pág. 44 / 68 Obrig. 108 Rej. Obrig. 109 Rej.

45 A mensagem será descartada se o tamanho exceder o limite previsto (10 KB). A aplicação da Secretaria de Fazenda não poderá permitir a geração de mensagem com tamanho superior a 10 KB. Caso isto ocorra, a conexão poderá ser interrompida sem retorno da mensagem de erro se o controle do tamanho da mensagem for implementado por configurações do ambiente de rede do Ambiente Nacional (ex.: controle no firewall). No caso do controle de tamanho ser implementado por aplicativo teremos a devolução da mensagem de erro 214. Caso o Web Service fique disponível, mesmo quando o serviço estiver paralisado, deverão implementar as verificações 108 e 109. Estas validações poderão ser dispensadas se o Web Service não ficar disponível quando o serviço estiver paralisado Validação das informações de controle da chamada ao Web Service Validação das informações de controle da chamada ao Web Service # Regra de Validação Aplic. Msg Efeito C01 Elemento nfecabecmsg inexistente no SOAP Header Obrig. 409 Rej. C02 Campo cuf inexistente no elemento nfecabecmsg do SOAP Header Obrig. 410 Rej. C03 Verificar se a UF informada no campo cuf é válida Obrig. 411 Rej. C04 Campo versaodados inexistente no elemento nfecabecmsg do SOAP Header Obrig. 412 Rej. C05 Versão dos Dados informada é superior à versão vigente Facult. 238 Rej. C06 Versão dos Dados não suportada Obrig. 239 Rej. C07 Campo indcomp inexistente no elemento nfecabecmsg do SOAP Header Obrig. 413 Rej. C08 indcomp com conteúdo diferente de 0 Obrig. 414 Rej. C09 CNPJ do transmissor não está autorizado a consultar os protocolos desta UF (vide Anexo I - Tabela de órgãos conveniados) Obrig. 433 Rej. A informação da versão do leiaute da mensagem e a UF de origem são informados no elemento nfecabecmsg do SOAP Header (para maiores detalhes vide item 3.4). A aplicação deverá validar a UF solicitante (cuf), indicador de compactação da área de dados (indcomp) e versão da mensagem (versaodados), rejeitando a solicitação recebida em caso de informações inexistentes ou inválidas Validação da área de Dados a) Validação de forma da área de dados A validação de forma da área de dados da mensagem é realizada pelo WS do Ambiente Nacional com a aplicação da seguinte regra: Validação da área de dados da mensagem # Regra de Validação Aplic. Msg Efeito D01 Verifica Schema XML da Área de Dados Obrig. 215 Rej. D02 Verifica o uso de prefixo no namespace Obrig. 404 Rej. D03 XML utiliza codificação diferente de UTF-8 Obrig. 402 Rej. b) Validação de regras de negócios do DF-e Pág. 45 / 68

46 Validação do DF-e Regras de Negócios # Regra de Validação Aplic. Msg Efeito I01 Tipo do ambiente do DF-e difere do ambiente do Web Service Obrig. 252 Rej. I02 Tipo de Autorizador do protocolo inicial inválido (diferente de 1=SEFAZ normal, 2= Contingência SCAN - RFB, 3=SEFAZ VIRTUAL-RS, 4=SEFAZ VIRTUAL-RFB) I03 Código da UF do número do protocolo inicial não compatível com o cuf informado no SOAP Header I04 Tipo de Autorizador do protocolo final difere do Tipo de Autorizador do protocolo inicial Obrig. 424 Rej. Obrig. 425 Rej. Obrig. 426 Rej Processamento da requisição O Ambiente Nacional deve gerar resposta com até 1000 faixas de protocolos faltantes, identificados a partir do número de protocolo informado pela UF. Para efeito de resposta um protocolo faltante pode ser uma faixa de numeração ou um único protocolo caso o número do protocolo inicial e o número do protocolo final forem idênticos. A resposta do WS do Ambiente Nacional pode ser: Rejeição - mensagem inválida, com o motivo da falha devolvido no cstat. Nenhum protocolo faltante localizado para a UF (cstat=114); Protocolos faltantes localizados para a UF (cstat=115); Quantidade de Protocolos faltantes localizados para a UF excedeu o limite 1000 faixas de protocolo. O WS deve informar as primeiras 1000 faixas de protocolos faltantes e o último número do protocolo que foi pesquisado nprotpesq (cstat=116). A aplicação cliente deverá solicitar nova consulta a partir do último número de protocolo pesquisado que foi informado pelo WS. Pág. 46 / 68

47 4.4 Serviço de Manutenção do Cadastro Nacional de Emissores de DF-e O Serviço de Manutenção do Cadastro Nacional de Emissores de DF-e é o serviço oferecido pelo WS do Ambiente Nacional para atualização do Cadastro Nacional de Emissores de DF-e pelas UF participantes do Projeto NF-e Web Service CNEManutencao Manutenção do Cadastro Nacional de Emissores de DF-e SEFAZ Receita Federal do Brasil Envio da alteração do cadastro de emissor da UF Web Service : CNEManutenca o cnemanutencao Proc. Ret Manutenção Client AN Aplicação AN Retorno Função: serviço destinado à recepção de mensagens de atualização do Cadastro Nacional de Emissores de DF-e. Processo: síncrono. Método: cnemanutencao Leiaute Mensagem de Entrada Entrada: Estrutura XML com atualização do Cadastro Nacional de Emissores Schema XML: envcne_v9.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação DP01 envcne Raiz TAG raiz DP02 versao A DP01 N Versão do leiaute DP03 tpamb E DP01 N Identificação do Ambiente: 1 Produção / 2 - Homologação DP04 veraplic E DP01 C Versão da aplicação Solicitante DP05 UF E DP01 C Sigla da UF onde o emissor está autorizado a emitir DF-e DP06 CNPJ E DP01 N CNPJ do Emissor DP07 IE E DP01 N IE do emissor, podendo conter o literal ISENTO no caso de autorização de acesso a consulta cadastro pelo Fisco (tpdfe=99) DP08 xnome E DP01 C Razão Social ou Nome do Emitente DP09 indobrig E DP01 N Indicador de obrigatoriedade de emissor de DF-e: 1 credenciado; 2 credenciado com obrigatoriedade para todas as operações; 3 credenciado com obrigatoriedade parcial. DP10 tpdfe E DP01 N Motivo de participação no CNE: 55 - NF-e; 57 - CT-e; Pág. 47 / 68

48 99 - uso exclusivo do Fisco para inclusão de qualquer órgão público no cadastro de emissores de DF-e com objetivo de permitir o acesso ao WS - CadConsultaCadastro de Consulta Cadastro de Contribuintes do ICMS de qualquer unidade federada. DP11 dvigobrig E DP01 D 0-1 Data de início de vigência da obrigatoriedade. Formato AAAA-MM-DD. A inexistência desta informação indica que o emissor não está obrigado a emitir NF-e. DP12 evento E DP01 N evento - Informa o tipo da atualização: 1 - credenciamento; 2 - suspensão do credenciamento; 3 - reativação do credenciamento; 4 - descredenciamento; 5 alteração de credenciamento. DP13 devento E DP01 D Data de início de vigência do evento informado. Formato AAAA-MM-DD DP14 xobs E DP01 C Observações complementares de interesse da UF do emissor (número, data, ato, etc. do credenciamento e outras informações de interesse) Diagrama simplificado do Schema XML: envcne_v9.99.xsd Pág. 48 / 68

49 Pág. 49 / 68

50 4.4.3 Leiaute Mensagem de Retorno Retorno: Estrutura XML com a mensagem do resultado da transmissão. Schema XML: retenvcne_v9.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação DR01 retenvcne Raiz TAG raiz da Resposta DR02 versao A DR01 N Versão do leiaute DR03 tpamb E DR01 N Identificação do Ambiente: 1 Produção / 2 - Homologação DR04 veraplic E DR01 C Versão da aplicação do AN DR05 cstat E DR01 N Código do status da resposta (vide item 5.1.1) DR06 xmotivo E DR01 C Descrição literal do status da resposta DR07 NSUCNE E DR01 N NSU - Número Seqüencial Único atribuído à operação pelo AN (NSU de movimento do CNE), fornecido somente para as atualizações atendidas Diagrama simplificado do Schema XML: retenvcne_v9.99.xsd Estrutura do Cadastro Nacional de Emissores Campo Tipo Tam. Descrição/Observação UF C 2 Sigla da UF onde o emissor está autorizado a emitir DF-e CNPJ N 14 CNPJ do Emissor IE N 14 IE do emissor: pode conter o literal ISENTO no caso de autorização de acesso a consulta cadastro pelo Fisco (tpdfe=99) xnome C 1-60 Razão Social ou Nome do Emitente indobrig N 1 Indicador de obrigatoriedade de emissor de DF-e: 1 credenciado; Pág. 50 / 68

51 2 credenciado com obrigatoriedade para todas as operações; 3 credenciado com obrigatoriedade parcial. tpdfe N 2 Motivo de participação no CNE: 55 - NF-e; 57 - CT-e; 99 - uso exclusivo do Fisco para inclusão de qualquer órgão público no cadastro de emissores de DF-e com objetivo de permitir o acesso ao WS - CadConsultaCadastro de Consulta Cadastro de Contribuintes do ICMS de qualquer unidade federada. dvigobrig D Data de início de vigência da obrigatoriedade. Formato AAAA-MM-DD sitcred C 1 Situação de credenciamento do emissor: A Ativo; S Suspenso; I Inativo. devento D - Data da situação de credenciamento informada pela SEFAZ -Formato AAAA-MM-DD xobs C Observações complementares de interesse da UF do emissor (número, data, ato, etc. do credenciamento e outras informações de interesse) dinclcne D Data de inclusão do emissor no Cadastro Nacional de Emissores NSUCadCNE N 1-15 NSU de Cadastro do CNE atribuído ao emissor (número seqüencial de registro do emissor dentro do CNE) datucne D Data de atualização do emissor no Cadastro Nacional de Emissores NSUMvtoCNECN E N 1-15 Último NSU de movimento do CNE atribuído ao Emissor (número seqüencial do movimento do CNE) A chave primária do Cadastro Nacional de Emissores é composta pelos campos: UF, CNPJ, IE e tpdfe Descrição do Processo de envio da mensagem de Manutenção do Cadastro Nacional de Emissores de DF-e A Secretaria de Fazenda que credenciar um novo emissor de DF-e ou promover qualquer alteração na situação de um emissor credenciado deve transmitir a mensagem de atualização do Cadastro Nacional de Emissores de DF-e. a) Geração da mensagem Além do credenciamento de novos emissores, qualquer evento que modifique a situação cadastral do emissor credenciado deve ser comunicado ao Ambiente Nacional para atualização de cadastro. b) Eventos de atualização do Cadastro Nacional de Emissores de DF-e credenciamento comunica o credenciamento de emissor; suspensão do credenciamento comunica a suspensão do credenciamento, deve ter caráter temporário; reativação do credenciamento comunica a reativação do credenciamento, só deve ser utilizado para os emissores suspenso. No caso de um novo credenciamento de um emissor descredenciado, a opção aplicável é o credenciamento; descredenciamento comunica o descredenciamento de um emissor; alteração permite a alteração dos seguintes campos: o razão social (xnome); o indicador de obrigatoriedade (indobrig) a UF deve comandar a atualização dos emissores que se tornaram emissores obrigados; o data da vigência da obrigatoriedade (dvigobrig) a data serve para indicar o início da obrigatoriedade para o emissor; o data do evento informada pela SEFAZ (devento); o observações (xobs). Para anular o efeito de um evento deverá ser comandado um evento contrário com a mesma data de evento (devento). Pág. 51 / 68

52 Não é permitida a alteração dos campos CNPJ, IE e tpdfe. Caso a alteração seja necessária deverá ser feito o descredenciamento, com a mesma data de evento, e um novo credenciamento. c) Informações de controle A informação da versão do leiaute dos dados, indicador de compactação dos dados e a UF de origem são informados no elemento nfecabecmsg do SOAP Header (para maiores detalhes vide item 3.4). O indicador de compactação deve ser informado com conteúdo = 0, pois a mensagem não será compactada. d) Envio das informações A solicitação será transmitida através do Web Service do Ambiente Nacional, sendo necessário que o CNPJ utilizado na transmissão da SEFAZ interessada esteja previamente cadastrado no Ambiente Nacional (vide Anexo I - Tabela de órgãos conveniados). Será permitido o uso do certificado digital da SEFAZ Virtual nos casos em que a transmissão seja realizada pela SEFAZ Virtual Descrição do Processo de recepção da mensagem de atualização do Cadastro Nacional de Emissores de DF-e O WS do Ambiente Nacional é acionado pela SEFAZ autorizadora (ou SEFAZ Virtual) que deve enviar uma mensagem de atualização do Cadastro Nacional de Emissores de DF-e que atenda os padrões estabelecidos neste manual Validação do Certificado de Transmissão Validação do Certificado Digital do Transmissor (protocolo SSL) # Regra de Validação Crítica Msg Efeito A01 Certificado de Transmissor Inválido: - Certificado de Transmissor inexistente na mensagem - Versão difere "3" - Se informado o Basic Constraint deve ser true (não pode ser Certificado de AC) - KeyUsage não define "Autenticação Cliente" Obrig. 280 Rej. A02 Validade do Certificado (data início e data fim) Obrig. 281 Rej. A03 Verifica a Cadeia de Certificação: - Certificado da AC emissora não cadastrado na RFB - Certificado de AC revogado - Certificado não assinado pela AC emissora do Certificado A04 LCR do Certificado de Transmissor - Falta o endereço da LCR (CRL DistributionPoint) - LCR indisponível - LCR inválida Obrig. 283 Rej. Obrig. 286 Rej. A05 Certificado do Transmissor revogado Obrig. 284 Rej. A06 Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej. A07 Falta a extensão de CNPJ no Certificado (OtherName - OID= ) Obrig. 282 Rej. As validações de A01, A02, A03, A04 e A05 são realizadas pelo protocolo SSL e não precisam ser implementadas. A validação A06 também pode ser realizada pelo protocolo SSL, mas pode falhar se existirem outros certificados digitais de Autoridade Certificadora Raiz que não sejam ICP-Brasil no repositório de certificados digitais do servidor de Web Service do Ambiente Nacional. Pág. 52 / 68

53 4.4.8 Validação Inicial da Mensagem no Web Service Validação Inicial da Mensagem no Web Service # Regra de Validação Aplic. Msg Efeito B01 Tamanho do XML de Dados superior a 10 KB Obrig. 214 Rej. B02 XML de Dados Mal Formado Obrig. 243 Rej. B03 Verifica se o Servidor de Processamento está Paralisado Momentaneamente Obrig. 108 Rej. B04 Verifica se o Servidor de Processamento está Paralisado sem Previsão Obrig. 109 Rej. A mensagem será descartada se o tamanho exceder o limite previsto (10 KB). A aplicação da Secretaria de Fazenda não poderá permitir a geração de mensagem com tamanho superior a 10 KB. Caso isto ocorra, a conexão poderá ser interrompida sem retorno da mensagem de erro se o controle do tamanho da mensagem for implementado por configurações do ambiente de rede do Ambiente Nacional (ex.: controle no firewall). No caso do controle de tamanho ser implementado por aplicativo teremos a devolução da mensagem de erro 214. Caso o Web Service fique disponível, mesmo quando o serviço estiver paralisado, deverão implementar as verificações 108 e 109. Estas validações poderão ser dispensadas se o Web Service não ficar disponível quando o serviço estiver paralisado Validação das informações de controle da chamada ao Web Service Validação das informações de controle da chamada ao Web Service # Regra de Validação Aplic. Msg Efeito C01 Elemento nfecabecmsg inexistente no SOAP Header Obrig. 409 Rej. C02 Campo cuf inexistente no elemento nfecabecmsg do SOAP Header Obrig. 410 Rej. C03 Verificar se a UF informada no campo cuf é válida Obrig. 411 Rej. C04 Campo versaodados inexistente no elemento nfecabecmsg do SOAP Header Obrig. 412 Rej. C05 Versão dos Dados informada é superior à versão vigente Facult. 238 Rej. C06 Versão dos Dados não suportada Obrig. 239 Rej. C07 Campo indcomp inexistente no elemento nfecabecmsg do SOAP Header Obrig. 413 Rej. C08 indcomp com conteúdo diferente de 0 Obrig. 414 Rej. C09 CNPJ do transmissor não está autorizado a enviar atualização desta UF (vide Anexo I - Tabela de órgãos conveniados) Obrig. 429 Rej. A informação da versão do leiaute da mensagem e a UF de origem da mensagem são informados no elemento nfecabecmsg do SOAP Header (para maiores detalhes vide item 3.4). A aplicação deverá validar a UF (cuf), indicador de compactação (indcomp=0) e versão da mensagem (versaodados), rejeitando a solicitação recebida em caso de informações inexistentes ou inválidas Validação da área de Dados a) Validação de forma da área de dados A validação de forma da área de dados da mensagem é realizada com a aplicação da seguinte regra: Validação da área de dados da mensagem Pág. 53 / 68

54 # Regra de Validação Aplic. Msg Efeito D01 Verifica Schema XML da Área de Dados Obrig. 215 Rej. D02 Verifica o uso de prefixo no namespace Obrig. 404 Rej. D03 XML utiliza codificação diferente de UTF-8 Obrig. 402 Rej. b) Validação de regras de negócios da atualização de Cadastro Nacional de Emissores Atualização do Cadastro Nacional de Emissores Regras de Negócios # Regra de Validação Aplic. Msg Efeito J01 Tipo do ambiente da mensagem difere do ambiente do Web Service Obrig. 252 Rej. J02 Sigla da UF do Emissor difere do Código da UF do SOAP Header Obrig. 434 Rej. J03 CNPJ do emissor inválido Obrig. 435 Rej. J04 IE do emissor inválida Obrig. 436 Rej. J05 devento na SEFAZ com data futura ou menor que (início da Obrig. 437 Rej. emissão de NF-e com validade jurídica) J06 indobrig = 2 ou 3 deve informar a dvigobrig Obrig. 438 Rej. J07 indobrig = 1 não informar a dvigobrig Obrig. 439 Rej. J08 dvigobrig anterior a (início da 1ª obrigatoriedade) Obrig. 440 Rej. J09 evento = 1 - credenciamento, acesso CNE (Chave UF, CNPJ, IE, tpdfe) existe emissor no cadastro com situação de credenciamento = A ativo ou S suspenso J10 evento = 2 suspensão, 3 - reativação, 4 - descredenciamento ou 5 alteração de credenciamento, acesso CNE (Chave UF, CNPJ, IE, tpdfe) não existe emissor no cadastro. J11 Se evento = 2 - suspensão, acesso CNE (Chave UF, CNPJ, IE, tpdfe) existe emissor no cadastro com situação de credenciamento diferente de A Ativo. J12 Se evento = 3 - reativação, acesso CNE (Chave UF, CNPJ, IE, tpdfe) existe emissor no cadastro com situação de credenciamento diferente de S Suspenso. J13 Se evento = 4 - descredenciamento, acesso CNE (Chave UF, CNPJ, IE, tpdfe) existe emissor no cadastro com situação de credenciamento igual a I - inativo. Obrig. 441 Rej. Obrig. 442 Rej. Obrig. 443 Rej. Obrig. 444 Rej. Obrig. 445 Rej Final do Processamento A validação da mensagem de atualização do Cadastro Nacional de Emissores poderá resultar em: Rejeição com retorno do código do status do motivo da rejeição; Recebido pelo Ambiente Nacional Cadastro Nacional de Emissores atualizado (cstat=119); O Ambiente Nacional deve atribuir um número seqüencial único NSUMvtoCNE para toda mensagem de atualização do Cadastro Nacional de Emissores processada com sucesso. Pág. 54 / 68

55 4.5 Serviço de Distribuição do Cadastro Nacional de Emissores de DF-e O Serviço de Distribuição do Cadastro Nacional de Emissores de DF-e é o serviço oferecido pelo WS do Ambiente Nacional para download das seguintes informações: Cadastro Nacional de Emissores resumido contendo o CNPJ do emissor credenciado; Cadastro Nacional de Emissores; O movimento de atualização do Cadastro Nacional de Emissores de um determinado período Web Service CNEDistribuicao Distribuição do Cadastro Nacional de Emissores de DF-e SEFAZ Receita Federal do Brasil Client AN Solicita Distribuição Cadastro Nacional de Emissores (resumo/completo) ou alterações ocorridas Web Service : CNEDistribuicao cnedistribuicao Proc. Re t Distribuição Aplicação AN Função: serviço destinado à distribuição do Cadastro Nacional de Emissores de DF-e (resumo/completo) ou das alterações ocorridas no período solicitado. Processo: síncrono. Método: cnedistribuicao Leiaute Mensagem de Entrada Entrada: Estrutura XML com o pedido de distribuição de CNE Schema XML: conscne_v9.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação EP01 conscne Raiz TAG raiz EP02 versao A EP01 N Versão do leiaute EP03 tpamb E EP01 N Identificação do Ambiente: 1 - Produção 2 Homologação EP04 veraplic E EP01 C Versão do Aplicativo solicitante EP05 indcons E EP01 N Indicador do escopo da consulta cadastro: 1 Cadastro de emissores resumido (somente CNPJ); 2 Cadastro de emissores completo; 3 - Movimento de Atualização de Cadastro ocorrido a partir do NSU informado; EP06 indcompret E EP01 N Indicador de Compactação da Mensagem de retorno: 0 - sem compactação; Pág. 55 / 68

56 1 - compactação padrão gzip EP07 ultnsucne E EP01 N indcons=1 (Cadastro resumido): O campo informa o último NSUCadCNE já recebido. Se informado com zero, o AN tentará localizar o primeiro registro do CNE. indcons=2 (Cadastro completo): Idem; indcons=3 (Movimento de atualização do CNE): O campo informa o último NSUMvtoCNE já recebido. Se informado com zero, o AN tentará localizar o primeiro registro de movimento do CNE. Filtros de uso não obrigatório, são mutuamente exclusivos. Se informado um dos filtros o WS deve selecionar os registros no cadastro ou no movimento que atendam. EP08 UF CE EP01 C Filtro: Sigla da UF EP09 datu CE EP01 D Filtro: Data de atualização do emissor no CNE (este filtro não tem sentido para indcons = 1). EP10 UFdAtu CE EP Filtro: Sigla UF e datu EP11 UF E EP10 C Sigla da UF EP12 datu E EP10 D 1-1 Data de atualização do emissor no CNE (este filtro não tem sentido para indcons = 1) EP13 CNPJ CE EP01 N Filtro: CNPJ do emissor EP14 UFIE CE EP Filtro: IE e Sigla da UF do emissor EP15 UF E EP14 C Sigla da UF do Emissor EP16 IE E EP14 N IE Diagrama simplificado do Schema XML: conscne_v9.99.xsd Leiaute Mensagem de Retorno Retorno: Estrutura XML com o Cadastro de emissores (resumo/completo) ou com o movimento de atualizações de Cadastro ocorridas a partir do NSU informado. Schema XML: retconscne_v9.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação ER01 retconscne Raiz TAG raiz da Resposta ER02 versao A ER01 N Versão do leiaute ER03 tpamb E ER01 N Identificação do Ambiente: 1 Produção / 2 Homologação ER04 veraplic E ER01 C Versão do Aplicativo do AN. ER05 cstat E ER01 N Código do status da resposta (vide item 5.1.1) ER06 xmotivo E ER01 C Descrição literal do status da resposta ER07 cademicomp CE ER01 B Movimento de atualização do Cadastro de Emissor ou Cadastro de Emissores compactado com o método indicado no indcompret, somente será informado se indcompret <> 0 sem compactação. O tipo do campo é base64binary. Deve conter as mesmas informações do grupo dados (ER08, ER10 ou ER26). ER08 CNERes CG ER Grupo de informações do cadastro de emissores resumido ER09 CNPJ E ER08 N CNPJ do Emissor ER10 NSUCadCNE E ER08 N 1 15 Número do último NSUCadCNE retornado (Chave de Continuação da consulta resumida) ER11 CNECpl CG ER Grupo de informações do cadastro de emissores completo ER12 emicpl G ER Dados Completos do Emissor Pág. 56 / 68

57 ER13 versao A ER12 N Versão do leiaute ER14 UF E ER12 C 1-2 Sigla da UF onde o emissor está autorizado a emitir DF-e ER15 CNPJ E ER12 N CNPJ do Emissor ER16 IE E ER12 N IE do emissor ER17 xnome E ER12 C Razão Social ou Nome do Emitente ER18 indobrig E ER12 N Indicador de obrigatoriedade de emissor de DF-e: 1 credenciado; 2 credenciado com obrigatoriedade para todas as operações; 3 credenciado com obrigatoriedade parcial. ER19 tpdfe E ER12 N Motivo de participação no CNE: 55 - NF-e; 57 - CT-e; 99 - uso exclusivo do Fisco para inclusão de qualquer órgão público no cadastro de emissores de DF-e com objetivo de permitir o acesso ao WS - CadConsultaCadastro de Consulta Cadastro de Contribuintes do ICMS de qualquer unidade federada. ER20 dvigobrig E ER12 D 0-1 Data de início de vigência da obrigatoriedade. Formato AAAA-MM-DD a inexistência desta informação indica que o emissor não está obrigado a emitir NF-e. ER21 sitcred E ER12 C Situação de credenciamento do emissor: A Ativo; S Suspenso; I Inativo. ER22 devento E ER12 D Data da situação de credenciamento informada pela SEFAZ -Formato AAAA-MM-DD ER23 xobs E ER12 C Observações complementares de interesse da UF do emissor (número, data, ato, etc. do credenciamento e outras informações de interesse) ER24 dinccne E ER12 D 1-1 Data de inclusão do emissor no Cadastro Nacional de Emissores ER25 NSUCadCNE E ER12 N 1 15 NSU de cadastro do Emissor no CNE (Chave de Continuação na consulta completa) ER26 datucne E ER12 D 1-1 Data de atualização do emissor no Cadastro Nacional de Emissores mantido pela RFB. ER27 NSUMvtoCNE E ER12 N NSU do último movimento de atualização do CNE para o emissor ER28 CNEMvto CG ER Grupo de Informações do movimento de atualização do Cadastro Nacional de Emissores de NF-e ER29 emimvto G ER Movimento de atualização do Cadastro Nacional de Emissores de NF-e ER30 envcne G ER29 1 Dados do Movimento de atualização do CNE. ER31 versao A ER30 N Versão do leiaute ER32 tpamb E ER30 N Identificação do Ambiente: 1 Produção / 2 - Homologação ER33 veraplic E ER30 C Versão da aplicação Solicitante ER34 UF E ER30 C Sigla da UF onde o emissor está autorizado a emitir DF-e ER35 CNPJ E ER30 N CNPJ do Emissor ER36 IE E ER30 N IE do emissor ER37 xnome E ER30 C Razão Social ou Nome do Emitente ER38 indobrig E ER30 N Indicador de obrigatoriedade de emissor de DF-e: 1 credenciado; 2 credenciado com obrigatoriedade para todas as operações; 3 credenciado com obrigatoriedade parcial. ER39 tpdfe E ER30 N Motivo de participação no CNE: 55 - NF-e; 57 - CT-e; 99 - uso exclusivo do Fisco para inclusão de qualquer órgão público no cadastro de emissores de DF-e com objetivo de permitir o acesso ao WS - Pág. 57 / 68

58 CadConsultaCadastro de Consulta Cadastro de Contribuintes do ICMS de qualquer unidade federada. ER40 dvigobrig E ER30 D 0-1 Data de início de vigência da obrigatoriedade. Formato AAAA-MM-DD ER41 evento E ER30 N evento - Informa o tipo da atualização: 1 - credenciamento; 2 - suspensão do credenciamento; 3 - reativação do credenciamento; 4 - descredenciamento; 5 alteração de credenciamento. ER42 devento E ER30 D Data de início de vigência do evento informado. Formato AAAA-MM-DD ER43 xobs E ER30 C Observações complementares de interesse da UF do emissor (número, data, ato, etc. do credenciamento e outras informações de interesse) ER44 datucne E ER28 D 1 Controle do Movimento de atualização: data da atualização ER45 NSUMvtoCNE E ER28 N Controle do Movimento de atualização: NSU da atualização (Chave de Continuação da consulta de movimento). ER46 xautormvto E ER28 C Controle do Movimento de atualização: identificação do Autor do Movimento. Campo opcional, que pode ser preenchido com o CNPJ do certificado da SEFAZ que comandou o movimento, ou um literal que identifique o autor (Ex.: SEFAZ-XX, SVRS,...). Pág. 58 / 68

59 Diagrama simplificado do Schema XML: retconscne_v9.99.xsd Pág. 59 / 68

60 4.5.4 Descrição do Processo de Geração de requisição de distribuição do Cadastro de Nacional de Emissores de DF-e Este serviço pode ser consumido por qualquer UF ou SUFRAMA para obter as seguintes informações: Cadastro Nacional de Emissores resumido contendo o CNPJ do emissor credenciado com a situação ativo; Cadastro Nacional de Emissores; O movimento de atualização do Cadastro Nacional de Emissores de um determinado período. a) Geração do pedido de consulta A aplicação cliente do WS deve informar o indicador de consulta desejada (indcons), informando um dos seguintes valores: 1 - Cadastro de emissores resumido (apenas CNPJ); 2 Cadastro de emissores completo; 3 Movimento de Atualização de Cadastro; b) Filtros do resultado da consulta É permitido informar qualquer um dos seguintes filtros: UF sigla da UF do emissor; datu data de atualização do cadastro; UF / datu Sigla da UF e data de atualização do cadastro; CNPJ CNPJ do emissor; IE/UF IE e UF do emissor. c) Compactação do retorno A escolha para receber as informações em formato compactado é da aplicação cliente, que deve informar a opção no campo indcompret (0-sem compactação ou 1-compactação padrão GZip). d) último NSU recebido O tamanho das mensagens de retorno serão limitadas para conterem 500 registros, se resultado da consulta ultrapassar este limite, o cliente deve tentar nova consulta informado o último NSU recebido. e) Informações de controle A informação da versão do leiaute dos dados, indicador de compactação dos dados e a UF de origem são informados no elemento nfecabecmsg do SOAP Header (para maiores detalhes vide item 3.4). A SUFRAMA deverá se identificar com cuf=90. f) Envio das informações O pedido de distribuição será transmitido através do Web Service do Ambiente Nacional, sendo necessário que o CNPJ utilizado na transmissão da SEFAZ interessada esteja previamente cadastrada no Ambiente Nacional (vide Anexo I - Tabela de órgãos conveniados). Pág. 60 / 68

61 4.5.5 Descrição do Processo de download do Cadastro Nacional de emissores resumido ou das Atualizações de Cadastro ocorridas a partir do NSU informado O WS do Ambiente Nacional é acionado pelo Órgão conveniado que deve enviar uma requisição de download do Cadastro ou das atualizações de Cadastro que atenda os padrões estabelecidos neste manual Validação do Certificado de Transmissão Validação do Certificado Digital do Transmissor (protocolo SSL) # Regra de Validação Crítica Msg Efeito A01 Certificado de Transmissor Inválido: - Certificado de Transmissor inexistente na mensagem - Versão difere "3" - Se informado o Basic Constraint deve ser true (não pode ser Certificado de AC) - KeyUsage não define "Autenticação Cliente" Obrig. 280 Rej. A02 Validade do Certificado (data início e data fim) Obrig. 281 Rej. A03 Verifica a Cadeia de Certificação: - Certificado da AC emissora não cadastrado na RFB - Certificado de AC revogado - Certificado não assinado pela AC emissora do Certificado A04 LCR do Certificado de Transmissor - Falta o endereço da LCR (CRL DistributionPoint) - LCR indisponível - LCR inválida Obrig. 283 Rej. Obrig. 286 Rej. A05 Certificado do Transmissor revogado Obrig. 284 Rej. A06 Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej. A07 Falta a extensão de CNPJ no Certificado (OtherName - OID= ) Obrig. 282 Rej. As validações de A01, A02, A03, A04 e A05 são realizadas pelo protocolo SSL e não precisam ser implementadas. A validação A06 também pode ser realizada pelo protocolo SSL, mas pode falhar se existirem outros certificados digitais de Autoridade Certificadora Raiz que não sejam ICP-Brasil no repositório de certificados digitais do servidor de Web Service do Ambiente Nacional Validação Inicial da Mensagem no Web Service Validação Inicial da Mensagem no Web Service # Regra de Validação Aplic. Msg Efeito B01 Tamanho do XML de Dados superior a 10 KB Obrig. 214 Rej. B02 XML de Dados Mal Formado Obrig. 243 Rej. B03 Verifica se o Servidor de Processamento está Paralisado Momentaneamente Obrig. 108 Rej. B04 Verifica se o Servidor de Processamento está Paralisado sem Previsão Obrig. 109 Rej. A mensagem será descartada se o tamanho exceder o limite previsto (10 KB). A aplicação da Secretaria de Fazenda não poderá permitir a geração de mensagem com tamanho superior a 10 KB. Caso isto ocorra, a conexão poderá ser interrompida sem retorno da mensagem de erro se o controle do tamanho da mensagem for implementado por configurações do ambiente de rede do Ambiente Nacional (ex.: controle no firewall). No caso do controle de tamanho ser implementado por aplicativo teremos a devolução da mensagem de erro 214. Caso o Web Service fique disponível, mesmo quando o serviço estiver paralisado, deverão implementar as verificações 108 e 109. Estas validações poderão ser dispensadas se o Web Service não ficar disponível quando o serviço estiver paralisado. Pág. 61 / 68

62 4.5.8 Validação das informações de controle da chamada ao Web Service Validação das informações de controle da chamada ao Web Service # Regra de Validação Aplic. Msg Efeito C01 Elemento nfecabecmsg inexistente no SOAP Header Obrig. 409 Rej. C02 Campo cuf inexistente no elemento nfecabecmsg do SOAP Header Obrig. 410 Rej. C03 Verificar se a UF informada no campo cuf é válida (SUFRAMA=90) Obrig. 411 Rej. C04 Campo versaodados inexistente no elemento nfecabecmsg do SOAP Header Obrig. 412 Rej. C05 Versão dos Dados informada é superior à versão vigente Facult. 238 Rej. C06 Versão dos Dados não suportada Obrig. 239 Rej. C07 Campo indcomp inexistente no elemento nfecabecmsg do SOAP Header Obrig. 413 Rej. C08 indcomp com conteúdo diferente de 0 Obrig. 414 Rej. C09 CNPJ do transmissor não é um dos CNPJ dos órgãos conveniados (vide Anexo I - Tabela de órgãos conveniados) Obrig. 447 Rej. A informação da versão do leiaute da mensagem, indicador de compactação e a UF de origem são informados no elemento nfecabecmsg do SOAP Header (para maiores detalhes vide item 3.4). A SUFRAMA deverá se identificar com cuf=90. A aplicação deverá validar a UF solicitante (cuf), indicador de compactação (indcomp) e versão da mensagem (versaodados), rejeitando a solicitação recebida em caso de informações inexistentes ou inválidas Validação da área de Dados a) Validação de forma da área de dados A validação de forma da área de dados da mensagem é realizada pelo WS do Ambiente Nacional com a aplicação da seguinte regra: Validação da área de dados da mensagem # Regra de Validação Aplic. Msg Efeito D01 Verifica Schema XML da Área de Dados Obrig. 215 Rej. D02 Verifica o uso de prefixo no namespace Obrig. 404 Rej. D03 XML utiliza codificação diferente de UTF-8 Obrig. 402 Rej. b) Validação de regras de negócios da Distribuição do Cadastro Nacional de Emissores de DFe Distribuição do Cadastro Nacional de Emissores de DF-e Regras de Negócios # Regra de Validação Aplic. Msg Efeito K01 Tipo do ambiente da solicitação difere do ambiente do Web Service Obrig. 252 Rej Processamento da Solicitação pelo WS do Ambiente Nacional a) Solicitação do Cadastro Nacional de Emissores de DF-e resumido (indcons=1) Pág. 62 / 68

63 O Ambiente Nacional deve gerar o Cadastro Nacional de Emissores de DF-e resumido com a lista de CNPJ de emissores autorizados a emitir DF-e no Cadastro Nacional que tenham o número seqüencial único NSU consecutivo ao NSU informado e o filtro caso tenha sido informado. b) Solicitação do Cadastro Nacional de Emissores de DF-e completo (indcons=2) O Ambiente Nacional deve gerar o Cadastro Nacional de Emissores de DF-e que tenham o número seqüencial único NSU consecutivo ao NSU informado e o filtro caso tenha sido informado. c) Solicitação do movimento de atualização do Cadastro Nacional de Emissores de DF-e (indcons=3) O Ambiente Nacional deve gerar um lote de mensagens de atualizações da UF informada no SOAP Header que tenham o número seqüencial único NSU consecutivo ao NSU informado e o filtro caso tenha sido informado Processamento da Solicitação pelo WS do Ambiente Nacional A criação do resultado da consulta deve observar as seguintes regras: ordem crescente de NSU; quantidade máxima de registros do lote: 500; tamanho máximo do lote: 1 MB; Caso o requisitante tenha solicitado a compactação da área de dados, a estrutura do lote de NF-e (envcne) deve ser compactada com o padrão definido no campo indcompret e convertida em uma seqüência BASE64 e informada no campo cademicomp. A resposta do WS do Ambiente Nacional pode ser: rejeição - com a devolução da mensagem com o motivo da falha informado no cstat. Consulta sem resultado não existe cadastro ou movimento que atenda os critérios de consulta - cstat=120. O Órgão deverá aguardar um tempo mínimo de 3 minutos para efetuar uma nova solicitação de distribuição; Consulta com resultado com a devolução do cadastro ou movimento encontrados cstat = 121; Consulta com resultado, existe continuação com a devolução do cadastro ou movimento encontrados cstat = 122; Pág. 63 / 68

64 5. Web Services Informações Adicionais 5.1 Regras de validação As regras de validação aplicadas nos Web Services estão agrupadas da seguinte forma: Grupo Aplicação A Validação do Certificado Digital utilizada no protocolo SSL geral B Validação da Mensagem geral C Validação das informações de controle da chamada ao Web geral Service D Validação da área de dados da Mensagem XML geral E Validação do Certificado Digital utilizada na Assinatura Digital geral F Validação da Assinatura Digital geral G Validação do Lote de DF-e específica H Validação do Pedido de Distribuição de DF-e específica I Validação do Pedido de Consulta de Protocolos faltantes específica J Validação do Pedido de Envio de Atualização do Cadastro específica Nacional de Emissores de DF-e K Validação do Pedido de Download do Cadastro Nacional de específica Emissores de DF-e As regras do grupo A, B, C, D, E e F são de aplicação geral e aplicadas em todos os Web Services existentes, as regras do grupo G, H, I, J e K são específicos de cada Web Service existente Tabela de códigos de erros e descrições de mensagens de erros CÓDIGO RESULTADO DO PROCESSAMENTO DA SOLICITAÇÃO 108 Serviço Paralisado Momentaneamente (curto prazo) 109 Serviço Paralisado sem Previsão 113 DF-e recebido no Ambiente Nacional 114 Nenhum protocolo faltante localizado 115 Todos os Protocolos faltantes da faixa informada foram localizados 116 Quantidade de protocolos faltantes localizados excedeu o limite, os protocolos excedentes não foram recuperados 117 Nenhum DF-e localizado para distribuição 118 DF-e localizados 119 Atualização recebida e processada pelo Ambiente Nacional 120 Nenhuma Atualização de cadastro localizada 121 Consulta com resultado 122 Consulta com resultado, existe continuação CÓDIGO MOTIVOS DE NÃO ATENDIMENTO DA SOLICITAÇÃO 204 Rejeição: Existe DF-e já autorizado com a mesma série e número 205 Rejeição: DF-e está denegado na base de dados da SEFAZ 206 Rejeição: Número de DF-e já está inutilizado na Base de dados da SEFAZ 213 Rejeição: CNPJ-Base do Emitente difere do CNPJ-Base do Certificado Digital 214 Rejeição: Tamanho da mensagem excedeu o limite estabelecido 215 Rejeição: Falha no schema XML 217 Rejeição: DF-e não consta na base de dados da SEFAZ 218 Rejeição: DF-e já está cancelada na base de dados da SEFAZ 238 Rejeição: Cabeçalho - Versão do arquivo XML superior a Versão vigente 239 Rejeição: Cabeçalho - Versão do arquivo XML não suportada 241 Rejeição: Um número da faixa já foi utilizado 243 Rejeição: XML Mal Formado 252 Rejeição: Ambiente informado diverge do Ambiente de recebimento Pág. 64 / 68

65 256 Rejeição: Uma número de DF-e da faixa já está inutilizado na Base de dados da SEFAZ 280 Rejeição: Certificado Transmissor inválido 281 Rejeição: Certificado Transmissor Data Validade 282 Rejeição: Certificado Transmissor sem CNPJ 283 Rejeição: Certificado Transmissor - erro Cadeia de Certificação 284 Rejeição: Certificado Transmissor revogado 285 Rejeição: Certificado Transmissor difere ICP-Brasil 286 Rejeição: Certificado Transmissor erro no acesso a LCR 290 Rejeição: Certificado Assinatura inválido 291 Rejeição: Certificado Assinatura Data Validade 292 Rejeição: Certificado Assinatura sem CNPJ 293 Rejeição: Certificado Assinatura - erro Cadeia de Certificação 294 Rejeição: Certificado Assinatura revogado 295 Rejeição: Certificado Assinatura difere ICP-Brasil 296 Rejeição: Certificado Assinatura erro no acesso a LCR 297 Rejeição: Assinatura difere do calculado 298 Rejeição: Assinatura difere do padrão do Projeto 402 Rejeição: XML da área de dados com codificação diferente de UTF Rejeição: Uso de prefixo de namespace não permitido 409 Rejeição: Elemento nfecabecmsg inexistente no SOAP Header 410 Rejeição: Campo cuf inexistente no elemento nfecabecmsg do SOAP Header 411 Rejeição: UF informada no campo cuf não é atendida pelo WebService 412 Rejeição: Campo versaodados inexistente no elemento nfecabecmsg do SOAP Header 413 Rejeição: Campo indcomp inexistente no elemento nfecabecmsg do SOAP Header 414 Rejeição: Campo indcomp com conteúdo inválido 415 Rejeição: CNPJ do transmissor não está autorizado a enviar DF-e desta UF 416 Rejeição: Falha na descompactação da área de dados 419 Rejeição: Cancelamento para NF-e denegada 420 Rejeição: Cancelamento para NF-e já cancelada 421 Rejeição: CC-e para NF-e inexistente 422 Rejeição: CC-e para NF-e cancelada 423 Rejeição: CC-e para NF-e denegada 424 Rejeição: Número do Tipo de Autorizador do protocolo inicial inválido 425 Rejeição: Código da UF do protocolo inicial incompatível com a UF solicitante 426 Rejeição: Falha no schema XML da área de dados descompactada 427 Rejeição: Uso de prefixo de namespace não permitido na área de dados descompactada Rejeição: CNPJ do transmissor não está autorizado a enviar atualização desta UF 430 Rejeição: Indicador de Compactação desligado e mensagem de dados compactada 431 Rejeição: Indicador de Compactação ligado e mensagem de dados descompactada 432 Rejeição: Código da UF do DF-e difere do Código da UF do SOAP Header 433 Rejeição: CNPJ do transmissor não está autorizado a consultar os protocolos desta UF 434 Rejeição: Sigla da UF do Emissor difere do Código da UF do SOAP Header 435 Rejeição: CNPJ do Emissor inválido 436 Rejeição: IE do Emissor inválido 437 Rejeição: devento futura ou anterior a Rejeição: dvigobrig deve ser informado quando indobrig = 2 ou Rejeição: dvigobrig não deve ser informado quanto indobrig = Rejeição: dvigobrig informado anterior a (início da 1ª obrigatoriedade) Pág. 65 / 68

66 441 Rejeição: Credenciamento não permitido, o emissor já credenciado ou suspenso 442 Rejeição: Atualização não é possível, emissor inexistente no cadastro 443 Rejeição: Suspensão de credenciamento impossível, emissor não está ativo 444 Rejeição: Reativação de credenciamento impossível, emissor não está suspenso 445 Rejeição: Descredenciamento impossível, emissor já se encontra descredenciado 446 Rejeição: Não existe emissor no cadastro para ser alterado 447 Rejeição: CNPJ do transmissor não é um dos CNPJ dos órgãos conveniados 569 Rejeição: Inexiste Schema XML com o nome informado no atributo schema 570 Rejeição: Falha ao validar o DF-e com o schema XML informado no atributo schema 571 Rejeição: Data do protocolo (dhrecbto) inválida 572 Rejeição: cstat do protocolo inválido 573 Rejeição: Protocolo não vinculado ao DF-e OBS.: 1. Recomendamos a não utilização de caracteres especiais ou acentuação nos textos das mensagens de erro. 2. Recomendamos que o campo xmotivo da mensagem de erro para o código 999 seja informado com a mensagem de erro do aplicativo ou do sistema que gerou a exceção não prevista Número do protocolo O número do protocolo é gerado pelo Portal da Secretaria da Fazenda Estadual ou da Receita Federal do Brasil para identificar univocamente as transações realizadas de autorização de uso, denegação de uso, cancelamento de NF-e e inutilização de numeração de NF-e e Evento da NF-e. A regra de formação do número do protocolo é: Tipo de Autorizador código da UF ano seqüencial de 10 posições 1 posição com o Tipo de Autorizador (1=SEFAZ normal, 2= Contingência SCAN - RFB, 3=SEFAZ VIRTUAL, 4=SEFAZ VIRTUAL-AN); 2 posições para o código da UF do IBGE; 2 posições para ano; 10 posições para o seqüencial no ano. A geração do número de protocolo deverá ser única, sendo utilizada por todos os Web Services que precisam atribuir um número de protocolo para o resultado do processamento. Pág. 66 / 68

67 Anexo I - Tabela de órgãos conveniados Ato Legal UF CNPJ AC / AL AM / AP BA / CE / DF / ES / GO / MA MG / MG (PRODEMGE) / MS / MT (CEPROMAT) / PA PB / PE / PI / PR (CELEPAR) / RJ / RN / RO / RR RS / SC / SE SP / TO / RFB (SERPRO) / SCAN (SERPRO) / SUFRAMA Protocolo de Cooperação n 03/2005 Protocolo ICMS 25/08 SVAN (SERPRO) / Protocolo ICMS 55/07 SVRS / Pág. 67 / 68

68 Anexo II - Endereço dos Web Services As URL dos serviços de compartilhamento do Ambiente Nacional são: A. Ambiente de HOMOLOGAÇÃO: Web Service de recepção de lotes na RFB: Web Service de distribuição da RFB: Web Service de consulta aos protocolos faltantes: Web Service de Manutenção do CNE: Web Service de Distribuição (Download) do CNE: B. Ambiente de PRODUÇÃO: Web Service de recepção de lotes na RFB: Web Service de distribuição da RFB: Web Service de consulta aos protocolos faltantes: Web Service de Manutenção do CNE: Web Service de Distribuição (Download) do CNE: Pág. 68 / 68