Pré-Requisitos


Para desenvolver uma nova integração com a TecnoSpeed, o pacote básico dos componentes deverão ser instalados. A versão que o mesmo foi homologado foi a versão v8.7.52.1487 e está disponível em \\192.168.111.11\Suporte\Integradores\NFS-e por Integrador\TecnoSpeed\setup_nfse_cnpj.8.7.52.1487.exe


Não é necessário realizar a instalação dos componentes para Delphi.


Ao carregar qualquer projeto de demonstração da TecnoSpeed para testes, os mesmos deverão ser compilados para x86 (Target CPU). Da mesma forma no Pool de Aplicativos do IIS, referente ao projeto MOVERE NF-e, deverá ter a opção [Habilitar Aplicativos de 32 Bits] marcada como True;


O usuário do Pool de Aplicativos deverá ter direito de acesso no Windows, na pasta de instalação da ferramenta da TecnoSpeed;



TecnoSpeed


A TecnoSpeed é um conjunto de ferramentas que padroniza, através de um layout chamado TX2, o processo de envio, porém, eles não fazem tudo, o que significa que temos que fazer tudo o que já fazíamos para as prefeituras, mas, utilizando suas ferramentas.


Na visão do MOVERE, a biblioteca deles foi implementada como uma nova prefeitura.



Configuração


Para que seja possível fazer o envio, o município deverá utilizar na rotina [R53 - Manutenção de Cidades] o integrador [28 - TecnoSpeed];



Fluxo geral da NF-e


O fluxo de todas as integrações segue da seguinte forma, a partir do MOVERE no momento da geração de uma nota fiscal eletrônica qualquer:


  • Gerar Chave de Acesso
  • Validar XML
  • Assinar XML
  • Criar um novo lote para transmissão
  • Adicionar chave de acesso ao lote
  • Fechar lote
  • Agendar a transmissão na tabela t0550


Todas estas requisições são feitas sempre no WebService [NFSeRecepcionarLoteRps.asmx] para serviço ou [NFeRecepcao2.asmx/NFeAutorizacao.asmx] para mercadoria. Todas estas requisições são feitas pela rotina R419 antes de exibir a mensagem de nota fiscal gerada com sucesso!


Para realizar a transmissão, é utilizado o projeto Agente de Tarefas e o mesmo deverá estar ativo, configurado para acessar tanto o banco do MOVERE quanto o banco do projeto NF-e, assim como, ter acesso a URL principal do MOVERE que está realizando a emissão das notas fiscais.


O Agente de tarefas fará o seguinte fluxo para realização da transmissão de qualquer integrador:


  • Consultar a situação do lote N vezes, até que o mesmo retorne como processado (NFSeConsultarSituacaoLoteRps.asmx/NFeRetRecepcao2.asmx/NFeRetAutorizacao.asmx);
  • Consultar o lote para baixar o XML da NFS-e (NFSeConsultarLoteRps.asmx);
  • Envia pedido de impressão [Navega na rotina R419 solicitando a impressão]
  • Envia o e-mail [Navega na rotina R419 solicitando o envio do e-mail, de acordo com as configurações do Agente]


Para as notas fiscais enviadas para a SEFAZ, as funções (NFeRetRecepcao2.asmx/NFeRetAutorizacao.asmx) já retornam o protocolo e demais dados de autorização da NF-e, não sendo necessário realizar uma nova consulta.


Para as notas fiscais enviadas para os municípios, existe a situação da transmissão Síncrona/Assíncrona, que determina se existirá uma consulta a mais para baixar a NFS-e.



Fluxo NF-e para TecnoSpeed


O MOVERE faz a geração do arquivo TX2 com todas as informações da nota fiscal eletrônica e envia ao projeto NF-e que, na validação, salva o arquivo TX2 na pasta [NF-e\Backup\TecnoSpeed\NFSe\EmpX\EstabY\].


No processo de assinatura do XML, o projeto NF-e envia apenas o endereço do arquivo TX2 para a ferramenta da TecnoSpeed, que retorna o XML assinado conforme as informações da prefeitura. Este XML é salvo conforme o fluxo padrão do projeto NF-e.


O projeto de Agente de Tarefas passa a fazer uma consulta adicional, antes de realizar a transmissão de todas as NFS-es, para identificar se aquela nota deverá ser transmitida de forma síncrona/assíncrona. Esta consulta é feita diretamente no projeto NFSeTools.asmx;



Layout TX2


Este arquivo TXT é gerado pelo MOVERE através da classe [Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.GeradorTx2], que se encontra no projeto Core.



Estrutura do Arquivo


O arquivo TX2 possui dois grupos, uma espécie de região de variáveis, onde, dentro de cada grupo, deverão ser especificadas as variáveis necessárias para transmissão e geração do RPS, sempre no formato campo=valor.


Não foi especificado se estas variáveis são Case Sensitive, no entanto, seguimos os padrões determinados no arquivo [ \\192.168.111.11\Suporte\Integradores\NFS-e por Integrador\TecnoSpeed\Manual Padrão Tx2 unificado.pdf].


Não foi especificado também se existe uma ordem de declaração das variáveis.


O arquivo TX2 segue o seguinte formato:


formato=tx2
padrão=TecnoNFSe
INCLUIR
campo1=valor1
campo2=valor2
campoN=valorN
SALVAR

INCLUIRRPS
campo1=valor1
campo2=valor2
campoN=valorN
SALVARRPS



Classes para Geração do TX2


As classes que geram o arquivo TX2 foram divididas conforme o agrupamento de informações do projeto ABRASF, elas fazem exclusivamente o preenchimento de um StringBuilder com todas as informações que a TecnoSpeed necessita.


Estas classes, seguem a seguinte hierarquia:


Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.GeradorTx2

> Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.Tx2.GrupoEmitente

> Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.Tx2.GrupoRps

>>> Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.Tx2.Nota

>>> Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.Tx2.Emitente

>>> Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.Tx2.Servicos

>>> Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.Tx2.Prestador

>>> Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.Tx2.Tomador

>>>>>> Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.Tx2.TomadorCadastrado ou

>>>>>> Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.Tx2.TomadorNaoCadastrado


A classe [Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.ArquivoTx2] é responsável apenas por padronizar a escrita no arquivo TX2.


A classe [Cbanet.Server.Core.Sistemas.Faturamento.NFSe.TecnoSpeed.GeradorArquivo] é responsável por criar um arquivo XML padronizado, permitindo a utilização do fluxo de emissão de notas já existente, mesmo porque, é neste XML que é gerado as informações de impressão RPS.


O XML gerado deve estar com a seguinte estrutura:


<doc>
   <rps>numero</rps>
   <serie>numero</serie>
   <chave>numero</chave>
   <tx2>conteudo-arquivo-TX2</tx2>
   <imp>documento-de-impressao-padronizado</imp>
</doc>



Desenvolvendo um Novo Município


Para implementar a integração com novos municípios, deve-se configurar normalmente as TAGs de certificado/estabelecimento do Web.Config do projeto NF-e, com uma exceção, o atributo Prefeitura deve estar no formato CIDADEUF, não necessitando existir as configurações de URL da mesma.



Passos


Deve-se ser seguido os seguintes passos para criação de um município 100% personalizado:


  • Configurar o município na rotina de cidades (R53) para o integrador TecnoSpeed;
  • Configurar um estabelecimento para o município em questão (R288);
  • Configurar uma série eletrônica de serviço para o estabelecimento (R78);
  • Obter informações do cliente, como: Certificado, CNPJ, Inscrição Municipal, Inscrição Estadual;
  • Obter informações sobre ambiente de produção/homologação no município, se existe a possibilidade de emitir notas em ambiente de homologação enquanto o nosso cliente emite nota pelo site ou por outro software;
  • Configurar o certifidado/estabelecimento no arquivo Web.Config do projeto NF-e;
  • Fazer testes de uso do certificado, como por exemplo, verificar a disponibilidade dos serviços de NF-e da SEFAZ (R648);
  • Fazer a liberação do CNPJ juntamente ao site da TecnoSpeed, conforme link disponível abaixo. Esta passo é necessário para utilização das DLLs mesmo no ambiente de homologação;
  • Criar uma pasta para a UF no projeto NF-e Core, caso não exista, em: Cbanet.NFe.Core\TecnoSpeed\Personalizacoes\UF;
  • Criar uma classe com o nome do município, sem a UF e sem acento, utilizando PascalCase, conforme os demais padrões permitidos pelo C#, no seguinte Namespace: Cbanet.NFe.Core.TecnoSpeed.Personalizacoes.UF.NomeMunicipio;
  • A classe do município deverá herdar a classe MunicipioPadrao;
  • Esta classe, deverá ter o atributo [Municipio("CIDADEUF")] configurado para o padrão exigido pela TecnoSpeed;
  • Deve ser definido nesta classe se a transmissão será Síncrona/Assíncrona;
  • A classe do município poderá implementar as seguintes interfaces: IPersonalizaParametrosDoEstabelecimento. Quando a transmissão para o município for assíncrona, deverá, obrigatoriamente, implementar também a interface IConsultaSituacaoLoteRps;
  • A classe do município tem disponível para ser sobrescrita, as seguintes funções: GerarChaveDeAcessoParaCancelamento, ConsultarProtocoloCancelamento e StatusMotivoIndicaNotaFiscalEmDuplicidade.;
  • Realizar vendas de serviços para o estabelecimento/série configurados;
  • Faturar pela rotina R419 ou R657;
  • Testar o fluxo de duplicidade de emissão de notas fiscais;
  • Testar o processo de emissão para clientes com substituição tributária de ISS, pois, alguns municípios possuem particularidades. O MOVERE preenche o campo [InscricaoMunicipalTomador] apenas se o mesmo é substituto de ISS, enviando exatamente da forma que está cadastrado na rotina [R43 - Clientes].



Desenvolvimento de um município genérico


Foram desenvolvidas 3 classes para gerenciamento dos municípios genéricos, o objetivo é permitir que novos municípios sejam integrados sem que haja a necessidade de desenvolvimento, apenas com a configuração das personalizações. As classes são:

  • MunicipioGenerico
  • MunicipioSincronoGenerico
  • MunicipioAssincronoGenerico


Todos eles possuem um objeto [DadosMunicipioTecnoSpeed] que possui propriedades que devem ser tratadas sempre no formato de fazer ou não algo, de forma que o desenvolvimento de novos recursos não impacte os municípios já configurados.


Para seu uso, o arquivo Web.Config deverá compor novas TAGs, favor verificar esta base de conhecimento.


Ao configurar novos municípios, os mesmos deverão ser relacionados nesta base de conhecimento e sua configuração deverá ser indicada nesta base de conhecimento.


Para o desenvolvimento de novas opções, estas deverão ser criadas na classe [DadosMunicipioTecnoSpeed] e carregadas do arquivo Web.Config na classe [ConfiguracaoTecnoSpeed], sempre utilizando o mesmo nome. Da mesma forma, documentar o uso da configuração nesta base de conhecimento.



Classe MunicipioPadrao


Esta classe permite a personalização dos parâmetros das principais funções do componente da TecnoSpeed. Todos estes parâmetros estão configurados como vazios e o padrão de transmissão é Síncrono.


Caso seja necessário realizar o envio de algum parâmetro, a propriedade relacionada ao mesmo deverá ser sobrescrita.



Interface IPersonalizaSerieNfse


Apenas para os municípios de transmissão síncrona, esta interface permite modificar o número da série antes de gerar o XML da RPS;



Interface IPersonalizaParametrosDoEstabelecimento


A implementação desta interface é opcional, quando feita, permite o município configurar os dados dos parâmetros extras, ou, carregar informações que serão utilizadas nas funções sobrescritas.


É passada para a execução da função Personalizar os dados do estabelecimento, referente aquela requisição.



Interface IPersonalizaArquivoTX2


Utilizada apenas como herança das interfaces de personalização do arquivo TX2.



Interface IPersonalizaArquivoTX2Cabecalho


A implementação desta interface é opcional, quando feita, permite o município configurar as variáveis que são enviadas no cabecalho do arquivo TX2, ou seja, antes dos grupos INCLUIR e INCLUIRRPS.


É passado para a execução do método PersonalizarCabecalho um dicionário com as variáveis atuais, estas, poderão ser modificadas, excluídas ou novas variáveis acrescentadas.



Interface IPersonalizaArquivoTX2GrupoEmitente


A implementação desta interface é opcional, quando feita, permite o município configurar as variáveis que são enviadas no grupo do emitente do arquivo TX2, ou seja, depois das variáveis de cabeçalho, dentro do grupo INCLUIR, imediatamente antes do grupo INCLUIRRPS.


É passado para a execução do método PersonalizarGrupoEmitente um dicionário com as variáveis atuais, estas, poderão ser modificadas, excluídas ou novas variáveis acrescentadas.



Interface IPersonalizaArquivoTX2GrupoRps


A implementação desta interface é opcional, quando feita, permite o município configurar as variáveis que são enviadas no grupo do RPS do arquivo TX2, ou seja, depois do cabeçalho e do grupo INCLUIR, personalizando o conteúdo do grupo INCLUIRRPS.


É passado para a execução do método PersonalizarGrupoRps um dicionário com as variáveis atuais, estas, poderão ser modificadas, excluídas ou novas variáveis acrescentadas.



Interface IPersonalizaArquivoTX2GrupoServicos


A implementação desta interface é opcional, quando feita, permite o município configurar as variáveis que são enviadas no grupo do RPS do arquivo TX2, ou seja, depois do cabeçalho e do grupo INCLUIR. Será personalizando, dentro do grupo INCLUIRRPS, um novo grupo chamado INCLUIRSERVICO. Para cada item da nota, será criado um grupo INCLUIRSERVICO.  


É passado para a execução do método PersonalizarGrupoServicos um dicionário com as variáveis atuais, estas, poderão ser modificadas, excluídas ou novas variáveis acrescentadas.



Interface IPersonalizaArquivoXML


A implementação desta interface é opcional, quando feita, permite o município configurar o documento XML convertido a partir do arquivo TX2, imediatamente antes do processo de assinatura, assim, qualquer modificação feita no documento será assinado e transmitido para o município.


É passado para a execução do método PersonalizarXml um documento do tipo XmlDocument com o documento atual, onde o mesmo pode ser totalmente modificado.



Interface IConsultaSituacaoLoteRps


A implementação desta interface é obrigatória para os municípios que fazem transmissão assíncrona, pois, o componente não possui uma via padronizada para a leitura da situação do lote.


A função existente nesta interface é responsável por gerar um retorno padronizado, que deve ser gerado pelo mesmo Gerador (GeradorDeSituacaoDoLoteDeRps) que é passado como parâmetro.


O objetivo é identificar a situação do lote e executar a função GerarRetornoDaConsultaDaSituacaoDeRps caso o município retorne uma mensagem clara com os erros da NFS-e quando esta não é autorizada, ou, executar a função GerarRetornoDaConsultaDaSituacaoDeRpsComConsultaDaMensagemDeErro quando o sistema deve realizar uma consulta adicional no município (NFSeConsultaLoteRps.asmx) quando os erros não são disponibilizados diretamente no retorno da situação.



Interface IPersonalizaParametrosDaConsultaNFSePorRps


A implementação desta interface é opcional, permite a personalização dos parâmetros extras que são enviados ao realizar a consulta da NFS-e por RPS.


Ela passa a utilizar apenas um método com as informações do RPS, lote e a nota fiscal envolvida, ao preencher o parâmetro [parametros], estes serão enviados como um parâmetro extra.



Interface IConsultaNFSePorRpsPersonalizada


A implementação desta interface é obrigatória quando, a TecnoSpeed não desenvolver a consulta de NFS-e por Rps, porém, o município possuir a consulta em questão.


Esta interface herda a interface IPersonalizaParametrosDaconsultaNFSePorRps, assim, não é necessário realizar a declaração da mesma no município.


Para que a mesma seja aceita pelo núcleo, é obrigatório o preenchimento da propriedade [NomeComandoConsultaNFSePorRps], assim, se o município implementar essa interface e esta propriedade retornar nulo ou vazio, a mesma será desconsiderada.


Quando o caso ocorrer, o sistema faz a consulta utilizando a própria ferramenta da TecnoSpeed, porém, utilizando a função de envio de comandos personalizados. A lista de comandos pode ser obtida pela própria ferramenta de testes da TecnoSpeed.



Ao implementar a interface, o personalizador de municípios deverá informar o nome do comando de consulta de NFS-e por Rps de acordo com o município em questão, assim como, os parâmetro necessários para consulta.



Método virtual GerarChaveDeAcessoParaCancelamento


Por padrão, o processo de cancelamento utiliza apenas o número da nota fiscal eletrônica.


Este método deve ser sobrescrito quando, para cancelar uma NFS-e no município, o componente da TecnoSpeed utiliza uma concatenação diferente para o campo Chave de Cancelamento.


A lista completa dos campos que devem ser concatenados está disponível no aplicativo de demonstração OCX da TecnoPoint, basta solicitar o cancelamento que será aberta uma janela solicitando a chave, ao clicar no checkbox [Mostrar Tabela de Chaves], o sistema irá exibir uma lista dos campos necessários para formatação da chave de cancelamento.


O objetivo é gerar a chave de cancelamento completa, quando a mesma for diferente do número da NFS-e.



Interface IPersonalizaParametrosDeCancelamento


A implementação desta interface é opcional, permite a personalização dos parâmetros extras que são enviados ao realizar o cancelamento da NFS-e.


Ela utiliza apenas um método com as informações da nota fiscal envolvida e justificativa, ao preencher o parâmetro [parametros], estes serão enviados como um parâmetro extra.



Interface IPersonalizaAutorizacoesDoEnvioSincrono


A implementação desta interface é opcional, permite realizar outras consultas para finalização do processo de autorização, que consiste em gerar o objeto RetornoRetRecepcao para envio ao agente de tarefas.



Interface IPersonalizaConversaoNFSeEmRetornoDeRecepcao


A implementação desta interface é opcional, permite centralizar o processo de conversão do XML, oficial da NFS-e já consultado, gerando o objeto RetornoRetRecepcao para envio ao agente de tarefas.


Interface IPersonalizaConversaoNFSeEmRetornoDeRecepcaoAssincrono


A implementação desta interface é opcional, permite centralizar o processo de conversão do XML, oficial da NFS-e já consultado, gerando o objeto RetornoRetRecepcao para envio ao agente de tarefas, quando se trabalha com município Assíncrono e ao realizar a consulta da situação do lote, a prefeitura devolve a nota e não a resposta do processamento do lote.


Interface IPersonalizaReciboProtocoloAposTransmissaoAssincrona

Esta interface permite modificar o recibo/protocolo após uma transmissão assíncrona. Foi necessário criar esta personalização no caso da integração com a cidade SERRA/ES onde eles utilizam o padrão SIL e retornam um XML como protocolo.


Interface IPersonalizaReciboOuProtocoloParaConsultaDeLoteRps

Esta interface permite modificar o recibo/protocolo antes da consulta do lote de RPS. Foi necessário criar esta personalização no caso da integração com a cidade SERRA/ES onde eles utilizam o padrão SIL e retornam um XML como protocolo. E este XML deve ser enviado na consulta do lote de RPS.


Interface IFixaRetornoConsultaSituacaoLoteRps

Esta interface permite fixar o retorno da consulta da situação de um lote de RPS. Foi necessário criar esta personalização no caso da integração com a cidade SERRA/ES onde eles utilizam o padrão SIL e nesta integração não existe consulta da situação do lote, apenas a consulta do RPS.


Método virtual ConsultarProtocoloCancelamento


Grande parte do processo de cancelamento das NFS-e dos municípios não possuem um protocolo de cancelamento, igual ao existente no projeto da SEFAZ, assim, quando a classe do município sobrescrever este método, o mesmo terá a possibilidade de leitura correta do protocolo de cancelamento.


O objetivo é identificar e retornar o código do protocolo de cancelamento, de acordo com cada município.



Método virtual StatusMotivoIndicaNotaFiscalEmDuplicidade


Um teste que deve ser feito durante o processo de homologação, é a situação de notas fiscais em duplicidade, pois, ela pode acontecer nos seguintes casos:


  • Erro de comunicação entre a prefeitura e o projeto NF-e. Por algum motivo, inexplicável, a prefeitura recebe e a autorização não chega ao projeto NF-e;
  • Erro entre a recepção da autorização e a gravação do mesmo. Nem tudo são flores, as vezes, erro de Lock de Banco ou alguma situação não tratada, o sistema não sabe que a autorização já veio!;



Método CorrigirTodosOsParametrosExtras


Este método foi criado para corrigir todos os parâmetros extras, assim, caso haja a necessidade de criação de um novo parâmetro extra, este método deverá ser atualizado.


Como simular as duplicidades?


Basta autorizar uma nota e remover a autorização! No banco do MOVERE, na tabela t0122, basta mudar o campo f0122statusautorizacaonfe para zero. No banco do projeto NF-e, exclua a chave de acesso na tabela notasfiscais e a dependência com a tabela conteudolote. Acesse a rotina R648 e solicite a retransmissão.


Pode ocorrer de algumas prefeituras solicitar a hora de transmissão, se isso ocorrer, a rotina R648 irá gerar um novo TX2 e ocorrerá de a assinatura ser diferente. No projeto NF-e da SEFAZ, ele faz a validação do DigestValue ou, dos dados principais da nota como: cliente, data, número/série da nota e valor.


O objetivo é simples, quando o projeto NF-e indicar um status de duplicidade, o projeto Agente de Tarefas irá fazer a análise do restante das informações para saber se é o mesmo documento, se for, ele ignora o erro de duplicidade e dá por autorizado, absorvendo as informações de autorização.



Links


Segue abaixo os links disponíveis para consulta sobre mais informações sobre o componente.