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

Astrogildo, Foi o que eu fiz. Confirmo que os XMLs vindo dos fornecedores estão de acordo com o manual de orientação e não da forma como está sendo baixada pelo portal. Por aqui consegui resolver solicitando aos meus clientes que obtenham o XML diretamente dos fornecedores até ser sanado este problema do portal. Estou postando um dos XMLs que anexei no post anterior. Podem ver que está tudo correto. Os outros XML's tbm estão corretos e não acho necessários postá-los. Obrigado! 31130400522972000146550010000105021463724057-nfe-sign.xml 31130400522972000146550010000105021463724057-nfe-sign.xml

Bom dia, Italo. Tive 2 XMLs de fornecedores diferentes em um cliente na terça-feira (que dizia que a partir da semana passada, começou este tipo de problema) e ontem tive novos casos em outro cliente diferente. Todos eles foram baixados do site da SEFAZ usando o certificado de cada cliente. Sei que o ACBr segue a risca todo o manual de orientação sobre NF-e, porém, o que não se pode deixar de lado é que TODOS os XMLs estão devidamente autorizados o que aponta que tbm não estão errados. Se não for possível alterar o componente para resolver isto, então vou ter que eu mesmo encontrar uma solução, porque se fossem casos isolados seria mais fácil. Obrigado.

Outro detalhe: se consultar a NF-e pela chave no portal, os itens aparecem normalmente, o que indica que o XML está correto e o sistema da SEFAZ reconheceu a estrutura dos mesmos sem problema algum. A questão é que, a cada dia que passa, mais XML's neste formato continuam chegando de N fornecedores diferentes. Se fossem sempre do mesmo fornecedor, seria mais fácil conversar e resolver mas fica impossível ter que discutir com tantas empresas dizendo que seus XMLs estão fora do padrão pois, se assim fosse, logicamente a SEFAZ autorizadora teria rejeitado os mesmos. Creio que o mais ideal é atualizar o componente.

Tbm estou com o mesmo problema! Os XMLs em anexo foram baixados do portal da NFe, portanto, estão validados, enviados e AUTORIZADOS. Isto começou semana passada comigo tbm... 31130400522972000146550010000105021463724057.xml 31130402268532000130550010000750601000750600.xml 31130400522972000146550010000105021463724057.xml 31130402268532000130550010000750601000750600.xml

Pessoal, boa tarde!! Aproveitando o tópico, estou com alguns XML's que o ACBrNFE não consegue ler item algum. Observei a tag nItem dos XMLs que são gerados pelo ACBrNFE e é gerado assim: <det nItem="1"> - <prod> <cProd>16</cProd> <cEAN /> <xProd>DUPLEX MADRI POP 4P SUC</xProd> ... ... </det> Os XMLs que estamos baixando do portal da NFe (validados, assinados e autorizados) estão vindo assim: <det> - <nItem> <nItem>1</nItem> </nItem> - <prod> <cProd>V5621791</cProd> <cEAN /> <xProd>BICO INJETOR</xProd> <NCM>84099969</NCM> ... ... </dev> O ACBrNFe não consegue ler os itens destes XMLs, quando faço ACBrNFe1.NotasFiscais.Items[0].NFe.Det.Count, nada acontece, é como se o XML não contivesse itens. Alguém poderia me ajudar?? Vou deixar 2 XMLs que recebemos pra vcs olharem. Obrigado!!! 31130402268532000130550010000750601000750600.xml 31130400522972000146550010000105021463724057.xml 31130402268532000130550010000750601000750600.xml 31130400522972000146550010000105021463724057.xml

Pessoal, li todas as mensagens sobre NFC-e, desde o inicio e fiquei muito entusiasmado. Mas duvido muito que MG (meu estado) irá aderir a NFC-e. Aqui as coisas sempre andam para trás, a começar pela nossa aliquota de ICMS (18%). Se alguém tiver noticias sobre NFC-e em MG e quiser compartilhar ficaria muito grato!! Att

Retorna só o XML mesmo. O nome fica por sua conta gerar. Fiz aqui da seguinte maneira: NomeAqruivoCCs:=PathWithDelim(EditPathCCe.Text)+SoNumero(cdsNotasFiscaisCHAVENFE.Text)+'-'+FormatFloat('00',cdsEventosNSEQCCE.AsInteger)+'-CCe.xml' EditPathCCe é o local onde ele irá salvar os XMLs de CCe que gerar, vc pode deixar na tela pro usuário configurar.

Outra coisa que esqueci. O XML da CCe vc pega assim: ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML; Att

Ainda não fiz a impressão de eventos. Como não é obrigatório, apenas envio o XML do evento juntamente com o XML da NF-e. Vou fazer a impressão de eventos mas não por agora...

Bom dia! Acho que vc está obtendo o numero do protocolo pela propriedade errada. Ao invés de: ACBrNFe1.WebServices.Consulta.procEventoNFe.Items[0].RetEventoNFe.retEvento.Items[0].RetInfEvento.nProt Após envio do evento, tente: ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.nProt Comigo aqui funciona beleza! Att