Matérias

1. 1.   Introdução

A obtenção da autorização de uso do CT-e é um processo que envolve diversos recursos de infraestrutura, hardware e software, tanto por parte da SEFAZ Autorizadora, quanto por parte das empresas. O mau funcionamento ou a indisponibilidade destes recursos podem prejudicar o processo de autorização do CT-e, com reflexos no processo de faturamento da empresa emissora do Conhecimento de Transporte Eletrônico.

A alta disponibilidade é uma das premissas básicas do sistema do CT-e e o Sistema de Autorização de CT-e da SEFAZ foi construído para funcionar em regime de 24x7, no entanto existem diversos componentes do sistema e da infraestrutura que podem apresentar falhas e comprometer a disponibilidade dos serviços.

Por outro lado, existem milhares de “aplicações cliente“ desenvolvidas pelas empresas, cujo comportamento indevido pode gerar um consumo excessivo de recursos do ambiente de autorização das SEFAZ, podendo inclusive vir a prejudicar o uso compartilhado deste ambiente.

Como exemplo maior do mau uso do ambiente de autorização, ressalta-se a falta de controle de algumas aplicações das empresas que entram em “loop”, consumindo recursos de forma indevida, sobrecarregando principalmente o canal de comunicação com a Internet.

Em decorrência do exposto foi publicada a Nota Técnica 06/20112 com o objetivo disciplinar o uso do Ambiente de Autorização da SEFAZ, inicialmente identificando e dando ciência para as empresas das situações de “uso indevido” deste ambiente.

2. Entrada em Vigência

A Nota Técnica 2012/006 - “Aplicação Cliente” - Consumo Indevido do Ambiente de Autorização, fixa os seguintes prazos de entrada em vigência das orientações e possíveis ações restritivas:

· Ambiente de homologação – 01/11/2012

· Ambiente de produção – 01/12/2012

Os sistemas autorizadores passarão a implementar uma politica de restrição de acesso aos Certificados de Transmissão que tiverem consumo caracterizado como uso indevido.

Essa política deverá aplicar bloqueio de conexão dos certificados ou endereços IP assinalados como uso indevido por períodos de tempo variável, desde poucos minutos, até intervalos maiores conforme a criticidade do serviço e o nível de reincidência característica de aplicação em “loop”.

Neste primeiro momento deverá ser excluído da política de bloqueio o Webservice de autorização de CT-e, evitando assim a parada das operações da empresa, entretanto outras ações deverão ser tomadas a critério da Sefaz Autorizadora, iniciando pela ciência aos representantes da área de informática das inconformidades detectadas.

Outras ações que poderão ocorrer:

· Ciência para as empresas das inconformidades apresentadas;

· Divulgação das empresas e/ou prestadores de informática que adotam as

melhores práticas;

3. Uso Indevido

A análise do comportamento atual de consumo dos WebServices do Ambiente de Autorização da SEFAZ permitiu identificar as situações de “uso indevido” deste ambiente.

 A seguir detalhamos as principais situações de “uso indevido” e em alguns casos documentamos também a orientação sobre a melhor prática a ser adotada pelas “aplicações cliente” das empresas.

3.1 Consulta Status Serviço: Intervalo entre Consultas (Delay)

Várias empresas implementaram suas aplicações em “loop” no Webservice de Consulta Status, consumindo de forma indevida o canal de comunicação da SEFAZ e o canal de comunicação da própria empresa.

O Manual de Orientações do Contribuinte define que esta consulta pode ser feita com um intervalo entre consultas (delay) de no mínimo 3 minutos, mas encontramos algumas empresas com mais de 1 consulta por segundo. Verificamos que este comportamento ocorre mesmo nas faixas de horário que a empresa não tem nenhum movimento.

Sobre as melhores práticas

A definição do intervalo entre consultas (delay) do Manual de Orientações do Contribuinte deverá ser observada.

Algumas empresas utilizam esta consulta de uma forma mais racional, efetuando a Consulta Status unicamente após terem recebido um erro de comunicação. Este é o caso de alguns grandes emissores de CT-e, que passam a efetuar a Consulta Status somente quando detectam algum problema de comunicação e usam o resultado desta consulta para a tomada de decisão quanto à entrada ou a saída de contingência.

3.2 Consulta Status Serviço: Antecede o envio do Lote de CT-e

Algumas empresas adotaram a prática de primeiro efetuar uma Consulta Status Serviço antes de enviar o Lote de CT-e.

Mesmo que a consulta Status Serviço retorne que o ambiente de Autorização está normal, a aplicação da empresa deve verificar se o envio do Lote de CT-e ocorreu com sucesso, portanto, não existe vantagem na adoção desta técnica.

Cabem as mesmas recomendações da proposição anterior, eliminado o comando da Consulta Status Serviço nesta situação.

3.3 Consulta Situação do CT-e versus Consulta Status Serviço

Algumas empresas não desenvolveram o Web Service de Consulta Status Serviço, mas utilizam a Consulta Situação CTe (Web Service cteConsultaCT”), sempre com a mesma Chave de Acesso, unicamente para verificar a disponibilidade do Ambiente de Autorização.

Cabem as mesmas recomendações das proposições anteriores, com a eliminação desta prática indevida.

3.4 Consulta Situação CT-e: Verifica Autorização

Algumas empresas utilizam a Consulta Situação CTe (Web Service cteConsultaCT”) para verificar se a Chave de Acesso realmente foi autorizada pela SEFAZ Autorizadora. Este procedimento normalmente é feito pela empresa destinatária do CT-e, quando a empresa mantém uma lista com as Chaves de Acesso dos CT-e recebidos e somente exclui a Chave de Acesso desta lista após a Consulta Situação CTe retornar um resultado satisfatório (mensagem de resposta com “100-Autorizado o Uso do CT-e”.

A “aplicação cliente” de algumas empresas permanece em “loop” nesta consulta, verificando sempre a mesma Chave de Acesso, que retorna com o erro “217-CT-e não consta na base de dados da SEFAZ”.

Sobre as melhores práticas

Adotar um tempo limite para efetuar esta consulta, dependendo da data de emissão do CTe.

Proposto:

- Manter um intervalo (delay) entre as consultas de 3 minutos, no mínimo, evitando que o “loop” da aplicação prejudique o Ambiente de Autorização da SEFAZ;

- Consultar os CT-e emitidos no máximo no mês anterior, removendo a Chave de Acesso da lista de CT-e não encontrados na SEFAZ Autorizadora.

Observação sobre o motivo da Chave de Acesso Inexistente:

Analisamos alguns casos onde a consulta da Chave de Acesso pela empresa destinatária não encontra o CT-e autorizado pela SEFAZ. Os motivos que levam a esta inconsistência podem ser:

- O Código Numérico da Chave de Acesso é diferente daquele existente no banco de dados da SEFAZ (maior parte dos casos);

- Por algum motivo, o CT-e foi emitido em contingência pela empresa emitente e, mesmo passado algum tempo, o CT-e não foi enviado para a SEFAZ Autorizadora;

- Operação comercial inidônea, com falsificação da DACTE pela empresa emitente.

3.5 Consulta Resultado do Lote

Como retorno do envio de um Lote para a SEFAZ, a empresa recebe o Número do Recibo deste Lote. Posteriormente a empresa consome o WebService de Retorno do Lote, informando este número de Recibo e recebendo o resultado do processamento do Lote.

Eventualmente algumas empresas “perdem” o Número do Recibo e passam a efetuar um “loop” na consulta de Resultado do Lote informando Números de Recibo seqüenciais, a partir de um número conhecido. Todas as mensagens são rejeitadas com o erro “223- CNPJ do transmissor do Lote difere do CNPJ do transmissor da Consulta”

Sobre as melhores práticas

No caso de perda do Número do Recibo, a definição da SEFAZ é que a empresa deve consultar individualmente a Chave de Acesso de cada CT-e que estava compondo este Lote, tomando a decisão de considerar se o CT-e está autorizado ou não, como resultado desta consulta.

3.6 Tratamento de Erro HTTP

Ocorrem várias situações em que a aplicação da empresa entra em loop reenviando a mesma mensagem, quando recebe como retorno um Status de erro HTTP.

As principais situações que levam a isso (no ambiente de produção) são:

· Erro 403.17: Certificado de Transmissão expirou;

· Erro 403.7: Certificado de Transmissão não apresentado;

· Erro 400.0: erro na chamada do WebService;

· Erro 500.0: Consumo de um WebService utilizando o WSDL de outro;

Sobre as melhores práticas

A aplicação da empresa deve tratar o HTTP Status evitando o reenvio de mensagens com erro. Em alguns casos, chegamos a acionar a empresa e em todos os casos sempre é surpresa a existência deste tipo de erro.

Em relação ao uso do Certificado Digital de transmissão, além do “loop” indevido da “aplicação cliente”, em alguns casos a empresa acaba contatando a SEFAZ perguntando se o Ambiente de Autorização está operacional, quando o problema é motivado pelo vencimento do seu Certificado Digital, por exemplo.

Portanto, além de evitar o “loop” da aplicação enviando a mesma mensagem, a aplicação da empresa deve ser alterada para informar ao operador da própria empresa do problema existente com o Certificado Digital, ou do outro motivo qualquer que motivou Status de erro HTTP.

3.7 Tempo de Espera (“timeout”)

Existem situações em que a aplicação da empresa não aguarda a resposta do Ambiente de Autorização e inicia um novo processo de consumo do WebService de forma antecipada.

Sobre as melhores práticas

O tempo de espera por uma resposta do Ambiente de Autorização é função da capacidade de processamento deste Ambiente e, principalmente, da infraestrutura do canal de comunicação com a Internet disponibilizado pela SEFAZ e pela empresa. De qualquer forma, este tempo pode variar, principalmente por alguma variação relacionada com o uso do backbone da Internet.

Proposta a adoção de um timeout mínimo de 50 segundos, antes da adoção de outras medidas pela aplicação da empresa. Ou seja, aguardar este tempo mínimo antes de reenviar a mensagem, ou decidir por entrar em contingência.

Fonte: Nota Técnica n. 006/2012

Por Marley Lima