-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validade após vencimento #307
Comments
Correto. Validade após vencimento é sempre utilizando dias corridos. |
E no caso da data de vencimento cair num sábado e o prazo de validade for de 1 dia? Como proceder nesse caso, já que a validade seria até domingo, mas é possível pagar na segunda por causa da data de vencimento? |
@latrevisani, boa noite.
Procederia não atribuindo uma |
@ninrod , eu entendo que há alternativas para evitar tais problemas. Mas como é o cliente que manda esses atributos, isso pode acontecer. Por exemplo, a situação abaixo: |
@latrevisani , eu acho que o @ninrod se confundiu na última resposta. Se o vencimento cair no sábado, seja o validadeAposVencimento 0 ou 1, o QR Code dinâmico relativo a essa cobrança deve ser pagável na segunda-feira de qualquer forma, por força de lei (Art. 1º Lei 7.089/1983), que obriga que o título com vencimento em dia não útil seja acatado no primeiro dia útil subsequente (sem multa ou juros, inclusive). |
Não, é isso mesmo que eu disse. Ele não fica pagável, mesmo. A única solução que entendo que haveria para não cairmos nesse corner case seria forçar um
Concordo. Vou falar com o DECEM para ver se podemos incluir esse valor mínimo na 2.2.1. |
Não evitaria se o vencimento fosse no sábado que antecede o carnaval (já que a segunda-feira subsequente é feriado bancário, sendo o primeiro dia útil apenas a quarta-feira) ou uma quinta-feira feriado de ano novo (onde normalmente seria decretado feriado bancário na sexta-feira, sendo segunda-feira o primeiro dia útil subsequente), casos onde seriam necessários 4 dias. No meu ponto de vista, a solução é simples: dataLimite = [ max ( (vencimento + validadeAposVencimento), vencimentoEfetivo + validadeAposVencimento ) ] onde "vencimentoEfetivo" = o próprio vencimento quando dia útil ou o primeiro dia útil subsequente. |
Isso mesmo, talvez 5 dias de seja um bom limite mínimo. |
Bom mesmo seria corrigir esse gap e permitir o valor zero para o validadeAposVencimento com a aplicação da fórmula sugerida acima (que eu entendo ser como funciona nos boletos). |
A gente usa na nossa emissão de boletos 5 dias, mas para compensar tanto feriados quanto a recepção via agentes lotéricos. |
Usaremos essa semântica. Exemplo:
|
Certo. Então, nesse caso, se validadeAposVencimento for 1 e o vencimento 2020-12-25 (sexta-feira, feriado) será pagável até terça-feira, 2020-12-29. Há alguma razão em particular para não se dar a possibilidade de validadeAposVencimento ser calculada a partir do vencimento original e o fato de o vencimento ser um dia não útil permitir o pagamento no primeiro dia útil subsequente como caráter de exceção e independente do valor de validadeAposVencimento? Pergunto isso pois seria justamente uma forma de garantir que o pagamento será recebido dentro do intervalo "data de vencimento + X dias", tal qual o nome do campo se propõe, enquanto a forma sugerida acaba dando margem para um pagamento acatado 4 dias depois do vencimento (e sendo o segundo dia útil subsequente, não o primeiro) enquanto o valor do campo é 1. A semântica, no meu ponto de vista, ficaria até bastante simples: "O campo Não há sequer necessidade de informar o caráter de exceção, pois ele é dado por força de lei e não pelo regulamento do próprio Pix (e na eventual mudança da lei, não seria necessário atualizar documentação nenhuma e o caráter de exceção deixaria de existir). Ou, se preferirem forçar a padronização (por segurança), inclui-se a exceção criada pela lei do dia útil na própria documentação: "O campo |
Exatamente.
@renatofrota , não entendi se há alguma diferença entre o que eu e você estamos falando. Entendi que o efeito é o mesmo. Melhor explicar com exemplos. Estamos usando exatamente a mesma semântica da fórmula |
Situação: Cobrança com vencimento: 2020-12-25 (sexta-feira, feriado). A semântica que você propôs: " Resultados:
Pagamento na sexta-feira: aceito
Pagamento na sexta-feira: aceito São 4 dias corridos e DOIS dias úteis após vencimento apesar do valor estar definido como E essa semântica não atende a fórmula A semântica que eu proponho (e que atende à formula): "O campo Resultados:
Pagamento na sexta-feira: aceito
Pagamento na sexta-feira: aceito Aqui, a terça-feira excede |
Ok, @renatofrota, ficaram claras as diferenças. |
Particularmente acho os dois modelos válidos e não tenho uma preferência, mas agradeço por indicar essa nuance, ajuda a tomar uma decisão mais informada. De qualquer maneira, a decisão caberá ao DECEM. Apresentarei os dois modelos, obrigado. edit: devemos utilizar o segundo modelo: Caso: Cobrança com vencimento: 2020-12-25 (sexta-feira, feriado).
Resultados:
validadeAposVencimento = 0
Pagamento na sexta-feira: aceito
Pagamento no sábado: aceito
Pagamento no domingo: aceito
Pagamento na segunda-feira: aceito
Pagamento na terça-feira: recusado
validadeAposVencimento = 1
Pagamento na sexta-feira: aceito
Pagamento no sábado: aceito
Pagamento no domingo: aceito
Pagamento na segunda-feira: aceito
Pagamento na terça-feira: recusado <- continua recusado |
Obrigado pela atenção. Só uma correção a respeito do que eu falei antes. Eu usei "max" onde deveria ser "min" na fórmula. Corrigindo:
De qualquer forma, talvez haja uma fórmula mais simples de explicar. Mas fico feliz que minha sugestão tenha sido aceita. 😃 |
Obrigado pelas contribuições. Acho que vou complementar a explicação com os exemplos mesmo. Fica mais didático. |
Prezados, já está no master. |
Caso um pagamento tenha a data de validade finalizando em um sábado, não pode ser pago na segunda?
Por exemplo:
Vencimento: 01/02
Validade após vencimento: 5 --> 06/02 (sábado)
A cobrança não pode ser paga segunda-feira, certo?
The text was updated successfully, but these errors were encountered: