Italo Giurizzato Junior

Boa tarde Hugo, Favor entrar em contato com a prefeitura para saber com exatidão se o webservice da mesma espera receber o XML segundo esse manual ou se espera receber o XML segundo a versão 1 do layout da ABRASF. Até onde sei Salvador possui um webservice próprio que foi construído com base na versão 1 do layout da ABRASF.

Boa tarde Gabriel, Favor atualizar todos os fontes de todas as pastas e reinstale os componentes. Note que fiz uma alteração em vários arquivos INI de provedores.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Sergio, Entendi, já passei para o administrador do fórum fazer a alteração, muito obrigado.

Boa tarde Fabio, E quais seriam esses 3 parâmetros? Chegou abrir o XML de consulta para ver se o componente não os coloca de forma automática?

Boa tarde Anderson, Após alterar o arquivo ACBrBPeServicos.ini você executou o BAT chamado Compila_RES ?

Boa tarde Marcos, Agora o problema é outro e se refere a versão do QR-Code que tem que ser 2.00 Acredito que a versão do ACBrMonitor seja a mais atual, sendo assim nas telas de configuração dele deve ter um campo que se refere a versão do QR-Code, favor mudar para 2.00 e faça um novo teste.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Moreira, Acredito ter encontrado o problema, ainda hoje estarei enviando uma possível correção para o repositório.

Bom dia Mariana, Você não esta usando o componente ACBrNFSe para emitir a nota para o provedor Betha?

Bom dia Eliezer, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Paulo, A única solução é gerar o XML do MDF-e como a mesma data e hora (hora/minutos/segundos) para que o DisgestValue fique exatamente igual ao do primeiro enviado. Existe uma outra saída que é realizar o Download do MDF-e via Portal Nacional do MDF-e. Segue o link: https://dfe-portal.sefazvirtual.rs.gov.br/MDFe

Bom dia, Favor anexar os XML de envio e retorno referente ao evento de pedido de encerramento.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Paulo, Esse erro ocorre quando geramos novamente o XML com uma data e ou hora diferente do que foi enviado. Por conta disso o conteúdo do DigestValue da assinatura desse novo XML fica diferente do DigestValue que esta no protocolo retornado pela SEFAZ que se refere ao primeiro XML enviado. Não sei se ficou claro.

Paulo, Não veio o anexo.

Bom dia Fabio, A rejeição é clara, a nota que você esta consulta não consta na base de dados da SEFAZ, ou seja, ela nem sequer foi enviada, se foi, foi rejeitada por conter alguma informação incorreta.

Bom dia Gabriel, Você poderia anexar esses XMLs para que possamos analisar? Na versão antiga da aplicação cujo cancelamento funciona, estava sendo usado o Capicom ou WinCrypt? E a nova versão o que usa?

Paulo, O componente ACBrMDFe, possui um método, chamado Cancelamento que requer que seja carregado o XML do MDF-e antes da sua execução. Mas você pode montar uma rotina para envio de evento, cujo evento é o de cancelamento, neste caso não se faz necessário possuir o XML do MDF-e. Mas é preciso saber a chave e o numero do protocolo de autorização. Como lhe disse, se o seu cliente ao tentar enviar novamente, ocorreu a rejeição de duplicidade, o XML assinado agora tem que estar salvo, visto que ele foi enviando e a SEFAZ retornou a rejeição.

Bom dia, Que cabeçalho você se refere, é a tag <mdfeProc>? Se sim, é obvio que não gerou, pelo simples fato do MDF-e não ter sido autorizado. Porque ele não foi autorizado? Não foi autorizado por existir uma pendencia. E a pendencia esta informada no arquivo (*-pro-rec.xml) que acusa a existência de um outro MDF-e que não foi encerrado. Entendeu?

Bom dia Gustavo, O método EnviarEvento não requer que você tenha carregado previamente o XML do CT-e. Trata-se de apenas uma alternativa para obter alguns dados, como chave, CNPJ e numero do Protocolo. Em qual unit ao debugar não passa pelo teste no que você se refere ao tpEvento?

Bom dia Paulo, O componente não esta configurado para salvar os XML em disco? Configuracoes.Arquivos.Salvar := True; Até onde seu o XML do MDF-e é gerado, assinado, validado e salvo em disco antes de ser enviado. Outra coisa, se agora esta ocorrendo erro de duplicidade com certeza você tem um novo XML com a mesma chave do anterior, basta carregar usando o LoadFromFile e depois executar o método Consultar para que o XML que esta assinado seja atualizado com o protocolo de autorização. E para finalizar, como você envia o MDF-e novamente após um problema seja um erro ou queda de energia? Quem foi que disse que o problema ocorreu durante o envio? Pode ter ocorrido durante o retorno. Como não sabemos o exato momento do ocorrido, o procedimento correto é carregar o XML e consultar. Se a SEFAZ retornar uma mensagem informando que o MDF-e não consta na base de dados ai sim devemos enviar novamente. Pense nisso. Espero ter ajudado.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Dercide, É preciso fazer mais testes para saber se foi um problema momentâneo ou não.

Boa tarde Rafael, Esse arquivo ExemplosXML.rar foi baixando do site da Pronim? Se sim, gostaria de saber se eles utilizam o ACBr para realizar testes. Pois os nomes dos XMLs são exatamente os mesmos usados pelo ACBrNFSe. ? Se o XML de exemplo é o que esta sendo usado agora para a cidade de Soledade/RS então a versão é a 2.02 Sendo assim no arquivo Cidades.ini será necessário mudar de Pronim para Pronimv2. E no arquivo Pronimv2.ini devemos incluir as URLs de homologação e de produção da cidade em questão. Favor entrar em contato com o provedor ou com a prefeitura e solicitar as URL de homologação e de produção.