leomcl

Agora, fiz um teste aqui, mudando de libWinCrypt para libCapicom e funcionou. Estranho que estava funcionando antes com a libWinCrypt. E é só o cancelamento, o envio vai normal com WinCrypt.

Bom dia senhores, Atualizei hoje meu ACBr, e parou de funcionar o cancelamento de NFSe. Eu não o atualizava desde novembro de 2017, e estava funcionando. Percebi que o XML de pedido de cancelamento antigo tem diferença do pedido de cancelamento que está sendo gerado hoje, com o ACBr assinado (segue anexos). Pelo que reparei, a assinatura antes de atualizar o ACBr vinha antes de: </Pedido> </CancelarNfseEnvio> Agora está vindo antes de: </CancelarNfseEnvio> Acho que é esse o problema. Uso o provedor EReceita (Montes Claros/MG). Alguém saberia me informar se isso é alguma configuração nos .ini que tenho que mexer? Desde já agradeço, Leandro 201700000000828-ped-can - ANTIGO - FUNCIONANDO.xml 201800000000236-ped-can - HOJE - COM ERRO.xml

Na verdade, ele não discutiu que o md5 do cupom estava diferente do md5 registrado no sistema da receita. Só pediu pra corrigir o que ele disse que não estava dentro da lei, que era um relatório gerencial. Menos mal rsrsrs. Leandro

No nosso PDV sai o MD5, por que inicialmente foi feito pro Requisito 02.02, depois que foi adaptado pro MG002 não tiramos tudo. De qualquer forma, deu tudo certo, recebemos resposta do auditor, já estamos sem problemas com eles. Obrigado!!!

Já está na MG002. Ao menos isso rsrs obrigado.

Obrigado Felipe, vou apresentar isso pro fiscal se ele reclamar de algo. Sobre formatar, @esantana, não é viável toda vez que formos instalar um sistema formatarmos a máquina. Cliente vai preferir nem trocar rsrsrs Obrigado, Leandro De qualquer forma, o fiscal pediu o MD5 da versão anterior que estava lá, então eles usam pra alguma coisa. Se alguém souber como proceder nos casos que falei acima de dlls diferentes, eu agradeceria. Obrigado, Leandro

Boa tarde @esantana, Não é executável de homologação. Aqui em MG, toda vez que a gente faz uma alteração no PAF-ECF, a gente mesmo vai lá no sistema da Receita e registra a versão e seu MD5. A questão é que o MD5 que registrei lá no site, está diferente do MD5 que está sendo impresso no cupom do cliente, embora o executável do PAF-ECF seja o mesmo. Isso acontece por que na máquina do cliente tem dll's diferente do ambiente desenvolvimento. Por exemplo, o pc onde desenvolvmentos é 64 bits e lá no cliente é windows 32 bits. Aí as dll's são diferentes.

Bom dia pessoal, tou com um problema sério. Em Minas utilizamos PAF-ECF ainda, e tem aquiele arquivo com a lista de MD5 dos arquivos exe e dll que é gerado ao entrar no sistema. Esse MD5 tem que ser impreso no cupom. Mas pode ser que na máquina do cliente vai estar com alguma dll com versao diferente da que foi usada na máquina de desenvolvimento, logo o MD5 do PAF-ECF registrado no site da receita vai ser diferente do MD5 que sai no cupom do cliente. Alguém sabe como proceder nesse caso? Estou com um fiscal me pedindo esse md5 e versão, e não bate com o que saiu no relatório gerencial do cliente q ele está fiscalizando. Obrigado, Leandro

Também estamos tendo esse problema com alguns clientes. Se tiverem alguma informação oficial da Sefaz, por favor repassem. Leandro

Mostro uma mensagem. att, Leo

Marcos, Resolvi fazendo isso que o BigWings falou. No laço que leio o retorno do ACBR com as NFe destinadas, fiz a seguinte condição: if ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip[zContNFe].schema = schprocNFe then begin ACBrNFe1.NotasFiscais.Clear; try ACBrNFe1.NotasFiscais.LoadFromString(ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip[zContNFe].XML, false); Except end; if ACBrNFe1.NotasFiscais.Count > 0 then begin if ACBrNFe1.NotasFiscais[0].NFe.Dest.CNPJCPF <> zCNPJ then //se não é nota destinada ao meu cnpj, ignoro continue; end; end; Onde zCNPJ é o CNPJ da empresa em questão. att, Leandro

Boa noite Senhores, Eu achava que o DistribuicaoDFe retornava apenas notas destinadas ao nosso CNPJ, mas está retornando as notas emitidas pelas filiais também. Alguém pode confirmar se também percebeu isso? Diante disso, tem-se um problema: eu quero apenas as NFe's emitidas para o meu CNPJ, mas não vi forma de filtrar isso pelo retorno. Pela propriedade: ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip[0].resNFe.CNPJCPF eu tenho o CNPJ que emitiu a nota, não o CNPJ destinatário. Alguém poderia me dar uma luz de como resolveu isso? Obrigado, Leandro

Consegui resolver. Atualizei a versão do fastreport de 5.1.5 para 5.3.16 e deu certo. Parece que a 5.1.5 não suporta scripts. Não sei como mudar o título do tópico pra resolvido, de qualquer forma, muito obrigado. Leandro

Obrigado Henrique. Estava usando o danferetrato.fr3, agora testei com o danferetratonovo.fr3, danfe.fr3, DANFeRetratoFS_Basic.fr3 e o DANFeRetrato_Basic.fr3, e o que ficou menos desconfigurado foi o DANFeRetrato_Basic.fr3. Percebi que ele tem menos campos que o DANFeRetrato.fr3, mas acho que não será problema pros meus clientes. Só a questão da borda do quadro de itens não estar preenchendo a folha toda que continua. Att, Leandro

Bom dia, Enquanto utilizando Delphi XE6, o DANFE estava normal. Ao compilar o mesmo sistema em Delphi Seattle (com FastReport 5.1.5), com os mesmos componentes ACBr (sem atualizar via svn), o DANFe começou a sair conforme imagem anexa. Ou seja: - Código de barras aparecendo em cima da mensagem de consulta de autenticidade (a nota não está em contingência); - Antes no Delphi XE6, quando a nota tinha um produto apenas, a borda do quadro de itens da nota ficava "esticada" até o quadro de dados complementares da nota. Testei no Demo ACBr e deu o mesmo problema. Debuguei e confirmei que o campo Contingencia_ID do report está em branco ao imprimir, portanto o código de barras em questão nem deveria aparecer. Desde já agradeço a ajuda, Leandro Esqueci de dizer, também, que os dados adicionais do DANFE não estão saindo (está mostrando em branco).

Senhores, Queria deixar registrado aqui a solução que achei para esse problema. Vou usar o evento AntesFinalizarRequisicao para detectar se a internet está funcionando no momento que envia o comando CNF. Se não estiver funcionando, avisa o usuário e ao invés de enviar o CNF envia um comando qualquer que não existe (XYZ por exemplo), mas deixa o ACBR finalizar o processo (apagar os arquivos temporários, etc) como se tivesse enviado o CNF. Nesse momento seu sistema tem que gravar que aquela transação não foi finalizada por conta de internet, gravando os dados para enviar o NCN logo após a internet ser reestabelecida. Detalhe: não utilizo múltiplos cartões, não sei se essa solução atenderia para quem utiliza. Segue anexo uma versão do TEF demo alterado simulando o que falei acima, para quem no futuro passe pelo mesmo problema. Sugestões para melhor tratar esse caso são bem vindas. Att, Leandro ExemploACBRTEFD_detectarinternet.rar

Tentei argumentar com o homologador que esse teste deveria ser só para quem usa a DLL deles, que tem um retorno referente ao link de internet estar funcionando, mas ele disse o seguinte: "Após o retorno do TEF indicando que a venda foi aprovada, você deve realizar a impressão do comprovante e enviar a confirmação “3ª perna”, nesse momento seu sistema deve identificar e indicar a falha na comunicação, após restabelecer a internet seu sistema deve enviar o desfazimento da transação." Enfim, não tem pra onde correr. Obrigado, Leandro

Desliguei a internet não só no momento da impressão da 2a via, mas antes de começar a primeira, durante a primeira via, etc, enfim, em vários momentos, mas não aconteceu o cancelamento da transação TEF. No site da Auttar a transação está como PENDENTE, mas na automação finalizou normalmente, como se tivesse confirmado a transação com CNF. Pelo que conversei com o Nelson (homologador) da Auttar, teria que ter tipo o tratamento de desligamento da impressora, só que para internet. A automação não deveria enviar o CNF para confirmar a venda se a internet cair no meio da impressão, tal qual acontece quando se desliga a impressora. Mas queria saber de quem já homologou com eles se fez esse teste e como tratou essa situação. Ou se não precisou fazer nada e o ACBrTEFD já tratou corretamente, aí tenho que ver o que fiz de errado aqui. Obrigado, Leandro

Bom dia senhores, Estou fazendo os testes para homologação Auttar, e tem o seguinte teste no roteiro: "Realizar uma transação de crédito a vista no valor de 905,00 utilizando um cartão com chip ou digitada, com o cartão 5111 1111 1111 8 validade 12/20 COD SEG: 123, no momento da impressão da 2ª via do comprovante desconectar a maquina da internet." Ação a ser tomada: "Após aprovar a transação, verificar na ferramenta web o status, que deve estar como PENDENTE, após estabilizar a internet a automação devera enviar a operação NCN "Não confirmação da venda e/ou da impressão". E na sequencia apresentar na tela a mensagem de TRANSAÇÃO NÃO APROVADA. Verificar na ferramenta web o status da transação, que deve estar como "DESFEITA NA AUTORIZADORA" Estou utilizando o ACBrTEFD, mas não achei nada no fonte do componente que tratasse queda da Internet. Alguém que já homologou Auttar pode me falar como fez nesse caso? Muito obrigado, Leandro

Ok, obrigado senhores. No caso é TEF Auttar, vou verificar com eles. att, Leandro

Bom dia senhores, Desculpe se isso já tiver sido discutido, mas não encontrei nas buscas. Em MG atualmente não é preciso homologar PAF-ECF. Tenho um sistema adaptado e registrado para os requisitos MG002 e agora surgiu um cliente que vai utilizar TEF. Sei que não precisa homologar TEF para registrar o PAF-ECF no site da SEF mas, em surgindo a necessidade do sistema trabalhar com TEF, preciso fazer homologação TEF? Ou posso apenas fazer os testes dos roteiros TEF e, estando tudo Ok, disponibilizar para o cliente? Desde já agradeço, Leandro

Desculpe se eu me expressei mal. Não é problema no ACBr não, eu queria uma opinião de outros profissionais em como tratam essa situação específica acima nos seus sistemas. Obrigado.

Senhores, Sempre que a Sefaz está com problema e os clientes tentam enviar a nota, o DANFE fica saindo como "sem autorização". Isso por que a Sefaz não retorna o XML com a tag procNFe, o que era o esperado já que está com problema. Infelizmente não tem como sabermos no exato momento que a Sefaz está com problema, por que o site que mostra os status dos webservices demoram a ficar amarelos/vermelhos, e enquanto isso várias notas já tentaram ser enviadas. Após a Sefaz ficar normal, se tentar reenviar essas notas, vai dar duplicidade. Eu queria saber dos senhores como fazem pra tratar esse problema em seus clientes. Tem aquele método do ACBrNFe que faz o download de uma NFe pela chave, mas só funciona quando ela está no servidor da Sefaz nacional, e às vezes demora pra os servidores sincronizarem. O que tenho feito é baixado manualmente o XML dessas notas problemáticas no site da Sefaz do estado, substituindo o XML que está com problema e mandando o ACBR gerar o DANFE de novo. Qualquer sugestão é bem vinda. Desde já agradeço, Leandro

Amigos, consegui descobrir os erros. 1) Programar forma de pagamento: tinha a ver com espaços em branco ao retornar as formas de pagamento da impressora (faltou um trim) , dando erro ao tentar registrar uma forma que já estava cadastrada; 2) Programar rel. gerencial: dava erro por que já tinha atingido o máximo de relatorios gerenciais suportados pela impressora; 3) Dava erro por que eu chamava um comando para tentar cancelar cupom não fiscal antes de cancelar o cupom fiscal. Esse primeiro comando já cancelava o cupom fiscal, dando erro ao chamar o segundo comando, pois o cupom já estava cancelado. Obrigado de qualquer forma, Leandro

Bom dia senhores, Estou tendo o seguinte erro com uma SWEDA ST200 ao tentar programar forma de pagamento, programar relatório gerencial, cancelar cupom (foi o que testei até agora). Erro (0058) Comando ou operação inválida! Segue o log em anexo caso possam me dar uma força. Li mas não achei solução nos outros tópicos relacionados a esse erro. O interessante é que o erro deu ao cancelar o cupom, mas ele foi cancelado (saiu o cancelamento na impressora). Estão usando USB emulando uma serial (COM5). Qualquer ajuda é bem vinda. Desde já agradeço, Leandro ACBR.log