jorgehenrique

Ressuscitando o tópico. Conferi no site da CEF agora a pouco, a versão do layout do arquivo de remessa está em 050, porém no ACBrBoleto ainda está no 030. Não está mais aceitando meus arquivos de remessa, dizendo que o código de cedente não existe. Observei as posições e foram alteradas. Como agora as cobranças passarama ser registradas (exigidas por lei), estou em cima da hora e tenho que resolver isto bem rápido. Vejam isto: Procedure GerarRegistroHeader240: PadLeft(aCodCedente,12, '0') + // 59 a 70 - Código do Cedente PadLeft(ACodCedenteDV,1,'0') + // 71 a 71 - DV Codigo Cedente Comparem com a imagem que estou postando em anexo. O código do beneficiário não está mais na posição que o ACBrBoleto informa. Ele informa (no meu caso) 6 zeros a esquerda e em seguida o código do cedente com mais 6 dígitos, porém, nesta versão 050 os 6 primeiros dígitos já são o código do cedente. Não sei o que mais foi alterado, teria que pegar todo layout. Se alguém ja tiver alterado e puder contribuir agradeço. Alguém mais ja teve este problema? Obrigado.

Pessoal, desculpem reativar o tópico. Mas preciso de uma informação: Alguém teve ou tem problemas na hora de gerar PDF's com esta versão do Fortes para o Delphi XE6? Eu consigo gerar os PDF's e XML's normalmente, mas na hora de abri-los dá erro, como se o arquivo gerado estivesse corrompido, além de que ficam enormes. Atualmente estou usando o Fortes Reports Comunity Edition, mas ele tem algumas incompatibilidades com o ACBr e gostaria de voltar a usar o Fortes Reports original. Muito obrigado.

Me parece ser algo relacionado a criptografia. Tipo: webservices atualizado + IE desatualizado = zica!! Pelo menos pra mim aqui, o problema foi resolvido e os pc s desatualizados ja foram solicitados a atualizarem. Eu ficar me matando com isso nao da mais nao...hehe Att

Rapaz, do jeito que está me parece que quem usa o Windows XP já era... Ainda te digo isso sem certeza, mas no momento estou com esta idéia, mesmo porque até a própria MS já anunciou o fim do suporte ao XP. Att

Pessoal boa tarde! Tenho uma novidade. Em uma estação de uma das empresas que mantenho, estavam usando os executaveis recentes normalmente. Estranhei e verifiquei quais as diferenças entre minha maquina virtual Windows 7 SP1, que não conseguia fazer as consultas e a estação que funcionava normalmente. Advinhem só: Internet Explorer desatualizado!! Estava usando o IE8, passei a usar o IE11 no meu Windows 7 e pronto. Tudo resolvido! Se tiverem como ratificar esta informação, ficarei grato. Att

Sim!! Quando faço o mesmo processo de consultar uma chafe NF-e de SP, por exemplo, tanto meu sistema quanto o demo do ACBr funcionam!!!! Att

Bom, sempre fiz pelo ACBrInstall desde que disponibilizado foi. Hoje fiz a instalacao como fazia anos atras, mas foi por faltar alternativas mesmo. Com o ACBrInstall os BPLs vao para a pasta ACBr\Lib\Delphi\LibD20, instalando manualmente vão para a pasta Documentos Públicos\Embarcadero\Studio\14.0\Bpl. A limpeza eu fiz geral mesmo, procurei tudo que era BPL em todas as pastas e limpei. Agora estão instalados na pasta de Documentos Publicos. Att

Juliomar, em uma das empresas que usam meu sistema, tenho um executável gerado pelo XE6 no dia 15/08/2014 (cerca de duas semanas atrás). Este executável estava com a versão do ACBrNFe do final do mês passado, senão me engano. Ele está funcionando corretamente. Me parece que o ACBr foi atualizado, mas MG está com algum problema nas respostas de consultas. O que fiz pra resolver meu problema parcialmente foi pegar este EXE e colocar nas outras empresas que atualizei da semana passada pra cá, apenas nas estações que emitem NF-e e consegui consultar as NF-es paradas obtendo os protocolos de autorização. Meu sócio me mandou este texto: A versão 2.0 expira no dia 01/12/2014 até lá está versão e a 3.10 irão conviver junto. Não seria porque mudou o nome do webservice conforme texto abaixo: A critério da Empresa e da SEFAZ Autorizadora, será implementada a possibilidade da resposta síncrona do Lote de NF-e, para os Lotes com somente uma NF-e. O novo processo de resposta do processamento Síncrono / Assíncrono do Lote da NF-e, na nova versão do leiaute das mensagens, irá conviver durante um tempo com o processamento da forma anterior (somente assíncrono). Para isso, muda o nome do Web Service como segue: Função Versão Web Service Método Envio Lote NF-e 2.00 NfeRecepcao2 nfeRecepcaoLote2 Consulta Recibo Lote NfeRetRecepcao2 nfeRetRecepcao2 Consulta Resultado do Lote (item 4.2 do Manual) O novo processo de resposta do processamento Síncrono / Assíncrono do Lote da NF-e, na nova versão do leiaute das mensagens, conviverá, durante um tempo, com o processamento da forma anterior (somente assíncrono). Para tanto, será alterado o nome do Web Service, como segue: •Novo Web Service: NfeRetAutorizacao; •Novo Método: NfeRetAutorizacaoLote. Vou aguardar mais um tempo até mandar novas atualizações para meus clientes. E desativarei por enquanto a atualização pelo meu servidor apenas de estações que emitem NF-e. Att

Juliomar, Por via das duvidas, removi o ACBr completamente do Delphi, limpei todas as dcu's e bpl's tanto do ACBr quanto do meu sistema. Eu estava instalando pelo ACBrInstall, desta fez fiz a instalação de todos os componentes manualmente, um a um, depois disso abri meu projeto no Delphi e dei um BUILD ALL. Resultado: mesmo problema!! Não sei mais o que fazer, mas vou continuar tentando encontrar o problema. Muito obrigado.

Juliomar, de acordo com http://scn.sap.com/thread/3544865 parece que MG está ok para o XML 3.10 (verifique os posts mais ao final da thread). Então, já tenho que proceder as mudanças ou ainda posso continuar na versão 2.00 até o prazo? Obrigado novamente.

Juliomar, concordo mais ou menos... É o mesmo erro, porém acredito que em momentos diferentes. O do inicio do post acontecia nos Eventos (CCe, Cancelamentos), pra mim está acontecendo no momento da consulta da NF-e pela chave. Outros fatores que observei é que não há arquivo de retorno gerado no comando ACBrNFe1.WebServices.Consulta.Executar, o erro é exibido na tela diretamente, antes mesmo de tentar obter o XML de retorno. Ainda não obtive reclamações, mas pode ser que venha a acontecer este problema com os meus eventos também. Estou meio corrido pra tentar testar, todavia, como disse antes no ambiente de homologação não acontece este erro, o que me faz ter que esperar algum cliente reclamar pra saber se tá ok ou não... Não creio ser problema em outras partes/componentes da minha aplicação, pois o demo do ACBr, está acontecendo a mesma coisa. Porém, a versão XML que estou usando ainda é a 2.00. Já tenho que mudar para a 3.10? Muito obrigado!!

Boa tarde, pessoal, eu de novo!! Só para confirmar alguns testes. - O problema acontece no Windows XP SP3 TAMBÉM!! - O erro não aparece no ambiente de homologação, tanto no meu sistema quanto no demo do ACBrNFe, funcionam normal. E esqueci de dizer: eu uso Windows 7 64 bits SP1, mas tenho uma maquina virtual com o XP SP3 e Delphi XE instalado, mas como já migrei meu sistema todo para XE6, inclusive o módulo de dados (DataSnap), voltar para o XE não dá mais. Ou resolvo o problema ou apanho mesmo!! Outro detalhe que percebi é que este erro acontece apenas no retorno de consulta de NF-e, então consigo enviar e autorizar o XML lá na Sefaz (consultei as chaves no portal e estão OK), mas não consigo obter o retorno da autorização pela consulta da Chave. Att

Reabrindo o tópico. Boa tarde, Juliomar. Estou começando a ter este erro "buffer do usuário não é válido" em alguns clientes. Não consigo entender porque isto acontece, já vasculhei todo meu sistema e os sistemas que apresentam esta mensagem, mas sem resultados. Vamos lá: - Uso o XE6, ACBr atualizado pelo SF através do Tortoise agora a tarde, revisão 7338. Estava indo tudo 100%, de repente comecei a ter o erro descrito no acima. - Não é problema de nível de segurança, todos os Windows 7 que apresentaram este erro estão com nível de segurança NUNCA NOTIFICAR, isto é, desligado. - As DLLs na pasta System32 e/ou SysWow64 são as fornecidas pelo ACBr. - Não tenho DLL's da OpenSSL em outros locais, apenas na pasta System32 e SysWow64. - O mesmo problema acontece no Demo de NFe do ACBr, quando tento consultar uma chave eletronica. Não importa qual certificado eu use (tenho vários A1, de várias empresas diferentes). - O problema parece não ocorrer em Windows XP SP3, ainda não tentei aqui no meu notebook, porém todos que usam o XP SP3 estão operando sem problemas, isto é, não tive ligações nem reclamações até agora, com a mesma versão do EXE do meu sistema e a mesma versão dos Schemas e da Capicom/OpenSSL. Não consigo resolver o problema e, como fiquei escasso de alternativas, recorro a vcs como fonte de ajuda. No que puderem me ajudar, atencipadamente agradeço muito. Att

Também recebi isso aí de um cliente justamente hoje, tava por fora de tudo e ficar sabendo destas firulices em cima da hora é de matar qualquer cristão de raiva, viu.......

Entendido Astrogildo. Diante do ocorrido, creio já poder marcar o topico como resolvido. Att