Italo Giurizzato Junior

Boa tarde, Analisando os dois XMLs acredito que você não pode comparar eles, pois um se refere ao RPS que é enviado para o provedor e o outro é o XML da NFS-e retornado pelo provedor. Me diz uma coisa, no arquivo de retorno consta essa mensagem: "Verifique a extrutura do arquivo"? Se sim, favor entrar em contato com o provedor para que eles corrijam a mensagem, pois não existe a palavra "extrutura", o correto é "estrutura". E aproveita e pede para eles um exemplo de um XML de RPS completo para você comparar e ver o que esta faltando.

Boa tarde José Augusto, Realmente esta muito estanho esse retorno.

Boa tarde Rafael, Os Schemas são utilizados para validar o lote antes do seu envio. Sendo assim a mensagem na sua postagem anterior é uma mensagem retornada pelo provedor? Se sim, favor anexar os arquivos Soap tanto do envio quanto do retorno para que possamos analisar.

Boa tarde Maicon, Você deve estar enviado o RPS através do Método Enviar, tente com o método EnviarSincrono e com o Gerar.

Boa tarde Adilson, Quanto a anexar arquivos, pode ser que já esgotou o seu limite de anexos. Ao lado do seu nome de login tem um botão que mostra um menu, nele você encontra a opção: Meus Anexos. Exclua os mais antigos, assim libera espaço para você continuar anexando. Agora quanto a rejeição do RPS, é preciso descobrir qual foi o ultimo numero do RPS enviado para que você possa dar continuidade.

Boa tarde Luciano, Fiz uma alteração no componente, pois não estava levando em consideração que no retorno poderia ter o "CDATA". Agora é para ler os dados de retorno de forma correta e salvar o XML que possamos abrir em um navegador. Favor atualizar os fontes e faça novos testes.

Boa tarde Matheus, Favor atualizar os fontes e me informe se alguns dos arquivos INI ou PAS ainda não contempla a sua contribuição. Desde já muito obrigado.

Boa tarde Rômulo, Já fiz as alterações tanto no arquivos Cidades.ini quanto no Pronimv2.ini, ainda hoje vou enviar para o repositório. Assim todos podem iniciar os testes.

Boa tarde a todos, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Marcelo, Recompilou o pacote ACBr_Comum?

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

Exatamente.

Ka F., Caso tenha sido informado o remetente ou destinatário errado, você não poder fazer um CT-e de Substituição para corrigir, se faz necessário realizar o cancelamento. Agora se o erro se refere ao tomador, ou seja, foi informado que o tomador era o destinatário sendo que o correto é o remetente, neste caso a pessoa informada como tomador (destinatário) deverá enviar a SEFAZ o evento de Prestação de Serviço em Desacordo. Ai sim, você emite o CT-e de Anulação e depois o CT-e de Substituição alterando o tomador de destinatário para remetente.

Bom dia Sergio, Muito obrigado pelos testes e retorno acusando que agora a impressão saiu correta. Fique a vontade em nos reportar erros. Vou fechar este tópico.

Bom dia Ka F., A mensagem de rejeição é clara. O CNPJ/CPF do destinatário informado no CT-e de substituição, tem que ser exatamente igual ao CNPJ/CPF do destinatário informado no CT-e original (o que esta sendo substituído).

Boa tarde pessoal, Quem esta usando o componente, favor fazer os testes com o programa exemplo. Verifiquem se o mesmo esta pegando o arquivo INI atualizado do provedor.

Boa tarde Francisco, Já estamos analisando o problema.

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

Boa tarde Kleber, Para poder Validar o XML o mesmo precisa estar previamente Assinado. Logo se faz necessário, primeiro executar o método Assinar que gera o XML, assina e salva em disco; depois executa-se o método Validar. Se preferir, você simplesmente executar o método Enviar, pois este, gera o XML, assina, salva em disco, valida, envia para a SEFAZ, aguarda o retorno, caso tenha sido autorizado o XML será atualizado com o protocolo de autorização deixando-o assim com validade jurídica.

Boa tarde Rafael, O evento foi implementado, mas a sua impressão ainda não. Caso deseje colaborar com a implementação da impressão ficaremos gratos.

Boa tarde Sergio, Favor atualizar os fontes e faça novos testes.

Bom dia Edu, A remoção de mudança de linha, espaços em brancos, identação, entre outras coisa, como já foi dito é regra geral e que já foi exposta acima. Em vez de você ficar criando as suas próprias rotinas para gerar o XML, porque não utiliza as que o componente lhe oferece, teria muito menos dor de cabeça. Quem garante que a sua rotina esta correta? Você e seus clientes, com certeza. Quem garante que a rotina do componente esta correta? Todos os clientes de todos os desenvolvedores que utilizam o componente. Mas em fim, vivendo e aprendendo. Como o problema referente a assinatura foi sanado assim que você passou a gerar o XML de forma correta, então vou dar esse tópico como encerrado. Para novas duvidas ou problemas favor criar novas postagens.

Bom dia Filipe, Os moderadores e consultores ainda estão analisando a sua contribuição, assim que chegarmos a um consenso retornaremos. Desde já muito obrigado pela colaboração.

Bom dia Rafael, Pela mensagem de erro de validação indica que a descrição do evento esta com todas as letras em minúsculas, que não é o correto. Você atualizou todos os fontes do ACBr ou implementou esse evento nos fontes? Se foi você que implementou, não fez da forma correta. Favor atualizar todos os fontes de todas as pastas e reinstale a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada.

Boa tarde Vinicius, Também fiz esse teste e retornou esse erro. Pode ser o numero da porta que é diferente no ambiente de homologação.