Milton Ferreira

Pessoal, encontrei o problema aqui. O horário do servidor da empresa estava incorreto, a emissão do nosso sistema busca o horário do servidor e não da maquina local. Obrigado!

Olá, bom dia! Estou com problema em único local até agora relatado, com a Rejeição Data-Hora de Emissão posterior ao horário de recebimento, no log realmente o envio está sendo realizado com uma hora a mais. No windows não está marcado a opção do horário de verão automático e Fuso Brasilia -03:00. O horário do Windows está correto e a configuração do TimeZone.Modo = 0 conforme prints. Alguém tem alguma sugestão do que pode estar ocorrendo? Segue log para analise. ACBrLibNFE-20240401 2.log

Pessoal, problema solucionado. SEFAZ parou de enviar a msg Falha no SChema XML. Aparentemente algo do lado deles mesmo.

@Juliomar Marchettitinha baixado ontem.. Vi agora depois do seu post que atualizou para ACBrLibNFE - 0.4.6.275 e realmente não aparece mais a msg de erro, obrigado! O problema motivo desse post continua mesmo com a lib mais nova, SEFAZ respondendo posto aqui pra ajudar os demais e agradeceria se pudessem me reportar a solução se alguém obtiver sucesso.

Estou efetuando vários testes enquanto aguardo o retorno da SEFAZ e ao atualizar a LIB agora é retornado "Valor string inválido para TmotRedAdRem: 0" Alguem pode me ajudar quanto à isso?

@Juliomar Marchetti, obrigado pela resposta, mas a atualização dos Schemas foi a primeira providência que tomamos e infelizmente sem sucesso. Enviei uma msg no portal da Sefaz, vamos ver o retorno deles. Enquanto isso, continuemos na contingência. Obrigado!

Bom dia, pessoal! Estou com problema para emissão de NFC-e em MG (Lib Java) desde ontem retornado Falha no schema XML em todas as NFC-es, curioso é que se vc consulta a nota, mesmo depois da rejeição ela consta como autorizada, como pode ser ver nos anexos (Log, XML e Print). Gostaria de saber se alguém tem uma sugestão ou se é falha na SEFAZ/MG mesmo, pra variar! ACBrLibNFE-20240314.log 31240307932214000145650010000017741024212016.xml

Restaurei a imagem de backup do windows de ontem, reinstalei o PDV e rodou.. Não sei pq não tentei isso antes ao invés de ficar pelejando durante quase 2 horas. Creio que tenha sido algo que corrompeu no SO mesmo. Resolvido. Muito obrigado pela atenção!

Obrigado pelo retorno. É a mesma DLL ST que utilizo em todos os clientes, usado o mesmo pacote de instalação com os respectivos caminhos. Unica coisa de diferente nessa estação que é Windows 7, porém estava funcionando até ontem.

Boa tarde, Estou com problema com um cliente apenas que a LIB Java não funciona. Além de não executar nenhuma operação não lê o arquivo ini de configuração e no LOG fica apenas: LIB_Finalizar. Arquivo ini conferido, configuração toda ok. Estava funcionando corretamente e parou sem motivo identificado. Alguém tem alguma informação que possa me ajudar?

Atualizado e funcionando, muito obrigado pela atenção de sempre!

Boa tarde, conforme conversa iniciada por Discord e solicitação do @Diego A. Folieni segue situação ocorrendo na versão ACBrLibMDFe - 0.2.1.225. Ao utilizar acbrMDFe.enviar o retorno não vem, mas no log é gerado a resposta corretamente. #TK-4550

Obrigado pelo retorno de vocês, com a ajuda consegui entender e resolver a situação. O que acontece? Quando usava o monitor, o XML só era salvo na pasta após a autorização, então quando dava rejeição de duplicidade, o sistema buscava os arquivos na pasta e atualizava o banco de dados com o XML autorizado anteriormente, esse processo ocorria após a rejeição. Dessa forma não era preciso salvar o cNF visto que a informação já estava no XML anterior. Com a Lib, o arquivo XML é salvo na pasta antes mesmo da autorização, logo se ocorre a rejeição por duplicidade e posteriormente o sistema buscar na pasta, buscará o arquivo sem o protocolo de autorização, então o sistema gerava um novo XML, logo com outro cNF. Então coloquei o sistema para salvar cNF ainda deu erro de DigestValue ao consultar a nota pq eram arquivos com horários diferentes, então mudei a ordem das coisas. Quando a nota está rejeitada no sistema, antes de tentar realizar a emissão, ele busca na pasta de arquivos, se possuir um XML correspondente autorizado, ele apenas o consulta e salva os dados no banco de dados. Minha explicação ficou um pouco confusa, porém funcionou, aceito sugestões caso exista um processo melhor. Obrigado!

Boa tarde, Não estou enviando com o mesmo número, o processo foi migrado do Monitor para a Lib Java, no monitor não precisava de enviar o mesmo número. Há alguma diferença no processo?

Olá, boa tarde! Estou com problema SEFAZ / MG quando retorna rejeição 539 não está vindo a chave anterior para tratamento adequado. Trecho do log: 04/10/23 13:49:30:495 - Travar 04/10/23 13:49:30:495 - NFe_Enviar, Limpando Resp 04/10/23 13:49:30:495 - NFe_Enviar, Assinando 04/10/23 13:49:30:501 - NFe_Enviar, Validando 04/10/23 13:49:30:519 - NFe_Enviar, Enviando 04/10/23 13:49:30:685 - NFe_Enviar, Proces.Resp Enviar 04/10/23 13:49:30:686 - NFe_Enviar, Consultando Retorno 04/10/23 13:49:32:834 - NFe_Enviar, Proces.Resp Retorno 04/10/23 13:49:32:835 - MoverStringParaPChar. StrLen:1128, BufLen:256 04/10/23 13:49:32:835 - SetRetorno(0, [Envio] CStat=103 CUF=31 DhRecbto=04/10/2023 13:49:29 Msg=Lote recebido com sucesso NProt= NRec=310000083657035 TMed=1 VerAplic=W-3.1.39 Versao=4.00 XMotivo=Lote recebido com sucesso tpAmb=2 [Retorno] CStat=104 CUF=31 ChaveDFe=31231007932214000145550010000005481037365217 DhRecbto= Msg=Nota(s) não confirmadas:548->539-Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso Protocolo= VerAplic=W-3.1.39 Versao=4.00 XMotivo=Lote processado cMsg=0 nRec=310000083657035 tpAmb=2 xMsg= [NFe548] Id= XML=<protNFe versao="4.00"><infProt><tpAmb>2</tpAmb><verAplic>J-3.1.39</verAplic><chNFe>31231007932214000145550010000005481037365217</chNFe><dhRecbto>2023-10-04T13:49:29-03:00</dhRecbto><digVal>N0Cg3jBzWtU1BInaPPms5aGKHQA=</digVal><cStat>539</cStat><xMotivo>Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso</xMotivo></infProt></protNFe> cStat=539 chDFe=31231007932214000145550010000005481037365217 dhRecbto=04/10/2023 13:49:29 digVal=N0Cg3jBzWtU1BInaPPms5aGKHQA= nProt= tpAmb=2 verAplic=J-3.1.39 xMotivo=Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso ) 04/10/23 13:49:32:836 - Destravar 04/10/23 13:49:32:836 - LIB_UltimoRetorno 04/10/23 13:49:32:837 - MoverStringParaPChar. StrLen:1128, BufLen:1466 04/10/23 13:49:32:837 - Codigo:0, Mensagem:[Envio][CR][LF]CStat=103[CR][LF]CUF=31[CR][LF]DhRecbto=04/10/2023 13:49:29[CR][LF]Msg=Lote recebido com sucesso[CR][LF]NProt=[CR][LF]NRec=310000083657035[CR][LF]TMed=1[CR][LF]VerAplic=W-3.1.39[CR][LF]Versao=4.00[CR][LF]XMotivo=Lote recebido com sucesso[CR][LF]tpAmb=2[CR][LF][CR][LF][Retorno][CR][LF]CStat=104[CR][LF]CUF=31[CR][LF]ChaveDFe=31231007932214000145550010000005481037365217[CR][LF]DhRecbto=[CR][LF]Msg=Nota(s) n[195][163]o confirmadas:548->539-Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso[CR][LF]Protocolo=[CR][LF]VerAplic=W-3.1.39[CR][LF]Versao=4.00[CR][LF]XMotivo=Lote processado[CR][LF]cMsg=0[CR][LF]nRec=310000083657035[CR][LF]tpAmb=2[CR][LF]xMsg=[CR][LF][CR][LF][NFe548][CR][LF]Id=[CR][LF]XML=<protNFe versao="4.00"><infProt><tpAmb>2</tpAmb><verAplic>J-3.1.39</verAplic><chNFe>31231007932214000145550010000005481037365217</chNFe><dhRecbto>2023-10-04T13:49:29-03:00</dhRecbto><digVal>N0Cg3jBzWtU1BInaPPms5aGKHQA=</digVal><cStat>539</cStat><xMotivo>Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso</xMotivo></infProt></protNFe>[CR][LF]cStat=539[CR][LF]chDFe=31231007932214000145550010000005481037365217[CR][LF]dhRecbto=04/10/2023 13:49:29[CR][LF]digVal=N0Cg3jBzWtU1BInaPPms5aGKHQA=[CR][LF]nProt=[CR][LF]tpAmb=2[CR][LF]verAplic=J-3.1.39[CR][LF]xMotivo=Rejeicao: Duplicidade de NF-e, com diferenca na Chave de Acesso[CR][LF] Alguém com o mesmo problema ou tem algo que estou deixando passar?