Web Service - NFComRecepcaoEvento - Parte Geral
Conteúdo técnico da parte geral do Sistema de Registro de Eventos do MOC NFCom - 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 NFCom.
Processo: síncrono.
Nome Serviço: NFComRecepcaoEvento.
Método: nfcomRecepcaoEvento.
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: eventoNFCom_v9.99.xsd.
| # | Campo | Ele. | Pai | Tipo | Ocor. | Tam. | Descrição/Observação |
|---|---|---|---|---|---|---|---|
| FP01 | eventoNFCom | Raiz | - | - | - | - | TAG raiz. |
| FP02 | versao | A | FP01 | N | 1-1 | 2v2 | Versão do leiaute. |
| FP03 | infEvento | G | FP01 | - | 1-1 | - | Grupo de informações do registro de eventos. |
| FP04 | Id | ID | FP03 | C | 1-1 | 55 | Identificador da TAG a ser assinada. Regra de formação: “ID” + tpEvento + chave da NFCom + nSeqEvento. |
| FP05 | cOrgao | E | FP03 | N | 1-1 | 2 | Código do órgão de recepção do Evento. Utilizar a Tabela do IBGE estendida. |
| FP06 | tpAmb | E | FP03 | N | 1-1 | 1 | Identificação do Ambiente: 1 - Produção; 2 - Homologação. |
| FP07 | CNPJ | E | FP03 | C | 1-1 | 14 | Informar o CNPJ do autor do Evento. |
| FP08 | chNFCom | E | FP03 | C | 1-1 | 44 | Chave de Acesso da NFCom vinculada ao Evento. |
| FP09 | dhEvento | E | FP03 | D | 1-1 | - | Data e Hora do Evento. Formato = AAAA-MM-DDTHH:MM:SS TZD. |
| FP10 | tpEvento | E | FP03 | N | 1-1 | 6 | Tipo do Evento (ver tabela de tipos de evento). |
| FP11 | nSeqEvento | E | FP03 | N | 1-1 | 1-3 | Sequencial 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. |
| FP12 | detEvento | G | FP03 | - | 1-1 | - | Informações do evento específico. |
| FP13 | versaoEvento | A | FP12 | N | 1-1 | 2v2 | Versão do leiaute específico do evento. |
| FP14 | any | E | FP12 | XML | 1-1 | - | XML do evento. Inserir neste local o XML específico do tipo de evento (cancelamento). |
| FP15 | Signature | G | FP01 | XML | 1-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: retEventoNFCom_v9.99.xsd.
| # | Campo | Ele. | Pai | Tipo | Ocor. | Tam. | Descrição/Observação |
|---|---|---|---|---|---|---|---|
| FR01 | retEventoNFCom | Raiz | - | - | - | - | TAG raiz do Resultado do Envio do Evento. |
| FR02 | versao | A | FR01 | N | 1-1 | 1-4 | Versão do leiaute. |
| FR03 | infEvento | G | FR01 | - | 1-1 | - | Grupo de informações do registro do Evento. |
| FR04 | Id | ID | FR03 | C | 0-1 | 18 | Identificador 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”. |
| FR05 | tpAmb | E | FR03 | N | 1-1 | 1 | Identificação do Ambiente: 1 - Produção; 2 - Homologação. |
| FR06 | verAplic | E | FR03 | C | 1-1 | 1-20 | Versã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. |
| FR07 | cOrgao | E | FR03 | N | 1-1 | 2 | Código da UF que registrou o Evento. |
| FR08 | cStat | E | FR03 | N | 1-1 | 3-4 | Código do status da resposta. |
| FR09 | xMotivo | E | FR03 | C | 1-1 | 1-255 | Descriçã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. | |||||||
| FR10 | chNFCom | E | FR03 | C | 0-1 | 44 | Chave de Acesso da NFCom vinculada ao evento. |
| FR11 | tpEvento | E | FR03 | N | 0-1 | 6 | Código do Tipo do Evento. |
| FR12 | xEvento | E | FR03 | C | 0-1 | 5-60 | Descrição do Evento. |
| FR13 | nSeqEvento | E | FR03 | N | 0-1 | 1-3 | Sequencial 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. |
| FR14 | dhRegEvento | E | FR03 | D | 0-1 | - | Data e Hora do Evento. Formato = AAAA-MM-DDTHH:MM:SS TZD. |
| FR15 | nProt | E | FR15 | N | 0-1 | 16 | Número do protocolo de registro do evento. |
| FR16 | Signature | G | FR01 | XML | 0-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 NFCom. 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
| Grupo | Descrição |
|---|---|
| A | Validação do Certificado de Transmissão (protocolo TLS). |
| B | Validação Inicial da Mensagem no Web Service. |
| C | Validação da Área de Dados da mensagem. |
| D | Validações do Certificado de Assinatura. |
| E | Validações da Assinatura Digital. |
5. Validação das Regras de Negócio do Serviço de Registro de Eventos
| # | Regra de Validação | Aplic. | cStat | Efeito | Mensagem |
|---|---|---|---|---|---|
| K01 | Tipo do ambiente informado difere do ambiente do Web Service. | Obrig. | 252 | Rej. | Rejeição: Ambiente informado diverge do Ambiente de recebimento. |
| K02 | Verificar se o código do órgão de recepção do Evento diverge do solicitado. | Obrig. | 226 | Rej. | Rejeição: Código da UF do Emitente diverge da UF autorizadora. |
| K03 | Validar CNPJ do autor do evento (DV ou zeros). | Obrig. | 627 | Rej. | Rejeição: CNPJ do autor do evento inválido. |
| K04 | Validar se o atributo Id corresponde à concatenação dos campos do evento (“ID” + tpEvento + chNFCom + nSeqEvento). | Obrig. | 628 | Rej. | Rejeição: Erro Atributo ID do evento não corresponde à concatenação dos campos (“ID” + tpEvento + chNFCom + nSeqEvento). |
| K05 | Verificar se o tpEvento é válido. | Obrig. | 629 | Rej. | Rejeição: O tpEvento informado inválido. |
| K06 | Verificar Schema da parte específica do Evento. Observação: utilizar o tpEvento + o atributo versaoEvento para identificar qual schema deve ser validado. | Obrig. | 630 | Rej. | Rejeição: Falha no Schema XML específico para o evento. |
| K07 | Validar chave de acesso da NFCom. Retornar o motivo da rejeição: CNPJ zerado ou inválido, Ano < 2021 ou maior que o atual, Mês inválido (0 ou > 12), Modelo diferente de 62, Número zerado, Tipo de emissão inválido, UF inválida ou DV inválido. | Obrig. | 236 | Rej. | Rejeição: Chave de Acesso inválida [Motivo: XXXXXXXXX]. |
| K08 | Site de autorização da chave de acesso da NFCom difere do Site de Recebimento. | Obrig. | 418 | Rej. | Rejeição: Site de autorização inválido. |
| K09 | Verificar duplicidade do evento (cOrgao + tpEvento + chNFCom + nSeqEvento). | Obrig. | 631 | Rej. | Rejeição: Duplicidade de evento [nProt:999999999999999][dhRegEvento: AAAA-MM-DDTHH:MM:SS TZD]. |
| K10 | Se evento do emissor, verificar se o CNPJ do Autor difere do CNPJ da chave de acesso da NFCom. | Obrig. | 632 | Rej. | Rejeição: O autor do evento diverge do emissor da NFCom. |
| K11 | Se evento do Fisco/Outros órgãos, verificar se o CNPJ do Autor consta da tabela de órgãos autorizados a gerar evento. | Obrig. | 633 | Rej. | Rejeição: O autor do evento não é um órgão autorizado a gerar o evento. |
| K12 | Se o evento exige NFCom, acessar o BD NFCom (Chave: CNPJ Emit, Modelo, Série, Nº) e verificar se a NFCom não existe. Observação: esta validação considera o ambiente de autorização do DF-e (nSiteAutoriz). | Obrig. | 217 | Rej. | Rejeição: NFCom não consta na base de dados da SEFAZ. |
| K13 | Se existir a NFCom, 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. | 600 | Rej. | Rejeição: Chave de Acesso difere da existente em BD. |
| K14 | Data do evento não pode ser menor que a data de emissão da NFCom, se existir. A SEFAZ deve tolerar diferença máxima de 5 minutos pela sincronização dos servidores. | Obrig. | 634 | Rej. | Rejeição: A data do evento não pode ser menor que a data de emissão da NFCom. |
| K15 | Data do evento não pode ser menor que a data de autorização da NFCom, se existir. A SEFAZ deve tolerar diferença máxima de 5 minutos pela sincronização dos servidores. | Obrig. | 637 | Rej. | Rejeição: A data do evento não pode ser menor que a data de autorização da NFCom. |
| K16 | Data 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. | 635 | Rej. | 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 NFCom.
- cStat=136: evento recebido e armazenado, mas a vinculação à NFCom fica prejudicada por inexistência da NFCom no momento do recebimento.
- cStat=134: evento recebido e vinculado a NFCom com situação diferente de Autorizada, com retorno de alerta sobre a situação da NFCom.
O Ambiente Autorizador deverá compartilhar os eventos autorizados no Sistema de Registro de Eventos com os órgãos interessados.