pix-api
pix-api copied to clipboard
bacen
Dúvidas sobre LoteCobv
Boa tarde! Segue algumas dúvidas/sugestões sobre lote:
1- Uma cobrança criada via lote, pode ser alterada (individualmente) no PATCH/cobv/{txid}?
2- A revisão de cobranças no PATCH/lotecobv/{id}, é assíncrona? Pois no response do endpoint dá a entender que o processamento foi concluído:
3- Se o PATCH/lotecobv/{id}, é assíncrono, ao verificar se a revisão foi processada, deve-se consultar o GET/lotecobv/{id}, porém os status são somente de "criada, em processamento ou negada", é possível criar status específicos na revisão, para que possamos diferenciar do status de criação?
4-Se na alteração em lote no PUT/lotecobv/{id} uma das cobranças enviadas não estiver alterada ou estiver com o status de removida, ela deve ser rejeitada, ou o todo o lote?
5- Na lista de violações do Lote, está descrito nos endpoints PUT /lotecobv/{txid}, mas acredito que no caso seria o ID ao invés do txid.
Sugestão: Sentimos a falta/necessidade de query parameters no GET/lotecobv que traga o status do resultado do processamento do lote, para que não seja necessária a validação de cada txid que o compõe e um parameters no /lotecobv/{id} de status das cobranças, para consultar por exemplo, somente as cobranças criadas, ou negadas.
Obrigada!
1- Uma cobrança criada via lote, pode ser alterada (individualmente) no PATCH/cobv/{txid}?
Sim.
A revisão de cobranças no PATCH/lotecobv/{id}, é assíncrona? Pois no response do endpoint dá a entender que o processamento foi concluído:
É assíncrono, assim como o PUT correlato. A descrição realmente cria essa confusão. Pode ser melhorada.
3- Se o PATCH/lotecobv/{id}, é assíncrono, ao verificar se a revisão foi processada, deve-se consultar o GET/lotecobv/{id}, porém os status são somente de "criada, em processamento ou negada", é possível criar status específicos na revisão, para que possamos diferenciar do status de criação?
Esses são os 3 possíveis status da solicitação de alteração (e não da cobrança em si). Não entendi o que seria "status específicos na revisão".
4-Se na alteração em lote no PUT/lotecobv/{id} uma das cobranças enviadas não estiver alterada ou estiver com o status de removida, ela deve ser rejeitada, ou o todo o lote?
Se 1 das N cobranças apresentar o problema, somente ela é "NEGADA", e não todo o lote.
5- Na lista de violações do Lote, está descrito nos endpoints PUT /lotecobv/{txid}, mas acredito que no caso seria o ID ao invés do txid.
Tem toda razão, é um bug. deveria ser {id}. Já marquei essa issue como 2.2.1.
Sugestão: Sentimos a falta/necessidade de query parameters no GET/lotecobv que traga o status do resultado do processamento do lote, para que não seja necessária a validação de cada txid que o compõe e um parameters no /lotecobv/{id} de status das cobranças, para consultar por exemplo, somente as cobranças criadas, ou negadas.
Você sugere, por exemplo:
-> GET /lotecobv/123?status=NEGADA
em que o resultado desta consulta seria apenas as solicitações negadas dentro desse lote?
Obrigada pelo retorno, segue abaixo as respostas:
3- Se o PATCH/lotecobv/{id}, é assíncrono, ao verificar se a revisão foi processada, deve-se consultar o GET/lotecobv/{id}, porém os status são somente de "criada, em processamento ou negada", é possível criar status específicos na revisão, para que possamos diferenciar do status de criação?
Esses são os 3 possíveis status da solicitação de alteração (e não da cobrança em si). Não entendi o que seria "status específicos na revisão".
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.
Sugestão: Sentimos a falta/necessidade de query parameters no GET/lotecobv que traga o status do resultado do processamento do lote, para que não seja necessária a validação de cada txid que o compõe e um parameters no /lotecobv/{id} de status das cobranças, para consultar por exemplo, somente as cobranças criadas, ou negadas.
Você sugere, por exemplo:
-> GET /lotecobv/123?status=NEGADA em que o resultado desta consulta seria apenas as solicitações negadas dentro desse lote?
isso, dois parâmetros: GET /lotecobv/123?status: nesse caso retornaria o status de processamento do lote, processado ou em processamento, para que o cliente não precise varrer o lote inteiro para saber se ele foi completamente processado.
GET /lotecobv/123?status=NEGADA, retornando somente os TXids negados/criados/em processamento do lote enviado.
Obrigada!
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.
GET /lotecobv/123?status=NEGADA, retornando somente os TXids negados/criados/em processamento do lote enviado.
Não entendi este trecho. Entendo que ?status=NEGADA retornaria somente as solicitações negadas do lote, e não as em processamento ou criadas.
Não entendi este trecho. Entendo que ?status=NEGADA retornaria somente as solicitações negadas do lote, e não as em processamento ou criadas.
exato, somente as negadas. Era mais para exemplificar que poderia ter o filtro para todos os status
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:
- EM PROCESSAMENTO
- CRIADA
- NEGADA
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:
- EM PROCESSAMENTO
- REVISADA
- REVISÃO NEGADA ( Esse status indicaria que a cobrança foi criada anteriormente porém a solicitação de revisão está negada )
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:
- EM PROCESSAMENTO
- CRIADA
- REVISADA
- NEGADA
- REVISÃO NEGADA
