Responsável Técnico para NFe e NFCe

39
Novos-campos-Responsavel-Tecnico Tempo de leitura: 4 minutos

A Nota Técnica 2018.005, publicada no início de Janeiro de 2019, trouxe muitas mudanças para NFe e NFCe. Dentre eles, está a apresentação do novo conceito chamado Responsável Técnico.

As alterações devem entrar em ambiente de homologação até dia 25 de Fevereiro. O ambiente de produção está previsto para 29 de abril de 2019.

+ Leia mais: Local de retirada e entrega na NFe 4.0

Quem afinal é o Responsável Técnico?

De acordo com a Nota Técnica, a Sefaz considera como Responsável Técnico as empresas que são:

    • Desenvolvedora do sistema de emissão; ou
  • Empresa responsável tecnicamente pelo sistema de emissão.

A identificação do responsável foi incluída principalmente para responsabilizar o uso indevido do ambiente de autorização. Além disso, com a informação do documento é possível o eventual contato das Secretarias com os responsáveis técnicos (e futuras sanções).

Sistema ERP vs. Software de Mensageria

No mercado atual, no entanto, existem cenários onde não existem apenas um responsável técnico. Um exemplo é quando uma empresa possui uma solução de faturamento e utiliza uma solução de mensageria de outra empresa para comunicação com a SEFAZ.

O primeiro seria um sistema de faturamento responsável por integrar dados e processos e automatizar as informações do negócio. Dentre suas atividades podemos listar: controlar estoques, gerenciamento de pedidos e tratar vendas. Normalmente, esse sistema é chamado de ERP (Enterprise Resource Planning) ou Sistema integrado de gestão empresarial.

O segundo seria um software de mensageria responsável por gerenciar a comunicação entre o sistema de faturamento e a Secretaria da Fazenda. Dentre suas atividades está formatar os dados fornecidos no layout solicitado, assinar o arquivo comprovando a autoria da emissão, enviar e tratar o retorno dos lotes emitidos a Sefaz. A Oobj é uma empresa que realiza a mensageria de diversos documentos fiscais, dentre eles a NFe e NFCe.

Ambos sistemas possuem responsabilidade técnica sobre o documento fiscal enviado, o primeiro sobre a qualidade dos dados enviados pelo contribuinte e o segundo pela transmissão dos dados aos sistemas autorizadores estaduais.

Ainda não ficou claro pela documentação da Sefaz qual seria o responsável técnico a ser informado no documento fiscal nesses casos.

Campos do Responsável Técnico

Foi criado um novo grupo opcional na NFe chamado Informações do Responsável Técnico pela emissão do DF-e (infRespTec). Nele existem os seguintes campos:

    • CNPJ da empresa responsável pelo sistema utilizado na emissão do documento fiscal eletrônico (CNPJ)
    • Nome da pessoa a ser contatada (xContato)
    • Email da empresa a ser contatada (email)
    • Telefone da empresa a ser contatada (fone)
    • Identificador do CSRT (idCSRT)
  • Hash do CSRT (hashCSRT)

Código de Segurança do Responsável Técnico (CSRT)

A critério da UF, para os estados que exigem o credenciamento de software emissor de DFe, poderá ser exigido também um código de segurança para a empresa desenvolvedora do software, denominado de Código de Segurança do Responsável Técnico – CSRT.

O CSRT será um código alfanumérico (de 16 a 36 bytes) de conhecimento apenas da Sefaz do emitente e da empresa responsável pelo sistema emissor de DFe. O conceito é bastante similar ao código CSC da NFCe.

Porém na NFe ou NFCe não deve ser preenchido o CSRT. A fim de garantir maior segurança no processo e autoria de emissão, foi incluído o campo Hash do CSRT (hashCSRT) que é gerado a partir da concatenação do CSRT da empresa com a chave de acesso do documento.

O fornecimento do CSRT será feito em página específica ou WebService da Sefaz estadual. Neste portal/API, o responsável técnico poderá solicitar, consulta ou revogar um CSRT. Por enquanto não foi divulgado nenhum portal estadual para cadastro do Responsável Técnico.

Poderão ser solicitados até 5 códigos CSRT válidos por estado. Para incluir outro, a empresa deverá revogar um anterior.

Como gerar o hash do CSRT?

O passo-a-passo para gerar o hashCSRT deve seguir o indicado a seguir:

  1. Concatenar o CSRT cadastrado na Sefaz com a chave de acesso do documento a ser emitido (NFe / NFCe)

         Exemplo:

     2. Aplicar o algoritmo SHA-1 sobre a concatenação e converter para base64. A string resultante terá 48 caracteres

         Exemplo:

gerar hash rt

   

  3. Preencher o campo hashCSRT com o resultado. Atenção! Poderão ser emitidos até 5 CSRT válidos com IDs diferentes. Guarde o hash gerado para CSRT de ID correspondente.

        Exemplo:

gerar hash rt

Responsável Técnico em outros modelos

O Conhecimento de Transporte (CTe) e o Manifesto de Carga (MDFe) já possuem campos para o Responsável Técnico desde as Notas Técnicas 2018.002 para os respectivos modelos. Os campos são exatamente os mesmos dos incluídos para NFe e NFCe.

+ Leia mais: MDFe e CTe com CPF a partir de Outubro de 2018

Novas Rejeições

Com os novos campos, foram adicionadas novas rejeições ao projeto. Seguem abaixo uma lista das regras de validação para o Responsável Técnico:

  • Rejeição 972: Obrigatória as informações do responsável técnico
  • Rejeição 973: CNPJ do responsável técnico inválido
  • Rejeição 974: CNPJ do responsável técnico diverge do cadastrado
  • Rejeição 975: Obrigatória a informação do identificador do CSRT e do Hash do CSRT
  • Rejeição 976: Identificador do CSRT não cadastrado na SEFAZ
  • Rejeição 977: Identificador do CSRT revogado
  • Rejeição 978: Hash do CSRT diverge do calculado

solucoes-oobj

39 Comentários

  1. Gostaria de saber se o responsavel técnico será obrigatório informar nas notas emitidas apartir de 29.04.2019 em ambiente de produção?

    • Olá, Ricardo
      Por enquanto não há obrigatoriedade prevista para os campos do Responsável Técnico.
      Porém, a partir do dia 29/04 eles poderão ser preenchidos nas NFe e NFCe de forma opcional.

  2. 3.1 Grupo F. Identificação do Local de Retirada
    Criados novos campos para complementação das informações de identificação do estabelecimento e do endereço do local de retirada:
    3.2 Grupo G. Identificação do Local de Entrega
    Criados novos campos para complementação das informações de identificação do estabelecimento e do endereço do local de entrega:

    Como para essa nova nota técnica está sendo incluído esses campos de local de retirada e local de entrega dentro do modelo da DANFE,
    Gostaria de saber se quando necessário informar esses locais, se podemos continuar informando no campo de Informações Adicionais da Nota, ou se passa a ser obrigatório a utilização desses campos específicos do grupo F e G.Pois não gostaria de alterar meu software , na condição do local de entrega ser diferente, pois a intenção é que continue sendo informado nos dados adicionais da nota , a não ser que seja uma obrigatoriedade do Sefaz.

    • A Nota Técnica 2018.005 traz a possibilidade de adicionar novos quadros no DANFE relacionados ao Expedidor e ao Recebedor, porém não obriga a informação dos mesmos. Da mesma forma que ainda não é obrigatório preencher os campos de retirada e entrega.
      Leia mais aqui: https://blog.oobj.com.br/local-de-retirada-nfe-4-0/

  3. Boa tarde,

    Onde me credencio para gerar o HASH do CSRT?

    • Boa tarde, Eliade
      Por enquanto não foi divulgado nenhum portal estadual para cadastro do Responsável Técnico.

  4. Preciso abrir as tags ID F01 no xml para identificação do local de Retirada e também local de entrega . Não localizei as notas sap para esta nova Nota Técnica 2018.005 versão 1.10 Fev 2019.

  5. Boa tarde!

    Acredito que ocorreu uma falha ao calcular os bytes do HASH SHA-1.

    A primeira inconsistencia se encontra no “Passo 2”, pois ao aplicar o algoritmo SHA-1 a qualquer string de texto o resultado é uma “matriz de 40 bytes” e não como indicado no documento: “string de 20 bytes hexadecimal”.

    Na documentação da NOTA TECNICA diz que temos que guardar o resultado do hash SHA-1, e converter o resultado para Base64 e o resultado será uma string de 28 caracteres, que também esta errado, seu converter para Base64 me retornar uma String “Njk2YmZhMmRlMTBjZTE3ZWFlZTNlYTgxMjM2Mzk4NjdjODJiOGEwYw==” no caso totalmente fora do esperado!

    Algo não esta batendo ou posso estar enganado!!!!

    • Olá Eberson.

      Quanto a primeira inconsistência, o exemplo foi atualizado na versão 1.20 da Nota Técnica, publicada dia 15/03/2019.
      Foram ajustados esses pequenos detalhes sobre o tamanho do resultado.

      Quanto ao segundo ponto, a aplicação do Base64 deve ser feita em cima dos binários do SHA-1, e não da representação em String.

      Se você desejar, posso lhe enviar por e-mail um snippet feito em Java com alguns testes unitários que garantem o funcionamento tal qual o exemplo presente na Nota Técnica da Sefaz.

  6. No seu exemplo quando diz que “aplica o SHA-1 e converte para Base64” o resultado da conversão não é um Base64 que esta sendo exibido, e sim apenas o resultado do SHA-1. O valor correto seria este, após a encriptação para o Base64…
    Njk2YmZhMmRlMTBjZTE3ZWFlZTNlYTgxMjM2Mzk4NjdjODJiOGEwYw==

  7. O hashCSRT gerado neste exemplo tem 40 caractres, porém na NT o campo de hashCSRT está dito que tem tamanho 28.
    Existe alguma diferença no calculo ou foi divulgado o campo com tamanho incorreto na NT?

    • Olá Karla.

      Sim, o tamanho divulgado inicialmente na NT estava incorreto.

      Foi publicada no Portal Nacional a NT 2018-005 v1.20, em 15/03/2019, com essas e outras correções.

  8. Bom dia.

    Pelo que vi o exemplo que consta no site é o mesmo do leiaute da SEFAZ.

    Realmente o texto que está no exemplo é somente até a encriptação SHA-1, mas não se trata de uma string e sim de um valor hexadecimal. A string seria algo do tipo “ikú-áá~®ãê#c˜gÈ+Š”, mas que não dá para ser copiada corretamente aqui por ter caracteres especiais não aceitos.

    Porém, ao converter para base 64 e disso para uma string eu tenho um valor de 28 posições, totalmente diferente dos demonstrados: aWv6LeEM4X6u4+qBI2OYZ8grigw=

    No meu caso:

    1 – setei uma variável do tipo clob com o texto G8063VRTNDMO886SFNK5LDUDEI24XJ22YIPO41180678393592000146558900000006041028190697 e apliquei o SHA-1 resultando no valor hexadecimal de 696bfa2de10ce17eaee3ea8123639867c82b8a0c

    2 – codifiquei o valor hexadecimal do primeiro passo para base 64 resultando em 615776364C65454D34583675342B714249324F595A3867726967773D

    3 – tornei o valor hexadecimal em string e obtive o texto aWv6LeEM4X6u4+qBI2OYZ8grigw=

    Pois no leiaute está descrito que o campo se trata de uma string de 28 posições:

    “Passo 3: Converter o resultado do passo anterior para Base64, resultando em uma string de 28 caracteres”

    Mas independente disso vejo que existe um problema, pois nem o próprio leiaute da SEFAZ traz um valor válido.

    Existe algum posicionamento quanto ao responsável técnico?

    Pois até agora não vi a disponibilização de sites para solicitar o cadastramento e consta que a implementação no ambiente de homologação seria até o dia 25/02/2019.

    E existe alguma correção quanto ao campo CSRT para que possamos ver qual o valor correto do exemplo dado por eles?

    • Bom dia, Alexandre

      Sobre a sua primeira pergunta: por enquanto não há obrigatoriedade prevista para os campos do Responsável Técnico.
      Porém, a partir do dia 29/04 eles poderão ser preenchidos nas NFe e NFCe de forma opcional. Trataremos sobre esse assunto com mais detalhes em um webinar dia 21/03: https://www.spedbrasil.com.br/atualizacoes-nfe/

  9. Revendo o meu algoritmo, vi que estava convertendo o valor para uma forma errada… No caso estava usando Java, e utilizei o sha1Hex(https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/digest/DigestUtils.html#sha1Hex-byte:A-) que retorna um Hexadecimal da conversão e na verdade eu queria apenas o byte da mesma… Quando troquei para o sha1 e apliquei o base64, ele me retornou um valor com 28 caracteres…

    Mas mesmo assim o output de exemplo esta errado, no caso o valor retornado após a conversão para base64 seria :
    aWv6LeEM4X6u4+qBI2OYZ8grigw=

  10. Ola, Boa tarde!

    Meu Nome é Tacilio e gostaria de saber se hoje tem algum estado que está disponibilizando o código do CSRT, estamos preparando nosso sistema para cadastrar essa informação.

    • Olá, Tacilio

      Por enquanto não há obrigatoriedade prevista para os campos do Responsável Técnico. Porém, a partir do dia 29/04 eles poderão ser preenchidos nas NFe e NFCe de forma opcional. Trataremos sobre esse assunto com mais detalhes em um webinar dia 21/03: https://www.spedbrasil.com.br/atualizacoes-nfe/

  11. Estou tentando emitir notas fiscais no ambiente de homologação onde o prazo era pra 25/02/2019 e já não consigo autorizar as notas fica dando erro 972 – obrigatoria informações do responsavel tecnico já tentei em 3 emissores diferentes e até agora uma soluçao

    • Olá, provavelmente os documentos que você está enviando estão sem os campos do Responsável Técnico (grupo infRespTec).
      Este grupo é opcional, porém alguns estados podem solicitar o preenchimento das informações básicas do Responsável Técnico (CNPJ, Nome, Email e Telefone)
      Trataremos sobre esse assunto com mais detalhes em um webinar dia 21/03: https://www.spedbrasil.com.br/atualizacoes-nfe/

  12. Bom dia…ao emitir as notas testes esta fando a rejeição 972 sobre o responsavel tecnico porem nao mostra onde é o campo e nao esta deixando transmitir

    • Os campos do Responsável Técnico estão no grupo infRespTec o último campo do grupo infNFe.
      Alguns estados já estão solicitando o preenchimento das informações básicas do Responsável Técnico (CNPJ, Nome, Email e Telefone)

  13. Existe uma relação dos Estados que estará exigindo as informações os campos do Responsável Técnico (grupo infRespTec)?

    • Por enquanto não há uma relação oficial sobre quais estados irão solicitar o preenchimento dos campos do Responsável Técnico.
      Porém os estados Pernambuco e Paraná já sinalizaram que irão validar esses campos.

  14. Bom dia, gostaria de mais informações a respeito desses códigos, como faremos para obte-los, é no site da SEFA?

    • Bom dia. Por enquanto apenas os dados básicos de identificação serão validados nos estados que exigirão o preenchimento do RT.

  15. Boa Tarde! Não consegui o retorno da base64.
    Retornou também “Njk2YmZhMm…”

    Alguém poderia me ajudar?

  16. Bom dia!

    Artigo bastante esclarecedor, me ajudou na compreensão de alguns pontos. Entretanto, tenho algumas dúvidas conforme abaixo:

    “CNPJ da empresa responsável pelo sistema utilizado na emissão do documento fiscal eletrônico (CNPJ)”

    1)No caso o Responsável Técnico, obrigatoriamente, terá que ser Pessoa Jurídica(PJ)? Poderá ser MEI?

    2) Para Programadores/Analistas Pessoa Física (PF) terá que constituir firma, abrir CNPJ?

    3) A Empresa que desenvolve seu próprio ERP, mas não é uma Softhouse, ela pode se constituir responsável técnico?

    Desde já agradeço atenção.

    • De acordo com a especificação dos campos do Responsável Técnico, a identificação obrigatoriamente terá que ser CNPJ (Pessoa Jurídica), não sendo possível ser um CPF (Pessoa Física). O contribuinte que fizer ele mesma a comunicação com a Sefaz, será também o Responsável Técnico pelos documentos enviados.

  17. Bom dia,

  18. Senhores, boa tarde.

    Em pesquisa as Legislações dos Estados, não são todos que estão exigindo o cadastro do responsável técnico, por exemplo SP, que não se manifestou sobre o tema.
    Alguém sabe dizer quais Estados, estão obrigando o cadastro do responsável técnico na plataforma da SEFAZ?

  19. Excelente.
    Este site está de parabéns pela clareza do assunto abordado.

    • Muito Obrigada, Giovani!

  20. Danilo Guimarães, pode me enviar o exemplo em java ?

    “Quanto ao segundo ponto, a aplicação do Base64 deve ser feita em cima dos binários do SHA-1, e não da representação em String.”

    (Se você desejar, posso lhe enviar por e-mail um snippet feito em Java com alguns testes unitários que garantem o funcionamento tal qual o exemplo presente na Nota Técnica da Sefaz.)

  21. Boa Tarde o xml de responável tecnico será enviado junto com os documentos

    • Os campos do Responsável Técnico ficam dentro do XML do documento que deve ser enviado.

  22. Consegui em PHP.

    Para quem esta fazendo em PHP e não esta conseguindo gerar o hash. ou esta gerando com tamanho errado.
    basta gerar o sha1 em binario, passando true no segundo parametro.

    segue o meu código para ajudar.

    $hash = base64_encode( sha1 ( $SCRT . $chnfe , true ) ) ;

    Espero ter ajudado.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *