Introdução

Desde o surgimento da Internet e sua popularização várias tecnologias têm surgido para facilitar a troca de informações. Cada organização avalia as tecnologias disponíveis e escolhe a que é melhor para si. Em algumas empresas de grande porte faz-se necessário a utilização de diversas tecnologias diferentes.

Como fazer para que haja uma maior integração entre os serviços disponíveis na Internet? Deve existir uma tecnologia que trate de tarefas complexas, como o gerenciamento de transações, disponibilizando serviços distribuídos que utilizem interfaces de acesso simples e bem definidas. Essa tecnologia já existe e esses serviços distribuídos são conhecidos como Web Services.

Definição

Web Service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Os Web Services são componentes que permitem às aplicações “conversarem” entre si enviando e recebendo dados no formato XML.

Usando Web Services, uma aplicação pode invocar outra para efetuar tarefas simples ou complexas mesmo que as duas aplicações estejam em diferentes sistemas e escritas em linguagens diferentes. Dessa forma, os Web Services fazem com que os recursos estejam disponíveis para qualquer tipo de aplicação cliente.

Os Web Services são identificados por um URI, descritos e definidos usando XML. A tecnologia de Web Services é atrativa porque se baseia em outras tecnologias já adotadas por padrão, em particular XML e HTTP.

Existem várias definições para Web Service. Observe algumas delas:

• Componentes de software flexível, que interagem entre si dinamicamente através de tecnologias padrões da Internet — Gartner.
• Um pedaço da lógica de negócio acessível através da Internet utilizando padrões abertos — Microsoft.
• Um software identificado por um URI, cujas interfaces e vinculações são capazes de serem definidas, descritas e descobertas por artefatos XML. Suporta interações diretas com outras aplicações de software usando mensagens baseadas em XML através de protocolos da Internet — W3C.

Tecnologias envolvidas

Para representar e estruturar as mensagens enviadas e recebidas é utilizado o XML. As chamadas às operações, incluindo os parâmetros de entrada e saída, são codificadas no protocolo SOAP. Os serviços (operações, mensagens, parâmetros) são descritos usando a linguagem WSDL. O processo de publicação, pesquisa e descoberta de Web Services utiliza o protocolo UDDI.

XML

É a base em que os Web Services são construídos. O XML fornece a descrição, o armazenamento e o formato da transmissão.

A sintaxe XML usada nas tecnologias dos Web Services especifica como os dados são representados genericamente, define como e com que qualidade de serviço os dados são transmitidos. Os Web Services decodificam as várias partes do XML para interagir com as várias aplicações.

SOAP

SOAP (Simple Object Access Protocol) é um protocolo projetado para invocar aplicações remotas através de RPC (Remote Procedure Calls — Chamadas Remotas de Procedimento) ou trocas de mensagens, em um ambiente independente de plataforma e linguagem de programação. É um padrão normalmente aceito para utilizar-se com Web Services. Assim, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização de uma linguagem (XML) e mecanismo de transporte (HTTP) padrões.

Características do SOAP

Algumas características do SOAP:

• Definido pelo consórcio W3C;
• Protocolo baseado em XML para a troca de informações em um ambiente distribuído;
• Padrão de utilização com Web Services;
• Normalmente utiliza HTTP como protocolo de transporte.

Mensagem SOAP

Uma mensagem SOAP consiste basicamente dos seguintes elementos:

• Envelope — toda mensagem SOAP deve contê-lo. É o elemento raiz do documento XML. O Envelope pode conter declarações de namespaces e também atributos adicionais como o que define o estilo de codificação (encoding style). Um “encoding style” define como os dados são representados no documento XML;
• Header — é um cabeçalho opcional. Ele carrega informações adicionais, como por exemplo, se a mensagem deve ser processada por um determinado nó intermediário. Quando utilizado, o Header deve ser o primeiro elemento do Envelope;
• Body — elemento obrigatório que contém o payload (informação a ser transportada para o seu destino final). O elemento Body pode conter um elemento opcional Fault, usado para carregar mensagens de status e erros retornadas pelos “nós” ao processarem a mensagem.

SOAP e RPC

Dentre outras coisas, o SOAP foi desenhado para encapsular e transportar chamadas de RPC, e para isto utiliza-se dos recursos e da flexibilidade do XML, sob HTTP.

RPCs são chamadas locais a métodos de objetos (ou serviços) remotos. Assim, pode-se acessar os serviços de um objeto localizado em um outro ponto da rede, através de uma chamada local a este objeto. Cada chamada ou requisição exige uma resposta.

O processo de uma chamada RPC funciona da seguinte maneira: Antes de serem enviadas pela rede, as chamadas RPC (emitidas pela aplicação cliente) são serializadas seguindo o padrão SOAP. O serviço remoto, ao receber a mensagem, faz o processo contrário: desencapsula a mensagem e extrai as chamadas de método. A aplicação servidora processa a chamada e envia uma resposta ao cliente. O processo então se repete: a resposta também é serializada e enviada pela rede. Na máquina cliente, a resposta é desencapsulada e repassada para a aplicação cliente.

A especificação SOAP define as seguintes informações como necessárias em toda chamada RPC:

• A URI do objeto alvo;
• O nome do método;
• Os parâmetros do método (requisição ou resposta);
• Uma assinatura do método opcional;
• Um cabeçalho opcional.

WSDL

O WSDL (Web Services Definition Language) descreve os serviços disponibilizados à rede através de uma semântica XML. Ele providencia a documentação necessária para se chamar um sistema distribuído e o procedimento necessário para que esta comunicação se estabeleça. Enquanto o SOAP especifica a comunicação entre um cliente e um servidor, o WSDL descreve os serviços oferecidos.

Um documento WSDL define um XML Schema para descrever um Web Service.

Basicamente, quando o cliente deseja enviar uma mensagem para um determinado Web Service, ele obtém a descrição do serviço (através da localização do respectivo documento WSDL), e em seguida constrói a mensagem, passando os tipos de dados corretos (parâmetros, etc) de acordo com a definição encontrada no documento. Em seguida, a mensagem é enviada para o endereço onde o serviço está localizado, a fim de que possa ser processada. O Web Service, ao receber a mensagem procede com uma validação conforme as informações contidas no documento WSDL. A partir daí, o serviço remoto sabe como tratar a mensagem, como processá-la (possivelmente enviando-a para outro programa) e como montar a resposta ao cliente.

UDDI

O UDDI (Universal Description Discovery and Integration) é um protocolo que foi desenvolvido para a organização e registro de Web Services.

É um protocolo aprovado como padrão pela OASIS e especifica um método para publicar e descobrir diretórios de serviços em uma arquitetura orientada a serviços (SOA).

O UDDI fornece três funções principais, conhecidas como publicação, descoberta e ligação:

1. Publicação: permite que uma organização divulgue seus serviços;

2. Descoberta: permite que o cliente procure e encontre um determinado serviço;

3. Ligação (binding): permite que o cliente possa estabelecer a ligação e interagir com o serviço.

Segurança

A segurança dos Web Services é um dos pontos fracos desta tecnologia. O problema não é a falta de mecanismos de segurança, mas sim a falta de consenso em qual deve ser o mecanismo a ser adotado pela tecnologia Web Service.

As questões mais relevantes na segurança são as seguintes:

• Autenticidade — a certeza de que uma transação do Web Service ocorreu entre o servidor e seu cliente;
• Privacidade — as mensagens trocadas entre o servidor e o cliente não podem ser interceptadas por uma pessoa não autorizada;
• Integridade — as mensagens trocadas entre o servidor e o cliente devem permanecer inalteradas.

Mecanismos de segurança

Seguem os mecanismos de segurança que podem ser adotados ao se trabalhar com Web Services:

SSL

O SSL (Secure Socket Layer) quando aplicado a pequenos dispositivos, oferece autenticação, integridade de dados e privacidade de serviços. Atualmente, a solução para enviar informação confidencial para Web Services é utilizar um mecanismo de segurança SSL sobre HTTP também conhecido como HTTPS (Hypertext Transfer Protocol Secure). Esse mecanismo protege informações confidenciais e é de fácil configuração.

XML Signature

É uma iniciativa conjunta da IETF (Internet Engineering Task Force) e do W3C para especificar uma sintaxe XML e as regras de processamento para criação e representação digital de assinaturas. As vantagens na utilização da XML Signature, ao contrário de outras normas de assinaturas digitais, estão baseadas na independência da linguagem de programação, fácil interpretação humana e independência do fabricante. Essa tecnologia também permite assinar digitalmente subconjuntos de um documento XML.

XML Encryption

Especifica um processo para encriptação de dados e sua representação em formato XML. Os dados podem ser arbitrários (incluindo um documento XML), elementos XML ou conteúdos de elementos XML. Um documento XML que utiliza a XML Encryption pode ser visto por qualquer utilizador, mas apenas o proprietário da chave de decodificação conseguirá compreender o conteúdo codificado.

WS-Security

O WS-Security (Web Services Security) é uma iniciativa conjunta de empresas como Microsoft, IBM e Verisign. É destinada ao uso da XML-Signature e da XML-Encryption para fornecer segurança às mensagens SOAP. O WS-Security é um esforço destinado a fazer com que os Web Services trabalhem melhor em um ambiente global. O WS-Security também inclui alguns importantes componentes como encaminhamento, confiança e tratamento de transações.

SAML

O SAML (Security Assertion Markup Language) é uma norma emergente para a troca de informação sobre autenticação e autorização. O SAML soluciona um importante problema para as aplicações da próxima geração, que é a possibilidade de utilizadores transportarem seus direitos entre diferentes Web Services. Isto é importante para aplicações que desejam integrar um número de Web Services para formar uma aplicação unificada.

Web Services no projeto NF-e

O Manual de Integração do Contribuinte nos informa o seguinte sobre o padrão de comunicação adotado para o projeto NF-e:

A comunicação entre o contribuinte e a Secretaria de Fazenda Estadual será baseada em Web Services disponibilizados nos Portais das respectivas Secretarias de Fazenda da circunscrição do contribuinte.

O meio físico de comunicação utilizado será a Internet, com o uso do protocolo SSL, 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 Portal da Secretaria de Fazenda Estadual e o aplicativo do contribuinte será realizada no padrão SOAP, com troca de mensagens XML no padrão Style/Enconding: Document/Literal, wrapped. A opção “wrapped” representa a chamada aos métodos disponíveis com a passagem de mais de um parâmetro.

Observe abaixo um exemplo de mensagem enviado para o portal da NFe utilizando o SOAP:

Serviços disponíveis

Os Portais das Secretarias de Fazenda Estaduais irão disponibilizar os seguintes serviços:

1. Recepção de NF-e;

a. Recepção de Lote;

b. Consulta Processamento de Lote;

2. Cancelamento de NF-e;

3. Inutilização de numeração de NF-e;

4. Consulta da situação atual da NF-e;

5. Consulta do status do serviço;

6. Consulta cadastro.

Para cada serviço oferecido existirá um Web Service específico. O fluxo de comunicação é sempre iniciado pelo aplicativo do contribuinte através do envio de uma mensagem ao Web Service com a solicitação do serviço desejado.

O Web Service sempre devolve uma mensagem de resposta confirmando o recebimento da solicitação de serviço ao aplicativo do contribuinte na mesma conexão.

A solicitação de serviço poderá ser atendida na mesma conexão ou ser armazenada em filas de processamento nos serviços mais críticos para um melhor aproveitamento dos recursos de comunicação e de processamento das SEFAZ.

Os serviços podem ser síncronos ou assíncronos em função da forma de processamento da solicitação de serviços:

1. Serviços síncronos — 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;
2. Serviços assíncronos — o processamento da solicitação de serviço não é concluído na mesma conexão, havendo a devolução de uma mensagem de resposta com um recibo que apenas confirma o recebimento da solicitação de serviço. O aplicativo do contribuinte deverá realizar uma nova conexão para consultar o resultado do processamento do serviço solicitado anteriormente.

O diagrama a seguir ilustra o fluxo conceitual de comunicação entre o aplicativo do contribuinte e o Portal da SEFAZ:

Modelo Operacional

Conforme já mencionado, a forma de processamento das solicitações de serviços no projeto Nota Fiscal Eletrônica pode ser síncrona, caso o atendimento da solicitação de serviço seja realizada na mesma conexão, ou assíncrona, caso o processamento do serviço solicitado não seja atendido na mesma conexão, nesta situação torna-se necessária a realização de mais uma conexão para a obtenção do resultado do processamento.

As solicitações de serviços que exigem processamento intenso serão executadas de forma assíncrona e as demais solicitações de serviços de forma síncrona.

Sendo assim, os serviços da NF-e serão implementados da seguinte forma:

Serviços síncronos

As solicitações de serviços de implementação síncrona são processadas imediatamente e o resultado do processamento é obtido em uma única conexão.

Observe na imagem abaixo o fluxo simplificado de funcionamento:

Veja agora como seriam as etapas do processo ideal quando solicitado um serviço síncrono:

a. O aplicativo do contribuinte inicia a conexão enviando uma mensagem de solicitação de serviço para o Web Service;

b. O Web Service recebe a mensagem de solicitação de serviço e encaminha ao aplicativo da NF-e que irá processar o serviço solicitado;

c. O aplicativo da NF-e recebe a mensagem de solicitação de serviço e realiza o processamento, devolvendo uma mensagem de resultado do processamento ao Web Service;

d. O Web Service recebe a mensagem de resultado do processamento e o encaminha ao aplicativo do contribuinte;

e. O aplicativo do contribuinte recebe a mensagem de resultado do processamento e, caso não exista outra mensagem, encerra a conexão.

Serviços assíncronos

As solicitações de serviços de implementação assíncrona são processadas de forma distribuída por vários processos e o resultado do processamento somente é obtido numa segunda conexão.

Observe na imagem abaixo o fluxo simplificado de funcionamento:

Veja agora como seriam as etapas do processo ideal quando solicitado um serviço assíncrono:

a. O aplicativo do contribuinte inicia a conexão enviando uma mensagem de solicitação de serviço para o Web Service de recepção de solicitação de serviços;

b. O Web Service de recepção de solicitação de serviços recebe a mensagem de solicitação de serviço e a coloca na fila de serviços solicitados, acrescentando o CNPJ do transmissor obtido do certificado digital do transmissor;

c. O Web Service de recepção de solicitação de serviço retorna o recibo da solicitação de serviço e a data e hora de recebimento da mensagem no Web Service;

d. O aplicativo do contribuinte recebe o recibo e o coloca na fila de recibos de serviços solicitados e ainda não processados e, caso não exista outra mensagem, encerra a conexão;

e. Na Secretaria de Fazenda Estadual a solicitação de serviços é retirada da fila de serviços solicitados pelo aplicativo da NF-e;

f. O serviço solicitado é processado pelo aplicativo da NF-e e o resultado do processamento é colocado na fila de serviços processados;

g. O aplicativo do contribuinte retira um recibo da fila de recibos de serviços solicitados;

h. O aplicativo do contribuinte envia uma consulta de recibo, iniciando uma conexão com o Web Service “Consulta Recibo (NFeRetRecepcao)”;

i. O Web Service “Consulta Recibo” recebe a mensagem de consulta recibo e localiza o resultado de processamento da solicitação de serviço;

j. O Web Service “Consulta Recibo (NFeRetRecepcao)” devolve o resultado do processamento ao aplicativo contribuinte;

k. O aplicativo do contribuinte recebe a mensagem de resultado do processamento e, caso não exista outra mensagem, encerra a conexão.

Filas e mensagens

As filas de mensagens de solicitação de serviços são necessárias para a implementação do processamento assíncrono das solicitações de serviços.

As mensagens de solicitações de serviços no processamento assíncrono são armazenadas em uma fila de entrada.

Para ilustrar como as filas armazenam as informações, observe o diagrama a seguir:

A estrutura de um item é composta pela área de controle (identificador) e pela área de detalhe. As seguintes informações são adotadas como atributos de controle:

• CNPJ do transmissor — CNPJ da empresa que enviou a mensagem que não necessita estar vinculado ao CNPJ do estabelecimento emissor da NF-e. Somente o transmissor da mensagem terá acesso ao resultado do processamento das mensagens de solicitação de serviços;
• Recibo de entrega — número seqüencial único atribuído para a mensagem pela Secretaria de Fazenda Estadual. Este atributo identifica a mensagem de solicitação de serviços na fila de mensagem;
• Data e hora de recebimento da mensagem — data e hora local do instante de recebimento da mensagem atribuída pela Secretaria de Fazenda Estadual. Este atributo é importante como parâmetro de desempenho do sistema, eliminação de mensagens, adoção do regime de contingência, etc. O tempo médio de resposta é calculado com base neste atributo.

A área de mensagem contém uma área de cabeçalho e a área de dados em formato XML.

Para processar as mensagens de solicitações de serviços, a aplicação da NF-e irá retirar a mensagem da fila de entrada de acordo com a ordem de chegada, devendo armazenar o resultado do processamento da solicitação de serviço em uma fila de saída.

A fila de saída terá a mesma estrutura da fila de entrada, a única diferença será no conteúdo do detalhe da mensagem que contém o resultado do processamento da solicitação de serviço em formato XML.

O tempo médio de resposta que mede a performance do serviço de processamento dos lotes é calculado com base no tempo decorrido entre o momento de recebimento da mensagem e o momento de armazenamento do resultado do processamento da solicitação de serviço na fila de saída.

Padrão de mensagens dos Web Services

As chamadas dos Web Services disponibilizados pelas Secretarias de Fazenda Estaduais ou Secretaria da Receita Federal e os respectivos resultados do processamento são realizadas através das mensagens com o seguinte padrão:

Área de cabeçalho

Estrutura XML padrão para todas as mensagens de chamada e retorno de resultado dos Web Services disponibilizados pelas Secretarias de Fazenda Estaduais ou Secretaria da Receita Federal, que contém os dados de controle da mensagem. A área de cabeçalho está sendo utilizada para armazenar a versão do layout do XML informado na área de dados.

Observe o layout da área de cabeçalho padrão definido através do Schema XML cabecMsg_v1.02.xsd:

O campo versaoDados deve conter a informação da versão do layout do XML armazenada na área de dados da mensagem.

Segue um exemplo da área de cabeçalho:

<?xml version="1.0" encoding="UTF-8" ?>
<cabecMsg xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.02">
  <versaoDados>1.07</versaoDados>
</cabecMsg>

Área de dados

Estrutura XML variável definida na documentação do Web Service acessado.

Validação do XML enviado aos Web Services

As alterações de layout 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 do XML é realizada por um analisador sintático (parser) que verifica se a mensagem atende às definições e regras de seu Schema XML.

Qualquer divergência entre o XML e seu Schema, provoca um erro de validação.

A primeira condição para que a mensagem seja validada com sucesso é que ela seja submetida ao Schema correto.

Dessa forma, os aplicativos do contribuinte devem estar preparados para gerar as mensagens no layout em vigor, devendo ainda informar a versão do layout no campo versaoDados da área de cabeçalho da mensagem.

Schemas XML

Toda mudança de layout das mensagens dos Web Services implica na atualização do seu respectivo Schema.

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”.

Exemplos:

• envNFe_v1.03.xsd (Schema XML de Envio de NFe, versão 1.03);
• retCancNFe_v1.10.xsd (Schema XML do Retorno de Cancelamento de NFe, versão 1.10);
• leiauteNFe_v10.15.xsd (Schema XML dos tipos básicos da NFe, versão 10.15).

A maioria dos Schemas da NF-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). Nesses 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.00.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.

As modificações de layout das mensagens dos Web Services podem ser causadas por necessidades técnicas ou em razão da modificação de alguma legislação.

Segue abaixo um exemplo de Schema XML:

Versões dos Schemas

Os Schemas válidos para o Projeto da Nota Fiscal Eletrônica serão disponibilizados no Portal da Nota Fiscal Eletrônica (www.nfe.fazenda.gov.br), e serão liberados após autorização da equipe de Gestão do Projeto formada pelos Líderes dos Projetos nos Estados e representante das Empresas.

A cada nova liberação será disponibilizado um arquivo compactado contendo o conjunto de Schemas a serem utilizados pelas empresas para a geração dos arquivos XML. Este arquivo será denominado “Pacote de Liberação” e será numerado seqüencialmente. Os pacotes de liberação serão identificados pelas letras “PL”, seguida do número do pacote.

Exemplificando: o pacote PL_001.zip representa o “Pacote de Liberação” nº 1 de Schemas da Nota Fiscal Eletrônica.

Os Schemas válidos estão contidos no pacote de liberação e são identificados pelo seu nome, seguido da versão do respectivo Schema.

Assim, para o Schema de “Envio de Lotes de Nota Fiscal Eletrônica”, corresponderá um arquivo com a extensão .XSD, que terá o nome de “enviNFe_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, deve-se comparar o número da versão do Schema deste pacote com o do pacote anterior.

Observe a tabela abaixo:

Veja que o pacote 02 foi liberado em junho, dois meses após o pacote 01. Neste pacote apenas um Schema sofreu alteração: “enviNFe_v1.00.xsd”.

É possível que os Web Services estejam aceitando várias versões de Schemas. Isso ocorre porque enquanto uma empresa utiliza a versão 1.00 do Schema “Envio de Lotes de Nota Fiscal Eletrônica” (enviNFe_v1.00.xsd), outra já poderá ter se atualizado e está utilizando uma versão mais recente. Por isso a importância do preenchimento do campo “versaoDados”, que informa a versão do Schema que está sendo utilizada.

Disponibilização dos Web Services

Já vimos que os Portais das SEFAZ irão disponibilizar os seguintes serviços:

1. Recepção de NF-e;

a. Recepção de Lote;

b. Consulta Processamento de Lote;

2. Cancelamento de NF-e;

3. Inutilização de numeração de NF-e;

4. Consulta da situação atual da NF-e;

5. Consulta do status do serviço;

6. Consulta cadastro.

Vejamos a descrição detalhada de cada um desses serviços.

Web Service Recepção de Lote de NF-e (NfeRecepcao)

• Função: serviço destinado à recepção de mensagens de lote de NF-e;
• Processo: assíncrono;
• Método: nfeRecepcaoLote;
• Entrada: Estrutura XML com as notas fiscais enviadas;
• Schema XML da Entrada: envNFe_v99.99.xsd;
• Retorno: Estrutura XML com a mensagem do resultado da transmissão;
• Schema XML do Retorno: retEnvNFe_v99.99.xsd.

O processamento de Lote é realizado pelo Servidor de Processamento de NF-e que consome as mensagens armazenadas na fila de entrada pelo método NfeRecepcao e faz a validação da forma e das regras de negócios e armazena o resultado do processamento na fila de saída.

Se a mensagem for recebida com algum tipo de erro, será gerada uma mensagem de erro. Caso não exista erro, será gerado um recibo com número, data, hora local de recebimento e tempo médio de resposta do serviço nos últimos 5 minutos.

O número do Recibo do Lote deve ser gerado pelo Portal da SEFAZ, com a seguinte regra de formação: duas posições para o código da UF onde foi entregue o lote e treze posições numéricas sequenciais:

O projeto utiliza a codificação da UF definida pelo IBGE. Observe a tabela abaixo:

A NF-e poderá ser autorizada ou denegada. Nos dois casos será gerado um número de protocolo. Este número de protocolo também será gerado nos casos de cancelamento de NF-e e inutilização da numeração. Veja abaixo a regra de formação do número do protocolo:

• 01 posição para indicar o órgão

1 — Secretaria de Fazenda Estadual;

2 — Receita Federal;

3 — SEFAZ Virtual RS;

4 — SEFAZ Virtual RFB.

• 02 posições para o código da UF do IBGE;
• 02 posições para ano;
• 10 posições para o seqüencial no ano.

O resultado do processamento do lote será disponibilizado na fila de saída e conterá o resultado da validação de cada NF-e inserida no lote. Este resultado ficará disponível na fila de saída por um período mínimo de 24 horas.

No final do processamento poderá ocorrer o seguinte:

• Rejeição — a NF-e será descartada, não sendo armazenada no Banco de Dados podendo ser corrigida e novamente transmitida;
• Autorização de uso — a NF-e será armazenada no Banco de Dados;
• Denegação de uso — a NF-e será armazenada no Banco de Dados com esse status nos casos de irregularidade fiscal do emitente ou do destinatário.

Serão realizadas as seguintes validações: A, B, C, D, E, F e G. Consulte a sessão Regras de Validação para entender o que significa cada uma das opções.

Web Service Consulta Processamento de Lote de NF-e (NfeRetRecepcao)

• Função: serviço destinado a retornar o resultado do processamento do lote de NF-e;
• Processo: assíncrono;
• Método: nfeRetRecepcao;
• Entrada: Estrutura XML contendo o número do recibo que identifica a mensagem de envio de lotes de NF-e;
• Schema XML da Entrada: consReciNFe_v99.99.xsd;
• Retorno: Estrutura XML com o resultado do processamento da mensagem de envio de lote de NF-e;
• Schema XML do Retorno: retConsReciNFe_v99.99.xsd.

Este método oferece a consulta do resultado do processamento de um lote de NF-e.

O aplicativo do contribuinte deve ser construído de forma a aguardar um tempo mínimo de 15 segundos entre o envio do Lote de NF-e para processamento e a consulta do resultado deste processamento, evitando a obtenção desnecessária do status de erro 105 — “Lote em Processamento”.

No final do processamento a mensagem de retorno poderá ser:

• Lote processado (cStat=104) — com os resultados individuais de processamento das NF-e;
• Lote em processamento (cStat=105) — o aplicativo do contribuinte deverá fazer uma nova consulta;
• Lote não localizado (cStat=106) — o aplicativo do contribuinte deverá providenciar o reenvio da mensagem;
• Recibo ou CNPJ do requisitante com problemas (cStat=248 ou 223) — o aplicativo do contribuinte deverá sanar o problema;

Serão realizadas as seguintes validações: A, B, C, D e E. Consulte a sessão Regras de Validação para entender o que significa cada uma das opções.

Web Service Cancelamento de NF-e (NfeCancelamento)

• Função: serviço destinado ao atendimento de solicitações de cancelamento de Notas Fiscais Eletrônicas;
• Processo: síncrono;
• Método: nfeCancelamentoNF;
• Entrada: Estrutura XML contendo a mensagem de solicitação de cancelamento;
• Schema XML da Entrada: cancNFe_v99.99.xsd;
• Retorno: Estrutura XML contendo a mensagem do resultado da solicitação de cancelamento;
• Schema XML do Retorno: retCancNFe_v99.99.xsd.

Este método é responsável por receber as solicitações referentes ao cancelamento de NF-e.

Ao receber a solicitação do transmissor, a aplicação do Portal da SEFAZ realiza o processamento da solicitação e devolve o resultado do processamento para o aplicativo do contribuinte.

A mensagem de solicitação de cancelamento de NF-e é um documento eletrônico e deve ser assinado digitalmente pelo emitente da NF-e.

Serão realizadas as seguintes validações: A, B, C, D, E, F e H. Consulte a sessão Regras de Validação para entender o que significa cada uma das opções.

Web Service Inutilização de Numeração de NF-e (NfeInutilizacao)

• Função: serviço destinado ao atendimento de solicitações de inutilização de numeração;
• Processo: síncrono;
• Método: nfeInutilizacaoNF;
• Entrada: Estrutura XML contendo a mensagem de solicitação de inutilização;
• Schema XML da Entrada: inutNFe_v99.99.xsd;
• Retorno: Estrutura XML contendo a mensagem do resultado da solicitação de inutilização;
• Schema XML do Retorno: retInutNFe_v99.99.xsd.

Este método é responsável por receber as solicitações referentes a inutilização de faixas de numeração de notas fiscais eletrônicas. Ao receber a solicitação, o Web Service realiza o processamento da solicitação e devolve o resultado do processamento para o aplicativo do transmissor.

A mensagem de pedido de inutilização de numeração de NF-e é um documento eletrônico e deve ser assinado digitalmente pelo emitente da NF-e.

Serão realizadas as seguintes validações: A, B, C, D, E, F e I. Consulte a sessão Regras de Validação para entender o que significa cada uma das opções.

Web Service Consulta Situação Atual da NF-e (NfeConsulta Protocolo)

• Função: serviço destinado ao atendimento de solicitações de consulta da situação atual da NF-e na Base de Dados do Portal da Secretaria de Fazenda Estadual;
• Processo: síncrono;
• Método: nfeConsultaNF;
• Entrada: Estrutura XML contendo a chave de acesso da NF-e;
• Schema XML da Entrada: consSitNFe_v99.99.xsd;
• Retorno: Estrutura XML contendo a mensagem do resultado da consulta de protocolo;
• Schema XML do Retorno: retConsSitNFe_v99.99.xsd.

Este método é responsável por receber as solicitações referentes à consulta de situação de notas fiscais eletrônicas enviadas para as SEFAZ. Seu acesso é permitido apenas pela chave única de identificação da nota fiscal.

O aplicativo do contribuinte envia a solicitação para o Web Service da SEFAZ. O Web Service processa a solicitação de consulta, valida a Chave de Acesso da NF-e e retorna a mensagem contendo a situação atual da NF-e na Base de Dados.

O processamento do pedido de consulta de status de NF-e pode resultar em uma mensagem de erro ou retornar a situação atual da NF-e consultada. Caso a NF-e seja localizada, retornar o “cStat” com os valores 100, 101 ou 110.

Serão realizadas as seguintes validações: A, B, C, D e J. Consulte a sessão Regras de Validação para entender o que significa cada uma das opções.

Web Service Consulta Status do Serviço (NfeStatusServico)

• Função: serviço destinado à consulta do status do serviço prestado pelo Portal da Secretaria de Fazenda Estadual;
• Processo: síncrono;
• Método: nfeStatusServicoNF;
• Entrada: Estrutura XML para a consulta do status do serviço;
• Schema XML da Entrada: consStatServ_v99.99.xsd;
• Retorno: Estrutura XML contendo a mensagem do resultado da consulta do status do serviço;
• Schema XML do Retorno: retConsStatServ_v99.99.xsd.

Este método é responsável por receber as solicitações referentes à consulta do status do serviço do Portal da SEFAZ.

O aplicativo do contribuinte envia a solicitação para o Web Service da SEFAZ. O Web Service processa a solicitação de consulta e retorna a mensagem contendo o status do serviço.

As Empresas que construírem um aplicativo que se mantenha em loop permanente de consulta a este Web Service, devem aguardar um tempo mínimo de 3 minutos entre cada consulta, evitando sobrecarregar desnecessariamente os servidores da SEFAZ.

O processamento do pedido de consulta de status de Serviço pode resultar em uma mensagem de erro ou retornar a situação atual do Servidor de Processamento: códigos de situação 107, 108 e 109.

A critério da UF o campo xObs pode ser utilizado para fornecer maiores informações ao contribuinte, como por exemplo: “manutenção programada”, “modificação de versão do aplicativo”, “previsão de retorno”, etc.

Serão realizadas as seguintes validações: A, B, C, D e K. Consulte a sessão Regras de Validação para entender o que significa cada uma das opções.

Web Service Consulta Cadastro (CadConsultaCadastro)

• Função: Serviço para consultar o cadastro de contribuintes do ICMS da unidade federada;
• Processo: síncrono;
• Método: consultaCadastro;
• Entrada: Estrutura XML para consulta ao cadastro de contribuintes ICMS;
• Schema XML da Entrada: consCad_v99.99.xsd;
• Retorno: Estrutura XML com o retorno da consulta ao cadastro de contribuintes do ICMS;
• Schema XML do Retorno: retConsCad_v99.99.xsd.

Este Web Service oferece a consulta pública do cadastro de contribuintes do ICMS de uma UF.

Apenas as empresas autorizadas a emitir Documentos Fiscais Eletrônicos poderão utilizar este serviço. A UF que oferecer o Web Service deverá verificar se o CNPJ da empresa solicitante consta do cadastro nacional de emissores de Documentos Fiscais Eletrônicos — DF-e.

A identificação da empresa solicitante do serviço será realizada através do CNPJ contido na extensão otherName — OID=2.16.76.1.3.3 do certificado digital utilizado na conexão SSL.

É importante ressaltar que este Web Service não tem a mesma disponibilidade dos demais Web Services da NF-e.

O aplicativo do contribuinte envia a solicitação para o Web Service da SEFAZ. O Web Service processa a solicitação de consulta, validando o argumento de pesquisa informado (CNPJ ou CPF ou IE) e retorna a mensagem contendo a situação cadastral atual do contribuinte no cadastro de contribuintes do ICMS.

O resultado do processamento poderá ser:

• cStat=111 — consulta cadastro com uma ocorrência;
• cStat=112 — consulta cadastro com mais de uma ocorrência, existe mais de um estabelecimento para o argumento pesquisado. (por exemplo: consulta por IE de contribuinte com diversos estabelecimentos e inscrição estadual única).

Serão realizadas as seguintes validações: A, B, C, D e L. Consulte a sessão Regras de Validação para entender o que significa cada uma das opções.

OBS: Consulte os layouts de cada um dos Schemas descritos anteriormente no Manual de Integração do Contribuinte.

Regras de validação

As regras de validação aplicadas nos Web Services estão agrupadas da seguinte forma:

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, K e L são específicos de cada Web Service existente.

Vamos detalhar cada uma das regras acima:

A — Validação do certificado digital utilizado no protocolo SSL

As validações A01 a 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-BR” no repositório de certificados digitais do servidor de Web Service da SEFAZ.

B — Validação da mensagem XML no serviço assíncrono

A aplicação do contribuinte não poderá permitir a geração de mensagem com tamanho superior a 500 KB. Caso o contribuinte envie uma mensagem maior que 500 KB poderá ocorre o seguinte:

• Conexão interrompida sem mensagem de erro. Isso ocorrerá quando o controle do tamanho da mensagem for implementado por configurações do ambiente de rede da SEFAZ (firewall).
• Devolução da mensagem de erro 214. Isso ocorrerá quando o controle do tamanho da mensagem for implementado por aplicativo.

C — Validação da área de cabeçalho da mensagem XML

O cabeçalho contém a versão do Schema XML da mensagem contida na área de dados que será utilizado pelo Web Service.

A ocorrência de qualquer erro na validação da área de cabeçalho da mensagem impossibilita o processamento da mensagem contida na área de dados.

D — Validação da área de dados da mensagem XML

E — Validação do certificado digital utilizado na assinatura digital

F — Validação da assinatura digital

G — Validação da NF-e

H — Validação do pedido de cancelamento de NF-e

O cancelamento só poderá ser realizado nota a nota e para cada cancelamento homologado é criado um novo protocolo de status para NF-e, com a atribuição de um número de protocolo único.

I — Validação do pedido de inutilização de numeração de NF-e

Para cada inutilização de numeração de NF-e homologada é criado um novo protocolo de status para NF-e, com a atribuição de um número de protocolo único.

J — Validação do pedido de consulta de situação de NF-e

K — Validação do pedido de consulta de status de serviço

L — Validação do pedido de consulta de cadastro de contribuintes

Tabela de erros

Segue abaixo as tabelas de códigos de erros e descrições de mensagens de erros. Essas tabelas podem ser consultadas no Manual de Integração do Contribuinte:

Padrões de nomes para os arquivos

Visando facilitar o processo de guarda dos arquivos pelos legítimos interessados, foi criado um padrão de nomes para os diversos tipos de arquivos utilizados pelo sistema NF-e:

• NF-e: O nome do arquivo será a chave de acesso completa com extensão “-nfe.xml”;
• Envio de Lote de NF-e: O nome do arquivo será o número do lote com extensão “-env-lot.xml”;
• Recibo: O nome do arquivo será o número do lote com extensão “-rec.xml”;
• Pedido do Resultado do Processamento do Lote de NF-e: O nome do arquivo será o número do recibo com extensão “-ped-rec.xml”;
• Resultado do Processamento do Lote de NF-e: O nome do arquivo será o número do recibo com extensão “-pro-rec.xml”;
• Denegação de Uso: O nome do arquivo será a chave de acesso completa com extensão “-den.xml”;
• Pedido de Cancelamento de NF-e: O nome do arquivo será a chave de acesso completa com extensão “-ped-can.xml”;
• Cancelamento de NF-e: O nome do arquivo será a chave de acesso completa com extensão “-can.xml”;
• Pedido de Inutilização de Numeração: O nome do arquivo será composto por: UF + Ano de inutilização + CNPJ do emitente + Modelo + Série + Número Inicial + Número Final com extensão “-ped-inu.xml”;
• Inutilização de Numeração: O nome do arquivo será composto por: Ano de inutilização + CNPJ do emitente + Modelo + Série + Número Inicial + Número Final com extensão “-inu.xml”;
• Pedido de Consulta Situação Atual da NF-e: O nome do arquivo será a chave de acesso completa com extensão “-ped-sit.xml”;
• Situação Atual da NF-e: O nome do arquivo será a chave de acesso completa com extensão “-sit.xml”;
• Pedido de Consulta do Status do Serviço: O nome do arquivo será: “AAAAMMDDTHHMMSS” do momento da consulta com extensão “-ped-sta.xml”;
• Status do Serviço: O nome do arquivo será: “AAAAMMDDTHHMMSS” do momento da consulta com extensão “-sta.xml”;

Resumo dos padrões técnicos

Nesse momento, podemos reproduzir a tabela que traz o resumo dos padrões técnicos adotados pelo Projeto NF-E.

Processo de autorização

Abaixo segue uma imagem que mostra como funciona o processo de envio e autorização das Notas Fiscais Eletrônicas:

Cadeia de certificados

Para que o emissor consiga se comunicar com os Web Services disponíveis, será necessário instalar a cadeia de certificados. A maneira mais rápida é instalar a cadeia completa de certificados das ACs do ICP-Brasil que pode ser obtida no repositório da AC Raiz. No entanto, o emissor pode instalar apenas a cadeia de certificados necessária para acessar os Web Services da sua UF.

São 28 UFs. Algumas mantêm aplicação própria, outras utilizam a SEFAZ Virtual do RS ou o SVAN (SEFAZ Virtual do Ambiente Nacional). Consulte a SEFAZ do seu Estado e verifique como funciona o seu ambiente.

Os Web Services utilizam certificados digitais das seguintes cadeias de certificados da hierarquia ICP-Brasil:

• AC CertiSign Múltipla V3;
• AC PRODEMGE;
• AC SERASA SRF;
• AC SERPRO Final v1;
• AC SERPRO SRF v1.

É possível que uma UF não utilize certificados digitais da hierarquia do ICP-Brasil. Consulte a SEFAZ do seu Estado para saber qual a cadeia de certificados utilizada.

Instalando uma cadeia de certificados no Windows

Veja como é simples instalar uma cadeia de certificados. Observe na imagem abaixo as cadeias de certificados que mencionamos anteriormente e algumas outras:

Vamos instalar a cadeia da AC SERASA SRF:

Você receberá uma mensagem informando que o certificado foi instalado com sucesso: “A importação obteve êxito”. Para visualizar o certificado instalado no Internet Explorer faça o seguinte:

Clique em Ferramentas / Opções de Internet — aba Conteúdo. Clique no botão Certificados. Na janela que abrir clique na aba “Autoridades de certificação intermediárias”.

Clique no botão “Exibir”. Serão mostradas as informações básicas do certificado digital.

Na aba “Caminho de certificação” você poderá verificar a hierarquia do certificado.

Ambiente de Homologação e Ambiente de Produção

As Secretarias de Fazenda Estaduais deverão manter dois ambientes para recepção de NFe: homologação e produção.

O ambiente de homologação é específico para a realização de testes e integração das aplicações do contribuinte durante a fase de implementação e adaptação do seu sistema de emissão de NF-e.

A autorização para emissão de NF-e no ambiente de produção fica condicionada à prévia aprovação das equipes de TI e de negócios da SEFAZ, que deverá avaliar a adaptação, comportamento e performance do sistema de emissão de NF-e do contribuinte no ambiente de homologação.

Credenciamento

O credenciamento é um procedimento formal, onde o contribuinte interessado solicita a autorização para emissão de NF-e.

Cada UF tem um modelo de credenciamento, que pode ter maior ou menor acompanhamento e avaliação da capacidade de emissão de NF-e do contribuinte interessado. Por esta razão consulte a SEFAZ do seu Estado para saber como proceder em relação ao credenciamento.

Ao solicitar o credenciamento, o contribuinte passa a ter acesso ao ambiente de homologação onde é possível realizar todos os testes necessários.

Após a realização dos testes o contribuinte também deverá realizar o credenciamento no ambiente de produção.

Endereços dos Web Services

Consulte o site da SEFAZ do seu Estado para verificar os endereços dos Web Services de homologação e de produção.

Digamos que o seu Estado utilize o ambiente da SEFAZ Virtual do RS. Neste caso os endereços de homologação são os seguintes:

Para ter acesso ao WSDL de cada um dos serviços, basta inserir o seguinte texto na frente do endereço: “?WSDL”. Assim, para acessar o WSDL do serviço Consulta Status você deve utilizar a seguinte URL:

https://homologacao.nfe.sefazvirtual.rs.gov.br/ ws/nfestatusservico/NfeStatusServico.asmx?WSDL

SEFAZ Virtual

Algumas Secretarias de Fazenda ainda não tem ambiente próprio e utilizam a Sefaz Virtual do Ambiente Nacional (SVAN) ou a Sefaz Virtual do Rio Grande do Sul (SVRS).

Nestes casos o modelo operacional é o seguinte:

Todas as requisições passam primeiro pelos servidores da SEFAZ Virtual, que se encarrega de repassar os dados para a SEFAZ de origem e destino e para a SUFRAMA.

Referências Bibliográficas

Instituto Nacional de Tecnologia da Informação
http://www.iti.gov.br

NF-eletrônica nacional
http://nf-eletronica.com/blog/

Portal da Nota Fiscal Eletrônica
http://www.nfe.fazenda.gov.br/portal

SEFAZ Acre
http://www.sefaz.ac.gov.br

SEFAZ Alagoas
http://www.sefaz.al.gov.br

SEFAZ Amapá
http://www.sefaz.ap.gov.br

SEFAZ Amazonas
http://www.sefaz.am.gov.br

SEFAZ Bahia
http://www.sefaz.ba.gov.br

SEFAZ Ceará
http://www.ceara.gov.br

SEFAZ Distrito Federal
http://www.fazenda.df.gov.br

SEFAZ Espírito Santo
http://www.sefaz.es.gov.br

SEFAZ Goiás
http://nfe.sefaz.go.gov.br

SEFAZ Maranhão
http://www.sefaz.ma.gov.br

SEFAZ Mato Grosso
http://www.sefaz.mt.gov.br

SEFAZ Mato Grosso do Sul

http://www1.nfe.ms.gov.br

SEFAZ Minas Gerais
http://portalnfe.fazenda.mg.gov.br

SEFAZ Pará
http://www.sefa.pa.gov.br

SEFAZ Paraíba
http://www.receita.pb.gov.br

SEFAZ Paraná
http://www.fazenda.pr.gov.br

SEFAZ Pernambuco
http://www.sefaz.pe.gov.br

SEFAZ Piauí
http://www.sefaz.pi.gov.br

SEFAZ Rio de Janeiro
http://www.fazenda.rj.gov.br

SEFAZ Rio Grande do Norte
http://www.set.rn.gov.br

SEFAZ Rio Grande do Sul
http://www.sefaz.rs.gov.br

SEFAZ Rondônia
http://www.portal.sefin.ro.gov.br/site/

SEFAZ Roraima
http://www.sefaz.rr.gov.br

SEFAZ Santa Catarina
http://nfe.sef.sc.gov.br

SEFAZ São Paulo
http://www.fazenda.sp.gov.br/nfe

SEFAZ Sergipe
http://nfe.sefaz.se.gov.br

SEFAZ Tocantins
http://www.sefaz.to.gov.br

SPED — Sistema Público de Escrituração Digital
http://www1.receita.fazenda.gov.br

WEBSERVICES.ORG
http://www.webservices.org/

Wikipedia, a enciclopédia livre
http://en.wikipedia.org/ | http://pt.wikipedia.org/

T2Ti ERP — Aprenda a Desenvolver um ERP

O T2Ti ERP 2.0 é feito em C#, Delphi, Java (RIA e Web) e Lazarus. São cinco projetos diferentes. Que tal aprender a desenvolver esse ERP totalmente grátis? Parece bom?

Acompanhe o canal da T2Ti no Youtube. A T2Ti está postando todos os vídeos do T2Ti ERP 2.0 no Youtube. São quase 300 módulos!

Os vídeos estão organizados em Playlists. Então se inscreva no canal e ative o sininho para receber atualizações sobre as postagens.