Régys Silveira

O procedimento que tenho adotado é o seguinte: - Veja se não existe nenhum bloqueio no firewall ou antivirus; - Instale a nova cadeia de certificados; - Reinstale o aplicativo gerenciador do certificado; - Reinstale a capicom do ACBr. Fazendo isso tem funcionado onde me deu problema.

O problema disso é que funciona somente para quem tem o certificado, o que mais está "pegando" é que muitos usuários utilizavam a rotina para outros fins, como por exemplo um contador baixar a nota e não ter que digitá-la, ou clientes que não possuem o certificado mas que recebem nota eletrônica.

Tópico duplicado, vejam em: viewtopic.php?f=6&t=5047, pois já existe uma discussão a esse respeito.

Ainda não tive tempo de trabalhar no componente está semana, estou correndo atrás de algumas coisas minhas e estou meio sem tempo.

Eu penso que a FENACOM vai conseguir alguma coisa, e penso também que vai melhorar do que era antes, eles sabem fazer pressão e sempre que algo assim acontece e eles entram no meio a coisa se resolve, inclusive eles entraram no meio por conta dos mesmos motivos que eu, você e vários outros usavam a página. Aqui tenho mais de 280 contadores que usavam isso todo o dia para lançar notas, fora os clientes que também usavam porque não recebiam os XMLs, é errado é, mas então porque não disponibiliza uma forma correta, foi o que a FENACOM pensou e está tentando chegar em um acordo com o a SEFAZ.

Tem um tópico bem movimentado a respeito desse assunto: viewtopic.php?f=6&t=5047 Resumindo: A receita federal semana passada por volta de terça-feira modificou a página de consulta da nota eletrônica e fez uma alteração que faz que ao invés de campos texto alguns campos seja mostrados como imagens, isso fez com que o recuperaXML não conseguisse ler tais campos. A receita disponibilizou agora um botão de download do XML, mas para utilizá-lo você precisa estar no Internet Explorer e possuir um certificado digital, e apenas o destinatário da nota fiscal e que pode mediante o certificado dele baixar o XML. A FENACOM protocolou um pedido de retorno ao formato antigo junto a receita federal e pediu para que fosse feita uma reunião com os contadores para que se defina uma forma melhor de fazer isso também.

O SEFAZ nacional passou a fazer isso semana passada, que é o que gerou todo o problema relatado aqui neste tópico, eles disponibilizaram o botão de download que pede o certificado e fazem a comparação, mas é um problema para contadores que não vão e nem podem ficar com o certificado de cada cliente e empresas que ainda não emitem nota fiscal que recebem nota eletrônica e ainda não possuem certificado.

Abra na pasta projetos\DemoDaruma ou no demo do ACBrECF, está implementado é funcionando.

Adicionou todos os paths corretamente no librarypath do delphi?

Isso mesmo, havia me esquecido destes dois, desculpem - 301 - Uso Denegado : Irregularidade fiscal do emitente - 302 - Uso Denegado : Irregularidade fiscal do destinatario

Acho que o pessoal vai gostar de saber dessa notícia. http://www.robertodiasduarte.com.br/fen ... ta-a-nf-e/

Aceita normalmente inclusive o modelo 57 que é o CT-e, só existe uma ressalva, para NF-e e CT-e você sempre pega os últimos 6 dígitos, porque a NF-e pode ir até 9 dígitos.

Basta testar se ACBrNFe.NotasFiscais.Items.NFe.procNFe.cStat é igual a 110, se for é denegada, em homologação não vai vir mesmo denegado, mas em produção se for denegada tem que ter o retorno 110.

você tem que executar o cmd como administrador, por padrão o cmd e executa com reservas pelo sistema operacional.

Parâmetros no sistema e cálculos.

Já estamos verificando esse problema, estamos vendo a melhor forma de arrumar isso.

Pelo meu entendimento sim.

Concordo

Eu utilizo o FastReport aqui na empresa em produção e não dá erro. Você dever ter duas instâncias do componente abertas ao mesmo tempo como o Kiko postou.

André seria mesmo o máximo de 999.99 eu conferi aqui, por isso que mandei essa validação para o rapaz ai, o problema não é aquele campo não são outros.

Fiz uma validação do XML enviado, utilizando o site: http://www.sefaz.rs.gov.br/nfe/nfe-val.aspx e os erros reportados foram outros: Schema XML: Nenhum erro encontrado NF-e 35120347946074000189550010000020971135687027 Regras de Negócio [Ambiente de Homologação (Testes)] 8 erros de validação 291 - [simulacao] Rejeicao: Certificado Assinatura Data Validade 295 - [simulacao] Rejeicao: Certificado Assinatura difere ICP-Brasil 531 - [simulacao] Rejeicao: Total da BC ICMS difere do somatorio dos itens 532 - [simulacao] Rejeicao: Total do ICMS difere do somatorio dos itens 533 - [simulacao] Rejeicao: Total da BC ICMS-ST difere do somatorio dos itens 534 - [simulacao] Rejeicao: Total do ICMS-ST difere do somatorio dos itens 610 - [simulacao] Rejeicao: Total da NF difere do somatorio dos Valores compoe o valor Total da NF. 245 - [simulacao] Rejeicao: CNPJ Emitente nao cadastrado

O problema está nos valores que você está passando. Os registros 60A tem que somar e bater com o valor informado no 60M não é algo no ACBr e algo ai no teu app na hora de passar os valores, ou você não gravou tudo corretamente. Lembrando que o 60A são as aliquotas da Redução Z, a soma delas tem bater com o valor da venda bruta informado no 60M.

O NCM é obrigatório e é validado pelo schema XML, tentou colocar '99' no NCM?

Quando pergunto o tipo, estou falando de DANFE FastReport, Rave, etc. Qual o tipo que você utiliza?

Não, é porque a soma dos registros 60A não bate com o valor informado no 60M.