Italo Giurizzato Junior

Bom dia Eliezer, Muito obrigado pela colaboração, já enviei para o repositório. Detalhe, os seus fontes estão desatualizados.

Bom dia, A única diferença que notei entre o XML de pedido de cancelamento gerado pelo componente e o de exemplo é que a tag <CodigoMunicipio> esta diferente. Gerada pelo componente o conteúdo é: 2611606 já o do exemplo o conteúdo é: 261160. Ou seja, o XML gerado pelo componente esta sendo informado o código IBGE completo do código do município, já no XML de exemplo esta faltando o ultimo digito que se não me falha a memória é um digito verificador. Como os webservices dos provedores costumam retornar mensagens de rejeição que não condiz com o problema, experimente informar o código do município se o ultimo digito.

Bom dia Guto, Muito obrigado pela colaboração, já enviei para o repositório. Um detalhe importante, os seus fontes estão desatualizados.

Bom dia Gumercino, Favor anexar a unit alterada para que possamos analisar.

Bom dia Caio, O provedor ISSDSF tem o seu próprio layout, logo ele pode ter com outro nome ou não ter os campos mencionados por você.

Boa tarde Gumercino, Estranho, estou com os fontes atualizados e não estou tendo esse problema. Você atualizou todos os fontes de todas as pastas? Reinstalou os componentes?

Boa tarde João, Favor anexar as units alteradas para que possamos analisar.

Boa tarde Anderson, O nome do responsável técnico tem vogal acentuada? Se sim, deixe sem o acento. Outra coisa, quem esta gerando o grupo do Responsável Técnico é o próprio componente, correto? Não é você que esta inserindo depois do XML ter sido gerado e assinado?

Boa tarde Juliano, É a sua aplicação que gera o XML e depois você utiliza o componente para assinar e fazer o resto? Se sim, porque você não utiliza o componente para fazer tudo?

Castro, Remova o componente do form, salve o mesmo, depois inclusa novamente. Agora a propriedade se chama DownloadDFe e não mais DownloadNFe. Essa alteração foi feita, pois a classe desse configuração foi padronizada para os demais componentes que emitem DF-e. Por favor leia a noticia: Alterações nas propriedades de Download

Boa tarde Nalso, Muito estranho esse retorno, pois o status 227 se refere a rejeição: CPF do Emitente difere do CPF do Certificado Digital.

Boa tarde Antônio, Verifique se o ícone da unit em questão não tem uma bolinha vermelha. Caso afirmativo, exclua o arquivo e baixe novamente.

Boa tarde Heto Andrade, Isso esta previsto no manual da Febrabam - Custodia de Cheques as informações ficam no Segmento D. O componente ACBrBoleto, se utiliza somente dos Segmentos específicos para o registro de Boletos. No repositório Branches temos um componente chamado ACBrCNAB que tem por objetivo gerar os Segmentos para o pagamento. Não me recordo se ele contempla o Segmento D. Outra coisa importante esse componente não esta 100% funcional, caso deseje colaborar com correções e melhorias ficaremos gratos.

Boa tarde Gumercino, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde João, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde, Obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Velmer, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Leonard, Favor entrar em contato com o provedor, pois esta muito estranho, se não ocorreu nenhum erro, inclusive o webservice esta respondendo, na resposta deveria ter o motivo da rejeição. Simplesmente esta retornando uma "resposta vazia".

Boa tarde Vinício, Chegou abrir o XML com um bloco de notas para ver se realmente existe esse espaço em branco? Se não me falha a memória ao abrir pelo navegador aparece esse espaço, mas ao abrir com o bloco de notas ele não existe.

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

Boa tarde Castro, Favor atualizar os fontes e faça um novo teste.

Boa tarde Felipe, Quando você diz que esta gerando o XML com nome diferente, com certeza você esta se referindo a chave. Muito bem, você esta atribuindo o valor zero ao campo cNF? Se sim, ai esta o seu problema. A sua aplicação tem que gerar o valor de cNF (Código da Nota Fiscal) e armazenar esse código no banco de dados juntamente com os demais dados da nota. Desta forma ao alimentar o componente novamente para gerar o XML basta ler o código do banco de dados e atribuir a cNF como é feito com os demais campos. Com isso você não vai ter mais problemas de ter uma chave nova ao gerar o XML novamente. Por favor leia a noticia: Código Numérico inválido, Chave não Gerada, nela mostro como gerar o valor para cNF da forma mais segura.

Nilton, Enviei um novo arquivo INI do provedor para o repositório. Favor atualizar e faça novos testes com esse novo.

Boa tarde Nilton, Com essa alteração resolveu o problema?

Bom dia Felipe, Qual é a função que você usava antes e que não funciona mais? Ao enviar a nota se ocorrer problemas no retorno devemos: 1. Carregar o XML da Nota através do método LoadFromFile; 2. Executar o método Consultar; O procedimento é só esse e ele funciona até hoje.