mbbortolini

Carlos, o Fábio lembrou bem a questão do servidor, tem que verificar se o mesmo tem encaminhamento de e-mail, o hotmail é um problema, para o gmail nas contas mais novas deve ser ativado o encaminhamento nas configurações do gmail.

Carlos, veja o Demo do componente lá consta o exemplo de envio do e-mail e os parâmetros de configuração.

Bom dia pessoal, estou com um problema na impressão do Danfe da NFCe após atualizar o projeto com o trunk2, ocorre que o danfe é impresso 'cortando' as informações das laterais +- 4 caracteres na esquerda e +- 2 na direita. Já testei alterações na impressora, mas não resolveu. No projeto apenas foram removidas as propriedades extintas dos paths e alguns eventos que não existem mais, no demais o componente é configurado da mesma forma, adicionado impressora, danfe, o path do arquivo fast. Ocorre que com o exe com a versão do trunk imprime normal e do trank2 'corta' a impressão, independente de usar o arquivo do fast que está no repositório ou usar o que já estava no pc. Impressora Epson TM-T20, mas ocorre tbm na Daruma. ImpressãoExeTrunk.pdf ImpressãoExeTrunk2.pdf

Tagales, algumas mudança do trunk para o trunk2 trunk -> trunk2 – EnviarEventoNFe -> EnviarEvento; – Configuracoes.Certificados.SelecionarCertificado -> SSL.SelecionarCertificado; – Geral.PathSchemas -> Arquivos.PathSchemas; – SaveToFile -> GravarXML; – Valida -> Validar; – Config.Cert.DataVenc -> SSL.CertDataVenc; – idToken -> idCSC; – Token -> CSC; – ConsultaDpec – extinto; – Onde utilizar o tipo moNFe -> declarar a pcnConversaoNFe na uses.

Obrigado Daniel, funcionou. Eu não tinha adicionado pois o path $(DELPHI)\Projects\Bpl já estava na library path, mas agora foi de boa.

Também estou com erro para instalar os reports pelo instalador. A máquina foi recém formatada, instalado fast 5.1.9, Borland Delphi Version 15.0 Copyright (c) 1983,2002 Borland Software Corporation D:\PROJETOS\LIB\ACBr\trunk2\Fontes\ACBrDFe\ACBrNFe\DANFE\NFe\Fast\ACBrNFeDANFEFRDM.pas(76) Fatal: File not found: 'frx7.dcp' Compilation failure O aquivo que falta está em C:\Program Files (x86)\Borland\Delphi7\Projects\Bpl Log do erro em anexo log_Delphi_7.txt

Italo, na verdade o meu processo de emissão teve muitos "remendos" ao logo dos tempos onde estes processos de geração e emissão haviam estavam com vários passos desnecessários, hoje no preenchimento de nota já tem todas as validações necessárias. Não quero de forma alguma reclamar do componente ou das alterações (que foram muito bem implementadas) só quis mostrar o exemplo para o caso de mais pessoas estarem cometendo os mesmo erros que eu.

Daniel, deixa ver se consigo te explicar melhor o processo : 1º caso : Rejeição 297 1.1 leitura da tabela de notas e carrega o componente (nNF provisório) 1.2 ACBRNFe.Validar //somente para testar o preenchimento dos campos, neste ponto o XML já é assinado 1.3 atribuo o nNF correto com a devida validação de numeração 1.4 ACBRNFe.Gerar 1.5 ACBRNFe.Validar // valida novamente 1.6 ACBRNFe.Enviar // Rejeição 297 2º caso : Emite, mas há diferença entre a informação do componente ACBrNFe e o XML gerado (usando o debug no componente) 2.1 leitura da tabela de notas e carrega o componente //nNF provisório 2.2 ACBRNFe.Validar //somente para testar o preenchimento dos campos, neste ponto o XML já é assinado com número provisório 2.3 atribuo o nNF correto com a devida validação de numeração 2.4 ACBRNFe.Validar // aqui como aquela string FXMLAssinado já tem um valor pois já passou aqui no passo 2.2 o XML não é assinado novamente 2.5 ACBRNFe.Enviar // aqui eu tenho o campo nNF do componente com o valor correto, mas no XML da variável FXMLAssinado o tag nNF possui ainda o nro provisório. 3º caso : Emite e com todas as informações corretas 3.1 leitura da tabela de notas e carrega o componente //nNF provisório 3.2 atribuo o nNF correto com a devida validação de numeração 3.3 ACBRNFe.Validar // XML é assinado com número correto 3.4 ACBRNFe.Enviar // aqui eu tenho o campo nNF do componente e o tag nNF em FXMLAssinado possuem o mesmo número;

Já tem um post sobre o assunto http://www.projetoacbr.com.br/forum/topic/22914-acbrnfe-rejeição-assinatura-difere-do-calculado/, tente ver se alguma as propostas feitas lá pode te ajudar.

Joelson aqui na minha empresa um dos projetos diminuiu quase 2 MB de tamanho com a alteração do ACBr para a versão do trunk2 e olha que instalei TODOS os componentes, porém somente um report o do Fast, que é o único que uso. Ah! Uso Delphi 7.

Rafael, também estou usando delphi 7 e Fast 4.15 em um dos projetos e também tive problemas com a instalação dos pacotes de relatórios pelo instalador, resolvi fazendo manual a instalação dos reports, usei o instalador somente para os demais pacotes e componentes, dps o report foi manual mesmo.

Italo, consegui solucionar o problema, ocorre que eu tinha uma rotina antes da emissão a qual continha ACBrNFe1.NotasFiscais.Validar e que servia única e exclusivamente para testar o preenchimento, se passasse por esta, era chamada a thread que atribui o nNF correto para a nota, valida novamente e faz a sua emissão, no entanto notei que na atualização do componente na procedure NotaFiscal.Validar do ACBrNFeNotasFiscais.pas há a seguinte implementação : ocorre que na primeira validação ainda com o nNF provisório o FXMLAssinado está vazio, assim ele é assinado como está. Após este passo há duas situações : 1- XML validado com nNF provisório : mesmo alterando o campo ACBrNFe1...Ide.nNF e chamado as procedures Validar e/ou Assinar o XML é gerado com o nNF provisório e emitido com este, não importando o que está no componente. 2 - XML validado com nNF provisório, alterado o nNF do componente e usado o comando ACBrNFe1.NotasFiscais.GerarNFe : aqui é que ocorre o retorno 297, pelo meu entendimento o FXMLAssinado contém o nNF provisório e não foi alterado com as informações atribuídas ao ACBrNFe1, no caso o nNF do componente continha o número que eu atualizai e o tag nNF do FXMLAssinado continha o número provisório.

Obrigado por responder Italo, mas preciso pedir desculpas pois confundi os campos, o campo alterado é o nNF, o número da nota. Na sequencia >> Alimentar componente com info do banco>> alterar número >> Assinar >> Validar >> Enviar a nota é emitida, no entanto o número nNF não é alterado ele passa com o que foi carregado do banco

Pessoal, desculpe ser recorrente na questão, mas estou enfrentando o mesmo problema. Atualizei os componentes com o trunk2 e após isso a minha rotina de emissão de NFe não está funcionando corretamente. O pessoal comentou que não se deve alterar o XML antes de enviar, no entanto a minha rotina altera o componente antes do envio, e na versão do trunk isso funciona. Rotina : >> grava a nota no banco com valor aleatório para o campo cNF; (o cliente pode gravar várias notas e depois emitir aleatoriamente, por isso não recebe o número direto) >> Enviar consiste em ler os dados no banco, carregar o componente, alterar o número e enviar; >> Nesse passo se eu não usar a função ACBrNFe1.NotasFiscais.GerarNFe o número que atribuo para cNF não é alterado, permanece o nro aleatório gravado e a nota é emitda, porém se uso a função eu recebo a Rejeição: Assinatura difere do calculado mas neste caso o número cNF no XML. Alguém teria alguma sugestão ? Ah! Neste processo em nenhum momento é usado alguma outra função do componente (assinar,validar,....)

Pessoal, aqui a emissão, consulta e inutilização de NFC-e está 100% funcional, no entanto estou enfrentando problemas com o cancelamento, o componente do ACBr está buscando pelo schemas 3.10 para cancelmaento mas o mesmo não existe. Onde posso encontrar informações sobre isso ? (busquei em todo o fórum sem sucesso). Posso tentar emitir com a versão 3.00 ? (segundo informações da sefaz(RS) 3.00 é para as empresas do plano piloto). Desde já obrigado

Bom dia a todos, após a atualização do ACBr no dia de ontem (08/11/2013) ao emitir as NFe's estava recebendo o seguinte retorno : "502 - Rejeição: Erro na Chave de Acesso - Campo Id não corresponde à concatenação dos campos correspondentes" após muito pesquisa e quebrar a cabeça enfim cheguei à uma solução e estou compartinhando com os demais colegas. Meu sistema foi desenvolvido para utilizar o ACBr Monitor, no entanto com o passar do tempo as funcionalidades foram incorporadas ao sistema por meio de threads. Então algumas funções ainda ficaram, como : >> carrega componente >> valida >> geraNfe >> geração de arquivo temporário, thread >> limpa componente (NotasFiscais.Clear) >> carregar arquivo temporario, >> atribui numeração, ambiente e demais informações, >> valida >> geraNfe >> emitir. thread Ocorre que na thread após carregar o componente e atribuir as informações finais o "segundo" geraNfe não estava atualizando a ID da nota (nfe.infNFe.ID) em virtude da implementaçao das linhas abixo na unit pcnNFeW.pas if trim(nfe.infNFe.ID) = '' then nfe.infNFe.ID := chave; Para resolver, após carregar o XML na thread e atribuir as informações e vallidar adicionei a linha ACBrNFe1.NotasFiscais.Items[0].NFe.infNFe.ID := ''; <<--- ACBrNFe1.NotasFiscais.GerarNFe; Fica a dica se alguém passar pela mesma situação.