search

bacen / pix-api

API Pix: a API do Arranjo de Pagamentos Instantâneos Brasileiro, Pix, criado pelo Banco Central do Brasil.
https://bacen.github.io/pix-api
2.32k stars 262 forks source link

> > A ideia é diferenciar na consulta os status, dado que ele será usado para consultar o resultado da emissão e da revisão. #397

Closed wesleygonalv closed 3 years ago

wesleygonalv commented 3 years ago

A ideia é diferenciar na consulta os status, dado que ele será usado para consultar o resultado da emissão e da revisão. Exemplo: revisado, em revisão ou revisão negada quando uma alteração e manter o status: criada, em processamento ou negada, quando for uma emissão de um novo qr code.

entando, mas eles são semanticamente equivalentes.

em revisao = em processamento criada = revisado revisão negada = negada.

@ninrod Já conversamos sobre isso na issue #360 mas, apesar dos status serem semanticamente equivalente, seria interessante o parceiro diferenciar uma cobrança criada de uma cobrança revisada, por exemplo.

Uma cobrança criada pelo processo do lote, pode ter os status:

Mas quando a cobrança do lote for revisada, o parceiro acaba recebendo os mesmo status sem ter indicação de número de revisão ou que foi revisada.

Seguindo o exemplo da @biancaOliveiraSantos para as cobranças que foram enviadas por lote para revisão, ficariam com um status identificando do que ocorreu na revisão, segue:

Eu entendo e concordo que o status NEGADA está semanticamente equivalente e faz sentido para a funcionalidade do lote, mas poderia ser uma melhoria interessante para Api PIx, a justificativa para utilizar esses status seria para que não fosse preciso consultar a cobrança, verificando se houve ou não a alteração solicitada.

Em resumo, ao consultar o lote as cobrança teriam os seguintes status:

Originally posted by @wesleygonalv in https://github.com/bacen/pix-api/issues/273#issuecomment-838926008

ninrod commented 3 years ago

@wesleygonalv ,

Mas quando a cobrança do lote for revisada, o parceiro acaba recebendo os mesmo status sem ter indicação de número de revisão ou que foi revisada.

Você sempre pode verificar se a cobrança foi revisada via GET /cobv/{txid} verificando o atributo revisao. Isso resolve seu problema, não?

wesleygonalv commented 3 years ago

Sim resolveria, mas não seria um ponto de apoio para o parceiro que está utilizando o serviço do lote?

Eu vejo que ficaria custoso o parceiro ter que fazer uma checagem no GET /cobv/{txid} para saber se aconteceu ou não o processo de revisão pelo lote, quando um status na consulta do lote resolveria.

O que achas?

ninrod commented 3 years ago

@wesleygonalv , apenas complementando que você também pode usar:

GET /cobv?loteCobVId={loteid}

E aí você poderia consultar o status de todas as cobranças do lote de uma vez.

Ressalto que existe um grande esforço de nossa parte no sentido de não criar caminhos adicionais para se fazer a mesma coisa, na medida do possível.