Painel de líderes

Bom dia Alguém teria arquivo de retorno bancário para disponibilizar aqui neste tópico? Acho que seria útil, não só para mim, como para outros desenvolvedores que necessitem testar o aplicativo com ACBrBoleto.

Boa tarde, Ao efetuar a Consulta UF está apresentando um erro de conversão ao obter o código da receita, ocorre na linha 214 da unit pgnreRetReceita.pas. Está tentando obter o código e a descrição da receita pelas strings "ns1:codigo" e "ns1:descricao", porem o retorno do XML não existe os caracteres "ns1:" antes. Retirei o caractere "ns1:" e funcionou corretamente, tanto no delphi quanto no lazarus no ambiente de homologação. Segue nos anexo as imagens do XML e do commit que fez o ajuste, e também segue o arquivo "pgnreRetReceita.pas". pgnreRetReceita.pas

Olá estava com a mesma situação. Horas minha aplicação comunicava com a Daruma FS800i e horas travava. Sempre tendo que desligar e religar a impressora, ou então finalizar o aplicativo e iniciar novamente. E como disse em situações diversas com os mesmos testes. Foi realizados testes com o programa da assistência a qual vendeu a impressora fiscal. E após alguns cupons também travou. A assistência trocou a fonte e solicitou para desinstalar o driver da Daruma e instalar o diver (compartilhado em https://drive.google.com/open?id=0B7ZvS1wjEhJSZ0swM0pTYVJnLVE) que eles tinham recebido do suporte da http://www.desenvolvedoresdaruma.com.br/. Fiz os testes novamente com minha aplicação e mesmo assim travava. Verifiquei que a porta sempre é ativada e desativada a cada comando pois faço o mesmo para a impressora Bematech MP-4200 TH FI II o qual já temos alguns clientes com ela utilizando e usa o mesmo protocolo (ecfEscECF) da Daruma FS800i. Alterei a propriedade controle da porta para realizar apenas para a bematech, e até a impressora está estável. Obs: - Vi que no teu log o mesmo é realizado, ativado e desativado a porta. - As configurações da porta alterei conforme imagem em compartilhada (https://drive.google.com/file/d/0B7ZvS1wjEhJSSENsUnlNdFUyaTQ/view?pref=2&pli=1) Faça o mesmo e boa sorte. Espero que funcione

pah esse é um dakeles problemas entre a cadeira e o teclado do teu contador. o problema está na aplicação que ele usa para importar. Uma vez que o destinatário na nfce é opcional fica dificil preencher o estado quando ele não existe, o que se passa é que a aplicação do contador não está a contemplar esta eventualidade na importação do xml, algo que o dito contador deveria saber pela natureza do trabalho que exerce (acho eu).

Boa tarde Elisângela, Muito obrigado pela colaboração, já esta no repositório. Favor atualizar os seus fontes pois este que você anexou esta desatualizado.

Ola pessoal, aconteceu isso comigo tambem algumas vezes, e descpbri neste site a baixo a solucao http://www.agnaldocarmo.com.br/home/comando-milagroso-para-reducao-de-memoria-delphi/ que tambem informei abaixo o que esta neste site caso alguem nao consegue abrir o link Caros colegas da comunidade Delphi, sabe quando realiza aquela descoberta e implementa aquela solução que você estava buscando a muito tempo? se você é programador deve saber, o que é poder dormir com aquele sentimento de realização, por poder implementar uma grande solução. Hoje eu quero compartilhar um comando milagroso para aplicações Delphi 7… Não efetuei testes com versões superiores do Delphi mas pela arquitetura imagino que este problema também ocorre até com as versões mais recentes do Delphi. (conforme diversos comentários, esta solução se aplica as versões mais recentes do Delphi) Quando você cria uma aplicação Delphi, tudo é um objeto, o Formulário é um objeto, cada objeto ocupa um espaço da memória gerenciado pelo programa após ser instanciado. E todo objeto após ser utilizado deve ser destruído para que esta memória seja liberada… O que a maioria dos programadores não sabem é que, especificamente em Delphi que não existe “Coletor de Lixo de memória” como na plataforma .NET. Existe uma memória residual que nunca é liberada mesmo que você destrua todos os objetos que instanciar, porque é uma parta da memória que é administrada pelo próprio Sistema operacional. Se você deixar o seu aplicativo aberto, e efetuar diversas ações que interajam com as APIs do Windows ou DLL externas, trabalhar multi-camadas através de sockets…. Ou mesmo fazer movimentos simples como minimizar ou maximizar sua aplicação… Você perceberá que memória reservada no gerenciador de tarefas para o processo do seu executável crescerá. E muitos destes movimentos como maximiza e minimizar, exceções como já postei em posts anteriores é a parte não gerenciável da memória de sua aplicação pois ela ocorre na própria interação do Sistema Operacional com sua aplicação. Desta maneira, sofríamos um problema sério na empresa onde trabalho, pois existem diversas aplicações que rodam como serviços, exemplo: E o problema comum em todas estas aplicações era o mesmo, por mais que todos os objetes estivessem sendo liberados da memória, esta memória não parava de crescer… Devido ao escopo de memória não gerenciável que falei anteriormente. E isso gerava um grande transtorno, pois estas aplicações de 3 megabytes chegavam a alcançar 2 giga de memória do servidor, obrigando a reinicialização da aplicação periodicamente. Fazia-se necessário que a aplicação Delphi localiza-se o processo do Windows e libera-se toda a memória não mais necessária, descartável…. E é aí que descobrir o procedimento milagroso que interage com a API do Windows… para liberar a memória do aplicativa. Este comando é fantástico. Este procedimento localiza o processo da aplicação, e limpa toda memória residual… E como existe muita pouca documentação desta solução em português… decidi postar aqui. Se sua aplicação for um Serviço, dll ou algo parecido basta remover a instrução Application.ProcessMessages; Quem quiser se aprofundar no assunto pode ler o artigo do link abaixo: http://delphi.about.com/od/windowsshellapi/ss/setprocessworkingsetsize-delphi-program-memory-optimize.htm

No svn a contribuição! Obrigado

Italo, obrigado pela ajuda, eu encontrei o erro e já corrigi aqui. Eu não tinha preenchido os dados do Emitente, apenas do Prestador ACBrNFSe1.Configuracoes.Geral.Emitente.CNPJ := edtEmitCNPJ.Text; ACBrNFSe1.Configuracoes.Geral.Emitente.InscMun := edtEmitIM.Text; ACBrNFSe1.Configuracoes.Geral.Emitente.RazSocial := edtEmitRazao.Text; ACBrNFSe1.Configuracoes.Geral.Emitente.WebUser := edtUserWeb.Text; ACBrNFSe1.Configuracoes.Geral.Emitente.WebSenha := edtSenhaWeb.Text; ACBrNFSe1.Configuracoes.Geral.Emitente.WebFraseSecr := '';

Beleza Juliomar, tudo certo. Apenas para constar caso alguém consulte o mesmo caso, basta abrir o pacote da Danfe Fortes (ACBr\Pacotes\Delphi\ACBrDFe\ACBrNFe\DANFE\NFe\Fortes\ACBr_NFeDanfeRL.dpk), abrir o form contendo o modelo, editar e compilar. Depois "build" sua aplicação. Valeu!

Neste caso como utiliza o instalador pode estar faltando no svn para gerar a compilação! Deixa só conferir com o pessoal!

Bom dia Juliomar, Agradeço a atenção, mas além do meu prazo já ter estourado não tenho conhecimento o suficiente para tal e continuo com o problema do WebService... Este tópico acabou tendo o assunto desviado, posso reabri-lo ou deixo como está?

Obrigado pela contribuição, mas acredito que poderíamos implementar algo mais genérico... ( e não somente para CPF/CNPJ ) Tenho uma implementação em Java para essas rotinas de captura no PinPad (que usei em um projeto proprietário)... Vou tentar ajustá-las para o ACBrTEFD

Juliomar, Essa DLL só funciona com ECFs da Epson... @ITWorks, Provavelmente há algo de errado na instalação do Driver da impressora... Experimente também, instalar o Driver de Spooler, e usar a impressora por compartilhamento...

Adriano, Muito obrigado pela colaboração, já esta no repositório.

O objetivo foi alcançado. Agora, quando o servidor de e-mail demora na autenticação, os comandos seguintes não travam o ACBrNFeMonitor Plus..

Titulo.Mensagem.Add('Mensalidade do mês de Maio/2016') Titulo.Mensagem.Add('Nota Fiscal Numero 0001')