Milton Ferreira
-
Total de ítens
52 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Milton Ferreira
-
-
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.
-
Pessoal, problema solucionado.
SEFAZ parou de enviar a msg Falha no SChema XML.
Aparentemente algo do lado deles mesmo.-
1
-
-
@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!
-
3
-
-
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
-
14 minutos atrás, Daniel InfoCotidiano disse:
@Milton Ferreira
Não teve nenhuma atualização do windows ou algum ponto de restauração foi executado?
Qual a lib está tendo problema?
Não sei se usa certificado, caso positivo, nao teve troca de certificado ?
Verificou os caminhos do log?
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! -
4 minutos atrás, Daniel InfoCotidiano disse:
Boa tarde @Milton Ferreira
A dll está correta ? é a mesma que utiliza em outras aplicações ?
Não está usando ST no MT ou vice versa?
O caminho da mesma esta correto?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? -
2 horas atrás, Diego Foliene disse:
Boa tarde @Milton Ferreira!
Após análise e testes pudemos constatar que a classe Java na versão ST estava com um parâmetro a mais no bind do método da Dll.
Foi enviado ao SVN na Rev-30871 alteração visando corrigir.
Por favor, queira atualizar para que possa realizar novos testes e reportar qualquer problema.
Atualizado e funcionando, muito obrigado pela atenção de sempre!
-
1
-
-
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!-
2
-
-
1 hora atrás, Daniel InfoCotidiano disse:
Boa tarde @Milton Ferreira
Veja regra de validação:
A propriedade cNF vc salva no banco para usar caso necessite reenviar, consultar a nota.. etc?
Esta gerando com o mesmo cNFE da nota anterior a rejeição?
Se puder anexar o log completo ou nos enviar para [email protected]
No corpo da mensagem, favor colar o link deste post para que possamos identifica-lo
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?
-
Desculpem me, achei meu erro grotesco, esqueci de adicionar o TPEvento.
Resolvido-
1
-
-
Olá,
Estou com problema na emissão de CC-e pela Lib Java, está retornando um erro REGEX e não estou conseguindo achar o motivo e o respectivo campo, segui as orientações para geração do INI do manual: https://acbr.sourceforge.io/ACBrMonitor/CartadeCorrecao.html, alguém poderia me ajudar?
Segue log:15/09/23 10:01:24:990 - ACBrLibNFE - 0.4.6.238
15/09/23 10:01:33:757 - NFE_LimparLista
15/09/23 10:01:33:757 - Travar
15/09/23 10:01:33:758 - SetRetorno(0, 0 NFe(s) Carregada(s))
15/09/23 10:01:33:758 - Destravar
15/09/23 10:01:33:759 - NFE_CarregarEventoINI("[EVENTO][LF]idLote=24[LF][EVENTO001][LF]cOrgao=31[LF]CNPJ=07932214000145[LF]chNFe=31230907932214000145550010000005471098528011[LF]dhEvento=15/09/2023 10:01:33[LF]nSeqEvento=1[LF]versaoEvento=1.00[LF]xCorrecao=TESTE CARTAO CORRECAO" )
15/09/23 10:01:33:760 - Travar
15/09/23 10:01:33:761 - SetRetorno(0, 1 Evento(s) Carregado(s))
15/09/23 10:01:33:761 - Destravar
15/09/23 10:01:33:762 - NFe_EnviarEvento(24 )
15/09/23 10:01:33:763 - Travar
15/09/23 10:01:33:783 - Destravar
15/09/23 10:01:33:784 - SetRetorno(-10, Falha na validação da Mensagem do Evento: --> 1839 - Element '{http://www.portalfiscal.inf.br/nfe}tpEvento': [facet 'pattern'] The value '-99999' is not accepted by the pattern '[0-9]{6}'.
)Agradeço desde já.
-
3 horas atrás, Alexandre de Paula disse:
Consegue configurar o log em nivel paranoico?
Configure também o SalvarWS e o PathSalvar. Repita o teste e nos envie o log e os arquivos de envelope.
Obrigado @Alexandre de Paula, com sua ajuda consegui resolver aqui.
Esse problema aconteceu em produção e como não tem console, recorri ao Log e consequentemente achei que o nível 3 apareceria em caso de Rejeição que foi o caso dessa nota em específico com o número de faixa já utilizado.-
1
-
-
1 hora atrás, Alexandre de Paula disse:
Bom dia.
O comando que você está enviando é NFE_Inutilizar ou NFE_InutilizarNFE. Veja a documentação abaixo.
Verifique a possibilidade de enviar o CNPJ sem a formatação (somente numeros).
https://acbr.sourceforge.io/ACBrLib/NFE_Inutilizar.html
Obrigado por retornar, utilizo a lib Java e é chamado a função:
acbrNFe.inutilizarenviei somente numero no CNPJ conforme sua sugestão e manual (Log abaixo), mas o problema persiste:
12/09/23 09:19:29:152 - ACBrLibNFE - 0.4.6.238
12/09/23 09:19:29:731 - NFE_LimparLista
12/09/23 09:19:29:738 - NFE_InutilizarNFe(07932214000145,Falha comunicacao de retorno,2023,65,1,475,475 ) -
Olá,
estou com um problema que ao enviar comando de inutilização nada acontece, segue trecho do log:
11/09/23 14:23:18:954 - NFE_LimparLista
11/09/23 14:23:18:959 - NFE_InutilizarNFe(07.932.214/0001-45,Falha comunicacao de retorno,2023,65,1,475,475 )
11/09/23 14:28:19:376 - NFE_LimparLista
11/09/23 14:28:19:378 - NFE_InutilizarNFe(07.932.214/0001-45,Falha comunicacao de retorno,2023,65,1,475,475 )
11/09/23 14:33:19:645 - NFE_LimparLista
11/09/23 14:33:19:646 - NFE_InutilizarNFe(07.932.214/0001-45,Falha comunicacao de retorno,2023,65,1,475,475 )
Alguém tem alguma dica do que pode estar acontecendo? Detalhe, todos os demais comandos funcionando perfeitamente.Agradeço desde já.
-
12 minutos atrás, Italo Giurizzato Junior disse:
Bom dia Milton,
Primeiramente, se ocorre algum erro de internet, já mais devemos enviar novamente a nota, pelo simples fato de não sabermos em que momento ocorreu o erro.
Uma vez que esse erro pode ter ocorrido no envio ou no retorno.
A lógica é bem simples, ocorreu erro de internet, carrega o componente com o XML da nota e execute o método Consultar.
Se o erro ocorreu no retorno teremos como resposta o resultado do processamento da nota que pode ser autorizada ou rejeitada.
Se retornar autorizada, automaticamente o XML vai ser atualizado com o protocolo de autorização, passo seguinte é imprimir o DANFE.
Se retornar rejeitada, ai devemos fazer as devidas correções e enviar a nota novamente.
Agora se o erro ocorreu no envio, ao realizar a consulta teremos a rejeição: 217 - NF-e não consta na base de dados da SEFAZ.
Com essa rejeição temos a certeza que a nota não consta na SEFAZ e que o erro ocorreu no envio, o passo seguinte é enviar novamente.
Desta forma você não vai ter mais a rejeição de nota em duplicidade.
Detalhe importante:
O procedimento acima pode ser adotado por quem usa o Componente ou a Lib ou o Monitor.
Olá Itallo,
Alterei o processo e deu certo.
Fiz a consulta carregando o XML sem protocolo e obtive o XML posteriormente completo.
Obrigado @Italo Giurizzato Junior e @Alexandre de Paula!-
1
-
-
17 minutos atrás, Alexandre de Paula disse:
Olá @Milton Felipe,
Fiquei com umas dúvidas em relação a sua operação.
Você está falando de NFe ou de NFCe?
Na NFe no caso de contingencia você muda de ambiente de emissão e passa a emitir no ambiente de contingencia até a produção voltar. Nesse caso o processo de emissão/autorização é igual, só muda o ambiente.
No caso da NFCe a emissão em contingencia não envolve a transmissão da nota enquanto o ambiente está indisponível, então você não tem que ficar tentando transmitir nada durante as emissões. Quando a conexão com o ambiente de NFCe é reestabelecida aí sim você realiza todo o processo de transmissão dos cupons emitidos antes em contingencia.Olá @Alexandre de Paula, agradeço o retorno.
Essa preocupação é somente com a NFC-e.
O processo da contingência é feito sim de forma off-line, se uma NFC-e é enviada e o servidor da SEFAZ está indisponível ele envia essa nota para o limbo (Inutilização ou Cancelamento por substituição) e emite a mesma nota em contingência e mantêm o sistema no modo contingencia off-line por 20 minutos, logo todas as notas nesse intervalo serão emitidas em modo contingencia off-line e o processo se repete dessa forma, esse processo está claro e funciona bem.
O problema não está na emissão, está em algumas situações na autorização posterior:
O sistema automaticamente com intervalo de 15 minutos verifica se existe alguma NFC-e em contingência, se houver ele envia para autorização, se é retornado um erro, o processo é parado e retornado 15 minutos depois. O que acontece é que às vezes, principalmente após um grande período de indisponibilidade da SEFAZ, quando o servidor volta ele parece ficar sobrecarregado, então quando a NFC-e é enviada para autorização o sistema não recebe retorno, porém ela foi autorizada.
Como o sistema parou de enviar, como dito acima, depois dos 15 minutos ele tenta enviar novamente e é retornado um erro de duplicidade, pois a autorização, apesar de não ter sido recebida como resposta, foi realizada. Com o ACBR Plus essa nota era consultada e na consulta o XML completo era retornado, pela LIB o XML completo não é retornado, então gostaria de uma sugestão de uma maneira de "completar" o XML com o protocolo de autorização.-
1
-
-
Olá,
trabalhamos com o ACBR Plus há bastante tempo, agora estamos finalizando a migração para a Lib e estou verificando uma demanda anterior e gostaria de uma ajuda se possível.
Começo dizendo que a maioria de nossos clientes estão em MG então, como sabemos, precisamos tentar antecipar alguns problemas antes de virar para produção e a minha dúvida é a seguinte:É sabido que o servidor da SEFAZ MG passa por muitas instabilidades e há um tempo atrás tivemos um problema que algumas NFC-es emitidas em contingência ficaram com o XML sem o protocolo de autorização mesmo autorizadas.
O problema ocorre porque as vezes a nota emitida em contingência é enviada para autorização automaticamente em segundo plano e o tempo de resposta da SEFAZ é maior que o TimeOut ou é retornado algum erro de indisponibilidade, logo a nota não é autorizada no banco de dados e nas tentativas posteriores retorna nota duplicada.
Usando o ACBR Plus contornamos esse problema da seguinte forma:
- Ao retornar duplicidade com o numero da chave o sistema busca na pasta o XML correspondente, ao consultar, o XML completo é retornado, dessa forma atualiza-se as informações gerais no banco de dados inclusive o XML.
Pois bem, gostaria de uma sugestão para contorno desse problema pela LIB, pois quando usamos o comando de consulta o XML completo não é retornado. -
Vou tentar entender onde estou errando aqui, pq realmente não aparece, posso ter errado algo na importação e configuração da Lib.
Segue print pra mostrar que o método não aparece:
-
ACBrLibNFE=0.4.6.199
Rejeição Data-Hora de Emissão posterior ao horário de recebimento
em NFe/NFCe - Nota Fiscal Eletrônica
Postado · Editado por 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!