Posso definir o ACBr como Responsável Técnico?

[EMBarbosa]

PERGUNTA: Eu uso o ACBr. Posso colocar o ACBr como Reponsável Técnico na emissão de algum documento fiscal eletrônico (ou DF-e, isto é, NF-e, NFC-e, CT-e, MDF-e, etc...) ?

Mesmo que você use o ACBrMonitor Plus, a ACBrLib, os componente ACBr, algum programa exemplo que disponibilizamos, a resposta simples é NÃO.

Não entenda mal. Reafirmamos nosso compromisso em ajudar os usuários do ACBr a resolver seus problemas no uso dos componentes, bibliotecas ou aplicativos que disponibilizamos na medida do possível. E claro, damos prioridades aos casos reportados por usuários que fazem uso do SAC ACBr.

Mas não somos o responsável técnico pelo seu sistema, mesmo que ele use qualquer ferramenta que provemos.

Talvez você queira entender um pouco mais, então vamos a uma resposta longa sobre isso. Vamos usar como exemplo a NF-e e NFC-e que são de longe os DF-es mais utilizados.

Se você ler a nota técnica 2018.005 da NF-e/NFC-e vai encontrar o item "2 Sobre a Identificação do Responsável Técnico". Nesse item há a seguinte frase no parágrafo que explica o que é essa informação (grifo é meu):

Citar

Responsável técnico é a empresa desenvolvedora ou a empresa responsável tecnicamente pelo sistema (software) de emissão de NF-e/NFC-e utilizado pelo contribuinte emitente.

Veja que a primeira frase menciona que o "responsável técnico" pode não ser simplesmente um desenvolvedor, mas a empresa responsável tecnicamente pelo sistema de emissão. O que neste caso é vocês. Vocês respondem perante seu cliente e perante as autoridades pela emissão do documento fiscal.

Os produtos do projeto ACBr (seja algum componente, o ACBrMonitor, ou uma ACBrLib) nesse processo é apenas uma ferramenta parte do seu software e não o sistema em si. Ou seja, é um framework/biblioteca/componente que ajuda seu sistema e sua empresa a emitir os documentos. Veja, não disponibilizamos sistemas para emissão, apenas ferramentas para ajudar na emissão.

Isso fica mais claro quando lemos o restante do parágrafo, porque ele explica não só o que é o "responsável técnico", mas também o objetivo dessa informação ser necessária. Veja:

Citar

Essa informação será utilizada pelas Administrações Tributárias, principalmente na identificação de uso indevido do ambiente de autorização, viabilizando eventual contato das SEFAZ com os responsáveis técnicos.

A ideia é a SEFAZ poder entrar em contato com o responsável pelo emissor em caso de dúvidas ou problemas na emissão.

Em caso de anomalias na emissão, com quem a SEFAZ teria que entrar em contato?

Por exemplo: Em uma das reuniões do ENCAT, um sistema tentou retransmitir uma nota com erros no XML, por 70.000 vezes... ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o XML que já sabia era rejeitado... Isso é praticamente um ataque de DDOS, nos servidores do SEFAZ...

Quem a SEFAZ teria que contatar se essa empresa fosse seu cliente?

É evidente que em caso de dúvidas ou problemas sobre o uso nas empresas que são seus clientes eles deverão entrar em contato com a sua empresa. Afinal de contas, nós não sabemos como seu sistema funciona, nem conhecemos os seus clientes.

Ainda mais, o ACBr, (quero dizer ACBrMonitor, ACBrLib, ou qualquer componente ou biblioteca que fornecemos), por si só nunca faz uso de um WebService. Qualquer WebService é acionado por sua aplicação. Ela, a sua aplicação, é responsável pela emissão.

Chamar o ACBr de responsável seria basicamente o mesmo que colocar como responsável a Microsoft porque você usa o Windows nos seus clientes, ou a biblioteca OpenSSL porque você a usa pra assinar os documentos.

Existe mais um detalhe, o item "2.1 Código de Segurança do Responsável Técnico - CSRT" que nos ajuda a entender.

Esse item fala do credenciamento do software emissor de DF-e na SEFAZ da UF e da empresa responsável. Se sua UF já tem esse cadastro, ou algum cadastro similar como era o caso do PAF-ECF, sem dúvida você entende que é sua empresa e seu software que deve ser cadastrado, independente de usar ou não alguma ferramenta de terceiros em seu sistema.

Peraí! Tem mais!

No terceiro parágrafo há a seguinte explicação sobre o CSRT, que pode ser exigido em formato de hash:

Citar

Desta forma será possível garantir a autoria do software emissor da NF-e/NFC-e, pois, somente a empresa desenvolvedora do software e o Fisco conhecem o valor válido do CSRT utilizado para a geração do “hashCSRT”.

Mais uma vez, se essa é uma informação conhecida somente entre a empresa desenvolvedora e Fisco, não teria como ser disponibilizada por nós. Senão, poderíamos nos passar por você. Seria como você dar seu RG ou Passaporte para outra pessoa se passar por você.

 

Então para pra deixar isso claro pra qualquer pessoa com dúvida no futuro:

O projeto ACBr não se responsabiliza por mal uso de nenhum dos programas, bibliotecas, componentes, ou códigos fontes disponibilizados. Usar qualquer um desses, incluindo o ACBrMonitor Plus, não dá direito a ninguém colocar o Projeto ACBr como responsável técnico, ou de qualquer outra forma responsável perante clientes ou autoridades.

Se alguém pensar diferente, informamos que não tem licença para utilizar o que provemos. Pedimos o favor de ler com cuidado as licenças LGPL e GPL que usamos.

[EMBarbosa]

E quando terceiros prestam serviço de manutenção? Quem é o responsável técnico?

Dúvidas assim podem surgir quando fixamos na mente mais a ideia de um "representante da classe de programação" perante a lei do que na ideia de um responsável pelo sistema.

Talvez isso aconteça porque o termo usado é "responsável técnico". Logo nos vem a mente um engenheiro responsável pela obra e tal...

Mas veja bem, a ideia do responsável técnico, é ter uma "pessoa" para quem a Sefaz vai mandar um e-mail quando quiser falar sobre o software emissor do DF-e.

Como dito antes, suponha que o software emissor tentou retransmitir a mesma NF-e com erros no XML, por 70.000 vezes... ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o mesmo XML que já sabia era rejeitado, isso por 70 mil vezes. Nesse caso, quem a SEFAZ deveria contatar?

Pensar nesses termos, nos ajuda a entender o motivo das tags Responsável Técnico e assim saber como preencher.

Vamos a dois exemplos, com base nas perguntas desse link:

• Imagine uma microempresa, distribuidora de produtos de limpeza, que para emitir a notas fiscais, paga a um programador fazer as alterações nos fontes de um sistema emissor. Esse programador é pessoa física. Como fica esta situação?

Não se engane. A resposta depende mais do tipo do vínculo entre eles e menos de o programador ser uma pessoa física.

A questão que deve ser respondida é: Quem é o responsável pelo software? Quem a SEFAZ deve contatar caso queira falar sobre o sistema?

Isso vai depender de cada caso e talvez de cada UF. Responder algumas perguntas podem ajudar a resolver a questão:

• Atualmente, o sistema é da ME distribuidora de produtos de limpeza?
• O programador é chamado como um terceirizado ou mesmo como funcionário temporário da empresa, não tendo de fato vínculo com o sistema? Por exemplo, ele pode ser substituído por outro programador? (Note, não importa aqui o conhecimento interno do sistema...)

Se a resposta a essas perguntas for sim então, a menos que algo diferente esteja em contrato, o responsável técnico é a empresa distribuidora de produtos de limpeza. 

Ela contrata outra pessoa para dar manutenção mas, ainda assim, ela é responsável, porque o sistema é dela. No PAF-ECF, chamávamos isso de "sistema próprio". Quer dizer próprio da empresa. Não é um sistema que ela aluga.

Caso alguma resposta para as perguntas for não, então, provavelmente, o responsável técnico é o programador. Será necessário verificar com a UF como ele deve ser informado já que ele não tem CNPJ.

• No caso da empresa ter uma pessoa que saiba programação e faça estas alterações mas não é programador registrado e sim diretor ou gerente ADM, como fica?

Nesse caso, sem dúvida, o responsável técnico é a própria empresa. Ela tem um sistema próprio, desenvolvido internamente para emitir os DF-e.

Não importa se quem faz as alterações é um programador ou o contínuo da empresa. O importante é quem é responsável perante a SEFAZ e, nesse caso, é claro que a SEFAZ não vai querer saber quem deu manutenção no sistema. Quando ela precisar falar com um responsável, ela vai querer contatar diretamente a empresa.

Afinal de contas, se a empresa não quisesse isso ela teria contratado um sistema de alguém ao invés de permitir um funcionário (ou sobrinho do dono) criar o sistema.