Painel de líderes

No SVN na revisão : 13466 -- pcnConversao -- [+] Nova função para retornar a descrição do modelo function DescrModeloNFe(chave: String):String; -- ACBrNFeDANFeRL ACBrNFeDANFEFRDM -- [*] Refatoracao de ManterDocreferenciados , para utilização da função DescrModeloNFe

Bom dia, Veja que essas opções só são usadas na impressão EscPos. Se estiver usando impressão em Fortes, elas não se aplicam.

Faz tempo que isso ocorre, mais de ano e, se não me engano, já ocorria no ACBrMonitor. Meus fontes estão atualizados e isto é bem antigo, vem de muito tempo. Nesta última semana decidi preencher o nosso número com zeros à esquerda até 8 caracteres antes de usar o "IncluirTitulos" pelo arquivo INI e o problema parece ter parado, darei mais informações no decorrer desta semana. Segue exemplo parcial de INI de inclusão: [Titulo1] NumeroDocumento=119 / 9163 / 1 NossoNumero=00000104 (antes colocava só "104", agora incluí os zeros à esquerda. Neste caso gerou normal, ficou 10405) Carteira=805076 ValorAbatimento=0,00 ValorDesconto=0,00 ValorMoraJuros=1,13 ValorIOF=0,00 ValorOutrasDespesas=0,00 ValorDocumento=678,00 PercentualMulta=3,00 Vencimento=07/08/2015 DataDocumento=10/07/2015 DataProcessamento=19/06/2017 DataAbatimento= DataDesconto= DataMoraJuros=07/08/2015 DataProtesto= LocalPagamento=Pagavel em qualquer agencia bancaria ate o vencimento Especie=DM EspecieMod=R$ Sacado.NomeSacado=DISTRIBUIDORA Sacado.CNPJCPF=12.345.678/9112-45 Sacado.Pessoa=1 Sacado.Logradouro=Avenida Assis Brasil Sacado.Numero=11 Sacado.Bairro=Cristo Redentor Sacado.Complemento= Sacado.Cidade=Porto Alegre Sacado.UF=RS Sacado.CEP=91140000 Sacado.Email=ti@moto Mensagem= Aceite=1 OcorrenciaOriginal=0 Parcela=1 TotalParcelas=1 SeuNumero=119 / 9163 / 1 TipoDiasProtesto=0 TipoImpressao=0

Juliomar, acredito ter resolvido o problema mas não achei exatamente a causa: Quando me referi que em Design Time o componente conectava e em Run Time dava o erro, só dava certo quando eu abria antes um dos meus projetos. Então identifiquei que um dos meus projetos o Zeos conectava normalmente, tanto em Desing quanto em Run Time. Achei este link na internet que mencionava outras dependências de DLL para o Zeos funcionar: https://pgolub.wordpress.com/2009/03/16/client-libraries-mess/ Então constatei que haviam DLLs dentro do projeto que funcionava que não estavam no projeto que dava erro. Tentei analisar todas as DLLs mencionadas no link e fui copiando 1 a 1 para o projeto com erro, mesmo assim sem sucesso. Então copiei todas as DDLs da pasta do projeto bem para a pasta do projeto com erro e funcionou, ou seja, era a falta ou desatualização de alguma DLL. Sobre em Design Time o projeto pelo menos conectar, era porque antes eu havia aberto o projeto que funcionava, e acredito que a DLL fica presa na memória, assim fazendo o projeto com erro conectar, mas em Run Time o EXE deve procurar as DLLs na pasta, daí o erro. Enfim, era realmente a falta ou desatualização de alguma das DLLs, mas não as DLLs libpq81.dll, libpq.dll que eu havia mencionado, e sim alguma outra, mas não sei identificar qual o nome dela pois acabei copiando varias DLLs ao mesmo tempo para ver se resolvia o problema.

Boa tarde, Italo Com esta ultima alteração, já não mais ocorreu erros, apenas a rejeição que já era previsto , de que o autor da prestação de serviço em desacordo deve ser o TOMADOR do serviço e não o emitente. Como eu não tinha outra forma para realizar a homologação, utilizei o mesmo XML que emiti. Agora posso realizar os testes definitivos no meu cliente, com base e informações reais e ai finalizarmos este processo. Obrigado Italo mais uma vez pela atenção dispensado e principalmente por me ajudar rapidamente a validar este processo. Conforme formos avançando nas validações com os dados reais, vou te posicionando, para assim liberar mais uma função da ferramenta ACBR Valeu. @Fábio Eduardo de Souza

Não testei estas funções, farei teste e te passo o retorno.

Sim Italo, sem atualização nenhuma, hoje começou a dar esse erro. Via Browser o Ws está no ar, mas executando, não. Obrigado pelo retorno... Voltou a funcionar. Era alguma instabilidade lá...

Bom dia André, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Douglas, O problema ocorreu de um dia para o o outro, sem que a aplicação tenha sido atualizada? Se sim o problema encontra-se no provedor.

Italo, Vou investigar melhor com meus clientes ( sempre ocorre em ambiente de produção )! O que pude notar é que geralmente se dá quando a velocidade da Internet está muito lenta no momento da transmissão! Mesmo assim, num lote transmitido com 10 notas por exemplo, pode acontecer o problema em apenas uma! Quanto a numeração, aparentemente estão corretas.

Sim o componente que é usado pelo próprio ACBr para gerar! ele é de terceiros e também existe no Fast Report.

Tambem estava com o mesmo problema no Delphi 2006, o problema foi resolvido fazendo o que o Evandro fez: "remover do form o ACBrNFeDANFEFR e adicionar novamente. "

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

Bom dia Só para complementar. O uso do FastMM4 não serve apenas para localizar possíveis vazamentos de memória. Na minha opinião o uso do FastMM4 otimiza em muito o gerenciamento de memória que não é muito satisfatório por parte do Delphi. No meu caso, por exemplo, não existia nenhum vazamento de memória, porém o crescimento da memória conforme o uso do aplicativo crescia sem parar. O simples fato de compilar o FastMM4 junto na minha aplicação ( com algumas configurações que não lembro agora) tornaram a otimização de memória muito mais eficaz.

Boa noite! bem detalhado e documentando e com o manual em anexo! correção já disponível no svn! Obrigado pela colaboração

Boa noite André, Só para confirmar, enviei para o repositório as suas alterações.

Não sabia que se tratava do ACBrMonitorPLUS Obrigado por compartilhar...

Realmente, fiz o ajuste para assinar antes de validar apenas para a NFe. Devo enviar uma nova versão do monitor com a correção hoje ainda.

Rodrigo, Olhando o seu arquivo e comparando com a documentação ele não é um arquivo de RETORNO por isso a mensagem, observe na primeira linha na coluna 143 é esperado que o valor seja 2 conforme o manual e no seu caso é 1, coloquei abaixo o endereço com os manuais existentes aqui mesmo no forum: svn://svn.code.sf.net/p/acbr/code/trunk2 Espero ter ajudado, abraços

Boa tarde Wislei, Após realizar a consulta, tente ler a chave desta forma: chave := ACBrMDFe1.WebServices.ConsMDFeNaoEnc.InfMDFe.Items[x].chMDFe; coloque a linha acima dentro de um loop, onde x é o índice iniciando de zero.

Boa tarde! Realizei uma busca mais detalhada nos manuais e encontrei os seguintes códigos de eventos: 110110 - Carta de Correção 110111 - Cancelamento 110112 - Encerramento Homologado 110113 - EPEC CT-e 110114 - Inclusão de Condutor 110140 - EPEC NF-e 110160 - Registro Multimodal 210200 - Confirmação da Operação 210210 - Ciência da Operação 210220 - Desconhecimento da Operação 210240 - Operação não Realizada 310620 - Registro de Passagem 510620 - Registro de Passagem BRID 610600 - CT-e Autorizado para NF-e 610501 - Registro de Passagem para NF-e Cancelado 610550 - Registro de Passagem para NF-e RFID 610601 - CT-e Cancelado 610611 - MDF-e Cancelado 990900 - Vistoria Suframa Esses foram os quais eu encontrei, se algum estiver errado, por gentileza corrija e se souberem de mais algum acrescente na lista. João Carlos