Italo Giurizzato Junior

Marcelo, Passei o seu problema para o pessoal que conhece mais a fundo o Linux. Por favor aguarde que logo, alguém vai te orientar.

Boa tarde a todos, Favor atualizar os fontes e façam novos testes de cancelamento.

Boa tarde Correia, Abra o arquivo INI do provedor utilizado por essa cidade. Logo no inicio existe um campo referente a quebra de linha. Nele você encontra o caractere utilizado, normalmente é ";".

Boa tarde a todos, Assim que conseguirem fazer os ajustes, favor anexar as units alteradas para que possamos analisar e estando tudo OK, vamos enviar para o repositório. Desde já muito obrigado pela colaboração de todos.

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.