Ir para conteúdo
  • Cadastre-se

dev botao

Erro de Data-Hora de Emissao


Ver Solução Respondido por Daniel Simoes,
  • Este tópico foi criado há 2261 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

  • Membros Pro
Postado

Logo após iniciar o horário de verão as NF-e e NFC-e estão rejeitando por causa do horário de emissão gerado no XML dando o erro:

CStat=703
XMotivo=Rejeicao: Data-Hora de Emissao posterior ao horario de recebimento

Portanto quando é gerado a data-hora no XML pelo Monitor está sendo colocado assim:

<dhEmi>2015-10-21T16:01:00-03:00</dhEmi>

..E o Sefaz processa o recebimento assim:

<dhRecbto>2015-10-21T16:01:02-02:00</dhRecbto>

Pelo que percebi a solução será trocar o GMT "-03:00" para  "-02:00" no momento em que o Monitor gera o XML, porque o GMT adotado agora no Sefaz RS é "-02:00" ou se não for isto favor informar qual procedimento adotar.

Obs.: estou usando o ACBrMonitor PLUS v0.1.10.5

  • Moderadores
Postado

Logo após iniciar o horário de verão as NF-e e NFC-e estão rejeitando por causa do horário de emissão gerado no XML dando o erro:

CStat=703
XMotivo=Rejeicao: Data-Hora de Emissao posterior ao horario de recebimento

Portanto quando é gerado a data-hora no XML pelo Monitor está sendo colocado assim:

<dhEmi>2015-10-21T16:01:00-03:00</dhEmi>

..E o Sefaz processa o recebimento assim:

<dhRecbto>2015-10-21T16:01:02-02:00</dhRecbto>

Pelo que percebi a solução será trocar o GMT "-03:00" para  "-02:00" no momento em que o Monitor gera o XML, porque o GMT adotado agora no Sefaz RS é "-02:00" ou se não for isto favor informar qual procedimento adotar.

Obs.: estou usando o ACBrMonitor PLUS v0.1.10.5

Estranhamente estou emitindo em todos os clientes e não estou com problema por causa do horário de verão!

seu micro está no horário correto e também no fuso horário correto?

Consultor SAC ACBr Juliomar Marchetti
 

Projeto ACBr

skype: juliomar
telegram: juliomar
e-mail: [email protected]
http://www.juliomarmarchetti.com.br
MVP_NewLogo_100x100_Transparent-02.png
 

 

  • Membros Pro
Postado

Logo após iniciar o horário de verão as NF-e e NFC-e estão rejeitando por causa do horário de emissão gerado no XML dando o erro:

CStat=703
XMotivo=Rejeicao: Data-Hora de Emissao posterior ao horario de recebimento

Portanto quando é gerado a data-hora no XML pelo Monitor está sendo colocado assim:

<dhEmi>2015-10-21T16:01:00-03:00</dhEmi>

..E o Sefaz processa o recebimento assim:

<dhRecbto>2015-10-21T16:01:02-02:00</dhRecbto>

Pelo que percebi a solução será trocar o GMT "-03:00" para  "-02:00" no momento em que o Monitor gera o XML, porque o GMT adotado agora no Sefaz RS é "-02:00" ou se não for isto favor informar qual procedimento adotar.

Obs.: estou usando o ACBrMonitor PLUS v0.1.10.5

Estranhamente estou emitindo em todos os clientes e não estou com problema por causa do horário de verão!

seu micro está no horário correto e também no fuso horário correto?

Sim está tudo certo Juliomar.

Também estou emitindo e não estou com problema mas usando o ACBRNFeMonitor.

O problema ocorre, como já citei, apenas com o ACBrMonitor PLUS (ambiente de Homologação)

 

  • Membros Pro
Postado (editado)

Estou usando a versão 0.1.10.5 compilada que está disponível para Download. Não sei se o problema é exatamente conforme eu conclui, pode ser outra coisa, mas o fato é que está ocorrendo com mais alguns usuários também. O problema é que ó Sefaz RS Trocou GMT para -02:00 conforme próprio retorno de consulta ao status (foi a diferença que percebi).

Editado por DATAC
Postado

bom de momento vou alterar a unit  pcnAuxiliar

na função

function GetUTC(UF: string; const dataHora: TDateTime): string; overload;
const
  UTC5 = '.AC.';
  UTC4 = '.AM.RR.RO.MT.MS.';
  UTC3 = '.AP.PA.MA.PI.TO.GO.CE.RN.PB.PE.AL.SE.BA.MG.ES.RJ.SP.PR.SC.RS.DF.';
var
  HorarioDeVerao: Boolean;
begin
  if (UF = '90') or (UF = '91') or (UF = '') then
     UF := 'DF';  

  HorarioDeVerao := IsHorarioDeVerao(UF, dataHora);

  if AnsiPos('.' + UF + '.', UTC4) > 0 then
  begin
    Result := '-04:00';
    if HorarioDeVerao then
      Result := '-03:00';
  end
  else
  if AnsiPos('.' + UF + '.', UTC3) > 0 then
  begin
    Result := '-03:00';
    if IsHorarioDeVerao(UF, dataHora) then
      Result := '-02:00';
  end
  else
  if AnsiPos('.' + UF + '.', UTC5) > 0 then
  begin
    Result := '-05:00';
  end;
end;

 

bem nessa parte aqui

 

  if AnsiPos('.' + UF + '.', UTC4) > 0 then
  begin
    Result := '-04:00';
    if HorarioDeVerao then
      Result := '-03:00';
  end

para isso

 

  if AnsiPos('.' + UF + '.', UTC4) > 0 then
  begin
    Result := '-04:00';
    if HorarioDeVerao then
      Result := '-02:00';
  end

 

preciso que retorna -02:00

  • Membros Pro
Postado

Bom dia.

Como o Delmar bem colocou no caso aqui do RS, UTC3 deve ficar -02:00, quando em horário de verão, porque é assim que a Sefaz está trabalhando pelo que vi no retorno.

Postado

exatamente ao enviar envia assim <dhEmi>2015-10-21T18:15:50-03:00</dhEmi> quando deveria estar enviando assim <dhEmi>2015-10-21T18:15:50-02:00</dhEmi> porque o retorno esta sendo -02:00

 

"Juliomar Marchetti"

Então não é mais usada essa função!

 

pois é não deu certo mudando aquela função! Juliomar Marchetti sabe qual é a função usada agora?

Postado

Boa tarde,

No windows, na configuração de horário marque a opção ajustar automaticamente o horário para horário de verão. ( Windows 7 = Alterar Configurações data e hora e depois alterar fuso horário)

Obs: Se o horário já estiver ajustado, volte 1 hora e depois marque a opção.

Fazendo isto o XML vai com -02:00.

 

 

  • Curtir 1
  • Membros Pro
Postado

Boa tarde,

No windows, na configuração de horário marque a opção ajustar automaticamente o horário para horário de verão. ( Windows 7 = Alterar Configurações data e hora e depois alterar fuso horário)

Obs: Se o horário já estiver ajustado, volte 1 hora e depois marque a opção.

Fazendo isto o XML vai com -02:00.

 

 

Mudar isto em uma maquina não é difícil mas, mas em muitos PCs de vários clientes é bem complicado, lavando também em consideração que nunca precisou se fazer este procedimento anteriormente, sempre o XML era gerado corretamente sem precisar deste ajuste. Acredito que tenha como realizar este ajuste diretamente na hora de gerar o XML via componente do ACBr ou não?

  • Fundadores
  • Solution
Postado

Esse comportamento não deve modificado nos fontes... ( a não ser que exista um motivo real )

Os fontes do Trunk usavam um método que tentava calcular se estava ou não em horário de verão... E se o governo não usasse as regras padrões (o que é muito comum) isso não funcionaria...

O método atual, usa uma função da biblioteca "Synapse" synautil.TimeZone, que lê o Flag de horário de verão do PC

Se você não corrigir o relógio do PC, vários outros problemas ocorrerão...

  • Curtir 2
Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

  • Moderadores
Postado

Já também explicando o porque dessa implementação ! caso você esteja com um servidor em outro estado e emitindo para um outro, ele vai conseguir se entender e passar pelo servidor enviando o UTC correspondente!

Eu fiz testes de diversos modos em nossos clientes no MT, MS, PA, AM, AC, SP , BA e temos diversos que tem servidores centralizados para usar via TS ou remoto e o problema foi totalmente sanado usando a função que o Daniel citou acima!

  • Curtir 1
Consultor SAC ACBr Juliomar Marchetti
 

Projeto ACBr

skype: juliomar
telegram: juliomar
e-mail: [email protected]
http://www.juliomarmarchetti.com.br
MVP_NewLogo_100x100_Transparent-02.png
 

 

Postado

Mas caso por uma questão de infra do meu cliente eu não posso habilitar este atributo?
Teria alguma outra alternativa? Alguma atributo no componente?

 

At+

Carlos H. Marian

Analista de Sistemas

|/-\|

Postado

Estou em SC, tentando emitir para o DF.

      <mod>65</mod>
      <serie>11</serie>
      <nNF>3</nNF>
      <dhEmi>2015-10-28T00:00:00-02:00</dhEmi>
      <tpNF>1</tpNF>

Já adiantei, já atrasei o relógio aqui e nada de funcionar.

Nota(s) não confirmadas:
704: NFC-e com Data-Hora de emissao atrasada

Alguma idéia do que mais fazer ?

 

 

Postado (editado)

Boa tarde.

Ocorreu o problema aqui e foi so ativar no cliente a flag do windows para ajustar automaticamente para o horário de verão que já resolveu o problema,

Tinha somente testado no windows xp e 2003 mas se desmarcar a flag no win 10 também ocorre o problema.

Editado por rafikrafael

Rafael Marcelo dos Santos

Desenvolvedor de Sistemas

Ápice Sistemas - Paranavaí - PR

email: [email protected]

fone: 44 3045 6878

  • 2 anos depois...
Postado

Pessoal tenho uma dúvida. Aqui ele gerou o xml tudo certinho, porém ficou sem internet, logo depois voltou e quando fui tentar enviar novamente ele fala que passou o tempo de envio. Agora estou tentando reenviar e ele não aceita de forma alguma. Lembrando que não existe na base do sefaz, mas na maquina existe o xml gerado certinho, apenas com divergência no horário. Existe uma forma de eu atualizar a data e hora do xml já gerado? Tipo eu carregar ele e gravar novamente com a data certa, depois assinar, validar e enviar. Isso é possível ?

  • Confuso 1
  • Administradores
Postado

Boa tarde.

Este tópico é antigo e será fechado, por favo crie um novo tópico para sua dúvida.

Att.

Consultora SAC ACBr

Juliana Tamizou

Gerente de Projetos ACBr / Diretora de Marketing AFRAC
Ajude o Projeto ACBr crescer - Seja Pro

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.  Discord

Projeto ACBr - A maior comunidade Open Source de Automação Comercial do Brasil


Participe de nosso canal no Discord e fique ainda mais próximo da Comunidade !!

  • Este tópico foi criado há 2261 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.
Visitante
Este tópico está agora fechado para novas respostas
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.