Campo `data_emissao` de NFS-e não é retornado em UTC

Boa tarde,

Não sei se esse é o comportamento desejado da API, porém, fazendo uma consulta aqui em alguns documentos, percebi que, diferentemente de outros campos, como o created_at, declaracao_prestacao_servico.rps.data_emissao, etc, que são retornados em UTC, o campo data_emissao principal da NFS-e está retornando com o horário de Brasília (não sei se para todas as cidades ou se ele pega pelo fuso do município de emissão da nota), mas seria interessante se todos os campos datetime da API retornassem sempre em UTC.

Boa tarde @cloudhotels,

Favor informar o id da nota e o trecho do JSON retornado pela API.

Um exemplo de nota é a nfs_3a0a4aa5abbc43f8bc80232b853c3460.

Segue os campos de data retornados no JSON:

{
    "id": "nfs_3a0a4aa5abbc43f8bc80232b853c3460",
    "created_at": "2023-03-30T16:20:55.012Z",
    "status": "autorizada",
    "data_emissao": "2023-03-30T13:20:58Z",
    "ambiente": "producao",
    "declaracao_prestacao_servico": {
        "rps": {
            "data_emissao": "2023-03-30T16:20:55.231Z"
        }
    }
}

@cloudhotels,

A princípio, tudo indica que é um comportamento não desejado.

Iremos analisar e em breve retornamos.

Bom dia, Arimateia,

Aproveitando, não sei se está relacionado a esse problema, mas quando os clientes tentaram emitir documentos ontem na parte da noite (após às 21h, que seria 00h UTC), começaram a chegar rejeições E16 - A data da emissão do RPS não poderá ser superior a data de hoje, porque talvez estejam passando a data em UTC, que, entre 21h e 23h59 ficam como sendo “dias diferentes”.

Esse tratamento deve ser feito pela Nuvem na comunicação com a prefeitura ou devemos enviar já as datas com o timezone correspondente? Fico na dúvida se a comunicação com a Nuvem deve ser toda feita em UTC ou não…

Bom dia @cloudhotels,

O envio de campos data/hora para a Nuvem Fiscal é sempre em UTC.

Para exemplificar, os seguintes valores são equivalentes:

  1. 2023-03-31T22:30:00-03:00
  2. 2023-03-31T21:30:00-04:00
  3. 2023-04-01T01:30:00Z
  4. 2023-04-01T01:30:00+00:00

Entretanto, pode ocorrer de alguns provedores/prefeituras não interpretarem adequadamente alguns valores no XML. Qual o provedor que você recebeu essa rejeição E16?

Perfeito!

A rejeição foi pelo provedor TIPLAN.

Boa noite, Arimateia,

Migramos outro cliente para a Nuvem hoje, que normalmente emite muita nota durante a noite, de uma prefeitura que também usa a TIPLAN, e começaram a receber essa rejeição agora. Vocês conseguiram identificar o problema, tem alguma previsão para resolver essa situação? Devemos tratar do nosso lado aqui para enviar a data com horário de Brasília para evitar esse tipo de erro por enquanto?

Boa tarde @cloudhotels,

Fizemos um ajuste agora para solucionar o problema da rejeição E16.

Bom dia!

Show de bola, acho que não tivemos nenhum caso de notas sendo emitidas entre 21h e 23h59 ontem, mas ficarei de olho aqui quando houver novamente para verificar se está tudo certinho!

Com relação ao campo data_emissao estar vindo com o offset errado, foi resolvido junto ou eram problemas separados mesmo?

Bom dia @cloudhotels,

Ainda será analisado. Favor aguardar.

Não precisa aguardar alguma nota ser emitida nesse intervalo, basta você baixar o XML gerado para qualquer nota e verificar se a data de emissão está indo no fuso horário da UF do prestador que a emitiu.

Perfeito, as notas estão indo com horários certinhos sim e a rejeição E16 parece ter sido resolvida, muito obrigado!

Bom dia, @arimateia, tudo bom ?

Alguma novidade sobre esse problema de offset do campo data_emissao das NFS-es ?

Boa tarde, @cloudhotels.

Fizemos a alteração agora na API. A correção só surtirá efeito para novas notas emitidas.

Favor testar e nos avisar caso tenha algum problema.

Acompanhei aqui os últimos documentos emitidos e está tudo certo, obrigado, Arimateia !

Este tópico foi fechado automaticamente 24 horas depois da última resposta. Novas respostas não são mais permitidas.