igor.oliveira3

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

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.

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

@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ê?

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

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.

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.

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.

Achei que fosse a tag de chave NFe vazia mas gerei esse e tive o mesmo retorno 1-ped-eve.xml

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

Ao enviar Ct-e em ambiente de homologação está sendo retornado sempre o código "217 - Lote em processamento". Não há um retorno de rejeição nem de aprovação. Alguém está passando por isso? Transmissão no estado de Goiás e usuário transmitindo normalmente em ambiente de produção

É isso mesmo que o Hugo falou. Porém, mesmo ajustando tudo conforme definido pelo provedor, continuo com o mesmo erro. Minha alternativa foi gerar e assinar o xml pelo ACBr e transmitir usando WSDL importer

Italo, gerando com o envelope já atual eu continuo tendo o seguinte problema utilizando o ACBr. Lembrando que o webservice para Rio Verde - GO é http://rioverde.centi.com.br/servicos/wcf/service/servicenfse.svc?ws --------------------------- Debugger Exception Notification --------------------------- Project SAgrVFat.exe raised exception class EACBrWinReqResp with message 'Erro: Requisição não enviada. Erro: 0 - BWBMAQMDoBATDjAyNDM1MzAxMDAwMTczoDgGBWBMAQMEoC8TLTIwMTAxOTczNTc4MDAxODkx MDQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDB6AOEwwwMDAwMDAwMDAwMDAw DQYJKoZIhvcNAQELBQADggIBACM5FVH64IriISmaR2dd2gnlnX1uENp1j631MCKiWVHk7ZFw CzyRSBeUItYETuLC1jI2TbSwb7HSdTqoF1z+NDwtoLmMQvXLwPhDFMkv4FSca3Hbq+QiBRuN I3hIjsOiEdf0U8VABOoNJOw1vLA0QkNDL/L/M8gO8J12HHExLnXO0EM3nyscUVrqcmd6Z/L+ M/p0YOuY+Au4KoU5zd70o43ZtuAqA86L2ZTyNc68RUeoqxTMHx6ivNiJzPHmcCIgf55yVwWZ WrNR96Uu9HVoCqJ2r+Zm5OC5DwkrzJ7H9x2K+D/NC2y7ZETI2Oa2yWpCrLWHUE6ILCekCKrC +a2JAatcAX7DaSoIvuyudIb/7ThHUtkmsUpZ9Bub1aEmOHTHr+TPu1VpG6G3qeX51z7bOT0O 8Nws9nhLjUz0V8HGQCrbbZf8cqgtGgXbDSF3o89sp/9KYU2uWMgRNpJvGjoo9ZOYaIXRfwOe VmSZGKtNiofxnb2FV37sU9YvVpBDgL6IaD18feD2nVJZkws+VWMkFU6mSUz+NAyb4PF8bEUx 8eCtBKeGErYmChIt9TXxWaL83tIL/cVqtKFGvNP8d9QkUwSagndFfM+9ejDmFDiID7oURr8x YqjRip/npaZrzTWF/2HM0yijSeCrdC2WN7jUN9zRIiVUPoTo8lghhtbGNuM5 </X509Certificate> </X509Data> --------------------------- Break Continue Help ---------------------------

Bom dia. Consegui realizar a transmissão com resposta de sucesso com o seguinte envelope em anexo. Realizei o teste sem usar o ACBr xmlTesteSucesso.xml

Boa tarde, Italo. Criei o tópico pelo fato de que nem sempre o provedor que está no Cidades.ini é o que o município está utilizando atualmente. Isso aconteceu com Sorriso-MT recentemente, o qual eu iniciei os testes de transmissão utilizando o provedor descrito do Cidades.ini. Passamos algum tempo tentando fazer funcionar até entrar em contato com a Agili e descobrir que o provedor não era o correto. O que acontece com Patos de minas é que no Cidades.ini o provedor está como ISSIntel , porém o manual disponível do portal da prefeitura remete ao provedor Governa. Então antes de iniciar os testes criei o tópico para justamente facilitar a obtenção dessa informação, visto que, na maioria das vezes, não temos um bom suporte vindo das prefeituras. Agradeço suas orientações.