Gr@c@

Esse erro dá no Windows 7 também. Tem que ir em -> Internet Explorer -> Ferramentas -> Opções da Internet -> Avançada -> Segurança -> e desmarcar "Verificar se há revogações de certificado no servidor" e "verificar se há certificados revogados no servidor"

É realmente o que eu havia sugerido não funcionaria. O que sugeri foi, se no componente tem até a versão 009, se eu informasse Cod_ver = ' ', o componente entendesse que a versão correspondente seria a 009.(a ultima versão que tem no fonte do componente, não a ultima versão estipulada pelo SEFAZ) Só que no componente já temos a versão 010, que só estará funcional a partir de 2016 porque foi prorrogada. E o validador só aceita até 09. Então, realmente não daria certo a minha sugestão. Cada versão tem o seu período de vigência para que o validador entenda. E cada versão é ref a alguma alteração no layout. Melhor deixar como está.

Erro <rodo> <veic> <prop> <uf> está dando esse erro ao consultar CT-e emitido/autorizado ontem e ao tentar enviar CT-e hoje. Mas analisando o xml está correto.

Existe a possibilidade de: Se for informato COD_VER = ' ' ou um outro conteúdo especifico, o componente atribuir automaticamente ao COD_VER a ultima versão suportada pelo componente? Digo isso porque o que o AlexandreADC mencionou realmente faz sentido. Em algumas versões não há tanto impacto. Por exemplo, eu havia setado o meu aplicativo para vlVersao107 e já havia no componente a vlVersao108 e vlversao109. A vlVersao108 não causou impacto e tudo ainda estava funcional e o validador não acusou incompatibilidade;

ocorreu isso com vários clientes meus hoje aqui em MG. Entre no Internet Explorer->Ferramentas->Opções da Internert-> avançadas e desmarque "verificar certificados revogados". Isso ocorre todo ano quando chega próximo da data de alterar horário de verão. (mas não me pergunte o porquê)

Você atualizou os schemas? Aqui está funcionando normal.

Uma dúvida: Em que situação, ao gerar o xml, é necessário informar previamente a chave de acesso e ser preciso manter a chave informada manualmente não deixando que o componente a substitua?

Concordo. Mas como sempre funcionou, deixei passar batido. Deve ser um erro que vem desde quando desenvolvi o meu aplicativo emissor de NFe. Já arrumei aqui e ficou correto. O problema é que, como não conseguia debugar o aplicativo, não achava um erro tão bobo. Mas, para ficar mais compatível com os demais componentes, nos NFe tem essa checagem que não tem no MDFe (no caso, o ValidarChave): if (Trim(nfe.infNFe.ID) = '') or (not ValidarChave(nfe.infNFe.ID)) then nfe.infNFe.ID := chave else begin NFe.infNFe.ID := StringReplace( UpperCase(NFe.infNFe.ID), 'NFE', '', [rfReplaceAll] ) ; NFe.infNFe.ID := 'NFe' + NFe.infNFe.ID; end;

Ítalo, consegui debugar o aplicativo até o erro e detectei onde está retornando o '' is not a integer value; No ACBrMDFe subversion mais antiga -> pmDFeMDFew.pas -> function TMDFeW.GerarXML:boolean antes essa parte da unit estava assim: ---------------------------------------------------------- chave := ''; if not GerarChave(Chave, MDFe.ide.cUF, MDFe.ide.cMDF, StrToInt(MDFe.ide.modelo), MDFe.ide.serie, MDFe.ide.nMDF, StrToInt(TpEmisToStr(MDFe.ide.tpEmis)), MDFe.ide.dhEmi, MDFe.emit.CNPJ) then Gerador.wAlerta('#001', 'infMDFe', DSC_CHAVE, ERR_MSG_GERAR_CHAVE); chave := StringReplace(chave,'NFe','MDFe',[rfReplaceAll]); MDFe.infMDFe.ID := chave; MDFe.ide.cDV := RetornarDigito(MDFe.infMDFe.ID); MDFe.Ide.cMDF := RetornarCodigoNumerico(MDFe.infMDFe.ID, 2); agora está assim: ----------------------------------- chave := ''; if not GerarChave(Chave, MDFe.ide.cUF, MDFe.ide.cMDF, StrToInt(MDFe.ide.modelo), MDFe.ide.serie, MDFe.ide.nMDF, StrToInt(TpEmisToStr(MDFe.ide.tpEmis)), MDFe.ide.dhEmi, MDFe.emit.CNPJ) then Gerador.wAlerta('#001', 'infMDFe', DSC_CHAVE, ERR_MSG_GERAR_CHAVE); chave := StringReplace(chave,'NFe','MDFe',[rfReplaceAll]); ----> acontece que nesse ponto a minha tag MDFe.infMDFe.Id = numero do MDFe = 13 e não igual a '', portando esse if não executa. Existe algum motivo especial para ter sido acrescentado esse if ? Nos outros componentes não está sendo tratado dessa forma. Verifiquei meu aplicativo de NFe e nele também estou movendo o numero da NFe para o infNFe.Id. if trim(MDFe.infMDFe.Id) = '' then MDFe.infMDFe.Id := chave; MDFe.ide.cDV := RetornarDigito(MDFe.infMDFe.Id); MDFe.Ide.cMDF := RetornarCodigoNumerico(MDFe.infMDFe.Id, 2); -----> setei o infMDFe.ID = '' e deu certo. -----> mais um detalhe: só consegui debugar o aplicativo completamente, depois de desinstalar todo o ACBr e reinstalar. Então, com certeza o que estava travando o debugger eram bpls ou dcus do componente. analisando o pcnNFew.pas está assim (por isso não ocorre o erro no meu aplicativo de NFe) ---------------------------------------------------------------------------------------- if (Trim(nfe.infNFe.ID) = '') or (not ValidarChave(nfe.infNFe.ID)) then nfe.infNFe.ID := chave else begin NFe.infNFe.ID := StringReplace( UpperCase(NFe.infNFe.ID), 'NFE', '', [rfReplaceAll] ) ; NFe.infNFe.ID := 'NFe' + NFe.infNFe.ID; end;

hoje fiz o seguinte teste: -compilei meu aplicativo emissor de MDF-e que estava funcional até ontem (com compilação anterior a 02/02/2015). Ontem por exemplo, sem compilar, ele estava enviando MDF-e com sucesso. -Não alterei os schemas nem o aplicativo -Após compilar, passou a dar o erro '' is not a valid integer e não gera o xml portanto o problema não são os schemas. Deve ter sido feita alguma alteração no componente que eu não consigo detectar porque ao debugar não me permite chegar até o ponto. Já deletei dcu,dcr,res deixando apenas o dpr,dfm e pas, mas mesmo assim o debug não continua.

Boa tarde Italo fiz o que vc sugeriu, mas continua o erro. No meu aplicativo anterior, usando os schemas antigos, e sem a tag RENAVAN não ocorre o erro e o MDF-e é enviado e autorizado. No aplicativo novo, com schemas novos e tag RENAVAN o erro ocorre. Sem tag RENAVAN também. E também ocorre se usar esse aplicativo novo com os schemas antigos. O problema é que não consigo debugar até o erro e nem gerar o xml até onde é possível. Tem uma outra forma de conseguir fazer isso? Já chequei o layout para ver se falta abastecer alguma tag mas está tudo aparentemente correto, inclusive os conteúdos (que consigo checar ao debugar o aplicativo).

apenas excluir a unit ACBrProvedorGinfesV3.pas não foi suficiente. Para conseguir instalar, foi necessário: 1-excluir toda a pasta Fontes\ACBrNFSe 2-atualizar novamente os fontes pelo ACBrInstall.exe compilou 100% Cleiton, tente fazer esse procedimento e se der certo, coloque o tópico como Resolvido, por favor. obrigada Italo

Pessoal, desculpem a insistência, mas já fiz de tudo por aqui e não consigo chegar ao erro e gostaria de saber se o pessoal de MG está conseguindo enviar MDFe conforme a NT 2015. Já fiz todas as alterações necessárias, mas não consigo gerar o xml, nem tão pouco chegar ao ponto do erro '' is not a integer value. Acredito que a única forma possível fosse gerar o xml incompleto até a tag que está dando o erro, mas isso também não é possível. Isso começou a ocorrer depois da atualização ACBr de 02/02/2015. Já chequei tudo com o layout, regras de validação e tudo o mais. Por sorte, tenho o aplicativo com compilação antiga que está funcional.

Minha consulta de MDFe Encerrados estava dando erro de Falha no Schema XML. Fiz conforme orientações doItalo: "Note que o conteúdo da TAG: xServ é CONSULTAR NAO ENCERRADOS sendo que eu alterei para que a palavra NAO seja acentuada. Atribua o valor False a propriedade RetirarAcentos: Configuracoes.Geral.RetirarAcentos := False; Antes de realizar a consulta." e funcionou perfeitamente. Portanto, essa consulta para emitentes do estado de MG está funcional.

atualizei o ACBrMDFe hoje 02/02/2015 atualizei todos os schemas conforme disponibilizado pelo portal do MDFe atualizei as tags conforme NT 2015 mas ao gerar o xml ocorre o erro : '' is not a integer value Debugo o aplicativo mas não consigo detectar o erro. Como não gera o xml, não consigo ver qual a tag que está com conteúdo invalido.

atualização de 02/02/2015 log_Delphi_7.txt

Marcelo_sp, eu faço exatamente esse tratamento no meu sistema, através do cStat como você demonstrou. Funciona corretamente com outras notas denegadas. A questão é que uma nota de destinatário de SP não me retorna denegada através da consulta via aplicativo com ACBr. Outras notas denegadas me retornam cStat 301 ou 302 correto. Mas em todo caso, o problema foi resolvido porque ontem a tarde (sem nenhuma alteração no aplicativo ou atualização do ACBr) a nota passou a retornar o correto. O problema estava realmente no SEFAZ. Mas a sua resposta está bem clara e vou coloca-la como solução de como tratar uma nota denegada no aplicativo.

Cleber, quando a nota retorna status de denegada o usuário não consegue imprimir o Danfe. Já fiz esse teste aqui consultando uma nota que foi denegada há uns 2 meses atrás. Quando consulto ela me retorna status de denegada e não permite impressão. Só que na nota denegada hoje (por conta do destinatário), a nota aparece denegada somente na consulta direta no portal da NFe. Pelo componente, não me retorna denegada. Terei que pegar o xml do cliente e também fazer um download do xml no portal nacional para poder entender isso.

Bom dia Hoje ocorreu de um cliente ter recebido rejeição de NF-e denegada por conta do destinatário (o emitente é de MG e o destinatário de SP). Porém, ao consultar a nota pelo ACBr, a nota vem com protocolo de autorização e sem nenhuma mensagem de rejeição, como se estivesse autorizada. Imprimo o Danfe sem nenhum erro. Mas ao consultar no portal da NFe, a nota consta como denegada. Ao consultar o CNPJ no Sintegra de SP o cliente está com o CNPJ inapto. Na versão anterior da NFe, notas denegadas eu não conseguia imprimir o danfe. Confesso que não entendi como o Danfe foi impresso como se aparentemente a NFe estivesse autorizada. Meu cliente quase transportou a mercadoria com essa nota. Alguém passou por isso?

Bom dia Arquivo digital para Entidades Financeiras: SISCOAF (Controle de Atividades Financeiras). Gostaria de saber sobre a viabilidade de desenvolvimento de um componente no ACBr. O Manual Operacional com todas as instruções está no link abaixo: https://www1.fazenda.gov.br/siscoaf/portugues/publicacoes/Siscoaf-comunicacoes-geral.pdf

22/01/2015 - Publicada a versão 1.10 da Nota Técnica NF-e 2014/001 - Evento Prévio de Emissão em Contingência (EPEC) Publicada a versão 1.10 da Nota Técnica NF-e 2014/001 - Evento Prévio de Emissão em Contingência (EPEC), com alterações na documentação e em Regras de Validação.

MG está funcionando parcial, tem hora q funciona normal, tem hora que não. O serviço de cancelamento, por exemplo, está no vermelho desde sexta-feira passada. Mas esse erro de [The server name or address could not be resolved] também pode ocorrer no cliente (internet)

Pessoal, não estou entendendo como é o procedimento de localização das pastas. Os arquivos xml estão sendo gerados na past AnoMes correta. Dentro dessa pasta, estão sendo geradas as pastas Cancelamento e CCe. Porém os arquivos xml de cancelamento e cce não estão sendo gravados nestas pastas e sim na pasta de xml normal. Então, se busco o arquivo com o ACBrCTe1.Configuracoes.Arquivos.GetPathEvento ele não localiza o arquivo porque está procurando dentro da pasta CCe ou Cancelamento.

O que está valendo para pegar os path dos eventos? ACBrCTe1.Configuracoes.Arquivos.GetPathCan ou ACBrCTe1.Configuracoes.Arquivos.GetPathEvento

Depois da ultima atualização do componente, percebi algumas alterações que estão afetando muito o funcionamento do meu aplicativo: 1-No pdf está criando chave+"-nfe.pdf" e antes era apenas chave+".pdf" 2-quando cancelo uma NFe é criada uma pasta "Cancelamento" onde é salvo o xml. Não entendi, porque em nenhum momento configurei o componente para criar essa pasta. Antes o xml do cancelamento era sempre gravado na pasta configurada em ACBrNFe.Configurações.Arquivos.PathNFe Preciso saber qual são as pastas criadas automaticamente pelo componente e em que situação (configuração do ACBrNFe) ele cria estas pastas. As minhas configurações estão assim: ACBrNFe.Configurações.Arquivos.PathCan := ACBrNFe.Configurações.Arquivos.PathNFe;