bacen
Dúvida - Devolução Pix
Bom dia,
Quando o recebedor enviar uma solicitação de devolução para um pix com cobrança, só faria sentido se a cobrança estiver CONCLUIDA, correto? Além disso, entendi que o envio da solicitação de devolução não muda o estado CONCLUIDA da cob.
Agora, se a cobrança não estiver CONCLUIDA, então bastaria fazer um PATCH /v2/cob, mudando o estado de ATIVA para REMOVIDA_PELO_USUARIO_RECEBEDOR.
Sendo assim, pelo JSON da resposta GET /v2/cob, posso estar em um estado CONCLUIDA, e eventualmente receber uma devolução.
Para saber o estado real da cobrança (pago, devolução solicitada, devolvido parcial, devolvido total,...), é necessário olhar o campo status E também o vetor de devoluções do vetor de pix da cob (posso ter também devoluções parciais, no caso de múltiplos pix).
É correto este entendimento?
boa tarde @dev-gto
Quando o recebedor enviar uma solicitação de devolução para um pix com cobrança, só faria sentido se a cobrança estiver CONCLUIDA, correto? Além disso, entendi que o envio da solicitação de devolução não muda o estado CONCLUIDA da cob.
Não é bem por aí. O conceito de devolução está especificamente associado ao pix e não diretamente à cobrança.
Agora, se a cobrança não estiver CONCLUIDA, então bastaria fazer um PATCH /v2/cob, mudando o estado de ATIVA para REMOVIDA_PELO_USUARIO_RECEBEDOR.
Não entendo qual seria a relação da devolução com essa operação específica.
Sendo assim, pelo JSON da resposta GET /v2/cob, posso estar em um estado CONCLUIDA, e eventualmente receber uma devolução
Sim, sem problem nenhum. Lembrando que a devolução nada tem a ver, diretamente, com a cobrança em si.
Para saber o estado real da cobrança (pago, devolução solicitada, devolvido parcial, devolvido total,...), é necessário olhar o campo status E também o vetor de devoluções do vetor de pix da cob (posso ter também devoluções parciais, no caso de múltiplos pix).
Sim, o importante é entender que não basta checar se a cobrança está concluída, tem que checar se o pix recebido honra o valor da cobrança. Vale ressaltar que como a devolução é uma operação autorizada pelo próprio usuário recebedor, este jamais se surpreenderá com uma devolução acontecendo "do nada".
Não entendo qual seria a relação da devolução com essa operação específica.
Perdão pela confusão, o termo que me referia é cancelamento/estorno da transação. No contexto do cliente recebedor, deseja-se cancelar a transação (exemplo: o cliente usou outra forma de pagamento). Ao fazer PATCH /v2/cob mudando de ATIVA para REMOVIDA_PELO_USUARIO_RECEBEDOR, automaticamente se cancela o pix não pago?
Ou, além disso, é necessário enviar também PUT /pix/{e2eid}/devolucao/{id}, mesmo se o pix não foi pago?
O que talvez esteja me confundindo é: a api GET /pix/{e2eid} só retorna 200 para pix efetivamente pagos pelo cliente?
Não entendo qual seria a relação da devolução com essa operação específica.
Perdão pela confusão, o termo que me referia é cancelamento/estorno da transação. No contexto do cliente recebedor, deseja-se cancelar a transação (exemplo: o cliente usou outra forma de pagamento). Ao fazer
PATCH /v2/cobmudando deATIVAparaREMOVIDA_PELO_USUARIO_RECEBEDOR, automaticamente se cancela o pix não pago?Ou, além disso, é necessário enviar também
PUT /pix/{e2eid}/devolucao/{id}, mesmo se o pix não foi pago?O que talvez esteja me confundindo é: a api
GET /pix/{e2eid}só retorna200para pix efetivamente pagos pelo cliente?
Um "Pix" é um elemento que representa uma transferência de fundos da conta A para a conta B.
Uma cobrança, é só uma cobrança (como um boleto). Se o cliente pagou por outro meio, basta cancelar a cobrança (com o PATCH alterando status para REMOVIDA_PELO_USUARIO_RECEBEDOR, como você disse). Não há Pix a ser cancelado/devolvido se o pagamento nunca aconteceu.
Não há Pix a ser cancelado/devolvido se o pagamento nunca aconteceu.
Entendi, então a cobrança, se tiver um vetor de pix populado, é porque foi pago (ainda que parcialmente). Em caso de um cancelamento, só envio PUT /pix/{e2eid}/devolucao/{id} para os elementos desse vetor.
Não há Pix a ser cancelado/devolvido se o pagamento nunca aconteceu.
Entendi, então a cobrança, se tiver um vetor de pix populado, é porque foi pago (ainda que parcialmente). Em caso de um cancelamento, só envio
PUT /pix/{e2eid}/devolucao/{id}para os elementos desse vetor.
Se houver recebimentos, não tem como cancelar a cobrança. Ela já estará com status CONCLUIDA a partir do momento que entrar um Pix relacionado a ela. Só precisa devolver o(s) Pix relacionado(s), se houver algum.
Se houver recebimentos, não tem como cancelar a cobrança. Ela já estará com status CONCLUIDA a partir do momento que entrar um Pix relacionado a ela. Só precisa devolver o(s) Pix relacionado(s), se houver algum.
Sim, me referia a cancelamento da transação, do ponto de vista do cliente recebedor (e não apenas na cobrança pix). Se quero cancelar a transação, envio PATCH cob,cobv (quando status ATIVA), E envio a devolução para cada um dos pix do vetor (já que posso ter pix parciais e a cobrança continuar ATIVA).
Tentei esclarecer e não fui claro o suficiente.
O BACEN não foi incisivo o suficiente na documentação (e nem aqui no GitHub), no princípio, para deixar claro que uma cobrança não pode ser paga com valor inferior ao determinado, o que criou essa celeuma que obriga o recebedor a verificar: se o Pix recebido tem o valor esperado; se tem mais de 1 Pix associado à cobrança, etc. Mas são situações "atípicas", dizem (deveriam então, determinar com clareza que os PSPs não podem acatar Pix com valor menor e pronto, a barreira de validação estaria imposto a um número mais restrito de "atores" do arranjo Pix, mas... enfim, agora já foi). O retorno dos Pix ser um array é compreensível: deixou-se uma abertura para situações que envolvam multi-transações vinculadas a uma só cobrança no futuro (num cenário de split, por exemplo).
Mas o fato é que se você receber qualquer Pix relacionado a uma cobrança, ela mudará de status (de ATIVA para CONCLUIDA). Não importa se foi o valor total ou não. Então, não tem como haver Pix relacionado a uma cobrança para ser devolvido e, ao mesmo tempo, ela ter qualquer status que não seja CONCLUIDA. Se tem Pix, ela sempre estará concluída (assim como um boleto pago, está sempre pago/baixado e não se pode cancelar o boleto, neste caso).
O BACEN não foi incisivo o suficiente na documentação (e nem aqui no GitHub), no princípio, para deixar claro que uma cobrança não pode ser paga com valor inferior ao determinado, o que criou essa celeuma que obriga o recebedor a verificar: se o Pix recebido tem o valor esperado; se tem mais de 1 Pix associado à cobrança, etc. Mas são situações "atípicas", dizem (deveriam então, determinar com clareza que os PSPs não podem acatar Pix com valor menor e pronto, a barreira de validação estaria imposto a um número mais restrito de "atores" do arranjo Pix, mas... enfim, agora já foi). O retorno dos Pix ser um array é compreensível: deixou-se uma abertura para situações que envolvam multi-transações vinculadas a uma só cobrança no futuro (num cenário de split, por exemplo).
Entendo... mas acho que deveria deixar claro, seja por um documento de homologação com casos de uso comuns e incomuns, ou mesmo deixar estes casos de uso ilustrados em algum lugar. Poderia estar no horizonte de alguma publicação futura.
Veja, quem implanta o sistema de cliente recebedor eventualmente levantarão as mesmas dúvidas que tive: como cancelar apropriadamente uma transação (e aí incluem-se ambos cobrança e pix)
A possibilidade de múltiplos Pix no array decorre não de uma única transação, mas de situações de alto tráfego de um EC. Se vier mais de um Pix na mesma PACS.008, e por acaso mais de um deles for do mesmo EC, aí faz sentido o webhook sinalizar vários Pix na mesma mensagem.
A possibilidade de múltiplos Pix no array decorre não de uma única transação, mas de situações de alto tráfego de um EC. Se vier mais de um Pix na mesma PACS.008, e por acaso mais de um deles for do mesmo EC, aí faz sentido o webhook sinalizar vários Pix na mesma mensagem.
No webhook isso é evidente. Não é evidente (e faz zero sentido) quando se consulta uma cobrança. O esperado é que sempre haja apenas 1 Pix associado a cada cobrança, mas o schema do retorno contém um vetor (array) de Pix.
Se tem Pix, ela sempre estará concluída (assim como um boleto pago, está sempre pago/baixado e não se pode cancelar o boleto, neste caso).
Entendo que não dá para cancelar o boleto pago, mas preciso estornar o valor para o cliente de alguma maneira (doc, ted). No caso do pix, imagino que o caminho é a devolução, assim como no caso do cartão de crédito, solicito a transação de estorno junto à operadora.
Veja, quem implanta o sistema de cliente recebedor eventualmente levantarão as mesmas dúvidas que tive: como cancelar apropriadamente uma transação (e aí incluem-se ambos cobrança e pix)
Faz um paralelo com o boleto: se um cliente paga o boleto e você quer devolver o dinheiro por qualquer razão, você não cancela o boleto (não se pode cancelar boleto que já foi pago). Você só devolve o dinheiro.
No arranjo Pix, igual: você devolve o dinheiro (preferencialmente devolvendo a mesma transação de recebimento). Mas a cobrança, "já era", ela já foi marcada CONCLUIDA quando você recebeu o Pix.
Se tem Pix, ela sempre estará concluída (assim como um boleto pago, está sempre pago/baixado e não se pode cancelar o boleto, neste caso).
Entendo que não dá para cancelar o boleto (até porque boleto registrado nem tem esse conceito, seja ele pago ou não), mas preciso estornar o valor para o cliente de alguma maneira (doc, ted). No caso do pix, imagino que o caminho é a devolução, assim como no caso do cartão de crédito, solicito a transação de estorno junto à operadora.
Boleto registrado tem as duas coisas. Dá para cancelar o boleto emitido e mesmo o cliente já tendo pago, pode ser cancelado pelo cliente até antes da conciliação bancária na madrugada.
Se tem Pix, ela sempre estará concluída (assim como um boleto pago, está sempre pago/baixado e não se pode cancelar o boleto, neste caso).
Entendo que não dá para cancelar o boleto (até porque boleto registrado nem tem esse conceito, seja ele pago ou não), mas preciso estornar o valor para o cliente de alguma maneira (doc, ted). No caso do pix, imagino que o caminho é a devolução, assim como no caso do cartão de crédito, solicito a transação de estorno junto à operadora.
Boleto registrado tem as duas coisas. Dá para cancelar o boleto emitido e mesmo o cliente já tendo pago, pode ser cancelado pelo cliente até antes da conciliação bancária na madrugada.
Mas aí é o cliente que está cancelando, Rubens. Estamos falando do ponto de vista do EC recebedor. Depois de pago o boleto, do ponto de vista do recebedor, não se pode cancelar o boleto. Inclusive, isso não seria "devolução" (ver título dessa issue), seria só um cancelamento, por parte do próprio cliente. O emissor ainda nem seria "recebedor" até esse momento, ele não recebeu efetivamente nada ainda.
-edit-
Mas, sim, antes de pago, pode-se cancelar (diferentemente do originalmente dito pelo @dev-gto, que ele já cortou da mensagem dele).
Veja, quem implanta o sistema de cliente recebedor eventualmente levantarão as mesmas dúvidas que tive: como cancelar apropriadamente uma transação (e aí incluem-se ambos cobrança e pix)
Faz um paralelo com o boleto: se um cliente paga o boleto e você quer devolver o dinheiro por qualquer razão, você não cancela o boleto (não se pode cancelar boleto que já foi pago). Você só devolve o dinheiro.
No arranjo Pix, igual: você devolve o dinheiro (preferencialmente devolvendo a mesma transação de recebimento). Mas a cobrança, "já era", ela já foi marcada CONCLUIDA quando você recebeu o Pix.
Me perdoem, acho que deixei as coisas confusas. O "cenário" deste tópico é: o cliente já pagou por um produto com outra forma de pagamento. Quais os procedimentos para cancelar a transação envolvendo a API Pix, considerando que uma cobrança foi emitida? Queria saber o passo-a-passo considerando todas as situações: cliente não pagou pix, cliente pagou pix parcial, cliente pagou integral, e se posso estornar o valor pago só pela api de devolução.
Nem estou abordando o fato de boleto cancelado ou cobrança cancelada, estou interessado em não onerar o cliente (ou evitar um erro operacional). Veja: posso emitir um boleto, o cliente paga no cartão de crédito, mas o pessoal do financeiro dele paga o boleto.
Me perdoem, acho que deixei as coisas confusas. O "cenário" deste tópico é: o cliente já pagou por um produto com outra forma de pagamento. Quais os procedimentos para cancelar a transação envolvendo a API Pix, considerando que uma cobrança foi emitida? Queria saber o passo-a-passo considerando todas as situações:
Vamos lá.
cliente não pagou pix
Cancela a cobrança (PATCH com status REMOVIDA_PELO_USUARIO_RECEBEDOR). E só.
cliente pagou pix parcial, cliente pagou integral
Devolve a(s) transação(ões). E só.
e se posso estornar o valor pago só pela api de devolução.
Pode fazer como bem entender. Mas faz mais sentido e é mais seguro* ser através da devolução do Pix de recebimento.
[*] Não existe o "chargeback" no Pix, mas o BACEN já sinalizou que, em algumas situações (se for constatado algum tipo de fraude, por exemplo) ele pode determinar a devolução de um Pix por parte do PSP recebedor sem o comando do EC recebedor. Então, se for pra devolver algo, melhor que seja o próprio Pix, pra não acabar devolvendo "duas vezes" (por outro meio + pelo Pix devolvido) na eventualidade de algum erro por parte do seu PSP, por exemplo ("seguro morreu de velho").
A possibilidade de múltiplos Pix no array decorre não de uma única transação, mas de situações de alto tráfego de um EC. Se vier mais de um Pix na mesma PACS.008, e por acaso mais de um deles for do mesmo EC, aí faz sentido o webhook sinalizar vários Pix na mesma mensagem.
Como não está muito explícito na documentação, acaba dando margem para interpretações. Eu, pelo menos, imaginei que o cliente poderia fazer pagamentos parciais, uma parte usando o saldo da conta corrente no banco A, e complementar com o saldo no banco B.
A possibilidade de múltiplos Pix no array decorre não de uma única transação, mas de situações de alto tráfego de um EC. Se vier mais de um Pix na mesma PACS.008, e por acaso mais de um deles for do mesmo EC, aí faz sentido o webhook sinalizar vários Pix na mesma mensagem.
Como não está muito explícito na documentação, acaba dando margem para interpretações. Eu, pelo menos, imaginei que o cliente poderia fazer pagamentos parciais, uma parte usando o saldo da conta corrente no banco A, e complementar com o saldo no banco B.
Isso não é possível. O cliente deve enviar um Pix da conta A dele para a conta B, também dele. Depois, com o valor integralizado na conta B, paga o Pix de uma só vez.
A possibilidade de múltiplos Pix no array decorre não de uma única transação, mas de situações de alto tráfego de um EC. Se vier mais de um Pix na mesma PACS.008, e por acaso mais de um deles for do mesmo EC, aí faz sentido o webhook sinalizar vários Pix na mesma mensagem.
Como não está muito explícito na documentação, acaba dando margem para interpretações. Eu, pelo menos, imaginei que o cliente poderia fazer pagamentos parciais, uma parte usando o saldo da conta corrente no banco A, e complementar com o saldo no banco B.
Isso não é possível. O cliente deve enviar um Pix da conta A dele para a conta B, também dele. Depois, com o valor integralizado na conta B, paga o Pix de uma só vez.
Ou... assim como alguns e-commerce fazem divisão em 2 ou mais cartões, o cliente pede isso e o e-commerce gera n cobranças distintas, o cliente vai e paga uma em cada banco. Como se trata de saldo e não de limite, acho mais simples fazer como você sugeriu... mas não duvide da criatividade nacional. ;-)
Isso não é possível. O cliente deve enviar um Pix da conta A dele para a conta B, também dele. Depois, com o valor integralizado na conta B, paga o Pix de uma só vez.
Ou... assim como alguns e-commerce fazem divisão em 2 ou mais cartões, o cliente pede isso e o e-commerce gera n cobranças distintas, o cliente vai e paga uma em cada banco. Como se trata de saldo e não de limite, acho mais simples fazer como você sugeriu... mas não duvide da criatividade nacional. ;-)
Não duvido. Só não quero dar ideia para mais bizarrices.
Isso não é possível. O cliente deve enviar um Pix da conta A dele para a conta B, também dele. Depois, com o valor integralizado na conta B, paga o Pix de uma só vez.
Ou... assim como alguns e-commerce fazem divisão em 2 ou mais cartões, o cliente pede isso e o e-commerce gera n cobranças distintas, o cliente vai e paga uma em cada banco. Como se trata de saldo e não de limite, acho mais simples fazer como você sugeriu... mas não duvide da criatividade nacional. ;-)
Não duvido. Só não quero dar ideia para mais bizarrices.
Daí a necessidade de um manual de procedimentos, ou um manual de homologação (ou deixar mais claro nos documentos existentes)... o que garante que meu cliente recebedor não receba pix parciais que totalizam a transação, oriundas de um PSP pagador que nem tenho contato? Você nem precisa dar ideias, a criatividade é um perigo nesses casos...
Daí a necessidade de um manual de procedimentos, ou um manual de homologação (ou deixar mais claro nos documentos existentes)... o que garante que meu cliente recebedor não receba pix parciais que totalizam a transação, oriundas de um PSP pagador que nem tenho contato? Você nem precisa dar ideias, a criatividade é um perigo nesses casos...
Nas versões mais recentes das documentações essa linha já foi adotada (de que o QR Code dinâmico não pode ter o valor editado pelo pagador, assim como os QR Codes estáticos com valor definido). As "poucas" inconsistências de interoperabilidade ainda ativas no momento estão listadas aqui: https://github.com/renatofrota/pix-pendencias/issues/22 (essa, especificamente, aqui: https://github.com/renatofrota/pix-pendencias/issues/18).
Mas o fato é que se você receber qualquer Pix relacionado a uma cobrança, ela mudará de status (de ATIVA para CONCLUIDA). Não importa se foi o valor total ou não. Então, não tem como haver Pix relacionado a uma cobrança para ser devolvido e, ao mesmo tempo, ela ter qualquer status que não seja CONCLUIDA. Se tem Pix, ela sempre estará concluída (assim como um boleto pago, está sempre pago/baixado e não se pode cancelar o boleto, neste caso).
Considerando a hipótese de vários Pix sob uma única cobrança:
Do ponto de vista do PSP recebedor, acho isso estranho... dizer que a cobrança foi CONCLUIDA com Pix Parcial que não totaliza a cobrança.
Do ponto de vista do PSP pagador também fica estranho, pois complementar o pagamento de uma cobrança CONCLUIDA parece errado.
A margem de dúvida ocorre porque GET /cob/{txid} retorna um vetor de vetor de pix, e cada elemento pix tem um vetor de devoluções.
Se o intuito é deixar apenas um pix por cobrança, não haveria razão para usar o vetor como representação.
Considerando a hipótese de vários Pix sob uma única cobrança:
Do ponto de vista do PSP recebedor, acho isso estranho... dizer que a cobrança foi
CONCLUIDAcom Pix Parcial que não totaliza a cobrança.
Um boleto também pode ser pago com valor diferente (menor ou maior) e estará baixado.
De qualquer forma, enterra essa ideia de pagamento parcial. Nas versões mais recentes das documentações ficou esclarecido que o pagamento deve ser sempre o original da cobrança (ou o calculado para o dia do pagamento, se ela tem vencimento e juros/multa e estiver vencida).
Do ponto de vista do PSP pagador também fica estranho, pois complementar o pagamento de uma cobrança
CONCLUIDAparece errado.
Enterra essa ideia, também. Você pode encontrar referências antigas que dizem o contrário, mas as versões mais recentes do manual de iniciação deixa claro que, uma vez marcada como CONCLUIDA, a cobrança não admite novos pagamentos.
A margem de dúvida ocorre porque
GET /cob/{txid}retorna um vetor de vetor de pix, e cada elemento pix tem um vetor de devoluções. Se o intuito é deixar apenas um pix por cobrança, não haveria razão para usar o vetor como representação.
Sobre o vetor de pix: dá a possibilidade de que, em usos futuros, uma única cobrança possa ter mais de 1 Pix associado (split de pagamento, por exemplo).
Sobre o vetor de devoluções: ver https://github.com/bacen/pix-api/issues/274#issuecomment-754132810
De qualquer forma, enterra essa ideia de pagamento parcial. Nas versões mais recentes das documentações ficou esclarecido que o pagamento deve ser sempre o original da cobrança (ou o calculado para o dia do pagamento, se ela tem vencimento e juros/multa e estiver vencida). ... Sobre o vetor de pix: dá a possibilidade de que, em usos futuros, uma única cobrança possa ter mais de 1 Pix associado (split de pagamento, por exemplo).
Então enterramos temporariamente, pois meu entendimento de pagamentos parciais era esse split de pagamentos (vários pagamentos parciais para integrar a transação, e não o cliente pagar só uma parte e pronto, como no boleto). No cartão de crédito, seria pagar uma compra com dois cartões.
Quando eu falei de split, me referi à situação onde um cliente compra num marketplace e uma cobrança gerado pelo marketplace remunera o próprio marketplace + repassa o valor designado ao vendedor do produto numa só tacada, sem depender que o marketplace faça o repasse posterior. Então seria 1 só cobrança, que geraria 2 "e2eid" diferentes (cliente->marketplace, cliente->vendedor). Mas isso é só especulação minha.
O split no sentido de oferecer mais de 1 meio de pagamento, você pode fazer criando 2 cobranças diferentes (meio a meio ou até mesmo na proporção que bem entender) e o cliente paga as 2 separadamente; e apenas quando ambas estiverem pagas, dá-se a baixa no pedido.
O BACEN não foi incisivo o suficiente na documentação (e nem aqui no GitHub), no princípio, para deixar claro que uma cobrança não pode ser paga com valor inferior ao determinado
Para não haver nenhuma dúvida: a cobrança não pode ser paga com valor inferior ao determinado. É uma infração.
Mesmo sendo uma infração, não impede o PSP pagador de mandar um pix com valor inferior ao determinado, por erro, bug, desconhecimento, etc...
O BACEN não foi incisivo o suficiente na documentação (e nem aqui no GitHub), no princípio, para deixar claro que uma cobrança não pode ser paga com valor inferior ao determinado
Para não haver nenhuma dúvda: a cobrança não pode ser paga com valor inferior ao determinado. É uma infração.
Não restam dúvidas (agora). O autor da issue tomou conclusões com base em conteúdo desatualizado.
Mesmo sendo uma infração não impede o PSP pagador de mandar uma pix com valor inferior ao determinado, por erro, bug, desconhecimento, etc...
Infração essa que o PSP recebedor deveria detectar e rejeitar o pagamento (se a cobrança está registrada no PSP recebedor e o pagamento entrante com aquele txid não atende aos requisitos da cobrança, não há razão pro Pix ser aceito), certo? Independente da resposta a essa pergunta, compreendo que o EC pode, preventivamente, validar do seu lado, também. Mas de fato acabei ficando com essa dúvida, se o PSP é orientado a rejeitar o recebimento nessa situação.
Mas de fato acabei ficando com essa dúvida, se o PSP é orientado a rejeitar o recebimento nessa situação.
Complementando a dúvida: seja valor pago a mais, como valor pago a menos
Infração essa que o PSP recebedor deveria detectar e rejeitar o pagamento (se a cobrança está registrada no PSP recebedor e o pagamento entrante com aquele txid não atende aos requisitos da cobrança, não há razão pro Pix ser aceito), certo?
Exatamente, correto. Para acontecer de existir um pix com valor inferior ao determinado na cobrança, tem que existir erros nas duas pontas: pagadora e recebedora. No entanto, para ser bem preciso, com relação à ponta recebedora, eu não sei citar exatamente onde estaria escrito que deve ser rejeitado esse pix que está em desconformidade com a cobrança. Se não há essa citação, pode ser um gap, mas se é um gap ou não, se for o caso, é com o DECEM.
Mas de fato acabei ficando com essa dúvida, se o PSP é orientado a rejeitar o recebimento nessa situação.
Orientado, com certeza. Essa é seria a orientação. Não consigo dizer agora, de imediato, onde estaria essa "orientação" na documentação, escrita de forma direta. No mínimo, em nível github, temos essa orientação. Vou ver com o DECEM.