Eventos Específicos do CT-e

Leiautes e regras dos eventos específicos do CT-e.

1. Visão Geral do Serviço

Regras específicas dos eventos previstos para os documentos do projeto CT-e.

Item	Especificação
Serviço	CTeRecepcaoEvento.
Escopo	Parte específica de cada tipo de evento.
Assinatura	Evento assinado conforme o padrão do projeto.

2. EPEC

2.1. Evento Prévio de Emissão em Contingência (EPEC)

Função: evento destinado ao atendimento de solicitações de emissão em contingência de CTe.

Autor do Evento: O autor do evento é o emissor do CTe. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CTe.

Modelo: CTe de Transporte de Cargas (modelo 57)

Código do Tipo de Evento: 110113 (Este evento não exige CTe autorizado)

Schema XML: evEPECCTe_v9.99.xsd

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
IP01	evEPECCTe	G	-	-	1-1	-	Schema XML de validação do evento EPEC
IP02	descEvento	E	IP01	C	1-1	4	Descrição do Evento - “EPEC”
IP04	xJust	E	IP01	C	1-1	15-255	Informar a justificativa da entrada em contingência
IP05	vICMS	E	IP01	N	1-1	13,2	Valor do ICMS: vICMS, vICMSRet ou vICMSOutraUF
IP06	vICMSST	E	IP01	N	0-1	13,2	Valor do ICMS ST
IP07	vTPrest	E	IP01	N	1-1	13,2	Valor Total da Prestação do Serviço
IP08	vCarga	E	IP01	N	1-1	13,2	Valor Total da carga
IP09	Toma4	G	IP01	-	1-1	-	Grupo de informações do tomador
IP10	Toma	E	IP09	N	1-1	1	Tipo de tomador do serviço, preencher com: 0-Remetente; 1-Expedidor; 2-Recebedor; 3-Destinatário; 4-Outro
IP11	UF	E	IP09	C	1-1	2	UF do Tomador do Serviço
IP12	CNPJ	CE	IP09	N	1-1	14	CNPJ do Tomador
IP13	CPF	CE	IP09	N	1-1	11	CPF do Tomador
IP14	IE	E	IP09	C	0-1	0-14	Informar a IE do tomador ou ISENTO se tomador é contribuinte do ICMS isento de inscrição no cadastro de contribuintes do ICMS. Caso o tomador não seja contribuinte do ICMS não informar o conteúdo.
IP15	modal	E	IP01	N	1-1	2	Modal de transporte, preencher com: 01-Rodoviário; 02-Aéreo; 03-Aquaviário; 04-Ferroviário; 05-Dutoviário; 06-Multimodal;
IP16	UFIni	E	IP01	C	1-1	UF de início da prestação
IP17	UFFIm	E	IP01	C	1-1	2	UF de fim da prestação
IP18	tpCTe	E	IP01	C	1-1	Tipo do CTe, informar obrigatoriamente CTe do	Tipo Normal = 0
IP19	dhEmi	E	IP01	D	1-1	Data e hora de emissão do CTe

2.1.1. Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic.	cStat	Efeito	Mensagem
O01	Verificar se o nSeqEvento é maior que o valor permitido (=1)	Obrig.	636	Rej.	Rejeição: O número sequencial do evento é maior que o permitido
O02	Verificar se ambiente de autorização é Normal. OBS: Eventos EPEC somente serão aceitos em SVC.	Obrig.	653	Rej.	Rejeição: Tipo de evento não é permitido em ambiente de autorização Normal
O03	Verificar se tipo de emissão da chave de acesso é EPEC (tpEmis=4)	Obrig.	680	Rej.	Rejeição: Tipo de Emissão diferente de EPEC
O04	Verificar se Mês e Ano da chave de acesso são inferiores a data do Evento	Obrig.	695	Rej.	Rejeição: CTe com emissão anterior ao evento prévio (EPEC)
O05	Emitente deve estar habilitado na base de dados para emissão do CTe Observação: Se evento gerado por PAA (grupo: infPAA) verificar se o CNPJ do emitente está em situação ativa no cadastro do CNPJ MEI da RFB	Obrig.	203	Rej.	Rejeição: Emissor não habilitado para emissão do CTe
O06	Acesso BD CHAVES-SVC (Chave: UF, CNPJ Emit, Modelo, Série, Nro): - Já existe CTe com esta numeração Observação: Buscar o CTe autorizado no ambiente normal na base de chaves naturais compartilhadas para uso da SVC.	Obrig.	638	Rej.	Rejeição: Já existe CTe autorizado com esta numeração
O07	Acesso BD Eventos CTE: - Existe evento do tipo EPEC emitido há mais de 7 dias (168h) para o mesmo CNPJ Emitente sem a emissão do CTe correspondente à chave de acesso no ambiente normal de autorização. Observação: Buscar na base de chaves naturais compartilhadas para uso da SVC. Recomenda-se que a SEFAZ retorne à quantidade de EPEC pendentes e a chave da EPEC mais antiga nessa situação Considerar EPEC pendente apenas se não existir evento de Manifestação do Fisco do tipo Liberação de EPEC para a Chave de acesso informada	Obrig.	639	Rej.	Rejeição: Existe EPEC emitido há mais de 7 dias (168h) sem a emissão do CTe no ambiente normal de autorização
O08	Data/Hora de Emissão posterior à Data/Hora de Recebimento (A SEFAZ Virtual deve considerar a hora local do emissor para a validação). A SEFAZ deve tolerar uma diferença máxima de 5 minutos quando a data/hora de emissão for maior que a data de recebimento, em função da sincronização de horário de servidores. OBS: Essa Validação deve considerar o novo formato de datas UTC com indicação do timezone.	Obrig.	212	Rej.	Rejeição: Data de emissão CTe posterior a data de recebimento
O09	Se IE Tomador informado: - Validar IE do Tomador (erro no dígito de controle) Observação: Antes da validação, a IE deverá ser normalizada, na aplicação da SEFAZ, com o acréscimo de zeros não significativos previstos na definição do formato da IE se necessário. Exemplo: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve ser padronizada para 00130000019, com o acréscimo dos zeros não significativos necessários para a validação do dígito verificador.	Obrig.	448	Rej.	Rejeição: IE do tomador inválida
O10	Se IE Tomador informada: Acessar Cadastro de Contribuinte da UF (Chave: IE Tomador) (*1) - IE deve estar cadastrada	Facult.	489	Rej.	Rejeição: IE do tomador não cadastrada
O11	Se IE e CNPJ Tomador informados: Acessar Cadastro de Contribuinte da UF (Chave: IE Tomador) (*1) - IE deve estar vinculada ao CNPJ	Facult.	490	Rej.	Rejeição: IE do tomador não vinculada ao CNPJ
O12	Se IE do tomador for “ISENTO” ou não informada, acessar o Cadastro de Contribuinte da UF e verificar se o tomador possui IE ativa na UF.	Facult.	719	Rej.	Rejeição: IE do Tomador não informada

2.1.2. Final do Processamento

Se o evento EPEC for homologado o status de retorno deverá ser cStat=136.

Não existirá cancelamento de eventos EPEC na SVC, e uma vez emitido o evento EPEC, este será compartilhado com a SEFAZ Autorizadora Normal pelo Ambiente Nacional.

Caso o contribuinte necessite cancelar uma operação emitida por engano em contingência EPEC na SVC, deverá primeiro autorizar o CTe (com tpEmis=4) na SEFAZ Autorizadora Normal e, logo em seguida, efetuar o seu cancelamento.

O Fisco poderá liberar uma EPEC de sua conciliação através do evento de Manifestação do Fisco do tipo “Liberação de EPEC”.

3. Cancelamento

3.1. Evento de Cancelamento

Função: evento destinado ao atendimento de solicitações de cancelamento de CTe, CTeOS e GTVe.

Autor do Evento: O autor do evento é o emissor do CTe. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CTe.

Modelo: CTe de Transporte de Cargas (modelo 57), Outros Serviços (modelo 67) e GTVe (modelo 64)

Código do Tipo de Evento: 110111 (Este evento exige CTe, CTeOS ou GTVe autorizada)

Schema XML: evCancCTe_v9.99.xsd

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
IP01	evCancCTe	G	-	-	-	-	TAG raiz
IP02	descEvento	E	IP01	C	1-1	12	Descrição do Evento: ‘Cancelamento’
IP03	nProt	E	IP01	N	1-1	15	Informar o número do protocolo de autorização do CTe a ser cancelado
IP04	xJust	E	IP01	C	1-1	1-	Informar a justificativa do cancelamento

3.1.1. Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic.	cStat	Efeito	Mensagem
O01	Verificar se o nSeqEvento é maior que o valor permitido (=1)	Obrig.	636	Rej.	Rejeição: O número sequencial do evento é maior que o permitido
O02	Emitente deve estar habilitado na base de dados para emissão do CTe Exceção: Esta regra não será aplicada quando a forma de emissão do CTe (tpEmis) for Regime Especial da Nota Fiscal Fácil (3) Observação: Se evento gerado por PAA (grupo: infPAA) verificar se o CNPJ do emitente está em situação ativa no cadastro do CNPJ MEI da RFB	Obrig.	203	Rej.	Rejeição: Emissor não habilitado para emissão do CTe
O03	Verificar Situação Fiscal irregular do Emitente Exceção: Esta regra não será aplicada quando a forma de emissão do CTe (tpEmis) for Regime Especial da Nota Fiscal Fácil (3)	Obrig.	240	Rej.	Rejeição: Irregularidade Fiscal do Emitente
O04	Verificar se CTe já está denegado Observação: Regra mantida para garantir compatibilidade com CTe antigos que possam estar na situação denegado	Obrig.	205	Rej.	Rejeição: CTe está denegado na base de dados da SEFAZ
O05	Verificar se CTe já está cancelado	Obrig.	218	Rej.	Rejeição: CTe já está cancelado na base de dados da SEFAZ [nProt:999999999999999][dhCanc: AAAA-MM- DDTHH:MM:SS TZD].
O06	Se modelo do CTe for igual a 57 (Carga) ou 67 (CTe OS): Verificar CTe autorizado há mais de 168 horas (7 dias) Observação: Exceto se existir evento de Manifestação do Fisco do tipo “Liberação do Prazo de Cancelamento”	Obrig.	220	Rej.	Rejeição: CTe autorizado há mais de 7 dias (168 horas)
O07	Se modelo for igual a 64 (GTVe): Verificar se GTVe autorizada há mais de 45 dias Observação: Exceto se existir evento de Manifestação do Fisco do tipo “Liberação do Prazo de Cancelamento”	Obrig.	876	Rej.	Rejeição: GTVe autorizada há mais de 45 dias
O08	Se tipo de emissão do CTe for EPEC (tpEmis=4): Verificar se Evento EPEC autorizado há mais de 168 horas (7 dias)	Obrig.	698	Rej.	Rejeição: Evento Prévio autorizado há mais de 7 dias (168 horas)
O09	Verificar se número do Protocolo informado difere do número do Protocolo do CTe	Obrig.	222	Rej.	Rejeição: Protocolo de Autorização de Uso difere do cadastrado
O10	Verificar se houve registro de circulação do CTe	Obrig.	219	Rej.	Rejeição: Circulação do CTe verificada
O11	Vedado o cancelamento de CTe do tipo substituição (tipo=3)	Obrig.	574	Rej.	Rejeição: Vedado o cancelamento de CTe do tipo substituição (tipo=3)
O12	Se Tipo do CTe=0 (Normal): - Vedado o cancelamento se possuir CTe de Substituição Associado	Obrig.	576	Rej.	Rejeição: Vedado o cancelamento se possuir CTe de Substituição associado
O13	- Se Tipo do CTe=0 (Normal): - Vedado o cancelamento se possuir CTe Complementar associado com Situação “Autorizado o Uso”.	Obrig.	660	Rej.	Rejeição: Vedado o cancelamento se possuir CTe complementar associado
O14	Vedado o cancelamento se possuir evento de Carta de Correção associado.	Obrig.	523	Rej.	Rejeição: Vedado cancelamento quando existir evento Carta de Correção
Q15	Vedado o cancelamento se existir evento de MDF-e autorizado para o CTe Observação: Se o MDF-e estiver cancelado deverá existir um evento de Cancelamento do MDF-e, nesse caso, o CTe poderá ser cancelado.	Obrig.	528	Rej.	Rejeição: Vedado cancelamento se exitir MDF-e autorizado para o CTe
Q16	Vedado o cancelamento se existir evento de Comprovante de entrega em situação autorizado para o CTe Observação: Eventos de comprovante de entrega podem ser cancelados pelo emitente, portanto deve-se considerar apenas os autorizados	Obrig.	862	Rej.	Rejeição: Vedado o cancelamento quando houver evento de Comprovante de Entrega associado
Q17	Vedado o cancelamento se existir evento de Comprovante de entrega em situação autorizado para o CTe Observação: Eventos de comprovante de entrega podem ser cancelados pelo emitente, portanto deve-se considerar apenas os autorizados	Obrig.	862	Rej.	Rejeição: Vedado o cancelamento quando houver evento de Comprovante de Entrega associado
Q18	Se o modelo do CT-e for 64 (GTV-e), é vedado o cancelamento se existir evento de CT-e OS Autorizado para a GTV-e, salvo quando houver o correspondente evento de CT-e OS Cancelado.	Obrig.	888	Rej.	Rejeição: Cancelamento não permitido para GTV-e com CT-e OS Autorizado

3.1.2. Final do Processamento

Se o evento de cancelamento for homologado, a situação do CTe para efeito de consulta situação passará para “101 – Cancelamento homologado” e o retorno do status do evento será cStat=135.

3.2. Evento de Registros do Multimodal

Função: Evento destinado a vincular informações dos serviços prestados ao CTe multimodal. Observa-se que, caso seja emitido um CTe já vinculado ao CTe multimodal, não é necessário informá-lo por este evento.

Autor do Evento: O autor do evento é o emissor do CTe multimodal. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CTe.

Modelo: CTe de Transporte de Cargas (modelo 57)

Código do Tipo de Evento: 110160 (Este evento exige CTe multimodal autorizado)

Schema XML: evRegMultimodal_v9.99.xsd

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
IP01	evRegMultimodal	G	-	-	-	-	TAG raiz
IP02	descEvento	E	IP01	C	1-1	19	Descrição do Evento: ‘Registro Multimodal’
IP03	xRegistro	E	IP01	C	1-1	15-	Informações sobre o tipo de documento utilizado
1000	e ressalvas, se for o caso, conforme Lei 9611, de						19 de fevereiro de 1998 (Texto Livre)
IP04	nDoc	E	IP01	C	0-1	1-44	Número do documento lançado no CTe multimodal

3.2.1. Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic	cStat	Efeito	Mensagem
O01	Verificar se o nSeqEvento é maior que o	Obrig.	636	Rej.	Rejeição: O número sequencial do evento é maior valor permitido (1-20) que o permitido
O02	Verificar se o CTe é multimodal	Obrig.	679	Rej.	Rejeição: O modal do CTe deve ser Multimodal para Evento Registros do Multimodal
O03	Verificar se CTe já está denegado	Obrig.	205	Rej.	Rejeição: CTe está denegado na base de dados da SEFAZ Observação: Regra mantida para garantir compatibilidade com CTe antigos que possam estar na situação denegado
O04	Verificar se CTe já está cancelado	Obrig.	218	Rej.	Rejeição: CTe já está cancelado na base de dados da SEFAZ [nProt:999999999999999][dhCanc: AAAA-MM- DDTHH:MM:SS TZD].

4. Registro Multimodal e Carta de Correção

Restrição: Os pedidos de cancelamento na modalidade SVC somente poderão afetar documentos autorizados em contingência pela correspondente SVC-[SP/RS].

O Fisco poderá liberar o cancelamento fora de prazo através do evento de Manifestação do Fisco do tipo “Liberação do Prazo de Cancelamento”

4.0.1. Final do Processamento

Se o evento de cancelamento for homologado, a situação do CTe para efeito de consulta situação passará para “101 – Cancelamento homologado” e o retorno do status do evento será cStat=135.

4.1. Evento de Registros do Multimodal

Autor do Evento: O autor do evento é o emissor do CTe multimodal. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CTe.

Modelo: CTe de Transporte de Cargas (modelo 57)

Código do Tipo de Evento: 110160 (Este evento exige CTe multimodal autorizado)

Schema XML: evRegMultimodal_v9.99.xsd

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
IP01	evRegMultimodal	G	-	-	-	-	TAG raiz
IP02	descEvento	E	IP01	C	1-1	19	Descrição do Evento: ‘Registro Multimodal’
IP03	xRegistro	E	IP01	C	1-1	15-	Informações sobre o tipo de documento utilizado
1000	e ressalvas, se for o caso, conforme Lei 9611, de						19 de fevereiro de 1998 (Texto Livre)
IP04	nDoc	E	IP01	C	0-1	1-44	Número do documento lançado no CTe multimodal

4.1.1. Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic	cStat	Efeito	Mensagem
O01	Verificar se o nSeqEvento é maior que o	Obrig.	636	Rej.	Rejeição: O número sequencial do evento é maior valor permitido (1-20) que o permitido
O02	Verificar se o CTe é multimodal	Obrig.	679	Rej.	Rejeição: O modal do CTe deve ser Multimodal para Evento Registros do Multimodal
O03	Verificar se CTe já está denegado	Obrig.	205	Rej.	Rejeição: CTe está denegado na base de dados da SEFAZ Observação: Regra mantida para garantir compatibilidade com CTe antigos que possam estar na situação denegado
O04	Verificar se CTe já está cancelado	Obrig.	218	Rej.	Rejeição: CTe já está cancelado na base de dados da SEFAZ [nProt:999999999999999][dhCanc: AAAA-MM- DDTHH:MM:SS TZD].
O05	Verificar se CTe possui CTe de substituição	Obrig.	664	Rej.	Rejeição: Evento não permitido para CTe associado Substituído

4.1.2. Final do Processamento

Os registros de multimodal não serão sobrepostos, podendo o operador OTM acrescentar novas ocorrências à medida que for preciso.

Se o evento de Registros do Multimodal for homologado o status de retorno deverá ser cStat=135.

4.2. Evento Carta de Correção eletrônica

Função: evento com objetivo de corrigir as informações do CTe.

O evento será utilizado pelo contribuinte e o alcance das alterações permitidas é definido no art. 58-B do CONVENIO SINIEF 06/89, que transcrevemos a seguir:

“Art. 58-B Fica permitida a utilização de carta de correção, para regularização de erro ocorrido na emissão de documentos fiscais relativos à prestação de serviço de transporte, desde que o erro não esteja relacionado com:

I - As variáveis que determinam o valor do imposto tais como: base de cálculo, alíquota, diferença de preço, quantidade, valor da prestação;

II - A correção de dados cadastrais que implique mudança do emitente, tomador, remetente ou do destinatário;

III - a data de emissão ou de saída”

Autor do Evento: O autor do evento é o emissor do CTe multimodal. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CTe.

Modelo: CTe de Transporte de Cargas (modelo 57) e Outros Serviços (modelo 67)

Código do Tipo de Evento: 110110 (Este evento exige CTe autorizado)

Schema XML: evCCeCTe_v9.99.xsd

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
IP01	evCCeCTe	G	-	-	1-1	-	Schema XML de validação do evento carta de correção 110110
IP02	descEvento	E	IP01	C	1-1	17	“Carta de Correção” ou “Carta de Correcao”
IP03	infCorrecao	G	IP01	-	1-n	-	Grupo de Informações de Correção
IP04	grupoAlterado	E	IP03	C	1-1	1-20	Indicar o grupo de informações que pertence o campoAlterado. Ex: ide
IP05	campoAlterado	E	IP03	C	1-1	1-20	Nome do campo modificado do CTe Original.
IP06	valorAlterado	E	IP03	C	1-1	1-	Valor correspondente à alteração.
IP07	nroItemAlterado	E	IP03	N	0-1	-	Preencher com o índice do item alterado caso a alteração ocorra em uma lista. OBS: O índice inicia sempre em 1
IP08	xCondUso	E	IP01	C	1-1	-	Condições de uso da Carta de Correção, informar a literal: “A Carta de Correção é disciplinada pelo Art. 58- B do CONVÊNIO/SINIEF 06/89: Fica permitida a utilização de carta de correção, para regularização de erro ocorrido na emissão de documentos fiscais relativos à prestação de serviço de transporte, desde que o erro não esteja relacionado com: I - as variáveis que determinam o valor do imposto tais como: base de cálculo, alíquota, diferença de preço, quantidade, valor da prestação;II - a correção de dados cadastrais que implique mudança do emitente, tomador, remetente ou do destinatário;III - a data de emissão ou de saída.” (Texto com acentuação) Ou “A Carta de Correcao e disciplinada pelo Art. 58- B do CONVENIO/SINIEF 06/89: Fica permitida a utilizacao de carta de correcao, para regularizacao de erro ocorrido na emissao de documentos fiscais relativos a prestacao de servico de transporte, desde que o erro nao esteja relacionado com: I - as variaveis que determinam o valor do imposto tais como: base de calculo, aliquota, diferenca de preco, quantidade, valor da prestacao;II - a correcao de dados cadastrais que implique mudanca do emitente, tomador, remetente ou do destinatario;III - a data de emissao ou de saida.” (Texto sem acentuação)

4.2.1. Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic	cStat	Efeito	Mensagem
O01	Verificar se o nSeqEvento é maior que o valor	Obrig.	636	Rej.	Rejeição: O número sequencial do evento é permitido (1-20) maior que o permitido
O02	Verificar se grupoAlterado e campoAlterado	Obrig.	681	Rej.	Rejeição: Informação não pode ser alterada por podem ser indicados em uma carta de correção. carta de correção Ver relação de campos que não podem ser corrigidos no item 13 deste MOC.
O03	Se informado o campo nroItemAlterado,	Obrig.	522	Rej.	Rejeição: Nro Item Alterado inválido. Preencher Verificar se foi preenchido com valor numérico com valor numérico (01 – 99) compreendido entre 01 e 99
O04	Verificar se tag informada em campoAlterado	Facult.	525	Rej.	Rejeição: Carta de correção inválida existe no layout e se pertence ao grupoAlterado (campo/grupo “xxxx” informado não existe no indicado na carta de correção schema do CTe ou não existe no grupo OBS: Validar layout conforme o modelo do CTe informado) (57 ou 67)
O05	Verificar se CTe já está denegado	Obrig.	205	Rej.	Rejeição: CTe está denegado na base de dados da SEFAZ Observação: Regra mantida para garantir compatibilidade com CTe antigos que possam estar na situação denegado
O06	Verificar se CTe já está cancelado	Obrig.	218	Rej.	Rejeição: CTe já está cancelado na base de dados da SEFAZ [nProt:999999999999999][dhCanc: AAAA-MM- DDTHH:MM:SS TZD].
O07	Verificar se CTe possui CTe de substituição	Obrig.	664	Rej.	Rejeição: Evento não permitido para CTe associado Substituído

4.2.2. Final do Processamento

Se o evento Carta de Correção for homologado o status de retorno deverá ser cStat=135.

5. Prestação em Desacordo

5.1. Evento Prestação de Serviço em Desacordo

Função: Evento para que o tomador possa informar ao fisco que o documento CTe que o relaciona está em desacordo com a prestação de serviço.

Autor do Evento: O autor do evento é o tomador do serviço indicado no CTe. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do tomador do serviço do CTe, ou o CNPJ da SEFAZ Virtual RS para tomadores pessoa física identificados por login na plataforma gov.br.

Modelo: CTe de Transporte de Cargas (modelo 57) e Outros Serviços (67)

Código do Tipo de Evento: 610110 (Este evento exige CTe autorizado)

Schema XML: evPrestDesacordo_v9.99.xsd

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
IP01	evPrestDesacordo	G	-	-	-	-	TAG raiz
IP02	descEvento	E	IP01	C	1-1	33	Descrição do Evento: ‘Prestação do Serviço em Desacordo’ ou ‘Prestacao do Servico em Desacordo’
IP03	indDesacordoOper	E	IP01	C	1-1	1	Indicador de prestação do serviço em desacordo
IP04	xObs	E	IP01	C	0-1	15-	Observações do tomador

5.1.1. Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic	cStat	Efeito	Mensagem
O01	Verificar se o nSeqEvento é maior que o valor	Obrig.	636	Rej.	Rejeição: O número sequencial do evento permitido (1-20) é maior que o permitido
O02	Verificar se CTe já está denegado	Obrig.	205	Rej.	Rejeição: CTe está denegado na base de dados da SEFAZ Observação: Regra mantida para garantir compatibilidade com CTe antigos que possam estar na situação denegado
O03	Verificar se CTe já está cancelado	Obrig.	218	Rej.	Rejeição: CTe já está cancelado na base de dados da SEFAZ [nProt:999999999999999][dhCanc: AAAA- MM-DDTHH:MM:SS TZD].
O04	Verificar se CTe possui CTe de substituição	Obrig.	664	Rej.	Rejeição: Evento não permitido para CTe associado Substituído
O05	Verificar se o CTe está com data de autorização há	Obrig.	787	Rej.	Rejeição: Data do evento de Prestação do mais de 45 dias Serviço em desacordo deve ocorrer em até 45 dias da autorização do CTe

5.1.2. Final do Processamento

Se o evento de Prestação do Serviço em Desacordo for homologado o status de retorno deverá ser cStat=135.

5.2. Evento Cancelamento do Evento Prestação de Serviço em Desacordo

Função: Evento para que o tomador possa cancelar o evento de prestação de serviço em desacordo gerado indevidamente em um CTe

Autor do Evento: O autor do evento é o tomador do serviço indicado no CTe que registrou um evento de Prestação em Desacordo. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do tomador do serviço do CTe, ou o CNPJ da SEFAZ Virtual RS para tomadores pessoa física identificados por login na plataforma gov.br.

Modelo: CTe de Transporte de Cargas (modelo 57) e Outros Serviços (67)

Código do Tipo de Evento: 610111 (Este evento exige CTe autorizado)

Schema XML: evCancPrestDesacordo_v9.99.xsd

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
IP01	evPrestDesacordo	G	-	-	-	-	TAG raiz
IP02	descEvento	E	IP01	C	1-1	46	Descrição do Evento: ‘Cancelamento Prestação do Serviço em Desacordo’ ou ‘Prestacao do Servico em Desacordo’
IP04	nProtEvPrestDes	E	IP01	N	1-1	15	Informar o número do protocolo de autorização do evento de prestação de serviço em desacordo que será cancelado

5.2.1. Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic	cStat	Efeito	Mensagem
O01	Verificar se o nSeqEvento é maior que o valor	Obrig.	636	Rej.	Rejeição: O número sequencial do evento permitido (1-20) é maior que o permitido
O02	Verificar se CTe possui CTe de substituição	Obrig.	664	Rej.	Rejeição: Evento não permitido para CTe associado Substituído
O03	Verificar se número do Protocolo do evento de	Obrig.	866	Rej.	Rejeição:Protocolo do evento a ser prestação em desacordo a ser cancelado existe cancelado não existe, não está associado para o CTe e encontra-se na situação autorizado ao CTe ou já está cancelado

5.2.2. Final do Processamento

Se o evento de Cancelamento do Evento de Prestação do Serviço em Desacordo for homologado o status de retorno deverá ser cStat=135.

6. Comprovante de Entrega

6.1. Evento Comprovante de Entrega do CTe

Função: Evento para indicar a efetivação da entrega da carga pelo transportador.

Autor do Evento: O autor do evento é o emissor do CTe. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CTe.

Modelo: CTe de Transporte de Cargas (modelo 57)

Código do Tipo de Evento: 110180 (Este evento exige CTe autorizado)

Schema XML: evCECTe_v9.99.xsd

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
IP01	evCECTe	G	-	-	-	-	TAG raiz
IP02	descEvento	E	IP01	C	1-1	30	Descrição do Evento: “Comprovante de Entrega do CTe”
IP03	nProt	E	IP01	N	1-1	15	Informar o número do protocolo de autorização do CTe
IP04	dhEntrega	E	IP01	D	1-1	-	Data e Hora da Conclusão da Entrega Formato = AAAA-MM-DDTHH:MM:SS TZD
IP05	nDoc	E	IP01	C	1-1	2-20	Documento de identificação da pessoa que recebeu a entrega
IP06	xNome	E	IP01	C	1-1	2-60	Nome da pessoa que recebeu a entrega
IP07	latitude	E	IP01	N	0-1	[-]2,6	Latitude do ponto da entrega (detectado pelo equipamento do transportador, exemplo: PDA, tablet, celular)
IP08	longitude	E	IP01	N	0-1	[-]3,6	Longitude do ponto da entrega (detectado pelo equipamento do transportador, exemplo: PDA, tablet, celular)
IP09	hashEntrega	E	IP01	C	1-1	28	Hash (SHA1) no formato Base64 resultante da concatenação: Chave de acesso do CTe + Base64 da imagem capturada da entrega (Exemplo: imagem capturada da assinatura eletrônica, digital do recebedor, foto, etc) Nota 1: A critério do autor deste evento, este campo pode ser utilizado como índice para acesso as informações do Comprovante de entrega. Nota 2: A SEFAZ não tem nenhum controle sobre a informação deste campo. Observação: 28 caracteres são representados no schema como 20 bytes do tipo base64Binary
IP10	dhHashEntrega	E	IP01	D	1-1	-	Data e hora da geração do hash da entrega Formato = AAAA-MM-DDTHH:MM:SS TZD
IP11	infEntrega	G	IP01	-	0-2000	-	Grupo de informações das entregas. Informar apenas para CTe com tipo de serviço Normal
IP12	chNFe	E	IP11	C	1-1	44	Chave de acesso da NFe que está sendo entregue

6.1.1. Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic.	cStat	Efeito	Mensagem
O01	Verificar se o nSeqEvento é maior que o valor permitido (1-999)	Obrig.	636	Rej.	Rejeição: O número sequencial do evento é maior que o permitido
O02	Verificar se CTe já está denegado Observação: Regra mantida para garantir compatibilidade com CTe antigos que possam estar na situação denegado	Obrig.	205	Rej.	Rejeição: CTe está denegado na base de dados da SEFAZ
O03	Verificar se CTe já está cancelado	Obrig.	218	Rej.	Rejeição: CTe já está cancelado na base de dados da SEFAZ [nProt:999999999999999][dhCanc: AAAA-MM-DDTHH:MM:SS TZD].
O04	Verificar se número do Protocolo informado difere do número do Protocolo do CTe	Obrig.	222	Rej.	Rejeição: Protocolo de Autorização de Uso difere do cadastrado
O05	Rejeitar se CTe for do tipo Complemento de Valores	Obrig.	869	Rej.	Rejeição: Evento não permitido para CTe Complementar
O06	Rejeitar se a data/hora da entrega for inferior a data de emissão do CTe ou superior a data/hora atual	Obrig.	872	Rej.	Rejeição: Data e hora da entrega inválida
O07	Rejeitar se a data/hora do hash do comprovante da entrega for inferior a data de emissão do CTe ou superior a data/hora atual	Obrig.	873	Rej.	Rejeição: Data e hora do hash do comprovante de entrega inválida
O08	Se o CTe não possuir indicador de CTe globalizado informado: Rejeitar se existir outro evento de Comprovante de Entrega na situação autorizado (não possui cancelamento do comprovante de entrega) para este CTe	Obrig.	870	Rej.	Rejeição: Não é permitido mais de um comprovante de entrega para CTe (exceto CTe Globalizado)
O09	Se CTe for do tipo de serviço Normal e possuir preenchido o grupo infNFe: O grupo infEntrega deve ser informado	Obrig.	865	Rej.	Rejeição: Comprovante de entrega deve relacionar NFe para CTe de tipo de serviço Normal
O10	Se o CTe for do tipo de serviço diferente de Normal O grupo infEntrega não deve ser informado Exceção: Esta regra não será aplicada quando a forma de emissão do CTe (tpEmis) for Regime Especial da Nota Fiscal Fácil (3) e o CTe for de Subcontratação	Obrig.	871	Rej.	Rejeição: Comprovante de entrega não pode informar NFe para CTe de tipo de serviço diferente de Normal
O11	Se informada NFe, para cada uma das NFe relacionadas: - Validar chave de acesso da NFe Retornar a primeira chave inválida e o motivo da rejeição da Chave de Acesso: CNPJ / CPF zerado ou inválido, Ano < 2005 ou maior que 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) [chNFe: 99999999999999999999999999999999999999999999] [Motivo: XXXXXXXXXXXX]	Obrig.	860	Rej.	Rejeição: Chave de acesso da NFe indicada no comprovante de entrega inválida
O12	Se informada NFe, para cada uma das NFe relacionadas: - Acessar BD CHAVES NFE (Chave: UF, CNPJ/CPF Emit, Modelo, Série, Nro): - A NFe deve existir Exceção: NFe em contingência fica dispensada dessa validação (verificar tpEmis da chave de acesso da NFe) Retornar a primeira chave de NFe inexistente	Facult.	661	Rej.	Rejeição: NFe inexistente na base de dados da SEFAZ
O13	Se informada NFe, para cada uma das NFe relacionadas: - Acessar BD CHAVES NFE (Chave: UF, CNPJ/CPF Emit, Modelo, Série, Nro): - A NFe não pode existir com diferença de chave de acesso Retornar a primeira chave de NFe com chave divergente	Facult.	662	Rej.	Rejeição: NFe com diferença de Chave de Acesso
O14	Se informada NFe, para cada uma das NFe relacionadas: - Acessar BD CHAVES NFE (Chave: UF, CNPJ/CPF Emit, Modelo, Série, Nro): - A NFe não pode estar cancelada ou denegada Retornar a primeira chave de NFe com situação inválida	Facult.	652	Rej.	Rejeição: NFe não pode estar cancelada ou denegada
O15	Se informada NFe, para cada uma das NFe relacionadas: A NFe não pode estar duplicada no grupo infEntrega Retornar a primeira chave de NFe em duplicidade no grupo entrega	Facult.	861	Rej.	Rejeição: NFe em duplicidade no evento comprovante de entrega
O16	Se informada NFe, para cada uma das NFe relacionadas: A NFe não pode estar vinculada em outro evento de Comprovante de Entrega para o mesmo CTe na situação autorizado (não possui cancelamento do comprovante de entrega) Retornar a primeira chave de NFe com evento pré-existente	Facult.	863	Rej.	Rejeição: NFe já possui comprovante de entrega para este CTe
O17	Se informada NFe, para cada NFe relacionada, ela deve constar nos documentos transportados do CT-e. Retornar a primeira chave que não estiver relacionada.	Facult.	864	Rej.	Rejeição: NFe não possui relação com este CT-e

6.1.2. Final do Processamento

Se o evento de Comprovante de entrega do CTe for homologado o status de retorno deverá ser cStat=135.

Este evento deverá ser propagado nas notas fiscais eletrônicas relacionadas de forma automática, conforme Boletim Técnico do projeto NFe.

6.2. Evento Cancelamento Comprovante de Entrega do CTe

Função: Evento para indicar o cancelamento de um evento da entrega da carga pelo transportador nas ocasiões em que ocorrer erro na geração do evento de entrega.

Autor do Evento: O autor do evento é o emissor do CTe. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CTe.

Modelo: CTe de Transporte de Cargas (modelo 57)

Código do Tipo de Evento: 110181 (Este evento exige CTe autorizado)

Schema XML: evCancCECTe_v9.99.xsd

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
IP01	evCancCECTe	G	-	-	-	-	TAG raiz
IP02	descEvento	E	IP01	C	1-1	46	Descrição do Evento: “Cancelamento do Comprovante de Entrega do CTe”
IP03	nProt	E	IP01	N	1-1	15	Informar o número do protocolo de autorização do CTe
IP04	nProtCE	E	IP01	N	1-1	15	Informar o número do protocolo de autorização do evento de Comprovante de entrega que será cancelado

6.2.1. Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic	cStat	Efeito
O01	Verificar se o nSeqEvento é maior que o valor permitido	Obrig.	636	Rej. Rejeição: O número sequencial do (1-999) evento é maior que o permitido
O02	Verificar se número do Protocolo informado difere do	Obrig.	222	Rej. Rejeição: Protocolo de Autorização de número do Protocolo do CTe Uso difere do cadastrado
O03	Verificar se número do Protocolo do evento de	Obrig.	866	Rej. Rejeição:Protocolo do evento a ser comprovante de entrega a ser cancelado existe para o cancelado não existe, não está CTe e encontra-se na situação autorizado associado ao CTe ou já está cancelado

6.2.2. Final do Processamento

Se o evento de Cancelamento do Comprovante de entrega do CTe for homologado o status de retorno deverá ser cStat=135.

Este evento deverá ser propagado nas notas fiscais eletrônicas informadas no evento Comprovante de Entrega cancelado, conforme Boletim Técnico do projeto NFe.

7. Insucesso da Entrega

Projeto Conhecimento de

Nota Técnica 2023.002

Evento Insucesso da Entrega

Versão 1.01 – abril de 2023

Controle de Versões

Versão	Publicação	Descrição
1.00	03/2023	Versão inicial da NT
1.01	04/2023	Correção do código do evento de cancelamento do insucesso

Histórico de Alterações / Cronograma Versão Histórico de atualizações Implantação Implantação Homologação Produção

Novos eventos de Insucesso na Entrega 1.00
Correção do código do evento 1.01 05/2023 07/2023

7.1. Resumo

Esta Nota Técnica disponibiliza novos eventos de Insucesso da Entrega e seu cancelamento conforme disposto no Ajuste SINIEF 50/2022 de 09 de dezembro de 2022.

IMPORTANTE: Os novos eventos serão disponibilizados somente para a versão 4.00 do CTe e constam do PL_CTE_400.

7.2. Evento Insucesso na Entrega do CTe

Evento EXCLUSIVO da Versão 4.00 do CTe

Função: Evento para indicar o insucesso na entrega da carga pelo transportador.

Autor do Evento: O autor do evento é o emissor do CTe. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CTe.

Modelo: CT-e de Transporte de Cargas (modelo 57)

Código do Tipo de Evento: 110190 (Este evento exige CT-e autorizado)

Schema XML: evIECTe_v9.99.xsd

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
IP01	evIECTe	G	-	-	-	-	TAG raiz
IP02	descEvento	E	IP01	C	1-1	28	Descrição do Evento: “Insucesso na Entrega do CT-e”
IP03	nProt	E	IP01	N	1-1	15	Informar o número do protocolo de autorização do CT-e
IP04	dhTentativaEntrega	E	IP01	D	1-1	-	Data e Hora da Tentativa da Entrega Formato = AAAA-MM-DDTHH:MM:SS TZD
IP05	nTentativa	E	IP01	N	0-1	3	Número da tentativa de entrega que não teve insucesso
IP06	tpMotivo	E	IP01	N	1-1	1	Motivo do insucesso: 1- Recebedor não encontrado; 2- Recusa do recebedor; 3- Endereço inexistente; 4- Outros (exige informar justificativa)
IP07	xJustMotivo	E	IP01	C	0-1	25-	Justificativa do Motivo de insucesso, informar
250	apenas para tpMotivo = 4
IP08	latitude	E	IP01	N	0-1	[-]2,6	Latitude do ponto da entrega (detectado pelo equipamento do transportador, exemplo: PDA, tablet, celular)
IP09	longitude	E	IP01	N	0-1	[-]3,6	Longitude do ponto da entrega (detectado pelo equipamento do transportador, exemplo: PDA, tablet, celular)
IP10	hashTentativaEntrega	E	IP01	C	1-1	28	Hash (SHA1) no formato Base64 resultante da concatenação: Chave de acesso do CT-e + Base64 da imagem capturada na tentativa da entrega (Exemplo: imagem capturada da assinatura eletrônica, digital do recebedor, foto, etc) Nota 1: A critério do autor deste evento, este campo pode ser utilizado como índice para acesso as informações do Insucesso de entrega. Nota 2: A SEFAZ não tem nenhum controle sobre a informação deste campo. Observação: 28 caracteres são representados no schema como 20 bytes do tipo base64Binary
IP11	dhHashTentativaEntrega	E	IP01	D	1-1	-	Data e hora da geração do hash da tentativa de entrega Formato = AAAA-MM-DDTHH:MM:SS TZD
IP12	infEntrega	G	IP01	-	0-	-	Grupo de informações das NF-e que não
2000	tiveram sucesso na entrega ao Destinatário.						Informar apenas para CT-e com tipo de serviço Normal
IP13	chNFe	E	IP11	C	1-1	44	Chave de acesso da NF-e com insucesso na tentativa de entrega

Validação das Regras Específicas do Evento

Final do Processamento

Se o evento de Insucesso de entrega do CT-e for homologado o status de retorno deverá ser cStat = 135.

Este evento futuramente será propagado nas notas fiscais eletrônicas relacionadas de forma automática.

7.2.1. Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic.	cStat	Efeito	Mensagem
O01	Verificar se o nSeqEvento é maior que o valor permitido (1-999)	Obrig.	636	Rej.	Rejeição: O número sequencial do evento é maior que o permitido
O02	Verificar se CTe já está denegado Observação: Regra mantida para garantir compatibilidade com CTe antigos que possam estar na situação denegado	Obrig.	205	Rej.	Rejeição: CTe está denegado na base de dados da SEFAZ
O03	Verificar se CTe já está cancelado	Obrig.	218	Rej.	Rejeição: CTe já está cancelado na base de dados da SEFAZ [nProt:999999999999999][dhCanc: AAAA- MM-DDTHH:MM:SS TZD].
O04	Verificar se número do Protocolo informado difere do número do Protocolo do CTe	Obrig.	222	Rej.	Rejeição: Protocolo de Autorização de Uso difere do cadastrado
O05	Rejeitar se CTe for do tipo Complemento de Valores	Obrig.	869	Rej.	Rejeição: Evento não permitido para CTe Complementar
O06	Rejeitar se a data/hora da entrega for inferior a data de emissão do CTe ou superior a data/hora atual	Obrig.	918	Rej.	Rejeição: Data e hora da tentativa entrega inválida
O07	Rejeitar se a data/hora do hash do Insucesso da entrega for inferior a data de emissão do CTe ou superior a data/hora atual	Obrig.	919	Rej.	Rejeição: Data e hora do hash do Insucesso de entrega inválida
O08	Se o CTe não possuir indicador de CTe globalizado informado: Rejeitar se existir outro evento de Insucesso de Entrega na situação autorizado (não possui cancelamento do Insucesso de entrega) para este CTe	Obrig.	920	Rej.	Rejeição: Não é permitido mais de um Insucesso de entrega para CTe (exceto CTe Globalizado)
O09	Se CTe for do tipo de serviço Normal e possuir preenchido o grupo infNFe: O grupo infEntrega deve ser informado	Obrig.	921	Rej.	Rejeição: Insucesso de entrega deve relacionar NFe para CTe de tipo de serviço Normal
O10	Se o CTe for do tipo de serviço diferente de Normal O grupo infEntrega não deve ser informado Exceção: Esta regra não será aplicada quando a forma de emissão do CTe (tpEmis) for Regime Especial da Nota Fiscal Fácil (3) e o CTe for de Subcontratação	Obrig.	922	Rej.	Rejeição: Insucesso de entrega não pode informar NFe para CTe de tipo de serviço diferente de Normal
O11	Se informada NFe, para cada uma das NFe relacionadas: - Validar chave de acesso da NFe Retornar a primeira chave inválida e o motivo da rejeição da Chave de Acesso: CNPJ / CPF zerado ou inválido, Ano < 2005 ou maior que 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) [chNFe: 99999999999999999999999999999999999999999999] [Motivo: XXXXXXXXXXXX]	Obrig.	923	Rej.	Rejeição: Chave de acesso da NFe indicada no Insucesso de entrega inválida
O12	Se informada NFe, para cada NFe relacionada, acessar a base de chaves da NF-e e verificar se a nota existe. NFe emitida em contingência fica dispensada desta validação, conforme o tipo de emissão da chave.	Facult.	661	Rej.	Rejeição: NFe inexistente na base de dados da SEFAZ
O13	Se informada NFe, para cada uma das NFe relacionadas: - Acessar BD CHAVES NFE (Chave: UF, CNPJ/CPF Emit, Modelo, Série, Nro): - A NFe não pode existir com diferença de chave de acesso Retornar a primeira chave de NFe com chave divergente	Facult.	662	Rej.	Rejeição: NFe com diferença de Chave de Acesso
O14	Se informada NFe, para cada uma das NFe relacionadas: - Acessar BD CHAVES NFE (Chave: UF, CNPJ/CPF Emit, Modelo, Série, Nro): - A NFe não pode estar cancelada ou denegada Retornar a primeira chave de NFe com situação inválida	Facult.	652	Rej.	Rejeição: NFe não pode estar cancelada ou denegada
O15	Se informada NFe, para cada uma das NFe relacionadas: A NFe não pode estar duplicada no grupo infEntrega Retornar a primeira chave de NFe em duplicidade no grupo entrega	Facult.	924	Rej.	Rejeição: NFe em duplicidade no evento Insucesso de entrega
O16	Se informada NFe, ela não pode estar vinculada a outro evento autorizado de Insucesso na Entrega para o mesmo CT-e sem o respectivo cancelamento. Retornar a primeira chave com evento pré-existente.	Facult.	925	Rej.	Rejeição: NFe já possui Insucesso de entrega para este CT-e
O17	Se informada NFe, ela deve estar relacionada nos documentos transportados do CT-e. Retornar a primeira chave que não estiver relacionada.	Facult.	864	Rej.	Rejeição: NFe não possui relação com este CT-e
Q18	Se informado motivo do insucesso “Outros” (tpMotivo=4), verificar se o campo Justificativa (xJustMotivo) está informado.	Obrig.	926	Rej.	Rejeição: Justificativa do insucesso é obrigatória para motivo outros

Se o evento de Insucesso na Entrega do CT-e for homologado, o status de retorno será cStat=135. O evento poderá ser propagado às notas fiscais eletrônicas relacionadas conforme a documentação do projeto NF-e.

7.3. Evento Cancelamento do Insucesso na Entrega do CTe

Evento EXCLUSIVO da Versão 4.00 do CTe

Função: Evento para indicar o cancelamento de um evento de insucesso da entrega da carga pelo transportador nas ocasiões em que ocorrer erro na geração do evento.

Autor do Evento: O autor do evento é o emissor do CT-e. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CT-e.

Modelo: CT-e de Transporte de Cargas (modelo 57)

Código do Tipo de Evento: 110191 (Este evento exige CT-e autorizado)

Schema XML: evCancIECTe_v9.99.xsd

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
IP01	evCancIECTe	G	-	-	-	-	TAG raiz
IP02	descEvento	E	IP01	C	1-1	44	Descrição do Evento: “Cancelamento do Insucesso de Entrega do CT-e”
IP03	nProt	E	IP01	N	1-1	15	Informar o número do protocolo de autorização do CT-e
IP04	nProtIE	E	IP01	N	1-1	15	Informar o número do protocolo de autorização do evento de Insucesso de entrega que será cancelado

7.3.1. Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic.	cStat	Efeito	Mensagem
O01	Verificar se o nSeqEvento é maior que o valor permitido (1-999)	Obrig.	636	Rej.	Rejeição: O número sequencial do evento é maior que o permitido
O02	Verificar se número do Protocolo informado difere do número do Protocolo do CTe	Obrig.	222	Rej.	Rejeição: Protocolo de Autorização de Uso difere do cadastrado
O03	Verificar se número do Protocolo do evento de insucesso de entrega a ser cancelado existe para o CTe e encontra-se na situação autorizado	Obrig.	866	Rej.	Rejeição: Protocolo do evento a ser cancelado não existe, não está associado ao CTe ou já está cancelado

7.3.2. Final do Processamento

Se o evento de Cancelamento do Insucesso de entrega do CT-e for homologado o status de retorno deverá ser cStat=135.

Este evento futuramente será propagado nas notas fiscais eletrônicas informadas no evento Insucesso de Entrega cancelado.

8. Vinculação de Pagamento

A NT 2026.001 disciplina a vinculação entre o DF-e e a transação financeira, por campos do documento ou por evento. A indicação representa a expectativa de pagamento e pode ocorrer antes ou depois da autorização do CT-e.

8.1. Introdução

A vinculação entre DFe e transação financeira sujeita ao split payment é estritamente necessária para a correta apuração dos débitos do fornecedor e concessão de créditos ao adquirente. No split payment, há duas formas de o contribuinte indicar a vinculação entre o documento fiscal e a transação financeira sujeita ao split payment: i. transmitindo a chave do documento fiscal ao prestador de serviço de pagamento, no início da transação financeira; ii. informando os dados da transação financeira em campos ou evento de DFe. Esta nota técnica detalha a forma (ii), de vinculação por meio da inserção de dados da transação financeira em campos de documento fiscal ou evento. Atenção: O vínculo indicado pelo contribuinte não necessariamente representa um pagamento efetuado e liquidado. Indica uma expectativa de pagamento que pode ou não se concretizar. Por exemplo: um boleto pode ser emitido e não pago. Nas transações sujeitas ao procedimento padrão do split payment e originadas por fornecedor/recebedor, a vinculação se faz necessária antes mesmo da liquidação financeira, com o propósito de viabilizar o split payment superinteligente. Cumpre destacar que, quanto mais tempo o fornecedor/recebedor demorar para reportar o vínculo entre DFe e transação financeira, menor serão as chances de o split superinteligente ser executado. Em caso de impossibilidade de execução do split superinteligente, será executado o split inteligente offline, com posterior devolução de valores retidos a maior no prazo de 3 (três) dias úteis. São exemplos, não exaustivos, de possíveis cenários de vinculação por meio da inserção de dados da transação financeira em campos de DFe ou evento: Ex. 1. O fornecedor emite um boleto para uma empresa adquirente, antes da emissão do DFe. Uma vez que o boleto foi emitido sem chave de DFe, a vinculação fica inicialmente pendente. Após a emissão do boleto, o fornecedor emite o DFe preenchendo os campos relativos à transação financeira, viabilizando assim a vinculação.

Ex. 2. O fornecedor emite um DFe. Em seguida, o fornecedor emite QR code Pix dinâmico para a empresa adquirente, informando valores de IBS e CBS, mas sem a chave do DFe previamente emitido (nos termos do § 2º- A do Art. 32 da LC 214/2025, com redação dada pela LC 227/2026). O vínculo fica inicialmente pendente, em razão da ausência da chave DFe na transação de pagamento. Para finalmente efetivar a vinculação, o fornecedor emite evento atrelado ao DFe, com os dados do Pix dinâmico.

Ex. 3. O fornecedor emite um DFe antes do início da transação financeira. A empresa adquirente efetua o pagamento via TED informando a chave do DFe, porém comete um erro neste preenchimento, o que impede a correta vinculação entre transação financeira e DFe. A fim de resolver o problema, o fornecedor emite um evento atrelado ao DFe com os dados da transação financeira.

8.2. Informação da vinculação da transação de pagamento no DFe

Este grupo deve ser informado quando a transação de pagamento for iniciada antes da emissão do DFe, ainda que esteja pendente de pagamento ou liquidação. Aplica-se ao CT-e, CT-e OS e CT-e Simplificado.

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
#	pgtoVinc	G	infCte	-	0-1	-	Grupo de informações da vinculação com a transação de pagamento
1	pgto	E	pgtoVinc	G	1-99	-	Dados de cada pagamento previsto para o DFe
2	nPag	A	pgto	N	1-1	3	Atributo numerador único de cada ocorrência de pagamento
3	idTransacao	A	pgto	C	1-1	2-35	Identificador específico da transação financeira. O próprio schema impede sua repetição dentro do grupo.
4	tpMeioPgto	E	pgto	N	1-1	2	Código do meio de pagamento utilizado. Ver IT DFe 2026.001, que divulga os códigos aceitos conforme a tabela nacional de Meios de Pagamento da NF-e.
5	CNPJReceb	E	pgto	C	1-1	14	CNPJ completo do recebedor do pagamento. Indicar o CNPJ responsável por receber o dinheiro do adquirente; ele pode ser diferente do CNPJ do fornecedor constante no documento fiscal.
6	CNPJBasePSP	E	pgto	C	1-1	8	CNPJ-base da instituição financeira ou de pagamento utilizada pelo recebedor do pagamento.

Regras de Validação

#	Regra de Validação	Aplic.	cStat	Efeito	Mensagem
01	Se informado o grupo de vinculação com a transação de pagamento (gPgtoVinc), validar, em cada pagamento, o CNPJ do recebedor (dígito de controle, zeros e CNPJ alfanumérico). Informar na rejeição o numerador do pagamento.	Obrig.	1001	Rej.	Rejeição: CNPJ do recebedor do pagamento inválido [nPag: XXX]
02	Verificar se o código informado em tpMeioPgto é válido. Os códigos válidos são publicados no Informe Técnico DFe 2026.001 e seguem a tabela de Meios de Pagamento da NF-e.	Obrig.	1003	Rej.	Rejeição: Meio de pagamento inválido [nPag: XXX]

8.3. Evento de vinculação da transação de pagamento no DFe

Evento gerado pelo emitente para vincular uma ou mais transações financeiras a um DFe previamente autorizado. A transação pode estar iniciada e ainda pendente de pagamento ou liquidação.

Função: vinculação do pagamento do DFe. Autor: emissor do DFe. Tipo de evento: 110300. Schema: evVincPgto_v9.99.xsd.

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
#	evVincPgto	Raiz	detEvento	G	1-1	-	Schema XML de validação do evento de vinculação da transação de pagamento com o DFe - 110300
1	descEvento	E	evVincPgto	E	1-1	20	Descrição do Evento: “Vinculação Pagamento”
2	nProt	E	evVincPgto	E	1-1	15	Número do protocolo de autorização do DFe
3	pgto	E	pgtoVinc	G	1-1	-	Dados de cada pagamento previsto para o DFe
4	nPag	A	pgto	N	1-1	3	Atributo numerador único de cada ocorrência de pagamento
5	idTransacao	A	pgto	C	1-1	2-35	Identificador específico da transação financeira. O próprio schema impede sua repetição dentro do grupo.
6	tpMeioPgto	E	pgto	N	1-1	2	Código do meio de pagamento utilizado, conforme IT DFe 2026.001.
7	CNPJReceb	E	pgto	C	1-1	14	CNPJ completo do recebedor do pagamento; pode ser diferente do CNPJ do fornecedor constante no documento fiscal.
8	CNPJBasePSP	E	pgto	C	1-1	8	CNPJ-base da instituição financeira ou de pagamento utilizada pelo recebedor.

Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic.	cStat	Efeito	Mensagem
L01	Verificar se a UF da Chave de Acesso difere da UF do Web Service.	Obrig.	249	Rej.	Rejeição: UF da Chave de Acesso diverge da UF autorizadora
L02	Verificar se o nSeqEvento é maior que o valor permitido (1 a 999).	Obrig.	636	Rej.	Rejeição: O número sequencial do evento é maior que o permitido
L03	Emitente deve estar habilitado na base de dados para emissão do DFe.	Obrig.	203	Rej.	Rejeição: Emissor não habilitado para emissão de CTe
L04	Verificar se DFe já está cancelado.	Obrig.	218	Rej.	Rejeição: CTe já está cancelado na base de dados da SEFAZ. [nProt][dhCanc]
L06	Verificar se DFe foi substituído.	Obrig.	224	Rej.	Rejeição: CTe já está substituído na base de dados da SEFAZ. [nProt][dhSubst]
L10	Verificar se o protocolo informado difere do protocolo do DFe.	Obrig.	222	Rej.	Rejeição: Protocolo de Autorização de Uso difere do cadastrado
L11	Validar o CNPJ do recebedor em cada pagamento vinculado e informar na rejeição o respectivo numerador.	Obrig.	1001	Rej.	Rejeição: CNPJ do recebedor do pagamento inválido [nPag: XXX]
L12	Verificar se tpMeioPgto é válido conforme o Informe Técnico DFe 2026.001.	Obrig.	1003	Rej.	Rejeição: Meio de pagamento inválido [nPag: XXX]

Final do Processamento

Se o evento de vinculação de pagamento do DFe for homologado, o status de retorno deverá ser cStat=135.

8.4. Evento de Cancelamento da Vinculação de Pagamento

Evento para cancelar uma vinculação de pagamento gerada com erro. Autor: emissor do DFe. Tipo de evento: 110301. Schema: evCancVincPGto_v9.99.xsd.

#	Campo	Ele	Pai	Tipo	Ocor.	Tam.	Descrição/Observação
IP01	evCancVincPgto	G	-	-	-	-	TAG raiz
IP02	descEvento	E	IP01	C	1-1	44	Descrição do Evento: “Cancelamento da Vinculação do Pagamento”
IP03	nProt	E	IP01	N	1-1	15	Número do protocolo de autorização do DFe
IP04	nProtVincPgto	E	IP01	N	1-1	15	Protocolo do evento de vinculação de pagamento que será cancelado

Validação das Regras Específicas do Evento

#	Regra de Validação	Aplic.	cStat	Efeito	Mensagem
Q01	Verificar se a UF da Chave de Acesso difere da UF do Web Service.	Obrig.	249	Rej.	Rejeição: UF da Chave de Acesso diverge da UF autorizadora
Q02	Verificar se o nSeqEvento é maior que o valor permitido (1 a 999).	Obrig.	636	Rej.	Rejeição: O número sequencial do evento é maior que o permitido
Q03	Emitente deve estar habilitado na base de dados para emissão do DFe.	Obrig.	203	Rej.	Rejeição: Emissor não habilitado para emissão de CTe
Q04	Verificar se o protocolo informado difere do protocolo do DFe.	Obrig.	222	Rej.	Rejeição: Protocolo de Autorização de Uso difere do cadastrado
Q05	Verificar se o protocolo do evento a cancelar existe, pertence ao DFe e está autorizado.	Obrig.	1002	Rej.	Rejeição: Protocolo do evento a ser cancelado não existe, não está associado ao DFe ou já está cancelado

Final do Processamento

Se o evento for homologado, o retorno deverá ser cStat=135 e o evento cancelado passará à condição de anulado.