Comprovante de entrega eletrônico retornando erro 999

[igor.oliveira3]

Boa tarde, estou enviando o Comprovante de entrega eletrônico(CT-e) no ambiente de homologação para o estado de Minas Gerais, porém o retorno que tenho é 999 - Erro não catalogado. 
Segue em anexo os arquivos xml de envio e resposta

2-eve.xml 2-ped-eve.xml

[igor.oliveira3]

Achei que fosse a tag de chave NFe vazia mas gerei esse e tive o mesmo retorno

1-ped-eve.xml

[BigWings]

O retorno 999 indica um problema no webservice, quando ele não sabe dizer o erro é retornado esse código.

Pode ser que a SEFAZ para o qual está enviando o evento ainda não esteja preparada para receber esse evento.

Já tentou contato com eles?

[igor.oliveira3]

Bom dia @BigWings, entrei em contato agora pela manhã, mas o canal de dúvidas técnicas é apenas o e-mail. 
Então enviei o e-mail relatando a situação e anexando os xml, porém eles dão um prazo de 48 horas para a resposta.

[ALA]

Pessoal, desculpe a minha ignorancia. Mas como vai funcionar esse comprovante de entrega ? E obrigatorio o desenvolvimento ?

[Juliana Tamizou]

Boa tarde.

Veja este tópico da base de conhecimento.

Att.

[ALA]

ops, obrigado..

[JeannyPaiva]

Em 22/08/2019 at 10:02, igor.oliveira3 disse:

Bom dia @BigWings, entrei em contato agora pela manhã, mas o canal de dúvidas técnicas é apenas o e-mail. 
Então enviei o e-mail relatando a situação e anexando os xml, porém eles dão um prazo de 48 horas para a resposta.

Obteve algum retorno diferente da SEF?

Entrei em contato com a SEF-MG também para averiguar o erro. Me retornaram hoje informando que haviam corrigido no ambiente de homologação, porém o problema persiste.

**Alguns clientes entraram em contato informando que a data inicial de obrigatoriedade seria 01/09/2019 de acordo com o Ajuste SINIEF n. 012/2019, porém se não conseguimos nem ao menos testar, será impossível liberar esta alteração (que já está com prazo apertado).

[igor.oliveira3]

Jeanny, tive o retorno hoje também. Deixou de dar o erro 999, na minha situação passou a dar rejeição 873, relacionada a data/hora de geração  da hash de entrega. Porém, está atendendo as regras da NT. 
Enviei o questionamento sobre tal, e estou aguardando reposta novamente. 

[JeannyPaiva]

3 minutos atrás, igor.oliveira3 disse:

Jeanny, tive o retorno hoje também. Deixou de dar o erro 999, na minha situação passou a dar rejeição 873, relacionada a data/hora de geração  da hash de entrega. Porém, está atendendo as regras da NT. 
Enviei o questionamento sobre tal, e estou aguardando reposta novamente. 

Tive esse retorno também a principio, e passando a informar algumas horas antes do horário do evento, voltou a apresentar  a rejeição 999.

[Italo Giurizzato Junior]

Bom dia a todos,

Igor, notei que no seu evento de Comprovante de Entrega, o CNPJ do emitente da NF-e é o mesmo do CT-e.

Essa empresa além de vender ela é uma transportadora também?

Ou você montou uma chave qualquer para fim de testes?

Será que a SEFAZ não esteja validando a chave da NF-e em ambiente de homologação?

Algo do tipo, comparando o CNPJ de ambas as chaves (CT-e e NF-e) e por serem iguais esta rejeitando o evento.

[igor.oliveira3]

Bom dia, Italo. 
Sim a empresa possui tanto NF-e quanto CT-e. De início a Sef - MG reconheceu que havia um erro na validação mesmo, e que havia corrigido no servidor de homologação. 
Então fiz a transmissão novamente e o retorno foi o 873 mesmo a data do hash estando superior a data de transmissão do CT-e, como exigido na NT. Nesse caso já reportei novamente a eles e estou aguardando respostas.
Ainda vou testar o cenário que a Jeanny falou para verificar se comigo também vai voltar a dar a rejeição 999.

[JeannyPaiva]

Bom dia.

Como empresa desenvolvedora temos apenas o CNPJ da própria habilitada para homologação (e a política da empresa não permite uso de dados do cliente para testes). Portanto a mesma empresa que emite CTe na homologação, emite a NFe também.

Recebi novo retorno da SEF hoje informando que fizeram mais correções ontem no ambiente de homologação, e consegui emitir alguns hoje,  e outros ainda com algumas rejeições ainda não façam muito sentido. O problema era lá mesmo (MG tem um histórico de dar dor de cabeça pra gente a cada nova implementação de recurso)

[igor.oliveira3]

Testei aqui também e consegui transmitir e cancelar em homologação

[igor.oliveira3]

 

 

@JeannyPaiva, quando gerei um comprovante de um CT-e que não possui NF-e (Sem chave NFe) , não geramos o grupamento infEntrega, e assim deu rejeição 999. Aconteceu isso com você?

Editado 27 Agosto, 2019 por igor.oliveira3

[Italo Giurizzato Junior]

Boa tarde Igor,

Vendo o código no componente, se você não informar nenhuma chave de NF-e o grupo <infEntrega> não é para ser gerado.

No seu XML consta o grupo e a tag chNFe vazia.

O XML esta sendo gerado pela sua aplicação?

[igor.oliveira3]

Em 27/08/2019 at 16:34, Italo Jurisato Junior disse:

Boa tarde Igor,

Vendo o código no componente, se você não informar nenhuma chave de NF-e o grupo <infEntrega> não é para ser gerado.

No seu XML consta o grupo e a tag chNFe vazia.

O XML esta sendo gerado pela sua aplicação?

Boa tarde. O XML está sendo gerado pelo ACBr, gerou a tag vazia porque passei o '' como valor.
Mas tentei das duas formas gerando a tag vazia ou nem gerando a tag. Só é aprovado quando se tem uma chave NF-e preenchida mesmo. 
Porém pelo que eu entendi já era esperado segundo essa regra, quando é um CT-e tipo NORMAL sempre deve ter pelo menos uma NF-e vinculada a ele, quando é de outro tipo nem é necessário um comprovante de entrega.


Me deparei com um segundo problema, nesse mesmo assunto. Pela especificação para cada chave NF-e vinculada, deve-se gerar um grupamento -infEntrga> chNFe. Assim como o xml que segue em anexo. 
Porém fazendo isso quando eu tenho mais de uma NF-e, o Sefaz me retorna a rejeição 630 - Falha no schema XML especifico para o evento. 
Entrei mais uma vez em contato com o Sefa MG e estou aguardando respostas. 

 

12-ped-eve.xml 12-eve.xml

[Italo Giurizzato Junior]

Boa tarde Igor,

Com certeza é alguma kaka da SEFAZ.

[igor.oliveira3]

1 minuto atrás, BigWings disse:

O nSeqEvento deve ser 1.

Boa tarde, BigWings. É porque em testes já foram enviados vários comprovantes de entrega para esse mesmo CT-e, transmitidos e cancelados. 
Quando se emite um segundo comprovante com o mesmo nSeqEvento dá rejeição de duplicidade, mesmo que o primeiro que foi enviado tenha sido cancelado. 

[BigWings]

3 minutos atrás, igor.oliveira3 disse:

Boa tarde, BigWings. É porque em testes já foram enviados vários comprovantes de entrega para esse mesmo CT-e, transmitidos e cancelados. 
Quando se emite um segundo comprovante com o mesmo nSeqEvento dá rejeição de duplicidade, mesmo que o primeiro que foi enviado tenha sido cancelado. 

Vi depois que para esse evento é permitido até 99 ocorrências.

[igor.oliveira3]

Em 30/08/2019 at 12:29, igor.oliveira3 disse:

Boa tarde. O XML está sendo gerado pelo ACBr, gerou a tag vazia porque passei o '' como valor.
Mas tentei das duas formas gerando a tag vazia ou nem gerando a tag. Só é aprovado quando se tem uma chave NF-e preenchida mesmo. 
Porém pelo que eu entendi já era esperado segundo essa regra, quando é um CT-e tipo NORMAL sempre deve ter pelo menos uma NF-e vinculada a ele, quando é de outro tipo nem é necessário um comprovante de entrega.


Me deparei com um segundo problema, nesse mesmo assunto. Pela especificação para cada chave NF-e vinculada, deve-se gerar um grupamento -infEntrga> chNFe. Assim como o xml que segue em anexo. 
Porém fazendo isso quando eu tenho mais de uma NF-e, o Sefaz me retorna a rejeição 630 - Falha no schema XML especifico para o evento. 
Entrei mais uma vez em contato com o Sefa MG e estou aguardando respostas. 

 

12-ped-eve.xml 4 kB · 3 downloads 12-eve.xml 331 B · 2 downloads

Sefa MG já está fazendo a validação corretamente quando se tem mais de uma NF-e vinculada. Transmiti aqui normalmente