Dúvida em cenário de reaproveitamento de location

[ccmario]

Boa noite!

Temos com uma dúvida no fluxo de reaproveitamento de locations. Considerando o cenário hipotético abaixo:

1. O cliente MERCADO DO JOSÉ cria duas locations (IDs 1 e 2) através do "POST /loc" com o intuito de imprimir os respectivos QR Codes e deixá-los visíveis para os clientes em cada terminal de seu estabelecimento.

2. O cliente MERCADO DO JOSÉ cria uma cobrança imediata através do "PUT /cob/{txid}" referenciando a location de ID 1, criada no passo anterior.

3. O cliente MERCADO DO JOSÉ percebe que a location associada estava incorreta e a desvincula da cobrança através do "PATCH /cob/{txid}", passando nulo para o objeto "location" (possibilidade discutida nessa issue). Nenhum outro campo é modificado, apenas a desassociação é realizada na ação.

4. O cliente MERCADO DO JOSÉ associa a location correta (de ID 2) à cobrança também através do "PATCH /cob/{txid}".

Dúvidas:

A) A ação do item 3 deveria ter gerado uma nova revisão da cobrança? Lembrando que se o desvínculo tivesse sido feito pelo "DEL /loc" isso não aconteceria.

B) Ao consultar a revisão 0 desta cobrança, deve ser retornada a location que havia sido associada durante sua criação (de ID 1)?

Grato desde já!

[ninrod]

bom dia @ccmario

A) A ação do item 3 deveria ter gerado uma nova revisão da cobrança? Lembrando que se o desvínculo tivesse sido feito pelo "DEL /loc" isso não aconteceria.

Ótima pergunta. Poderíamos seguir aqui com duas abordagens distintas. Incrementar ou não a revisão. Entendo que a cobrança em si não foi alterada, apenas decidiu-se deixar de exibí-la na "vitrine". Não vejo sentido em guardar o "histórico de locais em que a cobrança foi exibida ou deixou de ser exibida". Portanto, entendo que a abordagem mais simples e efetiva seria não incrementar o histórico de revisão quando da alteração deste campo.

B) Ao consultar a revisão 0 desta cobrança, deve ser retornada a location que havia sido associada durante sua criação (de ID 1)?

Outra excelente pergunta relacionada. Entendo que a resposta também seria não. O intuito da location, na cobrança, é apenas evidenciar onde a cobrança em questão está sendo exibida no presente momento. Não há nenhuma intenção de nossa parte no sentido de "armazenar o histórico de locais em que a cobrança foi exibida".

Dito isso, entendo que a maneira pela qual os objetos estão aninhados na cobrança tendem a gerar o entendimento de que uma alteração em quaisquer deles geraria uma nova revisão. Pensando nesta problemática, talvez uma melhor modelagem teria sido aninhar o objeto loc em um local mais "separado" dos outros objetos que sim, causariam alteração de revisão. Esse seria um ponto em que a modelagem poderia melhorar. Por outro lado, não vejo nada que possa ser feito nesse sentido, no momento, sem uma quebra de compatibilidade.

[mliberato]

@ninrod acredito que uma nota na documentação (openapi) dos métodos para esclarecer e definir este ponto possa ajudar outras pessoas que se depararem com a mesma questão.

[ninrod]

@ninrod acredito que uma nota na documentação (openapi) dos métodos para esclarecer e definir este ponto possa ajudar outras pessoas que se depararem com a mesma questão.

Sim, perfeita observação.

[jeanhora]

Eu tenho uma duvida em relação à essa discussão.

Ao alterar uma revisão, eu devo manter a revisão 0 em histórico? ou apenas altero para revisão um e altero os itens da cobrança?

No caso do Location, ao alterar uma cobrança o location eu altero, ou permanece o mesmo?

Alguém pode me indicar um cenário de revisão?

[ninrod]

Ao alterar uma revisão, eu devo manter a revisão 0 em histórico? ou apenas altero para revisão um e altero os itens da cobrança?

Sim porque em GET /cob/{txid} o usuário recebedor pode atribuir o parâmetro revisão.

ao alterar uma cobrança o location eu altero, ou permanece o mesmo?

Se ao alterar uma cobrança não se altera o location, ele permanece o mesmo.

Alguém pode me indicar um cenário de revisão?

Pagamento de conta de super-mercado. Item estava duplicado. Foi cobrado 7,98 por 2 iogurtes e o certo era 3,99, porque o cliente está levando apenas um iogurte. Altera-se a cobrança, o valor: de 7,98 -> 3,99. Escaneia novamente o mesmo QR Code. Valor correto: 3,99. Paga-se a conta, liquida-se, verifica-se que a cobrança foi paga, libera-se o cliente e a compra.

[ninrod]

corrigido em 2.2.2