Italo Giurizzato Junior

Boa tarde NatanaB, O problema é com o provedor. O componente possui configurações, para determinar o numero de tentativas de consultas que ele ira fazer, bem como o tempo entre uma tentativa e outra. Experimente aumentar o tempo e o numero de tentativas.

Boa tarde ilsouza, Eu também utilizo o Delphi 7 com o Quick Report - DACTE tamanho A4 - Retrato. E esta aparecendo o código de barras da chave.

Boa tarde Luiz, Você esta utilizando o componente ACBrMDFe? Se sim, tanto os fontes do componente, como os schemas estão atualizados? O componente esta sendo configurado com a versão: ve100a ?

Boa tarde Binho, Se o problema esta ocorrendo com o XML retornado ( NFS-e ) pelo Web Services e não o que é enviado ( RPS ) com certeza o problema é no provedor.

Boa tarde Heto Andrade, O que ocorre se colocar mais linhas? Ele corta, só mostra as 5 primeiras linhas?

Bom dia Heto Andrade, Verifique se não tem nenhuma DCU antiga perdida em alguma pasta que o Delphi possa ter acesso durante a compilação. Eu tenho o costume de compilar pacotes e aplicações utilizando a opção Build.

Bom dia Samuel, Se a nota foi processada 4 segundos após o envio, e mesmo assim ao usar o ConsultarLoteRps o Web Services retorna uma mensagem que ainda não foi processado, com certeza o problema é no Web Services.

Boa tarde Heto Andrade, Ao configurar o componente para emitir a NFC-e devemos atribuir o valor tiNFCe a propriedade TipoDANFE.

Boa tarde Heto Andrade, Atualize os fontes e tente novamente.

Boa tarde Ailton, Muito obrigado pela colaboração, ainda hoje estarei disponibilizando.

Bom dia Cristiam, Notei que você utiliza o ACBrNFeMonitor. O Cancelamento do CT-e na versão 2.00 é por evento, você configurou o ACBrNFeMonitor para efetuar o cancelamento por evento? Outra coisa, a mensagem de erro diz que a chave é inválida, verifique se a chave informada é mesmo a chave do CTe a ser cancelado.

Bom dia Caetano, Sim, exceto CE (ainda não disponibilizou os Web Services de homologação) e PR (não disponibilizou os Web Services de produção).

Bom dia Cristiano, Como o cancelamento é por evento e este esta na versão 1.00 independente da versão da NF-e, logo é possível sim, cancelar sem nenhum problema.

Bom dia Graça, Eu pensei em fazer isso, mas voltando ao exemplo: Carregar o XML (salvo em disco) para poder envia-lo por e-mail. O EnviarEmail executa o SaveToStream ou SaveToFile em ambas as rotinas o XML é gerado novamente pelo GerarXML e consequentemente se baseia nas configurações de Modelo e Versão. Se o LoadFromFile carrega o XML e restaura o Modelo e versão, ao executar o EnviarEmail o XML a ser enviado estará invalido, pelo que foi descrito acima.

Bom dia Volmir, A sua aplicação foi desenvolvida em Delphi? Se sim, utilize o componente ACBrNFSe para realizar todas as tarefas. Tome como base o programa exemplo que encontra-se dentro da pasta: ...\Exemplos\ACBrNFSe.

Bom dia a todos, Como todos sabem, o componente ACBrNFe possui todas as funcionalidades para trabalharmos com a NF-e e NFC-e. Para isso devemos sempre configurar o componente setando o Modelo e a Versão do Documento Fiscal da seguinte forma: para NF-e: ACBrNFe.Configuracoes.Geral.ModeloDF := moNFe; ACBrNFe.Configuracoes.Geral.VersaoDF := ve200; // ou ve310; para NFC-e: ACBrNFe.Configuracoes.Geral.ModeloDF := moNFCe; ACBrNFe.Configuracoes.Geral.VersaoDF := ve300; // ou ve310; O problema esta agora em carregar um XML, vou explicar: A sua aplicação esta configurada para emitir NF-e na versão 3.10, mas você necessita carregar o XML de uma NF-e versão 2.00 para enviar por e-mail, por exemplo. O LoadFromFile (por exemplo) ao carregar o XML, vai executar a procedure GerarNFe que por sua vez gera conforme o ModeloDF e VersaoDF setados. Isso faz com que o XML da NF-e que você carregou se transforme na versão 3.10 antes de ser enviado por e-mail. Uma solução que encontrei foi alterar o LoadFromFile de tal maneira que ele reconfigura o componente com o modelo e versão do XML carregado. Desta forma devemos tomar como regra, sempre setar o Modelo e Versão antes de alimentar o componente e/ou antes de enviar, cancelar, inutilizar numeração. Quero deixar claro que essa alteração não é A solução e sim UMA solução, caso alguém tenha uma proposta melhor por favor post neste tópico.

Boa tarde Dércio, Quem rejeitou a nota, foi a SEFAZ ou o componente? Por favor use o termo Rejeitar quando se tratar da SEFAZ e Erro de Validação quando se tratar do componente. Se foi um erro de validação, verifique se você não esta informando algum dado referente ao endereço. Lembre-se que espaço em branco é diferente de vazio.

Boa tarde a todos, Só para fechar com chave de ouro esse assunto. Se não me falha a memória a NF-e foi instituída em 30 setembro de 2005 através do AJUSTE SINIEF 07/05. Pois muito bem o meu sistema possui um módulo chamado: Controle de Entrada (implantado em 2005), a sua finalidade é simples, lançar as notas de compra de materiais. Quando começou a obrigatoriedade da emissão das NF-e, alguém lembra? Pois muito bem nesse meio tempo e até hoje o almoxarifado não digita nenhuma nota, detalhe importante, apesar de recebermos os XMLs dos fornecedores os mesmos não são importados. Resumindo tudo: Recebo por e-mail os XML das Notas; Não tenho nenhuma rotina para importar os dados das mesmas; O funcionário do almoxarifado da entrada nas notas sem a necessidade de digita-las. Para não dizer que ele não digita nada, ele digita o CNPJ do fornecedor e o numero do pedido de compra emitido pelo departamento de compras. Em vez de criar mecanismos obscuros para minimizar o trabalho, que tal desenvolver um módulo de compra de material que se integra com o de entrada?

Boa tarde, Alterei o Destroy: destructor TListaNfse.Destroy; begin if Assigned(FCompNfse) then FCompNfse.Free; FMsgRetorno.Free; inherited; end; Em vez de comentar inclui o if em negrito.

Boa tarde Luiz, A principio a ABRASF definiu o seguinte método de envio: EnviarLoteRps. Mas acontece que a empresas que chamamos de provedores, empresas estas que implantam os Web Services nas prefeituras, algumas criaram um método chamado EnviarLoteRpsSincrono e outras o GerarNfse. Muito bem, hoje temos provedores que se utilizada apenas de um dos métodos e outros que se utilizam de 2 ou todos os 3 métodos. Se você abrir o fonte: ACBrProvedorBHISS.pas vai notar que tanto a function Gera_TagI como a Gera_TagF a ação acGerar retorna vazio por outro lado a acRecepcionar temos o: EnviarLoteRpsEnvio. Esse provedor se utiliza apenas desse método. Note que o programa exemplo possui 3 botões: [Gerar e Enviar Lote] - utiliza o método: EnviarLoteRps. [Gerar e Enviar Lote - Síncrono] - utiliza o método: EnviarLoteRpsSincrono. e [Gerar e Enviar NFSe] - utiliza o método: GerarNfse. Se o provedor BHISS se utiliza apenas do método EnviarLoteRps, concluímos que devemos utilizar o botão [Gerar e Enviar Lote]. Troque a palavra Funcionalidade por método na mensagem apresentada pelo componente, temos: O método [ Gerar NFSe ] não foi disponibilizada pelo servidor: BHISS Entendeu como é que a coisa funciona?

Boa tarde Fabio, O XML da NFS-e é gerada pelo Web Services, alguns retornam 2.5 e outros não. No DANFSE é feita a multiplicação para que a mesma seja impressa como sendo 2.5

Boa tarde, Em uma primeira avaliação o XML esta correto, versão 3.10, modelo 65 e demais campos que indicam uma NFC-e estão corretos. Pode ser uma falha no Web Services.

Boa tarde, O componente possui 3 propriedades chamada Salvar (Geral, Arquivos e WebServices). Atribua o valor True a WebServices.Salvar Isso vai fazer com que seja salvo os arquivos completos com as TAGs do Soap. Será salvo o arquivo *-ger-nfse-c.xml, post como anexo esse arquivo para que eu possa analisar.

Boa tarde Augusto, Muito obrigado pela colaboração, já esta disponível.

Haverstaken, Se o retorno do envio vem sem assinatura e ao consultar vem com assinatura, o problema esta no Web Services do provedor. Entre em contato com o provedor.