Paulofrlima

Na verdade é uma pratica bem comum para o setor de Contabilidade.

Bagunçava sim... Estava com a cadeia toda quebrada, pois o último NSU entregue ao meu sistema não era mais o último NSU que o SEFAZ disponibilizou para o CNPJ. Este é o ponto da questão. Pois outro programa entrava na sequencia e baixava outros NSU´s antes de mim. Assim, toda vez que eu tentava passar meu ultimo NSU o SEFAZ retornava com erro "Rejeicao: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitacoes subsequentes. Tente apos 1 hora)". Algumas vezes eu conseguia entrar e baixar, pois já havia se passado 1 hora que meu sistema e a segunda aplicação haviam consumido o WS. Perceba que é exatamente o comportamento que sua aplicação está recebendo... Ou seja: para o SEFAZ não interessa qual IP/aplicação está buscando as informações, conforme NT ela disponibiliza por CNPJ. Se existe mais de uma aplicação concorrendo com mesmo CNPJ esta nova versão (SEFAZ) não faz distinção e bloqueia informando que você já baixou recentemente estes documentos...

Olha... minha situação era EXATAMENTE igual a de vc´s... Busquem... Revirem... pois tem outra aplicação fazendo concorrência com a de vcs... Minha aplicação está rodadndo de 16/03 sem nenhuma rejeição a cada 1:10h... O pessoal do SEFAZ me confirmou que haviam acessos indevidos, me indicando inclusive os horários de acessos. Inicialmente também rejeitei esta hipótese pois o contator "jurava" não fazer acessos... Pois é a maquina dele fazia e ele nem sabia...

Não, se perceu a cadeia vc deve aplicar "0" ou um NSU muito antigo (abaixo de 90 dias)... Suponha: ultimo nsu consultado corretamente pela sua aplicação: 23455. e sua aplicação irá aguradar 1h para buscar novos... Uma segunda aplicação entrou em paralelo e baixou arquivos de 23455 a, suponhamos, 23460. Quando sua aplicação tentar consultar o 23455, ou seja um NSU relativamente recente, vc toma rejeição, pois para o SEFAZ o CNPJ já baixou recente estes documentos...

"Mas, a contabilidade usa o certificado da empresa, isso iria resolver?" Não seria prático, pois todos os seus fornecedores teriam que colocar o CNPJ/CPF´s dos atores envolvidos (no caso o CNPJ do seu contator. Pois aí o contator acessaria pelo CNPJ do contator com o certificado do contador e não pelo CNPJ da empresa com certificado da empresa. De acordo com a NT cada CNPJ pode ter somente 1 acesso via tag distNSU. Sugestão: Faça um único recebimento de 100% da documentação. Internamente redistribua aos atores interessados (ao contador por exemplo).

Amigos, Compartilhando informações: Aqui mesmo caso, SEFAZ retornou chamados informando acesso indevido. Fiquei monitorando o trafego de saída para o IP do SEFAZ. Descobrimos que um "mensageiro" utilizado por um programa de terceiros aqui também estava acessando o serviço distribuicaoDFe com uma frequencia de 20 min (Obviamente bloqueando tudo)... Desligado o mesageiro tudo voltou ao normal.

Boa tarde, amigos, Desculpe, estava tratando outros assuntos e fiquei afastado... Segue link: https://www.gov.br/receitafederal/pt-br/canais_atendimento/fale-conosco/empresa/sped/nf-e Abaixo última conversa com eles: //------------------------------------- Prezado, Para o caso 1--> foi identificada a situação que estava causando o problema e já ajustada. Para o caso 2 --> é mesmo uso indevido do usuário. Só tem um IP consultando. Mas, desde às 12h aparentemente não estão recebendo uso indevido. Acredita-se que vocês tenham realizado os ajustes necessários. Atenciosamente, Equipe NF-e Bom dia, O setor de contabilidade é interno aqui na XXX. Testei a hipótese de um possível segundo acesso. Somente uma maquina está fazendo o acesso. Um detalhe, somos um grupo empresarial assim, faço a consulta em mais de um CNPJ. Para o CNPJ: XXXXXXXXXXXXXX Estou recebendo o cStaT=656 - Erro: Rejeicao: Consumo Indevido (Deve ser aguardado 1 hora para efetuar nova solicitacao caso nao existam mais documentos a serem pesquisados. Tente apos 1 hora) em vez de receber o cStaT=137 - Nenhum Documento. Estou respeitando o tempo de 2 horas entre consultas. Fiz um acesso via TAG: consNSU e o sistema me retornou maxNSU = ultNSU confirmando não haver mais documentos. Para um terceiro CNPJ (XXXXXXXXXXXX) não foi feito nenhum acesso desde sexta, hoje pela manhã já recebi a rejeição: cStaT=656 - Erro: Rejeicao: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitacoes subsequentes. Tente apos 1 hora) Tem mais algo que eu possa fazer? No aguardo,

Bom dia, Aqui segue o mesmo erro... Segue retorno do SEFAZ: //---------------------------- Prezado, Como a mensagem de bloqueio informa que a sequência de NSU não está sendo seguida e você acredita não ter quebrado a cadeia, a hipótese possível que geralmente ocorre é que há mais de um IP acessando o disNSU pela empresa, com sequência de NSU distinta. Verifique se não tem outra área da empresa/prestador de serviços com certificado para acessar o serviço. //---------------------------- A contabilidade é interna aqui, somente eu estou acessando... Tentarei contato novamente com SEFAZ...

Este é o padrão de erro aparente... Protocolo aberto, mas acredito que só na segunda...

Pois é o problema é que continua retornando rejeição quando consultado UltNSU com ultNSU = 0 (obviamente aguadando o tempo "de castigo" acima de 1 hora). Os outros serviços funcionam corretamente (por chave e NSU específico) dentro do limite de 20 pesq/h.

Não é, estou com o mesmo problema... Tentei ajustar o "Nº de Tentativas" para 1, mas estou com o mesmo problema...

Olá Suzana, Poderia explicar melhor a sua solução? onde se faz este ajuste?

Obrigado pela ajuda!! Com essa atualização o problema parou.

Sim, tentei sim, mas meu nível de conhecimento não é tão profundo a ponto d econseguir interceptar este possível erro, por isso estou apelando ao forum.

Sim, atualizo pelo SVN a pasta ACBr toda, e incluvise, baixei 100% novamente para ter certeza que não havia ficado nada para trás. Não ocorreu nenhum erro de compilação essa é a questão...

Bom dia, Desde a últimas 03 atualizações do ACBrLibNFe (Versões dll: 0.4.6.90, 0.4.6.91, 0.4.6.92 ) venho notando um comportamento estranho quanto tento finalizar a DLL em C++. Em resumo: Me conecto a DLL – Retorno: OK Inicializo a Biblioteca pelo método “NFE_Inicializar” – Retorno: OK Uso métodos diversos da DLL – Retorno: OK Finalizo a Biblioteca pelo método “NFE_Finalizar” – Retorno: OK Ao tentar Desconectar a DLL – Retorno: Erro Para ser mais específico quando chamo o “FreeLibrary()” o compilador retorna uma falha: “Project C:\20 - Diversos \Project1.exe faulted with message: 'access violation at 0x04dac502: read of address 0x000fc041'. Process Stopped. Use Step or Run to continue.” Até a versão da dll 0.4.6.89 não aparecia esse erro e sistema funcionava corretamente. A única mudança que fiz foi substituir a DLL pelas versões mais novas que compilei via Lazarus. Por acaso o método “NFE_Finalizar” não estaria deixando algum “processo ativo dentro da DLL” provocando sua violação no momento em que eu tento desconectar a DLL? Log: 10/07/20 09:26:10:218 - TLibNFeConfig.AplicarConfiguracoes: C:\Diversos\ACBrLibConfig.dat 10/07/20 09:26:10:218 - Travar 10/07/20 09:26:10:228 - TLibNFeConfig.AplicarConfiguracoes - Feito 10/07/20 09:26:10:228 - Destravar 10/07/20 09:26:10:228 - TLibNFeConfig.Ler - Feito 10/07/20 09:26:10:238 - Destravar 10/07/20 09:26:10:238 - LIB_Inicializar( C:\Diversos\Certificados\ACBrLibConfig.dat, ************************** ) 10/07/20 09:26:10:238 - ACBrLibNFE - 0.4.6.92 10/07/20 09:26:10:258 - LIB_Nome 10/07/20 09:26:10:258 - Nome:ACBrLibNFE, len:10 10/07/20 09:26:10:258 - SetRetorno(0, ACBrLibNFE) 10/07/20 09:26:10:258 - LIB_Versao 10/07/20 09:26:10:268 - Versao:0.4.6.92, len:8 10/07/20 09:26:10:268 - SetRetorno(0, 0.4.6.92) 10/07/20 09:26:11:568 - NFE_StatusServico 10/07/20 09:26:11:578 - Travar 10/07/20 09:26:11:868 - SetRetorno(0, [Status] CStat=107 CUF=41 DhRecbto=10/07/2020 09:26:11 Msg=Servico em Operacao TMed=1 VerAplic=PR-v4_6_4 Versao=4.00 XMotivo=Servico em Operacao XObs= tpAmb=1 ) 10/07/20 09:26:11:868 - Destravar 10/07/20 09:26:15:338 - LIB_Finalizar 10/07/20 09:26:15:343 - Finalizar

Resolvido... com os ajustes estavam corretos usei recuso da linguagem... obrigado!

Oi Rafael, Obrigado pela resposta, testei as duas configurações UTF-8 e ACSII, porém ambas me retornaram mesmo resultado com erros gramaticais.

Bom dia, Estou consumindo as DLL's do ACBrlibNFe em C++ Builder 6 com sucesso. Porém me deparei com um problema: erros de acentuação e “ç” tanto em respostas da DLL quanto em respostas do SEFAZ. Me corrijam se eu estiver errado, mas pesquisando aqui no fórum, percebi que a DLL não trata XML retornados (via DistribuicaoDFe). Sendo assim, o ajuste no arquivo de configuração ini (RetirarAcentos=0 ou RetirarAcentos=1) não produz efeito. Todavia, forcei a passagem errada de uma Chave de NF-e e a DLL me retornou “Chave inválida”. Testei mudar a opção CodificacaoResposta=0 (UTF-8) para CodificacaoResposta=1 (ANSI) mas sem mudanças no resultado. Estou errando ou omitindo em mais algum ajuste? Em anexo o arquivo de configuração que estou usando. ACBrLibConfig.ini

Ótimo! Obrigado pela indicação de documentação e dica técnica! Obrigado pela dica, irei na linha do "DistribuicaoDFePorUltNSU', além de descobrir alguma nota sem consentimento notei que este processo será muito, mas muito mais eficiente... pois mesmo antes de chegar o fisico+DANFE já terei todas minhas "regras de négócio validadas" que, neste ponto, é mais importante pra mim do que o elemento fiscal que hoje já é tratado. Ou seja, consegurei alinhar as inconsistências de Compra bem antes do recebimento físico.

Sim, fiz isso, foi um dos primeiros posts lidos. Com base nele que formulei as minhas regras de negócio. Perfeito, fiz uma leitura do docto nos pontos conforme orientado, mas como eu havia dito, as funções ACBr estão retornando valores corretos. Como o processo é síncrono havia entendido que o XML já ficaria disponível logo após o "OK" do WS Sefaz, o que não parece ser verdade. Com base nisso partirei para a verificação da existência de dctos novos e executar a "ciência prévia". Pois após uma segunda análise é até melhor, pois poderei as minhas regras de negócios antes mesmo de chegar o fisico + DANFE in-loco. Porém, me sugiu uma nova dúvida: Na NT2014.002 v1.02 item "3.13. Recomendações Para Evitar o Uso Indevido" ressalta o mau uso de loops de verificação. A minha intenção é automatizar todo o processo de ciência e baixar o xml. Assim preciso de uma dica técnica: qual seria uma frequência ideal (1 min, 5 min, 30min, 1h, 1 dia, etc) para executar as verificações de disponibilidade do xml uma vez q já foi validada a sua ciência sem cair nas regras de mau uso.

Boa tarde, Inicialmente parabéns pelo projeto ACBrMonitor! Decidi utilizá-lo em função da praticidade de integração com meu IDE. Estou tentando baixar os xml´s destinados a um CNPJ. Porém, percebi que existe um delay variável entre a resposta do servidor me informando sobre a Manifestação da Ciência da Emissão (obrigátorio para baixar o xml NF-e) e a disponibilidade para baixar o XML. Minha rotina: 1) Recebimento a Mercadoria + DANFE. 2) Leio Chave da DANFE e utilizo comando NFE.EnviarEvento(Evento.ini) para enviar Manifestação da ciência. 3) Aguardo o retorno do WS informando o recebimento da Manifestação, se a resposta for positiva: 4) Baixo o XML através do comando NFe.DistribuicaoDFePorChaveNFe(cUF, cCNPJ, aChNFe); 5) Executo ações de validações com a Ordem de Compra que solicitou o processo (Processo interno de minhas regras de negócio). Em 100% das minhas tentativas (entre ontem e hoje) recebo inicialmente uma resposta (para o passo 4) quanto tenho baixar o xml logo após receber o retorno do WS previamente manifestado: OK: [DistribuicaoDFe] CStat=137 CUF=0 DhRecbto=30/12/1899 Msg=Nenhum documento localizado VerAplic=1.2.0 Versao=1.01 XMotivo=Nenhum documento localizado arquivo= dhResp=12/11/2019 09:17:20 indCont=1 maxNSU= tpAmb=1 ultNSU= Aguardando algum tempo, se tento baixar o XML ele me retorna cStat=138 com XML correto. Lí em diversos posts aqui no forum sobre esse possível delay do Sefaz, porém o mais recente é de 12 de jan. de 2019. Nestes Posts, salvo engano, não encontrei nenhuma solução para o caso de se baixar logo que se retorna a resposta da manifestação. Entendo perfeitamente que o problema não é no ACBrMonitor, pois ele faz a ponte corretamente me retornando respostas o WS. Lí como melhor solução, até aquele momento de jan de 2019, que uma possível solução seria manifestar previamente a NFe e deixá-la disponível para quando a DANFE chegasse in-loco. Assim pergunto: 1) A rotina que uso acima estaria errada em algum ponto? Estou esquecendo algum passo importante? 2) Ainda permanece como melhor opção manifestar previamente para qdo chegar a DANFE estar já manifestada a ciência? A importãncia de se ter o XML (além das jurídicas impostas) é que valido as Ordens de Compra que geraram a NFe. Dessa forma, no meu mundo ideal, a rotina de baixar pela chave no momento da chegada da DANFE atenderia o processo. PS.: Entendo que a responsabilidade do envio do XML é do emissor da NF. Mas sabemos que depende de ação humana em um cadastro correto das informações de envio, o qual não temos domínio e em aprox. 30% dos casos está incorreta... No aguardo, Paulo

Bom, Obrigado Daniel/Rafael! Consegui utilizar a dll. Daqui pra frente virão os erros de utilização, mas para este ví mto material disponível... Grato pelo tempo disponibilizado!

Sim... já havia encontrato este tutorial e estou focado nele... Já consegui transportá-lo para os dados do ACBr, mas não estou muito certo das respostas que o sistema me retorna. Um ponto positivo é que as funções estão me retornando "0".. rsrsrs indicando o caminho correto... Obrigado pela ajuda, pois material sobre bcb nos dias atuais são bem raros, por isso postei para ver se alguém já passou pelos mesmos problemas.

Sou Eng. Mecânico, tenho a programação como um hobby. Programo em c++ a algum tempo (auto ditada), mas não sou mto familiarizado com consumo de dll's. Sei que será só uma questão de tempo para eu aprender. Os programas que desenvolvo estão mais voltados para alguma solução técnica na minha área, assim acabam sendo "programaticamente" fáceis de implementar, pois trata-se de matemática/física, entradas, saídas e gravação dem bancos. Mas agora surgiu uma necessidade no consultório de minha esposa em que eu queria implementar onde algumas ferramentas da biblioteca ACBr seria bastante úteis. Minha versão do BCB é muito antiga, adquiri a mais de 10 anos. Não tenho inteção de fazer upgrades pois não há essa necessiade no momento.