Funcionamento das cobranças em lote #171
Comments
Sim, esse é o funcionamento.
O loc é apenas a "vitrine" onde a cobrança é exibida. Precisaria efetivamente criar a cobrança que será apresentada no "loc".
Sim. É um bug. Obrigado pelo reporte @seanwykes
Não há. Mas acrdito que o loc não resolve o seu problema, ver resposta acima.
Sobre "como enfiar o código de barras atual dentro de um QR PIX", pode descrever mais em detalhes o caso de uso? |
No caso, a concessionária criaria um conjunto de locs e, por exemplo, será alocado N locs para cada dispositivo de leitura. Aí, o funcionário ao efetuar a leitura em situ, imprimirá o QR code e gravará um registro no dispositivo associado o loc e os dados lidos. Ao retornar à base, o backend receberá esses registros e criará um lote de cobranças que será submetido ao PSP pelo API-PIX, informando o {loc} utilizado em cada cobrança. A cobrança será criada vinculada à vitrine como disse. Por enquanto, não vejo impedimento para este caso de uso. Os locs podendo ser informados na criação do lote parece que resolve. |
Ok. Mas precisaria associar a cada "loc" os parâmetros corretos da cobrança considerando as leituras 'in loco'. Acho que funciona. Precisaria sempre criar um novo location, não poderia reaproveitar as locs antigas já criadas? Por exemplo, para um mesmo relógio, não daria para "cravar" um loc para ele? |
beleza.
Aí depende do funcionamento dos sistemas, mas seria com certeza a forma mais otimizada. Será preciso avaliar, no entanto, a memória limitada dos dispositivos móveis de captura, se cada funcionário tem rota preestabelecida e distinta de captura .. mas não é o foco aqui. Valeu pelas respostas. Tem muitas empresas com sistemas e processos já estabelecidos e funcionando há anos. Por isso é importante vislumbrarmos meios para a MMV (mínima mexida possível) e assim facilitarmos a migração para PIX!. |
É exatamente este o caso que estamos vendo .. muitas empresas e também bancos com sistemas rodando há milénios com códigos de barra no padrão FEBRABAN, e embora o QR dinâmico comporta os processos de pagamento, a minha percepção é que muitas deles estão buscando, neste primeiro momento, formas de facilitar a migração para PIX como meio de pagamento e não como ecosistema de cobranças, se você me entende. Aí, se o código de barras inteiro usado atualmente encaixasse (foi enfiado kkk) no QR estático ou dinâmico (e não cabe diretamente no TXID), o lado recebedor ao ser notificado (webhook ou outro) sobre o pagamento recebido, poderá montar um arquivo de entrada nos formatos atuais (contendo o código de barras) e largar para os processos ainda BATCH que nem ficariam sabendo que foi um PIX. |
@seanwykes , apenas complementando, não sei se ficou claro, mas os endpoints /lotecobv buscam agregar um comportamento de array aos endpoints /cobv. O PUT /cobv não serve apenas para criar uma cobrança, mas também para alterá-la de maneira idempotente. Segundo a API: Gerenciar quer dizer: "criar" mas também "alterar". Logo, você poderia usar essa semântica ao seu favor neste caso. Você não precisa criar locs em lote, porque vc pode criar cobranças com uma versão inicial "dummy" em lote, para, entre outros possíveis usos, aproveitar o location automaticamente criado pelo PSP. Veja:
Cabe dizer que ainda existem algumas questões que ainda estamos fechando. como por exemplo: "uma cobrança pode estar associada a dois ou mais lotes ao mesmo tempo?" Mas a ideia ideia principal é essa mesmo. |
Me parece que esse é o objetivo do padrão CNAB-750, que é mais próximo do CNAB atual. Eu pessoalmente preferia que o formato batch do ISO 20022, como já suportado por ERPs globais, fosse usado. Mas o que parece que está sendo mais considerado por quem vai oferecer boleto híbrido não é ter o mesmo código da CIP no QR-Code do Pix, e sim um código diferente, com relação 1:1 com boleto. Aí se for pago por Pix, o PSP imediatamente dá baixa do boleto registrado na CIP, e quando o boleto é pago na CIP, o PSP desativa o Pix (inclusive antes da efetiva compensação, mas quando já se sabe que o boleto foi inicialmente pago). |
Não havia ficado claro .. obrigado pela explicação.
Pelo jeito, atende aos dois casos .. criação automática de locs ou associação com locs pré-gerados. Ótimo. Obrigado |
Valeu as informações @rubenskuhl .. concordo contigo que o CNAB750 não é a melhor solução, até porque as mudanças no payload 2.1 já irão gerar ajustes por ser um arquivo "posicional". Sim, se usar o TXID para fazer um 1:1 tudo funciona beleza. Se o ecossistema consegue evoluir para tratar desta forma, melhor .. mas considerando que tem bancos ainda usando COBOL ou PL/1 ... sem falar das milhares de empresas clientes .. pode demorar um pouco e buscar soluções que compatibilizam, por exemplo, picar o código de barras e usar alguma combinação do TXID / Chave / Valor para representá-lo sem necessidade de criar esse mapping 1:1 .., pode ser uma saída para auxiliar na transição. Just my 10 cents. |
|
@seanwykes , versão |
Estou com alguma dúvidas sobre o funcionamento das cobranças em lote, a gostaria de verificar que o meu entendimento bate com o do BACEN.
Temos um caso de uso concreto em que uma concessionária (p.e. energia elétrica / água) faz a leitura do consumo e imprime a cobrança na hora, de modo OFFLINE. Posteriormente é enviado um arquivo de dados referente a cada cobrança. Hoje o sistema do banco e parceiros funciona desta forma, sendo que é feita simplesmente uma pre-alocação de um range de "números de série" do código de barras, que vai sendo consumido a cada leitura em campo.
Nosso mundo novo do PIX-API, se entendi bem, na criação de um lote (PUT /lotecobv), vai um vetor de informações de cobrança. Aí, o retorno 202 indica "Lote .. solicitado para criação". Aí, o status de todas cobranças no vetor pode ser consultado, retornando um vetor de { txid, status, criacao }.
Primeira dúvida: o { loc } é facultativo na solicitação. Se informado, deve ser associado a nova cobv a {loc} informado? E se não informado, deve ser criado um {loc}? A redação não está clara (ou não encontrei essa informação)
Se é possível informar o {loc} na criação, a concessionária poderá então solicitar um monte de {loc}s, talvez um para cada ramo/cliente, guardar os urls correspondentes e incorporar essa base de loc-url nos seus processos de leitora/impressão/envio. Aí, no backend, associa a cobv em lote com os {loc} consumidos. Procede?
Segunda dúvida: a descrição para { criacao } no vetor de retorno do GET /lotecobv/{id} é "Data e hora em que a location foi criada. Respeita RFC 3339.". Isso deveria ser "data e hora de criação da cobrança"?
Terceira dúvida: há previsão para a criação de {loc} em lotes? Entendo que pode ser chamada o API múltiplas vezes, mas acontece que há concessionárias com dezenas de milhões de contas para imprimir.
Quarta dúvida: Você sabe de algum processo de padronização em andamento, visando compatibilizar os processos e os códigos de barras de arrecadação e cobranças com PIX? Além da questão de vencimento/multa/juros. Tenho recebida diversas consultas sobre "como enfiar o código de barras atual dentro de um QR PIX" ....
Obrigado.
The text was updated successfully, but these errors were encountered: