Comportamento das revisões de cobranças via PATCH/lotecobv/{id} ao ocorrer erros nas revisões.

[tjbarbosa01]

Boa tarde a todos, o endpoint PATCH/lotecobv/{id} a ser utilizado para revisar cobranças especificas em um determinado lote, não deixa claro o comportamento que se espera ao revisar uma cobrança.

1 - Caso ocorra um erro ao revisar uma cobrança com vencimento via lote, o PSP deverá notificar o integrador de qual forma? Essa informação será relevante na consulta do lote, como por exemplo, quando a própria cobrança não pode ser criada: 2 - Seria interessante armazenar o erro ocorrido na revisão e exibi-lo na consulta do lote? 2.1 - Considerando o item dois como verdadeiro, no caso de múltiplos erros, em tentativas diferentes ou revisões diferentes, devemos sempre armazenar o ultimo erro ou montarmos um histórico de erros para ser exibido na consulta do lote?

Obrigado

[ninrod]

1 - Caso ocorra um erro ao revisar uma cobrança com vencimento via lote, o PSP deverá notificar o integrador de qual forma? Essa informação será relevante na consulta do lote, como por exemplo, quando a própria cobrança não pode ser criada:

Exatamente da maneira como informada no exemplo. O status da soliticação vem como NEGADA e o problema é especificado usando a estrutura da RFC 7808 como demonstrado. O endpoint a ser acessado é o GET /lotecobv/{id}

2 - Seria interessante armazenar o erro ocorrido na revisão e exibi-lo na consulta do lote? 2.1 - Considerando o item dois como verdadeiro, no caso de múltiplos erros, em tentativas diferentes ou revisões diferentes, devemos sempre armazenar o ultimo erro ou montarmos um histórico de erros para ser exibido na consulta do lote?

Optou-se por exibir, no endpoint GET /lotecobv/{id}, apenas o status da última solicitação, e não o "histórico". O usuário recebedor sempre tem em mãos a possibilidade de consultar diversas revisões da cobrança via GET /cobv/{txid}?revisao=xyz

[tjbarbosa01]

1 - Caso ocorra um erro ao revisar uma cobrança com vencimento via lote, o PSP deverá notificar o integrador de qual forma? Essa informação será relevante na consulta do lote, como por exemplo, quando a própria cobrança não pode ser criada:

Exatamente da maneira como informada no exemplo. O status da solicitação vem como NEGADA e o problema é especificado usando a estrutura da RFC 7808 como demonstrado. O endpoint a ser acessado é o GET /lotecobv/{id}

Ok, como no exemplo, para a criação de cobranças um erro será especificado usando a estrutura da RFC 7808. A duvida em si é sobre erros ocasionados por revisões via lote onde a cobrança já foi criada e o status esta como CRIADA.

2 - Seria interessante armazenar o erro ocorrido na revisão e exibi-lo na consulta do lote? 2.1 - Considerando o item dois como verdadeiro, no caso de múltiplos erros, em tentativas diferentes ou revisões diferentes, devemos sempre armazenar o ultimo erro ou montarmos um histórico de erros para ser exibido na consulta do lote?

Optou-se por exibir, no endpoint GET /lotecobv/{id} penas o status da última solicitação, e não o "histórico". O usuário recebedor sempre tem em mãos a possibilidade de consultar diversas revisões da cobrança via GET /cobv/{txid}?revisao=xyz`

Ok, concordo. Com base nesse contexto devemos armazenar um erro ocorrido em uma revisão? Ficando o resultado da consulta de um lote da seguinte forma, caso, por exemplo, houvesse um erro na revisão de uma cobrança por lote:

Ou devemos usar o objeto problema do retorno apenas para erros ao salvar as cobranças com vencimento em lote? E os erros gerados ao criar revisões de cobranças com vencimento via lote devem ser desconsiderados neste retorno?

[ninrod]

@tjbarbosa , bom dia.

A duvida em si é sobre erros ocasionados por revisões via lote onde a cobrança já foi criada e o status esta como CRIADA.

Não sei se entendi corretamente sua dúvida. Veja, se a revisão de uma cobrança foi incrementada, então foi um sucesso, e não um erro. Se há um erro na solicitação de alteração via lote, não é incrementada uma revisão. Esse "histórico de erros" não é apresentado, no momento, apenas o último.

ok, concordo. Com base nesse contexto devemos armazenar um erro ocorrido em uma revisão? Ficando o resultado da consulta de um lote da seguinte forma, caso, por exemplo, houvesse um erro na revisão de uma cobrança por lote:

Importante ressaltar que o status mostrado no exemplo é o status da 'solicitação' de alteração ou revisão e não o status da cobrança. Nesse caso, portanto, o status deveria estar como negado porque um problema é apresentado. Se o status é criado, não há o que se falar em termos de 'problemas'. O exemplo mostrado, portanto, está semanticamente errado.

Não existe um erro em uma 'revisão'. Existe um erro na solicitação de alteração de uma cobrança que, se existir, apresentará uma revisão X. Suponha que uma cobrança xyz apresente a revisão n. Você, via PACH /lotecobv/{id} inclui uma solicitação de alteração da cobrança xyz, que é negada pelo PSP recebedor por algum motivo. A cobrança em questão, a xyz, continua apresentando revisão n e não n+1. Nada mudou: a solicitação de alteração foi inválida. O efeito é o mesmo de se tentar fazer um PATCH inválido diretamente via PATCH /cobv/{txid}. Para a cobrança em questão, nada muda, porque o PATCH foi inválido.

[llatsch]

@ninrod Seguindo esse mesmo caso de uso, para a cobrança ok entendido, mas como ficaria o status da cobrança dentro do lote? "Negada"?

Não existe um erro em uma 'revisão'. Existe um erro na solicitação de alteração de uma cobrança que, se existir, apresentará uma revisão X. Suponha que uma cobrança xyz apresente a revisão n. Você, via PACH /lotecobv/{id} inclui uma solicitação de alteração da cobrança xyz, que é negada pelo PSP recebedor por algum motivo. A cobrança em questão, a xyz, continua apresentando revisão n e não n+1. Nada mudou: a solicitação de alteração foi inválida. O efeito é o mesmo de se tentar fazer um PATCH inválido diretamente via PATCH /cobv/{txid}. Para a cobrança em questão, nada muda, porque o PATCH foi inválido.

[ninrod]

@ninrod Seguindo esse mesmo caso de uso, para a cobrança ok entendido, mas como ficaria o status da cobrança dentro do lote? "Negada"?

Esse é o ponto. Não existe status da cobrança dentro do lote e sim apenas o status da solicitação de alteração/criação de cobrança dentro do lote. Não existe status da cobrança dentro dos endpoints organizados sob a tag "lotecobv". Os status das cobranças você encontra nos endpoints reunidos sob a tag cob ou cobv.

Em outras palavras, com "NEGADA" você apenas sabe a última requisição para aquela cobrança está negada. Se quer saber o status daquela cobrança, tem que usar outro endpoint.