Projeto Nota Fiscal de Energia Elétrica Eletrônica

Manual de Orientação do Contribuinte

NF3eReceita Estadual do Paraná

Web Service - NF3eRecepcaoEvento - Parte Geral

Conteúdo técnico da parte geral do Sistema de Registro de Eventos do MOC NF3e - Visão Geral v.1.00a. O MOC Online é material de apoio e não substitui os documentos oficiais.

Função: serviço destinado à recepção de mensagem de evento de NF3e.

Processo: síncrono.

Nome Serviço: NF3eRecepcaoEvento.

Método: nf3eRecepcaoEvento.

Parâmetro da mensagem da área de dados: XML sem compactação.

1. Leiaute da Mensagem de Entrada

Entrada: estrutura XML contendo a consulta do status do serviço.

Schema XML: eventoNF3e_v9.99.xsd.

#CampoEle.PaiTipoOcor.Tam.Descrição/Observação
FP01eventoNF3eRaiz----TAG raiz.
FP02versaoAFP01N1-12v2Versão do leiaute.
FP03infEventoGFP01-1-1-Grupo de informações do registro de eventos.
FP04IdIDFP03C1-154-55Identificador da TAG a ser assinada. Regra de formação: “ID” + tpEvento + chave da NF3e + nSeqEvento.
Observação: nSeqEvento deve ser preenchido com zeros à esquerda para fechar 2 (até 99) ou 3 (até 999) dígitos.
FP05cOrgaoEFP03N1-12Código do órgão de recepção do Evento. Utilizar a Tabela do IBGE estendida.
FP06tpAmbEFP03N1-11Identificação do Ambiente: 1 - Produção; 2 - Homologação.
FP07CNPJEFP03N1-114Informar o CNPJ do autor do Evento.
FP08chNF3eEFP03N1-144Chave de Acesso da NF3e vinculada ao Evento.
FP09dhEventoEFP03D1-1-Data e Hora do Evento. Formato = AAAA-MM-DDTHH:MM:SS TZD.
FP10tpEventoEFP03N1-16Tipo do Evento (ver tabela de tipos de evento).
FP11nSeqEventoEFP03N1-11-3Sequencial do evento para o mesmo tipo de evento. Para a maioria dos eventos será 1; nos casos em que possa existir mais de um evento, o autor deve numerar de forma sequencial.
FP12detEventoGFP03-1-1-Informações do evento específico.
FP13versaoEventoAFP12N1-12v2Versão do leiaute específico do evento.
FP14anyEFP12XML1-1-XML do evento. Inserir neste local o XML específico do tipo de evento (cancelamento).
FP15SignatureGFP01XML1-1-Assinatura XML do grupo identificado pelo atributo “Id”.

2. Leiaute da Mensagem de Retorno

Retorno: estrutura XML com o resultado do pedido de evento.

Schema XML: retEventoNF3e_v9.99.xsd.

#CampoEle.PaiTipoOcor.Tam.Descrição/Observação
FR01retEventoNF3eRaiz----TAG raiz do Resultado do Envio do Evento.
FR02versaoAFR01N1-11-4Versão do leiaute.
FR03infEventoGFR01-1-1-Grupo de informações do registro do Evento.
FR04IdIDFR03C0-118Identificador da TAG a ser assinada, somente informado se o órgão de registro assinar a resposta. Nesse caso, preencher com o número do protocolo precedido do literal “ID”.
FR05tpAmbEFR03N1-11Identificação do Ambiente: 1 - Produção; 2 - Homologação.
FR06verAplicEFR03C1-11-20Versão da aplicação que registrou o Evento; utilizar literal que permita a identificação do órgão, como a sigla da UF ou do órgão.
FR07cOrgaoEFR03N1-12Código da UF que registrou o Evento.
FR08cStatEFR03N1-13Código do status da resposta.
FR09xMotivoEFR03C1-11-255Descrição do status da resposta.
Os campos a seguir são obrigatórios no caso de homologação do evento cStat=135, 134 ou 136. Os campos dhRegEvento e nProt não serão preenchidos em caso de erro.
FR10chNF3eEFR03N0-144Chave de Acesso da NF3e vinculada ao evento.
FR11tpEventoEFR03N0-16Código do Tipo do Evento.
FR12xEventoEFR03C0-15-60Descrição do Evento.
FR13nSeqEventoEFR03N0-11-3Sequencial do evento para o mesmo tipo de evento. Para a maioria dos eventos será 1; nos casos em que possa existir mais de um evento, o autor deve numerar de forma sequencial.
FR14dhRegEventoEFR03D0-1-Data e Hora do Evento. Formato = AAAA-MM-DDTHH:MM:SS TZD.
FR15nProtEFR15N0-116Número do protocolo de registro do evento.
FR16SignatureGFR01XML0-1-Assinatura Digital do documento XML, aplicada no elemento infEvento. A decisão de assinar a mensagem fica a critério do Ambiente Autorizador.

3. Descrição do Processo de Web Service

Este método recebe solicitações de registro de eventos de NF3e. Ao receber a solicitação do transmissor, a aplicação do Ambiente Autorizador processa a mensagem e devolve o resultado ao aplicativo.

O Web Service de Eventos é acionado pelo interessado, emissor ou órgão público, que envia a mensagem de registro de evento.

4. Regras de Validação Básicas do Serviço

GrupoDescrição
AValidação do Certificado de Transmissão (protocolo TLS).
BValidação Inicial da Mensagem no Web Service.
CValidação da Área de Dados da mensagem.
DValidações do Certificado de Assinatura.
EValidações da Assinatura Digital.

5. Validação das Regras de Negócio do Serviço de Registro de Eventos

#Regra de ValidaçãoAplic.cStatEfeitoMensagem
K01Tipo do ambiente informado difere do ambiente do Web Service.Obrig.252Rej.Rejeição: Ambiente informado diverge do Ambiente de recebimento.
K02Verificar se o código do órgão de recepção do Evento diverge do solicitado.Obrig.226Rej.Rejeição: Código da UF do Emitente diverge da UF autorizadora.
K03Validar CNPJ do autor do evento (DV ou zeros).Obrig.627Rej.Rejeição: CNPJ do autor do evento inválido.
K04Validar se o atributo Id corresponde à concatenação dos campos do evento (“ID” + tpEvento + chNF3e + nSeqEvento).
Observação: o atributo ID poderá ter 54 ou 55 dígitos; a variação ocorre no nSeqEvento, que pode ter 2 ou 3 posições.
Obrig.628Rej.Rejeição: Erro Atributo ID do evento não corresponde à concatenação dos campos (“ID” + tpEvento + chNF3e + nSeqEvento).
K05Verificar se o tpEvento é válido.Obrig.629Rej.Rejeição: O tpEvento informado inválido.
K06Verificar Schema da parte específica do Evento.
Observação: utilizar o tpEvento + o atributo versaoEvento para identificar qual schema deve ser validado.
Obrig.630Rej.Rejeição: Falha no Schema XML específico para o evento.
K07Validar chave de acesso da NF3e. Retornar o motivo da rejeição: CNPJ zerado ou inválido, Ano < 2019 ou maior que o atual, Mês inválido (0 ou > 12), Modelo diferente de 66, Número zerado, Tipo de emissão inválido, UF inválida ou DV inválido.Obrig.236Rej.Rejeição: Chave de Acesso inválida [Motivo: XXXXXXXXX].
K08Site de autorização da chave de acesso da NF3e difere do Site de Recebimento.
Observação: o número do Site só deve ser diferente de zero em ambientes de autorização com múltiplos Sites; a relação de identificadores deve ser disponibilizada pelo Autorizador.
Obrig.482Rej.Rejeição: Site de autorização inválido.
K09Verificar duplicidade do evento (cOrgao + tpEvento + chNF3e + nSeqEvento).Obrig.631Rej.Rejeição: Duplicidade de evento [nProt:999999999999999][dhRegEvento: AAAA-MM-DDTHH:MM:SS TZD].
K10Se evento do emissor, verificar se o CNPJ do Autor difere do CNPJ da chave de acesso da NF3e.Obrig.632Rej.Rejeição: O autor do evento diverge do emissor da NF3e.
K11Se evento do Fisco/Outros órgãos, verificar se o CNPJ do Autor consta da tabela de órgãos autorizados a gerar evento.Obrig.633Rej.Rejeição: O autor do evento não é um órgão autorizado a gerar o evento.
K12Se o evento exige NF3e, acessar o BD NF3e (Chave: CNPJ Emit, Modelo, Série, Nº) e verificar se a NF3e não existe.
Observação: esta validação considera o ambiente de autorização do DF-e (nSiteAutoriz).
Obrig.217Rej.Rejeição: NF3e não consta na base de dados da SEFAZ.
K13Se existir a NF3e, independentemente de o evento exigir, verificar se a Chave de Acesso difere da existente em BD. Opcionalmente, xMotivo pode concatenar a Chave de Acesso.Obrig.600Rej.Rejeição: Chave de Acesso difere da existente em BD.
K14Data do evento não pode ser menor que a data de emissão da NF3e, se existir. A SEFAZ deve tolerar diferença máxima de 5 minutos pela sincronização dos servidores.Obrig.634Rej.Rejeição: A data do evento não pode ser menor que a data de emissão da NF3e.
K15Data do evento não pode ser menor que a data de autorização da NF3e, se existir. A SEFAZ deve tolerar diferença máxima de 5 minutos pela sincronização dos servidores.Obrig.637Rej.Rejeição: A data do evento não pode ser menor que a data de autorização da NF3e.
K16Data do evento não pode ser maior que a data de processamento. A SEFAZ deve tolerar diferença máxima de 5 minutos pela sincronização dos servidores.Obrig.635Rej.Rejeição: A data do evento não pode ser maior que a data do processamento.

6. Processamento das Validações Específicas

As validações específicas são definidas na parte do Manual correspondente a cada evento.

7. Final do Processamento do Evento

  • Rejeição: o Evento é descartado, com retorno do código do status do motivo da rejeição.
  • cStat=135: evento recebido e armazenado com vinculação na respectiva NF3e.
  • cStat=136: evento recebido e armazenado, mas a vinculação à NF3e fica prejudicada por inexistência da NF3e no momento do recebimento.
  • cStat=134: evento recebido e vinculado a NF3e com situação diferente de Autorizada, com retorno de alerta sobre a situação da NF3e.

O Ambiente Autorizador deverá compartilhar os eventos autorizados no Sistema de Registro de Eventos com os órgãos interessados.