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