Olá,
Não encontrei na documentação nenhuma informação sobre o payload, de quando a nuvem fiscal retorna “pendente” ou “erro”. Minha principal dúvida é se terei um “id” da Nuvem Fiscal nesses casos?
Estou vislumbrando no meu app um fluxo de sempre consultar o manifesto pelo “id”, quando estive de posse dele.
Obrigado,
Marcos
Olá @marcos1, seja bem-vindo à Nuvem Fiscal!
De qual endpoint está falando, exatamente?
Olá @wlandgraf, sobre o endpoint de autorização.
Poderia explicitar exatamente qual é o endpoint? E a qual situação de “pendente” e “erro” você está se referindo?
@wlandgraf estamos desenvolvendo a integração com a API. Como não usamos ainda, não sei lhe apresentar algo específico.
Mas gostaria de um exemplo desse retorno para que o meu aplicativo possa se comportar conforme e não quebrar tudo. Entendeu?
Até já seria legal complementar a documentação com algo nessa linha.
Bom dia @marcos1 ,
O questionamento do @wlandgraf seria sobre qual endpoint específico você tem dúvidas, pois a nuvem fiscal traz serviços para NFe, NFSe, CTe, consulta CNPJ, CEP…
Se você informar onde é sua dúvida de forma específica podemos te ajudar melhor.
Obrigado
Há entendi, mas como postei na flag mdfe achei que já saberiam, mas tudo que referenciei aqui se trata de mdfe/autorização.
Obrigado,
Marcos
Bom dia @marcos1 ,
Mesmo dentro de mdfe temos vários endpoints, eles normalmente seguem uma mesma estrutura da resposta. Caso você nos diga qual endpoint tem dúvida podemos verificar especificamente nele.
Mas essa estrutura de resposta sempre tem um ID da nuvem fiscal e também um status que pode indicar diversas ocorrencias, inclusive de erro.
Essas informações atendem sua necessidade?
Há, então leia-se mdfe/autorização como Emitir MDF-e.
E insisto que gostaria de exemplos de respostas desses retornos de status erro e pendente, como por exemplo:
Status pendente:
{
"id": "mdf_1234",
"ambiente": "producao",
"status": "pendente",
"chave": "12345678901234567890123456789012345678901234",
"mensagem": "Aguardando processamento"
}
Status erro:
{
"id": "mdf_1234",
"ambiente": "producao",
"status": "erro",
"chave": "12345678901234567890123456789012345678901234",
"numero": 123,
"serie": 1,
"autorizacao": {
"numero_protocolo": "123456789012345",
"motivo_status": "Erro interno do servidor da Nuvem Fiscal"
}
}
Essas respostas são suposições minhas e gostaria que vocês as descrevessem.
Obrigado,
Marcos
Bom dia, @marcos1.
Sim, esse é o fluxo ideal. Sempre que você estiver de posse do id, o recomendado é utilizar esse identificador para consultar o status do manifesto.
A única situação em que a Nuvem Fiscal não retornará um id após a requisição ao endpoint de emissão é quando ocorre um erro de validação, resultando em uma resposta com status HTTP 4xx. Nesses casos, o manifesto não é criado, e portanto, não há id a ser consultado.
Nos casos em que a API retorna um id, a estrutura do JSON de resposta seguirá o padrão descrito em nossa documentação. No momento, não temos exemplos prontos de payloads, mas você pode simular esses cenários facilmente na nossa API Sandbox.
Já fiz vários testes em sandbox, e já percebi vi como vem o payload de status 400 da requisição, um exemplo seria:
status 400
{
"error": {
"code": "ValidationFailed",
"message": "Validation failed: O campo 'infMDFeSupl.qrCodMDFe' não corresponde ao formato esperado..."
}
}
Mas em nenhum dos meus testes, consegui que a API respondesse status 200 e um payload com { “status”: “erro”, … } ou { “status”: “pendente”, … }.
É um detalhe bem específico e muito provável que não ocorra muito, pois se trata aparentemente alguma instabilidade interna no servidor de vocês.
Não espero uma resposta imediata, mas gostaria deixar registrado essa dificuldade que enfrentamos ao implementar a API. Não está claro como simular essas 2 respostas da API no ambiente de testes. Essa é uma situação que, provavelmente, só vou conseguir explorar em ambiente de produção, com os clientes utilizando meu aplicativo.
Claro que, simular não é uma necessidade, mas ter pelo menos um exemplo do payload seria mais seguro.
Vou tomar a decisão de supor os payload antes colocado, e rezar que estejam certos.
Caso alguém da comunidade consiga ajudar também, agradeço bastante.
Obrigado,
Marcos
Um erro 4xx significa que você chamou esse endpoint de forma incorreta. É um erro de client. Não é instabilidade do servidor.
A resposta do erro mostrada por você indica a razão do erro:
O campo ‘infMDFeSupl.qrCodMDFe’ não corresponde ao formato esperado.
Portanto, você deve revisar a sua chamada e revisar o conteúdo que está passando na propriedade infMDFeSupl.qrCodeMDFe` do JSON que está enviando. Não está correto.
@wlandgraf isso foi só uma referência para sustentação da minha questão principal, para que o leitor saiba que estou sabendo tratar erros de status 400.
A minha questão não era essa. E como citei antes, vou aguardar algo mais sobre a API responder status 200 e um payload com { “status”: “erro”, … } ou { “status”: “pendente”, … } .