Cronograma
- Homologação: 01/06/2019
- Produção: 15/07/2019
As regras de validação do QR Code devem entrar em vigor a partir de 07/10/2019 no ambiente de produção, no ambiente de homologação as regras do QR code passam a ser aplicadas a partir do dia 15/07/2019
Histórico de Alterações
- Consolidação das notas técnicas 2017-2018
- Alteração da validação da chave de acesso unificando as regras
- Criação do Evento de Inclusão de DF-e
- Criação do Web Service Síncrono de autorização
- Novas regras de integração ANTT
- Regras de validação de CNPJ/CPF para proprietário, contratante e responsável pelo CIOT no modal rodoviário
- Disciplina as regras para uso indevido
- Definição dos padrões do QR Code
- Regras de validação para grupo de responsável técnico
Informações Sobre as Alterações
1) Consolidação das notas técnicas 2017-2018
Sem explanação no assunto.
2) Alteração da validação da chave de acesso unificando as regras
604 – Chave de acesso da NF-e informada inválida [chNFe:9999999999999999999999999999999999999999999 Motivo: xxxx]
Rejeição obrigatória para todos os estados
Causa: Se informado grupo NF-e, para cada uma das NF-e relacionadas: Validar chave de acesso, retornar chave inválida e o motivo da rejeição da chave de acesso: CNPJ / CPF zerado ou inválido, Ano < 2006 ou maior que a atual, Mês inválido (0 ou > 12), Modelo diferente de 55, Número zerado, Tipo de emissão inválido, UF inválida ou DV inválido
649 – Chave de acesso de MDF-e informada inválida [chNFe:9999999999999999999999999999999999999999999 Motivo: xxxx]
Rejeição obrigatório para todos os estados
Causa: Se informado o grupo MDFeTransp, para cada um dos MDF-e relacionados: Validar chave de acesso, retornar chave inválida e motivo da rejeição da Chave de acesso: CNPJ / CPF zerado ou inválido, Ano < 2012 ou maior que atual, Mês inválido (0 ou > 12), modelo diferente de 58, número zerado, tipo de emissão inválido, UF inválida ou DV inválido.
601 – Chave de acesso do CT-e informado inválida [chCTe:9999999999999999999999999999999999999999999 Motivo: xxxx]
Rejeição obrigatória para todos os estados
Causa: Se informado grupo CT-e, para cada um dos CT-e relacionados: Validar a chave de acesso, retornar chave inválida e o motivo da rejeição da chave de acesso: CNPJ / CPF zerado ou inválido, Ano < 2008 ou maior que atual, Mês inválido (0 ou > 12), modelo diferente de 57, Número zerado, tipo de emissão inválido, UF inválida ou DV inválido.
3) Criação do Evento Inclusão de DF-e
3.1. Informações sobre o evento de inclusão
Nessa nota técnica foi incluído o evento de inclusão de DF-e que funciona juntamente com a tag de MDF-e com carregamento posterior.
É permitida a emissão do MDF-e quando, por ocasião do início da viagem, o emitente do MDF-e de carga própria não tiver acesso aos documentos fiscais transportados e tratar-se de operação interna na UF.
Nesses casos, o emitente poderá optar pela modalidade de emissão do MDF-e com indicação de tag específica do XML, intitulado indicador de carregamento posterior. Uma vez identificada essa modalidade de emissão, a inclusão de documentos fiscais será permitida em momento posterior à emissão do MDF-e, por meio do evento de inclusão de documento fiscal que deverá ser autorizado. Assim, os documentos passarão a compor a carga à medida em que ocorrerem os carregamentos no percursos da viagem.
O Evento de inclusão de DF-e é utilizado para quando o MDF-e tem a indicação de carregamento posterior
3.2. Validações de carregamento posterior
703 – Carregamento e Descarregamento inválidos para MDF-e com indicação de carregamento posterior
Causa: Se informado indicador de carregamento posterior (indCarregaPosterior=1), deve ser informado apenas um município de carregamento e um município de descarregamento que devem ser iguais
704 – MDF-e com indicação de carregamento posterior não permitido para operações interestaduais ou com o exterior
Causa: Se ifnormado indicador de carregamento posterior (indCarregaPosterior=1), UF de carregamento deve ser igual a UF de descarregamento e diferentes de EX
705 – Modal inválido para MDF-e com indicação de carregamento posterior (apenas modal rodoviário)
Causa: Se informado indicador de carregamento posterior (indCarregaPosterior=1), modal deve ser rodoviário
707 – MDF-e com indicação de carregamento posterior com tipo de emitente diferente de transporte próprio
Causa: Se informado indicador de carregamento posterior (indCarregaPosterior=1), o tipo do emitente deve ser transporte próprio
712 – Existe MDF-e com indicação de carregamento posterior sem inclusão de DF-e para o emitente há mais de 168 horas
Causa: Verificar se existe MDF-e com indicação de carregamento posterior (indCarregaPosterior=1), sem evento de inclusão de DF-e há mais de 168 horas para o mesmo CNPJ / CPF do emitente
4) Criação do Web Service Síncrono de autorização
4.1. Informações
As solicitações de serviços de implementação síncrona são processadas imediatamente e o resultado do processamento é obtido em uma única conexão.
A seguir, o fluxo simplificado de funcionamento:
Etapas do processo:
- O aplicativo do contribuinte inicia a conexão enviando uma mensagem de solicitação de serviço para o Web Service;
- O web service recebe a mensagem de solicitação de serviço e encaminha ao aplicativo do MDF-e que irá processar o serviço solicitado;
- O aplicativo do MDF-e recebe a mensagem de solicitação de serviço e realiza o processamento, devolvendo uma mensagem de resultado do processo ao Web Service;
- O web service recebe a mensagem de resultado do processamento e o encaminha ao aplicativo do contribuinte;
- O aplicativo do contribuinte recebe a mensagem de resultado do processamento e, caso não exista outra mensagem, encerra a conexão.
Para os serviços síncronos, o envio da solicitação e a obtenção do retorno serão realizados na mesma conexão por meio de um único método.
4.2. Tipos de serviço síncrono
- Serviço de Recepção Síncrono
O serviço de recepção de MDF-e é o serviço oferecido pelo ambiente autorizador para recepção dos MDF-e emitidos pelos contribuintes credenciados para emissão deste documento. - Serviço de Retorno Recepção
Serviço que deverá ser utilizado pelo emitente para obter o resultado do processamento do arquivo de MDF-e enviado ao serviço de recepção assíncrono. - Serviço de Consulta Situação do MDF-e
Serviço destinado ao atendimento de solicitações de consulta da situação atual do MDF-e na base de dados do ambiente autorizador. - Serviço de consulta MDF-e não encerrados
Serviço destinado à consulta MDF-e não encerrados na base de dados do ambiente autorizador - Serviço de Consulta Status do Serviço de Autorização
Serviço destinado à consulta do status do serviço prestado pelo Ambiente Autorizador - Serviço de Consulta Cadastro
Serviço para consultar o cadastro de contribuintes do ICMS da unidade federada
5) Novas Regras de Integração ANTT
5.1. Informações
Criado 6 novas validações para ANTT, ANTT é a Agência Nacional de Transporte Terrestres é uma autarquia federal brasileira responsável pela regulação das atividades de exploração da infraestrutura ferroviária e rodoviária federal e de prestação de serviços de transporte terrestres.
5.2. Validações
681 – RNTRC informado inexistente.
Rejeição Facultativa
Causa: Se modal rodoviário e informado RNTRC verificar se o RNTRC existe.
682 – RNTRC situação inválida
Rejeição Facultativa
Causa: Se modal rodoviário e informado RNTRC verificar situação do RNTRC.
683 – Placa do veículo de tração não vinculada ao RNTRC informado
Rejeição Facultativa
Causa: Se modal rodoviário e informado RNTRC verificar se a placa do veículo de tração está associada ao RNTRC.
684 – CIOT obrigatório para RNTRC informado.
Rejeição Facultativa
Causa: Se modal rodoviário, UF Carregamento e Descarregamento forem diferentes de
Exterior e informado RNTRC
Verificar se foi informado CIOT quando este for obrigatório para o RNTRC
687 – RNTRC deve estar associado ao transportador indicado
Rejeição Facultativa
Causa: Se modal rodoviário e informado RNTRC verificar se o RNTRC está associado ao transportador
Observação: verificar pelo CNPJ-base.
688 – RNTRC deve ser informado para prestador de serviço de transporte
Rejeição Facultativa
Causa: Se modal rodoviário, operação interestadual e tipo de emitente for prestador de serviços de transporte (tpEmit=1) ou globalizado (tpEmit=3): RNTRC deve ser informado.
As validação es da ANTT são aplicadas com base na integração entre os sistemas da agência e do ambiente autorizador do MDF-e, em caso de indisponibilidade do serviço de integração, as regras serão desabilitadas a´te a normalização. Em caso de rejeição, entre em contato com a ANTT nos canais de atendimento para solucionar as pendências As regras serão aplicadas aos RNTRC do transportador emitente do MDF-e e ao RNTRC do proprietário quando veículo não pertencer ao emitente do MDF-e
6) Regras de validação de CNPJ/CPF para proprietário, contratante e responsável pelo CIOT no modal rodoviário
6.1. Validações Modal Rodoviário
611 – Existe MDF-e não encerrado para esta placa, tipo de emitente e UF descarregamento
Rejeição Obrigatória
Causa: Se modal rodoviário: – Verificar se existe MDF-e não encerrado, para a placa principal (mesmo CNPJ base / CPF do emitente do MDF-e, mesma placa, mesmo tipo de emitente e a mesma UF descarregamento).
Observação: retornara chave de acesso e protocolo de autorização mais antigo que causa o bloqueio.
686 – Rejeição: Existe MDF-e não encerrado há mais de 30 dias para o emitente
Rejeição Obrigatória
Causa: Verificar se existe MDF-e não encerrado para o CNPJ / CPF do emitente com amais de 30 dias desde a autorização.
462 – Existe MDF-e não encerrado há mais de 5 dias para placa com até 2 UF de percurso informadas
Rejeição Obrigatória
Causa: Se modal rodoviário: verificar se existe MDF-e não encerrado para a placa do veículo com o mesmo CNPJ base / CPF do emitente com mais de 5 dias desde a autorização indicando no máximo duas UF de percurso além do carregamento e descarregamento.
662 – Existe MDF-e não encerrado para esta placa, tipo de emitente no sentido oposto da viagem
Rejeição Obrigatória
Causa: Se modal rodoviário: verificar se existe MDF-e não encerrado, para a placa principal (mesmo CNPJ base / CPF do emitente do MDF-e, mesma placa, mesmo tipo de emitente e contendo o par UF de carregamento/UF de descarregamento no sentido oposto ao MDF-e que está sendo autorizado).
646 – Placa de veículo formato inválido (UF Carregamento e Descarregamento <> ‘EX’)
Rejeição Obrigatória
Causa: Se modal rodoviário, UF carregamento e descarregamento forem diferentes de exterior: verificar se as placas informadas (veiculo tração e reboques) encontra-se diferentes do formato nacional.
663 – Percurso informado inválido
Rejeição Obrigatória
Causa: Se modal rodoviário, o grupo de informações de UF de percurso deverá ser preenchido na ordem origem – destino sempre que existir pelo menos uma UF entre a UF de carregamento e UF de descarregamento.
698 – Seguro da carga é obrigatório para modal Prestador de Serviço de Transporte no modal rodoviário
Rejeição Obrigatória
Causa: Se modal rodoviário e tipo emitente for igual a prestador de serviço de transporte (tpEmit=1) ou transportador que emitirá CT-e globalizado (tpEmit=3): rejeitar se o grupo de informações do seguro da carga não estiver informado.
699 – Dados do seguro de carga incompletos para o modal rodoviário
Rejeição Obrigatória
Causa: Se modal rodoviário e tipo emitente for igual a prestador de serviço de transporte (tpEmit=1) ou transportador que emitirá CT-e globalizado (tpEmit=3) e informado grupo de seguro da carga: rejeitar se alguma informação do grupo seguro não estiver informada.
Observação: verificar preenchimento de CNPJ da seguradora, infseg – Informações do seguro, nApol – Número da apólice e nAver – Número da averbação.
542 – CNPJ/CPF do responsável pelo seguro deve ser informado para o tipo de responsável informado
Rejeição Obrigatória
Causa: Se modal rodoviário e tipo emitente for igual a prestador de serviço de transporte (tpEmit=1) ou transportador que emitirá CT-e globalizado (tpEmit=3), informado grupo de seguro da carga e indicado responsável pelo seguro contratante (tpResp=2): rejeitar se não estiver informado o CNPJ ou CPF do responsável pelo seguro.
578 – Informações dos tomadores é obrigatória para esta operação
Rejeição Obrigatória
Causa: Se modal rodoviário e tipo emitente for igual a prestador de serviço de transporte (tpEmit=1) ou transportador que emitirá CT-e globalizado (tpEmit=3) e não estiverem preenchidos:
1 – Responsável pela geração do CIOT
ou
2 – Responsável pelo pagamento do vale-pedágio
Então:
Rejeitar se não estiver informado pelo menos um tomador de serviço (grupo infContratante).
577 – Duplicidade de condutor
Rejeição Obrigatória
Causa: Se modal rodoviário: rejeitar se existir CPF de condutor informado em duplicidade no grupo veículo tração
645 – CPF do condutor inválido
Rejeição Obrigatória
Causa: Se modal rodoviário: rejeitar se algum CPF de condutor estiver inválido entre os relacionados (dígito de controle, zeros).
716 – CNPJ / CPF do responsável pela geração do CIOT inválido
Rejeição Obrigatória
Causa: Se modal rodoviário e informado grupo do CIOT (grupo:infCIOT): rejeitar se o CPF ou CNPJ do responsável pela geração do CIOT informado estiver inválido (dígito de controle, zeros)
717 – CNPJ / CPF do contratante do transporte inválido
Rejeição Obrigatória
Causa: Se modal rodoviário e informado grupo do contratante (grupo: infContratante): rejeitar se o CPF ou CNPJ informado para o contratante estiver inválido (dígito de controle, zeros).
718 – CNPJ / CPF do proprietário do veículo de tração inválido
Rejeição Obrigatória
Causa: Se modal rodoviário e informado grupo do proprietário do veículo de tração (grupo: veicTracao/prop): rejeitar se o CPF ou CNPJ informado para o proprietário estiver inválido (dígito de controle, zeros)
719 – CNPJ / CPF do proprietário do veículo reboque inválido
Rejeição Obrigatória
Causa: Se modal rodoviário e informado grupo do proprietário do veículo reboque (grupo: veicReboque/prop): rejeitar se o CPF ou CNPJ informado para o proprietário estiver inválido (dígito de controle, zeros), verificar em todos os reboques informados.
7) Disciplina as Regras para Uso Indevido
7.1. Informações
A análise do comportamento atual das aplicações das empresas (“aplicação cliente”) permite identificar algumas situações de “uso indevido” nos ambientes autorizadores.
Como exemplo maior do mau uso do ambiente, ressalta-se a falta de controle de algumas aplicações que entram em “loop”, consumindo recursos de forma indevida, sobrecarregando principalmente o canal de comunicação com a internet.
Para evitar esses problemas serão mantidos controles para identificar as situações de uso indevido de sucessivas tentativas de busca de registro já disponibilizados anteriormente.
As notas tentativas serão rejeitadas com o erro 678 – Consumo indevido.
7.2. Validações para Uso Indevido
678 – Consumo Indevido, é separado por eventos, abaixo está a listagem de todos os tipos de eventos e suas causas de rejeição.
| Autorização de MDF-e |
| Regra de validação | Crítica | Msg |
| MDFe enviado com mais de 30* rejeições iguais: – Contribuinte ficará com o web service de autorização recebendo a rejeição 678 por até 1 hora para todas as requisições Observação 1: Caso após o tempo de 1 ( uma) hora o contribuinte envie novamente o mesmo MDF-e e tenha a mesma rejeição, ele poderá voltar a receber a rejeição 678 por até 1 (uma) hora, e isso se repetirá até ele parar de enviar o MDF-e com a mesma rejeição. Observação 2: A verificação do contribuinte para receber a rejeição 678 poderá ser feita em tempo de conexão pela identificação do CNPJ / CPF do emitente. Observação 3: A critério da UF, após 50 bloqueios o contribuinte poderá receber a rejeição 678 permanentemente, até entrar em contato com a UF autorizadora. |
Facult. |
678 |
| Consulta Situação |
| Regra de validação | Crítica | Msg |
|
MDF-e consultado mais de 10 vezes em 1 (uma) hora: |
Facult. | 678 |
| Registro de Eventos |
| Regra de validação | Crítica | Msg |
| Evento enviado com mais 20 rejeições iguais: – Contribuinte ficará com web service de eventos recebendo a rejeição 678 por até 1 (uma) hora para todos as requisições. Observação 1: Caso após o tempo de 1 (uma) hora o contribuinte envie novamente o mesmo evento e tenha a mesma rejeição, ele poderá voltar a receber a rejeição 678 por até 1 (uma) hora, e isso se repetirá até ele parar de enviar o evento com a mesma rejeição. Observação 2: A verificação do contribuinte para receber a rejeição 678 poderá ser feita em tempo de conexão pela identificação do CNPJ / CPF do certificado digital de transmissão mais o endereço de IP (CNPJ / CPF + IP) ou pela identificação do CNPJ / CPF do autor. Observação 3: A critério da UF, após 50 bloqueios o contribuinte poderá receber a rejeiçaõ 678 permanentemente, até entrar em contato com a UF autorizadora. |
Facult. | 678 |
| Outros Serviços |
| Regra de validação | Crítica | Msg |
| Se for verificado algum tipo de envio em looping (mais de 60 envios repetidos) no período de 5 minutos em outro web service que gere erro ou onere o sistema autorizador: – Contribuinte ficará com a web service recebendo a rejeição 678 por até 1 (uma) hora para todos as requisições. Observação 1: A verificação do contribuinte para receber a rejeição 678 poderá ser feita em tempo de conexão pela identificação do CNPJ / CPF do certificado digital de transmissão mais o endereço IP (CNPJ / CPF + IP) ou pela identificação do CNPJ / CPF do emitente (emit/CNPJ). |
Facult. | 678 |
8) Definição dos padrões do QR Code
8.1. Informações
O QR Code é um código de barras bidimensaional que foi criado em 1994 pela empresa japonesa Denso-Wave. QR siginifica “quick response” devido à capacidade de ser interpretado rapidamente.
Esse tipo de codificação permite que possa ser armazenada uma quantidade significativa de caracteres:
Numéricos: 7089
Alfanumérico: 4296
Binário (8 bits): 2953
O QR Code deverá existir no DAMDFE (impresso do MDFe), relativo à emissão em operação normal ou em contingência, seja ele impresso ou virtual. A impressão do QR Code no DAMDFE (impresso do MDFe) tem a finalidade de facilitar a consulta dos dados do documento fiscal eletrônico pela fiscalização e demais atores do processo.
8.2. MDF-e com tipo de emissão normal como gerar
O QR code está divido em duas partes, abaixo será discriminada cada uma delas
1° – parte – Endereço do site da Portal Nacional do MDF-e, seguido do caractere “?”, a lista dos serviços abaixo:
SEFAZ Virtual Rio Grande do Sul (SVRS) – Produção
| QR Code | https://dfe-portal.svrs.rs.gov.br/mdfe/qrCode |
SEFAZ Virtual Rio Grande do Sul (SVRS) – Homologação
| QR Code | https://dfe-portal.svrs.rs.gov.br/mdfe/qrCode |
Observação: O portal do ambiente nacional do MDF-e utiliza o mesmo endereço para consulta no ambiente de produção e ambiente de homologação. Neste caso, a distinção entre os ambientes de consulta será feita diretamente pela aplicação, a partir do conteúdo do parâmetro de identificação do ambiente (tpAmb), constante no QR code.
2° – parte – Parâmetros para consultar a chave de acesso de DMF-e separados pelo caractere “&”
- chMDFe: chave de acesso do MDF-e (44 caracteres)
- tpAmb: Identificação do ambiente (1 – Produção / 2 – Homologação)
Juntando as duas partes exemplo de como que vai ficar a URL do QR Code
https://dfe-portal.svrs.rs.gov.br/mdfe/qrCode?chMDFe=41190779100186000100581800000000031300000000&tpAmb=2
Esta mesma URL deverá abrir em qualquer navegador, e vai listar o MDFe emitido com essa chave de acesso.
8.3. Validações do QR Code
479 – Endereço do site da UF da consulta via QR code diverge do previsto
Causa: Endereço do site do Portal Nacional para consulta via QR code difere do previsto.
Nota: o uso diferenciado de maiúsculas ou minúsculas não deve ser considerado na validação
Observação: Para consultar as URLs utilizadas no QR code, acesse: https://dfe-portal.svrs.rs.gov.br/Mdfe/Servicos
480 – O QR code do MDF-e deve ser informado
Causa: Quando não contiver a tag qrcode dentro do XML será retornado a rejeição
481 – Parâmetro chave de acesso do QR code diverge do MDF-e
Causa: Parâmetro chave de acesso no QR code diverge da chave de acesso do MDF-e
482 – Parâmetro sign não informado no QR code para emissão em contingência
Causa: Se tipo de emissão for igual a contingência: o parâmetro sign não deve ser informado no QR code
488 – Parâmetro sign não deve ser informado no QR code para emissão normal
Causa: Se tipo de emissão for igual a normal: o parâmetro sign não deve ser informado no QR code
496 – Assinatura do QR Code difere do calculado
Causa: Se o tipo de emissão for igual a contingência: Valor da assinatura (sign) do QR code difere do valor calculado
9) Regras de Validação para Grupo Responsável Técnico
9.1. Informações
O novo grupo adicionado ao schema principal do MDF-e foi alterado de “infEmpresaSoft” para “infRespTec”. Este grupo tem o objetivo de identificar o responsável técnico do sistema utilizado na emissão do documento fiscal eletrônico.
A informação do responsável pelo desenvolvimento do sistema emissor é de grande utilidade para as SEFAZ. Permite identificação de uso indevido dos sistemas e maior agilidade para área de TI das SEFAZ fazer o contato com os fornecedores de solução dos emitentes. É importante ressaltar que esse grupo ainda não é obrigatório. Sendo assim, fica a critério da UF a exigência do preenchimento do grupo no futuro.
Segue abaixo informações dos novos campos do grupo:
9.2 Sobre as tags do XML
<infRespTec> – Informações do responsável técnico pela emissão do DF-e
Grupo de informações para informação do responsável técnico pelo sistema de emissão do DF-e
<CNPJ> – CNPJ da pessoa jurídica desenvolvedora do sistema utilizado na emissão do documento fiscal
Ocorrência: 1-1
Tamanho: 14
Informar o CNPJ da pessoa jurídica desenvolvedora do sistema utilizado na emissão do documento fiscal eletrônico.
<xContato> – Nomde da pessoa a ser contatada
Ocorrência: 1-1
Tamanho: 2-60
Informar o nome da pessoa a ser contada na empresa desenvolvedora do sistema utilizado na emissão do documento fiscal eletrônico. No caso de pessoa física, informar respectivo nome.
<email> – E-mail da pessoa jurídica/física a ser contada
Ocorrência: 1-1
Tamanho: 6-60
Informar o endereço de e-mail para contato da pessoa responsável.
<fone> – Telefone da pessoa jurídica/física a ser contatada
Ocorrência: 1-1
Tamanho: 7-12
Informar o telefone DDD + número.
<idCSRT> – Identificador do código de segurança do responsável técnico
Ocorrência: 1-1
Tamanho: 3
Identificador do CSRT utilizado para geração do hash
<hashCSRT> – Hash do token do código de segurança do responsável técnico
Ocorrência: 1-1
Tamanho: 28
O hashCSRT é o resultado das funções SHA-1 e base64 do token CSRT fornecido pelo fisco + chave de acesso do DF-e.
9.3. Validações Responsável Técnico
720 – Obrigatória as informações do responsável técnico
Facultativo
Causa: Não informado o grupo de informações do responsável técnico
Observação: implementação à critério da UF
713 – CNPJ do desenvolvedor do sistema inválido (zerado ou dígito inválido)
Facultativo
Causa: Se informado grupo do responsável técnico (infRespTec): Validar CNPJ (dígito controle, zeros ou nulo)
721 – Obrigatória a informação do identificador do CSRT e do Hash do CSRT
Causa: Obrigatória a inofrmação do identificador do CSRT (tag:idCSRT) e hash do CSRT(tag:hashCSRT)
Observação: Implementação futura