Open jorgebaruchi opened 3 years ago
Boa tarde,
Conforme documentação da API Pix, ao consultar um payload, a instituição do pagador deve fornecer o código do munícipio, utilizando como referência os códigos IBGE. Assim a instituição recebedora deve utilizar este código para calcular o valor devido.
Poderiam nos ajudar a entender qual seria referência oficial do Pix obter os feriados municipais / estaduais por código IBGE de cada munício. Existe um padrão de arquivo que possamos importar ou uma API que possamos consumir ?
Muito obrigado
Nunca usei, mas parece existir este aqui: http://www.calendario.com.br/api_feriados_municipais_estaduais_nacionais.php
Boa tarde, Conforme documentação da API Pix, ao consultar um payload, a instituição do pagador deve fornecer o código do munícipio, utilizando como referência os códigos IBGE. Assim a instituição recebedora deve utilizar este código para calcular o valor devido. Poderiam nos ajudar a entender qual seria referência oficial do Pix obter os feriados municipais / estaduais por código IBGE de cada munício. Existe um padrão de arquivo que possamos importar ou uma API que possamos consumir ? Muito obrigado
Nunca usei, mas parece existir este aqui: http://www.calendario.com.br/api_feriados_municipais_estaduais_nacionais.php
Esta não me parece ser uma fonte Oficial e por sua vez, confiável.
Aguardando
Nunca usei, mas parece existir este aqui: http://www.calendario.com.br/api_feriados_municipais_estaduais_nacionais.php
Esta não me parece ser uma fonte Oficial e por sua vez, confiável.
Se existissem, seriam 5570 + 27 + 1 = 5598 fontes oficiais, para levar em conta todos os entes federados. O que já vi no BACEN e na ANBIMA é a lista de feriados bancários, que são bem menos do que os feriados aplicáveis em todo lugar. O do BACEN é o https://www3.bcb.gov.br/expectativas/publico/consulta/feriados .
acredito que seria aqui: https://www.ibge.gov.br/explica/codigos-dos-municipios.php
acredito que seria aqui: https://www.ibge.gov.br/explica/codigos-dos-municipios.php
@ninrod aí tem apenas a lista de municípios, não de todos os feriados aplicáveis em um município num determinado ano...
@ninrod aí tem apenas a lista de municípios, não de todos os feriados aplicáveis em um município num determinado ano...
Confundi, ok.
Não existe uma lista oficial que responda esta pergunta e o BCB não estabelece uma. O PSP e o mercado estão livres para utilizar o método, software ou solução que quiserem para resolver o problema.
@ninrod aí tem apenas a lista de municípios, não de todos os feriados aplicáveis em um município num determinado ano...
Confundi, ok.
Não existe uma lista oficial que responda esta pergunta e o BCB não estabelece uma. O PSP e o mercado estão livres para utilizar o método, software ou solução que quiserem para resolver o problema.
Na verdade, existe a lista de feriados bancários da Febraban.
Na verdade, existe a lista de feriados bancários da Febraban.
Ótimo. Por oficial eu quero dizer "não é obrigatória a ser adotada por regramento do BACEN".
O pessoal que trabalha no T.I. dos bancos e já lida com essa mesma questão na hora de acatar pagamentos de boletos poderia deixar de ser apenar um observador (e extrator de informações) deste repositório e passar a contribuir compartilhando as soluções que utiliza (provavelmente já conheciam a URL que passei acima, por exemplo).
@ninrod aí tem apenas a lista de municípios, não de todos os feriados aplicáveis em um município num determinado ano...
Confundi, ok. Não existe uma lista oficial que responda esta pergunta e o BCB não estabelece uma. O PSP e o mercado estão livres para utilizar o método, software ou solução que quiserem para resolver o problema.
Na verdade, existe a lista de feriados bancários da Febraban.
Muito interessante. Ela cita o seguinte como fonte: Fonte: Banco do Brasil - CAF501 v.006064 de 19/11/2020 - importado em 20/11/2020 08:02:55
Como o nome sugere, o arquivo CAF501 remete ao "Cadastro de Agencias e Feriados" e não contém os mesmos códigos de município utilizados pelo IBGE, dificultando o relacionamento entre as bases. Além do fato que este arquivo é de mais fácil acesso a Bancos e nem todos os PSPs se enquadram nesta classificação.
A especificação da API Pix descreve claramente que devemos utilizar o código IBGE para buscar os feriados, fazendo-nos entender que o BACEN consultou algum órgão / instituição para entender que esta implementação era viável. Portando, o BACEN conseguiria nos informar a qual base devemos nos referenciar e haver homogeneidade nas implementações entre diferentes PSPs. A padronização antecipada evita também retrabalho de ambas as partes.
Esta definição é de extrema importância para que não hajam diferenças de cálculos entre os PSPs, ocasionando até em questões legais, já que o pagador poderia ser lesado em função da rejeição de pagamentos.
@ninrod, poderia nos ajudar neste ponto?
Obrigado, Jorge.
A especificação da API Pix descreve claramente que devemos utilizar o código IBGE para buscar os feriados
bom dia @jorgebaruchi.
O PSP pagador tem que informar o PSP recebedor qual é o domicílio bancário do usuário pagador. Para que isso não seja feito de forma "livre", e portanto, para que não exista uma quebra de interoperabilidade, a API tem que escolher um padrão para a informação deste atributo. O BCB entendeu adequado adotar a tabela de códigos de municípios do IBGE.
A ideia é que O PSP detendo esta informação acerca do município, encontrar feriados municipais ou estaduais torna-se possível, dada uma data específica.
Como exatamente o PSP recebedor executará essa implementação transcende a especificação e é uma liberalidade do PSP recebedor.
fazendo-nos entender que o BACEN consultou algum órgão / instituição para entender que esta implementação era viável.
A implementação deve ser viável, uma vez que se tenha posse da informação de domicílio bancário, porque existe este mesmo caso de uso para o arranjo "boleto".
Apenas hipoteticamente falando, como exemplo, não haveria óbice algum em criar-se uma startup para fornecer aos PSPs uma API para consulta desta informação, via convênios com os legislativos municipais e estaduais e distritais. Novamente, o BACEN não estabelece regramento para a obtenção desta informação.
Sugestões:
o PSP do pagador poderia passar ao PSP recebedor a informação se a véspera foi feriado ou não;
ainda mais precisamente, poderia passar qual data específica deve ser considerada para o cálculo do acolhimento do pagamento;
o Pix acolhe pagamentos 7/365, um pagamento após o vencimento deveria ser considerado um pagamento vencido (e ponto, desconsiderando-se feriados).
Tem alguma lei que rege a obrigatoriedade do acolhimento sem cobrança de juros/multa por qualquer meio de pagamento pós-feriado? Na minha visão, se o meio de pagamento da escolha do pagador for o pagamento de um boleto (que só pode ser acolhido em dias úteis), até faz sentido que seja acolhido sem juros e multa no primeiro dia útil após o feriado. Mas se escolher a conveniência do Pix, que funciona 7/365, se ele deixar o vencimento passar, problema dele... :roll_eyes:
@ninrod,
No arranjo de boletos, recebemos o pagamento por COB615, onde sempre é informada a Agência que recebeu o pagamento, seja ela física ou por algum meio digital (já que o usuário de acesso do pagador no Internet Banking sempre está ligado a uma Ag/Cta e geralmente é considerada esta para tal).
Com esta informação da agência, é possível identificar cruzar dados do arquivo CAF502 (cadastro de Agências X Municípios) com os feriados da CAF501 (Municípios X Feriados).
A dúvida é que não há relacionamento entre os códigos de municípios IBGE e o arquivo CAF501 (idem ao que é feito usando o arquivo CAF502), ou seja, dificultando a implementação homogênea e padronizada que poderíamos alinhar nesta thread.
De fato, sempre é possível criar soluções privadas e resolver o problema, mas isso não traz a garantia de uma mesma fórmula de cálculo entre diferentes PSPs.
o Pix acolhe pagamentos 7/365, um pagamento após o vencimento deveria ser considerado um pagamento vencido (e ponto, desconsiderando-se feriados).
Tem alguma lei que rege a obrigatoriedade do acolhimento sem cobrança de juros/multa por qualquer meio de pagamento pós-feriado? Na minha visão, se o meio de pagamento da escolha do pagador for o pagamento de um boleto (que só pode ser acolhido em dias úteis), até faz sentido que seja acolhido sem juros e multa no primeiro dia útil após o feriado. Mas se escolher a conveniência do Pix, que funciona 7/365, se ele deixar o vencimento passar, problema dele... 🙄
Interessante sua observação 👍
Sugestões:
- o PSP do pagador poderia passar ao PSP recebedor a informação se a véspera foi feriado ou não;
- ainda mais precisamente, poderia passar qual data específica deve ser considerada para o cálculo do acolhimento do pagamento;
- o Pix acolhe pagamentos 7/365, um pagamento após o vencimento deveria ser considerado um pagamento vencido (e ponto, desconsiderando-se feriados).
Tem alguma lei que rege a obrigatoriedade do acolhimento sem cobrança de juros/multa por qualquer meio de pagamento pós-feriado? Na minha visão, se o meio de pagamento da escolha do pagador for o pagamento de um boleto (que só pode ser acolhido em dias úteis), até faz sentido que seja acolhido sem juros e multa no primeiro dia útil após o feriado. Mas se escolher a conveniência do Pix, que funciona 7/365, se ele deixar o vencimento passar, problema dele... 🙄
Se a lei não restringe ou não especifica o meio de pagamento, vale para qualquer meio de pagamento. O próprio BACEN reconheceu que se aplica ao Pix no design das cobranças com vencimento que ganham município e data pretendida de pagamento para que o PSP leve em conta feriados.
Dados as ações judiciais que já recebemos, te digo que perderíamos se tentássemos usar o argumento de que o Pix é 24x7x365.
Mas a lei 7089 diz que o acolhimento de títulos deve ser acatado no primeiro dia útil subsequente ao sábado/domingo/feriado. Um QR Code Pix é um "título"?
Bora movimentar o legislativo pra modificar essa lei e especificar que a obrigatoriedade só se aplica aos meios de pagamento que não poderiam, naturalmente, acolher os pagamentos aos sábados/domingos/feriados!
Mas a lei 7089 diz que o acolhimento de títulos deve ser acatado no primeiro dia útil subsequente ao sábado/domingo/feriado. Um QR Code Pix é um "título"?
O documento que contém o QR Code Pix é um título. Pode ser um e-mail, uma página Web ou mesmo algo impresso; todos são títulos, independente de o que eles contém para pagamento (barcode CIP, QR-Code Pix, QR-Code de outro arranjo etc.).
Bora movimentar o legislativo pra modificar essa lei e especificar que a obrigatoriedade só se aplica aos meios de pagamento que não poderiam, naturalmente, acolher os pagamentos aos sábados/domingos/feriados!
Um problema disso é que o Pix prevê limites diferentes em horário comercial de dias úteis dos horários não comerciais ou de dias não úteis. Então se um Pix com vencimento tem alto valor, alguém pode não conseguir pagar num (por exemplo) domingo, mesmo que tenha saldo e mesmo que tenha acesso ao aplicativo para fazer Pix.
Mas a lei 7089 diz que o acolhimento de títulos deve ser acatado no primeiro dia útil subsequente ao sábado/domingo/feriado. Um QR Code Pix é um "título"?
O documento que contém o QR Code Pix é um título. Pode ser um e-mail, uma página Web ou mesmo algo impresso; todos são títulos, independente de o que eles contém para pagamento (barcode CIP, QR-Code Pix, QR-Code de outro arranjo etc.).
Bora movimentar o legislativo pra modificar essa lei e especificar que a obrigatoriedade só se aplica aos meios de pagamento que não poderiam, naturalmente, acolher os pagamentos aos sábados/domingos/feriados!
Um problema disso é que o Pix prevê limites diferentes em horário comercial de dias úteis dos horários não comerciais ou de dias não úteis. Então se um Pix com vencimento tem alto valor, alguém pode não conseguir pagar num (por exemplo) domingo, mesmo que tenha saldo e mesmo que tenha acesso ao aplicativo para fazer Pix.
O que também poderia acontecer, igualmente, na segunda-feira, certo?
Se o vencimento é o domingo, o cliente deveria pagar até o domingo (ou na segunda por boleto, se a empresa aceitar boletos, pela impossibilidade do boleto ser pago domingo).
Que frustrante... o país onde burocratizar as coisas é o caminho "natural" :facepalm:
Mas a lei 7089 diz que o acolhimento de títulos deve ser acatado no primeiro dia útil subsequente ao sábado/domingo/feriado. Um QR Code Pix é um "título"?
O documento que contém o QR Code Pix é um título. Pode ser um e-mail, uma página Web ou mesmo algo impresso; todos são títulos, independente de o que eles contém para pagamento (barcode CIP, QR-Code Pix, QR-Code de outro arranjo etc.).
Bora movimentar o legislativo pra modificar essa lei e especificar que a obrigatoriedade só se aplica aos meios de pagamento que não poderiam, naturalmente, acolher os pagamentos aos sábados/domingos/feriados!
Um problema disso é que o Pix prevê limites diferentes em horário comercial de dias úteis dos horários não comerciais ou de dias não úteis. Então se um Pix com vencimento tem alto valor, alguém pode não conseguir pagar num (por exemplo) domingo, mesmo que tenha saldo e mesmo que tenha acesso ao aplicativo para fazer Pix.
O que também poderia acontecer, igualmente, na segunda-feira, certo?
Não, no horário comercial o limite do Pix volta a ser baseado no limite da TED e não do cartão do débito. Eu já vi situações do limite da TED ser 10x o do cartão de débito.
Se o vencimento é o domingo, o cliente deveria pagar até o domingo (ou na segunda por boleto, se a empresa aceitar boletos, pela impossibilidade do boleto ser pago domingo).
O cliente poderia alegar que tem o direito legal de pagar na 2a.
Não, no horário comercial o limite do Pix volta a ser baseado no limite da TED e não do cartão do débito. Eu já vi situações do limite da TED ser 10x o do cartão de débito.
E se o "título" for de R$ 10.000 e o limite do sujeito for R$ 1.000 no FDS e R$ 5.000 na semana? :joy:
Concorda que não é responsabilidade do emissor da título saber qual o limite do pagador e o dia que ele pretente pagar?
Mesmo num cenário onde o pagador só tenha condições de pagar em dias úteis, ele que pague em dias úteis, ué. Ele tem que saber das suas responsabilidades e dos limites de pagamento que o seu banco oferece.
Se o vencimento é o domingo, o cliente deveria pagar até o domingo (ou na segunda por boleto, se a empresa aceitar boletos, pela impossibilidade do boleto ser pago domingo).
O cliente poderia alegar que tem o direito legal de pagar na 2a.
Eu entendo. Por isso sugeri que o legislativo deveria ser acionado a mudar a lei. Houve muito tempo pra isso durante o desenvolvimento do Pix (e ainda está em tempo de se corrigir, já que o BACEN não estipulou as formas de se obter a informação e na prática não está funcional). Com a mudança da lei, resolveria-se o problema em definitivo e simplificaria horrores o funcionamento do Pix nesse aspecto.
De qualquer forma, como questões legais envolvem tempo e o prazo para implantação de QRs do tipo "cobv" já está valendo, não vejo que será possível mudar a regra agora, mas precisamos padronizar um how-to para atender a especificação da API Pix.
De qualquer forma, como questões legais envolvem tempo e o prazo para implantação de QRs do tipo "cobv" já está valendo, não vejo que será possível mudar a regra agora, mas precisamos padronizar um how-to para atender a especificação da API Pix.
Mas já ficou claro que é cada um por si... talvez a FEBRABAN e a ABFintech possam patrocinar um esforço de gerar uma versão com códigos de município IBGE do arquivo CAF501 do BB.
De fato, ficou complicado mesmo para fornecer uma solução final com garantia de que vamos estar falando a mesma linguagem. =(
Tem alguma lei que rege a obrigatoriedade do acolhimento sem cobrança de juros/multa por qualquer meio de pagamento pós-feriado? Na minha visão, se o meio de pagamento da escolha do pagador for o pagamento de um boleto (que só pode ser acolhido em dias úteis), até faz sentido que seja acolhido sem juros e multa no primeiro dia útil após o feriado. Mas se escolher a conveniência do Pix, que funciona 7/365, se ele deixar o vencimento passar, problema dele... 🙄
__Tem__. Por causa exatamente desta lei é que algumas mecânicas foram implementadas na cobrança com vencimento, como as diferentes modalides de juros e multa, por exemplo.
@ninrod,
No arranjo de boletos, recebemos o pagamento por COB615, onde sempre é informada a Agência que recebeu o pagamento, seja ela física ou por algum meio digital (já que o usuário de acesso do pagador no Internet Banking sempre está ligado a uma Ag/Cta e geralmente é considerada esta para tal).
Com esta informação da agência, é possível identificar cruzar dados do arquivo CAF502 (cadastro de Agências X Municípios) com os feriados da CAF501 (Municípios X Feriados).
A dúvida é que não há relacionamento entre os códigos de municípios IBGE e o arquivo CAF501 (idem ao que é feito usando o arquivo CAF502), ou seja, dificultando a implementação homogênea e padronizada que poderíamos alinhar nesta thread.
De fato, sempre é possível criar soluções privadas e resolver o problema, mas isso não traz a garantia de uma mesma fórmula de cálculo entre diferentes PSPs.
Sem querer sugerir um caminho para resolver a questão, não seria trivial implementar um mapeamento IBGE-> CAF501?
Suponha que, para o município X, e para a DPP yyyy-mm-dd, o PSP A
calcule de forma errada o valor da cobrança (errando em um dia últil, desconsiderando um feriado municipal que existe). Ao mesmo tempo, o PSP B
calcular de maneira correta.
Qual é, de fato, o problema? Ou os problemas? Vejo dois.
1) os usuários pagadores que forem pagar cobranças emitidas pelo PSP A
poderão reclamar para os órgãos competentes que de acordo com a LEI XYZ/AA, o usuário recebedor do PSP A
deveria postergar a cobrança de multa em um dia devido ao feriado bancário municipal "tal". Isso vai causar um transtorno para o usuário recebedor que terá, para esses casos de usuários pagadores que conhecem esta lei, alterar a cobrança via PATCH /cobv/{txid}
.
2) O usuário recebedor pode ficar insatisfeito com a performance do PSP A
em termos de observância destes feriados e migrar para o PSP B
.
Não há, portanto, problemas de interoperabilidade.
Os problemas são de liability, não de interoperabilidade. E isso é algo que os PSTIs vão ter que alertar os PSPs. O risco com isso é de reduzir a oferta do escopo cobv por PSPs recebedores; a quantidade de PSPs com API Pix já é pequena.
DISCLAIMER: não sou advogado, de nenhuma maneira entendam isso como aconselhamento jurídico. Estou apenas querendo contribuir com o mercado para o entendimento da questão.
Mas a lei 7089 diz que o acolhimento de títulos deve ser acatado no primeiro dia útil subsequente ao sábado/domingo/feriado. Um QR Code Pix é um "título"?
Entendo que não é que exatamente o QR Code Pix é um título: o "título" continua sendo o título como sempre foi. Você só está escolhendo pagar via Pix. Poderia ser com dinheiro. Poderia ser com outro arranjo. O fato é que seja qual for o arranjo escolhido, vale a regra de que títulos só se pagam em dias úteis considerando-se dias não úteis feriados bancários municipais, estaduais, distritais, nacionais e universais.
Art 1º - Fica proibida a cobrança de juros de mora, por estabelecimentos bancários e instituições financeiras, sobre títulos de qualquer natureza, cujo vencimento se dê em sábado, domingo ou feriado, desde que seja quitado no primeiro dia subsequente.
O QR Code Pix é um instrumento utilizado para honrar uma cobrança, um título. Não se pode exigir do usuário pagador que honre este título em um dia não útil, segundo esta lei LEI No 7.089, DE 23 DE MARÇO DE 1983 , só porque está se pagando via Pix. É um comportamento vedado.
Esse é o entendimento atual acerca da questão.
O cliente poderia alegar que tem o direito legal de pagar na 2a.
Esse é o ponto central. E é por isso que a cobrança com vencimento, na API Pix, apresenta certas mecânicas específicas para tratar essa situação.
Eu entendo. Por isso sugeri que o legislativo deveria ser acionado a mudar a lei. Houve muito tempo pra isso durante o desenvolvimento do Pix (e ainda está em tempo de se corrigir, já que o BACEN não estipulou as formas de se obter a informação e na prática não está funcional). Com a mudança da lei, resolveria-se o problema em definitivo e simplificaria horrores o funcionamento do Pix nesse aspecto.
É um caminho válido, você tem razão, @renatofrota. Mas do outro lado da questão, você está retirando direitos do consumidor ao tentar implementar essa mudança no regramento jurídico.
Eu entendo. Por isso sugeri que o legislativo deveria ser acionado a mudar a lei. Houve muito tempo pra isso durante o desenvolvimento do Pix (e ainda está em tempo de se corrigir, já que o BACEN não estipulou as formas de se obter a informação e na prática não está funcional). Com a mudança da lei, resolveria-se o problema em definitivo e simplificaria horrores o funcionamento do Pix nesse aspecto.
É um caminho válido, você tem razão, @renatofrota. Mas do outro lado da questão, você está retirando direitos do consumidor ao tentar implementar essa mudança no regramento jurídico.
Discordo. O cliente continua podendo pagar no dia útil subsequente via boleto (por impossibilidade do método acatar o pagamento no fds/feriado). Ninguém tem atualmente o direito de pagar conta atrasada e simplesmente continuaria não tendo.
Discordo. O cliente continua podendo pagar no dia útil subsequente via boleto (por impossibilidade do método acatar o pagamento no fds/feriado). Ninguém tem atualmente o direito de pagar conta atrasada e simplesmente continuaria não tendo.
se entendi direito, estaria obrigando o usuário recebedor a sempre ofertar o boleto como meio de pagamento adicional por medo de o usuário pagador reclamar seus direitos ao não poder pagar no dia útil subsequente por pix.
Discordo. O cliente continua podendo pagar no dia útil subsequente via boleto (por impossibilidade do método acatar o pagamento no fds/feriado). Ninguém tem atualmente o direito de pagar conta atrasada e simplesmente continuaria não tendo.
se entendi direito, estaria obrigando o usuário recebedor a sempre ofertar o boleto como meio de pagamento adicional por medo de o usuário pagador reclamar seus direitos ao não poder pagar no dia útil subsequente por pix.
Mas aí cabe a quem emite a cobrança emitir para a data que considerar conveniente. Se ofertar apenas pagamento via Pix, o fazer definindo vencimentos apenas em dias úteis se quiser evitar o possível contratempo ao consumidor. Inclusive na emissão de boletos hoje já se tem adotado essa prática. Um cartão de crédito que sempre vence dia 20, se for um sábado, só vence dia 22, segunda-feira. Aí não se tem discussão ou briga por direitos em hipótese nenhuma.
É um caminho válido, você tem razão, @renatofrota. Mas do outro lado da questão, você está retirando direitos do consumidor ao tentar implementar essa mudança no regramento jurídico.
Discordo. O cliente continua podendo pagar no dia útil subsequente via boleto (por impossibilidade do método acatar o pagamento no fds/feriado). Ninguém tem atualmente o direito de pagar conta atrasada e simplesmente continuaria não tendo.
Veja: se derrubar o regramento jurídico que determina essa mecânica do pagamento no dia "verdadeiramente" útil, o próprio arranjo de boleto poderia ser alterado para não mais considerar essa mecânica. É uma remoção de direitos do consumidor, existindo ou não boleto.
Veja: se derrubar o regramento jurídico que determina essa mecânica do pagamento no dia "verdadeiramente" útil, o próprio arranjo de boleto poderia ser alterado para não mais considerar essa mecânica. É uma remoção de direitos do consumidor, existindo ou não boleto.
Eu não falei em derrubar o regramento. Citando minha propry reply anterior:
Bora movimentar o legislativo pra modificar essa lei e especificar que a obrigatoriedade só se aplica aos meios de pagamento que não poderiam, naturalmente, acolher os pagamentos aos sábados/domingos/feriados!
Veja: se derrubar o regramento jurídico que determina essa mecânica do pagamento no dia "verdadeiramente" útil, o próprio arranjo de boleto poderia ser alterado para não mais considerar essa mecânica. É uma remoção de direitos do consumidor, existindo ou não boleto.
Eu não falei em derrubar o regramento. Citando minha propry reply anterior:
Bora movimentar o legislativo pra modificar essa lei e especificar que a obrigatoriedade só se aplica aos meios de pagamento que não poderiam, naturalmente, acolher os pagamentos aos sábados/domingos/feriados!
Mas nesse caso, o regramento de limites precisaria ser alterado para dar um bom limite de Pix mesmo em sábados, domingos e feriados. O horário noturno poderia continuar limitado pois cabe a quem paga fazer isso no horário apropriado ou agendar para que assim aconteça.
Veja: se derrubar o regramento jurídico que determina essa mecânica do pagamento no dia "verdadeiramente" útil, o próprio arranjo de boleto poderia ser alterado para não mais considerar essa mecânica. É uma remoção de direitos do consumidor, existindo ou não boleto.
Eu não falei em derrubar o regramento. Citando minha propry reply anterior:
Bora movimentar o legislativo pra modificar essa lei e especificar que a obrigatoriedade só se aplica aos meios de pagamento que não poderiam, naturalmente, acolher os pagamentos aos sábados/domingos/feriados!
Mas nesse caso, o regramento de limites precisaria ser alterado para dar um bom limite de Pix mesmo em sábados, domingos e feriados. O horário noturno poderia continuar limitado pois cabe a quem paga fazer isso no horário apropriado ou agendar para que assim aconteça.
É uma recomendação interessante. Mas o recebedor já poderia simplesmente, se considerar relevante para a situação, emitir a cobrança especificamente para dias úteis. Não é uma necessidade absoluta, se a lei viabilizar o entendimento que eu propus (que o direito de pagar no dia útil subsequente é uma consequência baseada na indisponibilidade do método de pagamento utilizado no dia original do vencimento).
Apenas hipoteticamente falando, como exemplo, não haveria óbice algum em criar-se uma startup para fornecer aos PSPs uma API para consulta desta informação, via convênios com os legislativos municipais e estaduais e distritais. Novamente, o BACEN não estabelece regramento para a obtenção desta informação.
Voltando a isso (que ficou de lado nos comentários mais recentes), eu pergunto:
E se essa startup não surgir, aí todos os PSPs vão ficar praticamente sem viabilidade técnica para cumprir a determinação do BACEN?
A determinação deveria ser baseada na disponibilidade das informações necessárias para o cumprimento da mesma (se não disponibilizadas pelo próprio BACEN, ao menos uma metodologia clara de como obter as informações deveria ser apontada), ao tempo da vigência da determinação. Uma determinação ser imposta com base na premissa de que "a viabilidade se fará existir posteriormente a divulgação da exigência" (sem nenhuma garantia disso) é absurda por si só.
Ou parece normal uma situação que pode ser resumida como:
Você tem que fazer. Como? _ Não sei. Mas tem que fazer.
:roll_eyes:
Ou parece normal uma situação que pode ser resumida como:
Você tem que fazer. Como? _ Não sei. Mas tem que fazer.
Sim, também acho que este ponto ficou muito mal alinhado.
Ou parece normal uma situação que pode ser resumida como:
Você tem que fazer.
Eu entendo a posição, mas ressalto que ninguém tem que fazer. Não há absolutamente nenhuma data imposta pelo BCB para a disponibilização da API Pix. Nenhum PSP recebedor está obrigado a implementar a API Pix ou a "oferecer integração Pix de maneira automatizada".
Isso posto, eu posso ajudar se vocês me conseguirem me explicar o motivo de ser tão difícil implementar essa funcionalidade já que o arranjo de boleto funciona desta maneira. Especificamente, gostaria de saber por que, no arranjo de boleto, os PSPs conseguem implementar essa mecânica, e não conseguiriam no arranjo Pix. Quanto mais detalhes, melhor.
Repetindo o que eu disse acima (acho que ficou perdido):
Sem querer sugerir um caminho para resolver a questão, não seria trivial implementar um mapeamento IBGE-> CAF501?
Repetindo o que eu disse acima (acho que ficou perdido):
Sem querer sugerir um caminho para resolver a questão, não seria trivial implementar um mapeamento IBGE-> CAF501?0
O problema é que nem todos os participantes são de fato bancos e este arquivos CAF são disponibilizados aos bancos.
Ainda sim, ignorando este problema, vemos que somente seria possível este mapeamento via comparação de valores alfanuméricos (String para String), sujeitos a diferenças de acentuação ou outros problemas já sabidos deste tipo de abordagem. Exemplo de um UPDATE:
UPDATE MUNICIPIO MUN SET MUN.ID_CAF = ( SELECT MAX(CAF.ID_MUNICIPIO) FROM CAF_MUNICIPIO CAF WHERE CAF.NOME_MUNICIPIO = MUN.NOME AND CAF.UF = MUN.UF ) WHERE MUN.ID_CAF IS NULL;
Na minha opinião, ainda acho uma solução simplista e que pode acarretar em diferenças entre os PSPs. No mínimo, precisaríamos de uma base / arquivo consolidado e centralizado, onde todos os PSPs já pudessem obter este mapeamento, evitando tais diferenças. Poderia ser um arquivo colaborativo, porém centralizado no BACEN, onde pudéssemos informar quaisquer divergências.
O que acha @ninrod ?
O problema é que nem todos os participantes são de fato bancos e este arquivos CAF são disponibilizados aos bancos.
Ponto recebido.
Ainda sim, ignorando este problema, vemos que somente seria possível este mapeamento via comparação de valores alfanuméricos (String para String), sujeitos a diferenças de acentuação ou outros problemas já sabidos deste tipo de abordagem. Exemplo de um UPDATE:
UPDATE MUNICIPIO MUN SET MUN.ID_CAF = ( SELECT MAX(CAF.ID_MUNICIPIO) FROM CAF_MUNICIPIO CAF WHERE CAF.NOME_MUNICIPIO = MUN.NOME AND CAF.UF = MUN.UF ) WHERE MUN.ID_CAF IS NULL;
Gostaria de entender um pouco mais em detalhe. A tabela de municípios do IBGE diz
3550308 é São Paulo.
Como o arquivo CAF identifica a cidade de são paulo?
No arquivo CAF501 que tivemos acesso, temos esta linha referente ao município de SP:
007388SAO PAULO SP1F2018SAO PAULO - SP 10001600 010 202101250202107090202311200 000573
Sendo o código 007388 (posição 1 a 6), referente a SAO PAULO (7 a 44) e a UF como SP (posição 45 a 47).
Cada linha pode informar até 10 feriados, contendo as informações de DATA e TIPO_FERIADO (0 - permanente ou 1 - eventual). Nesta linha, o primeiro feriado informado está na posição 151, sendo: "2021-01-25" (Aniversário de São Paulo)
No arquivo CAF501 que tivemos acesso, temos esta linha referente ao município de SP:
007388SAO PAULO SP1F2018SAO PAULO - SP 10001600 010 202101250202107090202311200 000573
Sendo o código 007388 (posição 1 a 6), referente a SAO PAULO (7 a 44) e a UF como SP (posição 45 a 47).
Cada linha pode informar até 10 feriados, contendo as informações de DATA e TIPO_FERIADO (0 - permanente ou 1 - eventual). Nesta linha, o primeiro feriado informado está na posição 151, sendo: "2021-01-25" (Aniversário de São Paulo)
Ótimo, obrigado @jorgebaruchi. Assumindo que você teria acesso a este arquivo, o que impediria você de estabelecer um mapeamento exaustivo do tipo:
codMun (IBGE) -> (codCAF) 3550308 -> 007388 ... -> ... ... -> ...
Nada. Se a gente definir que vamos usar o CAF501 como referência, vamos seguir neste linha mesmo. Só que nem todos os participantes tem acesso ao arquivo, como mencionado anteriormente.
Neste sentido, vamos centralizar este mapeamento ou fica a cargo de cada PSP ?
Nada. Se a gente definir que vamos usar o CAF501 como referência, vamos seguir neste linha mesmo. Só que nem todos os participantes tem acesso ao arquivo, como mencionado anteriormente.
Neste sentido, vamos centralizar este mapeamento ou fica a cargo de cada PSP ?
Se os participantes não podem todos ter acesso ao CAF501, então não faz sentido esse trabalho ser centralizado. Só faria sentido se todos pudessem ser beneficiados.
Boa tarde,
Conforme documentação da API Pix, ao consultar um payload, a instituição do pagador deve fornecer o código do munícipio, utilizando como referência os códigos IBGE. Assim a instituição recebedora deve utilizar este código para calcular o valor devido.
Poderiam nos ajudar a entender qual seria referência oficial do Pix obter os feriados municipais / estaduais por código IBGE de cada munício. Existe um padrão de arquivo que possamos importar ou uma API que possamos consumir ?
Muito obrigado