Italo Giurizzato Junior

Bom dia Jose, Para mim é problema na SEFAZ-Virtual do RS.

Joangele, Configure o Monitor para a versão 2.5.0 (ve02_05_00) e tente novamente.

Hudson, No visual, não encontrei nada que pudesse estar gerando o erro, as URLs são iguais e o parâmetro ( p ) tem a mesma quantidade de caracteres. A nota foi enviada para o ambiente de produção, o idCSC e o CSC também são do ambiente de produção?

Favor atualizar os fontes e faça novos testes.

Bom dia Thiago, Peço que atualize os fontes, note que fiz uma alteração no arquivo Recife.ini, comente as linhas que você acrescentou na unit ACBrNFSeWebServices e faça um novo teste usando o novo arquivo INI do provedor. Fico no aguardo de um retorno.

Bom dia Mateus, Essas empresas são de cidades diferentes, mas atendidas pelo mesmo provedor? Se sim, lembre-se que esses provedores não conseguem manter um padrão para todas as cidades atendidas por eles. Portanto isso é normal ocorrer. Logo a sua aplicação, vai ter que ter uma opção de configuração que determina a geração ou não dessa informação no XML.

Bom dia mcob, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia, Muito obrigado pelo retorno, vou envia a sua colaboração para o repositório.

Bom dia, Se possível, poderia anexar os XML de envio e de retorno dos testes pelo ID e pelo Recibo? Quero comparar com o manual para ver se descubro algo de errado na geração dos XML. Quanto ao problema Timeout, acredito que seja falha no servidor do SPED que esta não esta dimensionado corretamente para suportar a carga que esta recebendo.

Bom dia Werley, Você esta com todos os fontes de todas as pastas atualizados? Reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 deixando marcado a opção para apagar os arquivos antigos? Fiz um teste esses dias a traz e o envio ocorreu sem nenhum problema.

Bom dia Werner, Vamos aos tipos de situação: Situação: 1 = Não Recebido 2 = Não Processado 3 = Processado com Erro 4 = Processado com Sucesso Se esta retornando 2, significa que o lote foi recebido mas se encontra na fila para o processamento, neste caso você deve aguardar alguns segundos e realizar uma nova consulta.

Bom dia Arturo, Faça o seguinte, em ambiente de homologação envie uma nota com o grupo <infRespTec> para todas as UFs que você tem clientes. Se todas elas aceitarem as notas, as chances de aceitar também em ambiente de produção é grande. Ou você parametriza a geração desse grupo, deixa a principio para não gerar o grupo. Se a UF xyz recusar a nota (em ambiente de produção) por falta do grupo, você muda a parametrização para gerar.

Bom dia Hudson, Quero entender o que esta ocorrendo. 1. A nota foi gerada e enviada para SEFAZ e esta autorizou a mesma (conforme consta o protocolo de autorização no XML da nota que você anexou). 2. É possível realizar a consulta da mesma pela chave via Site da SEFAZ. 3. Se tentar ler o QR-Code impresso na nota através de um leitor de QR-Code ocorre erro. Qual é o erro que ocorre? Como esta a qualidade de impressão do QR-Code no papel? Já tentou trocar o app que faz a leitura do QR-Code por outro?

Joangele, Qual é o erro?

Bom dia Carlos, Me tira uma duvida, você desenvolve em qual linguagem? Pois em outro tópico você esta com uma certa dificuldade na instalação dos componentes no Delphi. Eu no seu lugar procuraria reescrever a rotina que gera o arquivo TXT no layout da SEFAZ (agora é o SEBRAE) para gerar no layout do ACBr, pelo simples fato que esse sem duvida sempre vai estar atualizado com as últimas mudanças.

Bom dia Carlos, Você deve usar o ACBrInstall_Trunk2 para instalar os componentes, a instalação manual via pacotes é um pouco complicada e requer conhecimento das dependências entre os pacotes. Como você instalou o Fortes Report no Delphi ao instalar os componentes a minha sugestão é marcar todos os componentes, exceto os referente ao Fast Report.

Bom dia Joangele, Você não disse qual ou quais os erros que estão ocorrendo ao enviar o evento 2200.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Anderson, Ainda não esta disponível o serviço de DistribuicaoDFe para o BPe, acredito que em breve vai estar. Mas lembre-se, quando esse serviço se tornar disponível o emitente do BP-e não vai conseguir baixar o XML, com certeza somente o passageiro. Reimprimir o DABPE em um local diferente não entendi, de um exemplo pratico dessa situação. Quanto a perda, é complicado, como disse antes, esta sendo perdido um documento fiscal, logo o emitente tem por obrigação legal guardar o XML pelo período estipulado na legislação. Sendo assim é importante ter cópia de segurança do XML em um HD externo, Nuvem, Banco de Dados, etc.

Boa tarde Ancker, Muito obrigado pela correção, já enviei para o repositório.

Daniel, Se levarmos em consideração os nomes dos arquivos XML temos o numero do lote que "prova" que o retorno se refere ao envio. Mas infelizmente no XML de retorno não consta o numero do lote que se encontra no XML de envio do lote. E como a chave da nota que consta no retorno é diferente da chave da nota que consta no lote, a SEFAZ pode alegar que pegamos o retorno de uma outra nota ou outra empresa e estamos comparando com o que foi enviado. Outra informação que podemos comparar é o DigestValue, inclusive são essas duas informações (Chave e DigestValue) que o componente verifica para decidir se vai atualizar o XML da nota enviada com o retorno da SEFAZ (quando a nota é autorizada). E neste caso o DigestValue também é diferente. Existe uma semelhança quanto ao horário de emissão da nota que consta no XML e o do retorno. Na nota temos: 2019-04-09T15:31:02-04:00 No retorno temos: 2019-04-09T15:31:24-04:00 Essa diferença de 22 segundos, pode ser o tempo que o PDV demorou para realmente enviar o lote e mais o tempo de demora de processamento da SEFAZ. Resumindo: tomar como base os nomes dos XML e apenas pelo horário de emissão da nota e o que consta no retorno, não são argumentos fortes para dizer a SEFAZ que ela esta com problemas.

Bom dia, Por favor preste mais atenção ao postar, pois esse tópico se refere ao componente ACBrMDFe que não tem nada haver com NFC-e. Poste novamente o seu problema no tópico correto que se refere ao componente ACBrNFe. O tópico será fechado por ser muito antigo.

É a primeira vez que alguém relata esse tipo de problema: a SEFAZ rejeitar uma nota e a chave não ter nada haver com a nota enviada. Se isso ocorreu, chego a conclusão que o problema é na SEFAZ.

Isso eu percebi, mas você não respondeu a minha pergunta.

Bom dia, A sua aplicação roda em uma rede local? Ou em um servidor fora do estabelecimento comercial que chega emitir notas de varias empresas?