FireMonkey e NFe 2.0 - Revista Clube Delphi 141 - Parte Final

Nos artigos anteriores deste mini-curso foram abordadas as diversas etapas para o início da emissão da NF-e. A primeira parte em suma, teve seu foco direcionado na elaboração da Nota Fiscal e das funções necessárias para gerar as informações, levando em consideração os requisitos da SEFAZ e a importação de um Schema baseado em XML (Extensible Markup Language) através do recurso XML Data Binding, no qual o Delphi gera uma Unit contendo as interfaces e métodos obtidos de acordo com o Schema definido. Na segunda parte foi abordada a utilização do certificado digital, iniciando uma introdução à CAPICOM, a biblioteca que permite a utilização de recursos de segurança em aplicações desenvolvidas em Delphi e outras ferramentas para o ambiente Windows, para assinar os documentos XML utilizando um certificado digital, bem como a MSXML, que é uma biblioteca que permite a utilização de DOM (Document Object Model), um recurso muito importante e que facilita a manipulação dos documentos no padrão XML, para auxiliar na validação da NF-e. É importante salientar que a obtenção do certificado digital privado por parte da empresa é uma obrigatoriedade para a emissão da NF-e, e que o mesmo possui um tempo de validade determinado devendo ser renovado assim que é expirado. Contudo, também não se deve esquecer que existe a necessidade da instalação dos certificados públicos que pertencem à cadeia de certificação da hierarquia ICP-Brasil, para serem utilizados em diversos momentos na aplicação de NF-e.

Outro fator que deve ser observado e acompanhado de perto pelos utilizadores e desenvolvedores das aplicações de NF-e são as atualizações que ocorrem tanto nos XML Schemas quanto nos certificados. Isto é importante pois quando as correções necessárias não são efetuadas, as aplicações de Nota Fiscal Eletrônica correm o risco de não conseguirem consumir os WebServices da Secretaria da Fazenda, impossibilitando a emissão da nota.

Após a Nota Fiscal ser concebida, assinada e validada, a mesma necessita ser enviada para um determinado WebService da Secretaria da Fazenda para que ela possa ser considerada válida. O WebService é um recurso padronizado que é disponibilizado em uma rede como a Internet, por uma determinada organização, com a finalidade de prover vários recursos através da Internet e esses mesmos podem ser gratuitos ou pagos.

O WebService é implementado para ser autossuficiente e receber as requisições, processar e efetuar suas eventuais respostas de maneira automática, possibilitando assim uma consulta praticamente instantânea sobre determinado serviço. Contudo, cada WebSevice possui seus próprios métodos e forma de funcionamento interno, sendo assim o desenvolvedor precisa conhecer suas funcionalidades para que o mesmo possa consumir seus recursos, por este motivo existe o WSDL (WebService Description Language), que é um documento baseado no padrão XML que descreve os recursos do WebService em questão, demonstrando seus métodos e funções.

Além dos softwares e ferramentas necessários para a elaboração e disponibilização, os WebServices também são baseados nos protocolos HTTP (HyperText Transfer Protocol) e SOAP (Simple Object Access Protocol). O HTTP é o protocolo padrão de transporte no cenário da Web e o SOAP é um protocolo baseado em XML padronizado, cuja finalidade é permitir que os serviços fornecidos pelos WebServices possam ser chamados e posteriormente seu retorno seja recebido, bem como apresentar os dados necessários para que este processo possa ser efetuado através das mensagens. Por ser um padrão estabelecido pela W3C e baseado simplesmente em texto, uma mensagem padrão em SOAP é compatível com os mais variados ambientes e ferramentas de desenvolvimento presentes no mercado, sendo que tal protocolo possui diversas versões. A versão do protocolo SOAP adotada pela SEFAZ para a NF-e 2.0 é a 1.2. Entretanto, muitos WebServices, como é o caso dos disponibilizados pela Secretaria da Fazenda, podem utilizar uma implementação de segurança para seu funcionamento, que normalmente é baseada em SSL (Secure Socket Layer) sobre o protocolo HTTP, que recebe a denominação de HTTPS (HyperText Transfer Protocol Secure). A utilização deste recurso permite que usuários sejam autenticados, bem como mantém a integridade das informações oferecendo privacidade, tendo apenas a desvantagem de ser um pouco mais lenta que a aplicação convencional baseada somente em HTTP.

Outro fator que merece destaque é com relação aos recursos envolvidos para que um WebService possa estar disponível, ou seja, o mesmo depende de outros Softwares, da Internet e consequentemente de Hardware, sendo assim não há como garantir que um WebService esteja sempre em funcionamento. Este é um dos motivos de existirem outras modalidades na Emissão da NF-e, que devem ser adotadas como contingência, tais como o SCAN (Sistema de Contingência do Ambiente Nacional) e o DPEC (Declaração Prévia de Emissão em Contingência).

Contudo, ao consumir os WebServices da SEFAZ, deve-se definir em qual ambiente o mesmo será executado, ou seja, se em homologação (testes) ou produção, uma vez que os endereços dos WebServices são diferentes. Todo o desenvolvimento deste projeto deve ser realizado no ambiente de homologação para evitar quaisquer problemas. Sendo assim, uma vez que tudo esteja operando satisfatoriamente no ambiente de homologação, basta substituir os endereços (URL – Uniform Resource Locator) dos WebServices deste ambiente para o ambiente de produção, dando início a validade das notas emitidas pela aplicação NF-e.

Etapas do processo de envio e autorização da NF-e em modo Normal

A Internet possibilita diversas alternativas para a troca de informações e o processo de Nota Fiscal Eletrônica é mais um recurso que utiliza esta base. Uma vez que a NF-e está concluída, o envio da mesma deve ser efetuado para o WebService da Receita. Um detalhe que deve ser observado é que o processo de envio e autorização da NF-e é constituído por algumas etapas. O desenvolvedor também pode elaborar a aplicação de NF-e para enviar várias notas de uma só vez, dentro de um mesmo lote.

O primeiro passo deste processo de envio e autorização de NF-e é transmitir a Nota Fiscal versão 2.0 para o WebService padrão de recepção da SEFAZ (NfeRecepcao2), lembrando que os certificados digitais (privado e público) são necessários em todas as fases deste processo para a autenticação. Após o consumo deste WebService é obtida uma mensagem de retorno SOAP contendo diversas informações no padrão XML, entretanto os dados relevantes estão presentes nas TAGs <xMotivo>, que deverá conter a mensagem “Lote recebido com sucesso” , e <nRec>, que armazena o número de recibo do lote. Evidentemente se houver algum erro durante todo este processo o retorno obtido será uma mensagem contendo informações sobre o mesmo. Contudo, quando este processo é concluído satisfatoriamente, significa que o WebService da receita recebeu a NF-e, porém ainda não implica que a mesma está autorizada para o uso. Por esse motivo convém à aplicação de NF-e armazenar o arquivo de retorno para que possa ser utilizado futuramente. Após alguns segundos, a aplicação cliente de NF-e pode efetuar o consumo de um segundo WebService da SEFAZ (NfeRetRecepcao2) para a consulta do status da NF-e transferida, enviando em conjunto com a mensagem de requisição SOAP, o número do recibo que foi obtido durante o processo de envio (<nRec>). Se a NF-e emitida está de acordo com os requisitos da SEFAZ, através da consulta deste WebService será possível obter um documento de retorno também sobre o padrão SOAP contendo diversas informações das quais se destacam as TAGs <xMotivo>, que apresenta a mensagem “Autorizado o uso da NF-e”, indicando que a NF-e foi aprovada, bem como a TAG <nProt>, que traz consigo o número do protocolo da mesma, evidentemente se houver algum imprevisto ou problema detectado na NF-e, a mensagem de retorno conterá as informações relacionadas a esta ocorrência. Efetuadas estas etapas com sucesso, o próximo passo é anexar as informações obtidas em um único documento XML (procNFe) constituído pela NF-e validada que foi enviada e as informações retornadas pela última consulta (infProt) para então prosseguir para o passo final do processo geral da NF-e que é a impressão da DANFE, o Documento Auxiliar da Nota Fiscal Eletrônica. Este deve ser utilizado para o transporte das mercadorias e futuras consultas, e o envio do documento XML para o destinatário da nota através de e-mail ou outro recurso, uma vez que este passo é obrigatório.

Envio da NF-e e resposta na prática

Após ter uma visão geral do processo de envio da NF-e, o próximo passo é a implementação do mesmo. Para tanto, basta abrir o mesmo projeto que foi utilizado nos artigos anteriores. Um ponto importante que deve ser evidenciado neste momento é que existem várias maneiras de efetuar todo este processo, e o caminho que será seguido vai depender da necessidade do projeto. Entre eles, o desenvolvedor pode efetuar o XML Data Binding no XML Schema consReciNFe_v2.00.xsd para extrair as interfaces e poder manipular diversas informações de retorno das notas utilizando um objeto TXMLDocument por exemplo, que representa um documento XML e oferece diversas funcionalidades. Também pode-se ser mais direto, manipulando as informações obtidas da mesma maneira como manipula uma String, fazendo uso das funções Pos() e StringReplace(), entre outros caminhos que podem ser utilizados. Para este projeto, foi efetuado o XML Data Binding (File>New>Other>XML>XML Data Binding) no Schema XML mencionado anteriormente (consReciNFe_v2.00.xsd) para uma melhor manipulação dos retornos obtidos pelas consultas e demonstrar uma maneira de utilizar o mesmo. Também foram criados alguns elementos, tais como um objeto do tipo THTTPReqResp, cujo objetivo é permitir o consumo de WebServices através do protocolo HTTP ou HTTPS, e uma mensagem no padrão SOAP diretamente em uma variável String, uma vez que o funcionamento do WebService seja conhecido.