PROBLEMA RETORNO NFCe

[luizcnr]

Galera, boa tarde!

Estou com um problema em um cliente com o retorno do XML da NFCe.

A NFCe é emitida normalmente, porém, quando vai validar os dados da NFCe no validador de NFCe, https://www.sefaz.rs.gov.br/nfe/nfe-val.aspx.

É emitido o seguinte erro:

Schema XML: The 'http://www.portalfiscal.inf.br/nfe:dhRecbto' element is invalid - The value '2023-03-31T22:17:14+00:44' is invalid according to its datatype 'http://www.portalfiscal.inf.br/nfe:TDateTimeUTC' - The Pattern constraint failed.
Caminho: nfeProc/protNFe/infProt/dhRecbto/.

O problema identificado está na tag dhRecbto: <dhRecbto>2023-03-31T22:17:14+00:44</dhRecbto>

Ao corrigir, para -03:00, a NFCe é validada normalmente.

Alguém pode me dizer o porque da NFCe estar retornando +00:44?

 

 

[Juliomar Marchetti]

Não é ela, creio que seja seu windows ou se tu fixou isso no componente que tem local para isso

[luizcnr]

Não fixei no componente, Julio.

Isso está ocorrendo em um cliente em específico. Pois, na hora da emissão está correto, mas na hora de recebimento, está incorreto.

[Juliomar Marchetti]

fuso do micro está ok e as opções regionais também?

[luizcnr]

Está sim. Tudo correto. Pelo que entendi, esse retorno é da SEFAZ. Eu tentei simular algo na minha máquina e todas as vezes, foram retornados com -03:00 no horário de recebimento

[lucimauro]

Ola;

Na sua maquina funciona, não seria o horário de verão ativado e para o horário ficar correto altearam a hora manualmente ?

[luizcnr]

13 horas atrás, lucimauro disse:

Ola;

Na sua maquina funciona, não seria o horário de verão ativado e para o horário ficar correto altearam a hora manualmente ?

Pode ser uma situação. Mas, se tivesse alterado data e hora, na data da emissão estaria com o mesmo fuso horário. O problema em si, está sendo a data e hora do recebimento. Eu estou tendo quase a certeza que esse retorno de data e hora no dhRecbto, é a SEFAZ quem me retorna.

[lucimauro]

Ola;

Faça um consulta do status do serviço que  terá o horário do webservice para comparar.

[luizcnr]

Lucimauro, acabamos solucionando o problema.

Nos ajustes de data e hora do Windows 10, a máquina do cliente estava ativo definir fuso horário automaticamente.

Ao desabilitar essa opção, o cupom começou a retornar o fuso horário correto.

Obrigado pela ajuda!

[Juliomar Marchetti]

1 hora atrás, luizcnr disse:

Lucimauro, acabamos solucionando o problema.

Nos ajustes de data e hora do Windows 10, a máquina do cliente estava ativo definir fuso horário automaticamente.

Ao desabilitar essa opção, o cupom começou a retornar o fuso horário correto.

Obrigado pela ajuda!

Sabe porque isso? o windows não está atualizado pois isso vem a correção junto nas atualizações do windows e portanto seu windows está desatualizado.

ele está entendendo que tu tem ainda horário de verão

[luizcnr]

Juliomar, só uma dúvida. Uma pergunta "besta". Essa data e hora do recebimento, pode ter haver com a data e hora de envio? 

[Juliomar Marchetti]

17 minutos atrás, luizcnr disse:

Juliomar, só uma dúvida. Uma pergunta "besta". Essa data e hora do recebimento, pode ter haver com a data e hora de envio? 

Não. tu poderia estar emitindo ela agora e ocorrer algo no envio e conseguir só 5 minutos depois tu conseguir efetivar não será a mesma data ehora

[luizcnr]

Obrigado! E questionei, pois mesmo eu realizando aquela alteração que mencionei ali em cima, o problema voltou a acontecer no cliente.

Eu vou tentar atualizar o windows da máquina do cliente e a pasta schemas.

[HugoFialho]

Estou com o mesmo problema, o XML de resposta do processamento do lote está com o fuso horário preenchido errado 

<dhRecbto>2023-04-12T16:29:01+00:44</dhRecbto>

Muito estranho, o problema acontece apenas em algumas notas, não acredito que seja configuração do windows. 

Anexei um xml exemplo.

 

11151-ret-lot-35230408687461000196650010000111511823369960-bugado.xml

[luizcnr]

Em 12/04/2023 at 16:59, HugoFialho disse:

Estou com o mesmo problema, o XML de resposta do processamento do lote está com o fuso horário preenchido errado 

<dhRecbto>2023-04-12T16:29:01+00:44</dhRecbto>

Muito estranho, o problema acontece apenas em algumas notas, não acredito que seja configuração do windows. 

Anexei um xml exemplo.

 

11151-ret-lot-35230408687461000196650010000111511823369960-bugado.xml 639 B · 1 download

Em nosso cliente, esse problema ocorre em cupons emitidos após as 22h. Pelo que foi identificado, foi no fim do mês de março. Esse problema foi identificado, pois o cliente utiliza o arquivei e ele acusa esse erro mencionado.

E esse erro ocorre em apenas alguns cupons tb, deve ser algum problema no retorno da SEFAZ.

[jrdnzeraaa]

Boa tarde!

Só para acompanhar, também estou com este problema, e também com alguns cupons (não todos).

 

[Juliomar Marchetti]

35 é Minas né?

eu acho que é lá com eles o problema todo.

[luizcnr]

11 horas atrás, Juliomar Marchetti disse:

35 é Minas né?

eu acho que é lá com eles o problema todo.

Só pra frizar, o meu problema é em SP

[jrdnzeraaa]

1 hora atrás, luizcnr disse:

Só pra frizar, o meu problema é em SP

Bom dia, isso mesmo, na NFCe o cUF 35 é SP.

 

[Juliomar Marchetti]

Vocês usam sistemas locais ou estão usando TS ou VPS ou até servidores externos?

[luizcnr]

1 minuto atrás, Juliomar Marchetti disse:

Vocês usam sistemas locais ou estão usando TS ou VPS ou até servidores externos?

Eu utilizo sistema local

[HugoFialho]

No meu caso, o sistema é local, rodando em windows.

Os erros acontecem apenas em SP.

[jrdnzeraaa]

Em 14/04/2023 at 10:10, Juliomar Marchetti disse:

Vocês usam sistemas locais ou estão usando TS ou VPS ou até servidores externos?

Via TS!

Hoje fiz um contato com o http://www.nfce.fazenda.sp.gov.br/NFCePortal/

Através do e-mail que disponibilizam lá, caso tenha alguma resposta trago aqui para vocês, mas recomendo realizarem o contato também caso ainda não tenham resolvido: [email protected]

[jrdnzeraaa]

Pessoal, pelo menos aqui o problema parou de ocorrer, sendo a última vez no dia 15/04. Dessa forma imagino que era algo do lado deles lá, que foi corrigido.

[Juliomar Marchetti]

Obrigado por reportar.

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